IM 在追求“消息实时性”的架构上，所经历过的几个代表性阶段。
1.短轮询场景
在 PC Web 的早期时代，对于数据的获取，大部分应用采用一问一答的“请求响应”式模式，实际上，像现在我们浏览大部分门户网站的新闻，以及刷微博其实都是采用的“请求响应”模式。但这种依赖“手动”触发的模式，在即时消息系统中当有新消息产生时并不能很好地感知并获取到，所以明显不适用于对实时性要求高的场景。因此，这个时期的 IM 软件很多采用了一种“短轮询”的模式，来定期、高频地轮询服务端的新消息。在短轮询模式中，服务器接到请求后，如果有新消息就会将新消息返回给客户端，如果没有新消息就返回空列表，并关闭连接。
如下图所示：
短轮询缺点：
为了提升实时性，短轮询的频率一般较高，但大部分轮询请求实际上是无用的，客户端既费电也费流量；高频请求对服务端资源的压力也较大，一是大量服务器用于扛高频轮询的 QPS（每秒查询率），二是对后端存储资源也有较大压力。
使用场景：
所以适用于用户规模比较小，且不愿花费太多服务改造成本的小型应用上。
2.长轮询场景
长轮询和短轮询相比，一个最大的改进之处在于：短轮询模式下，服务端不管本轮有没有新消息产生，都会马上响应并返回。而长轮询模式当本次请求没有获取到新消息时，并不会马上结束返回，而是会在服务端“悬挂（hang）”，等待一段时间；如果在等待的这段时间内有新消息产生，就能马上响应返回。
如下图所示：
长轮询缺点：
（1）服务端悬挂（hang）住请求，只是降低了入口请求的 QPS，并没有减少对后端资源轮询的压力。假如有 1000 个请求在等待消息，可能意味着有 1000 个线程在不断轮询消息存储资源。
（2）长轮询在超时时间内没有获取到消息时，会结束返回，因此仍然没有完全解决客户端“无效”请求的问题。
使用场景：
对实时性要求比较高，但是整体用户量不太大。它在不支持 WebSocket 的浏览器端的场景下还是有比较多的使用。
3.WebSocket
随着 HTML5 的出现，全双工的 WebSocket 彻底解决了服务端推送的问题。
和短轮询、长轮询相比，基于 WebSocket 实现的 IM 服务，客户端和服务端只需要完成一次握手，就可以创建持久的长连接，并进行随时的双向数据传输。当服务端接收到新消息时，可以通过建立的 WebSocket 连接，直接进行推送，真正做到“边缘触发”，也保证了消息到达的实时性。
优点：
支持服务端推送的双向通信，大幅降低服务端轮询压力；
数据交互的控制开销低，降低双方通信的网络开销；
Web 原生支持，实现相对简单。
还有其他的基于TCP长连接衍生的通信协议，如 XMPP 协议、MQTT 协议以及各种私有协议。
XMPP ：XMPP 协议虽然比较成熟、扩展性也不错，但基于 XML 格式的协议传输上冗余比较多，在流量方面不太友好，而且整体实现上比较复杂，在如今移动网络场景下用的并不多。
MQTT :而轻量级的 MQTT 基于代理的“发布 / 订阅”模式，在省流量和扩展性方面都比较突出，在很多消息推送场景下被广泛使用，但这个协议并不是 IM 领域的专有协议，因此对于很多 IM 下的个性化业务场景仍然需要大量复杂的扩展和开发，比如不支持群组功能、不支持离线消息。
为了更好地解决实时性问题，即时消息领域经历过的几次技术的迭代升级：
1.从简单、低效的短轮询逐步升级到相对效率可控的长轮询；
2.随着 HTML5 的出现，全双工的 WebSocket 彻底解决了服务端推送的问题；
3.同时基于 TCP 长连接衍生的各种有状态的通信协议，也能够实现服务端主动推送，从而更好解决“消息收发实时性”的问题。