Linux内核协议栈为一个tcp连接管理使用两个队列，一个是半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求），一个是accpetd队列（用来保存处于established状态，但是应用层没有调用accept取走的请求）。
第一个队列的长度是/proc/sys/net/ipv4/tcp_max_syn_backlog，默认是1024。如果开启了syncookies，那么基本上没有限制。
第二个队列的长度是/proc/sys/net/core/somaxconn，默认是128，表示最多有129个established链接等待accept。
windows :
TCPView
https://technet.microsoft.com/en-us/sysinternals/bb897437.aspx
Linux 各状态查看命令：
netstat -ant|fgrep ":"|cut -b 77-90|sort |uniq -c
状态转换图中状态的描述:
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉
TCP/IP状态转换图的分析
其中，EATABLISHED是数据的传送状态。我们主要分析主动关闭这个框内的转换状态。
当客户端应用程序主动请求关闭时，调用close或shutdown关闭连接，这时应用程序发送FIN，然后进入FIN_WAIT_1状态，等待服务器端发送确认包ACK，接受到服务器端的ACK以后，然后客户端进入FIN_WAIT_2状态，等待服务器端调用close，并发送FIN，当客户端接受到FIN后，发送ACK，进入最终的TIME_WAIT状态，这结合着TCP关闭连接时的分组交换连接图可以更加的明白。需要注意的是，执行主动关闭的那一端进入TIME_WAIT状态。留在TIME_WAIT的持续的时间是MSL（最长分节生命周期 maximum segment lifttime）时间的两倍，也就是2MSL. MSL一般情况下是30秒到2分种，所以TIME_WAIT的时间一般为1-4分种。
下面是（《Unix 网络编程第一卷》关于TIME_WAIT状态存在的理由）
存在TIME_WAIT状态有两个理由：
1. 实现终止TCP全双工连接的可靠性
假设最终的ACK丢失，服务器将重发最终的FIN,因此客户必须维护状态信息以允许它重发最终的ACK，如果不维护状态信息，它将响应以RST，而服务器则把该分节解释成一个错误，如果TCP打算执行所有必要的工作以彻底终止某个连接上两个方向的数据流，那么它必须，能够处理连接终止序列四个分节中任何一个分节的丢失的情况，主动关闭的那一端必须进入TIME_WAIT状态，因为它可能不得不重发最终的ACK。
2. 允许老的重复分节的网络中消失。
我们假设206.62.226.33端口1500和198.162.10.2端口21之间有一个TCP连接，我们关闭这个连接后，在以后某个时候又重新建立起相同的IP地址和端口之间的TCP连接。后一个连接称为前一个连接的化身，因为它们的IP地坛和端口号是相同的，TCP必须防止来自某个连接的老重复分组在连接终止后再现，从而被误解成属于同一个连接的化身。要实现这种功能TCP不能给处于TIME_WAIT状态的启动新的化身，既然TIME_WAIT状态的待续时间是2MLS,这就足够让某个方向上的分组最多存活MSL秒即被丢弃，另一个方向上的应答最多存活MSL秒也被丢弃，通过实施这个规则，我们就能保证当成功建立一个TCP连接时，来自该连接先前的化身的老重复分组都已在网络中消逝了
参考图2：
参考：http://www.cnxct.com/coping-with-the-tcp-time_wait-state-on-busy-linux-servers-in-chinese-and-dont-enable-tcp_tw_recycle/
其它TCP状态转换图一：
