【IM即时通讯】IM即使通讯学习
由于目前所在公司是做IM即使通讯的公司,做了一款类似于飞书的OA办公软件,由于之前没有接接触过IM即使通讯,记录学习过程方便各位大佬学习和了解和指正
文章目录
前言
自互联网诞生以来,即时通讯平台就一直存在,并且随着互联网的发展,有些平台也逐渐发展成输出即时通讯通用能力云服务商,国内提供IM即时通讯云服务的有: 网易云信、融云、腾讯云、阿里云等等。目前我们所知几乎所有的APP都集成IM功能,从社交、游戏、到生活中的方方面面,打车、找房等。可以说IM作为一种通讯能力,已经成为互联网上的基础设施,成为许多APP不可或缺的功能。所以今天和大家一起分享一下个人对IM 的一些理解,如有哪些地方理解有偏差的地方,还请大家批评指正。
一、短连接和长连接实现即时通讯浅析
基于短连接http实现
HTTP协议是非持久化的,单向的网络协议,在建立连接后只允许浏览器向服务器发出请求后,服务器才能返回相应的数据。当需要即时通讯时,通过轮询在特定的时间间隔(如1秒),由浏览器向服务器发送Request请求,然后将最新的数据返回给浏览器。这样的方法最明显的缺点就是需要不断的发送请求(每次请求都需要新建连接并建立连接,当然可以使用长轮训keepalive来减少建立连接的次数),而且通常HTTP request的Header是非常长的,为了传输一个很小的数据 需要付出巨大的代价,是很不合算的,占用了很多的宽带。
缺点:会导致过多不必要的请求,浪费流量和服务器资源,每一次请求、应答,都浪费了很大流量在相同的头部信息上,效率比较低。并且用短连接实现即时通讯在实时性上较差,如果增加实时性,服务端压力会非常大。 所以很显然 此种短连接+轮训的方式实现IM是不合适的。
基于双向通信实现
双向通信我们可以简单理解为:不仅仅客户端可以向服务端发送数据,服务端也可以发送数据到客户端。这样我们可以很自然的联想到TCP的全双工实现,即基于长连接技术下服务端更新的数据。
基于SSE网络协议
SSE 是一种在基于浏览器的 Web 应用程序中仅从服务器向客户端发送文本消息的技术。SSE基于 HTTP 协议中的持久连接, 具有由 W3C 标准化的网络协议和 EventSource 客户端接口,作为 HTML5 标准套件的一部分。
基于WebSocket协议
WebSocket 是一种在 Web 应用程序中实现同时、双向、实时通信的技术。WebSocket 基于 HTTP 以外的协议(TCP),因此可能需要额外设置网络基础设施(代理服务器、NAT、防火墙等)。
基于Socket通信
Socket是应用层与TCP/IP协议族通信的中间软件抽象层,它是一组接口。在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后面,对用户来说,一组简单的接口就是全部,让Socket去组织数据,以符合指定的协议。
根据不同场景和客户端自行进行选择实现。
二、XMPP协议
XMPP(Extensible Messaging and Presence Protocol,前称Jabber)协议介绍
QQ
上面为什么要在这里提出XMPP协议,由于腾讯QQ就是参考 XMPP 进行实现的
(既然学习,就要了解IM的前生今世才能更好的学习)
现在了了XMPP协议的工作流程是怎么样的:
XMPP的架构
XMPP的基本网络架构包含三元素:客户端、服务器、网关,具体如下图:
(图片来自于的微信)
Jabber识别符(JID)是用户登录时所使用的帐号,看起来通常像一个电子邮件地址,如:someone@example.com,前半部分是用户名,后半部分是XMPP服务器域名,两个字段以@符号区隔。
假设李雷(LiLei@A.com)想和韩梅梅(HanMeimei@B.net)通话,他们两人的帐号分别在http://A.com和http://B.net的服务器上。当李雷发送信息后,过程如下:
李雷的XMPP客户端将他的信息传送到com XMPP服务器。
com XMPP服务器打开与net XMPP服务器的连接。
net XMPP服务器将信息传送给韩梅梅,如果其当前不在线,则存储信息以待其上线后发送
XMPP由于XMPP所所诞生的时代是存在于PC时代,为了解决当时(2000年)如火如荼的IM通讯,例如MSN、ICQ… 所以并没有考虑移动端的时代,庞大的数据结构就(XML数据格式)支持灵活拓展不同的数据格式,去中心化,,支持SASL、TLS加密,这些让XMPP风靡一时。
<stream:stream>
<iq
id="roster1"
type='get'>
<query xmlns='jabber:iq:roster'/>
</iq>
<message
from='test_account@jabber.org'
to='william_duan@jabber.org'
type='chat'>
<body>Hello</body>
</message>
<presence type='unavailable'/>
</stream:stream>
上面就是XMPP的一个标准的格式,感兴趣的同学可以看一篇这篇博客,讲的很全面XMPP基础
二、MQTT协议
XMPP的缺点
上面的协议似乎已经过时,随着移动2007年移动时代,和物联网时代的到来。似乎XMPP的诟病逐渐被表现出来,XMPP不支持QOS(指一个网络能够利用各种基础技术,为指定的网络通信提供更好的服务能力,是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题的一种技术)
。庞大的数据结构传输带来过大的带宽,随之而来的就是消耗移动设备更多的电量,大家也知道在移动手机盛行的年代以至于至今对于一个移动设备的电量续航一直是一款移动设备评估是否优秀的有利“条件”
MQTT优点
MQTT协议最初是在1999年由IBM公司开发的,用于将石油管道上的传感器与卫星相连接。 2014年正式成为OASIS开放标准。
MQTT使用类似MQ常用的发布/订阅模式,起到应用程序解耦,异步消息,削峰填谷的作用。很多MQ中间件也支持MQTT协议,比如ActiveMQ、 RabbitMQ、 HiveMQ、 WebSphereMQ等。
技如其名,MQTT(Message Queuing Telemetry Transport ),使用发布/订阅模式,提供一对多的消息发布,使消息发送者和接收者在时间和空间上解耦,使用二进制方式进行网络交互(更低的网络传输开销),支持QOS(前面介绍过可以去里了解一下
),标准和Topic订阅消息。
适用范围:在低带宽、不可靠的网络下提供基于云平台的远程设备的数据传输和监控,所以目前主流的小型IM即使消息协议大多是MQTT作为基准在此基础上进行开发定制。
IM 对于消息实现的模式
基于推(push)模式(消息投递)
Messages 消息直接通过长连接通道投递给目标设备;
实时性较高:实时性由服务端控制
基于拉(pull)模式(消息拉取)
目标设备根据本地偏移量按需定时主动拉取Messages
实时性较差:实时性由客户端控制
组合模式
将最小的通知消息投递给目标设备,目标设备根据自身的情况,自行携带本地偏移量向服务器主动拉取消息