【Tcp】TCP连接中存在大量TIME_WAIT、CLOSE_WAIT的原因【转】

TCP通信图

TIME_WAIT

表示客户端主动关闭socket。

原因：

• 大量的短连接存在
• 特别是 HTTP 请求中，如果 connection 头部取值被设置为 close 时，基本都由服务端发起主动关闭连接
• TCP 四次挥手关闭连接机制中，为了保证 ACK 重发和丢弃延迟数据，设置 time_wait 为 2 倍的 MSL(报文最大存活时间)

后果：

• TCP 连接中，「主动发起关闭连接」的一端，会进入 time_wait 状态
• time_wait 状态，默认会持续 2 MSL(报文的最大生存时间)，一般是 2x2 mins
• time_wait 状态下，TCP 连接占用的端口，无法被再次使用；TCP 端口数量，上限是 6.5w(65535，16 bit)
• 大量 time_wait 状态存在，会导致新建 TCP 连接会出错，address already in use : connect 异常
• 占用内存，但内存占用并不大，1万条TIME_WAIT的连接，也就多消耗1M
• 耗CPU，每次找到一个随机端口，需要遍历一遍bound ports的吧，这必然需要一些CPU时间，但也还好，无需太担忧

解决：

• 服务器端允许 time_wait 状态的 socket 被重用
• 缩减 time_wait 时间，设置为 1 MSL
• 修改内核参数：
  net.ipv4.tcp_tw_recycle = 1
  net.ipv4.tcp_tw_reuse = 1
  net.ipv4.tcp_timestamps = 1
  https://zhuanlan.zhihu.com/p/40013724

CLOSE_WAIT

表示服务端被动关闭socket。

根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。

原因：应用程序写的有问题，没有合适的关闭socket；要么是服务器CPU处理不过来（CPU太忙）或者应用程序一直睡眠到其它地方(锁，或者文件I/O等等)，应用程序获得不到合适的调度时间，造成程序没法真正的执行close操作。

后果：出现大量的CLOSE_WAIT后，服务无法继续正常服务，端口无法被复用，socket资源被耗尽。因为Linux分配给一个用户的文件句柄是有限的，而如果一直被保持，则文件句柄也就不能close，导致句柄资源达到上线，接着就会出现大量Too Many Open Files错误。