performance - WebSockets 在什么时候比轮询效率低？

Question

虽然我知道上述问题的答案在某种程度上取决于您的应用程序架构，但我主要对非常简单的场景感兴趣。

本质上，如果我的应用程序每 5 秒或每分钟 ping 一次以进行更改，那么大约何时发送以维护打开的 Web Sockets 连接的数据最终会超过您通过简单轮询浪费的数量？

基本上，我感兴趣的是，如果应用程序不一定需要实时更新，而只需要定期检查，是否有一种方法可以通过使用 Meteor 等框架来量化您的效率低下。

请注意，我在这里关注的重点是带宽利用率，而不一定是数据库访问时间，因为像 Meteor 这样的框架具有高度优化的方法，只请求对数据库进行更新。

Answer 1

websocket 连接的全部意义在于您不必对应用程序执行 ping 操作以进行更改。相反，客户端只需连接一次，然后服务器可以在客户端可用时直接发送更改。客户永远不必问。服务器仅在可用时发送数据。

对于任何类型的服务器启动数据，这在带宽方面比 http 轮询更有效。除了为您提供更及时的结果(结果会立即交付，而不是仅在下一个轮询间隔由客户端发现)。

对于纯带宽使用，细节将取决于具体情况。 http 轮询请求必须建立 TCP 连接并确认该连接(如果是 SSL 连接，则需要更多数据)，然后它必须发送 http 请求，包括属于该主机的任何相关 cookie，包括相关 header 和获取网址。然后，服务器必须发送响应。而且，在大多数情况下，所有这些轮询开销都将完全浪费带宽，因为没有什么新内容要报告。

webSocket 从一个简单的 http 请求开始，然后将协议(protocol)升级为 webSocket 协议(protocol)。 webSocket 连接本身根本不需要发送任何数据，直到服务器有东西要发送给客户端，在这种情况下，服务器只发送数据包。发送数据本身的开销也少得多。没有cookies，没有标题等……只有数据。即使您在 webSocket 上使用了一些保持事件状态，与 HTTP 请求的开销相比，该数据量也非常小。

因此，您将节省多少带宽取决于具体情况。如果它需要 50 个轮询请求才能找到任何有用的数据，那么与 webSocket 场景相比，这些 http 请求中的每一个都是完全浪费的。带宽的差异可能是巨大的。

您询问了只需要定期检查的应用程序。一旦您进行了定期检查而没有检索到任何数据，这就是浪费带宽。这就是 webSocket 的全部想法。当没有数据要发送时，您不消耗带宽(或接近不消耗带宽)。