即时通讯协议对比

1、即时通讯协议对比

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

1.1、即时通讯协议比较

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"的通讯方案选型的考虑，以便打造一个现代化即时通讯应用。

转自：深入浅出即时通讯(1)_即时通讯协议对比_即时通信协议_E聊SDK的博客-CSDN博客