Before comparing HTTP, WebSocket, and RSocket, let’s take a quick look at what network communication looks like with the following diagram of the OSI seven-layer model to better understand them later on.

1. HTTP features

HyperText Transfer Protocol (HTTP) is an application-layer Protocol for distributed, collaborative and hypermedia information systems.

HTTP has evolved in many versions, most of which are backward compatible. The use of HTTP version numbers is described in RFC 2145. The client tells the server its protocol version number at the beginning of the request, and the server responds with the same or earlier protocol version.

HTTP / 0.9 1.1

Has been out of date. Only GET is accepted as a request method, the version number is not specified in the communication, and the request header is not supported.

HTTP / 1.0 1.2

This is the first VERSION of the HTTP protocol to specify a version number in a communication.

  • Protocol version information is now sent with each request (HTTP / 1.0Appended toGETLine).
  • The status code is sent at the beginning of the response, enabling the browser to know whether the request succeeded or failed and adjust its behavior accordingly (such as updating or using local caching).
  • The introduction of the HTTP header concept allows the transfer of metadata, both for requests and responses, making the protocol very flexible and extensible.
  • With the help of the new HTTP header, you have the ability to transfer documents other than plain text HTML files.

HTTP / 1.1 1.3

In early 1997, the HTTP1.1 standard was released, just a few months after HTTP/1.0.

HTTP/1.1 uses Connection: keep-alive by default, which works well with proxy servers. It also supports piped multiple requests simultaneously to reduce line load and increase transmission speed.

The differences between HTTP/1.1 and HTTP/1.0 are as follows:

  • Cache handling
  • Bandwidth optimization and network connection usage
  • Management of error notifications
  • The sending of messages across the network
  • Maintenance of Internet addresses
  • Security and integrity

HTTP / 1.4 2

HTTP/2 differs from HTTP/1.1 in several basic ways:

  • HTTP/2 is a binary protocol rather than a text protocol. No longer readable or frictionless to create manually, improved optimization techniques can now be implemented.
  • This is a multiplexing protocol. Parallel requests can be processed within the same link, removing the order and blocking constraints of HTTP/1.x.
  • I’m compressing headers. Because Headers is often similar across a series of requests, it removes duplication and the cost of transferring duplicate data.
  • It allows the Server to populate the client cache with data requested in advance through a mechanism called Server Push.

HTTP / 1.5 3

Unlike its predecessors HTTP/1.1 and HTTP/2, TCP is deprecated in HTTP/3 in favor of a UDP-based IMPLEMENTATION of QUIC.

The advantages of HTTP/3 include:

  • Based on UDP protocol, so the connection time is shorter.
  • Address HTTP/2 header blocking problem. HTTP/2 uses multiplexing over a single TCP connection and is affected by TCP congestion control, where a small amount of packet loss can cause all streams over the entire TCP connection to be blocked. In this case, the delay in delivering the packet causes the entire connection to be delayed.
  • Better detection and repair of lost packets.
  • The transfer speed is faster, the load time is shorter and the connection is more stable

2. WebSocket features

WebSocket is a network transport protocol that enables full-duplex communication over a single TCP connection and is located at the application layer of the OSI model. WebSocket allows the server to actively push data to the client. In the WebSocket API, the browser and server only need to complete a handshake to create a persistent connection and two-way data transfer between the two.

WebSocket differs from HTTP:

  • WebSocket provides full-duplex communication, allowing data to be sent from a client to a server or from a server to a client by reusing established connection channels. The connection remains active until terminated by the client or server. HTTP provides half duplex communication.
  • The message mode of WebSocket is bidirectional, while the message mode of HTTP is request-Response.
  • WebSocket supports Push messages, which cannot be used directly in HTTP.
  • If an encrypted WebSocket connection is used, using Transport Layer Security (TLS) in a WebSocket secure connection ensures that HTTP CONNECT commands are issued when the browser is configured to use an explicit proxy server. This establishes a tunnel between the WebSocket security client and the WebSocket server, which provides low-level end-to-end TCP communication through the HTTP proxy.

Comparison between RSocket and these protocols

3.1 Vs. HTTP/1.1 & HTTP/2

  • To build an application, HTTP needs to define application semantics on top of it. Despite its ubiquity, REST is not enough to define application semantics.
  • HTTP does not support application-level flow control. HTTP/2 has added a Flow Control for HTTP streams based on the size of the byte Stream window. The Flow Control of HTTP/2 only defines the format and semantics of WINDOW_UPDATE frames. It does not specify how the receiver decides when to send frames, what values to send, or how the sender chooses to send packets. RSocket supports application layer Flow Control, which is not based on byte network layer Flow Control, but Flow Control based on application layer frame number.
  • HTTP does not support bidirectional transport (HTTP/2 Server Push is not really Push). HTTP requires Server Push to rely on Websockets. After RSocket establishes a long connection, either party can be Requester or Responder.

3.2 Comparison with TCP & QUIC

  • They have no framework or application semantics.
  • You must provide an application protocol (e.g. Netty simplifies TCP layer programming but requires custom protocols)

3.3 Comparison with WebSocket

  • WebSocket has no application semantics, just a framework.
  • An application protocol must be provided.

The resources

  1. Hypertext transfer protocol
  2. The development of HTTP
  3. HTTP/3
  4. WebSocket

Related articles in the series:

RSocket learning (I) : A preliminary study