CLOSE_WAIT

这个状态特别有用,只要看到这个状态,就说明程序有bug了!!!
这个是程序bug,不是配置上的问题,要么是中间件的,要么是应用层的.
本题考查的是TCP状态机(很有用).
关闭连接的时候,双方都可以作为主动关闭连接方.
主动关闭连接方--主动端
被动关闭连接方--被动端
主动端的状态：FIN-WAIT-1，FIN-WAIT-2，TIME-WAIT
被动端的状态：CLOSE-WAIT,LAST-ACK
一般来说服务器对FIN-WAIT-1，FIN-WAIT-2，TIME-WAIT这几个状态都要进行精密化控制,
Linux下FIN-WAIT-1，FIN-WAIT-2是1min,TIME-WAIT是2min,可配置.
对于被动端的CLOSE-WAIT这个时间可以非常长,因为TCP协议允许全双工进入半打开连接这样
的一个状态，只有一端可以发消息一端不可以发了,当然长时间使用这种状态的连接是很少的,
如果用netstat命令看到了CLOSE-WAIT状态的连接,一般来说就是程序出Bug了.
 
也许回答到这里就够了,如果你对Linux更了解的话可以做延展,每一个状态都有很多sysctrl的
参数可以去控制,比如说重试次数，超时时间等.

3.解决方法-操作系统设置重试次数&超时时间设置+代码中设置标志位(待验证)

3.1 操作系统内核参数设置

/proc/sys/fs/file-max 是整个系统可以打开的文件数的限制，由sysctl.conf控制

相关命令：
[muten@localhost ~]$ more /proc/sys/net/ipv4/tcp_keepalive_time 
300
[muten@localhost ~]$ more /proc/sys/net/ipv4/tcp_keepalive_probes
9
[muten@localhost ~]$ 
[muten@localhost ~]$ more /proc/sys/net/ipv4/tcp_keepalive_intvl 
75
[muten@localhost ~]$ 
[muten@localhost ~]$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 
CLOSE_WAIT 1
ESTABLISHED 1
SYN_SENT 1
[muten@localhost ~]$

3.2 代码里面要设置

setsockopt
SO_KEEPALIVE 保持连接 int
检测对方主机是否崩溃，避免（服务器）永远阻塞于TCP连接的输入。 
设置该选项后，如果2小时内在此套接口的任一方向都没有数据交换，TCP就自动给对方 发一个保持存活探测分节
(keepalive probe)。这是一个对方必须响应的TCP分节.它会导致以下三种情况： 对方接收一切正常：以期望的 
ACK响应。2小时后，TCP将发出另一个探测分节。 对方已崩溃且已重新启动：以RST响应。套接口的待处理错误被
置为ECONNRESET，套接 口本身则被关闭。 对方无任何响应：源自berkeley的TCP发送另外8个探测分节，相隔
75秒一个，试图得到 一个响应。在发出第一个探测分节11分钟15秒后若仍无响应就放弃。套接口的待处理错 误
被置为ETIMEOUT，套接口本身则被关闭。如ICMP错误是“host unreachable (主机不 可达)”，说明对方主机并
没有崩溃，但是不可达，这种情况下待处理错误被置为 EHOSTUNREACH。

4.问题-CLOSE_WAIT浪费的是什么资源？

是主动端的资源还是被动端的资源？具体是什么资源？

A机器是被动端，B机器是主动端，B主动关闭之后，A没有关闭，A机器上有大量的CLOSE_WAIT
状态的链接，这个会浪费A机器上的什么资源？这个会浪费B机器上的资源吗？

我觉得这个取决于B机器上的这个进程关闭套接字之后有没有就把自己给停了，如果自己没有
把自己给停了的话，那么这个进程在B机器上应该会有一些CLOSE_WAIT_2状态的链接的，是会
占据B机器上的资源的，如果进程停了挂了，那么应该是不会继续占用B机器的资源的。

待验证，仅仅是目前的观点。

0.引用阅读

1.TCP状态转移图及TCP四次挥手的图

1.1 TCP状态转移图-摘抄自《TCP/IP详解卷1》

1.2 TCP四次挥手

2.CLOSE_WAIT产生的原因

3.解决方法-操作系统设置重试次数&超时时间设置+代码中设置标志位(待验证)

3.1 操作系统内核参数设置

3.2 代码里面要设置

4.问题-CLOSE_WAIT浪费的是什么资源？

5.看看我们线上的一个应用程序的CLOSE_WAIT，吓死人啊

猜你喜欢