HTTP/2 and HTTP/3 explained

https://alexandrehtrb.github.io/posts/2024/03/http2-and-http3-explained/

by thunderbong • 2 years ago

263 87 2 years ago

alexandrehtrb.github.io

In the diagram below, request 2 cannot be sent until response 1 arrives, considering that only one TCP connection is used.

That's wrong, request 2 can be sent before response 1 arrives. Blocking is inability to receive response 2 until response 1 arrives. With HTTP/2 responses can be unordered.

tialaramex• 2 years ago

https://en.wikipedia.org/wiki/HTTP_pipelining

In practice it's not wrong. HTTP 1.x servers, and especially "middleboxes" get this badly enough wrong that when you ship this feature ("HTTP 1 pipelining") your users will report a low but persistent error rate. Oops the password request and image download were kinda sorta fused together.

You can (and some very minor browsers do) just insist it's not your bug and then painstakingly reject every incident where this is implicated, or you can just accept that this was never going to work in practice as the document you're disparaging does.

anonymoushn• 2 years ago

Do you get a mostly eliminated error rate if you only use pipelining over TLS, or have server operators situated their defective middleboxes behind their TLS termination?

ghusbands2• 2 years ago

To be very clear/direct, the HTTP pipelining you're referring to never fully worked and was always hit with problems with middleboxes, problems with servers, significant security vulnerabilities around request smuggling and more besides.

Every project I've been involved with that tried to use them eventually turned them off. So the quote is true in practise.

GoblinSlayer6• 2 years ago

AIU request smuggling, it can't be prevented by disabling pipelining, only by validation.

otbutz• 2 years ago

HTTP/3 was designed for unstable connections, such as cellphone and satellite networks.

Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.

supriyo-biswas• 2 years ago

The specific thing they’re talking about connection migration (and resumption) through multiple disconnection events — HTTP/1 and 2 do not offer a similar feature.

sgloutnikov• 2 years ago

Enjoyed these books on the same topic:

- https://http2-explained.haxx.se

- https://http3-explained.haxx.se

sylware4• 2 years ago

If HTTP[23] are more complex than HTTP1.1, it is a mistake.

GuB-42• 2 years ago

Most of the complexity actually comes from encryption. If you don't need encryption, HTTP/1.1 is great. Especially since unencrypted HTTP/2 and 3 are usually not supported.

HTTP/2 is sometimes considered a mistake.

HTTP/3 is certainly more complex than HTTP/1.1, but that's in large part because it is actually several protocols in one. It replaces TCP with QUIC and therefore implements its features. It also has encryption built-in, so it also provides some of TLS features.

It is based on UDP, but ideally it should QUIC/IP, the only reason why UDP is in the middle is to facilitate adoption.

So if you consider HTTP/3 with builtin TLS vs HTTP/1.1+TLS+TCP, I don't think there is much of a difference in complexity.

sylware4• 2 years ago

Then HTTP[23] are significantly more costly to implement, they are a mistake then.

Nothing to brag about then.

jillesvangurp• 2 years ago

It's more complex for server builders and client library builders (libcurl, netty, etc.). For web application developers, it's essentially zero effort if you use decent cloud based hosting.

We have our stuff in Google cloud. I just launched a website (while spaceX was launching a rocket) there. Simple bucket behind our load balancer. It serves http3 if your browser can handle it. If you check with curl (which can't) it falls back to http2. Our API runs there as well and a few other things. Just works. It's not even a configuration option. It's just part of the package.

Most of this stuff is either necessary complexity or useful complexity. Running without TLS is not really something you should be doing over a public network. And some people would argue even on a private network. So that's necessary complexity.

UDP vs. TCP is a no-brainer as well for mobile and roaming type use cases. Just a lot easier to deal with via UDP. With TCP you have to deal with connections timing out, connection overhead, etc. With UDP, which is connection less, switching networks is a lot less dramatic.

And then there's the notion of not needing multiple connections to download/stream multiple things. Since UDP has no connections, HTTP3 multiplexes it's own notion of "connections" on top of that. So, you are not constrained by browsers limiting you to just 4 or 8 connections per website (or whatever the number is these days). A bit more complex to implement but useful.

KaiserPro8• 2 years ago

This is called head-of-line blocking. In the diagram below, request 2 cannot be sent until response 1 arrives, considering that only one TCP connection is used.

Thats not really head of line blocking, because in HTTP1.1 you'd just open up another connection. The issue with HTTP1.1 is that opening up lots of connections can introduce lots of latency, especially if you are doing Encryption.

HTTP1.1 performs much much better over high latency or lossy links than http2

With HTTP/2, this problem is solved with streams, each stream corresponds to a message. Many streams can be interleaved in a single TCP packet. If a stream can't emit its data for some reason, other streams can take its place in the TCP packet.

This is where HTTP2 failed. It shoved everything into one single TCP connection which works fine on LAN and LAN like networks, and sucks balls in the real world. This is Top of line blocking and was entirely predictable had the HTTP2 team bothered to talk to anyone who did networking.

Its part of the reason why I was greatly suspicious of QUIC, because it appeared like it was designed by the same people that thought http2 was a good idea.

However QUIC seems to be actually reasonable. I've yet to fully test it in real world scenarios, but it does offer promise for highspeed latency resistant data streaming. One day I'll re-write my TCP multiplexor to compare the performance.

ghusbands2• 2 years ago

entirely predictable had the HTTP2 team bothered to talk to anyone who did networking

I think it's good that things have evolved rather than being stuck behind naysaying. Sure, there were pitfalls/hurdles that could have been avoided, but it's not clear that maintaining perfection every step of the way would have got us to QUIC.

blueflow2• 2 years ago

This is not some pitfall. This is a major problem in tech and IMHO totally unacceptable. The same things are re-invented all over again and again without actually making much of an improvement.

The result of this is that we get constant upgrades and "improvements", but overall reliability, UI usability, latency and performance in general are actually worsening every year.

ithkuil• 2 years ago

I find it difficult to believe that the team that built the prototype for http/2 (SPDY), implemented it for chrome, tested it on gazillions of customers around the world, wasn't bothered to talk to anyone who did networking.

Sure you can argue that the tradeoffs they selected were the wrong tradeoffs and that they may have been biased by their narrow domain specific goals (reducing latency to render an average web page). Perhaps they thought that people with really horrible packet loss will just fallback to http or use amp or whatever.

But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did

KaiserPro8• 2 years ago

But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did

As someone who was part of the rollout of HTTP2 for a $large_website, I can confirm that "this will harm mobile performance" was outright and flatly rejected. This included people who were our reps on the w3c. I just had to sit there and wait for the real world metrics to come in

"multiplexing will remove bottlenecks!"

"benchmarks prove that its faster!"

"you just don't understand how TCP works"

"the people at google are very smart, what do you know?"

"server push will reduce latency"

etc etc etc.

We even had the graphs of page size over time (going ever up) and average usable bandwidth (not keeping up, especially on mobile) None of that mattered until the rollout had a real world effect on our performance.

liveoneggs• 2 years ago

Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.

bsdetector• 2 years ago

SPDY's header compression allowed cookies to be easily leaked. This vulnerability was well known at the time so had they even asked an intern at Google Zero to look at it they would have been immediately schooled.

https://bugzilla.mozilla.org/show_bug.cgi?id=779413

In their performance tests vs HTTP 1.1 the team simulated loading many top websites, but presumably by accident used a single TCP connection for SPDY across the entire test suite (this was visible in their screenshots of Chrome's network panel, no connection time for SPDY).

They also never tested SPDY against pipelining - but Microsoft did and found pipelining performed the same. SPDY's benefit was merely a cleaner, less messy equivalent of pipelining.

So I think it's fair to say these developers were not the best Google had to offer.

jchw2• 2 years ago

HTTP/1.1 (RFC2616) specified a limit of two connections per server, which most browsers initially interpreted to mean per-origin, which still lead to quite a lot of unnecessary blocking. I think browsers eventually decided to increase that to 6, but as evidenced by viewing the "Network" tab of the Developer Tools on a lot of modern pages, it is in fact not very uncommon anymore to have a substantially larger number of resources per origin.

While it's true that HTTP/2 can be worse than HTTP/1.1, I don't think it usually is; it's pretty easy to demonstrate just how much better HTTP/2 is over a typical Internet connection. SPDY and HTTP/2 were clearly better and rarely worse, whereas HTTP/3 is almost never worse (maybe when interplay with TCP rate control is poor?) On very unreliable and very high latency connections it can definitely go the other way, but statistically my experience is that a large majority of cases see an improvement on plain-old HTTP/2.

That said, for all of the complexity HTTP/2 adds, it is kind of a nice protocol. I like that all of the "special" parts of the HTTP/1.1 request and response were just turned into header fields. HPACK is a minor pain in the ass, but it is pretty efficient. You get multiple concurrent bidirectional streams per connection and they can each send headers/trailers. There's even the MASQUE protocol, which enables unreliable datagrams with HTTP/3. Put together this makes HTTP/2 and HTTP/3 amazingly versatile protocols that you can really use for all kinds of shit, which makes sense given the legacy of HTTP/1.1.

There are some pitfalls even still. For example, all of this added complexity has made life a bit harder for load balancing and middleboxes. TCP level load balancing or round robin is basically defeated by using HTTP/2 multiplexing, without the client being explicitly cautious of this.

pi-e-sigma8• 2 years ago

This limit is completely artificial. Let's limit HTTP/2 to maximum 6 multiplexed streams per connection and see how it fares with HTTP1.1 with 6 TCP connections to the server. All of sudden HTTP1.1 wins :)

richardwhiuk3• 2 years ago

That's not really head of line blocking, because in HTTP1.1 you'd just open up another connection.

All browsers cap the number of connections which are opened to a single domain (I think on IE this was 4, and has increased to 10, but it's not a large number).

KaiserPro8• 2 years ago

you are correct, but with keepalive, 10 connections over http1 will beat 1 connection over http2[1] even 4 connections will do better.

[1] when there is high latency, or some packet loss, and the requests are batched evenly over all connections.

jeltz• 2 years ago

One thing in favor of QUIC is that it had a lot of other people also working on it, not just the HTTP2 team. People like Daniel Stenberg who have worked in networking for ages and are not beholden to the incentive structures at Google.

alwaysjoe• 2 years ago

According to his Wikipedia page he was also on the working group for HTTP2

dontlaugh• 2 years ago

HTTP/2 works quite well in practice though, both in browsers and for custom RPC protocols. Certainly better than HTTP/1.1.

KaiserPro8• 2 years ago

It works well on desktop. On mobile it really performs badly. especially if you are doing interactive things and lazy loading.

1vuio0pswjnm7• 2 years ago

It is imposible to meaningfuly evaluate these different protocols against each other without considering the "use case". For example, if someone is requesting 100 pages from a site, all hosted on the same domain, and nothing else,1 then HTTP/1.1 is the best of the three. The requests can be sent over a single connection. HOL blocking is not an issue. I have tested this exhaustively outside the browser for over a decade. (People promoting HTTP/2 and HTTP/3, and HN commenters submitting snarky replies every time I mention the utility of HTTP/1.1 pipelining, apparently have not tested this at all.)

1. This is text retrieval. The www is not a handful of browsers controlled by companies that seek to profit from advertising. It was and still is a facility that provides for (hyper)text retrieval.

HTTP/2 and HTTP/3 come from an advertising commpany and a CDN that expect ads hosted on different domains in every page. That is what _they_ want. Is that want _www users_ want. We do not know because www users were never asked. We do know that www users do not like ads. When given the choice, they say, "No."

The advertising company keeps repeating this HOL blocking as a problem of HTTP/1.1, and now it gets parroted everywhere, and few even know what it means. HOL blocking is not a problem if the www user is not requesting ads and tracking from different domains. How many www users actually want to request ads and tracking and particpate in telemetry. The so-called "tech" company might try to argue that all of them do, or more commonly that, "They do not care." Meanwhile its own employees call ad blocking a "right of passage" (direct quote from a reply I got on HN).

The truth is that when evaluating these new HTTP protocols, it matters what the www user is trying to do. Many users are simply trying to retrieve information as text. But the advertising company believes that www users only want to do what is in the interest of the advertising company: let the advertising company's browser automatically send requests for ads, tracking and telemetry purposes. (Except for employees of so-called "tech" companies profiting from the sale of online ad services. They exempted and are free to block the ads and tracking.)

ntwrkgy• 2 years ago

This is Top of line blocking and was entirely predictable had the HTTP2 team bothered to talk to anyone who did networking. > Its part of the reason why I was greatly suspicious of QUIC, because it appeared like it was designed by the same people that thought http2 was a good idea.

Agreed - i've always found them to be living in a world of their own, which doesn't match the realities of actual networking out there.

In fact, the very same team after touting QUIC over UDP as the revolutionary protocol is now complaining that the real world realities aren't matching their expectations and so are now proposing to do QUIC over TCP. Here's that proposal https://mailarchive.ietf.org/arch/msg/quic/N82WBOa_RJIb4cPQw...

IgorPartola2• 2 years ago

the UDP protocol wasn't optimized by routers and operating systems over the last decades due to its low usage, making it comparatively slower than TCP

What exactly does this mean?

subtra3t• 2 years ago

I haven't read the article yet but I think that means that UDP was used less than TCP and so routers/operating systems didn't optimize for it as much as they did for TCP. Hope this helps.

IgorPartola2• 2 years ago

Right that’s all it says on this subject. I am curious about what optimizations TCP has benefitted from that we’re not but could be applied to UDP.

chasd00• 2 years ago

there's nothing to optimize with UDP, you put a datagram on the wire and off it goes. There's no sequence number like in TCP to re-order and construct a stream on the receiving side. There is no stream, it's UDP. You put a datagram on the wire and that's it. There no syn/ack either so no congestion control in routers, no back-off or anything.

goodburb• 2 years ago

When loading many images [0] different browsers load the image in a different order and parallelism[1], especially HTTP/3 with Firefox [2]:

[0] https://github.com/TalalMash/100-Image-Load-Test

[1] https://imgur.com/a/b8P3XvB

[2] https://forum.openwrt.org/uploads/default/original/3X/b/c/bc...

superkuh4• 2 years ago

The biggest difference is that HTTP/3 (and to a lesser extent, 2) are designed and implemented entirely and exclusively for for profit-business use cases at the detriment to all other use cases and specifically longevity. Since there are no HTTP/3 implementations that allow the use of non-CA TLS or even just plain text that means in order to host a visitable website for major browsers you have to get continued re-approval from a third party corporation every ~3 months. This means that websites using HTTP/3 will have very short unmaintained lifetimes. HTTP/3 sites will not last many years. They'll simply become unvisitable in a fraction of a year if there's ever any problem in the huge chain of complexity that is acme2 (and when acme2 is deprecated and turned off a huge portion of the web will die, much more than died when acme1 was turned off on LE).

There is one feasible change that can be made now: Firefox needs to change the flags in it's HTTP/3 library build so that self signed certs are allowed.

JackSlateur7• 2 years ago

Which is, in my opinion, good

I am sick of seing all kind of unsecure websites (or other things over TLS) as well as private CA

Those things should not be put in production. If people cannot willingly work properly, then their life should be made harder and harder.

afavour• 2 years ago

Nope. It should be possible to set up infrastructure to serve web content without being beholden to a certificate authority. By all means there can be a bunch of warnings whenever anyone tries to access it but it should still be possible.

globular-toast• 2 years ago

So we squeeze a tiny bit more performance out of existing networks, then that immediately becomes normal again. Except now we have protocols that are difficult to implement, debug and understand.

kaycey20222• 2 years ago

Implementing concurrency in network protocols seems to be more than just a tiny improvement

JackSlateur7• 2 years ago

About QUIC evolutions : https://lwn.net/Articles/964377/

kaycey20222• 2 years ago

This was such a nice, concise article. It laid out everything so clearly and now I'm off exploring this subject by myself.

kiney• 2 years ago

What I don't understand: Why was the multiplexing in HTTP/2 and 3 pulled into the application layer instead of using a layer 4 protocol like SCTP?

HTTP/2 and HTTP/3 explained

Related Stories