实时 Web 应用程序的短轮询与长轮询？答案

【问题标题】：Short-polling vs Long-polling for real time web applications?实时 Web 应用程序的短轮询与长轮询？
【发布时间】：2011-06-06 06:27:38
【问题描述】：

我正在构建一个实时 Web 应用程序据我所知，最流行的选择是短轮询和长轮询。衡量一个比另一个有什么优点和缺点？

【问题讨论】：

@metrobalderas 长轮询在这里，只是不像 websockets。您仍然可以使用 iframe/script/xhr 并阻止服务器关闭连接。
对于其他研究这个主题的人，这里是关于short-polling vs long-polling主题的另一个问题。

标签： javascript http comet real-time long-polling

【解决方案1】：

只是为了争论。

两者都是http请求（xhr），它至少部分不真实它使用更多的服务器资源（完全取决于技术，稍后会解释）。

短轮询。

大量请求在服务器上进行处理。产生大量流量（使用资源，但在返回响应后立即释放它们）：

00:00:00 C-> Is the cake ready? 
00:00:01 S-> No, wait.
00:00:01 C-> Is the cake ready?
00:00:02 S-> No, wait.
00:00:02 C-> Is the cake ready? 
00:00:03 S-> Yes. Have some lad.
00:00:03 C-> Is the other cake ready? ..

长轮询

一个请求发送到服务器，而客户端正在等待响应的到来（未解决）。如果使用 php/apache 的服务器，则意味着要处理的衍生线程，该线程保留资源，直到完成。因此流量较小，但您会快速消耗资源（或者更确切地说，您会阻塞资源）。但是，如果您使用例如 Node（或任何其他异步方法 - 例如 c++ qt），您可能会大大减少资源使用量（存储 http 请求的响应对象并在工作准备好时使用它）

12:00 00:00:00 C-> Is the cake ready? 
12:00 00:00:03 S-> Yes.Have some lad.
12:00 00:00:03 C-> Is the cake ready?

如果您将其与短轮询进行比较，您会发现在短轮询中您可能使用了更多传输，但在这 3 秒内您实际上需要 1.5 秒的处理时间（意味着在您的调用之间可能会执行某些操作）。如果进行长轮询，则始终使用相同的资源。现在通常所有库的 php 都以 4MB 内存开始 - 然后你有一个 4-20MB 的框架。假设您有 1024MB RAM 可用（免费）。假设让我们悲观一点，假设每个 php 实例将使用 25 MB。这意味着您最多只能获得 40 个长轮询连接脚本。

这正是您可以使用 Node 提供更多服务的原因，因为节点不会产生它的实例（除非您想使用 worker 等），因此使用相同的内存，您可能很容易挂起 10k 连接。当它们到来时，你会在 CPU 中获得一个峰值，当它们可能被释放时，但是当它们空闲时就像它们不存在一样（你只需为你将保留在 node/c++ 中的内存结构付费）。

网络套接字

现在，如果您想发送一些东西，无论它们是在客户端还是客户端，都可以使用 websockets（ws 协议）。第一次调用是http请求的大小，但后来你只发送消息，从客户端到服务器（新问题）和服务器到客户端（答案或推送 - 甚至可以为所有连接的客户端进行广播）。有 php websocekts 库，但同样，请使用一些不同的技术 - 最好使用 node 或 c++。

一些库，比如 socket.io 有自己的层次结构，所以当 websocket 失败时，它会回到长轮询或短轮询。

何时使用。

短轮询 - 好吧，永远不要^^。

长轮询 - 当您与服务器交换单个呼叫时，服务器可能正在后台做一些工作。此外，当您不再在同一页面上查询服务器时。此外，当您不使用 php 作为层来处理长轮询连接时（node/c++ 可以是一个简单的中间层）。请注意，长轮询确实很有用，但只有当你这样做时。

Websocket - 您可能会与服务器交换超过一到两个呼叫，或者某些东西可能来自您不期望/未询问的服务器，例如电子邮件通知或其他东西。您应该根据功能计划不同的“房间”。拥抱 javascript 的基于事件的特性；]

【讨论】：

那么本质上，长轮询是一个可以异步打开socket的持久连接，而短轮询通常是一个同步进程的永久请求？
它本身不是持久的 - 它是你没有从服务器发送响应等待等待 - 并且一旦你关闭它 - 换句话说它正在等待（挂起）。使用一些长的 cron 脚本会得到相同的行为 - 在 10 分钟后准备好浏览器时只会发送内容。原理是一样的——只是用法会改变。所以它非常同步。这也给您带来了我没有提到的长轮询的第二个问题 - 浏览器对打开连接数的限制（我认为现在大约 8 个 - 浏览器中的 websocket 连接 atm 没有限制）。
长轮询的另一个严重限制是会话锁定，除非您关闭会话或使用非阻塞会话管理器（如 db），否则用户的会话文件将被锁定并且不会接受请求来自用户甚至来自不同的浏览器窗口。
短轮询有它的位置，例如在仪表板应用程序中，由于批处理 UI 更新的架构和 UX 优势。
哪个最容易扩展？

【解决方案2】：

短轮询（又名基于 AJAX 的计时器）：

优点：更简单，不消耗服务器（如果请求之间的时间很长）。
缺点：如果您需要在服务器事件毫不延迟地发生时收到通知，那就不好了。 Example（基于ItsNat）
长轮询（又名基于 XHR 的 Comet）

优点：当服务器事件立即发生时，您会收到通知。缺点：更复杂，使用的服务器资源更多。 Example（基于ItsNat）

【讨论】：

特别是对于长轮询，主要限制服务器资源是打开套接字的最大数量。不同的操作系统有不同的限制，但有限制，限制远低于可用内存。短轮询解决了这个问题，因为每个连接只在很短的时间内打开，因此可以对许多连接进行时间复用。
长轮询并没有使用更多的资源，实际上它使用的资源要少得多。空闲套接字连接基本上不使用除了保持活动数据包（如果启用/配置）和打开文件描述符之外的任何资源。
不再提供示例。

【解决方案3】：

如果您想获得基于数据库的实时应用程序，您可以使用 ajax 长轮询和彗星组合。 Long poll 对您的带宽非常有用，对用户 MB 也非常有用。因为当用户发送请求时，用户会像 MB 或某种互联网连接一样为它付费。例如对于 短轮询 当您执行每秒发送请求等操作时，用户互联网使用量会更多，因为每个连接用户都会为此付费（这意味着用户松动 Mb），但在长轮询中，用户只需为新消息付费.

Websocket确实是个好东西，但是当你使用它时你应该考虑一个大问题，很多人不能使用聊天系统，因为Websocket只是针对新版本的浏览器

【讨论】：

很多人应该更新他们的浏览器... IE11 已经支持 Websockets。微软正在推动所有人进入 Windows 10，这意味着默认情况下是 Edge。除非你使用的是 Opera Mini，但那是你的错：P
这就是为什么你应该使用像 socket.io 这样的东西来在 websockets 不可用时为你处理这个问题；] 但代码库保持不变
@sp3c1 Socket.io 是可扩展性的噩梦。
@Hobbyist 怎么样？你可以负载均衡，现在你也可以在不同进程之间共享套接字。您总是可以退回到纯 websocket 实现，但核心保持不变。好吧，您可以自己进行套接字实现，但是当 webdev 是一个很好的标准时，为什么还要发明轮子呢？如果您在处理套接字连接的进程的分布式通信方面遇到问题，您可以随时探索 redis pub/sub。 socket.io 相对于 websocket 的真正优势是回退协议，这使得它适用于旧浏览器。
@sp3c1 我很高兴听到这个消息，我可以在共享主机中使用 socket.io 吗？因为 websocket 也有缺点，比如它不适用于共享主机计划