有水友問我說，微博網頁端IM通過HTTP收發(fā)消息，會不會有延時？

之前做過幾十年IM架構，今天和大家聊聊這里面的技術點。

WebIM一般如何實現消息推送？

通常的有三種實現方式：

• WebSocket；
• FlashSocket；
• HTTP輪詢；

其中1和2是基于TCP長鏈接實現的，水友問的問題，主要是第三類，用HTTP短連接輪詢的方式實現消息的收發(fā)，能否能保證消息的絕對實時性。

大家為什么會覺得HTTP長輪詢有延時？

這要從大家理解的“輪詢”說起。

什么是輪詢？

舉個栗子，在火車上想上洗手間，擠到洗手間旁，卻發(fā)現洗手間有人，于是你只能回座位繼續(xù)等。過了N分鐘，又朝洗手間的方向擠過去，卻發(fā)現洗手間還是有人，又只能回坐等。這么一而再，再而三的每隔N分鐘去洗手間查看洗手間是否有蹲位，這就是輪詢。

WEBIM采用上述輪詢的方式收發(fā)消息會存在什么問題？

可能導致消息延時，某一時刻剛拉取完消息，突然又產生了一條新消息，這條消息就必須等到N分鐘之后，下次輪詢時，才有機會獲取到。延時的最大值是N。

減小輪詢時間間隔，是否能解決消息延時的問題？

不能，只能縮小延時，不能保證絕對實時。

同時還會產生更大的問題，大部分的輪詢調用，都沒有消息返回，造成服務端極大的資源浪費。

不少人基于上述直覺，認為WEBIM使用HTTP長輪詢收發(fā)消息會有延時。但其實，HTTP長輪詢壓根不是這回事。

HTTP長輪詢實際是怎么玩的？

專用消息連接。

什么是專用消息鏈接？

瀏覽器與web-server之間建立的，一條專門用來接受通知消息的HTTP鏈接。

專用消息連接的玩法細節(jié)如下：

• 沒有消息到達的時候，專用消息連接將被夯住一段時間（例如：90秒）；
• 夯住90秒，專用消息連接被斷開之后，立馬再發(fā)起一個專用消息連接；

• 在1和2的配合下，每次收到通知消息時，這個連接就能及時將消息帶回瀏覽器頁面；

• 在3的情況下，專用消息連接返回瀏覽器后，又立刻發(fā)起新的專用消息連接，如此一來，瀏覽器與web-server之間將永遠有一條能夠接受服務器通知的專用消息連接，以此，來保證WEBIM消息收發(fā)的絕對實時性。

總結

• HTTP長輪詢可以保證消息的絕對實時性；
• 這種實時性不是通過增加輪詢頻率來保證的；
• 而是通過專用消息連接，通過夯住HTTP請求來實現的，這個HTTP消息連接對于web-server的請求壓力大約是90秒1次，能夠大大節(jié)省了服務器資源。

知其然，知其所以然。

思路比結論更重要。