上次更新日期：2012 年 11 月 5 日（Spring MVC 3.2 RC1）

在我上一篇文章中，我介紹了 Spring MVC 3.2 中基於 Servlet 3 的全新非同步支援，並討論了長時間執行的請求。非同步處理的第二個非常重要的動機是瀏覽器需要接收即時更新。範例包括瀏覽器中的聊天、股票報價、狀態更新、現場體育賽事結果等。當然，並非所有範例都同樣對延遲敏感，但它們都具有相似的需求。

在標準 HTTP 請求-回應語意中，瀏覽器發起請求，伺服器傳送回應，這表示伺服器必須先收到瀏覽器的請求，才能傳送新資訊。已經發展出幾種方法，包括傳統輪詢、長輪詢和HTTP 串流，以及最近的 WebSocket 協定。

傳統輪詢

瀏覽器持續傳送請求以檢查新資訊，並且伺服器每次都會立即回應。這適用於可以以相當稀疏的間隔進行輪詢的情況。例如，郵件客戶端可以每 10 分鐘檢查一次新郵件。它簡單且有效。但是，如果必須盡快顯示新資訊，此方法會變得效率低下，在這種情況下，必須非常頻繁地進行輪詢。

長輪詢

瀏覽器持續傳送請求，但伺服器在有新資訊要傳送時才會回應。從用戶端角度來看，這與傳統輪詢相同。從伺服器角度來看，這與長時間執行的請求非常相似，可以使用第一部分中討論的技術進行擴展。

回應可以保持開啟多長時間？瀏覽器設定為 5 分鐘後逾時，而網路中介（例如 Proxy）可能會更快逾時。因此，即使沒有新資訊到達，長輪詢請求也應定期完成，以允許瀏覽器傳送新請求。此 IETF 文件建議使用 30 到 120 秒之間的逾時值，但要使用的實際值可能取決於您對將瀏覽器與伺服器分離的網路中介的控制程度。

長輪詢可以顯著減少接收低延遲資訊更新所需的請求數量，尤其是在不規則間隔提供新資訊的情況下。但是，更新越頻繁，它就越接近傳統輪詢。

HTTP 串流

瀏覽器向伺服器傳送請求，並且伺服器在有資訊要傳送時會回應。但是，與長輪詢不同，伺服器會保持回應開啟，並在收到更多更新時繼續傳送。這種方法消除了輪詢的需要，但也是對典型 HTTP 請求-回應語意的更重大偏離。例如，客戶端和伺服器需要協商如何解釋回應串流，以便客戶端知道一個更新的結束和另一個更新的開始位置。此外，網路中介可以快取回應串流，這會阻礙此方法的意圖。這就是為什麼現在更常使用長輪詢。

WebSocket 協定

瀏覽器向伺服器傳送 HTTP 請求以切換到 WebSocket 協定，並且伺服器透過確認升級來回應。此後，瀏覽器和伺服器可以透過 TCP Socket 在兩個方向上傳送資料框架。

WebSocket 協定旨在取代輪詢的需要，並且特別適用於需要在瀏覽器和伺服器之間以高頻率交換訊息的情況。透過 HTTP 的初始握手確保 WebSocket 請求可以通過防火牆。但是，也存在重大挑戰，因為大多數已部署的瀏覽器都不支援 WebSocket，並且在通過網路中介方面也存在 更多問題。

WebSocket 圍繞文字或二進位訊息的雙向交換。它導致與基於 RESTful、HTTP 的架構截然不同的方法。事實上，需要在 WebSocket 之上使用另一種協定，例如 XMPP、AMQP、STOMP 或其他協定，並且哪一個（或哪些）協定將佔據主導地位仍有待觀察。

WebSocket 協定已經由 IETF 標準化，而 WebSocket API 正處於 W3C 標準化的最後階段。許多 Java 實作已經可用，包括 Jetty 和 Tomcat 等 Servlet 容器。Servlet 3.1 規範可能會支援初始 WebSocket 升級請求，而單獨的 JSR-356 將定義基於 Java 的 WebSocket API。

回到 Spring MVC 3.2，Servlet 3 非同步功能可用於長時間執行的請求以及 HTTP 串流，Filip Hanik 將其稱為「用戶端 AJAX 呼叫的伺服器版本」。至於 WebSocket，Spring 3.2 尚不支援，但很可能會包含在 Spring 3.3 中。您可以關注 SPR-9356 以獲取進度更新。

下一篇文章將轉向範例程式碼，並更詳細地說明 Spring MVC 3.2 的新功能。