Spring websocket 使用

项目中用到了消息的实时推送，查资料后用到了Spring websocket，找了很多资料，还是感觉官方的帮助文档写得最为清晰，现摘录如下。

另外还有两个非常经典的例子：一个是https://spring.io/guides/gs/messaging-stomp-websocket/，附件参见文章中的下载方法；另外一个例子是https://github.com/rstoyanchev/spring-websocket-portfolio，可自行下载。

21. WebSocket Support

This part of the reference documentation covers Spring Framework’s support for WebSocket-style messaging in web applications including use of STOMP as an application level WebSocket sub-protocol.

Section 21.1, “Introduction” establishes a frame of mind in which to think about WebSocket, covering adoption challenges, design considerations, and thoughts on when it is a good fit.

Section 21.2, “WebSocket API” reviews the Spring WebSocket API on the server-side while Section 21.3, “SockJS Fallback Options” explains the SockJS protocol and shows how to configure and use it.

Section 21.4.1, “Overview of STOMP” introduces the STOMP messaging protocol. Section 21.4.2, “Enable STOMP over WebSocket” demonstrates how to configure STOMP support in Spring. Section 21.4.4, “Annotation Message Handling” and the following sections explain how to write annotated message handling methods, send messages, choose message broker options, as well as work with the special "user" destinations. Finally, Section 21.4.16, “Testing Annotated Controller Methods” lists three approaches to testing STOMP/WebSocket applications.

21.1 Introduction

The WebSocket protocol RFC 6455 defines an important new capability for web applications: full-duplex, two-way communication between client and server. It is an exciting new capability on the heels of a long history of techniques to make the web more interactive including Java applets, XMLHttpRequest, Adobe Flash, ActiveXObject, various Comet techniques, server-sent events, and others.

A proper introduction of the WebSocket protocol is beyond the scope of this document. At a minimum however it’s important to understand that HTTP is used only for the initial handshake, which relies on a mechanism built into HTTP to request a protocol upgrade (or in this case a protocol switch) to which the server can respond with HTTP status 101 (switching protocols) if it agrees. Assuming the handshake succeeds the TCP socket underlying the HTTP upgrade request remains open and both client and server can use it to send messages to each other.

Spring Framework 4 includes a new spring-websocket module with comprehensive WebSocket support. It is compatible with the Java WebSocket API standard (JSR-356) and also provides additional value-add as explained in the rest of the introduction.

21.1.1 WebSocket Fallback Options

An important challenge to adoption is the lack of support for WebSocket in some browsers. Notably the first Internet Explorer version to support WebSocket is version 10 (see http://caniuse.com/websockets for support by browser versions). Furthermore, some restrictive proxies may be configured in ways that either preclude the attempt to do HTTP upgrade or otherwise break connection after some time because it has remained opened for too long. A good overview on this topic from Peter Lubbers is available in the InfoQ article "How HTML5 Web Sockets Interact With Proxy Servers".

Therefore to build a WebSocket application today, fallback options are required to simulate the WebSocket API where necessary. Spring Framework provides such transparent fallback options based on the SockJS protocol. These options can be enabled through configuration and do not require modifying the application otherwise.

21.1.2 A Messaging Architecture

Aside from short-to-midterm adoption challenges, using WebSocket brings up important design considerations that are important to recognize early on, especially in contrast to what we know about building web applications today.

Today REST is a widely accepted, understood, and supported architecture for building web applications. It is an architecture that relies on having many URLs (nouns), a handful of HTTP methods (verbs), and other principles such as using hypermedia (links), remaining stateless, etc.

By contrast a WebSocket application may use a single URL only for the initial HTTP handshake. All messages thereafter share and flow on the same TCP connection. This points to an entirely different, asynchronous, event-driven, messaging architecture. One that is much closer to traditional messaging applications (e.g. JMS, AMQP).

Spring Framework 4 includes a new spring-messaging module with key abstractions from the Spring Integration project such as Message, MessageChannel,MessageHandler and others that can serve as a foundation for such a messaging architecture. The module also includes a set of annotations for mapping messages to methods, similar to the Spring MVC annotation based programming model.

21.1.3 Sub-Protocol Support in WebSocket

WebSocket does imply a messaging architecture but does not mandate the use of any specific messaging protocol. It is a very thin layer over TCP that transforms a stream of bytes into a stream of messages (either text or binary) and not much more. It is up to applications to interpret the meaning of a message.

Unlike HTTP, which is an application-level protocol, in the WebSocket protocol there is simply not enough information in an incoming message for a framework or container to know how to route it or process it. Therefore WebSocket is arguably too low level for anything but a very trivial application. It can be done, but it will likely lead to creating a framework on top. This is comparable to how most web applications today are written using a web framework rather than the Servlet API alone.

For this reason the WebSocket RFC defines the use of sub-protocols. During the handshake, client and server can use the header Sec-WebSocket-Protocol to agree on a sub-protocol, i.e. a higher, application-level protocol to use. The use of a sub-protocol is not required, but even if not used, applications will still need to choose a message format that both client and server can understand. That format can be custom, framework-specific, or a standard messaging protocol.

Spring Framework provides support for using STOMP — a simple, messaging protocol originally created for use in scripting languages with frames inspired by HTTP. STOMP is widely support and well suited for use over WebSocket and over the web.

21.1.4 Should I Use WebSocket?

With all the design considerations surrounding the use of WebSocket, it is reasonable to ask when is it appropriate to use?

The best fit for WebSocket is in web applications where client and server need to exchange events at high frequency and at low latency. Prime candidates include but are not limited to applications in finance, games, collaboration, and others. Such applications are both very sensitive to time delays and also need to exchange a wide variety of messages at high frequency.

For other application types, however, this may not be the case. For example, a news or social feed that shows breaking news as they become available may be perfectly okay with simple polling once every few minutes. Here latency is important, but it is acceptable if the news takes a few minutes to appear.

Even in cases where latency is crucial, if the volume of messages is relatively low (e.g. monitoring network failures) the use of long polling should be considered as a relatively simple alternative that works reliably and is comparable by efficiency (again assuming the volume of messages is relatively low).

It is the combination of both low latency and high frequency of messages that can make the use of the WebSocket protocol critical. Even in such applications, the choice remains whether all client-server communication should be done through WebSocket messages as opposed to using HTTP and REST? The answer is going to vary by application, however, it is likely that some functionality may be exposed over both WebSocket and as a REST API in order to provide clients with alternatives. Furthermore, a REST API call may need to broadcast a message to interested clients connected via WebSocket.

Spring Framework allows @Controller and @RestController classes to have both HTTP request handling and WebSocket message handling methods. Furthermore, a Spring MVC request handling method, or any application method for that matter, can easily broadcast a message to all interested WebSocket clients or to a specific user.

21.2 WebSocket API

The Spring Framework provides a WebSocket API designed to adapt to various WebSocket engines. For example, it runs on JSR-356 runtimes such as Tomcat (7.0.47+), GlassFish (4.0+) and WildFly (8.0+) but can also adapt to other WebSocket runtimes such as the Jetty (9.1+) native WebSocket support.

As explained in the introduction, direct use of a WebSocket API is too low level for applications — until assumptions are made about the format of a message there is little a framework can do to interpret messages or route them via annotations. This is why applications should consider using a sub-protocol and Spring’s STOMP over WebSocket support.

When using a higher level protocol, the details of the WebSocket API become less relevant, much like the details of TCP communication are not exposed to applications when using HTTP. Nevertheless this section covers the details of using WebSocket directly.

21.2.1 Create and Configure a WebSocketHandler

Creating a WebSocket server is as simple as implementing WebSocketHandler or more likely extending either TextWebSocketHandler orBinaryWebSocketHandler:

import org.springframework.web.socket.WebSocketHandler;
import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.TextMessage;

public class MyHandler extends TextWebSocketHandler {

    @Override
    public void handleTextMessage(WebSocketSession session, TextMessage message) {
        // ...
    }

}

There is dedicated WebSocket Java-config and XML namespace support for mapping the above WebSocket handler at a specific URL:

import org.springframework.web.socket.config.annotation.EnableWebSocket;
import org.springframework.web.socket.config.annotation.WebSocketConfigurer;
import org.springframework.web.socket.config.annotation.WebSocketHandlerRegistry;

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(myHandler(), "/myHandler");
    }

    @Bean
    public WebSocketHandler myHandler() {
        return new MyHandler();
    }

}

XML configuration equivalent:

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <websocket:handlers>
        <websocket:mapping path="/myHandler" handler="myHandler"/>
    </websocket:handlers>

    <bean id="myHandler" class="org.springframework.samples.MyHandler"/>

</beans>

The above is for use in Spring MVC applications and should be included in the configuration of a DispatcherServlet. However, Spring’s WebSocket support does not depend on Spring MVC. It is relatively simple to integrate a WebSocketHandler into other HTTP serving environments with the help of WebSocketHttpRequestHandler.

21.2.2 Customizing the WebSocket Handshake

The easiest way to customize the initial HTTP WebSocket handshake request is through a HandshakeInterceptor, which exposes "before" and "after" the handshake methods. Such an interceptor can be used to preclude the handshake or to make any attributes available to the WebSocketSession. For example, there is a built-in interceptor for passing HTTP session attributes to the WebSocket session:

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(new MyHandler(), "/myHandler")
            .addInterceptors(new HttpSessionHandshakeInterceptor());
    }

}

And the XML configuration equivalent:

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <websocket:handlers>
        <websocket:mapping path="/myHandler" handler="myHandler"/>
        <websocket:handshake-interceptors>
            <bean class="org.springframework.web.socket.server.support.HttpSessionHandshakeInterceptor"/>
        </websocket:handshake-interceptors>
    </websocket:handlers>

    <bean id="myHandler" class="org.springframework.samples.MyHandler"/>

</beans>

A more advanced option is to extend the DefaultHandshakeHandler that performs the steps of the WebSocket handshake, including validating the client origin, negotiating a sub-protocol, and others. An application may also need to use this option if it needs to configure a custom RequestUpgradeStrategy in order to adapt to a WebSocket server engine and version that is not yet supported (also see Section 21.2.4, “Deployment Considerations” for more on this subject). Both the Java-config and XML namespace make it possible to configure a custom HandshakeHandler.

21.2.3 WebSocketHandler Decoration

Spring provides a WebSocketHandlerDecorator base class that can be used to decorate a WebSocketHandler with additional behavior. Logging and exception handling implementations are provided and added by default when using the WebSocket Java-config or XML namespace. TheExceptionWebSocketHandlerDecorator catches all uncaught exceptions arising from any WebSocketHandler method and closes the WebSocket session with status1011 that indicates a server error.

21.2.4 Deployment Considerations

The Spring WebSocket API is easy to integrate into a Spring MVC application where the DispatcherServlet serves both HTTP WebSocket handshake as well as other HTTP requests. It is also easy to integrate into other HTTP processing scenarios by invoking WebSocketHttpRequestHandler. This is convenient and easy to understand. However, special considerations apply with regards to JSR-356 runtimes.

The Java WebSocket API (JSR-356) provides two deployment mechanisms. The first involves a Servlet container classpath scan (Servlet 3 feature) at startup; and the other is a registration API to use at Servlet container initialization. Neither of these mechanism make it possible to use a single "front controller" for all HTTP processing — including WebSocket handshake and all other HTTP requests — such as Spring MVC’s DispatcherServlet.

This is a significant limitation of JSR-356 that Spring’s WebSocket support addresses by providing a server-specific RequestUpgradeStrategy even when running in a JSR-356 runtime. At present such support is available on Tomcat 7.0.47+, Jetty 9.1+, GlassFish 4.0+, and WildFly 8.0+. Additional support will be added as more WebSocket runtimes become available.


	A request to overcome the above limitation in the Java WebSocket API has been created and can be followed at WEBSOCKET_SPEC-211. Also note that Tomcat and Jetty already provide native API alternatives that makes it easy to overcome the limitation. We are hopeful that more servers will follow their example regardless of when it is addressed in the Java WebSocket API.

A secondary consideration is that Servlet containers with JSR-356 support are expected to perform an SCI scan that can slow down application startup, in some cases dramatically. If a significant impact is observed after an upgrade to a Servlet container version with JSR-356 support, it should be possible to selectively enable or disable web fragments (and SCI scanning) through the use of an <absolute-ordering /> element in web.xml:

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://java.sun.com/xml/ns/javaee
        http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">

    <absolute-ordering/>

</web-app>

You can then selectively enable web fragments by name, such as Spring’s own SpringServletContainerInitializer that provides support for the Servlet 3 Java initialization API, if required:

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://java.sun.com/xml/ns/javaee
        http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">

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

</web-app>

21.2.5 Configuring the WebSocket Engine

Each underlying WebSocket engine exposes configuration properties that control runtime characteristics such as the size of message buffer sizes, idle timeout, and others.

For Tomcat, WildFly, and Glassfish add a ServletServerContainerFactoryBean to your WebSocket Java config:

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Bean
    public ServletServerContainerFactoryBean createWebSocketContainer() {
        ServletServerContainerFactoryBean container = new ServletServerContainerFactoryBean();
        container.setMaxTextMessageBufferSize(8192);
        container.setMaxBinaryMessageBufferSize(8192);
        return container;
    }

}

or WebSocket XML namespace:

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <bean class="org.springframework...ServletServerContainerFactoryBean">
        <property name="maxTextMessageBufferSize" value="8192"/>
        <property name="maxBinaryMessageBufferSize" value="8192"/>
    </bean>

</beans>


	For client side WebSocket configuration, you should use `WebSocketContainerFactoryBean` (XML) or`ContainerProvider.getWebSocketContainer()` (Java config).

For Jetty, you’ll need to supply a pre-configured Jetty WebSocketServerFactory and plug that into Spring’s DefaultHandshakeHandler through your WebSocket Java config:

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(echoWebSocketHandler(),
            "/echo").setHandshakeHandler(handshakeHandler());
    }

    @Bean
    public DefaultHandshakeHandler handshakeHandler() {

        WebSocketPolicy policy = new WebSocketPolicy(WebSocketBehavior.SERVER);
        policy.setInputBufferSize(8192);
        policy.setIdleTimeout(600000);

        return new DefaultHandshakeHandler(
                new JettyRequestUpgradeStrategy(new WebSocketServerFactory(policy)));
    }

}

or WebSocket XML namespace:

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <websocket:handlers>
        <websocket:mapping path="/echo" handler="echoHandler"/>
        <websocket:handshake-handler ref="handshakeHandler"/>
    </websocket:handlers>

    <bean id="handshakeHandler" class="org.springframework...DefaultHandshakeHandler">
        <constructor-arg ref="upgradeStrategy"/>
    </bean>

    <bean id="upgradeStrategy" class="org.springframework...JettyRequestUpgradeStrategy">
        <constructor-arg ref="serverFactory"/>
    </bean>

    <bean id="serverFactory" class="org.eclipse.jetty...WebSocketServerFactory">
        <constructor-arg>
            <bean class="org.eclipse.jetty...WebSocketPolicy">
                <constructor-arg value="SERVER"/>
                <property name="inputBufferSize" value="8092"/>
                <property name="idleTimeout" value="600000"/>
            </bean>
        </constructor-arg>
    </bean>

</beans>

21.3 SockJS Fallback Options

As explained in the introduction, WebSocket is not supported in all browsers yet and may be precluded by restrictive network proxies. This is why Spring provides fallback options that emulate the WebSocket API as close as possible based on the SockJS protocol.

21.3.1 Overview of SockJS

The goal of SockJS is to let applications use a WebSocket API but fall back to non-WebSocket alternatives when necessary at runtime, i.e. without the need to change application code.

SockJS consists of:

The SockJS protocol defined in the form of executable narrated tests.
The SockJS JavaScript client - a client library for use in browsers.
SockJS server implementations including one in the Spring Framework spring-websocket module.
As of 4.1 spring-websocket also provides a SockJS Java client.

SockJS is designed for use in browsers. It goes to great lengths to support a wide range of browser versions using a variety of techniques. For the full list of SockJS transport types and browsers see the SockJS client page. Transports fall in 3 general categories: WebSocket, HTTP Streaming, and HTTP Long Polling. For an overview of these categories see this blog post.

The SockJS client begins by sending "GET /info" to obtain basic information from the server. After that it must decide what transport to use. If possible WebSocket is used. If not, in most browsers there is at least one HTTP streaming option and if not then HTTP (long) polling is used.

All transport requests have the following URL structure:

http://host:port/myApp/myEndpoint/{server-id}/{session-id}/{transport}

{server-id} - useful for routing requests in a cluster but not used otherwise.
{session-id} - correlates HTTP requests belonging to a SockJS session.
{transport} - indicates the transport type, e.g. "websocket", "xhr-streaming", etc.

The WebSocket transport needs only a single HTTP request to do the WebSocket handshake. All messages thereafter are exchanged on that socket.

HTTP transports require more requests. Ajax/XHR streaming for example relies on one long-running request for server-to-client messages and additional HTTP POST requests for client-to-server messages. Long polling is similar except it ends the current request after each server-to-client send.

SockJS adds minimal message framing. For example the server sends the letter o ("open" frame) initially, messages are sent as a["message1","message2"] (JSON-encoded array), the letter h ("heartbeat" frame) if no messages flow for 25 seconds by default, and the letter c ("close" frame) to close the session.

To learn more run an example in a browser and watch HTTP requests. The SockJS client allows fixing the list of transports so it is possible to see each transport one at a time. The SockJS client also provides a debug flag which enables helpful messages in the browser console. On the server side enable TRACE logging fororg.springframework.web.socket. For even more detail refer to the SockJS protocol narrated test.

21.3.2 Enable SockJS

SockJS is easy to enable through a configuration:

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(myHandler(), "/myHandler").withSockJS();
    }

    @Bean
    public WebSocketHandler myHandler() {
        return new MyHandler();
    }

}

and the XML configuration equivalent:

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://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.samples.MyHandler"/>

</beans>

The above is for use in Spring MVC applications and should be included in the configuration of a DispatcherServlet. However, Spring’s WebSocket and SockJS support does not depend on Spring MVC. It is relatively simple to integrate into other HTTP serving environments with the help of SockJsHttpRequestHandler.

On the browser side, applications can use the sockjs-client that emulates the W3C WebSocket API and communicates with the server to select the best transport option depending on the browser it’s running in. Review the sockjs-client page and the list of transport types supported by browser. The client also provides several configuration options, for example, to specify which transports to include.

21.3.3 HTTP Streaming in IE 8, 9: Ajax/XHR vs IFrame

Internet Explorer 8 and 9 are and will remain common for some time. They are a key reason for having SockJS. This section covers important considerations about running in those browsers.

SockJS client supports Ajax/XHR streaming in IE 8, 9 via Microsoft’s XDomainRequest. That works across domains but does not support sending cookies. Cookies are very often essential for Java applications. However since the SockJS client can be used with many server types (not just Java ones), it needs to know whether cookies do matter. If so the SockJS client prefers Ajax/XHR for streaming or otherwise it relies on a iframe-based technique.

The very first "/info" request from the SockJS client is a request for information that can influence the client’s choice of transports. One of those details is whether the server application relies on cookies, e.g. for authentication purposes or clustering with sticky sessions. Spring’s SockJS support includes a property calledsessionCookieNeeded. It is enabled by default since most Java applications rely on the JSESSIONID cookie. If your application does not need it, you can turn off this option and the SockJS client should choose xdr-streaming in IE 8 and 9.

If you do use an iframe-based transport, and in any case, it is good to know that browsers can be instructed to block the use of iframes on a given page by setting the HTTP response header X-Frame-Options to DENY, SAMEORIGIN, or ALLOW-FROM <origin>. This is used to prevent clickjacking.

Spring Security 3.2+ provides support for setting X-Frame-Options on every response. By default the Spring Security Java config sets it to DENY. In 3.2 the Spring Security XML namespace does not set that header by default but may be configured to do so, and in the future it may set it by default.

See Section 7.1. "Default Security Headers" of the Spring Security documentation for details no how to configure the setting of the X-Frame-Optionsheader. You may also check or watch SEC-2501 for additional background.

If your application adds the X-Frame-Options response header (as it should!) and relies on an iframe-based transport, you will need to set the header value toSAMEORIGIN or ALLOW-FROM <origin>. Along with that the Spring SockJS support also needs to know the location of the SockJS client because it is loaded from the iframe. By default the iframe is set to download the SockJS client from a CDN location. It is a good idea to configure this option to a URL from the same origin as the application.

In Java config this can be done as shown below. The XML namespace provides a similar option on the <websocket:sockjs> element:

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/portfolio").withSockJS()
                .setClientLibraryUrl("http://localhost:8080/myapp/js/sockjs-client.js");
    }

    // ...

}


	During initial development, do enable the SockJS client `devel` mode that prevents the browser from caching SockJS requests (like the iframe) that would otherwise be cached. For details on how to enable it see the SockJS client page.

21.3.4 Heartbeat Messages

The SockJS protocol requires servers to send heartbeat messages to preclude proxies from concluding a connection is hung. The Spring SockJS configuiration has a property called heartbeatTime that can be used to customize the frequency. By default a heartbeat is sent after 25 seconds assuming no other messages were sent on that connection. This 25 seconds value is in line with the following IETF recommendation for public Internet applications.


	When using STOMP over WebSocket/SockJS, if the STOMP client and server negotiate heartbeats to be exchanged, the SockJS heartbeats are disabled.

The Spring SockJS support also allows configuring the TaskScheduler to use for scheduling heartbeats tasks. The task scheduler is backed by a thread pool with default settings based on the number of available processors. Applications should consider customizing the settings according to their specific needs.

21.3.5 Servlet 3 Async Requests

HTTP streaming and HTTP long polling SockJS transports require a connection to remain open longer than usual. For an overview of these techniques see this blog post.

In Servlet containers this is done through Servlet 3 async support that allows exiting the Servlet container thread processing a request and continuing to write to the response from another thread.

A specific issue is the Servlet API does not provide notifications for a client that has gone away, see SERVLET_SPEC-44. However, Servlet containers raise an exception on subseqeunt attempts to write to the response. Since Spring’s SockJS Service support sever-sent heartbeats (every 25 seconds by default), that means a client disconnect is usually detected within that time period or earlier if a message are sent more frequently.

As a result network IO failures may occur simply because a client has disconnected, which can fill the log with unnecessary stack traces. Spring makes a best effort to identify such network failures that represent client disconnects (specific to each server) and log a more minimal message using the dedicated log category DISCONNECTED_CLIENT_LOG_CATEGORY defined in AbstractSockJsSession. If you need to see the stack traces, set that log category to TRACE.

21.3.6 CORS Headers for SockJS

The SockJS protocol uses CORS for cross-domain support in the XHR streaming and polling transports. Therefore CORS headers are added automatically unless the presence of CORS headers in the response is detected. So if an application is already configured to provide CORS support, e.g. through a Servlet Filter, Spring’s SockJsService will skip this part.

It is also possible to disable the addition of these CORS headers thanks to the suppressCors property in Spring’s SockJsService.

The following is the list of headers and values expected by SockJS:

"Access-Control-Allow-Origin" - initialized from the value of the "Origin" request header.
"Access-Control-Allow-Credentials" - always set to true.
"Access-Control-Request-Headers" - initialized from values from the equivalent request header.
"Access-Control-Allow-Methods" - the HTTP methods a transport supports (see TransportType enum).
"Access-Control-Max-Age" - set to 31536000 (1 year).

For the exact implementation see addCorsHeaders in AbstractSockJsService as well as the TransportType enum in the source code.

Alternatively if the CORS configuration allows it consider excluding URLs with the SockJS endpoint prefix thus letting Spring’s SockJsService handle it.

21.3.7 SockJS Client

A SockJS Java client is provided in order to connect to remote SockJS endpoints without using a browser. This can be especially useful when there is a need of bidirectional communication between 2 servers over a public network, i.e. where network proxies may preclude the use of the WebSocket protocol. A SockJS Java client is also very useful for testing purposes for example to simulate a large number of concurrent users.

The SockJS Java client supports the "websocket", "xhr-streaming", and "xhr-polling" transports. The remaining ones only make sense for use in a browser.

The WebSocketTransport can be configured with:

StandardWebSocketClient in a JSR-356 runtime
JettyWebSocketClient using the Jetty 9+ native WebSocket API
Any implementation of Spring’s WebSocketClient

An XhrTransport by definition supports both "xhr-streaming" and "xhr-polling" since from a client perspective there is no difference other than in the URL used to connect to the server. At present there are two implementations:

RestTemplateXhrTransport uses the RestTemplate for HTTP requests.
JettyXhrTransport uses Jetty’s HttpClient for HTTP requests.

The example below shows how to create a SockJS client and connect to a SockJS endpoint:

List<Transport> transports = new ArrayList<>(2);
transports.add(new WebSocketTransport(StandardWebSocketClient()));
transports.add(new RestTemplateXhrTransport());

SockJsClient sockJsClient = new SockJsClient(transports);
sockJsClient.doHandshake(new MyWebSocketHandler(), "ws://example.com:8080/sockjs");


	SockJS uses JSON formatted arrays for messages. By default Jackson 2 is used and needs to be on the classpath. Alternatively you can configure a custom implementation of `SockJsMessageCodec` and configure it on the SockJsClient.

To use the SockJsClient for simulating a large number of concurrent users you will need to configure the underlying HTTP client (for XHR transports) to allow a sufficient number of connections and threads. For example with Jetty:

HttpClient jettyHttpClient = new HttpClient();
jettyHttpClient.setMaxConnectionsPerDestination(1000);
jettyHttpClient.setExecutor(new QueuedThreadPool(1000));

Consider also customizing these server-side SockJS related properties (see Javadoc for details):

@Configuration
public class WebSocketConfig extends WebSocketMessageBrokerConfigurationSupport {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/sockjs").withSockJS()
            .setStreamBytesLimit(512 * 1024)
            .setHttpMessageCacheSize(1000)
            .setDisconnectDelay(30 * 1000);
    }

    // ...

}

21.4 STOMP Over WebSocket Messaging Architecture

The WebSocket protocol defines two main types of messages — text and binary — but leaves their content undefined. Instead it’s expected that client and server may agree on using a sub-protocol, i.e. a higher-level protocol that defines the message content. Using a sub-protocol is optional but either way client and server both need to understand how to interpret messages.

21.4.1 Overview of STOMP

STOMP is a simple messaging protocol originally created for scripting languages (such as Ruby, Python and Perl) to connect to enterprise message brokers. It is designed to address a subset of commonly used patterns in messaging protocols. STOMP can be used over any reliable 2-way streaming network protocol such as TCP and WebSocket.

STOMP is a frame based protocol with frames modelled on HTTP. This is the structure of a frame:

COMMAND
header1:value1
header2:value2

Body^@

For example, a client can use the SEND command to send a message or the SUBSCRIBE command to express interest in receiving messages. Both of these commands require a "destination" header that indicates where to send a message to, or likewise what to subscribe to.

Here is an example of a client sending a request to buy stock shares:

SEND
destination:/queue/trade
content-type:application/json
content-length:44

{"action":"BUY","ticker":"MMM","shares",44}^@

Here is an example of a client subscribing to receive stock quotes:

SUBSCRIBE
id:sub-1
destination:/topic/price.stock.*

^@

The meaning of a destination is intentionally left opaque in the STOMP spec. It can be any string and it’s entirely up to STOMP servers to define the semantics and the syntax of the destinations that they support. It is very common however, for destinations to be path-like strings where "/topic/.."implies publish-subscribe (one-to-many) and "/queue/" to implies point-to-point (one-to-one) message exchanges.

STOMP servers can use the MESSAGE command to broadcast messages to all subscribers. Here is an example of a server sending a stock quote to a subscribed client:

MESSAGE
message-id:nxahklf6-1
subscription:sub-1
destination:/topic/price.stock.MMM

{"ticker":"MMM","price":129.45}^@


	It’s important to know that a server cannot send unsolicited messages. All messages from a server must be in response to a specific client subscription and the `"subscription-id"` header of the server message must match the `"id"` header of the client subscription.

The above overview is intended to provide the most basic understanding of the STOMP protocol. It is recommended to review the protocol specification, which is easy to follow and manageable in terms of size.

The following summarizes the benefits for an application from using STOMP over WebSocket:

Standard message format
Application-level protocol with support for common messaging patterns
Client-side support, e.g. stomp.js, msgs.js
The ability to interpret, route, and process messages on both client and server-side
The option to plug a message broker — RabbitMQ, ActiveMQ, many others — to broadcast messages (explained later)

Most importantly the use of STOMP (vs plain WebSocket) enables the Spring Framework to provide a programming model for application-level use in the same way that Spring MVC provides a programming model based on HTTP.

21.4.2 Enable STOMP over WebSocket

The Spring Framework provides support for using STOMP over WebSocket through the spring-messaging and spring-websocket modules. It’s easy to enable it.

Here is an example of configuring a STOMP WebSocket endpoint with SockJS fallback options. The endpoint is available for clients to connect to at URL path/app/portfolio:

import org.springframework.web.socket.config.annotation.EnableWebSocketMessageBroker;
import org.springframework.web.socket.config.annotation.StompEndpointRegistry;

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        config.setApplicationDestinationPrefixes("/app");
        config.enableSimpleBroker("/queue", "/topic");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/portfolio").withSockJS();
    }

    // ...

}

XML configuration equivalent:

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <websocket:message-broker application-destination-prefix="/app">
        <websocket:stomp-endpoint path="/portfolio">
            <websocket:sockjs/>
        </websocket:stomp-endpoint>
        <websocket:simple-broker prefix="/queue, /topic"/>
        ...
    </websocket:message-broker>

</beans>

On the browser side, a client might connect as follows using stomp.js and the sockjs-client:

var socket = new SockJS("/spring-websocket-portfolio/portfolio");
var stompClient = Stomp.over(socket);

stompClient.connect({}, function(frame) {
}

Or if connecting via WebSocket (without SockJS):

var socket = new WebSocket("/spring-websocket-portfolio/portfolio");
var stompClient = Stomp.over(socket);

stompClient.connect({}, function(frame) {
}

Note that the stompClient above does not need to specify a login and passcode headers. Even if it did, they would be ignored, or rather overridden, on the server side. See the sections Section 21.4.8, “Connections To Full-Featured Broker” and Section 21.4.10, “Authentication” for more information on authentication.

21.4.3 Flow of Messages

When a STOMP endpoint is configured, the Spring application acts as the STOMP broker to connected clients. It handles incoming messages and sends messages back. This section provides a big picture overview of how messages flow inside the application.

The spring-messaging module contains a number of abstractions that originated in the Spring Integration project and are intended for use as building blocks in messaging applications:

Message — represents a message with headers and a payload.
MessageHandler — a contract for handling a message.
MessageChannel — a contract for sending a message enabling loose coupling between senders and receivers.
SubscribableChannel — extends MessageChannel and sends messages to registered MessageHandler subscribers.
ExecutorSubscribableChannel — a concrete implementation of SubscribableChannel that can deliver messages asynchronously through a thread pool.

The provided STOMP over WebSocket config, both Java and XML, uses the above to assemble a concrete message flow including the following 3 channels:

"clientInboundChannel" — for messages from WebSocket clients. Every incoming WebSocket message carrying a STOMP frame is sent through this channel.
"clientOutboundChannel" — for messages to WebSocket clients. Every outgoing STOMP message from the broker is sent through this channel before getting sent to a client’s WebSocket session.
"brokerChannel" — for messages to the broker from within the application. Every message sent from the application to the broker passes through this channel.

Messages on the "clientInboundChannel" can flow to annotated methods for application handling (e.g. a stock trade execution request) or can be forwarded to the broker (e.g. client subscribing for stock quotes). The STOMP destination is used for simple prefix-based routing. For example the "/app" prefix could route messages to annotated methods while the "/topic" and "/queue" prefixes could route messages to the broker.

When a message-handling annotated method has a return type, its return value is sent as the payload of a Spring Message to the "brokerChannel". The broker in turn broadcasts the message to clients. Sending a message to a destination can also be done from anywhere in the application with the help of a messaging template. For example a an HTTP POST handling method can broadcast a message to connected clients or a service component may periodically broadcast stock quotes.

Below is a simple example to illustrate the flow of messages:

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/portfolio");
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        registry.setApplicationDestinationPrefixes("/app");
        registry.enableSimpleBroker("/topic");
    }

}

@Controller
public class GreetingController {

    @MessageMapping("/greeting") {
    public String handle(String greeting) {
        return "[" + getTimestamp() + ": " + greeting;
    }

}

The following explains the message flow for the above exmaple:

WebSocket clients connect to the WebSocket endpoint at "/portfolio".
Subscriptions to "/topic/greeting" pass through the "clientInboundChannel" and are forwarded to the broker.
Greetings sent to "/app/greeting" pass through the "clientInboundChannel" and are forwarded to the GreetingController. The controller adds the current time and the return value is passed through the "brokerChannel" as message to "/topic/greeting" (destination is selected based on a convention but can be overridden via@SendTo).
The broker in turn broadcasts messages to subscribers and they pass through the "clientOutboundChannel".

The next section provides more details on annotated methods including the kinds of arguments and return values supported.

21.4.4 Annotation Message Handling

The @MessageMapping annotation is supported on methods of @Controller classes. It can be used for mapping methods to message destinations and can also be combined with the type-level @MessageMapping for expressing shared mappings across all annotated methods within a controller.

By default destination mappings are treated as Ant-style, slash-separated, path patterns, e.g. "/foo*", "/foo/**". etc. They can also contain template variables, e.g. "/foo/{id}" that can then be referenced via @DestinationVariable-annotated method arguments.


	Applications can also use dot-separated destinations (vs slash). See Section 21.4.9, “Using Dot as Separator in `@MessageMapping` Destinations”.

The following method arguments are supported for @MessageMapping methods:

Message method argument to get access to the complete message being processed.
@Payload-annotated argument for access to the payload of a message, converted with a org.springframework.messaging.converter.MessageConverter. The presence of the annotation is not required since it is assumed by default. Payload method arguments annotated with Validation annotations (like @Validated) will be subject to JSR-303 validation.
@Header-annotated arguments for access to a specific header value along with type conversion using anorg.springframework.core.convert.converter.Converter if necessary.
@Headers-annotated method argument that must also be assignable to java.util.Map for access to all headers in the message.
MessageHeaders method argument for getting access to a map of all headers.
MessageHeaderAccessor, SimpMessageHeaderAccessor, or StompHeaderAccessor for access to headers via typed accessor methods.
@DestinationVariable-annotated arguments for access to template variables extracted from the message destination. Values will be converted to the declared method argument type as necessary.
java.security.Principal method arguments reflecting the user logged in at the time of the WebSocket HTTP handshake.

The return value from an @MessageMapping method is converted with a org.springframework.messaging.converter.MessageConverter and used as the body of a new message that is then sent, by default, to the "brokerChannel" with the same destination as the client message but using the prefix "/topic" by default. An@SendTo message level annotation can be used to specify any other destination instead.

An @SubscribeMapping annotation can also be used to map subscription requests to @Controller methods. It is supported on the method level, but can also be combined with a type level @MessageMapping annotation that expresses shared mappings across all message handling methods within the same controller.

By default the return value from an @SubscribeMapping method is sent as a message directly back to the connected client and does not pass through the broker. This is useful for implementing request-reply message interactions; for example, to fetch application data when the application UI is being initialized. Or alternatively an@SubscribeMapping method can be annotated with @SendTo in which case the resulting message is sent to the "brokerChannel" using the specified target destination.

21.4.5 Sending Messages

What if you wanted to send messages to connected clients from any part of the application? Any application component can send messages to the "brokerChannel". The easiest way to do that is to have a SimpMessagingTemplate injected, and use it to send messages. Typically it should be easy to have it injected by type, for example:

@Controller
public class GreetingController {

    private SimpMessagingTemplate template;

    @Autowired
    public GreetingController(SimpMessagingTemplate template) {
        this.template = template;
    }

    @RequestMapping(value="/greetings", method=POST)
    public void greet(String greeting) {
        String text = "[" + getTimestamp() + "]:" + greeting;
        this.template.convertAndSend("/topic/greetings", text);
    }

}

But it can also be qualified by its name "brokerMessagingTemplate" if another bean of the same type exists.

21.4.6 Simple Broker

The built-in, simple, message broker handles subscription requests from clients, stores them in memory, and broadcasts messages to connected clients with matching destinations. The broker supports path-like destinations, including subscriptions to Ant-style destination patterns.


	Applications can also use dot-separated destinations (vs slash). See Section 21.4.9, “Using Dot as Separator in `@MessageMapping` Destinations”.

21.4.7 Full-Featured Broker

The simple broker is great for getting started but supports only a subset of STOMP commands (e.g. no acks, receipts, etc), relies on a simple message sending loop, and is not suitable for clustering. Instead, applications can upgrade to using a full-featured message broker.

Check the STOMP documentation for your message broker of choice (e.g. RabbitMQ, ActiveMQ, or other), install and run the broker with STOMP support enabled. Then enable the STOMP broker relay in the Spring configuration instead of the simple broker.

Below is example configuration that enables a full-featured broker:

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/portfolio").withSockJS();
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        registry.enableStompBrokerRelay("/topic", "/queue");
        registry.setApplicationDestinationPrefixes("/app");
    }

}

XML configuration equivalent:

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <websocket:message-broker application-destination-prefix="/app">
        <websocket:stomp-endpoint path="/portfolio" />
            <websocket:sockjs/>
        </websocket:stomp-endpoint>
        <websocket:stomp-broker-relay prefix="/topic,/queue" />
    </websocket:message-broker>

</beans>

The "STOMP broker relay" in the above configuration is a Spring MessageHandler that handles messages by forwarding them to an external message broker. To do so it establishes TCP connections to the broker, forwards all messages to it, and reversely forwards all messages received from the broker to clients through their WebSocket sessions. Essentially it acts as a "relay" forwarding messages in both directions.


	Please add a dependency on `org.projectreactor:reactor-net` for TCP connection management.

Furthermore, application components (e.g. HTTP request handling methods, business services, etc) can also send messages to the broker relay, as described inSection 21.4.5, “Sending Messages”, in order to broadcast messages to subscribed WebSocket clients.

In effect, the broker relay enables robust and scalable message broadcasting.

21.4.8 Connections To Full-Featured Broker

A STOMP broker relay maintains a single "system" TCP connection to the broker. This connection is used for messages originating from the server-side application only, not for receiving messages. You can configure the STOMP credentials for this connection, i.e. the STOMP frame login and passcode headers. This is exposed in both the XML namespace and the Java config as the systemLogin/systemPasscode properties with default values guest/guest.

The STOMP broker relay also creates a separate TCP connection for every connected WebSocket client. You can configure the STOMP credentials to use for all TCP connections created on behalf of clients. This is exposed in both the XML namespace and the Java config as the clientLogin/clientPasscode properties with default values guest/guest.


	The STOMP broker relay always sets the `login` and `passcode` headers on every CONNECT frame it forwards to the broker on behalf of clients. Therefore WebSocket clients need not set those headers, they will be ignored. As the following section explains instead WebSocket clients should rely on HTTP authentication to protect the WebSocket endpoint and establish the client identity.

The STOMP broker relay also sends and receives heartbeats to and from the message broker over the "system" TCP connection. You can configure the intervals for sending and receiving heartbeats (10 seconds each by default). If connectivity to the broker is lost, the broker relay will continue to try to reconnect, every 5 seconds, until it succeeds.


	A Spring bean can implement `ApplicationListener<BrokerAvailabilityEvent>` in order to receive notifications when the "system" connection to the broker is lost and re-established. For example a Stock Quote service broadcasting stock quotes can stop trying to send messages when there is no active "system" connection.

The STOMP broker relay can also be configured with a virtualHost property. The value of this property will be set as the host header of every CONNECT frame and may be useful for example in a cloud environment where the actual host to which the TCP connection is established is different from the host providing the cloud-based STOMP service.

21.4.9 Using Dot as Separator in `@MessageMapping` Destinations

Although slash-separated path patterns are familiar to web developers, in messaging it is common to use "." as separator for example in the names of topics, queues, exchanges, etc. Applications can also switch to using "." (dot) instead of "/" (slash) as the separator in @MessageMapping mappings by configuring a customAntPathMatcher.

In Java config:

@Configuration
@EnableWebSocketMessageBroker
public class WebsocketConfig extends AbstractWebSocketMessageBrokerConfigurer {

  // ...

  @Override
  public void configureMessageBroker(MessageBrokerRegistry registry) {
    registry.enableStompBrokerRelay("/queue/", "/topic/");
    registry.setApplicationDestinationPrefixes("/app");
    registry.setPathMatcher(new AntPathMatcher("."));
  }

}

In XML config:

<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
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/websocket
    http://www.springframework.org/schema/websocket/spring-websocket.xsd">

  <websocket:message-broker application-destination-prefix="/app" path-matcher="pathMatcher">
    <websocket:stomp-endpoint path="/stomp" />
    <websocket:simple-broker prefix="/topic, /queue"/>
  </websocket:message-broker>

  <bean id="pathMatcher" class="org.springframework.util.AntPathMatcher">
    <constructor-arg index="0" value="." />
  </bean>

</beans>

And below is a simple example to illustrate a controller with "." separator:

@Controller
@MessageMapping("foo")
public class FooController {

  @MessageMapping("bar.{baz}")
  public void handleBaz(@DestinationVariable String baz) {
  }

}

If the application prefix is set to "/app" then the foo method is effectively mapped to "/app/foo.bar.{baz}".

21.4.10 Authentication

In a WebSocket-style application it is often useful to know who sent a message. Therefore some form of authentication is needed to establish the user identity and associate it with the current session.

Existing Web applications already use HTTP based authentication. For example Spring Security can secure the HTTP URLs of the application as usual. Since a WebSocket session begins with an HTTP handshake, that means URLs mapped to STOMP/WebSocket are already automatically protected and require authentication. Moreover the page that opens the WebSocket connection is itself likely protected and so by the time of the actual handshake, the user should have been authenticated.

When a WebSocket handshake is made and a new WebSocket session created, Spring’s WebSocket support automatically transfers the java.security.Principalfrom the HTTP request to the WebSocket session. After that every message flowing through the application on that WebSocket session is enriched with the user information. It’s present in the message as a header. Controller methods can access the current user by adding a method argument of typejavax.security.Principal.

Note that even though the STOMP CONNECT frame has "login" and "passcode" headers that can be used for authentication, Spring’s STOMP WebSocket support ignores them and currently expects users to have been authenticated already via HTTP.

In some cases it may be useful to assign an identity to WebSocket session even when the user has not formally authenticated. For example a mobile app might assign some identity to anonymous users, perhaps based on geographical location. The do that currently, an application can sub-class DefaultHandshakeHandler and override the determineUser method. The custom handshake handler can then be plugged in (see examples in Section 21.2.4, “Deployment Considerations”).

21.4.11 User Destinations

An application can send messages targeting a specific user. Spring’s STOMP support recognizes destinations prefixed with "/user/". For example, a client might subscribe to the destination "/user/queue/position-updates". This destination will be handled by the UserDestinationMessageHandler and transformed into a destination unique to the user session, e.g. "/queue/position-updates-user123". This provides the convenience of subscribing to a generically named destination while at the same time ensuring no collisions with other users subscribing to the same destination so that each user can receive unique stock position updates.

On the sending side messages can be sent to a destination such as "/user/{username}/queue/position-updates", which in turn will be translated by theUserDestinationMessageHandler into one or more destinations, one for each session associated with the user. This allows any component within the application to send messages targeting a specific user without necessarily knowing anything more than their name and the generic destination. This is also supported through an annotation as well as a messaging template.

For example message-handling method can send messages to the user associated with the message being handled through the @SendToUser annotation:

@Controller
public class PortfolioController {

    @MessageMapping("/trade")
    @SendToUser("/queue/position-updates")
    public TradeResult executeTrade(Trade trade, Principal principal) {
        // ...
        return tradeResult;
    }
}

If the user has more than one sessions, by default all of the sessions subscribed to the given destination are targeted. However sometimes, it may be necessary to target only the session that sent the message being handled. This can be done by setting the broadcast attribute to false, for example:

@Controller
public class MyController {

    @MessageMapping("/action")
    public void handleAction() throws Exception{
        // raise MyBusinessException here
    }

    @MessageExceptionHandler
    @SendToUser(value="/queue/errors", broadcast=false)
    public ApplicationError handleException(MyBusinessException exception) {
        // ...
        return appError;
    }
}


	While user destinations generally imply an authenticated user, it isn’t required strictly. A WebSocket session that is not associated with an authenticated user can subscribe to a user destination. In such cases the `@SendToUser` annotation will behave exactly the same as with `broadcast=false`, i.e. targeting only the session that sent the message being handled.

It is also possible to send a message to user destinations from any application component by injecting the SimpMessageTemplate created by the Java config or XML namespace, for example (the bean name is "brokerMessagingTemplate` if required for qualification with @Qualifier):

@Service
public class TradeServiceImpl implements TradeService {

	private final SimpMessageTemplate messagingTemplate;

	@Autowired
	public TradeServiceImpl(SimpMessageTemplate messagingTemplate) {
		this.messagingTemplate = messagingTemplate;
	}

	// ...

	public void afterTradeExecuted(Trade trade) {
		this.messagingTemplate.convertAndSendToUser(
				trade.getUserName(), "/queue/position-updates", trade.getResult());
	}
}

When using user destinations with an external message broker, check the broker documentation on how to manage inactive queues, so that when the user session is over, all unique user queues are removed. For example, RabbitMQ creates auto-delete queues when destinations like/exchange/amq.direct/position-updates are used. So in that case the client could subscribe to/user/exchange/amq.direct/position-updates. ActiveMQ has configuration options for purging inactive destinations.

21.4.12 Listening To ApplicationContext Events and Intercepting Messages

Several ApplicationContext events (listed below) are published and can be received by implementing Spring’s ApplicationListener interface.

BrokerAvailabilityEvent — indicates when the broker becomes available/unavailable. While the "simple" broker becomes available immediately on startup and remains so while the application is running, the STOMP "broker relay" may lose its connection to the full featured broker for example if the broker is restarted. The broker relay has reconnect logic and will re-establish the "system" connection to the broker when it comes back, hence this event is published whenever the state changes from connected to disconnected and vice versa. Components using the SimpMessagingTemplate should subscribe to this event and avoid sending messages at times when the broker is not available. In any case they should be prepared to handle MessageDeliveryException when sending a message.
SessionConnectEvent — published when a new STOMP CONNECT is received indicating the start of a new client session. The event contains the message representing the connect including the session id, user information (if any), and any custom headers the client may have sent. This is useful for tracking client sessions. Components subscribed to this event can wrap the contained message using SimpMessageHeaderAccessor or StompMessageHeaderAccessor.
SessionConnectedEvent — published shortly after a SessionConnectEvent when the broker has sent a STOMP CONNECTED frame in response to the CONNECT. At this point the STOMP session can be considered fully established.
SessionSubscribeEvent — published when a new STOMP SUBSCRIBE is received.
SessionUnsubscribeEvent — published when a new STOMP UNSUBSCRIBE is received.
SessionDisconnectEvent — published when a STOMP session ends. The DISCONNECT may have been sent from the client or it may also be automatically generated when the WebSocket session is closed. In some cases this event may be published more than once per session. Components should be idempotent to multiple disconnect events.


	When using a full-featured broker, the STOMP "broker relay" automatically reconnects the "system" connection should the broker become temporarily unavailable. Client connections however are not automatically reconnected. Assuming heartbeats are enabled, the client will typically notice the broker is not responding within 10 seconds. Clients need to implement their own reconnect logic.

Furthermore, an application can directly intercept every incoming and outgoing message by registering a ChannelInterceptor on the respective message channel. For example to intercept inbound messages:

@Configuration
@EnableWebSocketMessageBroker
public class WebsocketConfig extends AbstractWebSocketMessageBrokerConfigurer {

  @Override
  public void configureClientInboundChannel(ChannelRegistration registration) {
    registration.setInterceptors(new MyChannelInterceptor());
  }
}

A custom ChannelInterceptor can extend the empty method base class ChannelInterceptorAdapter and use StompHeaderAccessor orSimpMessageHeaderAccessor to access information about the message.

public class MyChannelInterceptor extends ChannelInterceptorAdapter {

  @Override
  public Message<?> preSend(Message<?> message, MessageChannel channel) {
    StompHeaderAccessor accessor = StompHeaderAccessor.wrap(message);
    StompCommand command = accessor.getStompCommand();
    // ...
    return message;
  }
}

21.4.13 WebSocket Scope

Each WebSocket session has a map of attributes. The map is attached as a header to inbound client messages and may be accessed from a controller method, for example:

@Controller
public class MyController {

    @MessageMapping("/action")
    public void handle(SimpMessageHeaderAccessor headerAccessor) {
        Map<String, Object> attrs = headerAccessor.getSessionAttributes();
        // ...
    }
}

It is also possible to declare a Spring-managed bean in the "websocket" scope. WebSocket-scoped beans can be injected into controllers and any channel interceptors registered on the "clientInboundChannel". Those are typically singletons and live longer than any individual WebSocket session. Therefore you will need to use a scope proxy mode for WebSocket-scoped beans:

@Component
@Scope(value="websocket", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyBean {

    @PostConstruct
    public void init() {
        // Invoked after dependencies injected
    }

    // ...

    @PreDestroy
    public void destroy() {
        // Invoked when the WebSocket session ends
    }
}

@Controller
public class MyController {

    private final MyBean myBean;

    @Autowired
    public MyController(MyBean myBean) {
        this.myBean = myBean;
    }

    @MessageMapping("/action")
    public void handle() {
        // this.myBean from the current WebSocket session
    }
}

As with any custom scope, Spring initializes a new MyBean instance the first time it is accessed from the controller and stores the instance in the WebSocket session attributes. The same instance is returned subsequently until the session ends. WebSocket-scoped beans will have all Spring lifecycle methods invoked as shown in the examples above.

21.4.14 Configuration and Performance

There is no silver bullet when it comes to performance. Many factors may affect it including the size of messages, the volume, whether application methods perform work that requires blocking, as well as external factors such as network speed and others. The goal of this section is to provide an overview of the available configuration options along with some thoughts on how to reason about scaling.

In a messaging application messages are passed through channels for asynchronous executions backed by thread pools. Configuring such an application requires good knowledge of the channels and the flow of messages. Therefore it is recommended to review Section 21.4.3, “Flow of Messages”.

The obvious place to start is to configure the thread pools backing the "clientInboundChannel" and the "clientOutboundChannel". By default both are configured at twice the number of available processors.

If the handling of messages in annotated methods is mainly CPU bound then the number of threads for the "clientInboundChannel" should remain close to the number of processors. If the work they do is more IO bound and requires blocking or waiting on a database or other external system then the thread pool size will need to be increased.

ThreadPoolExecutor has 3 important properties. Those are the core and the max thread pool size as well as the capacity for the queue to store tasks for which there are no available threads.

A common point of confusion is that configuring the core pool size (e.g. 10) and max pool size (e.g. 20) results in a thread pool with 10 to 20 threads. In fact if the capacity is left at its default value of Integer.MAX_VALUE then the thread pool will never increase beyond the core pool size since all additional tasks will be queued.

Please review the Javadoc of ThreadPoolExecutor to learn how these properties work and understand the various queuing strategies.

On the "clientOutboundChannel" side it is all about sending messages to WebSocket clients. If clients are on a fast network then the number of threads should remain close to the number of available processors. If they are slow or on low bandwidth they will take longer to consume messages and put a burden on the thread pool. Therefore increasing the thread pool size will be necessary.

While the workload for the "clientInboundChannel" is possible to predict — after all it is based on what the application does — how to configure the "clientOutboundChannel" is harder as it is based on factors beyond the control of the application. For this reason there are two additional properties related to the sending of messages. Those are the "sendTimeLimit" and the "sendBufferSizeLimit". Those are used to configure how long a send is allowed to take and how much data can be buffered when sending messages to a client.

The general idea is that at any given time only a single thread may be used to send to a client. All additional messages meanwhile get buffered and you can use these properties to decide how long sending a message is allowed to take and how much data can be buffered in the mean time. Please review the Javadoc of XML schema for this configuration for important additional details.

Here is example configuration:

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureWebSocketTransport(WebSocketTransportRegistration registration) {
        registration.setSendTimeLimit(15 * 1000).setSendBufferSizeLimit(512 * 1024);
    }

    // ...

}

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <websocket:message-broker>
        <websocket:transport send-timeout="15000" send-buffer-size="524288" />
        <!-- ... -->
    </websocket:message-broker>

</beans>

The WebSocket transport configuration shown above can also be used to configure the maximum allowed size for incoming STOMP messages. Although in theory a WebSocket message can be almost unlimited in size, in pracitce WebSocket servers impose limits. For example 8K on Tomcat and 64K on Jetty. For this reason STOMP clients such as stomp.js split larger STOMP messages at 16K boundaries and send them as multiple WebSocket messages thus requiring the server to buffer and re-assemble.

Spring’s STOMP over WebSocket support does this so applications can configure the maximum size for STOMP messages irrespective of WebSocket server specific message sizes. Do keep in mind that the WebSocket message size will be automatically adjusted if necessary to ensure they can carry 16K WebSocket messages at a minimum.

Here is example configuration:

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureWebSocketTransport(WebSocketTransportRegistration registration) {
        registration.setMessageSizeLimit(128 * 1024);
    }

    // ...

}

<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
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/websocket
        http://www.springframework.org/schema/websocket/spring-websocket.xsd">

    <websocket:message-broker>
        <websocket:transport message-size="131072" />
        <!-- ... -->
    </websocket:message-broker>

</beans>

An important point about scaling is using multiple application instances. Currently it is not possible to do that with the simple broker. However when using a full-featured broker such as RabbitMQ, each application instance connects to the broker and messages broadcast from one application instance can be broadcast through the broker to WebSocket clients connected through any other application instances.

21.4.15 Runtime Monitoring

When using @EnableWebSocketMessageBroker or <websocket:message-broker> key infrastructure components automatically gather stats and counters that provide important insight into the internal state of the application. The configuration also declares a bean of type WebSocketMessageBrokerStats that gathers all available information in one place and by default logs it at INFO once every 30 minutes. This bean can be exported to JMX through Spring’s MBeanExporter for viewing at runtime for example through JDK’s jconsole. Below is a summary of the available information.

Client WebSocket Sessions

Current

indicates how many client sessions there are currently with the count further broken down by WebSocket vs HTTP streaming and polling SockJS sessions.

Total

indicates how many total sessions have been established.

Abnormally Closed

Connect Failures: these are sessions that got established but were closed after not having received any messages within 60 seconds. This is usually an indication of proxy or network issues.
Send Limit Exceeded: sessions closed after exceeding the configured send timeout or the send buffer limits which can occur with slow clients (see previous section).
Transport Errors: sessions closed after a transport error such as failure to read or write to a WebSocket connection or HTTP request/response.

STOMP Frames

the total number of CONNECT, CONNECTED, and DISCONNECT frames processed indicating how many clients connected on the STOMP level. Note that the DISCONNECT count may be lower when sessions get closed abnormally or when clients close without sending a DISCONNECT frame.

STOMP Broker Relay

TCP Connections: indicates how many TCP connections on behalf of client WebSocket sessions are established to the broker. This should be equal to the number of client WebSocket sessions + 1 additional shared "system" connection for sending messages from within the application.
STOMP Frames: the total number of CONNECT, CONNECTED, and DISCONNECT frames forwarded to or received from the broker on behalf of clients. Note that a DISCONNECT frame is sent to the broker regardless of how the client WebSocket session was closed. Therefore a lower DISCONNECT frame count is an indication that the broker is pro-actively closing connections, may be because of a heartbeat that didn’t arrive in time, an invalid input frame, or other.

Client Inbound Channel

stats from thread pool backing the "clientInboundChannel" providing insight into the health of incoming message processing. Tasks queueing up here is an indication the application may be too slow to handle messages. If there I/O bound tasks (e.g. slow database query, HTTP request to 3rd party REST API, etc) consider increasing the thread pool size.

Client Outbound Channel

stats from the thread pool backing the "clientOutboundChannel" providing insight into the health of broadcasting messages to clients. Tasks queueing up here is an indication clients are too slow to consume messages. One way to address this is to increase the thread pool size to accommodate the number of concurrent slow clients expected. Another option is to reduce the send timeout and send buffer size limits (see the previous section).

SockJS Task Scheduler

stats from thread pool of the SockJS task scheduler which is used to send heartbeats. Note that when heartbeats are negotiated on the STOMP level the SockJS heartbeats are disabled.

21.4.16 Testing Annotated Controller Methods

There are two main approaches to testing applications using Spring’s STOMP over WebSocket support. The first is to write server-side tests verifying the functionality of controllers and their annotated message handling methods. The second is to write full end-to-end tests that involve running a client and a server.

The two approaches are not mutually exclusive. On the contrary each has a place in an overall test strategy. Server-side tests are more focused and easier to write and maintain. End-to-end integration tests on the other hand are more complete and test much more but they’re also more involved to write and maintain.

The simplest form of server-side tests is to write controller unit tests. However this is not useful enough since much of what a controller does depends on its annotations. Pure unit tests simply can’t test that.

Ideally controllers under test should be invoked as they are at runtime, much like the approach to testing controllers handling HTTP requests using the Spring MVC Test framework. i.e. without running a Servlet container but relying on the Spring Framework to invoke the annotated controllers. Just like with Spring MVC Test here there are two two possible alternatives, either using a "context-based" or "standalone" setup:

Load the actual Spring configuration with the help of the Spring TestContext framework, inject "clientInboundChannel" as a test field, and use it to send messages to be handled by controller methods.
Manually set up the minimum Spring framework infrastructure required to invoke controllers (namely the SimpAnnotationMethodMessageHandler) and pass messages for controllers directly to it.

Both of these setup scenarios are demonstrated in the tests for the stock portfolio sample application.

The second approach is to create end-to-end integration tests. For that you will need to run a WebSocket server in embedded mode and connect to it as a WebSocket client sending WebSocket messages containing STOMP frames. The tests for the stock portfolio sample application also demonstrate this approach using Tomcat as the embedded WebSocket server and a simple STOMP client for test purposes.

原文参见：http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html。

你可能感兴趣的:(websocket)

VUE3 + xterm + nestjs实现web远程终端或连接开启SSH登录的路由器和交换机。焚木灵 node.js vue
可远程连接系统终端或开启SSH登录的路由器和交换机。相关资料：xtermjs/xterm.js:Aterminalfortheweb(github.com)后端实现(NestJS)：1、安装依赖：npminstallnode-ssh@nestjs/websockets@nestjs/platform-socket.io2、我们将创建一个名为RemoteControlModule的NestJS模块，
Websocket及三次握手/四次挥手小童不学前端网络通信 websocket 网络协议网络
Websocket-实时通信文章目录前言一、目前可实现实时通信的方式1、轮询（polling）2、长轮询（longpolling）3、Websocket3.1、WebSocket心跳机制3.2、WebSocket工作原理3.3、Websocket优点3.4、HTTP和Websocket关系二、HTTP协议-TCP三次握手、四次挥手1、TCP和TCP连接2、HTTP和TCP关系3、关于TCP连接的常
websocket aabbccQBB websocket 网络协议网络
1、概念是一种在单个TCP连接上进行全双工通信的协议。websocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocketAPI中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。单工通信：数据传输只允许在一个方向上传输，只能一方发送数据，另一方接收数据并发送。半双工：数据传输允许两个方向上的传输，但在同一时
Http协议、TCP协议、WebSocket协议俗人浮生
网络编程大家都不陌生，但平时我们只是知道怎么用，对个中的网络协议倒是没花多少工夫去学习，所以，我们今天特意来对网络协议相关的知识加以总结记录。1）网络七层协议，从上到下依次为：7应用层6表示层5会话层4传输层3网络层2数据链路层1物理层2）Http协议对应于应用层，TCP协议对应于传输层，Http协议是建立在TCP协议基础之上的3）属于应用层的常用协议：Http（超文本传输协议）、FTP（文件传输
ESP32鉴权讯飞科技 qq_42949957 科技运维
#include#include#include#include#include#includeconstchar*ssid="464564";constchar*password="546456.";WebSocketsClientwebSocket;voidwebSocketEvent(WStype_ttype,uint8_t*payload,size_tlength){switch(type
【面试分享】面试题——网络题目_网络面试题程序员西西面试网络职场和发展测试工具 web安全网络安全系统安全
基于入门网络安全/黑客打造的：黑客&网络安全入门&进阶学习资源包一、题目1、网关、网桥、路由器、中继器作用、实现以及对应的osi层?2、MAC地址是什么?3、webSocket是什么?4、常见的协议有哪些？5、什么是arp协议？6、FTP依赖于哪种协议？7、ip和域名分别是什么，计算机上网如何获取ip?8、http和https是什么，他们的功能、对应的OSI层以及区别?9、你知道有哪些网络通信协议
【漏洞挖掘】——53、 WebSocket安全概览 FLy_鹏程万里【WEB渗透】websocket 安全网络协议渗透测试信息安全网络安全 web渗透
文章前言在一次做项目的时候本来是想去点击Burpsuite的Proxy界面的HTTPHistory选项卡来查看HTTP历史请求记录信息并做测试的，但是在查看的时候却下意识的点击到了HTTPProxy右侧的"WebSocketsHistory"选项卡中，从界面的交互历史中发现网站有使用WebSocket进行通信，虽然之前有对Websocket有一些简单的了解(比如:跨越问题)，但是未对此进行深入研究
Tomcat与JDK版本对应关系，Tomcat各版本特性 2401_84048671 程序员 java tomcat 开发语言
ApacheTomcat8.xApacheTomcat7.xApacheTomcat6.xApacheTomcat是一个开源软件实现了JavaServlet和JavaServerPages技术。不同版本的Servlet和JSP规范可使用不同版本的ApacheTomcat。Tomcat与JDK版本对应关系为：|Servlet规格|JSP规范|EL规格|WebSocket规范|JASPIC规格|Apa
实现两个窗口通信方法之postMessage itKingOne javascript postmessage 页面通讯跨域通讯
两个窗口的通信问题应该是一个比较常见的问题了，通信可以通过很多种方式,如下：localStoragepostMessagewebsocket今天博主先来一篇postMessage干货，后期还会给出websocket的实现代码。首先来看一下基本的语法otherWindow.postMessage(message,targetOrigin,[transfer]);otherWindow其他窗口的一个引
Spring boot 项目作为客户端调用服务端websocket 心之语歌 spring boot websocket 后端
文章目录java客户端请求websocketSpringboot导入包客户端调用方法测试执行方法connectWebSocketHandshakeMessagesendHandshakeWebSocketConfig.queue.take方法对应实体类配置yaml资源WebSocketConfig配置类注入配置websocketUrl：LinkedBlockingQueueLinkedBlocki
Springboot 项目中引入WebSocket后，单元测试出现错误，前端开发揭秘杭州湾Java仔 2024年前端程序员 spring boot websocket 单元测试
java.lang.IllegalStateException:FailedtoloadApplicationContextatorg.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:12
Linux Nginx 配置 Websocket 攀小黑 linux nginx websocket
直接上代码#负载均衡upstreamgzgc_balancer{#least_conn;ip_hash;#这个是tomcat的访问路径server127.0.0.1:8025weight=1max_fails=2fail_timeout=3s;server127.0.0.1:8026weight=1max_fails=2fail_timeout=3s;}#配置map$http_upgrade$co
基于Spring的消息推送实战（Websocket和前端轮询实现）星月梦瑾 vue java spring websocket 前端
基于Spring的消息推送实战（Websocket和前端轮询实现）本文介绍了基于Spring的消息推送实现方法，主要介绍了websocket实时消息推送方法（ServerEndpoint方式实现），以及前端客户端轮询方式的消息推送。一、消息推送常见的消息推送方式有轮询、websocket、jpush等。传统http协议需要客户端发起请求，不能服务端进行推送，且建立tcp连接需要多次握手（tcp三次
WebSocket的详细介绍（打开你对WebSocket的认识） Digimon-Y websocket 网络协议网络
WebSockets是一种网络通信协议，它允许在客户端（通常是Web浏览器）与服务器之间建立一个持久的双向通信通道。这种协议特别适用于需要实时数据交换的应用场景，如实时聊天、在线协作编辑文档、实时游戏、股票报价系统等。WebSockets的特点全双工通信：WebSockets支持客户端和服务器之间的双向数据流。这意味着客户端和服务器可以同时发送数据，而无需等待另一方完成接收。持久连接：一旦建立了W
spring-websocket基于stomp实现websocket 飘零未归人前端 java websocket 网络协议网络
目录概述后端代码拦截器HandshakeInterceptor拦截器ChannelInterceptor拦截器消息转换器配置类消息处理广播模式用户模式自定义请求头用户信息ChannelInterceptor拦截器设置用户信息DefaultHandshakeHandler的继承类中设置用户对象前端代码概述WebSocket协议是一种相当低级的协议。它定义了如何将字节流转换为帧。帧可以包含文本或二进制
打造实时双人答题对决——WebSocket与JS的完美搭档 8tydegrees websocket websocket javascript 网络协议
本文使用WebSocket+JS实现简单实时双人协同pk答题引入在实时双人PK答题应用中，前端主要负责与WebSocket服务器的交云通信，实现实时互动功能。通过JavaScript建立WebSocket连接后，前端将发送和接收消息以实现玩家匹配、题目显示、答题、分数更新和游戏结束等功能。在用户界面上，通过监听点击事件来触发匹配对手、提交答案和结束游戏的操作，同时动态更新UI以反映游戏状态的变化。
不只是答题：用WebSocket和SpringBoot让双人PK变得刺激又好玩 8tydegrees websocket websocket spring boot 网络协议后端网络 javascript
引入引入与技术选型：在实时互动应用中，实现流畅的多人协同对战功能是一大挑战。WebSocket技术，以其全双工通信能力，提供了解决方案。不同于传统HTTP请求的短连接，WebSocket建立持久连接，极大减少了通信延迟，为实时数据传输提供了理想的环境，极大减少了传统HTTP轮询的延迟，为实时游戏提供了必要的技术基础。架构设计：采用前后端分离，将WebSocket服务独立部署。前端使用JavaScr
Android SSE 单向接收数据 wk灬丨 android
Server-SentEvents（SSE）是一种在客户端和服务器之间实现单向实时通信的技术。它允许服务器向客户端推送数据，但客户端无法使用SSE向服务器发送数据。这使得其适用于需要持续接收服务器数据的应用场景（如实时通知、股票行情、社交媒体更新等）相比于其他技术如WebSocket，SSE更简单和轻量，但仅适用于信息量不大的单向数据流。大多数现代浏览器都支持SSE，并且其内置的自动重连机制进一步
Flask中实现WebSocket需要什么组件 ac-er8888 flask websocket python
在Flask中实现WebSocket功能，通常不会直接使用Flask本身，因为Flask是一个轻量级的Web框架，主要设计用于处理HTTP请求。然而，你可以通过集成一些第三方库来在Flask应用中支持WebSocket。WebSocket是一种在单个TCP连接上进行全双工通讯的协议，它允许服务器主动向客户端发送信息，这对于需要实时数据更新的应用（如聊天应用、实时通知系统等）非常有用。在Flask中
springboot websocket 服务端 java知路 spring boot websocket 后端
在SpringBoot中使用WebSocket实现服务端和Java客户端的实时通信，可以分为几个步骤来完成。这里将详细介绍服务端和Java客户端的具体实现。服务端设置添加依赖：在pom.xml文件中添加SpringWebSocket的依赖。org.springframework.bootspring-boot-starter-websocket配置WebSocket处理器：创建一个配置类来注册We
tio websocket 客户端 java 代码工具类 java知路 websocket 网络协议网络
为了更好地组织代码并提高可复用性，我们可以将WebSocket客户端封装成一个工具类。这样可以在多个地方方便地使用WebSocket客户端功能。以下是使用tio库实现的一个WebSocket客户端工具类。1.添加依赖确保项目中添加了tio的依赖。如果使用的是Maven，可以在pom.xml文件中添加以下依赖：com.github.xiaoymintio-core2.1.10com.github.x
JS实现WebSocket客户端 msw、 JS js
//webSocket服务端地址varwsUrl=''//webSocket对象varws;//webSocket尝试重新创建webSocket定时varreconnectTimeOut;//心跳重试次数服务端3次无响应就断开重连varheartCheckNum=0;//webSocket链接锁，用来保证只有一个客户端与服务端只生成一个连接。varlockReconnect=false;//web
Spring Boot 3使用Spring WebFlux + WebSocket(简单实现) 丿凌潇 spring spring boot websocket
效果为什么要使用SpringWebFlux？一部分答案是需要一个非阻塞的网络堆栈来处理少量线程的并发，并使用更少的硬件资源进行扩展。使用Servlet非阻塞I/O，远离ServletAPI的其余部分，因为他们的通信是同步的(Filter,Servlet)或阻塞的(getParameter,getPart)。SpringWebFlux是一个新的通用API作为跨任何非阻塞运行时的基础的动机。这很重要，
记一次spring boot自带的tomcat与websocket冲突 listenFeng. JAVA
记一次springboot自带的tomcat与websocket冲突问题解决方式问题项目新集成了websocket，然后在执行单元测试时报错，报错如下Causedby:org.springframework.beans.factory.BeanCreationException:Errorcreatingbeanwithname'serverEndpointExporter'definedincl
深度学习项目实践——qq聊天机器人（transformer）（二）配置环境与部署 Linductor qq聊天机器人项目深度学习机器人人工智能
深度学习项目实践——qq聊天机器人（transformer）（二）配置环境与部署上一节我们讲解了qq聊天的原理和qq机器人的框架以及运行流程，这一节我们来讲怎么配置环境，部署qq机器人。第一步——配置环境有关代替qq客户端实现反向websocket连接这一部分内容由于一些原因，我无法在这里具体讲解，我把这部分内容放到了github中我的项目内,请自行查看。机器人主体——nonebot2nonebo
springboot学习(七十二) webflux中使用WebSocket实现服务端和客户端码农-文若书生 spring boot websocket webflux WebSocket webflux使用ws ws
文章目录前言一、服务端1、编写一个WebSocketSession封装类2、编写最重要的handler3、附JsonUtils4、Spring注册二、客户端1、客户端连接类前言springboot中不使用Servlet，而是使用WebFlux的情况下，可以使用其自带的websocket实现websocket的功能，网上大部分例子都只能实现一个最基本的DEMO，不能实现服务端在Handler外部推送
Spring Cloud Gateway整合基于STOMP协议的WebSocket实战及遇到问题解决愤怒的代码 SpringBoot实战教程 websocket spring cloud gateway
本实例介绍了SpringCloudGateway整合基于STOMP协议的WebSocket的实现。开发了聊天功能，和用户在线状态。解决了协议gateway整合websocket出现的问题技术点SpringCloudGatewayNacosWebSocketSTOMPWebSocket与STOMP协议详解1.WebSocketWebSocket是一种通信协议，提供了在客户端和服务器之间建立全双工通信
WebSocket和HTTP有什么区别黑客CN 深度学习服务器
WebSocket和HTTP是两种不同的协议，它们在通信方式和特点上有一些区别。1.连接方式：HTTP是一种无状态的协议，每次请求都需要建立一个新的连接，完成请求后立即关闭连接。而WebSocket是一种全双工的协议，它在客户端和服务器之间建立一条持久的连接，可以实现双向通信。2.数据传输：HTTP协议是基于请求-响应模式的，客户端发送请求，服务器返回响应。而WebSocket允许服务器主动向客户
WebSocket 和 HTTP 请求区别懒人w #工具 websocket http 网络协议
区别与好处通信模式：HTTP请求：HTTP请求是基于请求-响应模型的。客户端发送请求到服务器，然后服务器处理请求并返回响应。每次请求都需要重新建立连接。WebSocket：WebSocket是一个全双工协议，允许客户端和服务器之间进行持续的双向通信。一旦连接建立，数据可以在双方之间实时传输，而不需要每次都重新建立连接。性能和效率：HTTP请求：由于每次请求都需要重新建立连接和断开连接，存在较大的开
Python实现WebSocket通讯与心跳控制详解菁英猎人职业教育软件测试计算机面试 python 开发语言功能测试 postman 测试工具自动化
为了使用Python实现WebSocket通讯和心跳控制，我们通常需要一个WebSocket客户端库和一个服务器端库。这里，我们将使用websockets库作为服务器和客户端的示例。安装必要的库首先，你需要安装websockets库。可以使用pip进行安装：pipinstallwebsockets1.服务器端代码服务器端将处理WebSocket连接，发送和接收消息，并管理心跳检测。importas
jquery实现的jsonp掉java后台知了ing java jsonp jquery
什么是JSONP？先说说JSONP是怎么产生的：其实网上关于JSONP的讲解有很多，但却千篇一律，而且云里雾里，对于很多刚接触的人来讲理解起来有些困难，小可不才，试着用自己的方式来阐释一下这个问题，看看是否有帮助。 1、一个众所周知的问题，Ajax直接请求普通文件存在跨域无权限访问的问题，甭管你是静态页面、动态网页、web服务、WCF，只要是跨域请求，一律不准； 2、
Struts2学习笔记 caoyong struts2
SSH : Spring + Struts2 + Hibernate 三层架构(表示层,业务逻辑层,数据访问层) MVC模式 (Model View Controller) 分层原则:单向依赖，接口耦合 1、Struts2 = Struts + Webwork 2、搭建struts2开发环境 a>、到www.apac
SpringMVC学习之后台往前台传值方法满城风雨近重阳 springMVC
springMVC控制器往前台传值的方法有以下几种： 1.ModelAndView 通过往ModelAndView中存放viewName：目标地址和attribute参数来实现传参： ModelAndView mv=new ModelAndView(); mv.setViewName="success
WebService存在的必要性？一炮送你回车库 webservice
做Java的经常在选择Webservice框架上徘徊很久，Axis Xfire Axis2 CXF ，他们只有一个功能，发布HTTP服务然后用XML做数据传输。是的，他们就做了两个功能，发布一个http服务让客户端或者浏览器连接，接收xml参数并发送xml结果。当在不同的平台间传输数据时，就需要一个都能解析的数据格式。但是为什么要使用xml呢？不能使json或者其他通用数据
js年份下拉框 3213213333332132 java web ee
<div id="divValue">test...</div>测试 //年份 <select id="year"></select> <script type="text/javascript"> window.onload =
简单链式调用的实现技术归来朝歌方法调用链式反应编程思想
在编程中，我们可以经常遇到这样一种场景：一个实例不断调用它自身的方法，像一条链条一样进行调用这样的调用你可能在Ajax中，在页面中添加标签： $("<p>").append($("<span>").text(list[i].name)).appendTo("#result"); 也可能在HQ
JAVA调用.net 发布的webservice 接口 darkranger webservice
/** * @Title: callInvoke * @Description: TODO(调用接口公共方法) * @param @param url 地址 * @param @param method 方法 * @param @param pama 参数 * @param @return * @param @throws BusinessException
Javascript模糊查找 | 第一章循环不能不重视。 aijuans Way
最近受我的朋友委托用js+HTML做一个像手册一样的程序，里面要有可展开的大纲，模糊查找等功能。我这个人说实在的懒，本来是不愿意的，但想起了父亲以前教我要给朋友搞好关系，再加上这也可以巩固自己的js技术，于是就开始开发这个程序，没想到却出了点小问题，我做的查找只能绝对查找。具体的js代码如下： function search(){ var arr=new Array("my
狼和羊，该怎么抉择 atongyeye 工作
狼和羊，该怎么抉择在做一个链家的小项目，只有我和另外一个同事两个人负责，各负责一部分接口，我的接口写完，并全部测联调试通过。所以工作就剩下一下细枝末节的，工作就轻松很多。每天会帮另一个同事测试一些功能点，协助他完成一些业务型不强的工作。今天早上到公司没多久，领导就在QQ上给我发信息，让我多协助同事测试，让我积极主动些，有点责任心等等，我听了这话，心里面立马凉半截，首先一个领导轻易说
读取android系统的联系人拨号百合不是茶 android sqlite数据库内容提供者系统服务的使用
联系人的姓名和号码是保存在不同的表中,不要一下子把号码查询来,我开始就是把姓名和电话同时查询出来的,导致系统非常的慢关键代码: 1, 使用javabean操作存储读取到的数据 package com.example.bean; /** * * @author Admini
ORACLE自定义异常 bijian1013 数据库自定义异常
实例： CREATE OR REPLACE PROCEDURE test_Exception ( ParameterA IN varchar2, ParameterB IN varchar2, ErrorCode OUT varchar2 --返回值,错误编码 ) AS /*以下是一些变量的定义*/ V1 NUMBER; V2 nvarc
查看端号使用情况征客丶 windows
一、查看端口在windows命令行窗口下执行： >netstat -aon|findstr "8080" 显示结果： TCP 127.0.0.1:80 0.0.0.0:0 &
【Spark二十】运行Spark Streaming的NetworkWordCount实例 bit1129 wordcount
Spark Streaming简介 NetworkWordCount代码 /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with
Struts2 与 SpringMVC的比较 BlueSkator struts2 spring mvc
1. 机制：spring mvc的入口是servlet，而struts2是filter，这样就导致了二者的机制不同。 2. 性能：spring会稍微比struts快。spring mvc是基于方法的设计，而sturts是基于类，每次发一次请求都会实例一个action，每个action都会被注入属性，而spring基于方法，粒度更细，但要小心把握像在servlet控制数据一样。spring
Hibernate在更新时，是可以不用session的update方法的(转帖） BreakingBad Hibernate update
地址：http://blog.csdn.net/plpblue/article/details/9304459 public void synDevNameWithItil() {Session session = null;Transaction tr = null;try{session = HibernateUtil.getSession();tr = session.beginTran
读《研磨设计模式》-代码笔记-观察者模式 bylijinnan java 设计模式
声明：本文只为方便我个人查阅和理解，详细的分析以及源代码请移步原作者的博客http://chjavach.iteye.com/ import java.util.ArrayList; import java.util.List; import java.util.Observable; import java.util.Observer; /** * “观
重置MySQL密码 chenhbc mysql 重置密码忘记密码
如果你也像我这么健忘，把MySQL的密码搞忘记了，经过下面几个步骤就可以重置了（以Windows为例，Linux/Unix类似）： 1、关闭MySQL服务 2、打开CMD，进入MySQL安装目录的bin目录下，以跳过权限检查的方式启动MySQL mysqld --skip-grant-tables 3、新开一个CMD窗口，进入MySQL mysql -uroot
再谈系统论，控制论和信息论 comsci 设计模式生物能源企业应用领域模型
再谈系统论，控制论和信息论偶然看
oracle moving window size与 AWR retention period关系 daizj oracle
转自： http://tomszrp.itpub.net/post/11835/494147 晚上在做11gR1的一个awrrpt报告时,顺便想调整一下AWR snapshot的保留时间,结果遇到了ORA-13541这样的错误.下面是这个问题的发生和解决过程. SQL> select * from v$version; BANNER -------------------
Python版B树 dieslrae python
话说以前的树都用java写的,最近发现python有点生疏了,于是用python写了个B树实现,B树在索引领域用得还是蛮多了,如果没记错mysql的默认索引好像就是B树... 首先是数据实体对象,很简单,只存放key,value class Entity(object): '''数据实体''' def __init__(self,key,value)
C语言冒泡排序 dcj3sjt126com 算法
代码示例： # include <stdio.h> //冒泡排序 void sort(int * a, int len) { int i, j, t; for (i=0; i<len-1; i++) { for (j=0; j<len-1-i; j++) { if (a[j] > a[j+1]) // >表示升序
自定义导航栏样式 dcj3sjt126com 自定义
-(void)setupAppAppearance { [[UILabel appearance] setFont:[UIFont fontWithName:@"FZLTHK—GBK1-0" size:20]]; [UIButton appearance].titleLabel.font =[UIFont fontWithName:@"FZLTH
11.性能优化-优化-JVM参数总结 frank1234 jvm参数性能优化
1.堆 -Xms --初始堆大小 -Xmx --最大堆大小 -Xmn --新生代大小 -Xss --线程栈大小 -XX:PermSize --永久代初始大小 -XX:MaxPermSize --永久代最大值 -XX:SurvivorRatio --新生代和suvivor比例,默认为8 -XX:TargetSurvivorRatio --survivor可使用
nginx日志分割 for linux HarborChung nginx linux 脚本
nginx日志分割 for linux 默认情况下，nginx是不分割访问日志的，久而久之，网站的日志文件将会越来越大，占用空间不说，如果有问题要查看网站的日志的话，庞大的文件也将很难打开，于是便有了下面的脚本使用方法，先将以下脚本保存为 cutlog.sh，放在/root 目录下，然后给予此脚本执行的权限复制代码代码如下: chmo
Spring4新特性——泛型限定式依赖注入 jinnianshilongnian spring spring4 泛型式依赖注入
Spring4新特性——泛型限定式依赖注入 Spring4新特性——核心容器的其他改进 Spring4新特性——Web开发的增强 Spring4新特性——集成Bean Validation 1.1(JSR-349)到SpringMVC Spring4新特性——Groovy Bean定义DSL Spring4新特性——更好的Java泛型操作API Spring4新
centOS安装GCC和G++ liuxihope centos gcc
Centos支持yum安装，安装软件一般格式为yum install .......，注意安装时要先成为root用户。按照这个思路，我想安装过程如下：安装gcc：yum install gcc 安装g++： yum install g++ 实际操作过程发现，只能有gcc安装成功，而g++安装失败，提示g++ command not found。上网查了一下，正确安装应该
第13章 Ajax进阶（上） onestopweb Ajax
index.html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/
How to determine BusinessObjects service pack and fix pack blueoxygen BO
http://bukhantsov.org/2011/08/how-to-determine-businessobjects-service-pack-and-fix-pack/ The table below is helpful. Reference BOE XI 3.x 12.0.0. y BOE XI 3.0 12.0. x. y BO
Oracle里的自增字段设置 tomcat_oracle oracle
　大家都知道吧，这很坑，尤其是用惯了mysql里的自增字段设置，结果oracle里面没有的。oh，no 　　我用的是12c版本的，它有一个新特性，可以这样设置自增序列，在创建表是，把id设置为自增序列 create table t ( id 　　　　 number generated by default as identity (start with 1 increment b
Spring Security（01）——初体验 yang_winnie spring Security
Spring Security（01）——初体验博客分类： spring Security Spring Security入门安全认证首先我们为Spring Security专门建立一个Spring的配置文件，该文件就专门用来作为Spring Security的配置

Spring websocket 使用

21. WebSocket Support

21.1 Introduction

21.1.1 WebSocket Fallback Options

21.1.2 A Messaging Architecture

21.1.3 Sub-Protocol Support in WebSocket

21.1.4 Should I Use WebSocket?

21.2 WebSocket API

21.2.1 Create and Configure a WebSocketHandler

21.2.2 Customizing the WebSocket Handshake

21.2.3 WebSocketHandler Decoration

21.2.4 Deployment Considerations

21.2.5 Configuring the WebSocket Engine

21.3 SockJS Fallback Options

21.3.1 Overview of SockJS

21.3.2 Enable SockJS

21.3.3 HTTP Streaming in IE 8, 9: Ajax/XHR vs IFrame

21.3.4 Heartbeat Messages

21.3.5 Servlet 3 Async Requests

21.3.6 CORS Headers for SockJS

21.3.7 SockJS Client

21.4 STOMP Over WebSocket Messaging Architecture

21.4.1 Overview of STOMP

21.4.2 Enable STOMP over WebSocket

21.4.3 Flow of Messages

21.4.4 Annotation Message Handling

21.4.5 Sending Messages

21.4.6 Simple Broker

21.4.7 Full-Featured Broker

21.4.8 Connections To Full-Featured Broker

21.4.9 Using Dot as Separator in @MessageMapping Destinations

21.4.10 Authentication

21.4.11 User Destinations

21.4.12 Listening To ApplicationContext Events and Intercepting Messages

21.4.13 WebSocket Scope

21.4.14 Configuration and Performance

21.4.15 Runtime Monitoring

21.4.16 Testing Annotated Controller Methods

你可能感兴趣的:(websocket)

21.4.9 Using Dot as Separator in `@MessageMapping` Destinations