Spring WebSocket details, springwebsocket

Spring WebSocket details, springwebsocket

Spring WebSocket
The Spring framework supports WebSocket from version 4.0. The following describes the content of the Spring WebSocket library. The content includes how the Spring framework supports WebSocket message communication in Web applications, and how to use the STOMP protocol as the sub-Protocol of the application layer-WebSocket.

1. Introduction to the WebSocket Protocol

WebSocket protocol is an important function of Web domain defined by RFC-6455 specification: full duplex, that is, bidirectional communication between the client and the server. It is an exciting feature that has been explored for a long time in the industry. The technologies used include Java Applet, XMLHttpRequest, Adobe Flash, ActiveXObject, various Comet technologies, and server-side sending events.
You need to understand that before using the WebSocket protocol, you must use the HTTP protocol to build the initial handshake. This depends on a mechanism-establish HTTP, request protocol upgrade (or protocol conversion ). After the server agrees, it will respond to HTTP status code 101, indicating that it agrees to switch the protocol. Assume that the handshake is successful through TCP socket, and the HTTP protocol upgrade request is passed, the client and server can send messages to each other.

Spring framework 4.0 and later versions introduce a new module, namely the spring-websocket module. It supports WebSocket communication. It is compatible with Java WebSocket API specification JSR-356 and provides additional functionality

2. WebSocket downgrade options

The browser's support for WebSocket is not fast, and IE is only available in version 10th. In addition, some proxy tools also restrict WebSocket communication. Therefore, even if you want to develop a WebSocket application, downgrading options are essential for simulating WebSocket APIs in scenarios that are not supported. The Spring framework provides this transparent degradation solution-using the SockJS protocol. This scheme can be automatically switched through configuration without modifying the application code.

3. Message Communication Architecture

In addition to development challenges, WebSocket is also difficult to consider in design.
Currently, the REST architecture is a widely accepted, easy to understand, and suitable for building modern Web applications. The REST architecture relies on many URLs and several HTTP methods, and uses the principles of linking and maintaining stateless.
In contrast, the WebSocket application may use only one URL for the initial HTTP handshake. All subsequent messages share the TCP connection, and messages flow in two directions. This point shows that it is completely different from the REST architecture, and is asynchronous, event-driven, and message transmission architecture. The WebSocket architecture is similar to traditional message transmission solutions (such as JMS and AMQP.

Spring framework 4.0 introduces a new module-spring-messaging module, which contains many conceptual abstractions from the Spring Integration project, such as Message, Message channel MessageChannel, and Message handle MessageHandler. This module also includes a set of annotations to map messages to methods, similar to the annotation-based programming model of Spring MVC.

4. WebSocket supports sub-Protocols

WebSocket is only an architecture for message transmission. It does not specify any specific message transmission protocol. It is an ultra-thin layer over TCP protocol. It can switch byte streams to message streams (text and cargo binary ). Then the application will explain the message.
Different from the HTTP protocol, the WebSocket protocol is only an application-level protocol. It is very simple and cannot understand incoming messages or route or process messages. Therefore, the WebSocket protocol is the underlying layer of the application-level protocol, which requires a framework to understand and process messages.
For this reason, the WebSocket RFC defines the use of sub-protocols. During the handshake, the client and the server can use the Sec-WebSocket-Protocol in the Header to negotiate the sub-Protocol, that is, the more advanced application-level Protocol. The use of sub-protocols is not necessary, but even if you do not use sub-protocols, the application still needs to select a message format-a format that allows the client and the server to understand each other. This format can be customized, framework-specific, or standard messaging protocols.

The Spring framework provides support for using the STOMP sub-protocol.
STOMP, Streaming Text Orientated Message Protocol, and stream Text oriented Message Protocol. STOMP is a simple messaging protocol and a simple text protocol designed for Message Oriented Middleware (Message Oriented Middleware.
STOMP provides an interoperable connection format that allows the STOMP client to interact with any STOMP Message Broker, similar to the OpenWire protocol (a binary protocol ).

5. What scenarios should I use WebSocket?

In Web applications, when the client and server need to exchange events with a high frequency and a low latency, WebSocket is suitable. Therefore, WebSocket is suitable for finance, games, collaboration, and other application scenarios.
It is not suitable for other application scenarios. For example, if a News subscription needs to display sudden news, long polling interval of several minutes is also acceptable, and the latency here is acceptable.
Even in scenarios that require low latency, if the number of messages transmitted is low (for example, in scenarios where network failures are monitored), the long polling technology should be considered.

The choice of WebSocket protocol is very suitable only in scenarios with low latency and high-frequency message communication. Even in such an application scenario, does WebSocket communication still exist? Or should I choose REST HTTP Communication?
The answer is that it depends on the needs of the application. However, these two technologies may also be used at the same time to put frequently exchanged data into WebSocket for implementation, while the rest api is used as the Implementation Technology of procedural businesses. In addition, when a rest api call needs to broadcast a certain information to multiple clients, it can also be implemented through WebSocket connection.

The Spring framework provides @ Controller annotation and @ RestController annotation, both of which can be used for HTTP request processing and WebSocket message processing. In addition, Spring MVC's request processing methods, or other application's request processing methods, can easily use the WebSocket protocol to broadcast messages to all interested clients or specified users.

Spring WebSocket
The Spring framework supports WebSocket from version 4.0. The following describes the content of the Spring WebSocket library. The content includes how the Spring framework supports WebSocket message communication in Web applications, and how to use the STOMP protocol as the sub-Protocol of the application layer-WebSocket.

1. Introduction to the WebSocket Protocol

WebSocket protocol is an important function of Web domain defined by RFC-6455 specification: full duplex, that is, bidirectional communication between the client and the server. It is an exciting feature that has been explored for a long time in the industry. The technologies used include Java Applet, XMLHttpRequest, Adobe Flash, ActiveXObject, various Comet technologies, and server-side sending events.
You need to understand that before using the WebSocket protocol, you must use the HTTP protocol to build the initial handshake. This depends on a mechanism-establish HTTP, request protocol upgrade (or protocol conversion ). After the server agrees, it will respond to HTTP status code 101, indicating that it agrees to switch the protocol. Assume that the handshake is successful through TCP socket, and the HTTP protocol upgrade request is passed, the client and server can send messages to each other.

Spring framework 4.0 and later versions introduce a new module, namely the spring-websocket module. It supports WebSocket communication. It is compatible with Java WebSocket API specification JSR-356 and provides additional functionality

2. WebSocket downgrade options

The browser's support for WebSocket is not fast, and IE is only available in version 10th. In addition, some proxy tools also restrict WebSocket communication. Therefore, even if you want to develop a WebSocket application, downgrading options are essential for simulating WebSocket APIs in scenarios that are not supported. The Spring framework provides this transparent degradation solution-using the SockJS protocol. This scheme can be automatically switched through configuration without modifying the application code.

3. Message Communication Architecture

In addition to development challenges, WebSocket is also difficult to consider in design.
Currently, the REST architecture is a widely accepted, easy to understand, and suitable for building modern Web applications. The REST architecture relies on many URLs and several HTTP methods, and uses the principles of linking and maintaining stateless.
In contrast, the WebSocket application may use only one URL for the initial HTTP handshake. All subsequent messages share the TCP connection, and messages flow in two directions. This point shows that it is completely different from the REST architecture, and is asynchronous, event-driven, and message transmission architecture. The WebSocket architecture is similar to traditional message transmission solutions (such as JMS and AMQP.

Spring framework 4.0 introduces a new module-spring-messaging module, which contains many conceptual abstractions from the Spring Integration project, such as Message, Message channel MessageChannel, and Message handle MessageHandler. This module also includes a set of annotations to map messages to methods, similar to the annotation-based programming model of Spring MVC.

4. WebSocket supports sub-Protocols

WebSocket is only an architecture for message transmission. It does not specify any specific message transmission protocol. It is an ultra-thin layer over TCP protocol. It can switch byte streams to message streams (text and cargo binary ). Then the application will explain the message.
Different from the HTTP protocol, the WebSocket protocol is only an application-level protocol. It is very simple and cannot understand incoming messages or route or process messages. Therefore, the WebSocket protocol is the underlying layer of the application-level protocol, which requires a framework to understand and process messages.
For this reason, the WebSocket RFC defines the use of sub-protocols. During the handshake, the client and the server can use the Sec-WebSocket-Protocol in the Header to negotiate the sub-Protocol, that is, the more advanced application-level Protocol. The use of sub-protocols is not necessary, but even if you do not use sub-protocols, the application still needs to select a message format-a format that allows the client and the server to understand each other. This format can be customized, framework-specific, or standard messaging protocols.

The Spring framework provides support for using the STOMP sub-protocol.
STOMP, Streaming Text Orientated Message Protocol, and stream Text oriented Message Protocol. STOMP is a simple messaging protocol and a simple text protocol designed for Message Oriented Middleware (Message Oriented Middleware.
STOMP provides an interoperable connection format that allows the STOMP client to interact with any STOMP Message Broker, similar to the OpenWire protocol (a binary protocol ).

5. What scenarios should I use WebSocket?

In Web applications, when the client and server need to exchange events with a high frequency and a low latency, WebSocket is suitable. Therefore, WebSocket is suitable for finance, games, collaboration, and other application scenarios.
It is not suitable for other application scenarios. For example, if a News subscription needs to display sudden news, long polling interval of several minutes is also acceptable, and the latency here is acceptable.
Even in scenarios that require low latency, if the number of messages transmitted is low (for example, in scenarios where network failures are monitored), the long polling technology should be considered.

The choice of WebSocket protocol is very suitable only in scenarios with low latency and high-frequency message communication. Even in such an application scenario, does WebSocket communication still exist? Or should I choose REST HTTP Communication?
The answer is that it depends on the needs of the application. However, these two technologies may also be used at the same time to put frequently exchanged data into WebSocket for implementation, while the rest api is used as the Implementation Technology of procedural businesses. In addition, when a rest api call needs to broadcast a certain information to multiple clients, it can also be implemented through WebSocket connection.

The Spring framework provides @ Controller annotation and @ RestController annotation, both of which can be used for HTTP request processing and WebSocket message processing. In addition, Spring MVC's request processing methods, or other application's request processing methods, can easily use the WebSocket protocol to broadcast messages to all interested clients or specified users.