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

1. 即时通讯协议对比

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

1.1 即时通讯协议比较

名称	特点	Web支持	模式
http短轮询/长轮询	实现简单; 开销大，耗费服务器性能与带宽	支持	请求-响应
Websocket	连接快，开销小	支持	双向通讯
xmpp	协议沉重，不支持二进制包文	不支持	双向通讯
mqtt	常用于物联网场景，协议简单	不支持	发布-订阅
socket.io	在websocket封装的基础上实现了连接管理，群组，命名空间等特性。	支持	发布-订阅
基于tcp自定义协议	连接可靠，开发难度中等	不支持	-
基于udp自定义协议	连接与发送数据不可靠，开发难度大	不支持	-

1.1.1 http短轮询/长轮询

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

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

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

http短轮询：

短轮询的处理如下:

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

**http长轮询: **

短轮询的处理如下:

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

总结: 不管是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, 原因有以下几点:

1. 使用XML为载荷的XMPP消息体很大;
2. XMPP的协议贪大求全，太过复杂，使用者门槛很高;
3. 虽说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 有如下的特点:

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

与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"的过程中，笔者注意考虑了以下几点即时通讯的需求:

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

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

1. http 的开发方式与调试工具已十分成熟，像Chrome 的F12调试窗, curl 工具, java后端的servlet debug等都十分好用， 使用http 请求的方式方便开发人员开发，调试，大大提交业务开发效率;
2. 服务器使用socket.io 的通道向客户端下发即时消息.当socket.io 连接起来后(底层使用websocket), 可以得益于websocket 全双工，低延时的优势。
3. socket.io 的基于订阅-发布模式，协议上自带连接管理，自动重连等功能, 接入使用简单，可以达到开箱即用，降低研发人员使用门槛；
4. 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"的通讯方案选型的考虑，以便打造一个现代化即时通讯应用。