运维面试题8：说说 TCP 的四次挥手?

好的，面试官。

TCP 的四次挥手是连接终止的标准过程，确保双方可靠地关闭连接。以面我试着对它进行详细分析：

​​1. 四次挥手流程​​

假设客户端主动发起关闭：

1. ​​FIN (Client → Server)​​
   • 客户端发送 FIN=1, seq=u，进入 FIN-WAIT-1 状态。
   • ​​含义​​：“我没有数据要发了，但还能收你的数据”。
2. ​​ACK (Server → Client)​​
   • 服务端回复 ACK=1, ack=u+1，进入 CLOSE-WAIT 状态。
   • ​​含义​​：“我收到你的关闭请求了，但我可能还有数据要发”。
   • 客户端收到后进入 FIN-WAIT-2 状态。
3. ​​FIN (Server → Client)​​
   • 服务端发送 FIN=1, seq=v（可能携带最后的数据），进入 LAST-ACK 状态。
   • ​​含义​​：“我的数据也发完了，可以彻底关闭了”。
4. ​​ACK (Client → Server)​​
   • 客户端回复 ACK=1, ack=v+1，进入 TIME-WAIT 状态，等待 ​​2MSL​​ 后关闭。
   • 服务端收到后立即关闭连接。

​​2. 为什么需要四次？​​

• ​​双向连接独立关闭​​：TCP是全双工协议，每个方向需单独关闭。
  • 第一次挥手：关闭客户端→服务端方向。
  • 第三次挥手：关闭服务端→客户端方向。
• ​​中间过渡状态​​：CLOSE-WAIT 允许服务端继续发送残留数据（如未传完的响应）。

​​3. 关键状态与超时控制​​

​​4. TIME-WAIT 状态的必要性​​

• ​​可靠终止​​：确保最后一个ACK到达服务端（若丢失，服务端会重传FIN）。
• ​​避免旧连接干扰​​：2MSL（报文最大生存时间）确保网络中残留报文失效。
• ​​副作用​​：高并发短连接时可能导致端口耗尽（可通过 SO_REUSEADDR 复用端口）。

​​5. 异常场景处理​​

​​场景1：主动方最后ACK丢失​​

• 服务端重传FIN，客户端在 TIME-WAIT 状态下可重新回复ACK。
• 若客户端已完全关闭，服务端达到重试上限（tcp_orphan_retries）后强制关闭。

​​场景2：被动方不关闭（CLOSE-WAIT堆积）​​

• ​​原因​​：服务端应用未调用 close()（如代码Bug）。
• ​​风险​​：连接泄漏，耗尽资源。
• ​​解决​​：
  # 监控CLOSE-WAIT连接数
  netstat -ant | grep CLOSE_WAIT | wc -l

  # 调整内核参数（缩短超时）
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

​​场景3：主动方崩溃​​

• 若客户端在 FIN-WAIT-1 或 FIN-WAIT-2 状态崩溃，服务端通过保活机制（Keepalive）检测后关闭。

​​6. 优化建议​​

• ​​快速回收TIME-WAIT​​（仅适用于安全内网）：
  echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle # （Linux 4.1+已移除）
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse # 允许复用TIME-WAIT连接
• ​​应对SYN Flood和TIME-WAIT攻击​​：
  # 调整MSL时间（默认60秒）
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout