在 Ajax 應用程式中實現即時資料推送

http://www.ibm.com/developerworks/cn/web/wa-aj-socket/

Ajax 技術已經存在了一段時間，開發的動力已經真正開始得到了人們的認可。越來越多的 Web 網站正在考慮使用 Ajax 進行設計，開發人員也開始將 Ajax 的能力發揮到極限。隨著社交網路和協作式報告等現象的出現，一組全新的要求浮現出來。如果有其他使用者更改了某位使用者正在觀察的任何活動，則使用者希望得到通知。如果一個 Web 網站顯示動態資料，如股價等，那麼所有使用者都必須立即得到關於變更的通知。

這些情境本身屬於一類稱為 “伺服器推送” 的問題。通常，伺服器是中心實體，伺服器將首先獲得關於所發生的任何更改的通知，伺服器負責將此類更改通知所有串連的用戶端。但遺憾的是，HTTP 是用戶端-伺服器通訊的標準協議，它是無狀態的，而且在某種意義上來說，也是一種單向的協議。HTTP 情境中的所有通訊都必須由用戶端發起，至伺服器結束，然而我們所提到的情境的需求則完全相反。對於伺服器推送來說，需要由伺服器發起通訊，並向用戶端發送資料。HTTP 協議並無相關配置，Web 網站應用程式開發人員使用獨創的方法來繞過這些問題，例如輪詢，用戶端會以固定（或可配置）的時間間隔與伺服器聯絡，尋找是否有新更新可用。在大多數時候，這些輪詢純粹是浪費，因而伺服器沒有任何更新。這種方法不是沒有代價的，它有兩大主要問題。

1. 這種方法極度浪費網路資源。每一個輪詢請求通常都會建立一個 TCP 通訊端串連（除非 HTTP 1.1 將自己的 keepAlive 設定為 true，此時將使用之前建立的通訊端）。通訊端串連本身代價極高。除此之外，每一次請求都要在網路上傳輸一些資料，如果請求未在伺服器上發現任何更新，那麼這樣的資料轉送就是浪費資源。如果在用戶端機器上還運行著其他應用程式，那麼這些輪詢會減少傳輸資料可用的頻寬。
2. 即便是請求成功，確實為用戶端傳回了更新，考慮到輪詢的頻率，這樣的更新也不是即時的。例如，假設輪詢配置為每 20 秒一次，就在一次請求剛剛從伺服器返回時，發生了更新。那麼這次更新將在 20 秒後的下一次請求到來時才能返回用戶端。因而，伺服器上準備好供用戶端使用的更新必須等待一段時間，才能真正地為用戶端所用。對於需要以儘可能即時的方式啟動並執行應用程式來說，這樣的等待是不可接受的。

考慮到這樣兩個問題，對於需要關鍵、即時的伺服器端更新的公司專屬應用程式程式而言，輪詢並不是最理想的方法。在這篇文章中，我將介紹多種可以替代輪詢的方法。每一種替代方法在某些情境中都有自己的突出之處。我將說明這些情境，並展示需要即時伺服器推送的一組 UI。

……