计算机网络-TCP的四次挥手

1. 四次挥手的过程

2. 为什么FIN消息自己需要独立占据一个seq号

• 如果不消耗一个独立的seq号，那么，对于之后接受到的ack号，就无从判断：到底是对方收到了之前自己发出的载荷数据，还是FIN消息

3. FIN_WAIT_1 和 FIN_WAIT_2 有什么区别？

1. 什么时候进入FIN_WAIT_1状态？

• 客户端发送了自己的FIN消息之后，就立刻进入FIN_WAIT_1状态，这个状态下，客户端实际上处在一种半关闭状态，也就是客户端保证了自己不会发送消息，在等待服务端发送ACK消息。

1. 什么时候进入FIN_WAIT_2状态？

• 客户端收到了服务端发送的ACK消息，也就是说，已经明确了服务端确实已经知道了我想关闭连接了，那么，此时就会进入FIN_WAIT_2状态。
• 这个状态下，客户端依然不具备发送消息的能力，也是一种半关闭状态，但是在等待服务端发送FIN消息，也就是说，等待服务端处理完所有的数据，并发送FIN消息，希望结束连接。

3. 为什么第三次挥手和第二次挥手的 seq 号可能相同`

• 上图中，第二次挥手和第三次挥手的ack号相同，这是不难理解的，因为二者都是对于第一次挥手（即客户端发起的FIN请求的确认）
• 但是为什么二者的seq可能相同呢？
• 因为服务端在这个过程当中没有传输数据，因此，第二次挥手和第三次挥手的seq是相同的。
• 这会不会造成混乱？
• 不会，因为最后一次客户端的ACK确认，本质上是对于上一次的服务端FIN消息的确认，可以通过FIN位判定实际拿到的消息是否为FIN消息。

4. 什么时候仅需三次挥手？

• 需要满足两个条件：1. 服务端在CLOSE_WAIT阶段没有传输数据 2.开启了TCP延迟确认机制
• 什么是延迟确认机制？ [[计算机网络-TCP的延迟确认]]