SockJS 备用方案
在公共互联网上,您无法控制的限制性代理可能会阻止 WebSocket 交互,原因可能是它们未配置为传递 Upgrade 头,或者它们关闭了看起来空闲的长期连接。
此问题的解决方案是 WebSocket 仿真——即,首先尝试使用 WebSocket,然后在必要时回退到基于 HTTP 的技术,这些技术模仿 WebSocket 交互并暴露相同的应用层 API。
在 Servlet 栈上,Spring Framework 为 SockJS 协议提供了服务器(以及客户端)支持。
概述
SockJS 的目标是让应用程序使用 WebSocket API,但在运行时必要时回退到非 WebSocket 替代方案,而无需更改应用程序代码。
SockJS 包括:
-
SockJS JavaScript 客户端——用于浏览器中的客户端库。
-
SockJS 服务器实现,包括 Spring Framework
spring-websocket模块中的一个。 -
spring-websocket模块中的 SockJS Java 客户端(自 4.1 版起)。
SockJS 专为浏览器使用而设计。它使用各种技术来支持广泛的浏览器版本。有关 SockJS 传输类型和浏览器的完整列表,请参阅 SockJS 客户端页面。传输分为三大类:WebSocket、HTTP 流和 HTTP 长轮询。有关这些类别的概述,请参阅这篇博客文章。
SockJS 客户端首先发送 GET /info 以从服务器获取基本信息。之后,它必须决定使用哪种传输。如果可能,将使用 WebSocket。如果不可能,在大多数浏览器中,至少有一个 HTTP 流选项。如果都没有,则使用 HTTP(长)轮询。
所有传输请求都具有以下 URL 结构:
https://host:port/myApp/myEndpoint/{server-id}/{session-id}/{transport}
其中:
-
{server-id}对于在集群中路由请求很有用,但在其他情况下不使用。 -
{session-id}关联属于 SockJS 会话的 HTTP 请求。 -
{transport}指示传输类型(例如,websocket、xhr-streaming等)。
WebSocket 传输只需一个 HTTP 请求即可完成 WebSocket 握手。此后,所有消息都在该套接字上交换。
HTTP 传输需要更多请求。例如,Ajax/XHR 流依赖于一个用于服务器到客户端消息的长时间运行请求,以及用于客户端到服务器消息的额外 HTTP POST 请求。长轮询类似,只是它在每次服务器到客户端发送后结束当前请求。
SockJS 添加了最小的消息帧。例如,服务器最初发送字母 o(“打开”帧),消息以 a["message1","message2"](JSON 编码数组)形式发送,如果 25 秒内(默认)没有消息流,则发送字母 h(“心跳”帧),以及发送字母 c(“关闭”帧)以关闭会话。
要了解更多信息,请在浏览器中运行一个示例并观察 HTTP 请求。SockJS 客户端允许固定传输列表,因此可以一次查看一个传输。SockJS 客户端还提供了一个调试标志,可在浏览器控制台中启用有用的消息。在服务器端,您可以为 org.springframework.web.socket 启用 TRACE 日志记录。有关更多详细信息,请参阅 SockJS 协议叙述性测试。
启用 SockJS
您可以通过配置启用 SockJS,如以下示例所示:
-
Java
-
Kotlin
-
Xml
@Configuration
@EnableWebSocket
public class WebSocketConfiguration implements WebSocketConfigurer {
@Override
public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
registry.addHandler(myHandler(), "/myHandler").withSockJS();
}
@Bean
public WebSocketHandler myHandler() {
return new MyHandler();
}
}
@Configuration
@EnableWebSocket
class WebSocketConfiguration : WebSocketConfigurer {
override fun registerWebSocketHandlers(registry: WebSocketHandlerRegistry) {
registry.addHandler(myHandler(), "/myHandler").withSockJS()
}
@Bean
fun myHandler(): WebSocketHandler {
return MyHandler()
}
}
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:websocket="http://www.springframework.org/schema/websocket"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/websocket
https://www.springframework.org/schema/websocket/spring-websocket.xsd">
<websocket:handlers>
<websocket:mapping path="/myHandler" handler="myHandler"/>
<websocket:sockjs/>
</websocket:handlers>
<bean id="myHandler" class="org.springframework.docs.web.websocket.websocketserverhandler.MyHandler"/>
</beans>
上述示例用于 Spring MVC 应用程序,应包含在 DispatcherServlet 的配置中。然而,Spring 的 WebSocket 和 SockJS 支持不依赖于 Spring MVC。在 SockJsHttpRequestHandler 的帮助下,将其集成到其他 HTTP 服务环境相对简单。
在浏览器端,应用程序可以使用 sockjs-client(版本 1.0.x)。它模拟 W3C WebSocket API 并与服务器通信,根据运行的浏览器选择最佳传输选项。请参阅 sockjs-client 页面以及浏览器支持的传输类型列表。客户端还提供了几个配置选项——例如,指定要包含哪些传输。
IE 8 和 9
Internet Explorer 8 和 9 仍在被使用。它们是使用 SockJS 的一个关键原因。本节涵盖了在这些浏览器中运行的重要注意事项。
SockJS 客户端通过使用 Microsoft 的 XDomainRequest 来支持 IE 8 和 9 中的 Ajax/XHR 流。这可以跨域工作,但不支持发送 cookie。Cookie 对于 Java 应用程序通常至关重要。然而,由于 SockJS 客户端可以与许多服务器类型(不仅仅是 Java 服务器)一起使用,它需要知道 cookie 是否重要。如果重要,SockJS 客户端倾向于使用 Ajax/XHR 进行流传输。否则,它依赖于基于 iframe 的技术。
SockJS 客户端的第一个 /info 请求是获取可能影响客户端传输选择的信息的请求。其中一个细节是服务器应用程序是否依赖 cookie(例如,用于身份验证目的或使用粘性会话进行集群)。Spring 的 SockJS 支持包含一个名为 sessionCookieNeeded 的属性。由于大多数 Java 应用程序依赖于 JSESSIONID cookie,因此默认启用此属性。如果您的应用程序不需要它,您可以关闭此选项,然后 SockJS 客户端应在 IE 8 和 9 中选择 xdr-streaming。
如果您确实使用基于 iframe 的传输,请记住,可以通过将 HTTP 响应头 X-Frame-Options 设置为 DENY、SAMEORIGIN 或 ALLOW-FROM <origin> 来指示浏览器阻止在给定页面上使用 IFrames。这用于防止点击劫持。
|
Spring Security 3.2+ 支持在每个响应上设置 |
如果您的应用程序添加了 X-Frame-Options 响应头(应该如此!),并且依赖于基于 iframe 的传输,则需要将头值设置为 SAMEORIGIN 或 ALLOW-FROM <origin>。Spring SockJS 支持还需要知道 SockJS 客户端的位置,因为它从 iframe 加载。默认情况下,iframe 设置为从 CDN 位置下载 SockJS 客户端。建议配置此选项以使用与应用程序同源的 URL。
以下示例展示了如何在 Java 配置中实现:
@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/portfolio").withSockJS()
.setClientLibraryUrl("https://:8080/myapp/js/sockjs-client.js");
}
// ...
}
XML 命名空间通过 <websocket:sockjs> 元素提供了类似的选项。
在初始开发期间,请启用 SockJS 客户端 devel 模式,该模式可防止浏览器缓存 SockJS 请求(如 iframe),否则这些请求将被缓存。有关如何启用它的详细信息,请参阅 SockJS 客户端页面。 |
心跳
SockJS 协议要求服务器发送心跳消息,以防止代理认为连接已挂起。Spring SockJS 配置有一个名为 heartbeatTime 的属性,您可以使用它来自定义频率。默认情况下,如果该连接上没有其他消息发送,则在 25 秒后发送心跳。此 25 秒的值符合以下针对公共互联网应用程序的 IETF 建议。
| 在使用 STOMP over WebSocket 和 SockJS 时,如果 STOMP 客户端和服务器协商交换心跳,则 SockJS 心跳将被禁用。 |
Spring SockJS 支持还允许您配置 TaskScheduler 以调度心跳任务。任务调度器由一个线程池支持,默认设置基于可用处理器数量。您应该考虑根据您的具体需求自定义设置。
客户端断开连接
HTTP 流和 HTTP 长轮询 SockJS 传输需要连接保持打开状态的时间比通常更长。有关这些技术的概述,请参阅这篇博客文章。
在 Servlet 容器中,这是通过 Servlet 3 异步支持完成的,该支持允许退出 Servlet 容器线程,处理请求,并从另一个线程继续写入响应。
一个具体的问题是 Servlet API 不提供客户端断开连接的通知。请参阅 eclipse-ee4j/servlet-api#44。但是,Servlet 容器在后续尝试写入响应时会引发异常。由于 Spring 的 SockJS 服务支持服务器端心跳(默认每 25 秒),这意味着客户端断开连接通常在该时间段内检测到(或者如果消息发送更频繁,则更早)。
因此,客户端断开连接可能导致网络 I/O 故障,这会使日志充满不必要的堆栈跟踪。Spring 尽力识别表示客户端断开连接的此类网络故障(特定于每个服务器),并使用专用日志类别 DISCONNECTED_CLIENT_LOG_CATEGORY(在 AbstractSockJsSession 中定义)记录最少的消息。如果您需要查看堆栈跟踪,可以将该日志类别设置为 TRACE。 |
SockJS 和 CORS
如果您允许跨源请求(请参阅允许的来源),SockJS 协议在 XHR 流和轮询传输中为跨域支持使用 CORS。因此,除非检测到响应中存在 CORS 头,否则会自动添加 CORS 头。因此,如果应用程序已配置为提供 CORS 支持(例如,通过 Servlet 过滤器),Spring 的 SockJsService 将跳过此部分。
通过在 Spring 的 SockJsService 中设置 suppressCors 属性,也可以禁用这些 CORS 头的添加。
SockJS 期望以下头和值:
-
Access-Control-Allow-Origin:从Origin请求头的值初始化。 -
Access-Control-Allow-Credentials:始终设置为true。 -
Access-Control-Request-Headers:从等效请求头的值初始化。 -
Access-Control-Allow-Methods:传输支持的 HTTP 方法(请参阅TransportType枚举)。 -
Access-Control-Max-Age:设置为 31536000(1 年)。
有关确切实现,请参阅 AbstractSockJsService 中的 addCorsHeaders 和源代码中的 TransportType 枚举。
或者,如果 CORS 配置允许,请考虑排除带有 SockJS 端点前缀的 URL,从而让 Spring 的 SockJsService 处理它。
SockJsClient
Spring 提供了一个 SockJS Java 客户端,用于连接远程 SockJS 端点而无需使用浏览器。当两个服务器之间需要通过公共网络进行双向通信时(即,网络代理可能阻止使用 WebSocket 协议),这尤其有用。SockJS Java 客户端对于测试目的也非常有用(例如,模拟大量并发用户)。
SockJS Java 客户端支持 websocket、xhr-streaming 和 xhr-polling 传输。其余的仅适用于浏览器使用。
您可以使用以下方式配置 WebSocketTransport:
-
JSR-356 运行时中的
StandardWebSocketClient。 -
使用 Jetty 9+ 原生 WebSocket API 的
JettyWebSocketClient。 -
Spring 的
WebSocketClient的任何实现。
XhrTransport,根据定义,支持 xhr-streaming 和 xhr-polling,因为从客户端的角度来看,除了用于连接服务器的 URL 之外,没有其他区别。目前有两种实现:
-
RestTemplateXhrTransport使用 Spring 的RestTemplate进行 HTTP 请求。 -
JettyXhrTransport使用 Jetty 的HttpClient进行 HTTP 请求。
以下示例展示了如何创建 SockJS 客户端并连接到 SockJS 端点:
List<Transport> transports = new ArrayList<>(2);
transports.add(new WebSocketTransport(new StandardWebSocketClient()));
transports.add(new RestTemplateXhrTransport());
SockJsClient sockJsClient = new SockJsClient(transports);
sockJsClient.doHandshake(new MyWebSocketHandler(), "ws://example.com:8080/sockjs");
SockJS 使用 JSON 格式的数组来表示消息。默认情况下,使用 Jackson 2,并且需要将其添加到类路径中。或者,您可以配置 SockJsMessageCodec 的自定义实现,并在 SockJsClient 上进行配置。 |
要使用 SockJsClient 模拟大量并发用户,您需要配置底层 HTTP 客户端(用于 XHR 传输)以允许足够的连接和线程。以下示例展示了如何使用 Jetty 实现:
HttpClient jettyHttpClient = new HttpClient();
jettyHttpClient.setMaxConnectionsPerDestination(1000);
jettyHttpClient.setExecutor(new QueuedThreadPool(1000));
以下示例显示了您还应该考虑自定义的服务器端 SockJS 相关属性(有关详细信息,请参阅 javadoc):
@Configuration
public class WebSocketConfig extends WebSocketMessageBrokerConfigurationSupport {
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/sockjs").withSockJS()
.setStreamBytesLimit(512 * 1024) (1)
.setHttpMessageCacheSize(1000) (2)
.setDisconnectDelay(30 * 1000); (3)
}
// ...
}
| 1 | 将 streamBytesLimit 属性设置为 512KB(默认值为 128KB — 128 * 1024)。 |
| 2 | 将 httpMessageCacheSize 属性设置为 1,000(默认值为 100)。 |
| 3 | 将 disconnectDelay 属性设置为 30 秒(默认值为 5 秒 — 5 * 1000)。 |