TCP通信过程中time_wait和close_wait产生过多的原因和解决方法

目录

由于socket是全双工的工作模式，一个socket的关闭，是需要四次握手来完成的。

 time_wait 产生原因：

time_wait过多产生原因：

time_wait过多解决方法：

短连接 

长连接 

close_wait产生原因：

close_wait产生太多原因：

close_wait太多解决方法：

Socket连接到底是个什么概念？

什么时候用长连接，短连接？ 

报文发送接收方式 （同步和异步）？

---

由于socket是全双工的工作模式，一个socket的关闭，是需要四次握手来完成的。

• 主动关闭连接的一方，调用close()；协议层发送FIN包

• 被动关闭的一方收到FIN包后，协议层回复ACK；然后被动关闭的一方，进入CLOSE_WAIT状态，主动关闭的一方等待对方关闭，则进入FIN_WAIT_2状态；此时，主动关闭的一方 等待 被动关闭一方的应用程序，调用close操作。

• 被动关闭的一方在完成所有数据发送后，调用close()操作；此时，协议层发送FIN包给主动关闭的一方，等待对方的ACK，被动关闭的一方进入LAST_ACK状态；

• 主动关闭的一方收到FIN包，协议层回复ACK；此时，主动关闭连接的一方，进入TIME_WAIT状态；而被动关闭的一方，进入CLOSED状态

• 等待2MSL时间，如没发现重传的FIN，主动关闭的一方，结束TIME_WAIT，进入CLOSED状态

• 

 time_wait 产生原因（等待2MSL意义）：

假设是客户端向服务端发起断开连接

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

防止“已失效的连接请求报文段”出现在本连接中。

客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

time_wait过多产生原因：

正常的TCP客户端连接在关闭后，会进入一个TIME_WAIT的状态，持续的时间一般在1-4分钟，对于连接数不高的场景，1-4分钟其实并不长，对系统也不会有什么影响，
但如果短时间内（例如1s内）进行大量的短连接，则可能出现这样一种情况：客户端所在的操作系统的socket端口和文件描述符被用尽，系统无法再发起新的连接！

举例来说：
  假设每秒建立了1000个短连接（Web场景下是很常见的，例如每个请求都去访问memcached），假设TIME_WAIT的时间是1分钟，则1分钟内需要建立6W个短连接，由于TIME_WAI