Bosh vs Comet vs Long Polling vs Polling

最近在研究在中國特點移動互聯網下經過性最好的應用層協議辦法，看到不少混亂的概念和實現，54chen在對各類名詞的歷史進行了深度考察，特做記錄以作區分。

HTTP協議歷史

• 第一個HTTP協議誕生於1989年3月。

• 第一個HTTP協議的版本是HTTP 0.9，它的組成極其簡單，由於它只容許客戶端發送GET這一種請求。

• HTTP協議的第二個版本是HTTP 1.0，直到HTTP 1.0成爲最重要的面向事務的應用層協議。該協議對每一次請求/響應，一樣是創建並關閉一次鏈接。

• HTTP協議的第三個版本是HTTP 1.1，它就是目前使用最普遍的協議版本。從HTTP 1.1開始，客戶端默認與Web 服務器創建長鏈接。

原始階段polling

最先期的時候，由於沒有能夠依賴的東西，能用的只有javascript的setInterval，定時循環向服務器發起請求。

優勢是：服務器端啥特別的東西都不用準備，直接當http請求處理便可。缺點是：白白浪費大量的請求。

什麼是Comet?

中文意思彗星，大概是想表示這是一次尾巴會拖很長的請求。

Comet和ajax同樣，都是一堆技術的合體叫作Comet（莫非是javascript界很喜歡搞高大上的名詞？）。

初始階段的Comet

• CometP屬於這種（jsonP＋iframe）。

• Frame Comet也屬於這種（json＋iframe）。

• ajax Comet也屬於這種（ajax）

• HTTP1.1是長鏈接，並且服務器chunked encoding機制可讓結果部分輸出。

• 利用HTTP1.1的特性，再配合iframe src到一個url，一旦有數據，經過javascript的top.func()把數據告訴瀏覽器。

• 優勢是：比起polling節省了更多的帶寬。缺點：用戶打開多個瀏覽器時會佔用多條鏈接，因此必須在server端配合使用非阻塞的http server，同時若是網絡不太穩定，容易斷掉。

改良版的Comet:long polling

• 由於發現網絡不穩定容易斷的問題。

• 改良後，添加了每次請求返回後當即從新發起請求機會－－長輪循。

• 優勢：比起初始階段，不容易因網絡斷了鏈接，是當今最多見的解決方案。缺點：實在找不到啥缺點，惟一的缺點就是利用了http協議，要是tcp層的，直接鏈接上收發數據就好了。

雙向可通的WebSocket

• 前面都是說的http的，html5就來了個WebSocket，WEB也能夠進行TCP鏈接了。

• 各瀏覽器實現略有不一樣。

• 優勢：底層鏈接 缺點：好多瀏覽器不支持。

BOSH（Bidirectional-streams Over Synchronous HTTP）

• 這是xmpp協議裏定義的一個擴展協議，實際上也能夠歸結爲Comet技術的合體。

• 它同時支持老的polling也支持long polling。

• 具體實現中要完成交互協議才行。

• 優勢：若實現細節可自動適應http 1.0 1.1  缺點：實現要更復雜。

結尾

• 各類讓人混淆的名詞，其實都是在作同一件事情。

• http streaming = http chunked encoding = http keepalive = http 1.1