webim如何使用http長輪詢保證消息的絕對實時性
一、webim如何實作消息推送
webim通常有三種方式實作推送通道：
1）WebSocket
2）FlashSocket
3）http輪詢
其中1）和2）是用Tcp長連接配接實作的，其消息的實時性很好了解，但這兩種方案都存在一些局限性，不通用。
方案3）才算是webim實作消息推送的“正統”方案，用http短連接配接輪詢的方式實作“僞長連接配接”，既然是輪詢，有朋友就對消息的實時性産生了質疑。本文要解答，webim使用http長輪詢如何保證消息的絕對實時性。
二、人們為什麼會誤解http長輪詢不實時
什麼是輪詢？我擦，這個該怎麼解釋咧。
舉個栗子，在火車上想上洗手間，擠到洗手間旁，卻發現洗手間有人，于是你隻能回座位繼續等。過了N分鐘，又朝洗手間的方向擠過去，卻發現洗手間還是有人，又隻能回坐等。這麼一而再，再而三的每隔N分鐘去洗手間檢視洗手間是否有蹲位，這就是輪詢。
webim用輪詢的方式拉取消息會存在什麼問題？
webim每隔N分鐘，輪詢調用 “擷取消息”接口，有可能出現消息的延時，某一時刻剛拉取完消息，突然又産生了一條新消息，這條消息就必須等到N分鐘之後，再次發起“擷取消息”輪詢時，才有機會擷取到。
減小輪詢時間間隔是否能解決消息延時的問題？
減小輪詢時間間隔的确可以縮短延時時間，但也不能保證消息絕對的實時，同時又會産生新的問題，絕大部分的輪詢調用，都沒有消息傳回，造成服務端極大的資源浪費。
很多人基于上述直覺，認為webim使用http長輪詢的方式拉取消息，會導緻消息有延時，其實，webim的http長輪詢根本不是這麼玩的。
三、長輪詢實際怎麼玩
消息連接配接
webim和webserver之間建立一條http連接配接，專門用作消息通道，這條連接配接叫http消息連接配接【見下圖】
消息連接配接的4大特性
1）沒有消息到達的時候，這個http消息連接配接将被夯住，不傳回，由于http是短連接配接，這個http消息連接配接最多被夯住90秒，就會被斷開（這是浏覽器或者webserver的行為）
2）在1）的情況下，如果http消息連接配接被斷開，立馬再發起一個http消息連接配接【見下圖中的步驟1、2】
3）在1）和2）的配合下，浏覽器與webserver之間将永遠有一條消息連接配接在（極限情況下會出現4）），每次收到消息時，這個消息連接配接就能及時将消息帶回浏覽器頁面，并且在傳回後，會立馬再發起一個http消息連接配接【見下圖中的步驟1、2、3】
4）如果消息到達時，上一個http消息連接配接正在傳回，沒有http消息連接配接可用（理論上http消息連接配接的傳回是瞬時的，沒有連接配接可用出現的機率極小），則将消息暫存入消息池中，下一個消息連接配接到達後（上一個消息連接配接傳回後，根據2）和3）會立馬傳回新的消息連接配接，無等待時間），将消息帶回，并又立刻傳回生成新的消息連接配接【見下圖中的步驟1、2、3、4、5、6、7】
上述1-4就能夠保證一直有一條http消息連接配接在，以保證webim消息推送的絕對實時性。
##四、結論
webim通過http長輪詢可以保證消息的絕對實時性。這種實時性的保證不是通過增加輪詢頻率來保證的，而是通過夯住http消息連接配接來保證的，在大部分時間沒有實時消息的情況下，這個http消息連接配接對于webserver的請求壓力是90秒1次，能夠大大節省了web伺服器資源。