在哪一点上 WebSockets 的效率低于轮询? [英] At what point are WebSockets less efficient than Polling?

查看:28
本文介绍了在哪一点上 WebSockets 的效率低于轮询?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

While I understand that the answer to the above question is somewhat determined by your application's architecture, I'm interested mostly in very simple scenarios.

从本质上讲,如果我的应用每 5 秒或每分钟 ping 一次更改,大约什么时候发送以维持打开的 Web 套接字连接的数据最终会超过您通过简单轮询浪费的数量?

Essentially, if my app is pinging every 5 seconds for changes, or every minute, around when will the data being sent to maintain the open Web Sockets connection end up being more than the amount you would waste by simple polling?

基本上,我感兴趣的是,如果应用程序不一定需要实时更新,而只需要定期检查,是否有一种方法可以量化使用 Meteor 等框架所导致的低效率.

Basically, I'm interested in if there's a way of quantifying how much inefficiency you incur by using frameworks like Meteor if an application doesn't necessarily need real-time updates, but only periodic checks.

请注意,我在这里的重点是带宽利用率,不一定是数据库访问时间,因为 Meteor 等框架具有高度优化的方法,仅请求更新数据库.

Note that my focus here is on bandwidth utilization, not necessarily database access times, since frameworks like Meteor have highly optimized methods of requesting only updates to the database.

推荐答案

websocket 连接的全部意义在于,您无需 ping 应用程序进行更改.相反,客户端只连接一次,然后服务器可以在客户端更改可用时直接发送它们.客户永远不必问.服务器只在数据可用时发送数据.

The whole point of a websocket connection is that you don't ever have to ping the app for changes. Instead, the client just connects once and then the server can just directly send the client changes whenever they are available. The client never has to ask. The server just sends data when it's available.

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

For any type of server-initiated-data, this is way more efficient with bandwidth than http polling. Besides giving you much more timely results (the results are delivered immediately rather than discovered by the client only on the next polling interval).

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

For pure bandwidth usage, the details would depend upon the exact circumstances. An http polling request has to set up a TCP connection and confirm that connection (even more data if its an SSL connection), then it has to send the http request, including any relevant cookies that belong to that host and including relevant headers and the GET URL. Then, the server has to send a response. And, most of the time all of this overhead of polling will be completely wasted bandwidth because there's nothing new to report.

一个 webSocket 以一个简单的 http 请求开始,然后将协议升级为 webSocket 协议.webSocket 连接本身根本不需要发送任何数据,直到服务器有东西要发送给客户端,在这种情况下,服务器只发送数据包.发送数据本身的开销也少得多.没有 cookie,没有标题等……只有数据.即使您在 webSocket 上使用了一些 keep-alives,与 HTTP 请求的开销相比,这个数据量也非常小.

A webSocket starts with a simple http request, then upgrades the protocol to the webSocket protocol. The webSocket connection itself need not send any data at all until the server has something to send to the client in which case the server just sends the packet. Sending the data itself has far less overhead too. There are no cookies, no headers, etc... just the data. Even if you use some keep-alives on the webSocket, that amount of data is incredibly tiny compared to the overhead of an HTTP request.

因此,您可以节省多少带宽取决于具体情况.如果在找到任何有用数据之前需要 50 个轮询请求,那么与 webSocket 场景相比,这些 http 请求中的每一个都完全浪费了.带宽差异可能很大.

So, how exactly much you would save in bandwidth depends upon the details of the circumstances. If it takes 50 polling requests before it finds any useful data, then every one of those http requests is entirely wasted compared to the webSocket scenario. The difference in bandwidth could be enormous.

您询问了一个只需要定期检查的应用程序.一旦定期检查导致没有检索到数据,就会浪费带宽.这就是 webSocket 的全部思想.当没有数据要发送时,您不消耗带宽(或几乎不消耗带宽).

You asked about an application that only needs periodic checks. As soon as you have a periodic check that results in no data being retrieved, that's wasted bandwidth. That's the whole idea of a webSocket. You consume no bandwidth (or close to no bandwidth) when there's no data to send.

这篇关于在哪一点上 WebSockets 的效率低于轮询?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆