Spring Framework 參考文檔（WebSocket介紹）

WebSocket介紹

WebSocket協議，RFC 6455，提供了一種標準化的方法，經過單個TCP鏈接在客戶端和服務器之間創建一個全雙工雙向通訊通道，它是一種不一樣於HTTP的TCP協議，但被設計用於HTTP之上，使用端口80和443並容許重用現有的防火牆規則。

WebSocket交互從HTTP請求開始，HTTP請求使用HTTP Upgrade header進行upgrade，或者在本例中切換到WebSocket協議，下面的示例展現了這種交互：

GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080

• Upgrade: websocket => Upgrade header。
• Connection: Upgrade => 使用Upgrade鏈接。

支持WebSocket的服務器返回的輸出與下面相似，而不是一般的200狀態代碼：

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp

• HTTP/1.1 101 Switching Protocols=> 協議轉換。

在成功握手以後，在HTTP upgrade請求基礎上的TCP socket仍然是開放的，以便客戶端和服務器繼續發送和接收消息。

關於WebSockets如何工做的完整介紹超出了本文的範圍，參見RFC 6455，HTML5的WebSocket章節，或者Web上許多介紹和教程中的任何一個。

注意，若是WebSocket服務器運行在web服務器（例如nginx）以後，你可能須要將它配置爲將WebSocket upgrade請求傳遞到WebSocket服務器，一樣，若是應用程序在雲環境中運行，請檢查與WebSocket支持相關的雲提供商的說明。

HTTP與WebSocket

儘管WebSocket被設計爲與HTTP兼容並從HTTP請求開始，但重要的是要理解這兩個協議致使了很是不一樣的體系結構和應用程序編程模型。

在HTTP和REST中，應用程序被建模爲多個URL，爲了與應用程序交互，客戶端訪問那些URL，請求-響應樣式，服務器根據HTTP URL、方法和headers將請求路由到適當的處理程序。

相比之下，在WebSockets中，一般初始鏈接只有一個URL，隨後，全部應用程序消息都在同一個TCP鏈接上流動，這指向了一個徹底不一樣的異步、事件驅動的消息傳遞體系結構。

WebSocket也是一種低級別的傳輸協議，與HTTP不一樣的是，它沒有對消息的內容規定任何語義，這意味着，除非客戶端和服務器在消息語義上達成一致，不然沒法路由或處理消息。

經過HTTP握手請求上的Sec-WebSocket-Protocolheader，WebSocket客戶端和服務器能夠協商使用更高級別的消息傳遞協議（例如STOMP），在沒有這些的狀況下，他們須要制定本身的約定。

什麼時候使用WebSockets

WebSockets能夠使一個web頁面成爲動態的和交互式的，然而，在許多狀況下，Ajax和HTTP流或長輪詢的組合能夠提供簡單而有效的解決方案。

例如，新聞、郵件和社交提要須要動態更新，但每隔幾分鐘更新一次可能徹底沒有問題，另外一方面，協做、遊戲和金融應用程序須要更接近實時。

延遲自己並非決定性因素，若是消息量相對較低（例如，監視網絡故障），HTTP流或輪詢能夠提供有效的解決方案，正是低延遲、高頻率和高容量的組合，使WebSocket的使用成爲最好的例子。

還要記住，在Internet上，超出你控制範圍的限制性代理可能會妨礙WebSocket交互，要麼是由於它們沒有配置爲傳遞Upgrade header，要麼是由於它們關閉了看起來空閒的長鏈接，這意味着對於防火牆內的內部應用程序使用WebSocket比面向公共的應用程序更直接。

---

下一篇：WebSocket API