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 長連接衍生的各種有狀態的通信協議，也能夠實現服務端主動推送，從而更好解決“消息收發實時性”的問題。