TCP连接生命周期的11种状态详解

 TCP 连接的生命周期

建立TCP连接
  与服务器建立TCP连接
  向服务器发送请求报文
  服务器返回应答报文
关闭TCP连接

 

TCP 生命周期中包含的所有状态

三次握手的过程中包含了其中四种状态变迁

LISTEN

服务端状态，应用程序打开监听端口，处理来自客户端TCP端口的连接
SYN_SENT

客户端状态，当客户端通过应用程序connect()连接时，客户端TCP发送SYN标记主动建立连接，此时状态为SYN_SENT
SYN_RECV

服务端状态，当收到客户端SYN封包后，服务端会发送一个SYN及ACK确认到客户端，再等待对方连接确认，这时状态为SYN_RECV，如果发现有很多SYN_RCVD状态，可能受到了SYN FLood的Dos攻击
ESTABLISHED

当客户端回复正确的ack值后，就建立一个打开的连接，客户端和服务端就都进入ESTABLISHED状态，此时便可以PSH数据
正常的四次握手包含6种tcp状态变迁 如主动发起关闭方为客户端 客户端发送FIN进入FIN_WAIT1 -> 服务端发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务端再发送FIN进入LAST_ACK状态 -> 客户端收到服务端的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务端收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务端的相关包，则进入CLOSED状态断开连接

FIN_WAIT1

客户端调用close()关闭连接后，TCP发出FIN标记主动关闭连接，然后进入FIN_WAIT1状态，等待远程TCP连接中断或者确认

CLOSE_WAIT

被动关闭状态，TCP接收到FIN后，就发送ack回应客户端的FIN标识封包，然后就进入了CLOSE_WAIT状态

FIN_WAIT2

半关闭状态，主动关闭端(也就是客户端调用close()后)接收到ack确认后，此时进入FIN_WAIT2状态，该状态下，客户端应用程序依然能接收数据

LAST_ACK

服务端发送确认中断后，也发送FIN关闭，然后进入LAST_ACK最后确认关闭状态

TIME_WAIT

在主动关闭端接收到FIN后，TCP就发送ACK，并进入TIME-WAIT状态，该状态持保持由内核参数默认等待2MSL，之后主动关闭方也进入CLOSED状态关闭连接

CLOSED

TCP连接关闭，被动关闭端在接收到ack包后，进入CLOSED状态关闭TCP连接

此外，还有CLOSING状态，不过比较少出现

CLOSING状态

CLOSING状态一般较少出现，这种是客户端和服务端同时发起了FIN主动关闭。如客户端发送FIN主动关闭，但是没有收到服务端发来的ACK确认，而是先收到了服务端发来的FIN关闭连接，所以必须是同时

在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态

TCP的 ESTABLISHED 和 TIME_WAIT 状态

TCP协议中有TIME_WAIT这个状态 主要有两个原因 1。防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失） 2。可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发 fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。 TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不 会被释放。 网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中，最值得 注意的状态有两个：CLOSE_WAIT和TIME_WAIT。

ESTABLISHED状态 ESTABLISHED的意思是建立连接。表示两台机器正在通信。