WebSocket API

Spring Framework 提供了一个 WebSocket API，你可以用它来编写处理 WebSocket 消息的客户端和服务器端应用程序。

WebSocketHandler

创建一个 WebSocket 服务器就像实现 WebSocketHandler 一样简单，或者更常见的是，扩展 TextWebSocketHandler 或 BinaryWebSocketHandler。以下示例使用了 TextWebSocketHandler：

有专门的 WebSocket 编程配置和 XML 命名空间支持，用于将上述 WebSocket 处理器映射到特定的 URL，如以下示例所示：

上述示例用于 Spring MVC 应用程序，应包含在 DispatcherServlet 的配置中。然而，Spring 的 WebSocket 支持不依赖于 Spring MVC。在 WebSocketHttpRequestHandler 的帮助下，将 WebSocketHandler 集成到其他 HTTP 服务环境相对简单。

当直接使用 WebSocketHandler API 而不是间接使用时，例如通过 STOMP 消息传递，应用程序必须同步消息的发送，因为底层标准 WebSocket 会话 (JSR-356) 不允许并发发送。一个选项是使用 ConcurrentWebSocketSessionDecorator 包装 WebSocketSession。

WebSocket 握手

自定义初始 HTTP WebSocket 握手请求最简单的方法是通过 HandshakeInterceptor，它公开了 “握手前” 和 “握手后” 的方法。你可以使用这样的拦截器来阻止握手，或者使任何属性可用于 WebSocketSession。以下示例使用内置拦截器将 HTTP 会话属性传递给 WebSocket 会话：

一个更高级的选项是扩展执行 WebSocket 握手步骤的 DefaultHandshakeHandler，包括验证客户端来源、协商子协议和其他详细信息。如果应用程序需要配置自定义 RequestUpgradeStrategy 以适应尚未支持的 WebSocket 服务器引擎和版本，可能还需要使用此选项（有关此主题的更多信息，请参阅 部署）。Java 配置和 XML 命名空间都允许配置自定义 HandshakeHandler。

Spring 提供了一个 WebSocketHandlerDecorator 基类，你可以使用它来装饰 WebSocketHandler，增加额外的行为。在使用 WebSocket Java 配置或 XML 命名空间时，默认提供并添加日志和异常处理实现。ExceptionWebSocketHandlerDecorator 捕获所有从任何 WebSocketHandler 方法产生的未捕获异常，并以状态 1011 关闭 WebSocket 会话，表示服务器错误。

部署

Spring WebSocket API 易于集成到 Spring MVC 应用程序中，其中 DispatcherServlet 同时处理 HTTP WebSocket 握手和其他 HTTP 请求。它也易于通过调用 WebSocketHttpRequestHandler 集成到其他 HTTP 处理场景中。这既方便又易于理解。然而，对于 JSR-356 运行时，需要考虑一些特殊事项。

Jakarta WebSocket API (JSR-356) 提供了两种部署机制。第一种涉及在启动时进行 Servlet 容器类路径扫描（Servlet 3 功能）。另一种是在 Servlet 容器初始化时使用的注册 API。这两种机制都无法为所有 HTTP 处理（包括 WebSocket 握手和所有其他 HTTP 请求）使用单个 “前端控制器”，例如 Spring MVC 的 DispatcherServlet。

这是 JSR-356 的一个重大限制，Spring 的 WebSocket 支持通过特定于服务器的 RequestUpgradeStrategy 实现来解决，即使在 JSR-356 运行时中运行也是如此。目前，Tomcat、Jetty、GlassFish、WebLogic、WebSphere 和 Undertow（以及 WildFly）都存在这样的策略。从 Jakarta WebSocket 2.1 开始，提供了一个标准的请求升级策略，Spring 在 Jakarta EE 10 基于 Web 容器（如 Tomcat 10.1 和 Jetty 12）上选择该策略。

次要的考虑是，具有 JSR-356 支持的 Servlet 容器预计会执行 ServletContainerInitializer (SCI) 扫描，这可能会减慢应用程序启动速度——在某些情况下，会显著减慢。如果在升级到具有 JSR-356 支持的 Servlet 容器版本后观察到显著影响，则可以通过在 web.xml 中使用 <absolute-ordering /> 元素来选择性地启用或禁用 Web 片段（和 SCI 扫描），如以下示例所示：

<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
		https://jakarta.ee/xml/ns/jakartaee
		https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
	version="5.0">

	<absolute-ordering/>

</web-app>

然后，你可以按名称选择性地启用 Web 片段，例如 Spring 自己的 SpringServletContainerInitializer，它为 Servlet 3 Java 初始化 API 提供支持。以下示例展示了如何实现：

<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
		https://jakarta.ee/xml/ns/jakartaee
		https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
	version="5.0">

	<absolute-ordering>
		<name>spring_web</name>
	</absolute-ordering>

</web-app>

配置服务器

你可以配置底层 WebSocket 服务器，例如输入消息缓冲区大小、空闲超时等。

对于 Jakarta WebSocket 服务器，你可以在配置中添加一个 ServletServerContainerFactoryBean。例如：

对于客户端 Jakarta WebSocket 配置，请在编程配置中使用 ContainerProvider.getWebSocketContainer()，或在 XML 中使用 WebSocketContainerFactoryBean。

对于 Jetty，你可以提供一个回调来配置 WebSocket 服务器：

在使用基于 WebSocket 的 STOMP 时，你还需要配置 STOMP WebSocket 传输 属性。

允许的来源

从 Spring Framework 4.1.5 开始，WebSocket 和 SockJS 的默认行为是只接受同源请求。也可以允许所有或指定来源列表。此检查主要为浏览器客户端设计。没有什么能阻止其他类型的客户端修改 Origin 头部值（有关更多详细信息，请参阅 RFC 6454: The Web Origin Concept）。

三种可能的行为是：

  • 只允许同源请求（默认）：在此模式下，当启用 SockJS 时，Iframe HTTP 响应头 X-Frame-Options 被设置为 SAMEORIGIN，并且禁用 JSONP 传输，因为它不允许检查请求的来源。因此，在此模式下不支持 IE6 和 IE7。

  • 允许指定来源列表：每个允许的来源必须以 http:// 或 https:// 开头。在此模式下，当启用 SockJS 时，IFrame 传输被禁用。因此，在此模式下不支持 IE6 到 IE9。

  • 允许所有来源：要启用此模式，你应该提供 * 作为允许的来源值。在此模式下，所有传输都可用。

你可以配置 WebSocket 和 SockJS 允许的来源，如以下示例所示：