IM 技术经历过几次迭代升级，如图所示：
从简单、低效的短轮询逐步升级到相对效率可控的长轮询；
全双工的 Websocket 彻底解决了服务端的推送问题；
基于 TCP 长连接衍生的 IM 协议，能够实现服务端的主动推送。
| 场景 | 定期、高频地轮询服务端的新消息。当服务器接到请求后，如果有新消息就将新消息返回给客户端，没有新消息就返回空列表，并关闭连接。即：服务端不管本轮有没有新消息产生，都会马上响应并返回。 | 当本次请求没有获取到新消息时，不会马上返回响应结果，而是在服务端“悬挂（hang）”请求并等待一段时间，一旦这段时间产生新消息，就能马上响应并返回。 |
| 缺点 | 对客户端来说，轮询频率较高，大部分请求是无用的，又费电（功效开销）又费流量（网络开销）；对服务端来说，高频的请求会产生较高的 QPS ，并且对后端存储资源造成较大的压力。 | 服务端悬挂住请求，只是降低了入口请求的QPS，并没有减少对后端资源轮询的压力。（假如有1000个请求在等待消息，则可能有1000个线程在不断轮询）；长轮询在超时时间内没有获取到消息时会结束返回，仍然没有完全解决客户端无效请求的问题。 |
结论：短轮询与长连接都无法做到基于事件的完全“边缘触发”，这是因为二者都是基于HTTP协议实现的，而HTTP是一个无状态协议，服务端有新消息产生时，无法直接向客户端推送，而客户端向服务端发起多次请求时，服务端也不会记录客户端的状态——所有的请求只能由客户端发起。
客户端和服务端只需要完成一次握手，就可以创建持久的长连接，并进行随时、双向的数据传输。
当服务端收到新消息时，可以通过建立的 Websocket 连接，直接进行推送，真正做到“边缘触发”，保证消息的实时性。
优点：
1.支持服务端推送的双向通信，大幅降低服务端轮询压力；
2.数据交互的控制开销低，降低双方通信的网络开销；
3.Web 原生支持，实现相对简单。
在 IM 领域，除了 Websocket 协议，还有 XMPP、MQTT 等通信协议，这些是基于 TCP 长连接衍生的私有协议。
这些私有协议，在用户上线连接时，在服务端维护好连接到服务器的用户设备和具体 TCP 连接的映射关系，并且一旦建立起长连接，就一直存在，除非网络被中断。这样，客户端能随时找到服务端，服务端也能通过这个映射关系随时找到对应在线的用户的客户端。
《即时消息技术剖析与实战》学习笔记3——IM系统如何保证消息的实时性
原文：https://www.cnblogs.com/sunshineliulu/p/11450664.html