TCP协议确认号在哪种情况下使用，以及TCP/IP详解对这个描述的疑问？

Posted 2021-04-15 车小胖谈网络

读者提问

TCP/IP详解 卷一 第二版 12.3的一段描述：“这个字段只有在ACK位字段被启用的情况下才有效，这个ACK位字段通常用于除了初始和末尾报文段之外的所有报文段。”英文版：" This field is valid only if the ACK bit field (describedlater in this section) is on,which it usually is for all but initial andclosing segments."

 

我认为这里的描述并不正确，TCP从三次握手开始到四次挥手，只有第一个报文段没有设置确认号。

 

 而在这本书的第一版中表述："Therefore we'll see that once a connection is established,this field is always set and the ACK flag is always on. "。我觉得这个是正确的表达。

归纳一下我的问题。首先，我不理解这里说的末尾报文段(closingsegment)指的是哪个。其次，我只看到在三次握手中的第一个报文段ACK为0，也就是说这本书第二版在这的表述是错误的。

正文

正常TCP通信只需要关心“SYN”、“ACK”、“FIN”，所以接下来只关心这三个状态标志位。

 

第一次握手

TCP主动发起的一方命名为“小攻”， TCP被动响应的一方命名为“小守”。

 

小攻需要将以上的TCP Header进行填充动作：

“SYN=1”

“Sequence  Number = 123456789”  (操作系统随机数)

 "Acknowledge Number”怎么填？

Acknowledge Number = 接收到对方TCP Header的Sequence Number + 1

而此时还没有接收到小守的任何信息，所以没法填，只有填默认值“0”，表示“空白”。

由于此时“Acknowledge Number”为空白，所以置ACK =1没有任何意义。

所以此时ACK也是0，表示空白。

 

第二次握手

小守接到了自然要回应，接下来就简单了，

“SYN=1”

“Sequence  Number = 987654321”  (操作系统随机数)

“Acknowledge Number“ = 小攻的Sequence number + 1 = 123456789 + 1 =123456790

“ACK =1”

 

看，小守由于知道了对方的“sequence number”,所以需要同时设置“Acknowledge Number” 与 “ACK”了。

 

第三次握手

小攻发的消息更简单，由于SYN已经完成了历史使命，第三次就无需 “SYN”标志位了。

“Sequence  Number = 123456790

“Acknowledge Number“ = 小守的Sequence number + 1 =987654321 + 1 =987654322

“ACK =1”

 

Okay，以上就完成了TCP三次连接握手，然后双方就可以愉快地互动了。

Happy完了，自然要断开，任意的一方都可以提出分手，可以使用 “FIN=1”来告诉对方要分手了，这种分分合合的游戏见得多了，大家自行脑补。

 

为何除了第一个TCP报文没有 “ACK=1”,其它的TCP报文都需要 “ACK=1”?

至于为何第一个TCP报文 “ACK=0”已经解释过了，那么就来解释为何其它TCP报文都需要 “ACK=1”？

 如果没有“ACK=1”，而且TCP报文没有携带任何Data，这样的报文有何意义?

没有任何意义！(Reset报文除外)

如果没有“ACK=1”，TCP携带Data，这样的报文只是纯纯粹粹的数据传输，无法ACK对方。

既然“ACK”标志位闲着也是闲着，为何不能让“ACK=1”呢？

 领导常数落下属的口头禅：多干点活能死啊？

不能！

既然闲着也是闲着，而“ACK=1”带来的好处多多，那为何不“ACK=1”呢？

抓一个完整的TCP连接可以发现这神奇的一幕，有状态防火墙就是利用这一点，只要检查报文的“ACK”是否为0，为0则是第一个报文，而第一个报文也是主动发起的一个报文。

如果第一个报文从inside（内网）收到，允许通过并提供必要的协助。

如果第一个报文从outside(外网）收到，直接拒绝，除非ACL明确允许（outside-inside）流量通过。

留给读者的问题，Sequence number 为何要采用随机数?