IM 技術經歷過幾次迭代升級，如圖所示：
從簡單、低效的短輪詢逐步升級到相對效率可控的長輪詢；
全雙工的 Websocket 徹底解決了服務端的推送問題；
基於 TCP 長連接衍生的 IM 協議，能夠實現服務端的主動推送。
一、基於HTTP協議的短輪詢與長連接
|
|
|
|
|---|---|---|
| 場景 | 定期、高頻地輪詢服務端的新消息。當服務器接到請求后，如果有新消息就將新消息返回給客戶端，沒有新消息就返回空列表，並關閉連接。即：服務端不管本輪有沒有新消息產生，都會馬上響應並返回。 | 當本次請求沒有獲取到新消息時，不會馬上返回響應結果，而是在服務端“懸掛（hang）”請求並等待一段時間，一旦這段時間產生新消息，就能馬上響應並返回。 |
| 缺點 | 對客戶端來說，輪詢頻率較高，大部分請求是無用的，又費電（功效開銷）又費流量（網絡開銷）；對服務端來說，高頻的請求會產生較高的 QPS ，並且對后端存儲資源造成較大的壓力。 | 服務端懸掛住請求，只是降低了入口請求的QPS，並沒有減少對后端資源輪詢的壓力。（假如有1000個請求在等待消息，則可能有1000個線程在不斷輪詢）；長輪詢在超時時間內沒有獲取到消息時會結束返回，仍然沒有完全解決客戶端無效請求的問題。 |
結論：短輪詢與長連接都無法做到基於事件的完全“邊緣觸發”，這是因為二者都是基於HTTP協議實現的，而HTTP是一個無狀態協議，服務端有新消息產生時，無法直接向客戶端推送，而客戶端向服務端發起多次請求時，服務端也不會記錄客戶端的狀態——所有的請求只能由客戶端發起。
二、基於單個TCP連接的雙全工通信協議的 Websocket
客戶端和服務端只需要完成一次握手，就可以創建持久的長連接，並進行隨時、雙向的數據傳輸。
當服務端收到新消息時，可以通過建立的 Websocket 連接，直接進行推送，真正做到“邊緣觸發”，保證消息的實時性。
優點：
1.支持服務端推送的雙向通信，大幅降低服務端輪詢壓力；
2.數據交互的控制開銷低，降低雙方通信的網絡開銷；
3.Web 原生支持，實現相對簡單。
三、基於TCP長連接衍生的 IM 協議
在 IM 領域，除了 Websocket 協議，還有 XMPP、MQTT 等通信協議，這些是基於 TCP 長連接衍生的私有協議。
這些私有協議，在用戶上線連接時，在服務端維護好連接到服務器的用戶設備和具體 TCP 連接的映射關系，並且一旦建立起長連接，就一直存在，除非網絡被中斷。這樣，客戶端能隨時找到服務端，服務端也能通過這個映射關系隨時找到對應在線的用戶的客戶端。
小結
從簡單、低效的短輪詢到相對效率可控的長輪詢，再到隨着HTML5出現的雙全工Websocket，再到基於TCP長連接衍生的各種有狀態的通信協議，消息實時性隨着技術的迭代升級，更加可靠。