TCP连接的任意一端在任一时刻都处于某种状态,当前状态可以通过netstat命令查看。
TCP完整状态转移图
图中粗虚线表示典型的服务器端连接的状态转移,粗实线表示典型的客户端连接的状态转移。CLOSED是一个假想的起始点
,并不是一个实际的状态。
下面讨论典型的连接场景: 客户端主动连接服务器,客户端主动断开连接 的状态转移过程。
- 先讨论服务器端的连接状态
- 服务器通过listen系统调用进入
LISTEN
状态,被动等待客户端的连接,因此执行的是所谓的被动打开- 服务器一旦监听到某个连接请求(收到同步报文段),就将该连接放入内核等待队列中,并向客户端发送带SYN标志的确认报文段,此时连接处于
SYN_RECV
状态
-服务器成功接收到客户端发送回的确认报文段,则该连接转移到ESTABLISHED
状态,即双方可进行双向数据传输的状态- 当客户端主动关闭连接时(通过close或shutdown系统调用向服务器发送结束报文段),服务器通过返回确认报文段使连接进入
CLOSE_WAIT
状态。这个状态的含义很明确:等待服务器应用程序关闭连接。- 通常,服务器检测到客户端关闭连接后,也会立即给客户端发送一个结束报文段来关闭连接。这将使连接转移到
LAST_ACK
状态,以等待客户端对结束报文段的最后一次确认。- 一旦确认完成,连接就彻底关闭了
CLOSED
。
- 下面讨论客户端典型状态转移过程
- 客户端通过connect系统调用主动与服务器建立连接。connect系统调用首先给服务器发送一个同步报文段,使连接转移到
SYN_SENT
状态,此后,connect系统调用可能因为如下两个原因失败返回:- 如果connect连接的目标端口不存在(未被任何进程监听),或该端口仍被处于TIME_WAIT状态的连接所占用,则服务器将给客户端发送一个复位报文段,connect调用失败。
- 如果目标端口存在,但connect在超时时间内未收到服务器的确认报文段,则connect调用失败
- connect调用失败将使连接立即返回初始的
CLOSED
状态。如果客户端成功收到服务器的同步报文段和确认,则connect调用成功返回,连接转移到ESTABLISHED
状态。- 当客户端执行主动关闭时,它将向服务器发送一个结束报文段,同时连接进入
FIN_WAIT_1
状态。- 若此时客户端收到服务器专门用于确认目的的确认报文段,则连接转移到
FIN_WAIT_2
状态。- 当客户端处于FIN_WAIT_2状态时,服务器处于CLOSE_WAIT状态,此时如果服务器也关闭连接(发送结束报文段),则客户端将给予确认并进入
TIME_WAIT
状态。- 图中还给出了客户端从
FIN_WAIT_1 --> TIME_WAIT
的一条线路,前提是处于FIN_WAIT_1状态的连接直接收到带确认信息的结束报文段(而不是先收到确认报文段,再收到结束报文段)。这种情况对应四次挥手中省略确认报文段5的情况。
TIME_WAIT 状态
TIME_WAIT状态表示连接还需要等待2MSL(Maximum Seqment Life, 报文段最大生存时间)
的时间,才能完全关闭。MSL是TCP报文段在网络中的最大生存时间,标准RFC 1122的建议值是2min。
TIME_WAIT状态存在的原因有两点:
- 可靠的终止TCP连接。
- 保证让迟来的TCP报文段有足够的时间被识别并丢弃。
第一个原因很好理解,假设确认服务器结束报文段6的TCP报文段7丢失,那么服务器将重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段(即向服务器发送确认报文段)。否则客户端将以复位报文段来回应服务器,服务器则认为这是一个错误,因为它期望的是一个像TCP报文段7那样的确认报文段。
在Linux系统上,一个TCP端口不能被同时打开多次(两次及以上)。当一个TCP连接处于TIME_WAIT状态时,我们将无法立即使用该连接占用着的端口来建立一个新连接。反过来如果不存在TIME_WAIT状态,则应用程序能够立即建立一个和刚关闭的连接相似的连接(这里说的相似,是指它们具有相同的IP地址和端口号)。新的化身可能收到属于原来的连接的携带应用程序数据的TCP报文段(迟到的报文段),这显然是不应该发生的。这就是TIME_WAIT存在的第二个原因。
另外,因为TCP报文段的最大生存时间是MSL,所以坚持2MSL时间的TIME_WAIT状态能够确保网络上两个传输方向上尚未被接收到的,迟到的TCP报文段都已经消失(被中转路由器丢弃)。保证后续连接可以安全的建立。