sockets - 为什么许多库没有检测到无效的TCP连接？

Question

TCP具有检测死连接的保持 Activity 机制，但令我感到惊讶的是，该选项默认情况下处于关闭状态，并且许多库/工具均未使用此功能。

如果我正确理解的话，如果来自对等方的所有FIN/RST数据包都丢失了，则在recv调用中阻塞的TCP连接将无法检测到该连接是否实际上已被中止。

客户端的超时参数可以缓解此问题，但是许多库也没有设置超时的选项。一个示例是mysql-python连接器没有recv超时选项。另一个示例是Nginx服务器通过proxy_pass与gunicorn后端进行通信，由于其上的死连接，gunicorn worker 可能会停止响应，但是gunicorn worker 无法检测到它。

如果我错了，谁能解释原因或纠正我？

Answer 1

术语“死连接”有点含糊-可能表示以下任何一种情况:

对等程序关闭其套接字(或者对等程序退出或崩溃，并且对等计算机的操作系统关闭套接字，作为其标准进程清除的一部分)

与对等计算机的连接突然丢失(这可能是由于对等计算机断电，或者有人拔出了将对等计算机连接到路由器的以太网线，或者对等方的ISP出现了路由器故障，或者您的ISP发生路由器故障等)

对等程序仍在运行，但只是决定(由于某种原因，可能是由于错误)决定不再在其TCP套接字上调用recv()。

程序和远程对等方之间的数据包路径仍然存在，但是，沿着该路径的内容正在丢弃太多数据包，以至于TCP连接的有效传输速率已降至大约零。

因此，第一个要回答的问题是，TCP层将自行检测以下哪些条件？

条件(1)是简单的情况-对等方的TCP堆栈将向您发送FIN数据包，并且当程序的网络堆栈收到它们时，它将确定TCP连接已关闭并采取相应措施，因此您的recv( )调用将很快返回0。

在条件(2)中，答案是“有时”-尤其是，如果您的程序在套接字的输出缓冲区中有任何TCP数据正试图发送给对等方，并且它从未获得与该数据有关的任何ACK数据包， ，然后经过一定数量的超时(以及随后的数据包重发尝试)，计算机的TCP堆栈将放弃，声明连接已死，并单方面关闭TCP连接；另一方面，recv()将返回0。另一方面，如果没有尝试发送的传出TCP数据包，则本地TCP堆栈将不会等待任何ACK的返回，因此它将不会如果没有收到它们，就不要超时，因此它将永远不会放弃并关闭TCP连接。在这种情况下，您的recv()调用可能会无限期地阻塞，因为TCP连接处于空闲状态，并且TCP堆栈无法知道对等端已消失(与现在不发送任何数据相反)。这种情况下应该使用SO_KEEPALIVE选项进行处理，但是由于SO_KEEPALIVE选项的设计者希望默认情况下节省带宽，并且发送自动keepalive数据包会占用额外的带宽，因此他们决定默认情况下禁用keepalive选项。另外，按照现代标准(例如，小时数)，默认的“发送keepalive”间隔通常会很长，并且在某些操作系统上，除非在整个系统范围内更改，否则很难更改，这使SO_KEEPALIVE在许多应用程序中的用途有限。

对于条件(3)和(4)，TCP连接并不是真正的“死”，只是某些设备(对等程序或程序与对等之间某处的网络设备)不合作。由于TCP层无法知道正在使用它的应用程序试图达到什么目的，因此明智地不要试图对此进行第二次猜测，除非您明确告诉它关闭，否则它将使TCP连接保持打开状态( ) 连接。

因此，既然我们已经描述了TCP层的行为，那么使用它的应用程序和API呢？即，为什么他们不尝试通过提供更好的检测来改善基本的TCP堆栈行为？答案是其中一些人确实这样做。例如通过周期性地在任何空闲的套接字上发送虚拟的“ping”消息，仅仅是“刺激” TCP堆栈以检测何时没有ACK返回，如上面关于条件(2)的段落中所述。有些人甚至走得更远，期望远程对等方发送相应的“pong”消息，以便在(这么多)秒之内返回相同的套接字，如果没有，程序将单方面关闭套接字。这种工作方式可行，但是它也会对网络性能进行假设，并且可能会导致误报，因此当对等方通过慢速或不可靠的网络进行连接时会导致不必要的断开连接，这就是为什么许多应用程序/库不这样做的原因。 t实现此功能(或至少默认情况下不启用它)。