实时性主要解决的问题是：

• 当一条消息发出后，我们的系统如何确保这条消息最快被接收人感知并获取到，并且尽量让耗费的资源较少。
• 这里关键的几个点是：最快触达，且耗费资源少。

短轮询场景

在短轮询模式中，服务器接到请求后，如果有新消息就会将新消息返回给客户端，如果没有新消息就返回空列表，并关闭连接。

 

长轮询场景

长轮询和短轮询相比，一个最大的改进之处在于：短轮询模式下，服务端不管本轮有没有新消息产生，都会马上响应并返回。而长轮询模式当本次请求没有获取到新消息时，并不会马上结束返回，而是会在服务端“悬挂（hang）”，等待一段时间；如果在等待的这段时间内有新消息产生，就能马上响应返回。

 

服务端推送：真正的边缘触发

随着 HTML5 的出现，全双工的 WebSocket 彻底解决了服务端推送的问题。

 

WebSocket

WebSocket 正是一种服务端推送的技术代表。

和短轮询、长轮询相比，基于 WebSocket 实现的 IM 服务，客户端和服务端只需要完成一次握手，就可以创建持久的长连接，并进行随时的双向数据传输。当服务端接收到新消息时，可以通过建立的 WebSocket 连接，直接进行推送，真正做到“边缘触发”，也保证了消息到达的实时性。

 

TCP 长连接衍生的 IM 协议

除了 WebSocket 协议，在 IM 领域，还有其他一些常用的基于 TCP 长连接衍生的通信协议，如 XMPP 协议、MQTT 协议以及各种私有协议。

• XMPP 协议虽然比较成熟、扩展性也不错，但基于 XML 格式的协议传输上冗余比较多，在流量方面不太友好，而且整体实现上比较复杂，在如今移动网络场景下用得并不多。
• 轻量级的 MQTT 基于代理的“发布 / 订阅”模式，在省流量和扩展性方面都比较突出，在很多消息推送场景下被广泛使用，但这个协议并不是 IM 领域的专有协议，因此对于很多 IM 下的个性化业务场景仍然需要大量复杂的扩展和开发，比如不支持群组功能、不支持离线消息。

对于开发人力相对充足的大厂，目前很多是基于 TCP（或者 UDP）来实现自己的私有协议，一方面私有协议能够贴合业务需要，做到真正的高效和省流；另一方面私有协议相对安全性更高一些，被**的可能性小。目前主流的大厂很多都是采用私有协议为主的方式来实现。