TCP状态转换图、TCP连接3次握手4次挥手

  

一 预备知识-两将军问题

    两将军问题：红蓝两军作战，蓝军战斗力强大，红1军或红2军与其单独作战都打不过蓝军，所以需要红一军与红二军联合对蓝军发起进攻，红军1首先通知红军2明早10点发起总攻，如图1-1，红军2接到消息需要回复“好的红军1，我已经收到你得消息，确认明早10点发动总攻”。因为消息传递路线必须经过蓝军营地，所以双方传递消息的信使很有可能被蓝军俘获。为了确保消息的可靠性，红1、红2双方在发出一个消息之后都想得到对方的消息回执。但是这会导致消息无线循环下去，如图1-2。那么如何解决这个可靠性的问题呢，其实没有办法解决，只要保证双方各自都有一次成功的发送、回执就可以了。

 

 

图1-1 红军发送消息

 

图1-2 无限回执

 

二 TCP连接的三次握手

     两将军问题也存在网络世界里，客户端、服务器建立连接不可能无限的确认下去，只要保证客户端和服务器分别对自己的收、发能力做一次确认即可，如下图。 客户端和服务器分别对自己的收、发能力做一次确认至少需要3次握手。

 

图2-1 TCP连接

 

 

    3次握手的具体过程、状态如下：

1. 首先客户端和服务器都处于CLOSED状态。
2. 服务器处于LISTEN状态，具体为服务器调用Socket、bind、listen函数，进入阻塞状态。
3. 客户端发送SYN（同步序列编号），发送完毕客户端进入SYN_SENT状态。
4. 服务端收到SYN，发送SYN+ASK，发送完毕进入SYN_RCVD状态。
5. 客户端收到服务端发来的SYN+ASK，发送服务端等待的ASK，发送完毕客户端进入ESTABLISHED状态，准备数据传输,到此客户端已经满足了对自己收发能力的一次验证。
6. 服务端收到客户端发来的ASK，与客户端一样，到此服务端也已经满足了对自己收发能力的一次验证，所以也进入ESTABLISHED状态，准备数据传输。
7. 准备开始传输数据

 

三 TCP断开四次挥手

 

 

 

 

图3-1 TCP断开

 

  TCP断开连接有两种情况或者说是场景，1 客户端先断开连接，当然也可能是服务器先断开连接，总之是一前一后。 2 双方同时发起断开连接操作。下面分别介绍两种场景：

  场景一

1. 客户端先发起断开连接操作，客户端向服务端发送FIN，发送完毕客户端进入FIN_WAIT_1状态。
2. 服务端收到客户端发来的FIN，服务端发送ACK，发送完毕进入CLOSED_WAIT状态。
3. 客户端收到服务端的ACK回复，客户端进入FIN_WAIT_2状态，如果后面服务端没有回应客户端，在TCP协议层面来讲，客户端将永远停留在这个状态了，不过还好，操作系统着这块做了处理，有一个超时时间。
4. 此时TCP连接进入半关闭状态，即客户端主，服务端从的这条线路已经关闭，不过服务端主，客户端从的这条线路还处于打开状态。
5. 服务端向客户端发送FIN，发送完毕，服务端进入LAST_ASK状态。
6. 客户端收到服务端的FIN后回复服务端ACK，回复完毕进入TIME_WAIT状态，为什么要进入这个状态？因为第6步是客户端的最后一条回复，服务端很有可能收不到，收不到服务端就会重发，所以客户端还要等待一会。
7. 服务端收到客户端的ACK回复之后，不再做响应，回到初始的CLOSED状态，在连接池中等待下一次的复用。
8. 客户端保持TIME_WAIT状态，超时之后同样进入CLOSED状态。

  场景二

1. 客户端、服务器双方同时发送FIN，双方同时进入FIN_WAIT_1状态
2. 双方都接到了对方的ACK，此时双方都会进入CLOSING状态。
3. 双方同时进入TIME_WAIT状态，为什么要进入这个状态而不是直接进入CLOSED状态呢？假设客户端和服务端本次是第X次建立连接、关闭连接。如果立即关闭，随后建立第X+1次连接，建立连接成功之后，第X次的丢包的数据有可能绕了一大圈又回来了，那就会出现数据错误，为了避免这种情况所以要进入TIME_WAIT状态，以保证旧连接的数据不会再回来。
4. TIME_WAIT超时之后，双双进入CLOSED状态。

 

四 TCP状态图

 

 

 

                                图4-1 TCP状态图

 

    有了上面对TCP连接3次握手4次挥手的介绍，再来理解TCP的状态图就不困难了，无非就是对TCP连接3次握手4次挥手过程的打包概述而已。