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

這種技術可能會產生大量不必要的流量和非最佳化的應用程式。幸運的是，某些富 Internet 應用程式（RIA）技術確實允許開啟專用通訊端通道，由後端伺服器為 Asynchronous JavaScript and XML (Ajax) 應用程式提供進入其 API 並實現伺服器推送的機會。這篇文章以多種方式探討了這項技術，協助您充分理解，以便著手開始進行自己的實現工作。

簡介

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

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

這種方法極度浪費網路資源。每一個輪詢請求通常都會建立一個 TCP 通訊端串連（除非 HTTP 1.1 將自己的 keepAlive 設定為 true，此時將使用之前建立的通訊端）。通訊端串連本身代價極高。除此之外，每一次請求都要在網路上傳輸一些資料，如果請求未在伺服器上發現任何更新，那麼這樣的資料轉送就是浪費資源。如果在用戶端機器上還運行著其他應用程式，那麼這些輪詢會減少傳輸資料可用的頻寬。

即便是請求成功，確實為用戶端傳回了更新，考慮到輪詢的頻率，這樣的更新也不是即時的。例如，假設輪詢配置為每 20 秒一次，就在一次請求剛剛從伺服器返回時，發生了更新。那麼這次更新將在 20 秒後的下一次請求到來時才能返回用戶端。因而，伺服器上準備好供用戶端使用的更新必須等待一段時間，才能真正地為用戶端所用。對於需要以儘可能即時的方式啟動並執行應用程式來說，這樣的等待是不可接受的。

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

Ajax 應用程式中的伺服器更新技術

讓我們來具體看看用於更新來自伺服器的資訊的一些常用技術，這些技術類比了伺服器推送。

短輪詢

短輪詢也稱為高頻輪詢，就是我在本文開頭處介紹的技術。這種方法在以下情況中表現最好：

有足夠的頻寬可用。

根據統計資料，大多數時候，請求都能獲得更新。例如，股市資料就總是有可用更新。

使用 HTTP 1.1 協議。設定 keepAlive=true，因而，同一個通訊端串連始終保持活動狀態，並可重用。

長輪詢

長輪詢是用於補救伺服器資料的另外一種方法。這種方法的理念就是用戶端建立串連，伺服器阻塞串連（通過使請求線程在某些條件下處於等待狀態），有資料可用時，伺服器將通過阻塞的串連發送資料，隨後關閉串連。用戶端在接收到更新後，立即重建立立串連，伺服器重複上述過程，以此實現近於即時的通訊。然而，長輪詢具有以下缺陷：

一般的瀏覽器預設允許每台伺服器具有兩個串連。在這種情況下，一個串連始終是繁忙狀態。因而，UI 只有一個串連（也就是說，能力減半）可用於為使用者請求提供服務。這可能會導致某些操作的效能降低。

仍然需要開啟和關閉 HTTP 串連，如果採用的是非持久串連模式（keepAlive=false），那麼這種方法的代價可能極高。

這種方法近於即時，但並非真正的即時。（當然，某些外部因素總是不可控的，比如網路延時，在任何方法中都會存在這些因素。）