- 主动关闭方，进入TIME_WAIT；被动关闭方，进入CLOSE_WAIT。
- Listen端主动关闭进入TIME_WAIT状态，则Listent的Server能够立即接收同一个四元组的连接，通常没任何害处。
- Client端主动关闭进入TIME_WAIT状态，则该Client无法使用同一个local端口连接同一个Server端，但这通常也不会带来坏处，因为Client端通常使用随机端口。
- 假如Nginx即作为Server端又作为Client端，例如Nginx+FastCGI的组合，则应该让FastCGI主动关闭Nginx的请求。否则Nginx作为Client产生的TIME_WAIT将会浪费一个随机端口，造成Nginx作为Proxy无法应对海量的请求。
- 如果有大量CLOSE_WAIT状态的连接，表明对端已经Close了连接，但本端还没有执行Close()操作，有以两种常见的原因：
- 最常见的情况是编码错误，造成socket fd泄漏，在某些情况下未能正常Close连接。
- 另一种情况则是由于Server端非常繁忙，有大量的短连接来不及关闭，可以考虑开启Keepalive来解决。
本文解析了TCP连接中主动关闭方进入TIME_WAIT状态及被动关闭方进入CLOSE_WAIT状态的原因与影响。特别是针对Nginx作为客户端和服务端时如何避免TIME_WAIT状态导致的问题，以及大量CLOSE_WAIT状态连接可能的原因和解决方案。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
