Comet 技術深度解析：基於 HTTP 長連接的服務器推送實現模型（長輪詢與流技術）

背景：為什麼需要服務器推送？

傳統 HTTP 協議是「請求-響應」模型：客戶端發起請求，服務器被動響應。但在股票行情、即時通訊、協同編輯等場景，服務器掌握核心資源，需主動、實時向客戶端推送數據。

AJAX 處理了「局部刷新」與「異步請求」，但無法解決「服務器發起消息傳遞」。早期採用輪詢模擬實時性，卻帶來：

• 頻繁建立/關閉連接的延遲與資源浪費
• 實時性與效能的矛盾難以平衡

由此催生了 Comet（HTTP 長連接服務器推送） 技術，由 Dojo Toolkit 項目負責人 Alex Russell 命名。

Comet 兩大核心實現模型

模型一：基於 AJAX 的長輪詢

機制：

1. 客戶端發起 AJAX 請求
2. 服務端阻塞持有請求，直到有數據或超時
3. 響應數據並關閉連接
4. 客戶端處理完畢，立即發起新請求，形成循環

特點：

• 服務端有新數據時保存，待客戶端重連時一次性取走
• 基於標準 AJAX，無插件，IE/Firefox 兼容性好
• 典型應用：Meebo、Pushlet Chat

瀏覽器差異：

• Firefox 支持 readyState === 3（數據接收中）讀取響應 → Streaming AJAX
• IE 僅在 readyState === 4（完成）可讀取 → 僅支持長輪詢

模型二：基於 Iframe + htmlfile 的流（Streaming）方式

機制：

1. 頁面嵌入隱藏 <iframe>，src 指向長連接端點
2. 服務端持續輸出 <script>js_func("data")</script> 片段
3. 瀏覽器 JS 引擎接收即執行，實現「推送」
4. 連接長期保持，僅在錯誤或超時時重連

痛點：IE/Firefox 進度條持續轉動、顯示「載入中」

Google 破解方案：使用 ActiveX htmlfile 組件承載 iframe，解決 IE 顯示異常，應用於 Gmail/Gtalk。

技術對比總結

現代替代方案

隨著 WebSocket（全雙工、單連接、低延遲）與 Server-Sent Events (SSE)（單向推送、自動重連、HTTP/2 多路複用）的普及，Comet 逐漸退出主流舞台。但理解其原理，有助於掌握「長連接」「狀態保持」「瀏覽器兼容」等核心網絡編程概念。

參考資源

• Comet Daily / Comet Wiki
• Jetty Continuation / Servlet 3.0 Async Servlet 支持長連接
• Alex Russell: "What else is buried down in the depths of Google's amazing JavaScript?"