Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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 ?

like image 701
rico Avatar asked Jun 20 '18 20:06

rico


People also ask

Is WebSocket low latency?

WebSockets is a technology that enables bidirectional, full-duplex communication between client and server over a persistent, single-socket connection. This allows for low-latency, realtime updates, and the creation of richer communication and gaming applications.

Does HTTP 2 replace WebSockets?

HTTP/2 does not provide a replacement for other push technologies such as WebSockets or SSE.

Should I use WebSockets or HTTP?

WebSockets allow for a higher amount of efficiency compared to REST because they do not require the HTTP request/response overhead for each message sent and received. When a client wants ongoing updates about the state of the resource, WebSockets are generally a good fit.

Will WebSocket survive HTTP 2?

Well, the answer is clearly no, for a simple reason: As we have seen above, HTTP/2 introduces Server Push which enables the server to proactively send resources to the client cache. It does not, however, allow for pushing data down to the client application itself.


2 Answers

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?

like image 184
Barry Pollard Avatar answered Sep 19 '22 05:09

Barry Pollard


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.

like image 21
Jonas Avatar answered Sep 20 '22 05:09

Jonas