What is the story with HTTP/2 in Rails?

Coming from Zeit Now/Next.js where I remember HTTP/2 was described as important for performance, for me as a complete non-expert it felt as a regression when I came to Rails/Heroku with the recommended Puma HTTP1.1 server; also ActionCable uses Websockets which has its limitations and is said not to be so needed with HTTP/2 (thanks to this thread for the link).

As an experiment I tried adding early hints to Puma but encountered blank page issues (reported by users, which I could then reproduce via an ngrok to my dev server).

A version number in itself does not mean anything, so do we need to care at all? What are the current framework limitations and opportunities in relation to H2? I would be grateful for any info on historical choices and the planned direction for HTTP/2 in relation to Rails.

1 Like

I can’t speak to this in any real detail but this tweet from @DHH might be worth taking a look at https://twitter.com/dhh/status/1212930897357479937

1 Like

Rails needs to be extremely careful here. HTTP/2 push is not a silver bullet. In some cases it can save an RTT for your various assets, in other cases you can end up pushing a whole bunch of data to the client in the wrong order and not gain anything out of it.

At the core HTTP/2 push is an optimization you would apply very carefully to site based on benchmarking access from a bunch of places in the world.

If you have enough CDN points close to the clients the RTT can become negligible. I am in Sydney. I reload this page … the page comes from San Jose, but the assets all come from Sydney that is really close to me. Cutting 20ms RTT down to my CDN would not gain me much.

HTTP/2 on the other hand is something almost all large scale Rails project use. We never put Puma in the wild on the Internet, there is always a proxy in front be it NGINX, NGINX+Varnish/HAProxy, Apache or the experimental H2O.

I really think the only big action item would be ensuring documentation covers how you go about hosting Rails in the wild.

Many other optimisations come much cheaper HTTP/2 server push. CDNs, Latest SSL protocols, plain old HTTP/2 and so on.

Also keep in mind Rails is not going to be doing the pushing, this is a dance between Rails and whatever proxy server that is fronting it.

See also: To push, or not to push?!

8 Likes

Thank you very much for the detailed info and interesting video. Happy to have learned more on the subject!

1 Like

What samsaffron said. We’re running HTTP/2 with HEY through nginx. The main benefit is higher concurrent loads and just a single HTTPS handshake. I don’t think HTTP/2 push is actually that interesting for most web apps, and I don’t think they’re a replacement for web sockets either.

2 Likes

NB: it is samsaffron who wrote that HTTP/2 could be seen as an alternative to WebSockets:

In a world that already had HTTP/2 it is very unlikely we would see WebSockets being ratified as it covers that vast majority of use cases WebSockets solves.

I agree 100% that HTTP/2 push is not a replacement for web sockets or event source. They are totally different beasts that exist for totally different use cases.

HTTP/2 with EventSource or XMLHttpRequest with chunked encoding do very efficient half duplex communications from a server to a client. Since HTTP/2 multiplexes, you effectively get full duplex by doing standard REST for upstream and chunked encoding for downstream.

As far as I know HTTP/2 or 3 still have not figured out how to give Web Sockets a shared home on the multiplexed connection used. I have not checked in the last 6 or so months, it may have changed.

1 Like

As someone who found your original “caution” post really insightful, I’d really thrilled if you ever followed it up with a contemporary “it’s been five years, here’s what got better, here’s what’s still worrisome, here’s what I was probably right to be concerned about but it turned out to not be so bad after all” post.

For better or worse, you’ve got the market on caution for websockets locked up. :slight_smile:

1 Like