在执行 AJAX 请求时，我总是尽量少做，因为每个请求都需要打开 http 连接来发送数据。由于 websocket 连接是不断打开的，发送请求是否有明显的数据包带宽之外的任何成本？
例如。在 1 分钟的时间里，客户端将向服务器发送 100kb 的数据。假设客户端不需要对这些请求中的任何一个做出响应，那么将数据包排队并在一个大的突发中发送它们与在它们准备好时发送它们有什么优势吗？
换句话说，对于不断打开的连接，停止和启动数据传输是否存在开销？
我想制作一个尽可能实时的多人浏览器游戏，但我不想发现每分钟 100 个微小的请求与更大的合并请求相比会给服务器带来额外的压力。我知道如果客户需要响应，它会更慢，因为来回等待很多。我会考虑这一点，只有在合适的时候才会巩固。每分钟的请求越小，用户体验就越好，但我不知道它会对服务器造成什么影响。
【问题讨论】：
标签： websocket packet data-transfer
你说得对，对于给定的消息传输，webSocket 消息的开销比通过 Ajax 调用发送相同的消息要低，因为 webSocket 连接已经建立，而且 webSocket 消息的开销低于 HTTP 请求。
首先，与发送大量较小的传输相比，发送一个较大的传输总是有更少的开销。这就是 TCP 的本质。每个 TCP 数据包都会被单独处理和确认，因此发送更多数据包会花费更多开销。这种差异是否相关或显着，是否值得为用户体验编写额外代码或是否值得牺牲某些用户体验元素（因为批处理的延迟）完全取决于给定情况的具体情况。
既然您已经描述了一种情况，即如果没有延迟且没有分组数据包，您的客户端可以获得最佳体验，那么您应该做的似乎不是实施批处理并测试您的服务器如何处理负载当它变得非常繁忙时，会有很多较小的数据包。如果效果很好，那么请保持更好的用户体验。如果您在跟上负载方面遇到问题，请认真分析您的服务器并找出性能的主要瓶颈在哪里（您可能会对瓶颈的实际位置感到惊讶，因为它通常不是您认为的位置 - 那就是为什么你必须分析和衡量才能知道将精力集中在哪里来提高可扩展性）。
仅供参考，由于在大多数 TCP 实现中都实现了Nagel's algorithm，如果您发送多个请求的时间间隔相当近或通过较慢的链接发送，TCP 堆栈本身会为您执行少量批处理。
也可以实现一个动态系统，只要您的服务器能够跟上，您就可以使用更小且响应速度更快的数据包，但是如果您的服务器开始忙碌，您就开始批处理以减少单独传输的数量。
【讨论】：