HTTP/2 or Websockets for low latency client to ser

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 ?

Answer 1

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.

Answer 2

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?