前端通讯协议：WebSocket 和长轮询

前面写过文章来对比 WebSockets 和 HTTP ，本文来简单对比 WebSockets 和长轮询。

长轮询概述

1995 年，网景通信聘请 Brendan Eich 在网景 Navigator 中实现脚本编写能力，在十天的时间里，JavaScript 语言诞生了。与现代 JavaScript 相比，它作为一种语言的能力最初非常有限，它与浏览器的文档对象模型（DOM）交互的能力很有限。JavaScript 主要用于提供有限的增强以丰富文档使用功能。例如，浏览器内表单验证和在现有文档中轻量插入动态 HTML。

随着浏览器大战的升温，微软的 Internet Explorer 达到了第 4 版甚至更高版本，对最强大特性集的争夺导致微软引入了最终成为 XMLHttpRequest 的东西。十多年来，所有浏览器都普遍支持这一功能。

长轮询实际上是原始轮询技术的一种更有效的形式，向服务器发出重复请求会浪费资源，因为必须建立每个新的传入连接，必须解析 HTTP 头，必须执行对新数据的查询，并且必须生成和交付响应（通常不提供新数据）。然后必须关闭连接并清除所有资源，而不必为每个客户端多次重复这个过程直到新数据对于一个给定的客户端可用。长轮询是一种技术，其中服务器选择尽可能长时间地保持客户端的连接打开，仅在数据变为可用后才传递响应可用或达到超时阈值。

优点

长轮询是在 XMLHttpRequest 的后面实现的，XMLHttpRequest 几乎得到了设备的普遍支持，因此通常不需要支持进一步的后备层。但是，在必须处理异常的情况下，或者可以查询服务器以获取新数据但不支持长轮询（更不用说其他更现代的技术标准）的情况下，基本轮询有时仍然具有有限的用途，并且可以使用 XMLHttpRequest 或通过简单的 HTML 脚本标签通过 JSONP。

缺点

长轮询在服务器上要密集得多。可靠的消息排序可能是长轮询的一个问题，因为来自同一客户端的多个 HTTP 请求可能同时进行。例如，如果客户端打开两个浏览器选项卡使用相同的服务器资源，并且客户端应用程序将数据持久化到本地存储（如 localStorage 或 IndexedDb），则没有内置保证不会重复数据写了不止一次。

根据服务器的实现，一个客户端实例对消息接收的确认也可能导致另一个客户端实例根本没有收到预期的消息，因为服务器可能错误地认为客户端已经收到了它预期的数据。

开源解决方案

大多数库都不会独立于其他传输来实现长轮询，因为一般来说，长轮询通常伴随着其他传输策略，作为后备或当长轮询不起作用时将这些传输作为后备。在 2018 年及以后，独立的长轮询库尤其不常见，因为面对对更现代的替代方案的广泛支持，这种技术正迅速失去相关性。下面是几种不同语言的长轮询开源库：

• go：golongpoll
  

• PHP：php-long-polling
  

• Node.js：Pollymer
  

• Python：simple COMET server
  

WebSocket 概述

大约在 2008 年年中，开发人员 Michael Carter 和 Ian Hickson 尤其敏锐地感受到了在实现任何真正强大的东西时使用 Comet 的痛苦和局限性。通过在 IRC 和 W3C 邮件列表上的合作，他们制定了一项计划，为网络上的现代实时双向通信引入新标准，因此创造了 WebSocket 这个名称。

这个想法进入了 W3C HTML 草案标准，不久之后，Michael Carter 写了一篇文章，将 Comet 社区介绍给 WebSockets。2010 年，Google Chrome 4 是第一个全面支持 WebSockets 的浏览器，其他浏览器供应商在接下来的几年里也纷纷效仿。2011 年，RFC 6455（WebSocket 协议）发布到 IETF 网站。

简而言之，WebSockets 是一个建立在设备 TCP/IP 堆栈之上的薄传输层。其目的是为 Web 应用程序开发人员提供本质上尽可能接近原始的 TCP 通信层，同时添加一些抽象以消除某些可能存在的与 Web 工作方式有关的摩擦。它们还迎合了这样一个事实，即网络具有额外的安全考虑因素，必须考虑这些因素以保护消费者和服务提供商。

优点

WebSocket 是一种事件驱动的协议，这意味着可以将其用于真正的实时通信。与 HTTP 不同（必须不断地请求更新），而使用 websockets，更新在可用时就会立即发送。

WebSockets 保持单个持久连接打开，同时消除基于 HTTP 请求/响应的方法出现的延迟问题。

WebSockets 通常不使用 XMLHttpRequest，因此，每次需要从服务器获取更多信息时，都不会发送标头。这反过来又减少了发送到服务器的数据负载。

缺点

当连接终止时，WebSockets 不会自动恢复，这是应用开发中需要自己实现的机制，也是存在许多客户端开源库的原因之一。

早于 2011 年的浏览器无法支持 WebSocket 连接，这个现在可以忽略不计。

开源解决方案

在之前的文章中有很详细的介绍，如有兴趣可以参阅《深入学习WebSockets概念和实践》。

为什么 WebSocket 协议是更好的选择

通常，WebSockets 将是更好的选择。

长轮询在服务器上占用的资源要多得多，而 WebSockets 在服务器上的占用空间非常小。长轮询还需要在服务器和设备之间进行多次跳跃。并且这些网关通常对允许典型连接保持打开状态的时间有不同的看法。如果它保持打开时间太长，某些东西可能会杀死它，甚至在它正在做一些重要的事情时也是如此。

为什么你应该使用 WebSockets 构建：

• 全双工异步消息传递，换句话说，客户端和服务器都可以独立地相互传输消息。

• WebSockets 无需任何重新配置即可通过大多数防火墙。

• 良好的安全模型（基于来源的安全模型）。