Spring WebSocket詳解

Spring框架從4.0版開始支持WebSocket，下面我將詳述Spring WebSocket庫的相關內容。內容包括Spring框架是如何在Web應用中支持WebSocket方式的消息通信，以及如何利用STOMP協議作為應用層的協議——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協議。此方案可以通過配置來自動切換，無需修改應用程序的代碼。

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

在Web應用中，客戶端和服務器端需要以較高頻率和較低延遲來交換事件時，適合用WebSocket。因此WebSocket適合財經、游戲、協作等應用場景。
對于其他應用場景則未必適合。例如，某個新聞訂閱需要顯示突發新聞，使用間隔幾分鐘的長輪詢也是可以的，這里的延遲可以接受。
即使在要求低延遲的應用場景，如果傳輸的消息數很低（比如監測網絡故障的場景），那么應該考慮使用長輪詢技術。

而只有在低延遲和高頻消息通信的場景下，選用WebSocket協議才是非常適合的。即使是這樣的應用場景，仍然存在是選擇WebSocket通信呢？又或者是選擇REST HTTP通信呢？
答案是會根據應用程序的需求而定。但是，也可能同時使用這兩種技術，把需要頻繁交換的數據放到WebSocket中實現，而把REST API作為過程性的業務的實現技術。另外，當REST API的調用中需要把某個信息廣播給多個客戶端是，也可以通過WebSocket連接來實現。

Spring框架提供了@Controller注釋和@RestController注釋，兩者都可以用于HTTP請求的處理以及 WebSocket消息的處理。另外，Spring MVC的請求處理方法，或其它應用程序的請求處理方法，都可以很容易地使用WebSocket協議來廣播消息到所有感興趣的客戶端或指定用戶。