开启KeepAlive的C# Socket断网时未发包导致Connected状态异常问题

差异原因 #

你遇到的场景差异是Windows TCP协议栈的默认行为导致的，不属于你的KeepAlive配置错误：

• 当设备存在其他处于链路Up状态的网络适配器（比如连接互联网的网卡/ WiFi）时，你拔掉连接远程主机的局域网网线后，系统仍认为存在可用网络接口，会继续按配置发送TCP保活报文，报文发送后收不到ACK超时，就会将连接标记为断开，Socket.Connected返回false。
• 当设备没有其他可用网络连接，所有适配器都处于链路Down状态时，TCP栈会直接判定没有可用路由发送保活报文，不会生成对应的保活包，自然不会触发超时断连逻辑，因此Socket.Connected会一直保持true状态。

此外要注意：Socket.Connected属性本身仅反映上一次IO操作时的连接状态，本身不具备实时性，即使TCP层已经断连，如果没有触发IO操作，该属性也可能返回true。

解决方案 #

要实现全场景的断连检测，可以搭配以下几个方案兜底：

• 监听指定网卡的链路状态
  你的远程主机仅通过独立的局域网适配器连接，可以通过Windows API直接监听该适配器的链路状态，一旦检测到该适配器链路Down（网线被拔出），直接手动关闭对应Socket，标记连接断开。
• 实现应用层心跳
  不要完全依赖TCP层KeepAlive，自己在应用层实现定时心跳机制：按固定间隔向对端发送心跳包，若连续3个发送周期没有收到对端响应，不管Socket.Connected的返回值，直接主动断开连接即可。
• 增加主动探测逻辑
  针对只读套接字，可定期调用Send方法发送0长度的空包，若调用返回错误或抛出异常，即可判定连接已断开。

你的SetupKeepAlive扩展方法的配置逻辑本身没有问题，只是TCP层保活本身受操作系统网络栈状态约束，无法覆盖所有断网场景，需要搭配应用层逻辑做兜底。

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