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.
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?
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?
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.
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?
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.
This is why browser marketshare matters. One player holding such a dominant position gives them according control over how web standards evolve.
- https://daniel.haxx.se/blog/2018/11/11/http-3/ - https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...
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.
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.
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.
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.
It's also pretty unreasonable to point at www.google.com and say that it makes too many requests and it could be trivially fixed to use fewer. But, let's assume that the problem you identify actually is the case: Google is a huge, cash rich organization - if they can't figure out how to enact the change you suggest, how could any other organization? And if HTTP/2 and QUIC (HTTP3) solve this problem for Google, and since they are making it an open standard, also for other organizations, why is that a bad thing?
Press Ctrl+U on any Google page.
> 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.
No, but it's evidence you claim doesn't exist.
It takes large team to produce a pages so bad as the Google landing page, blogger etc. For me, just about anything Google I looked at is to a well crafted website what elevator music played with a 1000 man orchestra is to someone with a guitar singing a really good song. The scale and the available resources makes the result worse to me, not better.
I’d hate to bring it up but here goes: SPDY was designed specifically to load the Google homepage quickly on typical American DSL MTU configuration, even with all that JavaScript tracking enabled.
Turned on it’s head: SPDY was designed to make google’s wide tracking of end-users impact page-load times as little impact as possible, to avoid it being a cause of end-user dissatisfaction.
SPDY was extremely tailored to a very niche need which first and foremost serves Google.
I see you don't cite any evidence that SPDY was miopically designed for American DSL connections, but regardless of that, HTTP3 is going to benefit a wife range of connection types.
How vile of them to force a purely optional protocol on us.
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.
Right?
"Just open more connections" has issues. QUIC making it less necessary to do that has value even if it didn't save memory or CPU usage.
Also, big(ish) routers are aware of TCP and can adapt as the load changes. They literally won't know what to do with a huge increase in UDP traffic.
I'd make an educated guess that mass deployment of QUIC will prove to be pretty awful until it's hacked to look more or less exactly like TCP with multiple connections, just with more overhead.
Randomly drop UDP packets.
I feel like you're conflating two very different things into "head of line blockings".
Head of line blocking in HTTP/1.1 was that HTTP/1.1 cannot transmit responses out of order, so a slow response "blocks" any responses behind it. HTTP/2 solves this by being multiplexed (effectively, it tags the requests & responses s.t. you can match out of order responses back to the appropriate request). This isn't necessarily that the network can't handle it; a request that might be easy for the server to handle (e.g., a static asset) can get caught behind one that is not (e.g., one that entails a slow DB query).
The other "head of line blocking" that I think you're getting at is just network loss or saturation. If the network can't deliver packets, I don't see how having 6 connections is going to help: you're going to have to wait for six different state machines to determine that the link is saturated, back off, etc.
Regardless, my understanding is that QUIC / HTTP/3 is still a multiplexed protocol; I would think it would behave very similarly. Nonetheless, Google's announcement of it backs up your claim[1]:
> Like HTTP/2, QUIC multiplexes multiple streams into one connection, so that a connection can serve several HTTP requests simultaneously. But HTTP/2 uses TCP as its transport, so all of its streams can be blocked when a single TCP packet is lost—a problem called head-of-line blocking. QUIC is different: Loss of a UDP packet within a QUIC connection only affects the streams contained within that packet. In other words, QUIC won’t let a problem with one request slow the others down, even on an unreliable connection.
But what here makes QUIC think that those other requests have any hope where the first didn't? To me, this approach seems like you're just spamming the link with packets and hoping for the best; those packets could just end up dropped like the other ones were. What makes QUIC think this approach will have any benefit? (It could, perhaps, if the link is just going to drop one packet and we can get right back to sending. I'm not sure that still conveys any benefit over TCP. Not saying QUIC is wrong, just that I don't see a decent reason to buy into it.)
(This whole thing makes me think there are two problems here: there's the actual network connection between two endpoints, and what its state is, how lossy it is, its PMTU, how much data we should allow in-flight between those two endpoints, etc. But then there is also logical streams, such as HTTP request/response pairs. It almost seems like to me any data about the link, such as PMTU/lossiness/window, should be shared between all TCP connections, and the individual logical streams should be otherwise cheap/easy to make.)
[1]: https://cloudplatform.googleblog.com/2018/06/Introducing-QUI...
There are a lot of ways to lose just a single packet. One way is a router is overloaded and so it throws some packets away. Another is some brief interference on a wireless connection.
I think the phrase "spamming the link" is incorrect. QUIC does flow control to determine how much data to send. Once it's decided that the link can take a certain amount of data, it will send it. So, say it sends packets 1, 2 and 3. But, let's say that packet one is lost but 2 and 3 get through. With QUIC, the receiver can potentially do something with packets 2 and 3 with TCP, the receiver couldn't. Regardless, QUIC will respond to the packet loss by updating its flow control information - I haven't read anything that suggestions that QUIC responds by "spamming the link".
> This whole thing makes me think there are two problems here: there's the actual network connection between two endpoints, and what its state is, how lossy it is, its PMTU, how much data we should allow in-flight between those two endpoints, etc. But then there is also logical streams, such as HTTP request/response pairs. It almost seems like to me any data about the link, such as PMTU/lossiness/window, should be shared between all TCP connections, and the individual logical streams should be otherwise cheap/easy to make.
You've basically described what QUIC is in this paragraph
You would need kernel support here, though, would you not? (And you would need a generic protocol. I have admittedly not studied QUIC thoroughly yet, but my impression was that it was strictly HTTP / not generic.) Without kernel support and/or being generic, I don't see how it's really different from HTTP/2 w/ a single TCP connection.
This document is about doing HTTP on QUIC, so it's renaming itself HTTP/3, the main QUIC document is as you've described it 'generic'
I wasn't as clear as I wanted to be. Yes HTTP/1.1 has head-of-line blocking on a single HTTP Connection (read TCP connection). Attempts to solve HTTP's head-of-line blocking like HTTP Pipelining didn't receive widespread adoption for many reasons, primarily middle ware boxes screwing things up.
H2 achieves logical parallelism by multiplexing requests/responses over a single connection. H1 solved it by allowing 2 (then 4, then 6-8) parallel TCP connections to a single origin.
While you might think that having 6 parallel TCP connections makes you 6x more like to encounter network loss, saturation, and dropped packets, that doesn't seem to be the case.
The best paper to date on this is "HTTP/2 Performance over Cellular Networks" [1]. In rigorous testing, they found that in slower/congested networks, H2 is actually worse than H1, sometimes by a lot. If 1 TCP connection in H1 stalls, no big deal, you have 5 others to that host. If 1 TCP connection in H2 stalls, you are stalled.
[1] https://www.akamai.com/kr/ko/multimedia/documents/technical-...