Python：TCP 中断路由检测起来非常慢
Python: TCP broken route is painfully slow to detect
我用 Python3/asyncio(Protocol) 编写的服务器应用程序有问题，但我很确定它与 python 或 asyncio 无关，因为我尝试了不同的版本，还有一些 5liner只是用套接字接口。
它是关于与许多客户端硬件 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 分钟太多了。
通过实施应用程序协议回答了类似的问题，这在我的情况下是不可能的。
我只是想确保对方在某个合理的时间内收到数据包（TCP ack）。
我仔细阅读了有关 socket.setsockopt 的文档，但没有发现任何有用的信息。也没有找到方法如何检查发送缓冲区是否被刷新来做一些变通方法-手动检测断开的路由。
TCP keep-alive 也没有帮助，因为它基于 inactivity 时间并且发送数据是 activity.
您看到了 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 秒正在重试。
更改应用程序协议是解决此问题的可靠方法，但由于您提到它对您不起作用，您的选择围绕询问 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。
我用 Python3/asyncio(Protocol) 编写的服务器应用程序有问题，但我很确定它与 python 或 asyncio 无关，因为我尝试了不同的版本，还有一些 5liner只是用套接字接口。 它是关于与许多客户端硬件 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 分钟太多了。
通过实施应用程序协议回答了类似的问题，这在我的情况下是不可能的。
我只是想确保对方在某个合理的时间内收到数据包（TCP ack）。
我仔细阅读了有关 socket.setsockopt 的文档，但没有发现任何有用的信息。也没有找到方法如何检查发送缓冲区是否被刷新来做一些变通方法-手动检测断开的路由。
TCP keep-alive 也没有帮助，因为它基于 inactivity 时间并且发送数据是 activity.
您看到了 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 秒正在重试。
更改应用程序协议是解决此问题的可靠方法，但由于您提到它对您不起作用，您的选择围绕询问 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
ETIMEDOUTto 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。