4 ms·

As 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 s

As 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 ago
  I 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 ago
    I'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 ago
I 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.

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 ago
I 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 ago
  I'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 ago

I 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.