Spring框架之websocket原始碼完全解析
Spring框架之websocket原始碼完全解析
Spring框架從4.0版開始支援WebSocket，先簡單介紹WebSocket協議（詳細介紹參見“WebSocket協議中文版”https://www.cnblogs.com/xxkj/p/14273710.html）。
1、WebSocket協議介紹
WebSocket協議是RFC-6455規範定義的一個Web領域的重要的功能：全雙工，即客戶端和伺服器之間的雙向通訊。它是一個令人興奮的功能，業界在此領域上已經探索很久，使用的技術包括Java Applet、XMLHttpRequest、Adobe Flash、ActiveXObject、各種Comet技術、伺服器端的傳送事件等。
需要理解一點，在使用WebSocket協議前，需要先使用HTTP協議用於構建最初的握手。這依賴於一個機制——建立HTTP，請求協議升級（或叫協議轉換）。當伺服器同意後，它會響應HTTP狀態碼101，表示同意切換協議。假設通過TCP套接字成功握手，HTTP協議升級請求通過，那麼客戶端和伺服器端都可以彼此互發訊息。
Spring框架4.0以上版本引入了一個新模組，即spring-websocket模組。它對WebSocket通訊提供了支援。它相容Java WebSocket API規範JSR-356，同時提供了額外的功能。
2、WebSocket的降級選項
瀏覽器對WebSocket的支援並不快，IE瀏覽器是第10版才開始支援的。此外，一些代理工具也會限制WebSocket通訊。因此，即使是現在要開發WebSocket應用，降級選項是必不可少的，以便在不支援的場景使用模擬WebSocket API的工作方式。Spring框架提供了這種透明的降級方案——使用SockJS協議。此方案可以通過配置來自動切換，無需修改應用程式的程式碼。
SockJS是WebSocket技術的一種模擬，在表面上，它儘可能對應WebSocket API，但是在底層它非常智慧。SockJS會優先選用WebSocket，但是如果WebSocket不可用的話，它將會從如下的方案中挑選最優的可行方案：XHR流、XDR流、iFrame事件源、iFrame HTML檔案、XHR輪詢、XDR輪詢、iFrame XHR輪詢、JSONP輪詢。
3、訊息通訊架構
使用WebSocket除了開發方面的挑戰外，還有一個難點在於設計上的考慮。
目前REST架構是一個廣泛接受、易於理解、適合構建現代Web應用的架構。REST架構依賴於很多URL和幾個HTTP方法，使用了連結、保持無狀態等原則。
相比之下WebSocket應用可能只使用一個URL用於最初的HTTP握手。隨後所有的訊息都共享此TCP連線，訊息在此連線上雙向流動。這一點可見，它與REST架構是完全不同的，是非同步的、事件驅動的、訊息傳遞的架構。WebSocket架構與傳統的訊息傳輸方案（如JMS、AMQP）比較相似。
Spring框架4.0引入了一個新模組——spring-messaging模組，它包含了很多來自於Spring Integration專案中的概念抽象，比如：Message訊息、訊息頻道MessageChannel、訊息控制代碼MessageHandler等。此模組還包括了一套註釋，可以把訊息對映到方法上，與Spring MVC基於註釋的程式設計模型相似。
4、WebSocket支援子協議
WebSocket只是一個訊息傳遞的體系結構，它沒有指定任何特定的訊息傳遞協議。它是一個TCP協議之上的超薄層，可以把位元組流轉換成訊息流（文字或二進位制）。隨後由應用程式來解釋訊息。
與HTTP協議不同，WebSocket協議只是一個應用級的協議，它非常簡單，並不能理解傳入的訊息，也不能對訊息進行路由或處理。因此WebSocket協議是應用級協議的底層，其上需要一個框架來理解和處理訊息。
出於這個原因，WebSocket RFC定義了子協議的使用。在握手過程中，客戶端和伺服器端可以使用Header部分的Sec-WebSocket-Protocol來協商使用的子協議——也即使用更高階的應用級協議。子協議的使用不是必須的，但即使不使用子協議，應用程式仍然需要選擇一個訊息格式——讓客戶端和伺服器相互可以理解的格式。這種格式可以自定義，或特定於框架，或使用標準的訊息傳遞協議。
Spring框架提供了對使用STOMP子協議的支援。
STOMP，Streaming Text Orientated Message Protocol，流文字定向訊息協議。STOMP是一個簡單的訊息傳遞協議， 是一種為MOM（Message Oriented Middleware，面向訊息的中介軟體）設計的簡單文字協議。
STOMP提供了一個可互操作的連線格式，允許STOMP客戶端與任意STOMP訊息代理（Broker）進行互動，類似於OpenWire協議（一種二進位制協議）。
5、WebSocket 和HTTP的區別
WebSocket建立在 TCP 之上，同 HTTP 一樣通過 TCP 來傳輸資料，它和 HTTP 不同之處有：
（1）HTTP 和 WebSocket 是兩種不同的協議，但是HTTP負責了建立WebSocket的連線。
（2）HTTP 請求以 http:// 或 https:// 開始，WebSocket 請求一般以ws:// 或 wss:// 開始。
（3）所有瀏覽器都支援 HTTP 協議，WebSocket 可以會遇到不支援的瀏覽器（可通過SockJS解決）。
（4）HTTP長連線中，每次資料交換除了真正的資料部分外，伺服器和客戶端還要大量交換HTTP header，資訊交換效率很低。Websocket協議通過第一個request建立了TCP連線之後，之後交換的資料都不需要傳送 HTTP header就能交換資料。
（5）WebSocket 是一種雙向通訊協議，在建立連線後，WebSocket 伺服器和 Browser/ Client Agent 都能主動的向對方傳送或接收資料，就像 Socket 一樣。
（6）WebSocket 需要類似 TCP 的客戶端和伺服器端通過握手連線，連線成功後才能相互通訊。
6、WebSocket使用場景
在Web應用中，客戶端和伺服器端需要以較高頻率和較低延遲來交換事件時，適合用WebSocket。因此WebSocket適合財經、遊戲、協作等應用場景。
對於其他應用場景則未必適合。例如，某個新聞訂閱需要顯示突發新聞，使用間隔幾分鐘的長輪詢也是可以的，這裡的延遲可以接受。
即使在要求低延遲的應用場景，如果傳輸的訊息數很低（比如監測網路故障的場景），那麼應該考慮使用長輪詢技術。
而只有在低延遲和高頻訊息通訊的場景下，選用WebSocket協議才是非常適合的。即使是這樣的應用場景，仍然存在是選擇WebSocket通訊還是選擇REST HTTP通訊。
答案是會根據應用程式的需求而定。但是，也可能同時使用這兩種技術，把需要頻繁交換的資料放到WebSocket中實現，而把REST API作為過程性的業務的實現技術。另外，當REST API的呼叫中需要把某個資訊廣播給多個客戶端時，也可以通過WebSocket連線來實現。
下面基於的Spring版本為5.2.4.BUILD-SNAPSHOT原始碼，對websocket模組中包含的類和介面進行分析。
一、web/socket/
1.1 WebSocketMessage：介面，可以在WebSocket連線上處理或傳送的訊息。
1.2 AbstractWebSocketMessage：抽象類，可以在WebSocket連線上處理或傳送的訊息。
1.3 BinaryMessage：二進位制WebSocket訊息。
1.4 TextMessage：文字WebSocket訊息。
一個幀有一個相應的型別。屬於相同訊息的每一幀包含相同型別的資料。從廣義上講，有文字資料型別（它被解釋為UTF-8[RFC3629]文字）、二進位制資料型別（它的解釋是留給應用）、和控制幀型別（它不包含用於應用的資料，而是協議級的訊號，例如應關閉連線的訊號）。
1.5 PingMessage：一個WebSocket ping訊息。
Ping幀包含0x9操作碼。
Ping幀可以包含“應用資料”。
當接收到一個ping幀時，一個端點必須在響應中傳送一個Pong幀，除非它早已接收到一個關閉幀。它應該儘可能快地以Pong幀響應。
一個端點可以在連線建立之後並在連線關閉之前的任何時候傳送一個Ping幀。
一個Ping可以充當一個keepalive，也可以作為驗證遠端端點仍可響應的手段。
Ping幀是控制幀的一種。控制幀由操作碼確定，其中操作碼最重要的位是1。當前定義的用於控制幀的操作碼包括0x8 (Close)， 0x9 (Ping)，和0xA (Pong)。操作碼0xB-0xF保留用於未來尚未定義的控制幀。控制幀用於傳達有關WebSocket的狀態。控制幀可以插入到分片訊息的中間。所有的控制幀必須有一個125位元組的負載長度或者更少，必須不被分段。
1.6 PongMessage：一個WebSocket pong訊息。
Pong幀包含一個0xA操作碼。
一個Pong幀用來回應一個Ping幀時，必須包含一份在接收到的Ping幀的訊息體中完全相同的“應用資料”。
如果端點接收到一個Ping幀但是對於前一個Ping幀還沒有返回相應的Pong幀，端點可以選擇僅為最近處理的Ping幀傳送一個Pong幀。
一個Pong幀可以自發的進行傳送，充當單向的心跳。接收到一個自發的Pong幀時不需要回應一個Pong幀。
1.7 SubProtocolCapable：WebSocket處理器的介面，支援定義在RFC 6455中的子協議。
客戶端可能通過包含|Sec-WebSocket-Protocol|欄位在它的握手中使用一個特定的子協議請求伺服器。如果它被指定，伺服器需要在它的響應中包含同樣的欄位和一個選擇的子協議值用於建立連線。
1.8 CloseStatus：表示一個WebSocket連線關閉的原因。狀態時一個在1000到4999（包括）之間的一個整數數字。每一個狀態碼都必須有唯一的含義。
1000：表示正常關閉，意思是建議的連線已經完成了。
1001：表示端點“離開”，例如伺服器關閉或瀏覽器導航到其他頁面。
1002：表示端點因為協議錯誤而終止連線。
1003：表示端點由於它收到了不能接收的資料型別（例如，端點僅理解文字資料，但接收到了二進位制訊息）而終止連線。
1004：保留。可能在將來定義某具體的含義。
1005：是一個保留值，且不能由端點在關閉控制幀中設定此狀態碼。它被指定用在期待一個用於表示沒有狀態碼是實際存在的狀態碼的應用中。
1006：是一個保留值，且不能由端點在關閉控制幀中設定此狀態碼。它被指定用在期待一個用於表示連線異常關閉的狀態碼的應用中。
1007：表示端點因為訊息中接收到的資料是不符合訊息型別而終止連線（比如，文字訊息中存在非UTF-8 [RFC3629]資料）。
1008：表示端點因為接收到的訊息違反其策略而終止連線。這是一個當沒有其它合適狀態碼（例如1003或1009）或如果需要隱藏策略的具體細節時能被返回的通用狀態碼。
1009：表示端點因接收到的訊息對它的處理來說太大而終止連線。
1010：表示端點（客戶端）因為它期望伺服器協商一個或多個擴充套件，但伺服器沒有在WebSocket握手響應訊息中返回它們而終止連線。所需要的擴充套件列表應該出現在關閉幀的/reason/部分。注意，這個狀態碼不能被伺服器端使用，因為它可以使WebSocket握手失敗。
1011：表示伺服器端因為遇到了一個不期望的情況使它無法滿足請求而終止連線。
1015：是一個保留值，且不能由端點在關閉幀中被設定為狀態碼。它被指定用在期待一個用於表示連線由於執行TLS握手失敗而關閉的狀態碼的應用中（比如，伺服器證書不能驗證）。
1.9 WebSocketExtension：表示一個在RFC 6455中定義的WebSocket擴充套件。擴充套件提供了一種機制來實現選擇性加入的附加協議特性。
WebSocket客戶端可以請求RFC6455規範的擴充套件，且WebSocket伺服器可以接受一些或所有客戶端請求的擴充套件。伺服器不必響應不是客戶端請求的任何擴充套件。如果擴充套件引數包含在客戶端和伺服器之間的協商中，這些引數必須按照引數應用到的擴充套件規範來選擇。
1.10 WebSocketHandler：WebSocket訊息及其生命週期中的事件處理器。實現該介面的類最好也同時對本地的異常進行處理，如可以對異常進行記錄、使用1011（表示伺服器端因為遇到了一個不期望的情況使它無法滿足請求而終止連線）狀態碼關閉會話。
1.11 WebSocketHttpHeaders：繼承自org.springframework.http.HttpHeaders，增加對在RFC 6455 WebSocket規範中定義的HTTP頭部的支援。
頭欄位名：Sec-WebSocket-Key
相關資訊：該頭欄位僅用於WebSocket開啟階段握手。
|Sec-WebSocket-Key|頭欄位用於WebSocket開啟階段握手。它從客戶端傳送到伺服器，提供部分資訊用於伺服器檢驗它收到了一個有效的WebSocket握手。這有助於確保伺服器不接收正被濫用來發送資料給毫不知情的WebSocket伺服器的非WebSocket客戶端的連線（例如HTTP客戶端）。
|Sec-WebSocket-Key|頭欄位在一個HTTP請求中不能出現多於一個。
頭欄位名：Sec-WebSocket-Extensions
相關資訊：該頭欄位僅用於WebSocket開啟階段握手。
|Sec-WebSocket-Extensions|頭欄位用於WebSocket開啟階段握手。它最初是從客戶端傳送到伺服器，隨後從伺服器端傳送到客戶端，用來達成在整個連線階段的一組協議級擴充套件。
|Sec-WebSocket-Extensions|頭欄位在HTTP請求中可以出現多次（邏輯上等價於單個|Sec-WebSocket-Extensions|頭欄位包含的所有值）。但是，|Sec-WebSocket-Extensions|頭欄位在一個HTTP響應中必須不出現多於一次。
頭欄位名：Sec-WebSocket-Accept
相關資訊：該頭欄位僅用於WebSocket開啟階段握手。
|Sec-WebSocket-Accept|頭欄位用於WebSocket開啟階段握手。它從伺服器傳送到客戶端來確定伺服器願意啟動WebSocket連線。
|Sec-WebSocket-Accept|頭在一個HTTP響應中必須不出現多於一次。
頭欄位名：Sec-WebSocket-Protocol
相關資訊：該頭欄位僅用於WebSocket開啟階段握手。
|Sec-WebSocket-Protocol|頭欄位用於WebSocket開啟階段握手。它從客戶端傳送到伺服器端，並從伺服器端發回到客戶端來確定連線的子協議。這使指令碼可以選擇一個子協議和確定伺服器同一服務子協議。
|Sec-WebSocket-Protocol|頭欄位在一個HTTP請求中可以出現多次（邏輯上等價於|Sec-WebSocket-Protocol|頭欄位包含的所有值）。但是，|Sec-WebSocket-Protocol|頭欄位在一個HTTP響應必須不出現多於一次。
頭欄位名：Sec-WebSocket-Version
相關資訊：該頭欄位僅用於WebSocket開啟階段握手。
|Sec-WebSocket-Version|頭欄位用於WebSocket開啟階段握手。它從客戶端傳送到伺服器端來指定連線的協議版本。這能使伺服器正確解釋開啟階段握手和傳送資料的隨後資料。如果伺服器不能以安全的方式解釋資料則關閉連線。當從客戶端接收到不匹配伺服器端理解的版本是，WebSocket握手錯誤，|Sec-WebSocket-Version|頭欄位也從伺服器端傳送到客戶端。在這種情況下，頭欄位包括伺服器端支援的協議版本。
注意：如果沒有期望更高版本號，必然是向下相容低版本號。
|Sec-WebSocket-Version|頭欄位在一個HTTP響應中可以出現多次（邏輯行等價於單個|Sec-WebSocket-Version|透過自動包含的所有值）。但是，|Sec-WebSocket-Version|頭欄位在HTTP請求中必須不出現多於一次。
來自客戶端的握手看起來像如下形式：
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
來自伺服器的握手看起來像如下形式：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
1.12 WebSocketSession：一個WebSocket會話抽象。允許通過一個WebSocket連線傳送訊息，也可關閉該連線。核心函式：
sendMessage(WebSocketMessage<?> message)函式，用來發送一個WebSocket訊息，文字訊息或者二進位制訊息。
close(CloseStatus status)函式，使用給定的關閉狀態碼來關閉一個WebSocket連線。
二、 web/socket/adapter
2.1 NativeWebSocketSession：繼承自WebSocketSession介面，提供了getter方法來暴露本地的WebSocketSession。該介面會被AbstractWebSocketSession抽象類實現。
2.2 AbstractWebSocketSession：WebSocketSession介面實現類的抽象基類。其傳送訊息函式為sendMessage(WebSocketMessage<?> message)。
web/socket/adapter/jetty
2.3 JettyWebSocketHandlerAdapter：適配Jetty 9 WebSocket API的WebSocketHandler。
Jetty是基於Java語言編寫的一個開源servlet容器，為Jsp和servlet提供了執行環境，可以迅速為一些獨立執行的Java應用提供網路和web連線。
Jetty目前正在快速成長為一個優秀的 Servlet 引擎，但是Tomcat的地位還是沒辦法撼動，市場份額遠遠不及Tomcat的多。
2.4 JettyWebSocketSession：使用Jetty 9.4 WebSocket API的WebSocketSession。
2.5 WebSocketToJettyExtensionConfigAdapter：介面卡類，用於將一個WebSocketExtension轉換為Jetty ExtensionConfig。
web/socket/adapter/standard
2.6 ConvertingEncoderDecoderSupport：抽象基類，用於實現一個標準的javax.websocket.Encoder和/或javax.websocket.Decoder。該類通過委託給Spring的ConversionService實現了編碼和解碼方法。
預設情況下，該類使用”webSocketConversionService”名字查詢在ApplicationContext容器中註冊的一個ConversionService。
2.7 StandardToWebSocketExtensionAdapter：WebSocketExtension的子類，可以從一個javax.websocket.Extension構造。
2.8 StandardWebSocketHandlerAdapter：適配一個WebSocketHandler到基於Java API的標準WebSocket。
2.9 StandardWebSocketSession：用於基於Java API的標準WebSocket的WebSocketSession。
2.10 WebSocketToStandardExtensionAdapter：適配一個WebSocketExtension例項到javax.websocket.Extension介面。
三、web/socket/client
3.1 AbstractWebSocketClient：WebSocketClient介面實現類的抽象基類。
3.2 ConnectionManagerSupport：是WebSocketConnectionManager的基類。
3.3 WebSocketClient：負責初始化一個WebSocket請求。
3.4 WebSocketConnectionManager：在指定uri，WebsocketClient和websocketHandler時通過start()和stop()方法連線到websocket伺服器。如果setAutoStartup(boolean)設定為true，Spring的ApplicationContext容器重新整理時會自動連線。
web/socket/client/jetty
3.5 JettyWebSocketClient：通過Jetty WebSocket API，以程式設計方式傳送WebSocket請求到WebSocket伺服器。
web/socket/client/standard
3.6 AnnotatedEndpointConnectionManager：給定了一個URI、一個ClientEndpoint-annotated端點的WebSocket連線管理器，通過#start()和#stop()方法連線到一個WebSocket伺服器。如果setAutoStartup(boolean)設定為true時，當Spring ApplicationContext容器重新整理的時候這些會自動執行。
3.7 EndpointConnectionManager：給定了一個URI、一個端點的WebSocket連線管理器，通過#start()和#stop()方法連線到一個WebSocket伺服器。如果setAutoStartup(boolean)設定為true時，當Spring ApplicationContext容器重新整理的時候這些會自動執行。
3.8 StandardWebSocketClient：基於標準的Java WebSocket API的WebSocketClient。
3.9 WebSocketContainerFactoryBean：一個FactoryBean，通過Spring XML配置來建立和配置一個WebSocketContainer。在Java配置中，忽視該類，使用getWebSocketContainer()方法替代。
四、web/socket/config
4.1 HandlersBeanDefinitionParser：解析<websocket:handlers/>名稱空間元素。註冊一個Spring MVC SimpleUrlHanderMapping，用來將HTTP WebSocket握手（或者SockJS）請求對映到WebSocketHandlers。
SockJS 是一個瀏覽器上執行的 JavaScript 庫，如果瀏覽器不支援 WebSocket，該庫可以模擬對 WebSocket 的支援，實現瀏覽器和 Web 伺服器之間低延遲、全雙工、跨域的通訊通道。
4.2 MessageBrokerBeanDefinitionParser：一個BeanDefinitionParser，提供XML名稱空間元素<websocket:message-broker/>的配置。
4.3 WebSocketMessageBrokerStats：核心類，用於聚合setup的關鍵架構元件的內部狀態和計數資訊，這些元件Java配置帶了@EnableWebSocketMessageBroker，XML中帶了<websocket:message-broker>。
4.4 WebSocketNamespaceHandler：Spring WebSocket配置名稱空間的NamespaceHandler。
4.5 WebSocketNamespaceUtils：提供了功能性函式用於解析通用的WebSocket XML名稱空間元素。
web/socket/config/annotation
4.6 AbstractWebSocketHandlerRegistration：WebSocketHandlerRegistrations介面實現類的抽象基類，收集所有的配置選項，但是允許其子類組合真實的HTTP請求對映。
4.7 AbstractWebSocketMessageBrokerConfigurer：WebSocketMessageBrokerConfigurer實現類的抽象基類，為一些空方法實現了空實現。Spring 5.0中被廢棄，使用WebSocketMessageBrokerConfigurer替代。
4.8 DelegatingWebSocketConfiguration：WebSocketConfigurationSupport的一個變體，在Spring配置中檢測WebSocketConfigurer的實現類，呼叫他們用於配置WebSocket請求處理。
4.9 DelegatingWebSocketMessageBrokerConfiguration： WebSocketMessageBrokerConfigurationSupport的拓展，檢測WebSocketMessageBrokerConfigurer型別的bean，並代理這些bean允許對WebSocketMessageBrokerConfigurationSupport提供的配置進行回撥式定製。
4.10 EnableWebSocket：將該註解加到一個@configuration類，從而配置處理WebSocket請求。一個典型的配置如下：
@Configuration
@EnableWebSocket
public class MyWebSocketConfig {
}
4.11 EnableWebSocketMessageBroker：將該註解加到@Configuration類，使WebSocket上的broker-backed訊息使用更高階的訊息子協議。
@Configuration
@EnableWebSocketMessageBroker
public class MyWebSocketConfig {
}
4.12 ServletWebSocketHandlerRegistration：幫助類，用於配置包括SockeJS回退選項的WebSocketHandler請求處理。
4.13 ServletWebSocketHandlerRegistry：WebSocketHandlerRegistry介面實現類，使用了Spring MVC處理器對映，用於握手請求。
4.14 SockJsServiceRegistration：幫助類，配置SockJS回退選項，用於一個EnableWebSocket和WebSocketConfigurer setup。
4.15 StompEndpointRegistry：註冊WebSocket端點上的STOMP。
STOMP即Simple (or Streaming) Text Orientated Messaging Protocol，簡單(流)文字定向訊息協議，它提供了一個可互操作的連線格式，允許STOMP客戶端與任意STOMP訊息代理（Broker）進行互動。STOMP協議由於設計簡單，易於開發客戶端，因此在多種語言和多種平臺上得到廣泛地應用。
4.16 StompWebSocketEndpointRegistration：配置WebSocket端點上的一個STOMP。
4.17 WebMvcStompEndpointRegistry：註冊WebSocket端點上的STOMP，使用HandlerMapping對映端點。
4.18 WebMvcStompWebSocketEndpointRegistration：配置WebSocket/SockJS端點上的STOMP的抽象基類。
4.19 WebSocketConfigurationSupport：WebSocket請求處理的配置支援。
4.20 WebSocketConfigurer：定義了回撥方法，通過@EnableWebSocket註解來配置WebSocket 請求處理。
4.21 WebSocketHandlerRegistration：提供了配置一個WebSocket處理器的方法。
4.22 WebSocketHandlerRegistry：提供了配置WebSocketHandler請求對映的方法。
4.23 WebSocketMessageBrokerConfigurationSupport：拓展自AbstractMessageBrokerConfiguration，增加了配置用於接收或者回應從WebSocket客戶端來的STOMP訊息。
4.24 WebSocketMessageBrokerConfigurer：定義了使用來自WebSocket客戶端的簡單訊息協議（如STOMP）配置訊息處理的方法。
4.25 WebSocketTransportRegistration：配置從WebSocket客戶端接收到的或傳送過去的訊息處理。
五、web/socket/handler
5.1 AbstractWebSocketHandler：帶空方法的WebSocketHandler介面實現類的抽象基類。
5.2 BeanCreatingHandlerProvider：通過Spring BeanFactory初始化一個目標處理器，同樣也提供一個等價的銷燬函式。主要在內部使用，在每個連線生命週期中初始化和銷燬處理器。
5.3 BinaryWebSocketHandler：WebSocketHandler實現類的父類，僅用於處理二進位制訊息。
5.4 TextWebSocketHandler：WebSocketHandler實現類的父類，僅用於處理文字訊息。
5.5 ConcurrentWebSocketSessionDecorator：封裝一個WebSocketSession，以確保在一個時刻僅有一個執行緒可以傳送訊息。
5.6 ExceptionWebSocketHandlerDecorator：一個異常處理WebSocketHandlerDecorator。捕捉所有從裝飾處理器漏掉的Trowable例項，使用#SERVER_ERROR關閉狀態碼關閉這個會話。
5.7 LoggingWebSocketHandlerDecorator：繼承自WebSocketHandlerDecorator，對WebSocket生命週期的事件增加了日誌功能。
5.8 PerConnectionWebSocketHandler：繼承自WebSocketHandler，為每一個WebSocket連線初始化和銷燬一個WebSocketHandler例項，並將所有其他的方法委託給它。
5.9 SessionLimitExceededException：當一個WebSocket會話超過了配置的限制會引發該異常，比如事件、緩衝區大小等等。
5.10 WebSocketHandlerDecorator：封裝另一個WebSocketHandler例項，並代理它。
5.11 WebSocketHandlerDecoratorFactory：對一個WebSocketHandler應用裝飾器的工廠。
5.12 WebSocketSessionDecorator：封裝另一個WebSocketSession例項並代理它。
六、web/socket/messaging
6.1 AbstractSubProtocolEvent：從一個WebSocket客戶端接收到一個訊息並將其解析成更高級別的子協議（如STOMP）的事件的抽象基類。
6.2 DefaultSimpUserRegistry：SimpUserRegistry介面的預設實現類，依賴於應用上下文事件來跟蹤連線的使用者及其訂閱者。
6.3 SessionConnectedEvent：一個連線事件，表示伺服器對客戶單連線請求進行響應。
6.4 SessionConnectEvent：當一個新的WebSocket客戶端使用一個簡單訊息協議（如STOMP）作為WebSocket子協議來發送一個連線請求時引發該事件。
6.5 SessionDisconnectEvent：當WebSocket客戶端使用一個簡單訊息協議（如STOMP）作為WebSocket子協議的會話關閉時引發該事件。
6.6 SessionSubscribeEvent：當一個新的WebSocket客戶端使用一個簡單訊息協議（如STOMP）來發送一個訂閱請求時引發該事件。
6.7 SessionUnsubscribeEvent：當一個新的WebSocket客戶端使用一個簡單訊息協議（如STOMP）傳送一個請求去移除一個訂閱時引發該事件。
6.8 StompSubProtocolErrorHandler：使用STOMP的SubProtocolErrorHandler。
6.9 StompSubProtocolHandler：一個支援版本1.0，1.1和1.2的STOMP規範的SubProtocolHandler。
6.10 SubProtocolErrorHandler：處理髮送到客戶端的子協議錯誤。
6.11 SubProtocolHandler：處理WebSocket訊息，作為更高級別協議的一部分，被稱作WebSocket RFC規範中的“sub-protocol”。處理來自客戶端的WebSocketMessage和傳送到客戶端的訊息。
6.12 SubProtocolWebSocketHandler：WebSocketHandler介面的實現類，將收到的WebSocket訊息委託給SubProtocolHandler和MessageChannel。
6.13 WebSocketAnnotationMethodMessageHandler：SimpAnnotationMethodMessageHandler子類，提供了對帶全域性@MessageExceptionHandler方法的ControllerAdvice的支援。
6.14 WebSocketStompClient：WebSocket客戶端上的一個STOMP，使用WebSocketClient實現類包括SockJSClient進行連線。
七、web/socket/server
7.1 HandshakeFailureException：由於一個內部的、無法恢復的原因導致握手處理無法完成丟擲的異常。這表示一個伺服器錯誤（HTTP狀態碼500），而不是握手協商時產生的失敗。
7.2 HandshakeHandler：處理一個WebSocket握手請求。
7.3 HandshakeInterceptor：WebSocket握手請求的攔截器。可以用來檢查握手請求和響應，也可以將引數傳遞給目標WebSocketHandler。
7.4 RequestUpgradeStrategy：一個伺服器端特定的策略，用於對一個WebSocket互動執行實際的upgrade操作。
web/socket/server/jetty
7.5 JettyRequestUpgradeStrategy：使用Jetty 9.4的RequestUpgradeStrategy。基於Jetty內部的WebSocketHandler類。
web/socket/server/standard
7.6 AbstractStandardUpgradeStrategy：基於標準的WebSocket API的RequestUpgradeStrategy介面實現類的抽象基類。
7.7 AbstractTyrusRequestUpgradeStrategy：RequestUpgradeStrategy介面實現類的父類，這些策略在基於JSR-356的伺服器上實現，其中包括Tyrus作為其WebSocket引擎。
適用於Tyrus 1.11（WebLogic 12.2.1）和Tyrus 1.12（GlassFish 4.1.1）。
7.8 GlassFishRequestUpgradeStrategy：一個用於Oracle's GlassFish 4.1和更高版本的WebSocket RequestUpgradeStrategy。
GlassFish 是一款強健的商業相容應用伺服器，達到產品級質量，可免費用於開發、部署和重新分發。開發者可以免費獲得原始碼，還可以對程式碼進行更改。
7.9 ServerEndpointExporter：檢測ServerEndpointConfig型別的beans，並使用標準的Java WebSocket runtime註冊。同時檢測使用ServerEndpoint註解的beans，同樣也對其進行註冊。
7.10 ServerEndpointRegistration：ServerEndpointConfig介面實現類，在Spring-based應用中使用。
7.11 ServletServerContainerFactoryBean：用於配置ServerContainer的FactoryBean。
7.12 SpringConfigurator：繼承自Configurator，用於通過Spring初始化ServerEndpoint註解的類。
7.13 TomcatRequestUpgradeStrategy：用於Apache Tomcat的WebSocket RequestUpgradeStrategy。相容支援JSR-356的Tomcat的所有版本，比如Tomcat 7.0.47+ z或者更高的版本。
JSR 356 (Java API for WebSocket) 指定 Java 開發人員在希望將 WebSocket 整合到應用程式（同時在伺服器端和 Java 客戶端）時可以使用的 API。WebSocket 協議的每一個聲稱符合 JSR 356 的實現都必須實現此 API。
7.14 UndertowRequestUpgradeStrategy：用於WildFly 和它的Undertow web伺服器的WebSocket RequestUpgradeStrategy。
WildFly，原名 JBoss AS(JBoss Application Server) 或者 JBoss，是一套應用程式伺服器，屬於開源的企業級 Java 中介軟體軟體，用於實現基於 SOA 架構（面向服務的架構）的 Web 應用和服務。
Undertow 是紅帽公司開發的一款基於 NIO 的高效能 Web 嵌入式伺服器。
7.15 WebLogicRequestUpgradeStrategy：用於Oracle的 WebLogic的webSocket RequestUpgradeStrategy。
WebLogic是Oracle公司出品的一個application server，確切的說是一個基於Java EE架構的中介軟體，WebLogic是用於開發、整合、部署和管理大型分散式Web應用、網路應用和資料庫應用的Java應用伺服器。將Java的動態功能和Java Enterprise標準的安全性引入大型網路應用的開發、整合、部署和管理之中。Weblogic就是和我們常用的Tomcat差不多的部署Java web程式的伺服器。
7.16 WebSphereRequestUpgradeStrategy：WebSphere，支援在WebSocket握手時升級一個HttpServletRequest。
WebSphere 是 IBM 的軟體平臺。它包含了編寫、執行和監視全天候的工業強度的隨需應變 Web 應用程式和跨平臺、跨產品解決方案所需要的整個中介軟體基礎設施，如伺服器、服務和工具。WebSphere 提供了可靠、靈活和健壯的軟體。
web/socket/server/support
7.17 AbstractHandshakeHandler：HandshakeHandler實現類的抽象基類，獨立於Servlet API。
7.18 DefaultHandshakeHandler：HandshakeHandler介面的預設實現類，在父類AbstractHandshakeHandler基礎上拓展了Servlet-specific初始化支援。
7.19 HandshakeInterceptorChain：用於協助呼叫一列handshake攔截器。
7.20 HttpSessionHandshakeInterceptor：攔截器，用於將HTTP會話中的資訊拷貝到"handshake attributes" map中。
7.21 OriginHandshakeInterceptor：攔截器，基於“允許的origins值集合”對請求“Origin”頭的值進行檢查。
7.22 WebSocketHandlerMapping：繼承自SimpleUrlHandlerMapping，同時實現了SmartLifecycle，傳播start和stop呼叫到任意的處理器中。這些處理器一般是WebSocketHttpRequestHandler或SockJsHttpRequestHandler。
7.23 WebSocketHttpRequestHandler：一個處理WebSocket握手請求的HttpRequestHandler。
八、web/socket/sockjs
SockJS 是一個瀏覽器上執行的 JavaScript 庫，如果瀏覽器不支援 WebSocket，該庫可以模擬對 WebSocket 的支援，實現瀏覽器和 Web 伺服器之間低延遲、全雙工、跨域的通訊通道。
8.1 SockJsException：處理SockJS HTTP請求引發的異常的父類。
8.2 SockJsMessageDeliveryException：當通過HTTP POST方法成功接收和解析一個訊息幀，但是由於處理器失效或者連線關閉等原因，該訊息一個或多個幀不能被傳遞給WebSocketHandler時丟擲該異常。
8.3 SockJsService：處理來自SockJS客戶端的HTTP請求訊息的主入口。在一個Servlet 3+容器中，SockJsHttpRequestHandler能夠用來呼叫該服務。
8.4 SockJsTransportFailureException：表示在SockJS實現中發生了一個嚴重的錯誤，而不是在使用者程式碼中（比如，寫入到響應時傳送I/O錯誤）。當該異常引發時，SockJS會話通常會關閉。
web/socket/sockjs/client
8.5 AbstractClientSockJsSession：SockJS客戶端WebSocketSession實現類的父類。提供了對到來的SockJS訊息幀的處理，委託lifecyle事件和訊息給WebSocketHandler進行處理。其子類要實現send和disconnect。
8.6 XhrTransport：一個SockJS Transport，使用HTTP請求來模擬一個WebSocket互動。connect方法用來接收伺服器來的訊息，executeSendRequest()方法用來發送訊息。
8.7 AbstractXhrTransport：實現XhrTransport介面的抽象類。
8.8 TransportRequest：該介面通過各種get方法來暴露資訊，主要被Transport和session實現，關於連線到SockJS伺服器端點的請求的相關資訊。
8.9 DefaultTransportRequest：TransportRequest介面的預設實現類。
8.10 InfoReceiver：能夠執行SockJS “Info”請求的元件，需要在SockJS會話開始前執行，以堅持伺服器端點的能力，比如這個端點是否允許使用WebSocket。
8.11 JettyXhrTransport：基於Jetty的HttpClient的XHR transport。
xhr，全稱為XMLHttpRequest，用於與伺服器互動資料，是ajax功能實現所依賴的物件，jquery中的ajax就是對 xhr的封裝。
8.12 RestTemplateXhrTransport：使用一個RestTemplate的XhrTransport實現類。
8.13 SockJsClient：WebSocketClient的一個SockJS實現，帶了一個備用方案：通過純HTTP流和長輪詢模擬一個WebSocket互動。
8.14 SockJsUrlInfo：SockJS端點的基URL的容器，附帶獲取相關SockJS URLs的方法：getInfoUrl()和getTransportUrl(TransportType)
8.15 Transport：一個客戶端SockJS transport的實現。
8.16 UndertowXhrTransport：基於Undertow的UndertowClient的XHR transport。
Undertow 是紅帽公司開發的一款基於 NIO 的高效能 Web 嵌入式伺服器。
8.17 WebSocketClientSockJsSession：繼承自AbstractClientSockJsSession，封裝和代理一個實際的WebSocket會話。
8.18 WebSocketTransport：使用一個WebSocketClient的SockJS Transport。
8.19 XhrClientSockJsSession：繼承自AbstractClientSockJsSession，使用HTTP transports模擬一個WebSocket會話。
web/socket/sockjs/frame
8.20 AbstractSockJsMessageCodec：SockJS訊息編解碼器的基類，提供了encode(String[])的實現。
8.21 DefaultSockJsFrameFormat：SockJsFrameFormat介面的預設實現類，依賴於java.lang.String#format(String, Object...)。
8.22 Jackson2SockJsMessageCodec：一個Jackson 2.6+編解碼器，用於對SockJS訊息進行編碼和解碼。
8.23 SockJsFrame：表示一個SockJS幀，提供了建立SockJS幀的工廠方法。
8.24 SockJsFrameFormat：將一個transport-specific格式應用到SockJS幀的內容中，產生一個可以被寫出的內容。主要用在HTTP服務端transports推送資料。
8.25 SockJsFrameType：列舉類，枚舉了SockJS幀的型別，有OPEN，HEARTBEAT，MESSAGE，CLOSE。
8.26 SockJsMessageCodec： 將一個訊息編碼到SockJS訊息幀，或從一個SockJS訊息幀解碼出訊息，本質上是一組JSON編碼的訊息。例如：a["message1","message2"]。
web/socket/sockjs/support
8.27 AbstractSockJsService：SockJsService實現類的抽象基類，提供了SockJS路徑解決方案，處理靜態SockJS請求（比如，"/info", "/iframe.html"等等）。子類必須處理會話URLs（比如，transport-specific請求）。
預設情況下，只有同源的請求才允許。使用#setAllowedOrigins方法指定一列允許的源。
8.28 SockJsHttpRequestHandler：一個HttpRequestHandler，將一個SockJsService對映到在Servlet容器中的請求。
web/socket/sockjs/transport
8.29 SockJsServiceConfig：提供transport處理程式碼訪問SockJsServie配置選項。主要在內部使用。
8.30 SockJsSession：Spring標準的WebSocketSession關於SockJS的拓展。
8.31 SockJsSessionFactory：用於建立SockJS會話的工廠。
8.32 TransportHandler：處理一個SockJS會話URL，比如transport-specific請求。
8.33 TransportHandlingSockJsService：SockJsService的一個基本實現，支援基於SPI的transport處理和會話管理。
8.34 TransportType：列舉類，枚舉了SockJS transport型別。有：websocket、xhr、xhr_send、xhr_streaming、eventsource、htmlfile。
web/socket/sockjs/transport/handler
8.35 AbstractHttpReceivingTransportHandler：HTTP transport處理器的基類，通過HTTP POST方式接收訊息。
8.36 AbstractHttpSendingTransportHandler：HTTP transport處理器的基類，推送訊息到連線的客戶端。
8.37 AbstractTransportHandler：TransportHandler實現類的通用基類。
8.38 DefaultSockJsService：SockJsService的預設實現，帶所有預先註冊的預設TransportHandler實現類。
8.39 EventSourceTransportHandler：一個TransportHandler，用於通過服務端傳送事件來發送訊息。
8.40 HtmlFileTransportHandler：一個HTTP TransportHandler，使用知名的瀏覽器技術。
8.41 SockJsWebSocketHandler：WebSocketHandler實現類，增加了SockJS訊息幀，傳送SockJS心跳訊息，委託生命週期事件和訊息到一個目標WebSocketHandler。
8.42 WebSocketTransportHandler：基於WebSocket的TransportHandler。使用SockJsWebSocketHandler和WebSocketServerSockJsSession來增加SockJS處理。
8.43 XhrPollingTransportHandler：基於XHR長輪詢的TransportHandler。
8.44 XhrReceivingTransportHandler：一個TransportHandler，通過HTTP接收訊息。
8.45 XhrStreamingTransportHandler：一個TransportHandler，通過HTTP流請求來發送訊息。
web/socket/sockjs/transport/session
8.46 AbstractHttpSockJsSession：用於HTTP transport SockJS會話的抽象基類。
8.47 AbstractSockJsSession：SockJsSession介面實現類的抽象基類。
8.48 PollingSockJsSession：用於輪詢HTTP transport的SockJS會話。
8.49 StreamingSockJsSession：用於流式HTTP transport的SockJS會話。
8.50 WebSocketServerSockJsSession：用於WebSocket transport的SockJS會話。
參考：
【1】https://blog.csdn.net/fhadmin24/article/details/47055985
【2】https://www.cnblogs.com/xxkj/p/14273710.html
拓展閱讀：
WebSocket協議中文版
Spring框架之jdbc原始碼完全解析
Spring原始碼深度解析之資料庫連線JDBC
Spring框架之spring-webmvc原始碼完全解析
Spring原始碼深度解析之Spring MVC
Spring框架之spring-web web原始碼完全解析
Spring框架之spring-web http原始碼完全解析
Spring框架之jms原始碼完全解析
Spring框架之AOP原始碼完全解析
Spring框架之beans原始碼完全解析
&n