TCP四次挥手不可简化为三次，因其需保障全双工下双向数据可靠交付与状态可预测；TIME_WAIT存续2MSL是为了确保最后ACK可达及防止旧报文干扰新连接。
Linux TCP 四次挥手不是“设计得繁琐”，而是为保证全双工连接下两端数据的**可靠交付**与**状态可预测性**——只要任意一端还有未确认的数据或 FIN，就不能单方面关闭连接。
为什么不能三次挥手？
因为 TCP 是全双工协议，两端可以独立发送 FIN。A 发送 FIN 表示“我发完了”，但 B 此时可能还在发数据，或有未 ACK 的报文，B 不能立刻回 ACK + FIN。必须等 B 自己也准备好了（应用层调用 close() 或 shutdown(SHUT_WR)），才能发自己的 FIN。强行合并会导致：B 的剩余数据丢失、B 的 FIN 被 A 丢弃（因 A 已进入 CLOSED）、连接异常中断。
TIME_WAIT 状态为何必须存在 2MSL？
TIME_WAIT 不是 Linux 特有，而是 TCP 协议要求。它的两个核心作用：
- 确保被动关闭方（收到第一个
FIN的那一端）能收到最后的ACK：如果这个ACK丢了，对方会重传FIN，TIME_WAIT端能再次响应，避免对方卡在LAST_ACK - 防止旧连接的延迟报文干扰新连接：2MSL（Maximum Segment Lifetime）足够让网络中所有属于该四元组（src_ip:port, dst_ip:port）的残留包过期
Linux 默认 60 秒（即 2MSL ≈ 30s），可通过 /proc/sys/net/ipv4/tcp_fin_timeout 调整，但不建议设太小；更安全的做法是启用 net.ipv4.tcp_tw_reuse = 1（仅对客户端有效）或 tcp_tw_recycle（已废弃，NAT 下必出问题）。
主动关闭方如何快速回收 TIME_WAIT 连接？
常见误区是盲目调小 tcp_fin_timeout 或开 tcp_tw_recycle。真正可控且安全的方式只有：
- 服务端避免做主动关闭：让客户端发起
FIN，服务端只响应ACK和后续FIN（即尽量由客户端承担TIME_WAIT） - 客户端启用
net.ipv4.tcp_tw_reuse = 1，并在connect()前设置 socket 选项SO_LINGER为 {on=1, linger=0}（强制 RST 关闭，跳过四次挥手——仅适用于明确不需要可靠终止的场景） - 复用连接：HTTP/1.1 的
Connection: keep-alive、HTTP/2 多路复用，从源头减少短连接数量
注意：SO_LINGER 设为 0 会绕过 TIME_WAIT，但可能导致对端收到 RST 后应用层误判为连接异常；它不是“优化”，而是放弃可靠性换速度。
四次挥手的“冗余感”恰恰来自它对边界情况的穷尽覆盖——比如半关闭、RST 干扰、乱序 FIN、NAT 设备老化表项。跳过某步或压缩状态，往往不是提速，而是把问题留给上层应用去 debug。
