Python:TCP 中断路由的检测速度非常慢

Question

我在使用 Python3/asyncio(Protocol) 编写的服务器应用程序时遇到了问题，但我很确定它与 python 或 asyncio 的关系不大，因为我尝试了不同的版本，还有一些 5liner 只是带有套接字接口(interface)。它是关于与许多客户端硬件 TCP/IP<->RS232 转换器的并发通信。这就是使用 asyncio 而不是阻塞写入的线程的原因。

有一些周期性的短数据发送。当我物理地切断连接并等待异常发生时出现问题:

asyncio - Fatal read error on socket transport protocol
<_SelectorSocketTransport fd=11 read=polling write=<idle, bufsize=0>>
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/selector_events.py", line 663, in
_read_ready
data = self._sock.recv(self.max_size)
OSError: [Errno 113] No route to host

它发生了，但是在 15 分钟 之后，这意味着我发出 15 分钟的信号，一切都很好，但事实并非如此，这是难以忍受的漫长和功能中断。在不同硬件的 Ubuntu 16.04、Ubuntu 14.04 和 Debian Jessie 中检查了行为。

我发现(可能)内核正在缓冲数据，因为如果我在十分钟后重新连接设备，所有数据都会立即刷新。我知道这对短暂断开连接有好处，10 秒、15 秒甚至一分钟都没有问题，但 15 分钟太多了。

通过实现应用程序协议(protocol)回答了类似的问题，这在我的情况下是不可能的。我只是想确保对方在某个合理的时间内收到数据包(TCP ack)。我仔细阅读了有关 socket.setsockopt 的文档，但没有发现任何有用的信息。也没有找到方法如何检查发送缓冲区是否被刷新来做一些变通方法——手动检测断开的路由。

TCP keep-alive 也没有帮助，因为它基于不活动时间并且发送数据是事件的。

Answer 1

您将看到 TCP 的重传超时 (RTO) 行为。

您的 TCP 永远不会收到任何反馈¹，因此它会非常努力地尝试让这些段通过。在 Linux 上，此行为受 net.ipv4.tcp_retries2 = 15 约束。 :

This value influences the timeout of an alive TCP connection, when RTO retransmissions remain unacknowledged. Given a value of N, a hypothetical TCP connection following exponential backoff with an initial RTO of TCP_RTO_MIN would retransmit N times before killing the connection at the (N+1)th RTO.

The default value of 15 yields a hypothetical timeout of 924.6 seconds and is a lower bound for the effective timeout. TCP will effectively time out at the first RTO which exceeds the hypothetical timeout.

这意味着您的 send 显然有效(即 TCP 最终同意发送您的数据)并且您等待 TCP 继续重试约 900 秒。

更改应用程序协议(protocol)是解决此问题的可靠方法，但由于您提到它对您不起作用，您的选择围绕着询问 TCP。

TCP_USER_TIMEOUT似乎完全按照您的意愿行事:

When the value is greater than 0, it specifies the maximum amount of time in milliseconds that transmitted data may remain unacknowledged before TCP will forcibly close the corresponding connection and return ETIMEDOUT to the application.

有关 Application Control of TCP retransmission 的更多详细信息.

Also didn't find method how to check if send buffer was flushed to do some workarounds-manual detection of broken route.

上面链接的问题有 SIOCOUTQ - 检查输出队列中的数据量 - 作为您描述的解决方法。

---

¹例如，它可能会收到 TCP RST 或无法访问的 ICMP。