《即时消息技术剖析与实战》学习笔记3——IM系统如何保证消息的实时性

深藏阁楼爱情的钟 2023-10-09 12:07 1阅读 0赞

IM 技术经历过几次迭代升级，如图所示：  
![IM技术的演化史][IM]

从简单、低效的短轮询逐步升级到相对效率可控的长轮询；  
全双工的 Websocket 彻底解决了服务端的推送问题；  
基于 TCP 长连接衍生的 IM 协议，能够实现服务端的主动推送。

#### 一、基于HTTP协议的短轮询与长连接 ####

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>  短轮询 </th> 
   <th>  长连接 </th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>场景</td> 
   <td>定期、高频地轮询服务端的新消息。当服务器接到请求后，如果有新消息就将新消息返回给客户端，没有新消息就返回空列表，并关闭连接。即：服务端不管本轮有没有新消息产生，都会马上响应并返回。</td> 
   <td>当本次请求没有获取到新消息时，不会马上返回响应结果，而是在服务端“悬挂（hang）”请求并等待一段时间，一旦这段时间产生新消息，就能马上响应并返回。</td> 
  </tr> 
  <tr> 
   <td>缺点</td> 
   <td>对客户端来说，轮询频率较高，大部分请求是无用的，又费电（功效开销）又费流量（网络开销）；对服务端来说，高频的请求会产生较高的 QPS ，并且对后端存储资源造成较大的压力。</td> 
   <td>服务端悬挂住请求，只是降低了入口请求的QPS，并没有减少对后端资源轮询的压力。（假如有1000个请求在等待消息，则可能有1000个线程在不断轮询）；长轮询在超时时间内没有获取到消息时会结束返回，仍然没有完全解决客户端无效请求的问题。</td> 
  </tr> 
 </tbody> 
</table>

结论：短轮询与长连接都无法做到基于事件的完全“边缘触发”，这是因为二者都是基于HTTP协议实现的，而HTTP是一个无状态协议，服务端有新消息产生时，无法直接向客户端推送，而客户端向服务端发起多次请求时，服务端也不会记录客户端的状态——所有的请求只能由客户端发起。

#### 二、基于单个TCP连接的双全工通信协议的 Websocket ####

客户端和服务端只需要完成一次握手，就可以创建持久的长连接，并进行随时、双向的数据传输。  
当服务端收到新消息时，可以通过建立的 Websocket 连接，直接进行推送，真正做到“边缘触发”，保证消息的实时性。  
优点：  
1.支持服务端推送的双向通信，大幅降低服务端轮询压力；  
2.数据交互的控制开销低，降低双方通信的网络开销；  
3.Web 原生支持，实现相对简单。

#### 三、基于TCP长连接衍生的 IM 协议 ####

在 IM 领域，除了 Websocket 协议，还有 XMPP、MQTT 等通信协议，这些是基于 TCP 长连接衍生的私有协议。  
这些私有协议，在用户上线连接时，在服务端维护好连接到服务器的用户设备和具体 TCP 连接的映射关系，并且一旦建立起长连接，就一直存在，除非网络被中断。这样，客户端能随时找到服务端，服务端也能通过这个映射关系随时找到对应在线的用户的客户端。

#### 小结 ####

从简单、低效的短轮询到相对效率可控的长轮询，再到随着HTML5出现的双全工Websocket，再到基于TCP长连接衍生的各种有状态的通信协议，消息实时性随着技术的迭代升级，更加可靠。

转载于:https://www.cnblogs.com/sunshineliulu/p/11450664.html

[IM]: https://img2018.cnblogs.com/blog/953680/201909/953680-20190903002253018-1192170384.png