4 ms·

Google ruined the simplicity and orthogonality of the internet while we all were there looking. There is nothing of the original design grandiosity of the first

by l4hel 6y ago

Google ruined the simplicity and orthogonality of the internet while we all were there looking. There is nothing of the original design grandiosity of the first batch of internet protocols here. It's just engineering work of sacrificing every elegance and modularity to seek some percentage (not order of magnitude) performance gain.

vbezhenar 6y ago
You're free to use HTTP/1.1. I think that it'll be supported forever both on clients and servers.
benkuhn 6y ago
Simplicity, orthogonality, elegance, modularity, etc. are useful when you want to build lots of different things easily. When you're building one single thing that's used by 4.6 billion people, it turns out that percentage optimizations matter! (I work for a company that built a shitty half-baked homegrown QUIC equivalent because in rural Ethiopia, HTTPS handshakes were so slow that they literally just didn't work. Glad that Google is optimizing our percent-of-a-percent use case!)
- baybal2 6y ago
  The thing is, what Google does often doesn't work. Unsound hacks that kind of work "acceptable" in A/B test telemetry and slowly break in real life from inherent design deficiency, are almost always worse than something saying from the start "will not work on bugged os/hardware version, but work really well on standard compliant ones" The TLS 1.3 hack a Google engineer has forced through IETF is now backfiring for example. They did it to hack around a certain brand of middleboxes, but the hack instead broke few other ones, and embedded http servers. They may well errata it, and go back to normal versioning in 1.4, despite putting it on paper in 1.3 that the hack is here permanently.
  - tialaramex 6y ago
    > The TLS 1.3 hack a Google engineer has forced through IETF is now backfiring for example. How is it "backfiring"? It seems to be working for billions of people. If you've got a non-compliant TLS implementation that broke you get to keep both halves, good luck with that.
  - algesten 6y ago
    I hadn't heard the tls 1.3 version hack being a problem. You have a link where I can read about it?
ekimekim 6y ago
> There is nothing of the original design grandiosity of the first batch of internet protocols here. I'd be interested to know how you feel TCP and QUIC differ in this regard. It seems to me that they're both reasonably similar protocols that design for slightly different things and make different tradeoffs (reliable single-stream transfer vs reliable multi-stream transfer, ip and port-based endpoints vs abstract connection ids, etc). I guess you could see the integration of encryption to be an ugly layering violation, but IIUC the primary driver for that decision is less performance and more to prevent ossification by ensuring as much protocol information as possible is inaccessible to middleware. I'm less enthused about HTTP/3 - I would've liked to see a simpler, "QUIC-ified" version of HTTP/1.1 done first (ie. basically just normal HTTP except with one request per stream), but I guess it's a hard sell to roll back from HTTP/2's efficiencies, and HTTP/2 itself is unsuitable for QUIC since it duplicates much of its functionality. I also want to see QUIC used for more protocols, especially those that (like HTTP/2) already had some level of stream multiplexing built in (AMQP comes to mind here).
ReactiveJelly 6y ago
It's not like Google is coming into my desktops and servers and blocking my incoming and outgoing TCP connections.

by l4hel 6y ago

vbezhenar 6y ago

You're free to use HTTP/1.1. I think that it'll be supported forever both on clients and servers.

benkuhn 6y ago

Simplicity, orthogonality, elegance, modularity, etc. are useful when you want to build lots of different things easily. When you're building one single thing that's used by 4.6 billion people, it turns out that percentage optimizations matter! (I work for a company that built a shitty half-baked homegrown QUIC equivalent because in rural Ethiopia, HTTPS handshakes were so slow that they literally just didn't work. Glad that Google is optimizing our percent-of-a-percent use case!)

baybal2 6y ago
The thing is, what Google does often doesn't work. Unsound hacks that kind of work "acceptable" in A/B test telemetry and slowly break in real life from inherent design deficiency, are almost always worse than something saying from the start "will not work on bugged os/hardware version, but work really well on standard compliant ones" The TLS 1.3 hack a Google engineer has forced through IETF is now backfiring for example. They did it to hack around a certain brand of middleboxes, but the hack instead broke few other ones, and embedded http servers. They may well errata it, and go back to normal versioning in 1.4, despite putting it on paper in 1.3 that the hack is here permanently.
- tialaramex 6y ago
  > The TLS 1.3 hack a Google engineer has forced through IETF is now backfiring for example. How is it "backfiring"? It seems to be working for billions of people. If you've got a non-compliant TLS implementation that broke you get to keep both halves, good luck with that.
- algesten 6y ago
  I hadn't heard the tls 1.3 version hack being a problem. You have a link where I can read about it?

ekimekim 6y ago

> There is nothing of the original design grandiosity of the first batch of internet protocols here. I'd be interested to know how you feel TCP and QUIC differ in this regard. It seems to me that they're both reasonably similar protocols that design for slightly different things and make different tradeoffs (reliable single-stream transfer vs reliable multi-stream transfer, ip and port-based endpoints vs abstract connection ids, etc). I guess you could see the integration of encryption to be an ugly layering violation, but IIUC the primary driver for that decision is less performance and more to prevent ossification by ensuring as much protocol information as possible is inaccessible to middleware. I'm less enthused about HTTP/3 - I would've liked to see a simpler, "QUIC-ified" version of HTTP/1.1 done first (ie. basically just normal HTTP except with one request per stream), but I guess it's a hard sell to roll back from HTTP/2's efficiencies, and HTTP/2 itself is unsuitable for QUIC since it duplicates much of its functionality. I also want to see QUIC used for more protocols, especially those that (like HTTP/2) already had some level of stream multiplexing built in (AMQP comes to mind here).

ReactiveJelly 6y ago

It's not like Google is coming into my desktops and servers and blocking my incoming and outgoing TCP connections.