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

之前做過幾十年IM架構(gòu)，今天和大家聊聊這里面的技術(shù)點。

WebIM一般如何實現(xiàn)消息推送？

通常的有三種實現(xiàn)方式：

• WebSocket；
• FlashSocket；
• HTTP輪詢；

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

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

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

什么是輪詢？

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

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

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

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

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

同時還會產(chǎn)生更大的問題，大部分的輪詢調(diào)用，都沒有消息返回，造成服務(wù)端極大的資源浪費。

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

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

專用消息連接。

什么是專用消息鏈接？

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

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

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

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

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

總結(jié)

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

知其然，知其所以然。

思路比結(jié)論更重要。