深入浅出即时通讯(1)_即时通讯协议对比

1. 即时通讯协议对比

业界上用来做即时通讯的解决方案有：1. 基于http 的轮询; 2. 基于websocket 长连接; 3. 基于tcp或udp的自定义协议, 这种若在要在Web端使用, 需要套一层websocket 封装. 此外早期还有基于Comet 技术的长连接，基于xmpp 的开源客户端应用等。

1.1 即时通讯协议比较

1.1.1 http短轮询/长轮询

一个http的请求有如下的特点:

连接必须由客户端发起, 服务端被动等待请求, 模式为请求-响应方式. 每次请求是无状态的，每次请求之间彼此独立. 一个http 请求包括 请求方法+请求资源地址+请求头部+请求体，见【图1.1.1 】，同理一个http 响应包括 相应头+响应头部+响应体, 见【图1.1.2 】

图1.1.1.png

图1.1.2.png

由于http连接必须由客户端发起的通讯特点，服务器要往客户推送消息，必须依赖由客户端发起的这条连接。因此在http的协议上做服务端的消息推送，需要客户端不断轮询，服务器有需要发送的消息时，就在轮询结果中返回给客户端。根据轮询类型的不同，又分为短轮询和长轮询。

http短轮询：

图1.1.3.png

短轮询的处理如下:

客户端请求服务器，服务器立即返回; 客户端间隔一段时间; 客户端请求服务器，服务器立即返回;

http长轮询:

图1.1.4.png

短轮询的处理如下:

客户端请求服务器，服务器若有数据，立即返回，否则阻塞等待; 客户端再次请求服务器，服务器若有数据，立即返回，否则阻塞等待;

总结: 不管是http短轮询或http长轮询，其吞吐量以及响应性都十分不尽人意，由于http的请求头和响应头的协议字段带来的流量损耗，以及服务器被动等待客户端建立的连接来推送消息带来延时，都注定http轮询的方式这种解决方案用在并发量吞吐量小，响应延时容忍度高这种场景。如果用作即时通讯这种专业化的软件不那么适合。

1.1.2 Websocket

WebSocket是一种在单个TCP连接上进行全双工通信的协议。WebSocket通信协议于2011年被IETF定为标准RFC 6455，并由RFC7936补充规范。WebSocket API也被W3C定为标准。

WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

WebSocket的定义包括:

WebSocket 是独立的、创建在 TCP 上的协议。 Websocket 通过HTTP/1.1 协议的101状态码进行握手。 为了创建Websocket连接，需要通过浏览器发出请求，之后服务器进行回应，这个过程通常称为“握手”（handshaking WebSocket的出现正是为解决服务器向客户端推送消息这个问题，在WebSocket出现之前，服务器向客户端推送消息，只能依赖客户端轮询，这会导致巨大的资源浪费。

1.1.3 XMPP

可扩展通讯和表示协议 (XMPP) 可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础，而Jabber是即时通讯中常用的开放式协议。

XMPP的出现背景是为了解决ICQ, MSN等桌面聊天应用消息协议互不相通的局面出现的。当"理想很好，现时很骨感", XMPP在现代越来越不被当做作主流的聊天协议来使用，甚至一些大厂逐渐弃用了XMPP, 原因有以下几点:

使用XML为载荷的XMPP消息体很大; XMPP的协议贪大求全，太过复杂，使用者门槛很高; 虽说XMPP是一个开放的协议，但实际上遵守协议的应用很少，更多是在此基础上的魔改;

因此XMPP的现状是虽然有一些历史的开源组件，开源应用支持快速上手，但因技术陈旧，没人维护等问题，导致二次开发，后期维护等都十分困难。

1.1.4 MQTT

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（Publish/Subscribe）模式的轻量级通讯协议，MQTT 最大的优点在于可以以极少的代码和有限的带宽，为远程设备提供实时可靠的消息服务。做为一种低开销、低带宽占用的即时通讯协议， MQTT 在物联网、小型设备、移动应用等方面有广泛的应用。

MQTT 的协议比较简单，是低开销、低带宽的物联网环境下发展起来。若要在Web的应用下使用，需要在Websocket之做一层协议封装。

1.1.5 socket.io

socket.io 是一个在客户端，服务器之间进行即时通讯的使用库，它提供一个低延时，双向的，基于事件的通讯模式.

socket.io 有如下的特点:

它是在Websocket之上构建的协议，它可以充分利用Websocket 低延时，消耗小的优势; 若客户端不支持Websocket协议，它会回退成使用HTTP 进行long-polling来实现; 它支持广播，分组，命名空间，连接管理等丰富的功能。

与MQTT相比，MQTT与socket.io都是基于发布/订阅（Publish/Subscribe）模式的，但与MQTT不同的是， socket.io 是基于Web应用发展起来的，它天然支持Web应用，它支持websocket 与 long-polling 等多种实现协议切换，它在处理一些浏览器兼容性的问题上更有优势.

与Websocket相比，socket.io 提供了更丰富的功能，它支持广播，分组，命名空间，连接管理等丰富的功能，而且，它提供了从客户端-服务端, 和服务器-客户端的双向确认机制，更有效的保证了即时聊天应用消息不遗漏。

1.1.6 基于tcp/udp自定义协议

一些大的企业拥有自己的专业开发团队，通常自己打造一套自己标准的通讯协议，一方面可以做到"闭源"，阻止竞争者窃取数据；一方面可以根据自身的业务情况，不端深入做优化。一般而言，不是专业做即时通讯的中小企业都很少打造自己的通讯协议。

1.2 即时通讯协议选型

在设计"E聊SDK"的过程中，笔者注意考虑了以下几点即时通讯的需求:

聊天方式支持单聊，群聊，消息类型支持文本，表情 ，图片，文件等; 首要支持移动端(android, ios, h5), Web端， 其次PC端等多个平台; 开发难度小，调试方便，要求API包文可视化; 适用于中小项目，支持同时在线: 1000,000 发消息QPS:100,000

经上述几种即时通讯协议的仔细比较，考虑到项目需求，最终笔者选择了socket.io + http 的方案。socket.io 的用途是作为服务器向客户端下发消息，而客户端向服务器请求API的方式仍选择传统的HTTP 方式，如图3，这样的好处有以下几点:

http 的开发方式与调试工具已十分成熟，像Chrome 的F12调试窗, curl 工具, java后端的servlet debug等都十分好用， 使用http 请求的方式方便开发人员开发，调试，大大提交业务开发效率; 服务器使用socket.io 的通道向客户端下发即时消息.当socket.io 连接起来后(底层使用websocket), 可以得益于websocket 全双工，低延时的优势。 socket.io 的基于订阅-发布模式，协议上自带连接管理，自动重连等功能, 接入使用简单，可以达到开箱即用，降低研发人员使用门槛； socket.io 诞生于Web环境，支持websocket, xhr-polling 多种底层实现方式，在传统Web, 现代h5 已得到良好的验证。移动互联网发展至今，开发原生应用因开发成本，推广费用等因素不再是"刚需"，对于原生应用的开发一般使用前端跨平台的开发框架来实现，如ReactNative, uniapp 等，基于此类流行的跨平台框架上，socket.io 也有对应的sdk，真正达到"一招通吃"。

1.3 本章总结

本章主要介绍了市面上可供即时通讯选型的多种技术方案，包括http, Websocket, xmpp, mqtt, socket.io 以及自定义的TCP/UDP协议等。并在最后介绍了"E聊SDK"的通讯方案选型的考虑，以便打造一个现代化即时通讯应用。