我刚刚发现 Twitter 流媒体端点以某种方式支持检测慢速连接。
参考：https ://dev.twitter.com/docs/streaming-apis/parameters#stall_warnings （和页面底部）
想法是套接字发送可能会一一处理数据。它知道客户端何时收到一个数据包，因此它可以维护队列并始终知道它的大小。
当客户端为每个人发送一些确认数据包时，这很容易。但 Twitter Streaming API 并非如此——它是一种单向传输。
我的问题是：他们是如何做到这一点的？如果没有一些非常低级别的原始套接字支持，我看不到一种方法 - 但我可能在这里忘记了一些东西。通过一些低级别的支持，我们可能会为每个数据包获得 ACK。这甚至可能吗？可以以某种方式追踪 ACK 吗？
还有其他想法是如何做到的吗？有什么方法可以做到这一点，例如在 Python 中？或任何其他语言示例将不胜感激。
或者也许我在这里不知所措，它只是用来跟踪有多少字节尚未通过 socket.send 处理？但这不是客户端连接的不良指示吗？
我一开始的想法和你一样，但我认为实现实际上比我们预期的要容易得多。
Twitter 的 API 文档状态：-
“客户端读取数据太慢。每个流连接都由要发送到客户端的消息队列支持。如果这个队列随着时间的推移变得太大，连接将被关闭。” - https://dev.twitter.com/docs/streaming-apis/connecting#Disconnections
基于上述，我想 Twitter 将有一个线程将推文推送到队列和与客户端的长期 http 连接（通过 while 循环保持打开），该连接将消息从队列中弹出并将数据写入 http 响应在每次循环迭代期间。
现在，如果您想象一下 while 循环内部发生了什么，并且您考虑缓冲区，Twitter 将从队列中弹出一个项目，然后将推文数据写入某种输出缓冲区，该缓冲区将被刷新，然后填满 TCP 缓冲区用于运输给客户。
如果客户端从其 TCP 缓冲区缓慢读取数据，则服务器的TCP 发送缓冲区将填满，这意味着当服务器的输出缓冲区被刷新时，它将阻塞，因为数据无法写入 TCP 缓冲区，因此意味着 while 循环是不经常从队列中弹出推文（因为在刷新数据时它被阻塞）导致推文队列填满。
现在，您只需要在每次循环迭代开始时进行检查，以检查 Tweet 队列是否已达到某个预定义的阈值。