News for hackers. Stuff that matters.
Re:A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-C... by kstrauser on Sunday June 27, 2021 @10:43AM (#27651953)
I think the disconnect between your experience and others’ may involve the complexity of the sites you’re talking about. If you have a simple site that has a few images, HTTP 1 may be nearly equal to HTTP 2/3. If you have a complex site with a lot of resources, and your server software allows you to push resources you know the client will need before the client even gets around to asking for them, HTTP 2/3 can be a clear winner.
Re:A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-C... by kilburn on Sunday June 27, 2021 @03:05PM (#27654271)
I think you are speaking about HTTP push, which has been abandoned [1] (also discussed in HN [2]).

[1] https://evertpot.com/http-2-push-is-dead/

[2] https://news.ycombinator.com/item?id=25283971

Re:A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-C... by jlokier on Sunday June 27, 2021 @03:23PM (#27654441)
No, it's not Push.

As a practical matter if your page requires a large number of resources (say 50+), and you are measuring the time to complete loading all of them, HTTP/2 loads much faster than HTTP/1.1. There are some nice demo sites which show this, with pages full of small images.

This is because all requests can be issued in parallel over HTTP/2 as soon as the client knows what to request, and this reduces the number of round trip times before all resources complete loading.

Even without Push, the client usually knows all the requests after it receives the HTML or sometimes the CSS.

With HTTP/1.1, the client requests are bottlenecked in a queue limited by the number of parallel TCP+TLS connections. Some sites boost this limit by using extra subdomains. But running 50+ TCP connections bursting at the same time is not efficient, even if it does bring down the latency by parallelising. With that many, there will be a burst of congestion and possible packet loss at the low bandwidth receiving end. And the 3-way handshake and TLS handshake needed for each new TCP+TLS means the parallel request latencies are a multiple of HTTP/2 request latency.

HTTP/2 also has request header compression, which makes a difference when upstream bandwidth from the client is limited.