被印证的感觉,真爽!

共 2831字,需浏览 6分钟

 ·

2022-02-27 09:29

大家好,我是小林。

之前我在公众号解答了一位读者面试腾讯的面试题,问题如下:

当时我看到这个问题也没有思路,后面我就啃了 TCP 源码,把这个问题搞清楚了,就写了这篇文章:TCP 四次挥手收到乱序的 FIN 包会如何处理?

针对这个问题,我也没办法用实验来验证我的结论,所以当时结论是基于啃 TCP 源码得出来的。

但是,就在昨天!

有位读者在工作中抓到跟这个面试题场景类似的抓包图,我看了下,现象跟我之前啃 TCP 源码得出的结论是符合的。

这种被印证的感觉真爽!

我觉得这个案例还是挺有意思的,因为很好的说明是 TCP 传输协议是按序接收的。

所以,先来回顾腾讯一面的这个问题,再来看看跟这个问题相似的抓包图。

回顾问题

这道鹅厂的网络题可能是提问的读者表述有问题。

因为如果 FIN 报文比数据包先抵达客户端,此时 FIN 报文其实是一个乱序的报文,此时客户端的 TCP 连接并不会从 FIN_WAIT_2 状态转换到 TIME_WAIT 状态。

因此,我们要关注到点是看「在 FIN_WAIT_2 状态下,是如何处理收到的乱序的 FIN 报文,然后 TCP 连接又是什么时候才进入到 TIME_WAIT 状态?」。

我这里先直接说结论:

在 FIN_WAIT_2 状态时,如果收到乱序的 FIN 报文,那么就被会加入到内核中的「乱序队列」,并不会进入到 TIME_WAIT 状态。

等再次收到前面被网络延迟的数据包时,会判断乱序队列有没有数据,然后会检测乱序队列中是否有可用的数据,如果能在乱序队列中找到与当前报文的序列号保持的顺序的报文,就会看该报文是否有 FIN 标志,如果发现有 FIN 标志,这时才会进入 TIME_WAIT 状态

我也画了一张图,大家可以结合着图来理解。

TCP 源码分析这里我不再说明了,之前也分析过了,感兴趣的详见:TCP 四次挥手收到乱序的 FIN 包会如何处理?

神一般的抓包图

下图是昨天一位读者发给我的抓包图,图中的异常情况,跟前面这个问题的现象有点类似:

你可能会有疑问为什么 TCP 握手时,双方的 seq 都是 0 开始的?这个是抓包图做了优化,显示的是相对值,而不是真实值,显示相对值方便分析。

为了方便文字描述,我针对异常部分的报文进行编号如下:

图中端口号为 11710 的为客户端,端口号为 8080 的为服务端。另外,编号 4 是客户端发送的 http 请求,抓包图没有显示 TCP 信息,这里文字补充下:编号 4 数据报文 seq = 1,ack = 1,len = 27

编号 6 是 FIN 报文,也就是服务端向客户端发送的 FIN 报文(第一次挥手),但是是一个乱序的 FIN 报文,因为从编号 4 报文中的 ack = 1 知道,客户端期望下一次收到的报文的序列号为 1,而当前收到的 FIN 报文的 seq = 177,这并不是客户端下一次期望收到的报文,所以是乱序的。

客户端收到乱序 FIN 报文后,并不会从 establish 转为 close_wait 状态,而是把这个乱序的 FIN 报文放到内核中的乱序队列。因为如果这时候就进入了 close_wait 状态,就会马上发送 FIN 报文了(第三次挥手),而不会有客户端后面发送的编号 8 和 9 报文的事情了。

编号 8 是应答报文,是客户端对编号 6 乱序 FIN 报文的应答报文,可以看到这个应答报文中 seq = 28,ack=1,因为并不是我期望的下一个报文,所以应答报文中 ack 还是为 1。

编号 7 是数据报文,也就是服务端向客户端发送的数据报文,该报文 seq = 1,ack=28,len=176,因为 seq 为 1,所以是客户端期望收到的报文。客户端收到该报文后,就回了编号 9 应答报文,此应答报文 seq = 28,ack = 178,其中 ack = 178 是告诉服务端:“你发的 seq = 178 之前(不包括seq=178)的报文,我都收到了,我下次期望收到的报文的 seq 为 178”。

客户端收到编号 7 数据报文时还会做一件事情,会检测「乱序队列」中是否有可用的数据,如果能在乱序队列中找到与当前收到报文的序列号「保持的顺序」的报文,就把处于乱序队列的报文移到可以被正常处理的数据队列。比如,这次的案例中,编号 7 报文 seq = 1,len=176 的数据范围是 1~176,而乱序队列中的 FIN 报文的 seq = 177,这两个报文的 seq 正好是保持顺序的,所以会把  FIN 报文从乱序队列中拿出来一起处理,然后发现有 FIN 标志,于是就会转换状态。

所以,客户端在应答完编号 7 数据报文后,就立马发送 FIN 报文了(第三次挥手),接着服务端应答了该报文,至此四次挥手结束。

这个抓包图跟前面这个腾讯的面试题有一点差异,差异在于:

  • 腾讯的面试题是在 FIN_WAIT_2 状态下收到乱序的 FIN 报文(第三次挥手);
  • 抓包图是在 establish 状态收到了乱序的 FIN 报文(第一次挥手);

上面这两种 TCP 状态,收到乱序的 FIN 报文,并不会立即转换状态,只会被内核放到一个乱序队列里。等收到一个序列号符合「接收方」期望收到的序列号的数据包时,会检测「乱序队列」中是否有可用的数据,如果能在乱序队列中找到与当前收到报文的序列号「保持的顺序」的报文,就会看该报文是否有 FIN 标志,如果发现有 FIN 标志,就会转换状态

所以,从这里可以看到, TCP 传输协议是按序接收,如果收到一个乱序的报文时,并且在接收窗口范围内(序列号超过接收窗口范围外的报文就会被丢弃),就会缓存在内核中的乱序队列,不做其他处理。等收到能与乱序队列中报文的序列号保持顺序的报文,才会一起被处理。

TCP 层必须保证收到的字节数据是完整且有序的,所以如果序列号较低的 TCP 报文在网络传输中丢失了,即使序列号较高的 TCP 报文已经被接收了,应用层也无法从内核中读取到这部分数据。

举个例子,如下图:

图中发送方发送了很多个 packet,每个 packet 都有自己的序号,你可以认为是 TCP 的序列号,其中 packet 3 在网络中丢失了,即使 packet 4-6 被接收方收到后,由于内核中的 TCP 数据不是连续的,于是接收方的应用层就无法从内核中读取到,只有等到 packet 3 重传后,接收方的应用层才可以从内核中读取到数据。

完!

图解系列文章:
看书的一点小建议!
图解系列文章汇总
计算机基础学习路线
小林的图解系统,大曝光!
不鸽了,小林的「图解网络 3.0 」发布!
浏览 27
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报