TCP的FIN_ WAIT_ 2状态与FIN_ WAIT_ 1状态详解 1. 问题描述 在TCP四次挥手过程中，主动关闭连接的一方会经历 FIN_ WAIT_ 1 和 FIN_ WAIT_ 2 状态。这两个状态容易混淆，且涉及超时处理、资源管理等问题。面试中常考察： 两个状态的区别及触发条件； 状态持续时间的控制； 异常场景（如对端不发送FIN）的处理机制。 2. 状态触发条件与流程 FIN_ WAIT_ 1状态 触发条件 ：主动关闭方发送FIN报文后进入该状态，等待对端的ACK确认。 正常转移 ： 若收到对端的ACK，则进入 FIN_ WAIT_ 2 状态； 若同时收到对端的FIN+ACK（对端也同时关闭），则直接进入 TIME_ WAIT 状态。 FIN_ WAIT_ 2状态 触发条件 ：在FIN_ WAIT_ 1状态下收到对端的ACK后进入。 正常转移 ：等待对端发送FIN报文，收到后回复ACK，并进入 TIME_ WAIT 状态。 3. 状态细节与超时控制 FIN_ WAIT_ 1的异常处理 若未收到ACK或FIN+ACK，TCP会启动重传机制： 重传FIN报文（次数由系统配置限制，如默认5次）； 若始终无响应，则超时后连接强制关闭。 FIN_ WAIT_ 2的等待机制 该状态需等待对端发送FIN报文，但 对端可能一直不关闭连接 （如半关闭状态，仅发送数据而不发FIN）。 超时控制 ： 系统会设置 FIN_ WAIT_ 2定时器 （如Linux的 tcp_fin_timeout 参数，默认60秒）； 超时后主动关闭方直接进入 CLOSED 状态，释放资源。 若对端在超时前发送数据，TCP会正常接收并传递至应用层，但不会重置定时器。 4. 资源管理与常见问题 为什么需要FIN_ WAIT_ 2状态？ 保证对端有足够时间处理未完成的数据传输（如被动关闭方仍需发送剩余数据）。 若直接跳过FIN_ WAIT_ 2，可能导致对端数据丢失。 FIN_ WAIT_ 2状态累积的风险 若对端不发送FIN（如程序bug或恶意行为），主动关闭方会长期占用连接资源。 解决方案： 调整系统参数（如缩短 tcp_fin_timeout ）； 监控网络连接状态，及时kill异常进程。 5. 实例分析（四次挥手片段） 假设主机A主动关闭与主机B的连接： A发送FIN，进入 FIN_ WAIT_ 1 ； B回复ACK，A进入 FIN_ WAIT_ 2 ； B发送FIN，A回复ACK后进入 TIME_ WAIT ； 若B在第3步迟迟不发送FIN，A在60秒（默认）后自动关闭连接。 6. 总结 FIN_ WAIT_ 1 ：等待ACK或FIN+ACK，需处理重传； FIN_ WAIT_ 2 ：等待对端FIN，需防范对端“半关闭”导致的资源占用； 两者均需依赖超时机制避免无限等待，是TCP可靠关闭的重要环节。