TCP time_wait 的存在意义

《TCP/IP详解》中的TCP的建立和终止中有关"TCP的终止"的讲解 TCP的终止通过双方的四次挥手协议实现。发起终止的一方执行主动关闭，响应的另一方执行被动关闭。 　

　　1. 发起方更改状态为FIN_WAIT_1，关闭应用程序进程，发出一个TCP的FIN段(FIN J)； 　

　　2. 接收方收到FIN段，返回一个带确认序号的ACK(ACK J+1)，同时向自己对应的进程发送一个文件结束符EOF，同时更改状态为CLOSE_WAIT，发起方接到ACK后状态更改为FIN_WAIT_2； 　

　　3. 接收方关闭应用程序进程，更改状态为LAST_ACK，并向对方发出一个TCP的FIN段(FIN K)； 　

　　4. 发起方接到FIN后状态更改为TIME_WAIT，并发出这个FIN的ACK(ACK K+1)确认。ACK发送成功后（2MSL后）， 双方TCP状态变为CLOSED。 我们不难看出上面的显示的结果的意思。根据TCP协议，主动发起关闭的一方，在发送ACK K + 1后，会进入TIME_WAIT状态，持续2*MSL(Max Segment Lifetime)。

TIME_OUT状态的存在的意义 

TIME_WAIT状态发生在了active close 端，产生的时间点是发送ACK K+1 分节之后，原因是防止ACK分节在网络中丢失（lost），此时passive close进入LAST_ACK状态，意为等待ACK分节，如果此时ACK分节真的丢失了（passive close端的LAST_ACK超时），那么passive close端将会再次发送一个FIN K分节给对端。这就是为什么在图中，出现两次FIN的分节。 

因此，TIME_OUT存在的理由：
1、 可靠地实现TCP全双工连接的终止。 
2、 处理的可能存在的重复FIN包。  

TIME_OUT状态的持续时间 
图中标明了TIME_OUT状态的持续时间是最长分节生命周期（MSL）的两倍，即2MSL。RFC（ 因特网标准）中的建议 MSL值 是2分钟，Berkeley的实现传统上使用的是30秒，那么这意味着TIME_WAIT状态的延迟是在1~4分钟之间。  

对于CS的模式，大多是由客户机主动关闭连接，这也避免了TIME_OUT产生于服务端，但对于某些协议，如HTTP则是由服务器执行主动关闭的。 

为了避免多个请求产生多个连接，也就是避免产生创建连接的三次握手和断开连接四次挥手协议的消耗，和出现大量处于TIME_WAIT状态的连接。

于是，长连接就有存在的意义。至于长连接的保持，可以打开keepalive  选项或者在应用层发送心跳包。

总结

以上是生活随笔为你收集整理的TCP time_wait 的存在意义的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。