5 ms·

So HTTP/1.1 worked fine for around 2+ decades. Google(tm) HTTP/2.0 was unasked for, tried to reinvent TCP, found buggy and fundamentally broken after less than

So HTTP/1.1 worked fine for around 2+ decades. Google(tm) HTTP/2.0 was unasked for, tried to reinvent TCP, found buggy and fundamentally broken after less than a year. So now Google is pushing HTTP/3 to solve the bugs they made with HTTP/2, by reinventing even more of the IP-stack. What could possibly go wrong? Can someone please tell Google that protocols are not Chrome-releases? They need to work and stay working and supported for decades. You can’t ship a new revision every 6 month. Edit: Correct HTTP/1.1 longdetivity.

manigandham 8y ago
3 decades? 1.1 was released in 1997. Networks change as the world evolves and supports more people and applications, so new protocols are expected. HTTP/2 was great progress at the application layer, and QUIC is now about improving the transport layer. Can you clearly list the bugs you claim HTTP/2 has?
- josteink 8y ago
  > 3 decades? 1.1 was released in 1997. Fair enough. Corrected. > Can you clearly list the bugs you claim HTTP/2 has? They seemed fairly well outlined in the post I was replying to, no?
  - profmonocle 8y ago
    The only issue raised in the post you replied to was that TCP head-of-line blocking can be a bigger issue in HTTP/2. Claiming this makes the protocol "fundamentally broken" is a bit of a stretch. Plus, this wasn't "found after less than a year". It was a known drawback from the very beginning, when the protocol was still SPDY, and deemed an acceptable tradeoff.
  - manigandham 8y ago
    That is not a bug with HTTP/2. It is designed to be more efficient by using a single TCP connection, thereby magnifying any efficiency issues that TCP had all along. These issues are not only about HTTP but include the massively increased amount of devices, network types, security features, and general throughput over the years. Perhaps a new version of TCP could've been made, and that's a valid concern, but it's a slow moving standard that takes decades to alter. QUIC evolved faster on UDP so that's what we have. What strategy do you suggest for improving TCP faster than the current process?
    - dagenix 8y ago
      I agree with what you have to say, but just want to respond to last second paragraph: QUIC basically is a new version of TCP. Yeah, it's based on UDP, but, that is just an implementation detail. If it weren't for various poorly behaved middleboxes, QUIC could just sit on top of IP like TCP does. But, it can't - so we hold our noses and put it on top of UDP and we end up with something that actually works.
mintplant 8y ago
> Can someone please tell Google that protocols are not Chrome-releases? This is why browser marketshare matters. One player holding such a dominant position gives them according control over how web standards evolve.
- forgot-my-pw 8y ago
  It's been endorsed by mozilla devs & others too? - https://daniel.haxx.se/blog/2018/11/11/http-3/ https://daniel.haxx.se/blog/2018/11/11/http-3/ - https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...
necubi 8y ago
That's really not what happened. Spdy (HTTP/2) and quic were in development simultaneously at Google before the standardization process began in 2012. HTTP/2 solves a bunch of performance challenges around running web applications over HTTP (a protocol designed for simple, static documents). Part of this was adding pipelining and multiplexing to solve the HTTP/1.1 problem of head-of-line blocking. (A problem which previously people solved by opening a bunch of connections and even using different subdomains so they could bypass browser limits). And to be clear, you can still do that in HTTP/2, it's just less necessary. However there's only so much you can at the application level. Some problems need to be fixed at the transport level, and there's where QUIC comes in. It's not fixing problems in HTTP/2 (at least not compared to HTTP/1), it's making things even better for high performance web applications.
- ubernostrum 8y ago
  A problem which previously people solved by opening a bunch of connections and even using different subdomains so they could bypass browser limits I suppose that's one way of putting it. Currently, the home page at www.google.com wants to do twenty-five requests in order to show me an interface consisting of a text input and two buttons. Google decided to fundamentally redesign HTTP to accommodate their own inability to impose any kind of discipline on their programmers. I don't see this as a good thing.
  - dagenix 8y ago
    > Google decided to fundamentally redesign HTTP to accommodate their own inability to impose any kind of discipline on their programmers 1) That is a ridiculous statement with absolutely no evidence to back it up. 2) The number of requests that Googles homepage does in order to load has _nothing at all_ to do with whether or not solving head of line blocking problems for the rest of the web is a good thing.
    - ubernostrum 8y ago
      The number of requests that Googles homepage does in order to load has _nothing at all_ to do with It has a lot to do with the desire to work around limits on the number of in-flight connections allowed to a single host, which is one of the primary things HTTP/2 is designed for.
nitwit005 8y ago
> Google(tm) HTTP/2.0 was unasked for, tried to reinvent TCP, found buggy and fundamentally broken after less than a year. How vile of them to force a purely optional protocol on us.
- ilammy 8y ago
  > purely optional And then one day Google declares HTTP/1.1 deprecated, lowers the score of sites without HTTP/3, and removes support for HTTP/1.1 from Chrome in a week. You're personally free to not use it, but I'm not sure that everybody else will while you'll be the one responsible for supporting it on your website.
  - nitwit005 8y ago
    They might lower your search ranking, but dropping support won't happen as it would force people to ditch the browser. New things that don't support http2 are still being made.

manigandham 8y ago

3 decades? 1.1 was released in 1997. Networks change as the world evolves and supports more people and applications, so new protocols are expected. HTTP/2 was great progress at the application layer, and QUIC is now about improving the transport layer. Can you clearly list the bugs you claim HTTP/2 has?

josteink 8y ago
> 3 decades? 1.1 was released in 1997. Fair enough. Corrected. > Can you clearly list the bugs you claim HTTP/2 has? They seemed fairly well outlined in the post I was replying to, no?
- profmonocle 8y ago
  The only issue raised in the post you replied to was that TCP head-of-line blocking can be a bigger issue in HTTP/2. Claiming this makes the protocol "fundamentally broken" is a bit of a stretch. Plus, this wasn't "found after less than a year". It was a known drawback from the very beginning, when the protocol was still SPDY, and deemed an acceptable tradeoff.
- manigandham 8y ago
  That is not a bug with HTTP/2. It is designed to be more efficient by using a single TCP connection, thereby magnifying any efficiency issues that TCP had all along. These issues are not only about HTTP but include the massively increased amount of devices, network types, security features, and general throughput over the years. Perhaps a new version of TCP could've been made, and that's a valid concern, but it's a slow moving standard that takes decades to alter. QUIC evolved faster on UDP so that's what we have. What strategy do you suggest for improving TCP faster than the current process?
  - dagenix 8y ago
    I agree with what you have to say, but just want to respond to last second paragraph: QUIC basically is a new version of TCP. Yeah, it's based on UDP, but, that is just an implementation detail. If it weren't for various poorly behaved middleboxes, QUIC could just sit on top of IP like TCP does. But, it can't - so we hold our noses and put it on top of UDP and we end up with something that actually works.

mintplant 8y ago

> Can someone please tell Google that protocols are not Chrome-releases? This is why browser marketshare matters. One player holding such a dominant position gives them according control over how web standards evolve.

forgot-my-pw 8y ago
It's been endorsed by mozilla devs & others too? - https://daniel.haxx.se/blog/2018/11/11/http-3/ https://daniel.haxx.se/blog/2018/11/11/http-3/ - https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...

necubi 8y ago

That's really not what happened. Spdy (HTTP/2) and quic were in development simultaneously at Google before the standardization process began in 2012. HTTP/2 solves a bunch of performance challenges around running web applications over HTTP (a protocol designed for simple, static documents). Part of this was adding pipelining and multiplexing to solve the HTTP/1.1 problem of head-of-line blocking. (A problem which previously people solved by opening a bunch of connections and even using different subdomains so they could bypass browser limits). And to be clear, you can still do that in HTTP/2, it's just less necessary. However there's only so much you can at the application level. Some problems need to be fixed at the transport level, and there's where QUIC comes in. It's not fixing problems in HTTP/2 (at least not compared to HTTP/1), it's making things even better for high performance web applications.

ubernostrum 8y ago
A problem which previously people solved by opening a bunch of connections and even using different subdomains so they could bypass browser limits I suppose that's one way of putting it. Currently, the home page at www.google.com wants to do twenty-five requests in order to show me an interface consisting of a text input and two buttons. Google decided to fundamentally redesign HTTP to accommodate their own inability to impose any kind of discipline on their programmers. I don't see this as a good thing.
- dagenix 8y ago
  > Google decided to fundamentally redesign HTTP to accommodate their own inability to impose any kind of discipline on their programmers 1) That is a ridiculous statement with absolutely no evidence to back it up. 2) The number of requests that Googles homepage does in order to load has _nothing at all_ to do with whether or not solving head of line blocking problems for the rest of the web is a good thing.
  - ubernostrum 8y ago
    The number of requests that Googles homepage does in order to load has _nothing at all_ to do with It has a lot to do with the desire to work around limits on the number of in-flight connections allowed to a single host, which is one of the primary things HTTP/2 is designed for.

nitwit005 8y ago

> Google(tm) HTTP/2.0 was unasked for, tried to reinvent TCP, found buggy and fundamentally broken after less than a year. How vile of them to force a purely optional protocol on us.

ilammy 8y ago
> purely optional And then one day Google declares HTTP/1.1 deprecated, lowers the score of sites without HTTP/3, and removes support for HTTP/1.1 from Chrome in a week. You're personally free to not use it, but I'm not sure that everybody else will while you'll be the one responsible for supporting it on your website.
- nitwit005 8y ago
  They might lower your search ranking, but dropping support won't happen as it would force people to ditch the browser. New things that don't support http2 are still being made.