大家好，又见面了，我是你们的朋友全栈君。
大家好，我是小林。
最近收到了一位读者的问题，他在面试鹅厂时被问到一个棘手的网络问题：
不得不说，鹅厂确实很喜欢考察网络问题，尤其是异常情况下的处理方式。之前也有读者分享过类似的经历：「被鹅厂面怕了！」。
然而，这道题目可能因为读者的表述有误，因为如果 FIN 报文在数据包之前到达客户端，实际上这是一个乱序报文，客户端的 TCP 连接并不会从 FIN_WAIT_2 状态转换到 TIME_WAIT 状态。
所以，我们需要关注的问题是：「在 FIN_WAIT_2 状态下，如何处理收到的乱序 FIN 报文，以及 TCP 连接何时才能进入 TIME_WAIT 状态？」。
我先直接给出结论：
在 FIN_WAIT_2 状态下，如果收到乱序的 FIN 报文，它会被加入到「乱序队列」中，并不会立即进入 TIME_WAIT 状态。
当客户端再次收到之前被网络延迟的数据包时，会检查乱序队列是否有数据。如果能在乱序队列中找到与当前报文序列号连续的报文，就会检查该报文是否有 FIN 标志。如果发现有 FIN 标志，这时才会进入 TIME_WAIT 状态。
我还画了一张图，大家可以结合图来理解。
接下来，我带大家看看源码。听到要分析源码，可能有些同学就退缩了。
其实，要分析我们今天的问题，只需要懂得 if else 语句就足够了。我也会用中文来解释代码逻辑，所以单纯看我的文字也是可以的。
这次我们重点分析的是，在 FIN_WAIT_2 状态下，收到 FIN 报文是如何处理的。
在 Linux 内核中，当 IP 层处理完消息后，会通过回调 tcp_v4_rcv 函数将消息传递给 TCP 层，所以这个函数是 TCP 层接收消息的入口。
处于 FIN_WAIT_2 状态的客户端，在收到服务端的报文后，最终会调用 tcp_v4_do_rcv 函数。
接下来，tcp_v4_do_rcv 方法会调用 tcp_rcv_state_process，在这里会根据 TCP 状态做相应的处理，我们只关注 FIN_WAIT_2 状态。
在上面的代码中，可以看到如果 shutdown 关闭了读方向，收到对方发来的数据包会回复 RST 报文。
而我们这次的问题中，shutdown 只关闭了写方向，所以会继续往下调用 tcp_data_queue 函数（因为 case TCP_FIN_WAIT2 代码块里没有 break 语句，所以会执行到该函数）。
在上面的 tcp_data_queue 函数中，如果收到的报文序列号是我们预期的，也就是有序的：
会判断该报文是否有 FIN 标志，如果有的话就会调用 tcp_fin 函数，这个函数负责将 FIN_WAIT_2 状态转换为 TIME_WAIT。接着还会检查乱序队列是否有数据，如果有的话会调用 tcp_ofo_queue 函数，这个函数负责检查乱序队列中是否有可用的数据包，即能否在乱序队列中找到与当前数据包序列号连续的数据包。而当收到的报文序列号不是我们预期的，也就是乱序的，则调用 tcp_data_queue_ofo 函数，将报文加入到乱序队列，这个队列的数据结构是红黑树。
我们的题目中，客户端收到的 FIN 报文实际上是一个乱序报文，因此此时并不会调用 tcp_fin 函数进行状态转换，而是通过 tcp_data_queue_ofo 函数将报文加入到乱序队列。
豆包AI编程
豆包推出的AI编程助手
483 查看详情
然后当客户端收到被网络延迟的数据包后，因为该数据包的序列号是期望的，又因为上一次收到的乱序 FIN 报文被加入到了乱序队列，表明乱序队列是有数据的，于是就会调用 tcp_ofo_queue 函数。
我们来看看 tcp_ofo_queue 函数。
在上面的 tcp_ofo_queue 函数中，在乱序队列中找到能与当前报文序列号保持连续的报文后，会检查该报文是否有 FIN 标志，如果有的话，就会调用 tcp_fin() 函数。
最后，我们来看看 tcp_fin 函数的处理。
可以看到，如果当前的 TCP 状态为 TCP_FIN_WAIT2，就会发送第四次挥手的 ack，然后调用 tcp_time_wait 函数，这个函数会将 TCP 状态变更为 TIME_WAIT，并启动 TIME_WAIT 的定时器。
怎么看 TCP 源码？之前有不少同学问我，我是怎么看 TCP 源码的？
其实，我看 TCP 源码，并不是直接打开 Linux 源码直接看，因为 Linux 源码实在太庞大了，如果我不知道 TCP 入口函数在哪，那简直就是大海捞针。
所以，在看 TCP 源码时，我们可以去网上搜索别人的源码分析，网上已经有很多前辈帮我们分析了 TCP 源码，而且各个函数的调用链路，他们都有写出来。
比如，你想了解 TCP 三次握手/四次挥手的源码实现，你就可以以「TCP 三次握手/四次挥手的源码分析」这样的关键字来搜索，大部分文章的注释写的还是很清晰，我最开始就是按这种方式来学习 TCP 源码的。
网上的文章一般只会展示重点的部分，很多代码细节没有贴出来，如果你想完整地看到函数的所有代码，那就得看内核代码了。
这里推荐一个看 Linux 内核代码的在线网站：
https://www.php.cn/link/d0a194dc29ee00d2f22ef573f2d7097f
我觉得这个网站还是挺好用的，左侧有各个版本的代码，右上角也可以搜索函数。
所以，我看 TCP 源码的经验就是，先在网上找找前辈写的 TCP 源码分析，然后知道整个函数的调用链路后，如果想具体了解某个函数的具体实现，可以在我说的那个看 Linux 内核代码的在线网站上搜索该函数，就可以看到完整的函数实现。如果中途遇到看不懂的代码，也可以将这个代码复制到百度或者谷歌搜索，一般也能找到别人分析的过程。
学会了看 TCP 源码其实有助于我们分析一些异常问题，就比如今天这道网络题目，在网上其实是搜索不出答案的，而且我们也很难用实验的方式来模拟。
所以要想知道答案，只能去看源码。
这次就说到这啦，我们下次见！
发布者：全栈程序员栈长，转载请注明出处：https://www.php.cn/link/32e0740fc318fc059523a2f830a5b248
以上就是又被鹅厂问懵逼了：TCP 四次挥手收到乱序的 FIN 包会如何处理？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/464482.html
微信扫一扫 
支付宝扫一扫 
