TIME_WAIT状态
TCP要保证在所有可能的情况下使得所有的数据都能够正确被投递。
当关闭一个 socket 连接时，主动关闭一端的 socket 将进入TIME_WAIT状态，而被动关闭一方则转入CLOSED状态。
见图解。
当一个socket关闭的时候，是通过两端互发信息的四次握手过程完成的，当一端调用close()时，就说明本端没有数据再要发送了。这好似看来在握手完成以后，socket就都应该处于关闭CLOSED状态了。但这有两个问题，
假设最后一个ACK丢失了，服务器会重发它发送的最后一个FIN，所以客户端必须维持一个状态信息，以便能够重发ACK；如果不维持这种状态，客户端在接收到FIN后将会响应一个RST，服务器端接收到RST后会认为这是一个错误。如果TCP协议能够正常完成必要的操作而终止双方的数据流传输，就必须完全正确的传输四次握手的四个节，不能有任何的丢失。这就是为什么socket在关闭后，仍然处于 TIME_WAIT状态，因为他要等待以便重发ACK。
如果目前连接的通信双方都已经调用了close()，假定双方都到达CLOSED状态，而没有TIME_WAIT状态时，就会出现如下的情况。现在有一个新的连接被建立起来，使用的IP地址与端口与先前的完全相同，后建立的连接又称作是原先连接的一个化身。还假定原先的连接中有数据报残存于网络之中，这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这一点，TCP不允许从处于 TIME_WAIT状态的socket建立一个连接。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后（之所以是两倍的MSL，是由于MSL是一个数据报在网络中单向发出到认定丢失的时间，一个数据报有可能在发送图中或是其响应过程中成为残余数据报，确认一个数据报及其响应的丢弃的需要两倍的MSL），将会转变为CLOSED状态。这就意味着，一个成功建立的连接，必然使得先前网络中残余的数据报都丢失了。
由于TIME_WAIT状态所带来的相关问题，我们可以通过设置SO_LINGER标志来避免socket进入TIME_WAIT状态，这可以通过发送RST而取代正常的TCP四次握手的终止方式。但这并不是一个很好的主意，TIME_WAIT对于我们来说往往是有利的。
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
Q: 编写 TCP/SOCK_STREAM 服务程序时，SO_REUSEADDR到底什么意思？
A: 这个套接字选项通知内核，如果端口忙，但TCP状态位于 TIME_WAIT ，可以重用
端口。如果端口忙，而TCP状态位于其他状态，重用端口时依旧得到一个错误信息，
指明"地址已经使用中"。如果你的服务程序停止后想立即重启，而新套接字依旧
使用同一端口，此时 SO_REUSEADDR 选项非常有用。必须意识到，此时任何非期
望数据到达，都可能导致服务程序反应混乱，不过这只是一种可能，事实上很不
可能。
一个套接字由相关五元组构成，协议、本地地址、本地端口、远程地址、远程端
口。SO_REUSEADDR 仅仅表示可以重用本地本地地址、本地端口，整个相关五元组
还是唯一确定的。所以，重启后的服务程序有可能收到非期望数据。必须慎重使
用 SO_REUSEADDR 选项。
Q: 在客户机/服务器编程中(TCP/SOCK_STREAM)，如何理解TCP自动机 TIME_WAIT 状
态？
A: W. Richard Stevens <1999年逝世，享年49岁>
下面我来解释一下 TIME_WAIT 状态，这些在<>
中2.6节解释很清楚了。
MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间，每个具体的TCP实现
都必须选择一个确定的MSL值。RFC 1122建议是2分钟，但BSD传统实现采用了30秒。
TIME_WAIT 状态最大保持时间是2 * MSL，也就是1-4分钟。
IP头部有一个TTL，最大值255。尽管TTL的单位不是秒(根本和时间无关)，我们仍需
假设，TTL为255的TCP报文在Internet上生存时间不能超过MSL。
TCP报文在传送过程中可能因为路由故障被迫缓冲延迟、选择非最优路径等等，结果
发送方TCP机制开始超时重传。前一个TCP报文可以称为"漫游TCP重复报文"，后一个
TCP报文可以称为"超时重传TCP重复报文"，作为面向连接的可靠协议，TCP实现必须
正确处理这种重复报文，因为二者可能最终都到达。
一个通常的TCP连接终止可以用图描述如下：
client
close（主动关闭） -----------------> (被动关闭)
<---------------------------------
<------------------------------- CLOSED
ACK N+1
------------------------------->
TIME_WAIT
为什么需要 TIME_WAIT 状态？
假设最终的ACK丢失，server将重发FIN，client必须维护TCP状态信息以便可以重发
最终的ACK，否则会发送RST，结果server认为发生错误。TCP实现必须可靠地终止连
接的两个方向(全双工关闭)，client必须进入 TIME_WAIT 状态，因为client可能面
临重发最终ACK的情形。
此外，考虑一种情况，TCP实现可能面临先后两个同样的相关五元组。如果前一个连
接处在 TIME_WAIT 状态，而允许另一个拥有相同相关五元组的连接出现，可能处理
TCP报文时，两个连接互相干扰。使用 SO_REUSEADDR 选项就需要考虑这种情况。
为什么 TIME_WAIT 状态需要保持 2MSL 这么长的时间？
如果 TIME_WAIT 状态保持时间不足够长(比如小于2MSL)，第一个连接就正常终止了。
第二个拥有相同相关五元组的连接出现，而第一个连接的重复报文到达，干扰了第二
个连接。TCP实现必须防止某个连接的重复报文在连接终止后出现，所以让TIME_WAIT
状态保持时间足够长(2MSL)，连接相应方向上的TCP报文要么完全响应完毕，要么被
丢弃。建立第二个连接的时候，不会混淆。
A: 小四
在Solaris 7下有内核参数对应 TIME_WAIT 状态保持时间
# ndd -get /dev/tcp tcp_time_wait_interval
240000
# ndd -set /dev/tcp tcp_time_wait_interval 1000
缺省设置是240000ms，也就是4分钟。如果用ndd修改这个值，最小只能设置到1000ms，
也就是1秒。显然内核做了限制，需要Kernel Hacking。
# echo "tcp_param_arr/W 0t0" | adb -kw /dev/ksyms /dev/mem
physmem 3b72
tcp_param_arr: 0x3e8 = 0x0
# ndd -set /dev/tcp tcp_time_wait_interval 0
我不知道这样做有什么灾难性后果，参看<>的声明。
Q: TIME_WAIT 状态保持时间为0会有什么灾难性后果？在普遍的现实应用中，好象也
就是服务器不稳定点，不见得有什么灾难性后果吧？
Linux 内核源码 /usr/src/linux/include/net/tcp.h 中
#define TCP_TIMEWAIT_LEN (60*HZ)
最好不要改为0，改成1。端口分配是从上一次分配的端口号+1开始分配的，所以一般
不会有什么问题。端口分配算法在tcp_ipv4.c中tcp_v4_get_port中。
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
TIME_WAIT状态对HTTP影响
根据TCP协议，主动发起关闭的一方，会进入TIME_WAIT状态，持续2*MSL(Max Segment Lifetime)，缺省为240秒，在这个post中简洁的介绍了为什么需要这个状态。
值得一说的是，对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，可想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态，假如server一秒钟接收1000个请求，那么就会积压240*1000=240，000个 TIME_WAIT的记录，维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT，所以对于新的 TCP连接请求，判断是否hit中一个TIME_WAIT不会太费时间，但是有这么多状态要维护总是不好。
HTTP协议1.1版规定default行为是Keep-Alive，也就是会重用TCP连接传输多个request/response，一个主要原因就是发现了这个问题。还有一个方法减缓TIME_WAIT压力就是把系统的2*MSL时间减少，因为240秒的时间实在是忒长了点，对于 Windows，修改注册表，在HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters上添加一个DWORD类型的值TcpTimedWaitDelay，一般认为不要少于60，不然可能会有麻烦。
对于大型的服务，一台server搞不定，需要一个LB(Load Balancer)把流量分配到若干后端服务器上，如果这个LB是以NAT方式工作的话，可能会带来问题。假如所有从LB到后端Server的IP包的 source address都是一样的(LB的对内地址），那么LB到后端Server的TCP连接会受限制，因为频繁的TCP连接建立和关闭，会在server上留下TIME_WAIT状态，而且这些状态对应的remote address都是LB的，LB的source port撑死也就60000多个(2^16=65536,1~1023是保留端口，还有一些其他端口缺省也不会用），每个LB上的端口一旦进入 Server的TIME_WAIT黑名单，就有240秒不能再用来建立和Server的连接，这样LB和Server最多也就能支持300个左右的连接。如果没有LB，不会有这个问题，因为这样server看到的remote address是internet上广阔无垠的集合，对每个address，60000多个port实在是够用了。
一开始我觉得用上LB会很大程度上限制TCP的连接数，但是实验表明没这回事，LB后面的一台Windows Server 2003每秒处理请求数照样达到了600个，难道TIME_WAIT状态没起作用？用Net Monitor和netstat观察后发现，Server和LB的XXXX端口之间的连接进入TIME_WAIT状态后，再来一个LB的XXXX端口的 SYN包，Server照样接收处理了，而是想像的那样被drop掉了。翻书，从书堆里面找出覆满尘土的大学时代买的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》，中间提到一句，对于BSD-derived实现，只要SYN的sequence number比上一次关闭时的最大sequence number还要大，那么TIME_WAIT状态一样接受这个SYN，难不成Windows也算BSD-derived?有了这点线索和关键字 (BSD)，找到这个post，在NT4.0的时候，还是和BSD-derived不一样的，不过Windows Server 2003已经是NT5.2了，也许有点差别了。
做个试验，用Socket API编一个Client端，每次都Bind到本地一个端口比如2345，重复的建立TCP连接往一个Server发送Keep-Alive=false 的HTTP请求，Windows的实现让sequence number不断的增长，所以虽然Server对于Client的2345端口连接保持TIME_WAIT状态，但是总是能够接受新的请求，不会拒绝。那如果SYN的Sequence Number变小会怎么样呢？同样用Socket API，不过这次用Raw IP，发送一个小sequence number的SYN包过去，Net Monitor里面看到，这个SYN被Server接收后如泥牛如海，一点反应没有，被drop掉了。
按照书上的说法，BSD-derived和Windows Server 2003的做法有安全隐患，不过至少这样至少不会出现TIME_WAIT阻止TCP请求的问题，当然，客户端要配合，保证不同TCP连接的sequence number要上涨不要下降。
文章链接：
socket中的TIME_WAIT状态
TCP TIME_WAIT状态QA
TIME_WAIT状态对HTTP影响
============================================
写过TCP服务器的人都知道，要解决主动关闭后的TIME_WAIT状态是件很麻烦的事情，如果服务器设置Linger生效且延迟为0秒，则服务器发送给Client的最后一个数据包极可能丢失。Server端TIME_WAIT过多会导致服务器效率急剧下降，Client端TIME_WAIT过多会导致connect to server失败(报WSAEADDRINUSE错误，休息一段时间让部分处于TIME_WAIT状态的句柄超时后又能connect成功到服务器)。
几乎翻遍互联网也没找到比较好的解决方案，其中有老外提出修改TCP/IP协议栈的方案（前几天我也在考虑这个方案的可行性）。
下面给出我的关于解决TIME_WAIT的方案。
只有两种方式：
我们知道主动关闭至少会经过TIME_WAIT_1--->TIME_WAIT(2MSL timeout)--->CLOSED
而被动关闭会经过CLOSE_WAIT--->LAST_ACK--->CLOSED
Step 1:
Step 3:
Step 4:
Step 5:
----------------------------------------------------------------------------------------------------
Step 6:
CLIENT new socket handle，设置Linger生效，且延迟为0秒XSetSocketLinger(),设置为非阻塞模式XSetSocketBlockingMode(),便于快速connect到SERVER ,异步检测是否连接成功。
Step 7:
Step 8:
Step 9:
效果：
D:\vcoutput\Release>SimuCGIClient.exe 172.30.14.13 25000 1000000
usage:SimuCGIClient.exe CacheServerHost Port LoopTimes
total ssuccess query:1000012 in 703 seconds.
1422.49 querys/second.
在windows下向SERVER请求100万个连接，在703seconds内完成响应，平均每秒约能完成1422个TCP并发请求。SERVER,CLIENT均为单线程程序。
在这100万个节点查询过程中，查看服务器和client的协议栈句柄消耗情况：
----------------------------------------------------------------------------------------------------
Active Connections
----------------------------------------------------------------------------------------------------
方案关键点：
请问我如何
检查
自己的socket连接当前处于什么TCP状态呢？
系统
，可以参考一下这个，
void
===================================================
一般来说，tcp正常关闭需要四个包。比如a和b关闭连接，a先给b发一个fin，b会进行确认ack，然后b也会发出fin，当a接受到这个fin，并发出最后一个ack后，就会处于time_wait状态。这个时间长短跟操作系统有关，一般会在1-4分钟，也就是两倍的数据包(2msl)最大生存时间。TCP主动关闭方采用TIME_WAIT主要是为了实现终止 TCP全双工连接的可靠性及允许老的重复分节在网络中消逝，等过了2msl(大约1~4分钟)后TIME_WAIT就会消失。
TIME_WAIT状态的目的是为了防止最后a发出的ack丢失，让b处于LAST_ACK超时重发FIN
关闭BITCOMET后系统出现的几个TCP状态
1420
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
