【问题标题】：In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?在什么情况下，AJAX 长/短轮询优于 HTML5 WebSockets？
【发布时间】：2012-04-19 04:52:15
【问题描述】：

我正在为朋友构建一个小型聊天应用程序，但不确定如何及时获取信息，而不是像强制刷新页面那样手动或初级。

目前，我正在使用简单的 AJAX 来实现这一点，但这有一个缺点，即在较短的计时器过去时会定期访问服务器。

在研究长/短轮询时，我遇到了 HTML5 WebSockets。这似乎很容易实现，但我不确定是否有一些隐藏的缺点。例如，我认为 WebSockets 仅被某些浏览器支持。我应该注意 WebSocket 的其他缺点吗？

既然两种技术似乎都做同样的事情，那么在哪种情况下，人们更愿意使用其中一种技术而不是另一种？更具体地说，HTML5 WebSockets 是否让 AJAX 长/短轮询过时了，还是有令人信服的理由更喜欢 AJAX 而不是 WebSockets？

【问题讨论】：

标签： javascript ajax html websocket network-protocols

【解决方案1】：

WebSockets ~~绝对是未来~~现在。

长轮询是一种肮脏的解决方法，可以防止像 AJAX 那样为每个请求创建连接 - 但是当 WebSocket 不存在时会创建长轮询。现在由于 WebSockets，长轮询不再是消失了。

WebRTC 允许点对点通信。

推荐学习WebSockets。

比较：

网络上不同的通信技术

AJAX - request → response。创建到服务器的连接，发送带有可选数据的请求标头，从服务器获取响应，然后关闭连接。 所有主流浏览器都支持。
长期投票 - request → wait → response。像 AJAX 一样创建到服务器的连接，但保持一个保持活动连接打开一段时间（虽然不长）。在连接过程中，开放的客户端可以从服务器接收数据。由于超时或数据 eof，客户端必须在连接关闭后定期重新连接。在服务器端，它仍然被视为 HTTP 请求，与 AJAX 相同，除了请求的答案将在现在或将来的某个时间发生，由应用程序逻辑定义。 support chart (full) | wikipedia
WebSockets - client ↔ server。创建到服务器的 TCP 连接，并根据需要保持打开状态。服务器或客户端可以轻松关闭连接。客户端通过 HTTP 兼容的握手过程。如果成功，那么服务器和客户端可以随时双向交换数据。如果应用程序需要以两种方式进行频繁的数据交换，那么它是有效的。 WebSockets 确实具有数据框架，包括对从客户端发送到服务器的每条消息进行屏蔽，因此数据被简单地加密。 support chart (very good) | wikipedia
WebRTC - peer ↔ peer。传输在客户端之间建立通信并且与传输无关，因此它可以使用 UDP、TCP 甚至更多抽象层。这通常用于大容量数据传输，例如视频/音频流，其中可靠性是次要的，可以牺牲几帧或质量进展的降低来换取响应时间，至少是一些数据传输。双方（对等方）可以独立相互推送数据。虽然它可以完全独立于任何集中式服务器使用，但它仍然需要某种方式来交换端点数据，在大多数情况下，开发人员仍然使用集中式服务器来“链接”对等点。这只需要交换基本数据以建立连接，之后不需要集中式服务器。 support chart (medium) | wikipedia
服务器发送事件 - client ← server。客户端与服务器建立持久和长期的连接。只有服务器可以向客户端发送数据。如果客户端想要向服务器发送数据，则需要使用另一种技术/协议来执行此操作。该协议与 HTTP 兼容，并且在大多数服务器端平台上易于实现。这是代替长轮询的更可取的协议。 support chart (good, except IE) | wikipedia

优点：

WebSockets 服务器端的主要优点是它不是 HTTP 请求（握手之后），而是一个适当的基于消息的通信协议。这使您能够获得巨大的性能和架构优势。例如，在 node.js 中，您可以为不同的套接字连接共享相同的内存，因此它们可以各自访问共享变量。因此，您不需要使用数据库作为中间的交换点（如使用 AJAX 或使用 PHP 等语言的 Long Polling）。您可以将数据存储在 RAM 中，甚至可以立即在套接字之间重新发布。

安全注意事项

人们经常关心 WebSocket 的安全性。现实情况是，它几乎没有什么区别，甚至将 WebSockets 作为更好的选择。首先，使用 AJAX，MITM 的可能性更高，因为每个请求都是一个新的 TCP 连接，它正在穿越互联网基础设施。使用 WebSockets，一旦连接，在两者之间进行拦截就更具挑战性，当数据从客户端流式传输到服务器时会额外强制执行帧屏蔽以及额外的压缩，这需要更多的努力来探测数据。 所有现代协议都支持：HTTP 和 HTTPS（加密）。

附言

请记住，WebSockets 通常具有非常不同的网络逻辑方法，更像是实时游戏一直以来的做法，而不是 http。

【讨论】：

这与它本身的兼容性无关。最重要的是，它即将全面重新思考沟通的方式。由于 RESTful API 使用 Request>Response 模式，因此这里的双向通信毫无意义。所以尝试使用 WebSockets 来查询 RESTful API - 是一个有点奇怪的尝试，而且根本看不到它的任何好处。如果您需要来自 RESTful API 的实时数据，那么您可以创建 WebSockets api 来推送可以与 WebSockets 等双向通信一起使用的数据。您正在尝试以无法比较的角度比较事物:)
嗨@pithhelmet 这一切都取决于它自己的服务器端软件（语言/技术）。 WebSocket 是 TCP 之上的层，有很多方法可以实现 TCP 流。现代 Web 服务器使用基于事件的架构，并且使用线程池非常高效。您正在使用哪种技术？ Node.js 使用幕后事件进行 IO，并在执行上下文中使用单线程事件，因此效率惊人。为每个连接使用线程 - 在 RAM（每个线程 1mb+）和 CPU 方面效率非常低，因为这些线程只会空闲或更糟 - 检查数据的无限循环。
长轮询不是一个肮脏的解决方法，它与 webSocket 不同。这两个旨在用于不同的场景。
@bagz_man 长轮询是一种“骇人听闻的”技术使用，以实现技术定义上不允许且没有标准替代方案可用的结果。长轮询存在的原因正是 WS 不存在的事实，期间。
@moka：Cloudflare 的 free-tier 将吸收持续的 400+Gbps 攻击。你的钱包能吸收 AWS 账单吗？在处理针对您的来源的投诉时，AWS 和 Cloudflare 也有相反的看法。只要我们在讨论权衡取舍，就需要牢记这一点。 :)

【解决方案2】：

XHR 轮询 请求在事件发生时得到响应（可以是立即响应，也可以是延迟之后）。需要发出后续请求才能接收更多事件。

浏览器向服务器发出异步请求，这可能会在响应之前等待数据可用。这响应可以包含编码数据（通常是 XML 或 JSON）或由客户端执行的 Javascript。在处理结束时在响应中，浏览器创建并发送另一个 XHR，等待下一个事件。因此浏览器始终保持未完成的请求与服务器一起，在每个事件发生时得到答复。 Wikipedia
服务器发送事件 客户端向服务器发送请求。服务器随时向网页发送新数据。

传统上，网页必须向服务器发送请求以接收新数据；即页面向服务器请求数据。使用服务器发送的事件，服务器可以发送新数据通过将消息推送到网页，随时访问网页。这些传入的消息可以被视为网页内的事件 + 数据。 Mozilla
WebSockets 在初始握手之后（通过 HTTP 协议）。使用 WebSocket 协议进行双向通信。

握手以 HTTP 请求/响应开始，允许服务器处理 HTTP 连接以及 WebSocket 连接同一个端口。建立连接后，通信切换到不符合 HTTP 的双向二进制协议协议。 Wikipedia

【讨论】：

【解决方案3】：

您忽略的一项竞争技术是服务器发送事件/事件源。 What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet? 对所有这些都进行了很好的讨论。请记住，其中一些比其他更容易在服务器端集成。

【讨论】：

在所有这些中，您建议研究哪一个？
我在长轮询方面取得了成功，唯一的技巧（对于它和其他技术）是不占用服务器线程。如果您不使用异步服务器代码，它将无法扩展。
@somdow Maksims-Mihejevs 在回答的前两段中很好地回答了您的问题。使用 websocket。

【解决方案4】：

对于聊天应用程序或任何其他与服务器持续对话的应用程序，WebSockets 是最佳选择。但是，您只能将WebSockets 与支持它们的服务器一起使用，因此如果您无法安装所需的库，则可能会限制您使用它们的能力。在这种情况下，您需要使用Long Polling 来获得类似的功能。

【讨论】：

每个服务器都支持WebSockets...您只需要安装node.js或类似的东西。
稍微调整以解释是的，任何服务器都将支持 WebSockets。但是，如果您使用托管服务，则可能无法使用它们。
我意识到这个线程有点老了，但是...... WebSockets 可能不是所有双向通信的最佳答案。我最近注意到 Spring 4 的 Web 套接字支持文档表明 WebSocket 更适合移动大量数据或低延迟。如果这些不适用或不是优先事项，那么我相信他们建议使用长轮询。我不知道这种观点的全部理由，我只是认为 Spring 的人知道他们在说什么。
@Stoney 除了您需要在服务器上设置 websocket（处理程序等）之外，根本没有理由在 websocket 上使用长轮询。 Websocket 速度更快（低延迟），并允许服务器与客户端“对话”而无需客户端请求。现在我使用 signalr（我认为 websocket 的最佳实现之一 - 它在客户端和服务器上运行，并允许客户端调用服务器上的方法和客户端上的服务器，就好像没有区别一样）在每个我制作的网站 - 动态内容加载、无底页面等
我在保持从 android mobile 到 nodejs socket.io 服务器的连接时遇到问题。