栏目?：码农手记 ?

撰文✍?：极链科技开发工程师 桔子

编辑?：果果

关键词?： 轮询(polling) 、 WebSocket协议 、 Socket.io 、 MQTT协议 

✍️ 码农手记 

将会邀请

一直在幕后用代码和算法改变世界的技术大佬们将会不定期推送他们所写的在技术专业中的技术经验/研究/论文为你呈现/ 更前沿的技术思考 / / 更专业的技术干货 /#码农手记# 第69期文 | Video++极链科技开发工程师 桔子

在绝大多数Web项目中，展示代码与业务逻辑代码分别运行在前端(本篇仅讨论浏览器端)与服务器上。它们之间的数据难以保证实时一致。某些应用场景下，比如需要展示异步耗时操作结果，第三方处理结果，聊天对话信息等等，前端无法判断什么时候发送请求来获取这些信息。

1⃣️

过去的常见处理方案中，前端持续定时发出HTTP请求，称为轮询，其中又分为短轮询与长轮询。

短轮询：按一定频率发送请求，服务端立即响应，有新数据返回新数据，无数据返回默认响应。

长轮询：发送请求后保持连接，服务端有新数据时才响应。前端收到响应后立即再次连接。

这两种方案都非常消耗资源，HTTP协议的报头从几KB到几十KB不等，短轮询会造成过多流量无谓浪费在头信息的重复传输上。长轮询保持连接，更会占用服务器内存和网络端口。轮询方案的消耗与收益非常不对等，也很难应对较高的并发请求。

仔细思考发现，这些问题都来自HTTP协议的限制，它是无状态协议，只能由前端发起，一次请求只对应一次响应，并且有等待时长限制。

因此HTML5开始，Web标准中提供了允许持久连接和全双工通讯的WebSocket协议。

2⃣️

借助HTTP请求握手，建立TCP长连接，后续使用数据帧进行双向通讯。与轮询方式的区别如下：

WebSocket所指的长连接与HTTP1.1的keep-alive含义不同：HTTP长连接只是在传输层保持连接，应用层中还是由客户端主动发起完整HTTP格式的请求，一次请求对应一次响应。

 # 一些关键头信息 

Connection: Upgrade：表示要升级协议。

Upgrade: websocket：表示要升级到WebSocket协议。

Sec-WebSocket-Version: 13：表示WebSocket协议版本。如果服务端不支持该版本，需要返回一个Sec-WebSocket-Versionheader，里面包含服务端支持的版本号。

Sec-WebSocket-Key：与后面服务端响应头的Sec-WebSocket-Accept匹配，提供基本防护。

WebSocket请求头：

WebSocket响应头：

WebSocket通信的最小单位是帧(frame)，一个或多个帧组成一条完整的消息。

数据帧结构如下：

各常用语言和框架都有WebSocket的实现库，大多同时提供了服务端与客户端的实现。因此除了与浏览器通讯，服务器间交互也可以视情况选用。

3⃣️

Socket.io是浏览器端比较流行的实时通讯库，基于engine.io实现了双向即时通信。除了WebSocket协议，它还包括轮询与长轮询、jsonp polling、iframe streaming 等大部分可实现事件推送的通信机制。实际使用中会根据运行环境及可配置项自动选择。

 # 它有以下主要特征 

• 可靠性：允许在负载均衡及防火墙环境下建立连接。为此采用先建立HTTP长轮询，再升级为WebSocket协议长连接的方式。它也能在不支持WebSocket的环境中自动降级为其他连接方式。

• 自动重连与断连检查：除非另有配置，否则断开连接的客户端将尝试永久重新连接，直到服务器再次可用为止。

• 不限数据形式的双向传输：支持二进制的payload，适用于所有可序列化的数据结构。

• 多路并行传输：使用namespace和room机制，在同一连接内创建相互隔离的通道或广播组。在不同功能模块或不同权限之间实现关注点分离。

由于Socket.io最终建立连接前需要一次或多次HTTP请求来建立匹配关系，所以在服务端做了负载均衡时，需要把各网关路由模式配置为iphash，保证同个客户端在协议切换期间分配到同个后端服务。

这是Socket.io独特实现方式的需求，原生WebSocket只需要网关配置支持 HTTP1.1 keep-alive即可。

Socket.io并非纯粹的Websocket实现，必须同时使用它的服务端与客户端SDK。在单独一端使用原生WebSocket库是无法连接成功的。

4⃣️

MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它比WebSocket更加轻量高效，兼容性更强。

 #它具有以下主要特性 

1.使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合；

2.对负载内容屏蔽的消息传输；

3.使用 TCP/IP 提供网络连接；

4.有三种消息发布服务质量(Qos)：

• “至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。

• “至少一次”，确保消息到达，但消息重复可能会发生。

• “只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。

5.小型传输，开销很小(固定长度的头部是 2 字节)，协议交换最小化，以节省网络流量；

6.使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。

MQTT的协议格式非常简约，使用尽量少的二进制位标识以节约资源：

协议格式的具体说明可参考文档 https://mcxiaoke.gitbooks.io/mqtt-cn/content/

MQTT协议中有三种身份：发布者(Publish)、代理(Broker)、订阅者(Subscribe)。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。

MQTT传输的消息分为主题(Topic)和负载(payload)两部分。Topic可以理解为消息的类型，订阅者订阅后，就会收到该主题的消息内容(payload)。

mosca/mqtt.js 是适用浏览器环境的一个mqtt实现，借用了WebSocket连接传输数据。MQTT包含一个允许在WebSocket连接上通信的子协议。

如果MQTT在WebSocket [RFC6455] 连接上传输，必须满足下面的条件：

• MQTT控制报文必须使用WebSocket二进制数据帧发送。如果收到任何其它类型的数据帧，接收者必须关闭网络连接 [MQTT-6.0.0-1]。

• 单个WebSocket数据帧可以包含多个或者部分MQTT报文。接收者不能假设MQTT控制报文按WebSocket帧边界对齐 [MQTT-6.0.0-2]。

• 客户端必须将字符串 mqtt 包含在它提供的WebSocket子协议列表里 [MQTT-6.0.0-3]。

• 服务端选择和返回的WebSocket子协议名必须是 mqtt [MQTT-6.0.0-4] 。

• 用于连接客户端和服务器的WebSocket URI对MQTT协议没有任何影响。

使用浏览器的开发工具，分别使用Socket.io与mqtt.js连接，查看连接过程与传输详情，可以看到Socket.io的握手过程，以及与MQTT协议数据帧的差异。

Socket.io:

数据帧：

MQTT：

数据帧：

# 综合以上方案 

从便利角度考虑，直接使用原生HTTP轮询方案或同属HTML5的SSE方案，无需引入多余的包，适合快速上线。

Socket.io作为比较流行的第三方库，兼容浏览器差异，针对不同场景提供统一解决方案，适合快速开发也适合生产环境长期使用，可作为WebSocket协议的浏览器替代方案。

MQTT具有较高兼容性、开放性和执行性能，除了借助WebSocket支持浏览器，在移动端推送以及物联网设备中也有广泛应用，对于多客户端高并发型项目以及熟悉网络协议的开发者强烈推荐。

如果以上都不能满足业务需要，参考各方案特性，基于TCP/UDP定制私有协议或许是大型复杂项目的最终选择。

*参考文章链接：

https://datatracker.ietf.org/doc/rfc6455

http://www.websocket.org/echo.html

https://socket.io/

https://github.com/mcxiaoke/mqtt

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

?

 极链科技Video++  聚焦于视频互联网的AI科技公司 

??点击「阅读原文」查看更多深度技术好文