经常有人问这个问题，这种问题问我就对了。我准备了下面的一幅时序图来解释这个问题：

简单点说就是两个目的：

• 正常处理被动关闭方的重传 FIN；
• 确保当前连接的所有报文全部消失。

也就是说，无论任何情况下，只要交互还在进行或者有可能还要进行，双方就不会全部 CLOSED。

比如说，被动关闭端始终等不到最后的 ACK，它会一直重传 FIN，即使这些重传全部无回应，由于它一直处在 LAST_ACK 状态，相同四元组的连接就建不起来。而对于主动关闭端，只要它收到对端的 FIN，不管是原始的还是重传的，都重置 2MSL 定时器，以确保自己发出的 ACK 消失或被 RST，这种情况下，在定时器到期之前，同四元组的连接依然建不起来。

但协议规范并非总是精确映射进具体实现，否则这就是一个非常显然的安全攻击面。试想大量主动发送端故意不对 FIN 进行 ACK 则如何，被动关闭端的 LAST_ACK 连接将耗尽系统资源。但我们知道，这种情况不会发生，对于 Linux TCP(比如) 实现，存在一个 “最大重传次数” 参数，在 FIN 重传次数到达该值时，连接将被无条件释放。

关于 MSL 本身，它与什么有关，取值多少？在具体实现中，我们经常希望它为很小的值，30s 嫌大，更别提 1m，2m。MSL 与网络规模相关，但对 TCP 的现实意义不大。

一个报文在网络上最长驻留时间与介质光速，网络直径，网络拓扑，排队时长等因素有关，而这些皆由网络规模决定，因此火星上的 MSL 与地球上肯定不同。但对于 TCP 而言，旧连接报文侵染新建连接是非常小概率事件，为这件事坚持 2MSL 的时间造成的连接资源浪费的成本完全可以让应用程序花小得多的代价自己买单。

1980 年代的 2MSL 不算什么，彼时多对一 C/S 通信模型尚不流行，对等通信模型的连接资源并不昂贵，相反却非常廉价，主机根本不会有 “太多”，“大量” 的连接场景和需求，但进入 HTTP 时代后，情况不一样了，“timewait 太多”，“大量 last_ack 消失不了”，“大量 closing 关不干净” 等变成了最大的恶，因为它们不光阻碍新连接建立，还消耗了大量内存，优雅关闭成了累赘，因此我建议直接用 RST 关连接，或将 MSL 设为 0，然后把皮鞋扔向经理。

浙江温州皮鞋湿，下雨进水不会胖。