深入浅出即时通讯(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 】

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

深入浅出即时通讯(1)_即时通讯协议对比_第2张图片

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

http短轮询:

深入浅出即时通讯(1)_即时通讯协议对比_第3张图片

短轮询的处理如下:

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

**http长轮询: **

深入浅出即时通讯(1)_即时通讯协议对比_第4张图片

短轮询的处理如下:

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

你可能感兴趣的:(深入浅出即时通讯,websocket,http,xmpp,即时通信)