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，它公开了 “before” 和 “after” 握手的方法。您可以使用这样的拦截器来阻止握手或使任何属性可用于 WebSocketSession。以下示例使用内置拦截器将 HTTP 会话属性传递给 WebSocket 会话：

一个更高级的选项是扩展 DefaultHandshakeHandler，它执行 WebSocket 握手的步骤，包括验证客户端来源、协商子协议和其他细节。如果应用程序需要配置自定义 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 支持在 WebSocket API 2.1+ 运行时通过标准 RequestUpgradeStrategy 实现解决了这个问题。

次要的考虑是，具有 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 允许的来源，如以下示例所示：