如何在两者之间做出选择？
有时我们需要服务器提供的信息。我们习惯的通常的AJAX请求/响应不会为这种情形保持连接处于打开状态。相反，我们需要基于推送的方法，比如WebSockets，长轮询，服务器发送事件以及最近的HTTP2推送。本文中，我们比较了两种方法：WebSockets与长轮询。
长轮询概述
1995年，Netscape Communications聘请Brendan Eich在Netscape Navigator中实现脚本功能，在十天的时间里，JavaScript语言诞生了。与现代JavaScript相比，它作为一种语言的功能最初非常有限，并且它与DOM交互的能力更加有限。JavaScript主要用于提供有限的增强功能来丰富文档功能。例如，浏览器内表单验证和动态HTML轻量级插入现有文档。
随着浏览器战争升温，微软的Internet Explorer达到4以及更高版本，对最强大功能集的争夺导致微软推出了最终成为XMLHttpRequest的东西。十多年来，所有浏览器都普遍支持这一点。
长轮询本质上是原始轮询技术的一种更有效的形式。向服务器发出重复请求会浪费资源，因为必须建立每个新的传入连接，必须解析HTTP标题，并且生成响应（通常不提供数据），交付。然后必须关闭连接并清除所有资源。在给定客户端的新数据变得可用之前，不必为每个客户端多次重复此过程，长轮询是一种技术，服务器选择尽可能长时间的保持客户端连接打开，仅在数据可用或者达到超时阈值之后才提供响应。
WebSockets概述
在2008年中期，开发人员Michael Carter和Ian Hickson特别敏锐的感受到Comet在实现任何真正强大的东西时所带来的的苦恼和局限。通过on IRC和W3C邮件列表的合作，他们制定了一项计划，在网上引入现代实时双向通信的新标准，因此创造了WebSocket这个名称。
这个想法进入了W3C HTML草案标准，不久之后，Michael Carter写了一篇文章，将Comet社区介绍给WebSockets。2010年，Chrome4是第一个提供对WebSockets全面支持的浏览器，其他浏览器供应商也在接下来的几年中采用了这种方式。2011年，RFC 6455-WebSocket协议被发布到了IETF网站。
简而言之，WebSockets是一个构建在设备TCP/IP堆栈上的瘦传输层。目的是为Web应用程序开发人员提供基本上尽可能接近原始的TCP通信层，同时添加一些抽象，以消除与Web工作方式有关的某些摩擦。它们还满足了这样一个事实，即网络具有额外的安全考虑因素，必须将其考虑在内以保护消费者和服务供应商。
长轮询：优缺点
优点：
- 长轮询是在XMLHttpRequest的基础上实现的，它几乎得到了设备的普遍支持，因此通常很少需要支持回退层。如果必须处理异常，或者可以查询服务器获取新数据，但是不支持长轮询（更不用说其它更现代的技术标准），基本轮询有时依然存在限制，并且可以使用XMLHttpRequest，或通过简单的HTML脚本标记通过JSONP实现。
缺点：
- 可靠的消息排序可能是长轮询的问题，因为来自同一客户端的多个HTTP请求可能同时进行。例如，如果客户端有两个浏览器选项卡打开消耗相同的服务器资源，并且客户端应用程序将数据持久保存到本地存储（如localStorage或IndexedDb）,则没有内置保证重复数据不会多次写入。
- 取决于服务器的实现方式，一个客户端实例确认消息接收也会导致另一个客户端实例永远不会收到预期消息，因为服务器可能地认为客户端已经收到了它期望的数据。
WebSockets:优缺点
优点：
- WebSockets保持独特的连接打开，同时消除长轮询引起的延迟问题。
- WebSockets通常不使用XMLHttpRequest,因此，每次我们需要从服务器获取更多信息时，不会发送标头。反过来，减少了发送到服务器的昂贵数据负载。
缺点：
- 连接终止时WebSockets不会自动回复-这是您需要自己实现的，并且这是存在许多客户端库的原因之一。
- 2011年前的浏览器无法支持WebSocket连接，但这种相关性越来越低。
为什么WebSocket协议是更好的选择
通常，WebSockets是更好的选择。
长轮询在服务器上占用更多资源，而WebSockets在服务器上占用的空间非常轻量。长轮询还需要在服务器和设备之间多次跳转。这些网关通常对于特定连接保持打开的时间有不同的规定。如果保持打开时间过长，可能会关闭，甚至可能会在它做某些重要的事情时关闭。
