Table of contents
1. What is Websocket
According to the RFC 6455 standard, Websocketthe protocol provides a standardized way to establish a full-duplex, two-way communication channel between the client and the server through a TCP connection. It is a TCP protocol different from HTTP, but designed to run on top of HTTP.
WebsocketThe interaction starts with an HTTP request, which will Upgradeupgrade the request through the HTTP request header, and then switch to the Websocket protocol. The request message is as follows:
GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080
We can see that there are two special request headers in the request message, one is Upgradethe request header, which represents the upgrade to the websocket protocol. There is also a Connectionrequest header, which represents an upgraded connection.
If a normal HTTP response message is returned normally, the response code is 200, and the response message requesting to upgrade to the websocket protocol is as follows:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp
We can see that the response code returned by the status line in the response message is 101followed by Switching Protocolsthe switching protocol keyword.
After a successful handshake, the underlying HTTP upgrade request TCP socket remains open between the client and server to continue sending and receiving messages.
Note: A complete document on how Websockets work can be found in RFC 6455 .
2. Introduction to WebSocket header
We can see that there are some special websocket header information in the request and response packets, here is a brief introduction:
- Sec-WebSocket-Key : It is used to uniquely identify the initial handshake between the client and the server, and it is a Base64 encoded string.
- Sec-WebSocket-Accept : The unique identifier returned by the server for the initial handshake, which is also a Base64 encoded string, used to prove that the handshake request from the client has been received. The value of the response header is: SHA-1(" " + "
Sec-WebSocket-Key"GUID) , and then Base64 encoded.
Remarks: The GUID here is a fixed value258EAFA5-E914-47DA-95CA-C5AB0DC85B11。
- Sec-WebSocket-Protocol : WebSocket sub-protocol, for example, it can be
STOMPa protocol. - Sec-WebSocket-Version : WebSocket protocol version number, the value must be 13.
3. HTTP VS WebSocket
Although WebSocket is designed to be compatible with the HTTP protocol, the two protocols have different architectures and application programming models.
In HTTP and REST, the application is modeled as many URLs. The client and the application need to visit these URLs. The server routes the request and hands it to the appropriate processor. The processor will base on the HTTP URL, method and header. deal with.
WebSocket is the opposite of HTTP. Usually there is only one URL for the initial connection, and all subsequent application messages will be transmitted on the same TCP connection. This is a completely different asynchronous, event-driven message.
WebSocket is also a low-level transport protocol. Unlike HTTP, it does not specify the semantics of message content, which means that if the client and server do not agree on message semantics, there is no way to route and process messages.
The WebSocket client and server can negotiate to use a higher-level message protocol, such as STOMP, which can be Sec-WebSocket-Protocolspecified by the request header of the HTTP handshake request.
4. When to use WebSockets
AJAXWebSockets can make Web pages dynamic and interactive, however, and HTTP Streamingor long polling can also provide a simple and effective solution in many scenarios .
For example, news, emails, and social facts need to be updated dynamically, every few minutes is fine. Collaborative, gaming, and financial apps need to be more real-time.
Latency is not a decisive factor. If the message volume is relatively small, HTTP Streaming or long polling can also solve it. For scenarios such as low latency, high frequency, and large message volume, WebSocket is more suitable.
5. About SockJS and STOMP
SockJSBoth STOMPare technologies for communicating between Web applications and message brokers, but they solve different problems.
SockJSis a JavaScript library that provides a cross-browser solution for establishing a WebSocket connection between a web browser and a web server.
SockJSIt is intended to solve the problem of using polling and other techniques to establish real-time two-way communication in cases where WebSocket is not supported or not available. The SockJS library supports multiple transports, including WebSocket, XHR streaming, XHR short polling, etc., thus ensuring maximum compatibility and reliability.
STOMP（Simple Text Oriented Messaging Protocol）is a simple text-based messaging protocol that provides an interoperable mechanism for real-time messaging across languages and platforms.
STOMP The protocol defines a set of commands and message formats for message transfer between clients and servers, and it has nothing to do with a specific message broker, so you can use the STOMP protocol to communicate with multiple message brokers. STOMP supports both subscribe/publish and peer-to-peer modes, and can be used to implement applications such as chat rooms, notification systems, and real-time data updates.
In general, SockJSuse STOMPa combination of and for best performance and reliability.
SockJSprovides a reliable cross-browser solution for establishing WebSocket connections, while STOMP provides a standardized protocol for real-time messaging over WebSocket connections.
When SockJSusing STOMPa combination of and , you can use SockJS to establish a WebSocket connection and then use the STOMP protocol for message passing over the WebSocket connection for best performance and reliability.
