SpringBoot整合WebSocket详解( 二 )

  • WebSocket Handshake
要定制初始的HTTP WebSocket握手请求,最简单的方法是使用HandshakeInterceptor,它提供了握手前和握手后的方法 。你可以使用这样的拦截器来阻止握手,或者让 WebSocketSession可以访问任何属性 。下面的例子使用内置的拦截器将HTTP会话属性传递给WebSocket会话:
@Configuration@EnableWebSocketpublic class WebSocketConfig implements WebSocketConfigurer {@Overridepublic void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {registry.addHandler(messageHandler(), "/message").setHandshakeHandler(handshakeHandler())// 添加捂手拦截器.addInterceptors(new HandshakeInterceptor() {// 如果该方法返回false,则不允许建立连接@Overridepublic boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response,WebSocketHandler wsHandler, Map<String, Object> attributes) throws Exception {// todoattributes.put("uid", uid) ;return true ;}@Overridepublic void afterHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler,Exception exception) {// todo}}) ;}}
  • 部署
Spring WebSocket API很容易集成到Spring MVC应用程序中,DispatcherServlet可以同时处理HTTP WebSocket握手和其他HTTP请求 。调用
WebSocketHttpRequestHandler也很容易集成到其他HTTP处理场景中 。这样既方便又容易理解 。但是,对于JSR-356运行时,需要特别注意 。
JAVA WebSocket API (JSR-356)提供两种部署机制 。第一种方法涉及启动时的Servlet容器类路径扫描(Servlet 3特性)@ServerEndpoint 。另一个是Servlet容器初始化时使用的注册 API(ServletContAInerInitializer) 。这两种机制都不可能对所有HTTP处理使用单个“前端控制器” — 包括WebSocket握手和所有其他HTTP请求 — 如Spring MVC的DispatcherServlet 。
这是JSR-356的一个重要限制,Spring的WebSocket支持通过特定于服务器的RequestUpgradeStrategy实现来解决这个问题,即使运行在JSR-356运行时也是如此 。Tomcat、Jetty、GlassFish、WebLogic、WebSphere和Undertow(以及WildFly)目前都存在这样的策略 。
  • 服务配置
每个底层WebSocket引擎都公开了控制运行时特征的配置属性,例如消息缓冲区大小、空闲超时等 。
对于Tomcat、WildFly和GlassFish,可以在WebSocket Java配置中添加
ServletServerContainerFactoryBean,如下面的例子所示:
@Beanpublic ServletServerContainerFactoryBean servletServerContainerFactoryBean() {ServletServerContainerFactoryBean container = new ServletServerContainerFactoryBean() ;container.setMaxTextMessageBufferSize(8192) ;container.setMaxBinaryMessageBufferSize(8192) ;return container ;} 
  • 允许的来源
从Spring Framework 4.1.5开始,WebSocket和SockJS的默认行为是只接受同源请求 。也可以允许所有或指定的来源列表 。这个检查主要是为浏览器客户端设计的 。没有什么能阻止其他类型的客户端修改Origin首部值 。
三种可能的行为是:
  1. 仅允许同源请求(默认):在这种模式下,当启用SockJS时,Iframe HTTP响应头X-Frame-Options设置为SAMEORIGIN,并且禁用JSONP传输,因为它不允许检查请求的来源 。因此,启用此模式时,不支持IE6和IE7 。
  2. 允许指定的来源列表:每个允许的来源必须以http://或https://.开头在此模式下,当启用SockJS时,禁用IFrame传输 。因此,启用此模式时,将不支持IE6到IE9 。
  3. 允许所有来源:要启用此模式,你应该提供*作为允许的来源值 。在该模式下,所有传输通道都可用 。
@Configuration@EnableWebSocketpublic class WebSocketConfig implements WebSocketConfigurer {@Overridepublic void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {registry.addHandler(messageHandler(), "/message").setAllowedOriginPatterns("*") ;}}测试通过上面的介绍和配置,WebSocket环境就算是简单的配置完成了,接下来通过Postman进行测试 。
【SpringBoot整合WebSocket详解】
SpringBoot整合WebSocket详解

文章插图
图片
连接成功
SpringBoot整合WebSocket详解

文章插图
发送消息及接收消息
 
SpringBoot整合WebSocket详解

文章插图


推荐阅读