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

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

在標準的 HTTP 請求-響應語義中，瀏覽器發起請求，伺服器傳送響應，這意味著伺服器在收到瀏覽器的請求之前無法傳送新資訊。已經發展了幾種方法，包括傳統輪詢、長輪詢和HTTP 流，最近我們有了 WebSocket 協議。

傳統輪詢

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

長輪詢

瀏覽器不斷髮送請求，但伺服器只有在有新資訊要傳送時才響應。從客戶端的角度來看，這與傳統輪詢相同。從伺服器的角度來看，這與長時間執行的請求非常相似，並且可以使用第 1 部分中討論的技術進行擴充套件。

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

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

HTTP 流

瀏覽器向伺服器傳送請求，伺服器在有資訊要傳送時響應。但是，與長輪詢不同，伺服器保持響應開啟並繼續傳送更多更新。這種方法消除了輪詢的需要，但也與典型的 HTTP 請求-響應語義有更顯著的背離。例如，客戶端和伺服器需要就如何解釋響應流達成一致，以便客戶端知道一個更新在哪裡結束而另一個更新在哪裡開始。此外，網路中介可以快取響應流，這會阻礙該方法的意圖。這就是為什麼現在更常用長輪詢。

WebSocket 協議

瀏覽器向伺服器傳送 HTTP 請求以切換到 WebSocket 協議，伺服器透過確認升級來響應。此後，瀏覽器和伺服器可以透過 TCP 套接字在兩個方向上傳送資料幀。

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

WebSockets 圍繞文字或二進位制訊息的雙向交換。 它導致與基於 RESTful 的 HTTP 架構截然不同的方法。 事實上，需要在 WebSockets 之上使用一些其他協議，例如 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 呼叫的伺服器版本”。至於 WebSockets，Spring 3.2 尚不支援，但很可能會包含在 Spring 3.3 中。您可以關注 SPR-9356 以獲取進度更新。

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