Spring框架之websocket源碼完全解析
Spring框架從4.0版開始支持WebSocket，先簡單介紹WebSocket協議。
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
拓展閱讀：
Spring框架之beans源碼完全解析
Spring框架之AOP源碼完全解析
Spring框架之jdbc源碼完全解析
Spring源碼深度解析之數據庫連接JDBC
Spring框架之jms源碼完全解析
Spring框架之事務源碼完全解析
Spring源碼深度解析之事務
Spring源碼深度解析之Spring MVC
Spring框架之websocket源碼完全解析
WebSocket協議中文版
Spring框架之spring-web web源碼完全解析
Spring框架之spring-web http源碼完全解析
Spring框架之spring-webmvc源碼完全解析