我们有一个使用 tornado 编写的服务器，它通过 websockets 向客户端发送异步消息。在本例中，是在 Mac 上的 Chrome 中运行的 javascript 应用程序。当客户端被强制断开连接时，在这种情况下通过让客户端休眠，服务器仍然认为它正在向客户端发送消息。此外，当客户端从睡眠中醒来时，消息会以突发方式传递。
这些消息排队/缓冲的机制是什么？谁是负责的人？为什么他们仍然交付？谁在重新连接套接字？我的直觉是，即使 websocket 不像 HTTP 那样请求/响应，它们仍然应该需要 ACK 数据包，因为它们是基于 TCP 构建的。这样做是为了使协议对移动时代的暂时下降更加健壮吗？
浏览器可以在单独的线程中处理 websocket 客户端消息，该线程不会被睡眠阻塞。
即使您的自定义应用程序的某个线程未处于活动状态，当您强制它进入睡眠状态（如 sleep(100)）时，在这种情况下 TCP 连接也不会关闭。套接字句柄仍然由操作系统内核管理，并且 TCP 服务器仍然发送消息，直到它到达 TCP 客户端的接收窗口溢出。即使在此之后，服务器端的应用程序仍然可以成功提交新消息，这些消息在服务器端的 TCP 级别缓冲，直到 TCP 传出缓冲区溢出。当传出缓冲区已满时，应用程序应在发送请求时收到错误代码，例如“没有更多空间”。我自己没有尝试过，但它的行为应该是这样的。
尝试关闭客户端（终止进程），你会看到完全不同的画面——服务器会注意到断开连接。
对于高度可靠的场景，断开连接和溢出这两种情况都很难在服务器端处理。断开连接情况可以转换为溢出情况（当客户端重新连接时，websocket 服务器可以将消息缓冲到用户空间的某个限制）。但是，没有简单的方法来可靠地处理传输缓冲区限制的溢出。我只看到一个解决方案 - 将溢出错误传播回事件的发起者，这引发了由于溢出而被丢弃的消息。