4 ms·
I never followed it that closely, but from afar HTTP/2 always seemed like an amazingly stupid idea to me, and I always wondered if I was missing something -- a
by patrec 6y ago
I never followed it that closely, but from afar HTTP/2 always seemed like an amazingly stupid idea to me, and I always wondered if I was missing something -- apart from all the bloat and complexity, multiplexing several streams over TCP is a typical networking rookie mistake, because chances are you will be caught out by head-of-line blocking.
First there was all this hype how awesome HTTP2 would be, no mention of head of line blocking. Then, several years later, lo and behold HTTP3 is hyped next, and one big motivation is that HTTP2 turned out to have a head of line blocking problem.
What on earth is going on here? Google obviously has great engineering talent and HTTP2 must have been high profile enough to not leave to a bunch of interns. So there must be more nuance to this, does anyone know the score?
- lemagedurage 6y agoAs explained in the article, HTTP/2 solves a HTTP-level head-of-line blocking issue over HTTP/1.1, but retains TCP-level head-of-line blocking, which is later solved by HTTP/3. The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1). Now these problems are solved incrementally, and HTTP/2 plays a part in that. Which part is stupid?
- throw0101a 6y ago> The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1). And of course SCTP (nor DCCP) are usable on the general Internet.
- patrec 6y agoI sometimes idly wonder if one of the last favors Google and the other IT behemoths could do the open web before being broken up is just announcing a plan to just use SCTP for Important Thing, and fuck people who are sitting behind broken middleware and if they don't like it complain to the idiots who block SCTP upstream (mutatis mutandis for a zillion other things that are only there to work around broken middleware). Of course there is zero chance of this happening (for one thing, it would probably greatly increase the chances of getting broken up earlier rather than later), but it's kind of nice to imagine someone of sufficient size throwing their weight around to stop socializing costs and shake up the useable protocol stack a bit again, and retire a lot of horrible hacks and complexity in one fell swoop.
- throw0101a 6y agoI'd be happy with firewall makers, instead of having "tcp" or "udp" for the protocol, have (e.g.) "stream" or "dgram". One can then have both "tcp" and "sctp" with-in "stream" and the rules wouldn't have to have special cases. DCCP would be with-in "dgram".
- patrec 6y agoI might be wrong, but is there real evidence that HTTP/2 "solves" the HTTP head of line blocking issue, in a disease was worse than the cure sort of way? Of course the reason people try to multiplex higher level protocol streams over TCP is some butt-hurt over cost/availability of multiple TCP connections and a desire to make the higher level protocol appear to have more "parallelism" than is really there. In the case of HTTP so that e.g. you are not forced to use sprite-sheets, data-urls, or just less bloat in order to minimize load latency. My experience so far is that in practice this rarely works out, you end up with nastier TCP level issues instead and I get the impression that this has been the actual experience with HTTP/2 as well. In that case the stupid part would be assuming that multiplexing over TCP is a good idea, despite various cautionary tales to the contrary. As I said, I haven't looked into this carefully so my superficial impressions might well be wrong, which is why I'd appreciate input from someone who has properly looked into it.