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=>Upgradeheader。 -
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比面向公共的應用程式更直接。
—