我知道对于 HTML 和发送数据，鼓励不经常发送大量数据，因为与标题、内容、标签、到期日期、cookie 等相关的开销。为了更好的用户体验和更少的延迟，最好发送大消息不经常比小更新频繁。
但是，WebSockets 就是这种情况吗？现在在我的网页上，我非常频繁地发送大量像素数据，因此客户不会遇到太多波动。但是，如果我不经常发送更新会更好吗？
我想我的问题归结为：“使用 WebSockets，不经常发送大消息比频繁发送小消息更有效吗？” 我想我听说这项技术摆脱了与发送和接收消息相关的大部分开销，因为它保持恒定的连接并且是全双工的，等等。
谢谢阅读。
编辑：帮助计算机
我想说的主要一点是，健谈与笨拙的接口不限于技术堆栈（WebSockets、HTTP、UDP、其他网络相关协议）。它们都具有相同的属性，并且必须以类似（如果不相同）的方式权衡许多请求与较大请求的影响。这是一篇很棒的文章，可以更多地阅读该主题。
最后要注意的是，您的应用程序的性质也会最大程度地影响您的决定。实时股票交易系统将比简单的用户输入表单更健谈。
编辑
这是一个与 WebSocket 性能相关的类似问题：HTTP vs Websockets 关于开销
发送大小 <=125 个八位字节有效负载的 WebSocket（客户端到服务器）消息的开销为 6 个八位字节。高达 64k 的有效载荷将是 8 个八位字节，超过 14 个八位字节。
由于 WebSocket 是基于 TCP 的协议，由于流/动态窗口大小调整，快速发送许多小消息将成批成较大大小的 TCP 段和无论如何发送的 IP 数据包。在网络上，它类似于更慢地发送大型 WS 消息。
当然，这只适用于异步发送的情况，即在发送另一条消息之前无需等待已发送消息的响应。