关闭时状态转变:
client: Fin_wait_1 -> Fin_wait_2 -> Time_wait -> closed
server: Close_wait -> Last_ack -> closed
Fin_wait_1 发生在client 发出Fin包后, 并等待server 回 ack 时.
Fin_wait_2 发生在client收到ack包后, 并等待server发出Fin包时.
Time_wait 发生在client收到Fin包并发出ack包后, 在等待2msl的时间时.
Close_wait 发生在server收到client的fin包并且发出ack包后以及自己主动关闭发出fin包前.
Last_ack发生在server发出fin包后, 并等待client回ack时.
经常出现的状态组合:
- client: fin_wait_2; server: close_wait
原因: 当client close了,但是server忘记close的时候, 即server在收到client的fin后并没有发送fin包给client, 导致自己处于close_wait状态, 而client在等待server的fin包,处于fin_wait_2状态.
- client:time_wait; server: closed
原因: 当client, server都close了, client必须处于time_wait状态等待2msl时间. 于是如果server是处于高并发短连接的状态, 就会有大量的time_wait的连接霸占着. 使得其他的连接连接不了.
解决方法: 用linger强制关闭可以解决此问题(用rst代替fin),但是linger会导致数据丢失,linger值为0时是强制关闭,无论并发多少多能正常连接上,如果非0会发生部分连接不上的情况!(可调用setsockopt设置套接字的linger延时标志,同时将延时时间设置为0。)
TCP/IP的RFC文档。TIME_WAIT是TCP连接断开时必定会出现的状态。
是无法避免掉的,这是TCP协议实现的一部分。
在WINDOWS下,可以修改注册表让这个时间变短一些
time_wait的时间为2msl,默认为4min.
你可以通过改变这个变量:
TcpTimedWaitDelay
把它缩短到30s
PS: Linux 查看 tcp 状态的命令 netstat -an | grep portnumber
Linux close()和shutdown()的区别.
Linux的版本是kernel-2.6.21:
1,只要TCP栈的读缓冲里更有未读取(read)数据,则调用close时会直接向对端发送RST。
2,shutdown和socket描述符没有关系,即使调用shutdown(fd, SHUT_RDWR)也不会关闭fd,最终还需close(fd)。
3,能认为shutdown(fd, SHUT_RD)是空操作,因为shutdown后还能继续从该socket读取数据,这点也许还需要进一步证实。
4,在已发送FIN包后write该socket描述符会引发EPIPE/SIGPIPE。
5,当有多个socket描述符指向同一socket对象时,调用close时首先会递减该对象的引用计数,计数为0时才会发送FIN包结束TCP连接。shutdown不同,只要以SHUT_WR/SHUT_RDWR方式调用即发送FIN包。
6,SO_LINGER和close,当SO_LINGER选项开启但超时值为0时,调用close直接发送RST(这样能避免进入TIME_WAIT状态,但破坏了TCP协议的正常工作方式),SO_LINGER对shutdown无影响。
7,TCP连接上出现RST和随后可能的TIME_WAIT状态没有直接关系,主动发FIN包方必然会进入TIME_WAIT状态,除非不发送FIN而直接以发送RST结束连接。