在什么情况下，AJAX长/短轮询优先于HTML5 WebSockets？

Question

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

目前，我正在使用简单的AJAX实现此功能，但这样做的缺点是在短时间计时器过后会定期点击服务器。

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

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

Answer 1

WebSockets绝对是未来。

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

WebRTC允许对等通信。

我建议学习WebSockets。

比较

网上不同的沟通技巧

• AJAX - request→response。创建与服务器的连接，发送带有可选数据的请求标头，从服务器获取响应，以及关闭连接。 在所有主流浏览器中都受支持。

• 漫长投票 - request→wait→response。像AJAX一样创建与服务器的连接，但保持keep-alive连接打开一段时间（不长）。在连接期间，打开的客户端可以从服务器接收数据。由于超时或数据eof，客户端必须在连接关闭后定期重新连接。在服务器端，它仍被视为HTTP请求，与AJAX相同，除了请求的答案现在或将来某个时间由应用程序逻辑定义。 support chart (full) | wikipedia

• WebSockets - client↔server。创建与服务器的TCP连接，并根据需要保持打开状态。服务器或客户端可以轻松关闭连接。客户端经历HTTP兼容的握手过程。如果成功，则服务器和客户端可以随时在两个方向上交换数据。如果应用程序需要以两种方式频繁进行数据交换，则效率很高。 WebSockets确实有数据框架，包括屏蔽从客户端发送到服务器的每条消息，因此数据只是加密。 support chart (very good) | wikipedia

• WebRTC - peer↔peer。传输以在客户端之间建立通信并且与传输无关，因此它可以使用UDP，TCP甚至更抽象的层。这通常用于高容量数据传输，例如视频/音频流传输，其中可靠性是次要的，并且可以牺牲几帧或质量进展的降低以支持响应时间，并且至少有一些数据传输。双方（同行）可以独立地将数据推送到彼此。虽然它可以完全独立于任何集中式服务器使用，但它仍然需要某种方式来交换endPoints数据，在大多数情况下，开发人员仍然使用集中式服务器来“链接”对等体。这仅需要交换用于建立连接的基本数据，之后不需要集中式服务器。 support chart (medium) | wikipedia

• 服务器发送的事件 - client←server。客户端建立与服务器的持久和长期连接。只有服务器才能将数据发送到客户端。如果客户端想要将数据发送到服务器，则需要使用其他技术/协议来执行此操作。该协议与HTTP兼容，并且在大多数服务器端平台上易于实现。这是一种优选的协议，用于代替长轮询。 support chart (good, except IE) | wikipedia

优点：

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

安全注意事项

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

P.S。

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

Answer 2

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

Answer 3

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

Answer 4

• XHR轮询：事件发生时（可能是立即发生，也可能有延迟），将答复请求。需要发出后续请求才能接收其他事件。

    

  浏览器向服务器发出异步请求，   可能会等待数据可用后再进行响应。的   响应可以包含编码数据（通常为XML或JSON）或   客户端要执行的Javascript。在处理结束时   响应的结果，浏览器创建并发送另一个XHR，以等待   下一个事件。因此，浏览器始终保持未解决的请求   与服务器一起使用，以便在每个事件发生时得到答复。 Wikipedia

• 服务器发送事件客户端向服务器发送请求。服务器可以随时将新数据发送到网页。

    

  传统上，网页必须向服务器发送请求到   接收新数据；也就是说，页面从服务器请求数据。   通过服务器发送的事件，服务器可以发送新数据   通过将消息推送到网页可以随时访问网页。这些   传入消息可被视为网页内的事件+数据。 Mozilla

• WebSockets （在首次握手后）（通过HTTP协议）。使用WebSocket协议双向进行通信。

    

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