实时 Web 应用程序的短轮询与长轮询？
我正在构建一个实时 Web 应用程序 据我所知，最流行的选择是短轮询和长轮询。衡量其中一种相对于另一种可能有哪些优点和缺点？
I'm building a real-time web application As far as I know, the most popular choices are short-polling and long-polling. What are the advantages and disadvantages might there be for measuring one over the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只是为了论证。
两者都是http请求（xhr），并且它至少部分不真实，它使用了更多的服务器资源（完全取决于技术，稍后将解释）。
短轮询。
许多请求在到达服务器时就被处理。创建大量流量（使用资源，但在响应发回后立即释放它们）：
长轮询
一个请求发送到服务器，客户端正在等待响应到来（未解析）。如果使用 php/apache 的服务器，则意味着需要生成一个线程来处理、保留资源，直到完成为止。因此流量较小，但您很快就会耗尽资源（或者更确切地说，您会阻塞资源）。但是，如果您使用 Node（或任何其他异步方法 - 例如 c++ qt），您可以最大限度地减少资源使用（存储 http 请求的响应对象并在工作准备好时使用它）
如果您将其与短轮询，您会发现在短轮询中您可能使用了更多传输，但在这 3 秒内，您实际上花费了 1,5 秒的处理时间（意味着在调用之间可能会执行某些操作）。如果进行长轮询，则始终使用相同的资源。现在，通常 php 的所有库都以 4MB 内存开始 - 那么你就有一个 4-20MB 的框架。假设您有 1024MB RAM 可用（免费）。让我们悲观一点，假设每个 php 实例将使用 25 MB。这意味着您最多只能获取 40 个长轮询连接脚本。
这正是为什么您可以使用 Node 提供更多服务的原因，因为 Node 不会生成其实例（除非您想使用工作线程等），因此使用相同的内存，您可能可以轻松挂起 10k 连接。当它们到来时，以及当它们可能被释放时，您会得到 CPU 峰值，但当它们空闲时，就像它们不存在一样（您只需为要保留在 Node/C++ 中的内存结构付费）。
Websocket
现在，如果您想发送一些东西，无论它们何时进出客户端，请选择 websockets（ws 协议）。第一次调用是http请求的大小，但后来你只发送消息，从客户端到服务器（新问题）和服务器到客户端（答案或推送 - 甚至可以为所有连接的客户端进行广播）。有 php websocekts 库，但同样，使用一些不同的技术 - 最好是节点或 c++。
有些库（例如 socket.io）有自己的层次结构，因此当 websocket 失败时，它会返回到长轮询或短轮询。
何时使用。
短轮询 - 好吧，从来没有^^。
长轮询 - 可能是当您与服务器交换单个呼叫并且服务器正在后台执行某些工作时。此外，当您不再在同一页面上查询服务器时。此外，当您不使用 php 作为层来处理长轮询连接时（node/c++ 可以是简单的中间层）。请注意，长轮询确实非常有益，但前提是您这样做。
Websocket - 您可能会与服务器交换一到两个以上的调用，或者服务器可能会发出您没有预料到/询问的内容，例如电子邮件通知或其他内容。您应该根据功能规划不同的“房间”。拥抱 javascript 基于事件的本质；]
Just for the sake of argument.
Both are http request (xhr), and its at least partially untrue it uses more server resources (depends totally on technology, will explain later).
Short polling.
Lot of request that are processed as they come on server. Creates a lot of traffic (uses resources, but frees them as soon as response is send back):
Long polling
One request goes to server and client is waiting for the response to come (its unresolved). In case of Server with php/apache would mean a spawned thread to handle, that reserve resources, till its done. So the traffic is smaller, but you eat up your resources fast (or rather you block resources). But if you use for example Node (or any other async approach - c++ qt for example), you can potentially minimize the resource usage a lot (store response object for http request and use it when the work is ready)
If you compare that to short polling, you will see that potentially in short poll you used more transfer, but during those 3s you actually take 1,5s of processing time (means something could execute in between your calls). In case for long poll the same resources were used all the time. Now usually php with all libs starts with 4MB memory - then you have a framework 4-20MB. Assume you have 1024MB RAM available (free). Say lets be pessimistic and assume that you will use 25 MB per one php instace. It means you can get only as much as 40 long polled connection scripts.
Its precisely the reason why you could serve potentially a lot more with Node, as node would not spawn its instances (unless you want to use workers etc), so with same memory you could probably get easily to 10k connections hanging. You would get a spike in the CPU as they will come, and when they will potentially be released, but when they are idle its like they are not there (you pay only for the memory structures you would keep in node/c++).
Websocket
Now if you want to send few things, whenever they are in or out of client, go for the websockets (ws protocol). First call is size of http request, but later you send just the messages, from the client to server (new questions) and server to client(answers or pushes - can even do broadcast for all connected clients). There are php websocekts libs but again, use some different technology - node or c++ preferably.
Some libs, like socket.io have a hierarchy of its own, so when websocket fails, it goes back to long or short polling.
When to use.
Short polling - well, never ^^.
Long polling - potentially when you are exchanging single call with server, and server is doing some work in background. Also when you won't query server on the same page anymore. Also when you are not using php as layer to handle the long polled connection (node/c++ can be a simple middle layer). Note long polling can be really beneficial, but only when you make it so.
Websocket - you potentially will exchange more then one or two calls with server, or something might come from server you did not expected / asked, like notification of email or something. You should plan different "rooms", depend on functionalities. Embrace the event based nature of javascript ;]
短轮询（又名基于 AJAX 的计时器）：
优点：更简单，不消耗服务器（如果请求之间的时间很长）。
缺点：如果您需要在服务器事件立即发生时收到通知，那就不好了。
示例 （基于 ItsNat）
长轮询（又名基于 XHR 的 Comet）
优点：当服务器事件发生时，您会立即收到通知。
缺点：更复杂并且使用更多的服务器资源。
示例 （基于ItsNat）
Short polling (a.k.a. AJAX based timer):
Pros: simpler, not server consuming (if the time between requests is long).
Cons: bad if you need to be notified WHEN the server event happens with no delay.
Example (ItsNat based)
Long polling (a.k.a. Comet based on XHR)
Pros: you are notified WHEN the server event happens with no delay.
Cons: more complex and more server resources used.
Example (ItsNat based)
如果你想获得基于数据库的实时应用程序，你可以使用ajax长轮询和comet组合。
长轮询对您的带宽确实有好处，而且对用户 MB 也非常有用。因为当用户发送请求时，用户将为其付费，例如 MB 或某种互联网连接。例如 短轮询当您执行每秒发送请求之类的操作时，用户互联网使用量会更多，因为每个连接用户都会为此付费（这意味着用户会释放 Mb），但在长轮询中，用户只需为新消息付费。
If you want to get real time application based on database you can use ajax long poll and comet combination.
Long poll is really good for your bandwith and also it is really useful for user MB.Because when user send request user will pay for it like MB or some kind of internet connection.For example for Short poll when you do something like sending request per second user internet usage will be more because each connection user will pay for it(It means that user loose Mb )but in the long polling user only will pay just for new messages.