Spring Web Reactive | 3. WebSocket | 3.1. WebSocket Overview

Tags:

The WebSocket protocol, RFC 6455, provides a standardized way to establish a full-duplex, two-way communication channel between a client and server over a single TCP connection. Although it is a different TCP protocol from HTTP, it is designed to work through HTTP and reuse existing firewall rules on ports 80 and 443.

A WebSocket conversation starts with an HTTP request that uses the HTTP Upgrade header to upgrade, or switch, to the WebSocket protocol. The following example shows this interaction.

GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket   (1)
Connection: Upgrade   (2)
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080
  • (1) The Upgrade header.
  • (2) Uses an upgraded connection.

Instead of the usual 200 status code, a server with WebSocket support returns output like the following.

HTTP/1.1 101 Switching Protocols   // (1)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp
  • (1) Protocol switch.

After a successful handshake, the TCP socket underlying the HTTP upgrade request remains open for both the client and server to continue sending and receiving messages.

A complete introduction to how WebSockets work is beyond the scope of this document. See RFC 6455, the HTML5 WebSocket chapter, or one of the many introductions and tutorials available on the web.

If a WebSocket server runs behind a web server such as nginx, you will likely need to configure it to forward WebSocket upgrade requests. Likewise, if the application runs in a cloud environment, check the cloud provider’s guidance for WebSocket support.

3.1.1. HTTP and WebSocket

WebSocket is designed to be HTTP-compatible and starts with an HTTP request, but the two protocols lead to very different architectures and application programming models.

With HTTP and REST, an application is modeled as many URLs. Clients interact with the application by accessing those URLs in a request-response style. The server routes requests to the appropriate handler based on the HTTP URL, method, and headers.

In contrast, WebSockets generally use only one URL for the initial connection. Afterward, all application messages flow over the same TCP connection. This is an entirely different asynchronous, event-driven messaging architecture.

WebSocket is a low-level transport protocol. Unlike HTTP, it does not prescribe semantics for message content. There is no way to route or process a message unless the client and server agree on its meaning.

WebSocket clients and servers can negotiate a higher-level messaging protocol, such as STOMP, through the Sec-WebSocket-Protocol header in the HTTP handshake request. Without this header, the client and server must define their own conventions.

3.1.2. When Should You Use WebSockets?

WebSockets can make a web page dynamic and interactive. However, in many cases, a combination of Ajax and HTTP streaming or long polling provides a simple and effective solution.

For example, news, email, and social feeds need dynamic updates, but updating every few minutes may be sufficient. Collaboration, gaming, and financial applications often need a more real-time experience.

Latency is not the only deciding factor. When message volume is relatively low, such as for network failure monitoring, HTTP streaming or polling can provide an effective solution. WebSockets are best suited to a combination of low latency, high frequency, and high volume.

Also note that restrictive proxies on the internet can interfere with WebSocket interactions because they are not configured to pass the Upgrade header or close long-lived connections that appear idle. This means that using WebSockets for applications behind a firewall can be a simpler decision than using them for public applications.