HTTP/2 or Websockets for low latency client to server messages

Question

I have a requirement to have very low latency for client to server messages in my web application.

I have seen several posts on stackoverflow saying it would be preferable to use websockets instead of HTTP for this requirement, but it was quite some time ago.

Today, in 2018, with the progress of HTTP/2, is it still worth using websockets for this use case ?

Prolusion

Answer 1

HTTP/2 has multiplexing, meaning that there should be no wait time - like there was under HTTP/1 due to the 6 connection limit per domain. So this means it could be used for a low latency connection as you say.

However there are still other overheads to HTTP such as HTTP headers, which could add significant unnecessary extra data to small requests that you would not have with web sockets.

Additionally HTTP/2 is not a full duplex protocol so can only respond to requests (though possibly with more than one response thanks to Server Push). You say you only need this for client-server messaging so this may be less of a concern for you.

The binary framing layer underpinning HTTP/2 is a full duplexed protocol so could in theory be similar to websockets but HTTP/2 does not allow this - unless you just drag out sending of the request and response bodies to fake this (long polling or Server-Sent Events). In fact Websockets over HTTP/2 has been approved which will allow the HTTP/2 binary format to be used for websockets by wrapping websockets messages in the HTTP/2 Data frame. This has the added advantage of also allowing regular HTTP messages on the same connection. It is not yet available in any browser at the time of writing (though coming in version 65 of FireFox and Chrome has started an implementation). Until then, Websockets reverts back to HTTP/1.1.

See also this question and answers: Does HTTP/2 make websockets obsolete?

Acherman

A quick clarification on the "http message size" parts: Yes http2 came with HPACK for smart header compression and it helps keep header size reasonably low. And yes http2 does indeed follow compression trends for payload-compression better than websocket (which also supports compression). Having said all these, bare in mind that http2 is taxing you under the hood for all this smart-complexity (CPU, RAM) and that if you have to deal with random http-headers (like tracking cookies that change frequently or w/e) you will have a hard time keeping the message size predictable and low. Just my 2c. – Terenceterencio

Answer 2

very low latency for client to server messages in my web application.

I read this as that you want to "connect" and then send low latency messages between client and server.

Both HTTP/2 and Websocket can be binary and the frames that your messages is transported in has similar overhead (a few bytes), but Websocket has to iterate over the full message to mask the payload and then the receiver has to reverse this. See What is the mask in a WebSocket frame?

In addition Websocket primitives is more low-level e.g. to have multiple message streams, you have to do that on your own, but it is easily done with HTTP/2. Ref Podcast about HTTP/2. Also server code gets more complicated when using both Websocket and HTTP at the same application.

Flow Control may be an issue using HTTP/1.1 Websocket, but is built-in protocol feature in HTTP/2.

Server to Client

This can be done efficiently with HTTP/2 by using fetch and response.body.getReader(); to get a ReadableStream. A good article about streams in browser JavaScript: 2016 - the year of web streams.

Client to Server

The only way to send messages from clients to server in HTTP currently is by sending a full request. Streamed request body is planned but not yet implemented by the browsers. See Fetch with ReadableStream as Request Body about streamed request body.

Asante

Answer 3

It will depend on your client and your requirements. If you are sure that your client won't close the underlying TLS connection of HTTP/2 (even when unutilized for some time), the latency for sending out message/request might be similar to a persisted websocket connection. If the client closes the connection after some idle time and a new TLS connection needs to be established, it will be worse.

In the case of a browser as client, you know that the web socket connection will be persistent, and don't know anything about HTTP connections. Maybe you can force the browser to keep up the connection by making a dummy request to a SSE endpoint on the same server and keep that up, but it's a bit of a workaround.

Apart from connection establishment there a different kinds of overheads on both protocols (flow-control & stream headers vs masking), and the impact can most likely only be estimated based on the actual application needs.

Grindlay