共计 2374 个字符，预计需要花费 6 分钟才能阅读完成。
摘要： 收到个读者的问题，他在面试的时候，被搞懵了，因为面试官问了他这么一个网络问题。
本文分享自华为云社区《TCP 四次挥手收到乱序的 FIN 包会如何解决？》，作者：小林 coding。
收到个读者的问题，他在面试的时候，被搞懵了，因为面试官问了他这么一个网络问题：
不过这道网络题可能是发问的读者表述有问题， 因为如果 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 源码剖析
接下来，我带大家看看源码，听到要源码剖析，可能有的同学就怂了。
其实要剖析咱们明天这个问题，只有懂 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 函数退出到乱序队列。
而后当客户端收到被网络提早的数据包后，此时因为该数据包的序列号是冀望的，而后又因为上一次收到的乱序 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://elixir.bootlin.com/li…
我感觉还是挺好用的，左侧各个版本的代码都有，右上角也能够搜寻函数。
所以，我看 TCP 源码的教训就是，先在网上找找前辈写的 TCP 源码剖析，而后晓得整个函数的调用链路后，如果想具体理解某个函数的具体实现，能够在我说的那个看 Linux 内核代码的在线网站上搜寻该函数，就能够看到残缺的函数的实现。如果中途遇到看不懂的代码，也能够将这个代码复制到百度或者谷歌搜寻，个别也能找到他人剖析的过程。
学会了看 TCP 源码其实有助于咱们剖析一些异样问题，就比方明天这道网络题目，在网上其实是搜寻不出答案的，而且咱们也很难用试验的形式来模仿。
所以要想晓得答案，只能去看源码。
点击关注，第一工夫理解华为云陈腐技术~
