WebSockets
本參考文件的這一部分介紹了對 Servlet 棧的支援、WebSocket 訊息傳遞（包括原始 WebSocket 互動）、透過 SockJS 實現的 WebSocket 模擬以及透過 STOMP 作為 WebSocket 子協議實現的釋出-訂閱訊息傳遞。
WebSocket 簡介
WebSocket 協議，RFC 6455，提供了一種標準化方法，用於透過單個 TCP 連線在客戶端和伺服器之間建立全雙工、雙向通訊通道。它與 HTTP 是一種不同的 TCP 協議，但旨在透過 HTTP 工作，使用埠 80 和 443，並允許重用現有防火牆規則。
WebSocket 互動始於一個 HTTP 請求，該請求使用 HTTP Upgrade 頭來升級或在本例中切換到 WebSocket 協議。以下示例顯示了此類互動
GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket (1)
Connection: Upgrade (2)
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: https://:8080| 1 | Upgrade 頭。 |
| 2 | 使用 Upgrade 連線。 |
具有 WebSocket 支援的伺服器會返回類似於以下內容的輸出，而不是通常的 200 狀態碼
HTTP/1.1 101 Switching Protocols (1)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp| 1 | 協議切換 |
成功握手後，HTTP 升級請求底層的 TCP 套接字保持開啟狀態，客戶端和伺服器都可以繼續傳送和接收訊息。
關於 WebSocket 工作原理的完整介紹超出了本文件的範圍。請參閱 RFC 6455、HTML5 的 WebSocket 章或網路上許多介紹和教程中的任何一個。
請注意，如果 WebSocket 伺服器執行在 Web 伺服器（例如 Nginx）後面，您可能需要配置它以將 WebSocket 升級請求傳遞給 WebSocket 伺服器。同樣，如果應用程式在雲環境中執行，請檢視雲提供商關於 WebSocket 支援的說明。
HTTP 與 WebSocket
儘管 WebSocket 被設計為與 HTTP 相容並以 HTTP 請求開始，但瞭解這兩種協議會導致非常不同的架構和應用程式程式設計模型是很重要的。
在 HTTP 和 REST 中，應用程式被建模為許多 URL。為了與應用程式互動，客戶端以請求-響應的方式訪問這些 URL。伺服器根據 HTTP URL、方法和頭將請求路由到適當的處理程式。
相比之下，在 WebSocket 中，通常只有一個 URL 用於初始連線。隨後，所有應用程式訊息都在同一 TCP 連線上傳輸。這指向了一種完全不同的非同步、事件驅動的訊息傳遞架構。
WebSocket 也是一種低階傳輸協議，與 HTTP 不同，它不規定訊息內容的任何語義。這意味著，除非客戶端和伺服器就訊息語義達成一致，否則無法路由或處理訊息。
WebSocket 客戶端和伺服器可以透過 HTTP 握手請求上的 Sec-WebSocket-Protocol 頭協商使用更高級別的訊息協議（例如 STOMP）。如果不存在，它們需要自己制定約定。
何時使用 WebSockets
WebSockets 可以使網頁具有動態性和互動性。然而，在許多情況下，AJAX 和 HTTP 流或長輪詢的組合可以提供一個簡單有效的解決方案。
例如，新聞、郵件和社交訂閱源需要動態更新，但每隔幾分鐘更新一次可能完全可以接受。另一方面，協作、遊戲和金融應用程式需要更接近即時。
僅延遲本身並不是決定性因素。如果訊息量相對較低（例如，監控網路故障），HTTP 流或輪詢可以提供有效的解決方案。低延遲、高頻率和高流量的組合是使用 WebSocket 的最佳理由。
還要記住，在網際網路上，您無法控制的限制性代理可能會阻止 WebSocket 互動，要麼是因為它們未配置為傳遞 Upgrade 頭，要麼是因為它們關閉了看起來空閒的長時間連線。這意味著，在防火牆內部的內部應用程式中使用 WebSocket 是一個比面向公眾的應用程式更直接的決策。
