使用Boost ASIO的C++程序退出后TCP Socket仍处于ESTABLISHED状态

这种TCP连接残留的问题我在基于Boost ASIO开发服务端时也碰到过，结合实际排查经验和ASIO的特性，给你整理几个可行的方向：

一、先做基础排查，定位问题根源 #

• 确认服务端关闭流程的完整性：
  别只看代码里有没有写关闭socket的逻辑，要仔细核对：是不是每个已连接的socket都调用了shutdown(boost::asio::socket_base::shutdown_both)再执行close()？有没有遗漏某个连接？另外，Boost ASIO的异步操作如果还在pending状态，会阻碍socket的正常关闭——你有没有在停止io_context前，对所有socket调用cancel()取消异步任务？有没有等待运行io_context的所有线程完全退出？
• 验证服务端进程是否真的终止：
  用ps aux | grep 你的进程名确认服务端进程是否完全退出。如果进程还残留（比如僵尸进程或者没正确退出的线程），那连接自然会保持ESTABLISHED状态。
• 抓包分析TCP握手流程：
  用tcpdump或者Wireshark抓包，看服务端退出时的TCP四次握手是否完整：服务端有没有发送FIN包？客户端有没有回应ACK？如果四次握手没完成，就能定位是哪一端的问题——是服务端没触发关闭，还是客户端没响应。
• 检查客户端的行为逻辑：
  有些客户端可能没处理服务端的关闭通知，比如服务端发了FIN，但客户端的代码还在阻塞读或者没监听socket的关闭事件，导致客户端一直认为连接正常，从而维持ESTABLISHED状态。可以在测试环境里用一个简单的客户端模拟，看是否能重现问题。

二、针对性的解决方法 #

• 完善服务端的关闭流程：
  这是最常见的解决点，按这个顺序来：
  1. 先停止监听新连接：关闭acceptor，确保不再接收新的客户端连接。
  2. 对每个已连接的socket，先调用shutdown(shutdown_both)，这个操作会主动通知客户端“我要关闭连接了”，比直接close()更规范。
  3. 调用socket.cancel()取消该socket上所有pending的异步读写任务，避免这些任务占用socket资源。
  4. 调用socket.close()关闭本地socket。
  5. 调用io_context.stop()停止IO服务，然后等待所有运行io_context的线程join完成，确保所有异步处理逻辑都执行完毕。
• 合理使用SO_LINGER选项（谨慎选择）：
  如果客户端确实无法主动关闭连接，你可以给socket设置SO_LINGER选项，让服务端在close()时立即发送RST包强制断开连接。代码示例大概是：

  boost::asio::socket_base::linger option(true, 0);
  socket.set_option(option);
  

  注意：这个方式会跳过TCP四次握手，可能导致未传输完成的数据丢失，只适合对数据完整性要求不高的场景。
• 处理系统层面的特殊情况：
  如果确认服务端进程已经完全退出，但连接还是ESTABLISHED，那可能是操作系统内核的异常或者网络中间件（比如防火墙、负载均衡）的问题。可以检查系统的socket统计（ss -s），或者调整相关内核参数（比如net.ipv4.tcp_orphan_retries），不过这种情况比较少见，优先排查应用层问题。

内容的提问来源于stack exchange，提问作者Konstantin Utkin