HTTP/2 and HTTP/3 explained
alexandrehtrb.github.io
alexandrehtrb.github.io
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.
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.
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.
is this just a rose-tinted gut feel, or do you have actual data?
UI usability: This is a discoverable, good UI: https://jbss.de/bilder/scr118d.gif . You can instantly tell what is a button, where you can enter text and what is inert. You can even read out all the hotkeys from the screenshot. Now, without hovering over it with your mouse, check the header of this post (the grey line) and tell me which strings will take you to a place (= are a link), which do an action (= are a button) or are inert. They all look the same and you need to investigate it first with the cursor. And even then you can't tell the buttons ("flag", "vouch") apart from the links ("parent", "context").
Latency and performance: I played RTS games for 15 years. Despite getting old and rustly, i easily hit 120 APM during office work. I can tell if an application can handle it. Things like the Windows Start menu were fast enough for me until like Vista, but now they aren't - i need to wait a bit or i click before it is popped up.
The CPU/GPU required to render an interface at 60hz has gone up inline with moore's law.
Last I checked my old commodore PET wasn’t rendering ray-traced 4K UHD graphics at 60hz…
60hz is pretty easy if all you are doing is a simple character buffer.
Nor is my phone, yet newer apps are now struggling to render basic GUIs at 60hz.
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
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.
This sounds like a bullshit conspiratorial excuse. If you have real world data and you aren't afraid of having peers looking through it, nothing prevents you from presenting it to peers.
So where is that data?
Instead, you just have vague unsupported unbelievable claims made by random people in the internet, as if that's any way to decide over policy, and any faint doubt raised over that claim is faced with conspiratorial remarks complemented by statements on how everyone around OP is incompetent except him.
I will go as far as to claim OP's assertion is unbelievable, to the point of sounding like bullshit. It's entirely unbelievable that people designing protocols for a multinational corporation whose bread and butter is stuff done over TCP connections were oblivious to how TCP works, and the most incompetent of them would bother to design the first major revision of HTTP. Unbelievable.
But hey, some random guy online said something, so it must be true!
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.
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.
It’s also a specious argument anyway. The six connection limit isn’t purely artificial, opening and tracking TCP connection state is expensive, and happens entirely in the kernel. There’s a very real cap on how many TCP connections a machine can serve before the kernel starts barfing, and that cap is substantially lower than the number of multiplexed streams you can push over a single TCP connection.
You’re also completely ignoring TCP slow start process, which you can bet your bottom dollar will prevent six TCP streams beating six multiplexed streams over a single TCP stream when measuring latency from first connection.
Oh and while doing that, also feel free to respond to the rest of comment that outlines why opening an unbounded number of TCP connections to a server might be a bad idea.
Besides that, more than half my point is that I like HTTP/2 and HTTP/3 for the featureset, and you can't get that by increasing the max connection limit for HTTP/1.1.
When the limit is reached, all clients would be broken
Looks like a good deal indeed, why do not we do that
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).
[1] when there is high latency, or some packet loss, and the requests are batched evenly over all connections.
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.)
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...
Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.
[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...
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.
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.
Browsers have spent years trying to find a way to deploy pipelining, but nothing really worked. You can't even allowlist based on known-good User-Agent or Via headers, because the broken proxies are often transparent. It's also very hard to detect pipelining errors, because you don't just get responses out of order, you may get response bodies mangled or interleaved.
The idea is truly dead. With H2 being widely supported now, and having superior pipelining in every way, there's no incentive to retry the pain of deossifying H1.
Every project I've been involved with that tried to use them eventually turned them off. So the quote is true in practise.
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.
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.
However, if you want to expose something publicly, then your own ideas matters less than the interests of your clients (at least, this is how I see things) : so exposing to the internet something without TLS or with a self-signed / private CA certificates is something that should be denied (those three propositions are the same, if you think about it).
This incredibly insecure business use case has made it so using a browser for merely surfing the web is dangerous and that's why CA TLS is required. But if you just turn JS off... it's fine.
There is so much more to the web than just business web applications selling things or institutional/government websites with private information. There are human people on the web and their use cases matter too. HTTP/3 disregards them. It's fine for now but when Chrome removes HTTP/1.1 for "security reasons" it's not going to be fine.
I do not want my coworkers to do that on any of my communications, nor my family, nor anybody.
The only known way to prevent this is encryption.
And no, it has nothing to do with browsers : the same applies to my emails, ssh, IRC and whatever.
The problem with MITM attacks is when you execute programs or exchange money or other private information. The risks when viewing public documents that don't require execution is minimal. That's my point. One use case "web app stores" ruins everything for everyone by requiring the mindset you advocate for as browser defaults. But the entire justification goes away if the end user just turns off JS auto-execute. It's not intrinsic to all use cases for the web or even most.
EDIT: Mentioning wikipedia is missing the point. Of course there are cases where CA TLS should be used. I am not denying that. I am saying there are many cases with CA TLS makes things fragile and short lived and it is not needed: like personal websites run by a human person. And these use cases are not invalidated by the existence of yet another corporate person (wikimedia).
MITM has nothing to do with read-only nor with local execution.
If you’re living in a well developed country with strong privacy laws, you might have a point. But most of the people in the world don’t, and in many places simply looking at LGBT communities can land you in jail.
Then there’s places like the U.S. with multiple states currently doing their level best to criminalise so much as thinking about an abortion. I don’t see why those states would be above scanning people’s clear text browsing habits to any signs of a possible abortion, and using it as evidence of an illegal abortion having been committed or about to be committed. They’ve certainly jailed women for less (even while pregnant).
Just because you’re among a group of people that is lucky enough to have no worries about being oppressed, or discriminated against, doesn’t mean everyone has that luxury. Encryption is good for everyone, I don’t anyone being able to easily know what I do online, because I have no idea who those people, or what their motives might be, and quite frankly I don’t care. I just don’t want them rummaging around in my life looking for opportunities to exploit me or others.
and i do. i run a personal static website over http. oh the horror.
What exactly does this mean?
1. Handing the NIC a single blob of data (> MSS) in a single operation, and having the NIC do the segmentation into multiple packets.
2. Having the NIC detect multiple exactly consecutive TCP packets on the same flow, and merging them to a single receive operation.
Hardware offload is impossible to do for UDP, since neither the NIC or OS can assume anything about the payload semantics.
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.
Nothing to brag about then.
But in reality, the world probably only needs a few dozen H3 implementations, just like there are only tens of production TCP stacks. But those implementations will be used by billions of people, hundreds of billions of machines, and handle effectively all data transmission of the entire humanity.
The leverage is massive, even the most minor improvements will be able to pay off any level of engineering effort.
Sometimes cost of implementation isn't the only consideration.
Usually, just a bunch of planned obsolescence fan boys.
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.