最後更新於 2012 年 11 月 5 日 (Spring MVC 3.2 RC1)

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

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

傳統輪詢

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

長輪詢

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

響應可以保持開啟多久？瀏覽器設定為 5 分鐘超時，而代理等網路中間裝置可能更早超時。因此，即使沒有新資訊到達，長輪詢請求也應該定期完成，以允許瀏覽器傳送新請求。這個IETF 文件建議使用 30 到 120 秒之間的超時值，但實際使用的值可能取決於您對分隔瀏覽器和伺服器的網路中間裝置的控制程度。

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

HTTP 流式傳輸

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

WebSocket 協議

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

WebSocket 協議旨在取代輪詢的需要，並特別適用於需要高頻在瀏覽器和伺服器之間交換訊息的場景。初始的 HTTP 握手確保 WebSocket 請求可以透過防火牆。然而，挑戰也很顯著，因為大多數已部署的瀏覽器不支援 WebSockets，並且在穿越網路中間裝置方面存在進一步的問題。

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 功能。