关于TCP四次挥手的疑惑

记一次wireshark抓包

Posted by mengxun on November 25, 2018

前言

最近一段在读《TCP/IP详解》,在第18章讲了TCP的连接和断开,其中有提到四次挥手过程,尽管之前就知道有四次挥手这个东西,但是也是一知半解,这次我用Wireshark抓了一下包,却发现了一个问题。

问题的来历

wireshark的截图如下: 这就是wireshark抓到的四次挥手过程,可是这明明就三次挥手好不好,跟平常大家说的和书上讲的有所出入,难道说当接受端没有数据要发送的时候,第二次挥手和第三次挥手会合并么,于是带着问题去Google翻了下文章和资料。

解决

网上有很多人的答案,都在人云亦云的说这个东西在RFC793的3.5节里有提及这个东西,可是我打开RFC793的3.5节Closing a Connection,压根没找到有说这回事的话!

后来还是在知乎上找了个没人赞过(其实就这个答案答到点上了)的答案启发了我一下,才让我明白是怎么一回事:

那什么是延迟确认呢,其实在详解的第19章有讲到这个,下面简单讲一下

延迟确认

延迟确认就是延迟ACK,其实就是让接收方在收到数据后不立即反馈ACK消息,而是等到一小段时间,如果之后还有收到其他包就把这些ACK消息一起放入一个包中反馈给客户端。

这个延迟ACK机制并不会延迟太长时间,因为发送端对ACK反馈消息的等待是有时限的,这就是TCP对数据传输时的超时时间。如果延迟太久可能会导致超时,所以这个延迟ACK的值通常不会超过200ms。

而之所以我在wireshark上只抓到了三个包,其实就是因为TCP的这个延迟确认机制。

那问题来了,这个延迟确认会在什么时候启用呢?

其实这个问题在网上有篇文章讲的很不错,他也是跟我遇到同样的问题,然后他就在linux内核源码里找了一下原因,感兴趣的可以看看……感觉比我厉害多了,一言不和就直接弄内核源码,我都是先在google上查查,实在查不着了再看看源码_(:з」∠)_