TCP的TIME WAIT快速回收与重用

               

声明一点：

Linux中是无法修改tcp的TIME_WAIT值的，除非重新编译，起码我是没有找到怎么改。值得注意的是，net.ipv4.tcp_fin_timeout这个参数是FIN_WAIT_2的值，而不是TIME_WAIT的值。我不知道为何很多人都会把它当成是TIME_WAIT的值，想了一下，我觉得是两点：
1.TIME_WAIT过于耀眼，以至于所有出现timeout，加上里面有个tcp的配置，都会想当然往TIME_WAIT上联系；
2.FIN_WAIT_2过于默默无闻，以至于很少有人知道它也是一种状态。
所以，我想大家在学习的时候，不能想当然。

TIME_WAIT的作用

TCP初见于互联网早期，当时的网络很不稳定，大量的丢包，为了冗余，大量包复制多径传输，网速慢--正因为如此，TCP才会更有意义。为了保证TCP的严格语义，就要避免上述冗余机制以及网速慢导致的问题，这些问题集中体现在连接关闭时的四次挥手上。
        由于TCP是全双工的，因此关闭连接必须在两个方向上分别进行。首先发起关闭的一方为主动关闭方，另一方为被动关闭方。很多人都会在这里晕掉，实际上四次挥手比三次握手还简单。四次挥手简单地分为三个过程：
过程一.主动关闭方发送FIN，被动关闭方收到后发送该FIN的ACK；
过程二.被动关闭方发送FIN，主动关闭方收到后发送该FIN的ACK；
过程三.被动关闭方收到ACK。
以上三步下来，圆圈就闭合了！也就是说，在过程三后，被动关闭方就可以100%确认连接已经关闭，因此它便可以直接进入CLOSE状态了，然而主动关闭的一方，它无法确定最后的那个发给被动关闭方的ACK是否已经被收到，据TCP协议规范，不对ACK进行ACK，因此它不可能再收到被动关闭方的任何数据了，因此在这里就陷入了僵局，TCP连接的主动关闭方如何来保证圆圈的闭合？这里，协议外的东西起作用了，和STP(Spanning tree)依靠各类超时值来收敛一样，IP也有一个超时值，即MSL，这类超时值超级重要，因为它们给出了一个物理意义上的不可逾越的界限，它们是自洽协议的唯一外部输入。MSL表明这是IP报文在地球上存活的最长时间，如果在火星上，Linux的代码必须要重新定义MSL的值并且要重新编译。
       于是问题就解决了，主动关闭一方等待MSL时间再释放连接，这个状态就是TIME_WAIT。对于被动关闭的一方，发出FIN之后就处在了LAST_ACK状态了，既然已经发出FIN了，缺的无非也就是个ACK，连接本身其实已经关闭了，因此被动关闭的一方就没有TIME_WAIT状态。
       实际上，两倍MSL才能说明一个报文的彻底丢失，因为还要记入其ACK返回时的MSL。