TCP四次挥手释放连接的相关问题思考

TCP(Transmission Control Protocol, 传输控制协议)的三次握手和四次挥手是很基础的计算机网络知识, 也是很常见的考题, 在期末考试和面试的过程中我都有遇到过

本文是对TCP四次挥手释放连接的几个经典问题思考. 我觉得其中的设计考量是挺值得推敲的, 所以我就专注于分享所理解到的设计思想吧, 可能会忽视一些实现上的具体细节

同样的, TCP三次握手建立连接的过程也有一些经典问题诸如"为什么要三次握手而不是两次"等, 不过我觉得还是四次挥手的这几个问题更具有思考深度和参考意义吧

贴一张我找来的四次挥手图片吧, 这样比较直观一些

接下来就是三个经典的问题(所提及的客户端和服务端均以上图为标准, 左为客户端, 右为服务端):

1. 为什么需要第四次挥手? 三次不能吗?

• 一般情况下, 如果只有三次挥手, 那么当服务端发起第三次挥手之后就关闭了, 客户端收到这一次报文也就可以关闭了. 但这是不出差错的理想化情况, 假设如果这一次没能发送成功+接收成功呢? 这样的话服务端是直接关闭了, 但是客户端一直就不会得到服务端"我没有信息要发送了, 你可以关闭了"这样一个信号, 那么客户端的接收功能就一直不会关闭, 资源就杵在那浪费了
• 但是实际上, 是可以三次挥手就释放连接的. 这种情况就是"第二次挥手和第三次挥手的报文一起发送", 如下图的逻辑
  

2 .四次挥手就能保证这个过程成功吗? 如果发送了没能接收到呢?

• TCP有超时重传的机制, 在第三次挥手的报文发送后, 服务端就开始计时(依靠重传定时器, TCP一共有4种定时器), 如果计时结束还未收到来自客户端的第四次挥手报文, 那就认为这次过程失败了(可能是第三次挥手出了问题, 也有可能是第四次挥手出了问题). 不过无论是哪次出了问题, 解决方式都一样: 直接重发一个第三次挥手的报文即可. 重复这个过程, 直到成功完成四次挥手为止

3. 为什么第四次挥手的发送方需要等待2MSL? 如果不等待而直接关闭会怎么样?

• 首先, 解释一下MSL. MSL = Maxmimal Segment Lifetime, 最大报文存活时间(不同文章的翻译结果可能有偏差, 总之就是报文从诞生到消失的"生存时间"), 有标准定义的时长, 也可以自定义这个时长, 不过这并不是重点

• 原因1: 第四次挥手并不是一定能成功到达服务端的. 如果不能成功到达, 会触发服务端第三次挥手的超时重传(上文也有提及). 假设客户端不等待2MSL而直接关闭的话, 显而易见, 有可能并不会真正地完成两端的连接释放. 导致的结果就是, 客户端确实是关闭连接了, 但服务端迟迟没有收到第四次挥手报文, 无法关闭连接, 且会一直给客户端不断地"超时重传"第三次挥手报文, 那可太糟糕了

• 原因2: 为了不让本次TCP连接所产生的任何一个报文去干扰下一次的TCP连接. 比如在2)中, 提到的挥手报文出现问题的时候, 并不一定是报文丢失/销毁了, 而可能是因为网络中产生了阻塞等情况, 导致它未能及时传达. 但是如果四次挥手之后直接关闭TCP连接, 不考虑这些”仍然存活且还去向不明的报文”的话, 假设此时该客户端和服务端很快又建立了一个TCP连接(比如为了请求其他的网页资源), 那么这些旧的报文就有可能对新的这个TCP连接造成干扰. 因为TCP报文的内容包含一些序列号(由报文序列和滑动窗口大小等决定), 所以旧的TCP连接中的报文是有可能对新的TCP连接产生干扰的. 因此, 在第四次挥手之后等待2MSL的时间, 使得该次TCP连接中的所有报文全部失效, 就可以避免这个可能的问题
  在我的理解中, 理论上是可以设计更复杂的报文结构去甄别该报文是否属于当前的TCP连接(比如给报文添加当前连接编号的字段), 但那肯定会影响性能, 加重网络IO的负担(比起UDP报文来说, TCP报文的长度已经较大了, 再添加字段的话, 可能并不是个好主意). 相比之下, 在第四次挥手之后等待2MSL就可以解决这样的问题, 我觉得还是高下立判的

• 另外还有一个问题: 为什么是2MSL而不是1.5MSL呢? 看起来1.5MSL也是可以解决这个问题的, 但2MSL的设计既然经得起理论和实际工程上的考验, 肯定是足够合理的. 目前我还没有找到很合适的解答, 如果有找到的话我再更新吧

文中图片来自于下方视频链接, 我觉得这个视频合集对于计算机网络的讲解是非常好的, 推荐一下:
https://www.bilibili.com/video/av52745283/?spm_id_from=333.788.videocard.1