browser - 我可以在我的 websockets 上进行流量控制吗？

Question

我正在使用 websockets 将 video-y 图像从用 Go 编写的服务器传输到客户端，这是一个 HTML 页面。我在下面分享的经验是关于 Chrome 的。

我通过 websocket 的 onmessage 处理程序接收图像。在接收图像时，我可能需要异步完成一些任务才能显示图像。即使这些任务没有完成，另一个 onmessage() 可能会触发。我不想对图像进行排队，因为在这一点上我无法像服务器一样快速地进行处理，而且显示旧图像也没有意义。我也不想丢弃这些图像，我根本不想接收它们。

如果客户端使用传统的 TCP 连接，它只会停止从连接中读取数据。这将导致接收缓冲区被填满，接收窗口被关闭，并最终暂停在服务器上发送图像。一旦客户端开始读取，接收缓冲区将清空，接收窗口将打开，服务器将恢复传输。每次我的服务器开始发送图像时，它都会选择最新鲜的图像。这种最新鲜的行为与 TCP 的流量控制一起确保了在许多情况下的合理行为。

websockets 是否可以具有基于 websockets 的 TCP 的流量控制功能？我对依赖 TCP 流量控制而不依赖应用程序级流量控制的解决方案特别感兴趣，因为这往往会导致不必要的额外延迟。

Answer 1

现在可以在 WebSocket 中使用流。 Chrome 78 将附带一个支持背压的新 WebSocketStream API。

这是来自 Chrome Platform Status 的引述:

The WebSocket API provides a JavaScript interface to the RFC6455 WebSocket protocol. While it has served well, it is awkward from an ergonomics perspective and is missing the important feature of backpressure. The intent of the WebSocketStream API is to resolve these deficiencies by integrating streams with the WebSocket API.

Currently applying backpressure to received messages is not possible with the WebSocket API. When messages arrive faster than the page can handle them, the render process will either fill up memory buffering those messages, become unresponsive due to 100% CPU usage, or both.

Applying backpressure to sent messages is possible but involves polling the bufferedAmount property which is inefficient and unergonomic.

不幸的是，这是一个仅限 Chrome 的 API，没有网络标准在撰写本文时。

更多信息见:

• Issue 983030: Implement WebSocketStream