一  CLOSE_WAIT探究

CLOSE_WAIT 状态出现在被动关闭方,当收到对端'FIN'以后回复'ACK',但是自身'没有'发送FIN包之前

①   服务器出现大量 CLOSE_WAIT 状态的原因有哪些?

1、通常来讲,CLOSE_WAIT状态的'持续'时间应该很'短',正如SYN_RCVD状态2、但是在一些'特殊'情况下,就会出现大量'连接长时间'处于CLOSE_WAIT状态的情况3、观察TCP连接状态,包括'CLOSE_WAIT'netstat -nat | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

说明：'分析'一个'普通'的 TCP 服务端的'流程' 备注： 注意每'一'步

分析： 导致服务端'没有'调用 close 函数的'原因'主要分析的'方向'就是服务端'为什么没有'调用 close --> 没有发送'FIN'包

线上大量CLOSE_WAIT的原因深入分析

一次 Netty 代码不健壮导致的大量 CLOSE_WAIT 连接原因分析

二  如果已经建立了连接,但是客户端突然出现故障了怎么办?

TCP 连接,一端断电和进程崩溃有什么区别?

①  TCP保活机制

sysctl -a|grep tcp_keepalive  --> '查看'/proc/sys/net/ipv4/tcp_keepalive_intvl  /proc/sys/net/ipv4/tcp_keepalive_probes  /proc/sys/net/ipv4/tcp_keepalive_timeSO_KEEPALIVE 选项  --> '保活' 机制

②  操作系统默认值TCP保活计算方式

③  nginx listen 指令的tcp选项参数

Linux下 nginx so_keepalive 参数详解

http的keepalive及在nginx的配置使用

nginx的so_keepalive和timeout相关小计 

④  开启TCP保活连接考虑场景

⑤  应用层实现心跳机制

三  如果已经建立了连接,但是服务端的进程崩溃会发生什么?

四   发送RST包的场景