TCP 状态转移

在《Linux 高性能服务器编程》中,有下面这样的状态转移图。

TCP 的各个状态

客户端

建立连接(三次握手)
  • SYN_SENT 在客户端发送第一个同步报文段(第一次握手)之后,就会进入这个状态。

  • ESTABLISHED 在收到服务端发送的确认和同步报文段(第二次握手)后,客户端只需要发送出一个确认报文段(第三次握手),就算完成了三次握手了,即客户端认为连接已经建立。

断开连接(四次挥手)
  • FIN_WAIT_1 TCP 断开连接时,需要进行四次挥手。当客户端主动关闭连接,发出第一个 FIN 报文段(第一次挥手)后,即进入此状态。

  • FIN_WAIT_2 服务端在收到第一个 FIN 报文段后,回复给客户端确认报文段(第二次挥手)后的状态。其实 FINE_WAIT 的含义,就是等待服务端发来的 FIN 报文段。

  • TIME_WAIT 在客户端收到服务端的 FIN 报文(第三次挥手)后,返回给服务端确认报文段(第四次挥手)后的状态。

服务端

建立连接(三次握手)
  • CLOSED 一个假想的起点和终点,不是一个实际的状态。

  • LISTEN 在程序启动后,等待客户端连接的状态。

  • SYN_RCVD 在每一个 TCP 连接建立时,都要进行三次握手,这个状态表示服务端接收到客户端发来的同步报文段(第一次握手),并且向客户端发送了确认同步报文段(第二次握手)之后的状态,在这个状态时,其实连接已经经历了两次握手。

  • ESTABLISHED 收到客户端发来的确认报文段(第三次握手),即三次握手成功后,双方正式建立连接的状态。

断开连接(四次挥手)
  • CLOSE_WAIT 在收到客户端主动断开连接的 FIN 报文段(第一次挥手)后,返回给客户端确认报文段(第二次挥手)后的状态。

  • LAST_ACK 服务端发送 FIN 报文段(第三次挥手)后的状态。在该状态之后,收到确认报文段(第四次握手),连接就关闭了。

时序图

对于书中的状态转移图,有一些复杂和抽象。我根据自己的分析,画出了一份时序图。

建立连接(三次握手)

断开连接(四次挥手)

TIME_WAIT 状态

第一次看这个转移图的时候,我很疑惑,为什么要有一个 TIME_WAIT 状态?为什么不能直接到达 CLOSED 状态?相信很多人看到这个状态转移图,也会有这样的疑惑。其实,原因大致有下面两点。

可靠地终止连接

假设没有 TIME_WAIT 这种状态。现实中,网络环境不是理想的。在数据包传输的过程中,难免会有一些延时、丢包的情况发生。如果,在客户端最后一个确认报文段发出去之后,由于某种原因,没有到达服务端,这样,服务端在超时后,就会向客户端重新发一个 FIN 报文段,请求重传。由于在客户端,连接实际上已经断开,端口已经关闭。那么在客户端收到这个报文段后,会向服务端发送一个 RST 报文段。而服务器收到该报文段后,会认为是错误的,它所期望收到的是确认报文段。

保证让迟来的报文段有足够的时间被处理

同样在不理想的网络环境中,有些包会在网络中有所延迟。假如没有 TIME_WAIT 这种状态,在关闭连接后并且建立新的连接后,可能会收到该数据包。由于序号不同,客户端会要求服务端重传数据包,这样,连接就会混乱出错。而 TIME_WAIT 状态的时间,一般是 2MAL 时间,并且端口没有释放。这样,前一个连接的报文段有足够的时间被识别或者丢弃,也就不会出现这个问题。

欢迎评论。
lingkb » TCP 状态转移

发表评论