1.TCP握手定理
2.TCP状态
l CLOSED：初始状态，表示TCP连接是“关闭着的”或“未打开的”。
l LISTEN ：表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接。
l SYN_RCVD ：表示服务器接收到了来自客户端请求连接的SYN报文。在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat很难看到这种状态，除非故意写一个监测程序，将三次TCP握手过程中最后一个ACK报文不予发送。当TCP连接处于此状态时，再收到客户端的ACK报文，它就会进入到ESTABLISHED 状态。
l SYN_SENT ：这个状态与SYN_RCVD 状态相呼应，当客户端SOCKET执行connect()进行连接时，它首先发送SYN报文，然后随即进入到SYN_SENT 状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT 状态表示客户端已发送SYN报文。
l ESTABLISHED ：表示TCP连接已经成功建立。
l FIN_WAIT_1 ：这个状态得好好解释一下，其实FIN_WAIT_1 和FIN_WAIT_2 两种状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET进入到FIN_WAIT_1 状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2 状态。当然在实际的正常情况下，无论对方处于任何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1 状态一般是比较难见到的，而FIN_WAIT_2 状态有时仍可以用netstat看到。
l FIN_WAIT_2 ：上面已经解释了这种状态的由来，实际上FIN_WAIT_2状态下的SOCKET表示半连接，即有一方调用close()主动要求关闭连接。注意：FIN_WAIT_2 是没有超时的（不像TIME_WAIT 状态），这种状态下如果对方不关闭（不配合完成4次挥手过程），那这个 FIN_WAIT_2 状态将一直保持到系统重启，越来越多的FIN_WAIT_2 状态会导致内核crash。
l TIME_WAIT ：表示收到了对方的FIN报文，并发送出了ACK报文。 TIME_WAIT状态下的TCP连接会等待2*MSL（Max Segment Lifetime，最大分段生存期，指一个TCP报文在Internet上的最长生存时间。每个具体的TCP协议实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟，但BSD传统实现采用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值），然后即可回到CLOSED 可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（这种情况应该就是四次挥手变成三次挥手的那种情况）
l CLOSING ：这种状态在实际情况中应该很少见，属于一种比较罕见的例外状态。正常情况下，当一方发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING 状态表示一方发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？那就是当双方几乎在同时close()一个SOCKET的话，就出现了双方同时发送FIN报文的情况，这是就会出现CLOSING 状态，表示双方都正在关闭SOCKET连接。
l CLOSE_WAIT ：表示正在等待关闭。怎么理解呢？当对方close()一个SOCKET后发送FIN报文给自己，你的系统毫无疑问地将会回应一个ACK报文给对方，此时TCP连接则进入到CLOSE_WAIT状态。接下来呢，你需要检查自己是否还有数据要发送给对方，如果没有的话，那你也就可以close()这个SOCKET并发送FIN报文给对方，即关闭自己到对方这个方向的连接。有数据的话则看程序的策略，继续发送或丢弃。简单地说，当你处于CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。
l LAST_ACK ：当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK 状态。当收到对方的ACK报文后，也就可以进入到CLOSED 可用状态了。
#######################################################################################################################################
LISTEN：等待从任何远端TCP 和端口的连接请求。 SYN_SENT：发送完一个连接请求后等待一个匹配的连接请求。 SYN_RECEIVED：发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。 ESTABLISHED：表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。 FIN_WAIT_1：等待远端TCP 的连接终止请求，或者等待之前发送的连接终止请求的确认。 FIN_WAIT_2：等待远端TCP 的连接终止请求。 CLOSE_WAIT：等待本地用户的连接终止请求。 CLOSING：等待远端TCP 的连接终止请求确认。 LAST_ACK：等待先前发送给远端TCP 的连接终止请求的确认（包括它字节的连接终止请求的确认） TIME_WAIT：等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。 TIME_WAIT 两个存在的理由： 1.可靠的实现tcp全双工连接的终止； 2.允许老的重复分节在网络中消逝。 CLOSED：不在连接状态（这是为方便描述假想的状态，实际不存在）
######################################################################################################################################
3.服务器大量TIME_WAIT和CLOSE_WAIT分析
#查看TCP状态：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1
常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭，Listen表示正在监听可以接受客户端连接。
#常见问题分析
1.服务器保持了大量TIME_WAIT状态
2.服务器保持了大量CLOSE_WAIT状态
因为linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的请求就无法被处理了，接着就是大量Too Many Open Files异常，tomcat崩溃。
#############################################################################
tomcat环境下服务器文件句柄耗尽（Too Many Open Files）的问题排查
为什么会出现文件句柄耗尽的情况？
主要是因为linux在文件句柄的数目上有两个级别的限制。一个是系统级别的总数限制，一个是针对用户的限制。默认情况下每个用户所能使用的句柄数是1024。一般情况下1024也够用了，但是在大容量的系统上，特别是会频繁使用网络通信和文件IO的系统上，1024很快就被耗光了。所以首先我们要调整这个值。修改方法如下：
1. ulimit -a 查看当前用户的文件句柄限制
2. 用户级别的句柄数限制修改
修改 /etc/security/limits.conf 增加下面的代码：
用户名(或者用*表示所有用户) soft nofile 65535
用户名 hard nofile 65535
有两种限制，一种是soft软限制，在数目超过软限制的时候系统会给出warning警告，但是达到hard硬限制的时候系统将拒绝或者异常了。
修改之后可能需要重启shell生效。
3. 系统级别的句柄数限制修改
sysctl -w fs.file-max 65536
或者 echo "65536" > /proc/sys/fs/file-max
两者作用是相同的，前者改内核参数，后者直接作用于内核参数在虚拟文件系统（procfs, psuedo file system）上对应的文件而已。
可以用下面的命令查看新的限制
sysctl -a | grep fs.file-max
或者 cat /proc/sys/fs/file-max
4.修改内核参数
/etc/sysctl.conf
echo "fs.file-max=65536" >> /etc/sysctl.conf
sysctl -p
查看系统总限制 命令：cat /proc/sys/fs/file-max
查看整个系统目前使用的文件句柄数量命令：cat /proc/sys/fs/file-nr
查看某个进程开了哪些句柄 ：lsof -p pid
某个进程开了几个句柄 ：lsof -p pid |wc -l
也可以看到某个目录 /文件被什么进程占用了,显示已打开该目录或文件的所有进程信息 ：lsof path/filename
具体这个值应该设置成多少？
优先级（Open File Descriptors）：
soft limit < hard limit < kernel < 实现最大file descriptor数采用的数据结构所导致的限制
其实这个值倒是没有具体限制，但是分配的值如果太大反而会影响系统性能，所以要根据具体应用调配权衡。
问题的解决方案：
首先当然是修改linux句柄数限制到一个合适的值。
然后就是应用本身的一个调整。有这么几种情况：
1.数据库连接池的优化。必须要使用连接池，否则句柄没耗光数据库就崩了。。。
2.抓取资源的时候有可能会用到HttpClient，尽量也应该使用连接池来控制连接数。
3.连接池设置的把握，建立连接超时时间，读取超时时间，连接数目，等待时间，等都需要配置到一个合适的值，否则发挥不出连接池的性能。
###########################################################################################################
解决思路很简单，就是让服务器能够快速回收和重用那些TIME_WAIT的资源。
对/etc/sysctl.conf文件的修改：
#对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255，默认值是5，对应于180秒左右时间
net.ipv4.tcp_syn_retries=2
#net.ipv4.tcp_synack_retries=2
#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒
net.ipv4.tcp_keepalive_time=1200
net.ipv4.tcp_orphan_retries=3
#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间
net.ipv4.tcp_fin_timeout=30
#表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_syn_backlog = 4096
#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭
net.ipv4.tcp_syncookies = 1
#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭
net.ipv4.tcp_tw_reuse = 1
#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭
net.ipv4.tcp_tw_recycle = 1
##减少超时前的探测次数
net.ipv4.tcp_keepalive_probes=5
##优化网络设备接收队列
net.core.netdev_max_backlog=3000
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*
如果将大量CLOSE_WAIT的解决办法总结为一句话那就是：查代码。因为问题出在服务器程序里头啊。
