5 ms·

Indeed, and I won't be surprised to hear that the other advertised benefit of http/2 and beyond (avoid head of line blocking) turns out to be marginal at best,

Indeed, and I won't be surprised to hear that the other advertised benefit of http/2 and beyond (avoid head of line blocking) turns out to be marginal at best, and just as difficult to take advantage of. I've got to ask, what was all the buzz about then, and why was it necessary to "improve" a simple text protocol into a giant ball of binary protocols replacing and circumventing regular TCP/IP. In combination with subverting web standardization, I can only assume it was a deliberate effort to deprive the web of its open nature, by making it so fscking complicated that only Google is capable to implement it. Same with Kubernetes, which turns out just as the one ring to bind them all, and enslave humanity into "the cloud". I have a suspicion a coming generation will not look favorably to Google tech in a post-SV era, who managed to subvert RFC and just about every other org we had to keep the net sane.

CyberRabbi 6y ago
It saves google a very large amount of money if every chrome browser opens http3 connections to google.com on startup instead of the layered stack. You don’t see much of an effort to deprecate the layered stack and in my opinion that’s because standardizing http3 is enough to lower their costs, what other server hosts do is irrelevant to their bottom line.
chrismorgan 6y ago
You’re getting the narrative quite wrong here and assuming a great deal of bad faith that simply doesn’t exist. People often seem to think Google presented SPDY and QUIC to IETF as faits accomplis, and they were just adopted as HTTP/2 and HTTP/3 because Google said so. This is not how the standardisation processes work. Rather: (1) many involved parties recognised that something like this would be of value; (2) Google developed something, because they happened to be one of the parties that cared the most about it; (3) Google gave it to IETF; (4) all the relevant stakeholders joined in on improving it until there was consensus and practical experience that it really was worth it; and (5) it was finalised and published. What ends up being standardised normally has some quite major differences from what was initially proposed. IETF QUIC is definitely quite different from gQUIC, as HTTP/2 is from SPDY. Standardisation within IETF brings diverse parties together to improve things based upon their experience and expertise. Certainly there will be dissenters, because there are trade-offs everywhere (e.g. the Varnish author was lukewarm about HTTP/2, reckoning it wasn’t worth it and that more radical changes should be made to HTTP semantics), but the end result will be better than what was initially presented, and there must be broad consensus that what is to be published is better than what preceded it (in this case HTTP/1.1). At Fastmail I observed a fair bit of the process of the standardisation of JMAP at IETF, and it benefited enormously from the process, changing shape quite significantly in some areas from what Fastmail initially presented. The end result of HTTP/2 is definitely harder to implement than HTTP/1 (though it’s still not too bad—I implemented it in the draft days and didn’t have any real trouble, there was mostly just more to implement than with HTTP/1), but of its operational parameters, it’s better in every way than HTTP/1. Turns out that a protocol being plain-text really just isn’t useful, so long as the semantics are conveyed—literally the only people that need to care about the wire protocol are the people making tools that speak it (that is, HTTP libraries). There’s really just one issue with HTTP/2: it makes it possible to use a single TCP connection where HTTP/1 probably used up to six, but this leads to TCP head-of-line blocking issues becoming more serious. And make no mistake, TCP head-of-line blocking is a real issue on high-loss networks like the outskirts of wi-fi and cellular networks. HTTP/2’s multiplexing solved real problems, and HTTP/3’s HOLB-fixing solves the last real problem with HTTP/2. Google didn’t browbeat people into doing their will; rather, they presented a draft, and then everyone worked together to improve upon that draft, and they all (or at the least, almost all) agreed that the end result was a good improvement. > a deliberate effort to deprive the web of its own nature by making it so complicated that only Google is capable to implement it. … are you aware of how many HTTP/3 implementations there are already? In Rust alone, there are at least three fairly mature implementations: Quinn by various people, Quiche by Cloudflare, Neqo by Mozilla; as well as a handful more not-so-mature implementations. Look, I’m not fond of Google, and I do think they abuse their position in many and various places, but this is not one of them.
- tannhaeuser 6y ago
  The question is if on balance, http/2 and up really is worth the complexity when http/1.1 has served us well enough, with peak web traffic already behind us. Considering that we were able to somehow run the web (and messaging and mail and apps) 20-30 years ago with much, much less capable computers. It's almost as if computers have become way too powerful, so we had to invent atrocious web apps to offset any performance advances. Similarly, F/OSS was too ubiquitous so we had to invent "the cloud". I can't help to see anything other than a self-serving power end game in this, with a few monopolies grabbing everything left, and a legion of developers having a vested interest to keep the hamster wheel spinning. Regarding the implementations of http/2 and up you speak of, I know only a single F/OSS one (ng-http2) actually used in server-side production.
  - tick_tock_tick 6y ago
    3 has real value 2 is a waste of time. I will state with great confidence you won't see 2 in the wild in the next 5 years.
    - chrismorgan 6y ago
      I dunno, the topic may be a bit more nuanced than that because the HTTP/2 upgrade is free (via ALPN, part of the TLS handshake) while there’s not yet any good way of starting on HTTP/3. See https://news.ycombinator.com/item?id=24855848 https://news.ycombinator.com/item?id=24855848 that I wrote 42 days ago on this very topic, with arguments in both directions.
  - jlokier 6y ago
    > Regarding the implementations of http/2 and up you speak of, I know only a single F/OSS one (ng-http2) actually used in server-side production. I've been using NginX HTTP/2 for years, and that's F/OSS. It doesn't use ng-http2. Pretty sure this is widely used by others, including by Cloudflare who sponsored it.
    - tannhaeuser 6y ago
will4274 6y ago
Not sure I agree here. The binary protocol aspect of HTTP/2 is already a massive benefit, especially when combined with the ability to omit redundant headers. Consider e.g. just a basic API with Bearer tokens - those tokens are sent once instead of on each request. Cloudflare saw a 53% reduction in ingress volume size (https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/ https://blog.cloudflare.com/hpack-the-silent-killer-feature-...). These changes restore something that had been lost - efficient use of the available bandwidth - GET requests fit in one packet. W.r.t. head of line blocking, all you have to do is find a website that shows a hundred pictures or loads a hundred scripts and you can see the benefit. It's true that the benefit is minor if you're already webpacking and spriting everything, but restoring performance to naive implementations that just use the img tags is not a minor benefit. See this website for example: https://imagekit.io/demo/http2-vs-http1 https://imagekit.io/demo/http2-vs-http1. HTTP/3 adds a lot more complexity than HTTP/2 added, for a smaller benefit, but.. that's how these things go. Our processors reorder instructions too. Even if it's only single digit percent, optimization are worth it. A few percent in the processor, a few percent in the OS, a few percent from the network, a few percent from the JIT - these things add up.
- tannhaeuser 6y ago
  > W.r.t. head of line blocking, all you have to do is find a website that [...] loads a hundred scripts and you can see the benefit Ok then, I guess this answers the question regarding the other purported benefit of http/2+.
  - will4274 6y ago
    Have you ever used Facebook and clicked on "my friends"? Have you user browsed a page of forum posts where each user has their own picture? Have you ever looked at a slideshow on the internet? Have you ever gone on reddit or another aggregator site that shows thumbnails? These are hardly obscure use cases.
    - tannhaeuser 6y ago
      These things exist since way before 2000, and are working just fine without http/2+. I can think of another use case, though: sending lots of ads and videos from a single domain of a well-known ad company.
jeroenhd 6y ago
> the other advertised benefit of http/2 and beyond (avoid head of line blocking) turns out to be marginal at best When I'm on a slow connection (EDGE, for example) I can clearly notice a difference with HTTP/2. The extra round trip times and potential connection resets they might encounter do have an impact that can sometimes be measured in whole seconds of loading. The same might also be true for those forced to use satellite connections for internet access, where latencies of half a second are common even with good reception and clear weather. Burst speeds are fine, as long as the data comes in over existing connections, for which HTTP/2 provides are real benefit. Most websites still push half a megabyte of JS down your throat on slow connections, so there's not as much of an improvement as advertised, but that's not the protocol's problem. Of course there are no improvements on cable internet or faster, but there are plenty of people for whom protocols like HTTP/2 make a difference. As for Kubernetes, it's a decent tool that solves a real problem. Automated replication and load balancing isn't trivial and for companies that need it, k8s, even on bare metal, can save huge amounts of development effort. It wasn't the first product in its class, it just became the most popular. There are plenty of alternatives available online if you just look for them. That said, most "cool" companies that use kubernetes because it's the "standard" or whatever should really pick something else because you waste loads of resources for nothing if your problem doesn't need a solution as complex as K8s.
- tannhaeuser 6y ago
  EDGE won't cut it for any modern bloated site, http/2+ or not. Will timeout long before the page is loaded.
  - majewsky 6y ago
    EDGE can get you up to 1 Mib/s. Even if we just take 400 Kib/s as a sustained estimate, that's about 3 MiB/min. It's not a fun experience, but most of the times, it's enough to eventually load the site you want. (Source: Where my parents lived, they only had EDGE for a really long time, until LTE was deployed.)

CyberRabbi 6y ago

It saves google a very large amount of money if every chrome browser opens http3 connections to google.com on startup instead of the layered stack. You don’t see much of an effort to deprecate the layered stack and in my opinion that’s because standardizing http3 is enough to lower their costs, what other server hosts do is irrelevant to their bottom line.

chrismorgan 6y ago

You’re getting the narrative quite wrong here and assuming a great deal of bad faith that simply doesn’t exist. People often seem to think Google presented SPDY and QUIC to IETF as faits accomplis, and they were just adopted as HTTP/2 and HTTP/3 because Google said so. This is not how the standardisation processes work. Rather: (1) many involved parties recognised that something like this would be of value; (2) Google developed something, because they happened to be one of the parties that cared the most about it; (3) Google gave it to IETF; (4) all the relevant stakeholders joined in on improving it until there was consensus and practical experience that it really was worth it; and (5) it was finalised and published. What ends up being standardised normally has some quite major differences from what was initially proposed. IETF QUIC is definitely quite different from gQUIC, as HTTP/2 is from SPDY. Standardisation within IETF brings diverse parties together to improve things based upon their experience and expertise. Certainly there will be dissenters, because there are trade-offs everywhere (e.g. the Varnish author was lukewarm about HTTP/2, reckoning it wasn’t worth it and that more radical changes should be made to HTTP semantics), but the end result will be better than what was initially presented, and there must be broad consensus that what is to be published is better than what preceded it (in this case HTTP/1.1). At Fastmail I observed a fair bit of the process of the standardisation of JMAP at IETF, and it benefited enormously from the process, changing shape quite significantly in some areas from what Fastmail initially presented. The end result of HTTP/2 is definitely harder to implement than HTTP/1 (though it’s still not too bad—I implemented it in the draft days and didn’t have any real trouble, there was mostly just more to implement than with HTTP/1), but of its operational parameters, it’s better in every way than HTTP/1. Turns out that a protocol being plain-text really just isn’t useful, so long as the semantics are conveyed—literally the only people that need to care about the wire protocol are the people making tools that speak it (that is, HTTP libraries). There’s really just one issue with HTTP/2: it makes it possible to use a single TCP connection where HTTP/1 probably used up to six, but this leads to TCP head-of-line blocking issues becoming more serious. And make no mistake, TCP head-of-line blocking is a real issue on high-loss networks like the outskirts of wi-fi and cellular networks. HTTP/2’s multiplexing solved real problems, and HTTP/3’s HOLB-fixing solves the last real problem with HTTP/2. Google didn’t browbeat people into doing their will; rather, they presented a draft, and then everyone worked together to improve upon that draft, and they all (or at the least, almost all) agreed that the end result was a good improvement. > a deliberate effort to deprive the web of its own nature by making it so complicated that only Google is capable to implement it. … are you aware of how many HTTP/3 implementations there are already? In Rust alone, there are at least three fairly mature implementations: Quinn by various people, Quiche by Cloudflare, Neqo by Mozilla; as well as a handful more not-so-mature implementations. Look, I’m not fond of Google, and I do think they abuse their position in many and various places, but this is not one of them.

tannhaeuser 6y ago
The question is if on balance, http/2 and up really is worth the complexity when http/1.1 has served us well enough, with peak web traffic already behind us. Considering that we were able to somehow run the web (and messaging and mail and apps) 20-30 years ago with much, much less capable computers. It's almost as if computers have become way too powerful, so we had to invent atrocious web apps to offset any performance advances. Similarly, F/OSS was too ubiquitous so we had to invent "the cloud". I can't help to see anything other than a self-serving power end game in this, with a few monopolies grabbing everything left, and a legion of developers having a vested interest to keep the hamster wheel spinning. Regarding the implementations of http/2 and up you speak of, I know only a single F/OSS one (ng-http2) actually used in server-side production.
- tick_tock_tick 6y ago
  3 has real value 2 is a waste of time. I will state with great confidence you won't see 2 in the wild in the next 5 years.
  - chrismorgan 6y ago
    I dunno, the topic may be a bit more nuanced than that because the HTTP/2 upgrade is free (via ALPN, part of the TLS handshake) while there’s not yet any good way of starting on HTTP/3. See https://news.ycombinator.com/item?id=24855848 https://news.ycombinator.com/item?id=24855848 that I wrote 42 days ago on this very topic, with arguments in both directions.
- jlokier 6y ago
  > Regarding the implementations of http/2 and up you speak of, I know only a single F/OSS one (ng-http2) actually used in server-side production. I've been using NginX HTTP/2 for years, and that's F/OSS. It doesn't use ng-http2. Pretty sure this is widely used by others, including by Cloudflare who sponsored it.
  - tannhaeuser 6y ago

will4274 6y ago

Not sure I agree here. The binary protocol aspect of HTTP/2 is already a massive benefit, especially when combined with the ability to omit redundant headers. Consider e.g. just a basic API with Bearer tokens - those tokens are sent once instead of on each request. Cloudflare saw a 53% reduction in ingress volume size (https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/ https://blog.cloudflare.com/hpack-the-silent-killer-feature-...). These changes restore something that had been lost - efficient use of the available bandwidth - GET requests fit in one packet. W.r.t. head of line blocking, all you have to do is find a website that shows a hundred pictures or loads a hundred scripts and you can see the benefit. It's true that the benefit is minor if you're already webpacking and spriting everything, but restoring performance to naive implementations that just use the img tags is not a minor benefit. See this website for example: https://imagekit.io/demo/http2-vs-http1 https://imagekit.io/demo/http2-vs-http1. HTTP/3 adds a lot more complexity than HTTP/2 added, for a smaller benefit, but.. that's how these things go. Our processors reorder instructions too. Even if it's only single digit percent, optimization are worth it. A few percent in the processor, a few percent in the OS, a few percent from the network, a few percent from the JIT - these things add up.

tannhaeuser 6y ago
> W.r.t. head of line blocking, all you have to do is find a website that [...] loads a hundred scripts and you can see the benefit Ok then, I guess this answers the question regarding the other purported benefit of http/2+.
- will4274 6y ago
  Have you ever used Facebook and clicked on "my friends"? Have you user browsed a page of forum posts where each user has their own picture? Have you ever looked at a slideshow on the internet? Have you ever gone on reddit or another aggregator site that shows thumbnails? These are hardly obscure use cases.
  - tannhaeuser 6y ago
    These things exist since way before 2000, and are working just fine without http/2+. I can think of another use case, though: sending lots of ads and videos from a single domain of a well-known ad company.

jeroenhd 6y ago

> the other advertised benefit of http/2 and beyond (avoid head of line blocking) turns out to be marginal at best When I'm on a slow connection (EDGE, for example) I can clearly notice a difference with HTTP/2. The extra round trip times and potential connection resets they might encounter do have an impact that can sometimes be measured in whole seconds of loading. The same might also be true for those forced to use satellite connections for internet access, where latencies of half a second are common even with good reception and clear weather. Burst speeds are fine, as long as the data comes in over existing connections, for which HTTP/2 provides are real benefit. Most websites still push half a megabyte of JS down your throat on slow connections, so there's not as much of an improvement as advertised, but that's not the protocol's problem. Of course there are no improvements on cable internet or faster, but there are plenty of people for whom protocols like HTTP/2 make a difference. As for Kubernetes, it's a decent tool that solves a real problem. Automated replication and load balancing isn't trivial and for companies that need it, k8s, even on bare metal, can save huge amounts of development effort. It wasn't the first product in its class, it just became the most popular. There are plenty of alternatives available online if you just look for them. That said, most "cool" companies that use kubernetes because it's the "standard" or whatever should really pick something else because you waste loads of resources for nothing if your problem doesn't need a solution as complex as K8s.

tannhaeuser 6y ago
EDGE won't cut it for any modern bloated site, http/2+ or not. Will timeout long before the page is loaded.
- majewsky 6y ago
  EDGE can get you up to 1 Mib/s. Even if we just take 400 Kib/s as a sustained estimate, that's about 3 MiB/min. It's not a fun experience, but most of the times, it's enough to eventually load the site you want. (Source: Where my parents lived, they only had EDGE for a really long time, until LTE was deployed.)