TCP连接中的TIME_WAIT

[img]http://dl2.iteye.com/upload/attachment/0118/1788/00675594-fe4a-3708-8196-4a91d5ba084a.jpg[/img]

这张图较为直观，对照看下图

[img]http://dl2.iteye.com/upload/attachment/0118/1790/d545f176-2ec9-3e76-9d67-a2ff526eae78.jpg[/img]

TIME_WAIT
一般来说，tcp正常关闭需要四个包。比如a和b关闭连接，a先给b发一个fin，b会进行确认ack，然后b也会发出fin，当a接受到这个fin，并发出最后一个ack后，就会处于time_wait状态，通常是所估计的最大分段使用期的2倍（称为2MSL，通常为2分钟）

虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文，并保证于此。

那么问题来了：
我写一个测试程序，循环调用某http接口，并没有启用keep-alive, 如果有time_wait状态存在的话，理论上两次请求中间，至少要等待2MSL时间？不是这样呢？

使用org.apache.httpcomponents:httpclient，写一个简单测程序，循环发起http调用，使用wiresharp抓发，结果如下


[img]http://dl2.iteye.com/upload/attachment/0118/1809/aa6dea28-c00b-3102-9b89-dba0f5cf17dd.png[/img]


结论：主动发起关闭连接的一方，进入time_wait状态，此时进程所占用的端口号不能被释放，但是断开连接后再次连接时，SOCKET将使用了不同的端口，等几分钟后，原有的端口就会自动关闭了