`
v7sky
  • 浏览: 75275 次
文章分类
社区版块
存档分类
最新评论

TCP连接中的TIME_WAIT

阅读更多



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



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抓发,结果如下





结论:主动发起关闭连接的一方,进入time_wait状态,此时进程所占用的端口号不能被释放,但是断开连接后再次连接时,SOCKET将使用了不同的端口,等几分钟后,原有的端口就会自动关闭了
  • 大小: 234.5 KB
  • 大小: 43.3 KB
  • 大小: 177.9 KB
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics