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模塊中包含的類和接口進行分析。

1、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鏈接。

 

2、 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接口。

 

3、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()方法替代。

 

4、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客戶端接收到的或發送過去的消息處理。

 

5、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實例並代理它。

 

6、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進行鏈接。

 

7、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。

 

8、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源碼徹底解析