TCP连接建立或终止的三次握手中的段序列号

网络工程 tcp 协议论 传输协议 第 4 层
2022-02-28 01:59:54

我试图从Forouzan 的书中了解 TCP 连接建立和终止步骤。

在连接建立的三次握手的第三步中,它说如下

客户端发送第三个段。这只是一个 ACK​​ 段。它用 ACK 标志和确认号字段确认第二个段的接收。请注意,如果 ACK 段不携带数据,则它不会消耗任何序列号,但某些实现允许连接阶段的第三段携带来自客户端的第一块数据。在这种情况下,该段消耗的序列号与数据字节数一样多。 在此处输入图像描述

Q1。 我没有得到大胆的面对句子。它说如果第三段只是ACK并且不携带任何数据,则不消耗序列号。但是,在图中,显示的第一段和第二段都有不同的序列号 8000 和 8001。我觉得两者都应该是 8000。

在连接终止的三次握手的第三步中,它说:

客户端 TCP 发送最后一个段,一个 ACK​​ 段,以确认收到来自 TCP 服务器的 FIN 段。该段包含确认号,它是从服务器接收到的 FIN 段中的序列号加一。段不能携带数据并且不消耗序列号在此处输入图像描述

Q2。我再一次没有得到大胆的面对句子。它表示如果 ACK 段不携带数据,则不会消耗序列号。但在图中,第一段和第三段的序号不同:x 和 x+1。我觉得两者都应该是x。

我在这里犯了一些错误来理解图表吗?

在本书后面的某个地方,在解释如何计算重传定时器时,它显示了连接建立阶段如下:

在此处输入图像描述

注意第一段和第三段有相同的序号,1400。那么为什么第一段和第二段的第一段和第三段有不同的序号呢?他们应该有相同的序列号还是我错过了解释“不消耗序列号”?

2个回答

我认为您缺少的部分是确认号是下一个预期的数据数。带有 ACK 的段表示我在此确认号之前确认了所有内容,并且我期望的下一个数据将以该确认号作为其序列号开始。

在第一个图中,第一个段 (SYN) 中没有确认号,因为发送方还不知道接收方将使用什么序列号来启动。下一个段(SYN 和 ACK)都有一个序列号,而确认号是它接收到的序列号加一,因为这是它所期望的下一个(下一个接收到的任何数据都将从该序列号开始)。设置了 ACK 标志,因此它在确认号之前确认接收到所有内容,并设置它接收到的下一个数据序列号的期望值。第三段 (ACK) 也设置了 ACK 标志,因此它也在确认接收到确认号之前的所有内容,并设置它接收到的下一个数据序列号应该是什么的期望。

如果您理解这一点,那么第二张图也很有意义。请记住,初始握手后的几乎每个段都将携带两个数据并设置 ACK 标志。FIN 段也可以携带数据;它只是告诉对方它已完成发送,但对方可以继续发送数据直到完成。显然,对方也完成了,回复一个FIN,但也是一个ACK,并且确认号需要为X + 1,表示它确认的所有内容都少于此,并且接下来收到的任何数据都需要从X +开始1.

在第三个图中,序列号为 1400 的两个段是正确的,因为它们都没有显示任何数据。确定序列号的是数据,它是确认号中接下来预期的内容。

Q1:即使不携带数据,SYN 段也消耗序列号中的一个字节,因为 SYN 标志必须得到对等方的确认。这就是服务器回复 8001 的 ACK 并且下一个客户端段序列号是 8001 的原因。

Q2:FIN 标志也必须被确认(所以在服务器回复中 +1)并表示“我已完成发送数据”。这就是为什么在该段之后,客户端不能再发送任何数据(但只要这个还没有发送 FIN 标志,它仍然可以从服务器接收)。

在第三张图中,这是一个故障,因为 SYN 标志计为 1 个字节(对等方正确地确认了 SYN。在真实网络中,这会给服务器带来麻烦,因为它看起来像是没有 SYN 标志的重传......)。第三段的序号应该是1401(和第四段一样)。