简而言之: 服务器调用::send() 成功，但数据未通过电缆传输。客户端在几秒钟后发送其退出命令，因为它没有收到任何东西并且该命令已被服务器正确接收。
详情: 服务器每 1/10 秒向其客户端发送一次命令，每秒发送一次心跳。客户端只返回心跳的确认。我们修改了服务器应用程序以记录发送和接收的每个命令，并且我们使用 Wireshark 记录了 pc 的流量。我们可以将每个记录的命令与 TCP 数据包匹配，直到问题出现。该问题一次只影响一个客户端。数据继续与其他客户端正常流动。连接通常会在出现问题之前工作几分钟。连接应该从客户端启动的那一刻开始工作，直到它关闭(即几天)。
当问题发生时，日志文件包含预期的命令，但 Wireshark 转储不包含任何内容。下图显示了一个客户端的流量。红线是流量停止，但服务器继续调用::send() 成功。 
大约 4 秒后，客户端超时并关闭连接。它发送一个退出命令，服务器正常接收它。
更让我困惑的是包含退出命令的数据包没有被TCP ACK数据包确认。就好像 TCP 连接在发送端完全堵塞了一样。重传是那个堵塞的结果，但即使是建立新连接的 TCP SYN 也没有得到正确处理，也没有得到简单的 TCP ACK。
大约 30 秒后，问题消失，SYN 数据包最终被接受，通信继续使用新连接。
这已在各种 Windows 版本上进行了测试。在测试期间，使用了远程桌面 session ，它从未因同样的问题而断开连接。它保持连接数小时没有任何问题。当客户端通过无线网桥时，问题更频繁。我们在无线端点的两侧都使用了 Wireshark，我们没有看到可以解释较高断开率的重传或数据包丢失。
当许多客户端连接到同一个网桥时，它们不会同时失败。一次只有一个。所以无线噪音似乎不是一个解释。我们可以在 Wireshark 转储中看到一些重传，但通信照常进行，在问题发生之前没有重传。接入点连接到服务器的交换机。客户端pc和服务器pc没有使用无线网卡。
长期以来，我们认为偶尔的断线是由网络引起的，但越来越多的安装是无线的，现在断线非常频繁，以至于给用户带来了问题。
我们尝试了启用和不启用 Windows 防火墙。即使防火墙被禁用，我们也添加了端口异常(exception)。客户端或服务器都没有防病毒软件。
最佳答案
关于c++ - 与 TCP 套接字断开连接非常奇怪，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11505877/