So, what's the point of ditching all that and reinventing HTTP over a thin wrapper (UDP) over (lossy) IP? Has there been a huge theoretical breakthrough which simply can't be applied to TCP?
In general, it is true that TCP is highly optimised, but it is only optimised for one use case: a long lived single flow over a low error rate connection to a single destination. That was the predominate type of connection back in the FTP and early web days. But is hasn't been that way for a while now. HTTP is short lived, video goes to multi destinations, HTTP/2 and multi media in general has multiple flows. Wireless only appears to be low error rate because the physical layer had to cover up it's shortcomings otherwise TCP's performance became abysmal.
TCP hasn't remained king of the mountain because its fantastic protocol that can't be improved. On the contrary - looks to be the simplest thing it's inventors could come up with. It even lacked round trip time measurement - which is something I suspect that would have killed it if an extension hadn't saved it. TCP has remained king of the mountain purely because it appears to be near impossible to replace. Now that Google has done it, I expect we will see a lot more experimentation in this area.
If you want to put security on/into IP, you suddenly need the whole key management thing, and if you want it to be automatic, you need to somehow cobble together the assignment, provisioning, allocation, publication, revocation of keys with IP addresses (or hostnames, domain names, and you just put DNS into IP).
Eventually it means either you need manual key management (thus IPsec becames a hard to manage old rusty and poorly supported concept from an old era) or you just descended into the recursive pit of all hells of circular dependencies. Sure, it can be done, we can put keys into DNS, and we can use that, but then we're back to QUIC or DTLS basically.
The thing is, how you set up (mutual) authentication is very much an application level thing. Do you want certs, an SSH key, passwords, hardware tokens, SIM based authentication, or something else? These aren't things the OS can decide, and they aren't so simple we could tell the OS what we want with a few flags.
It then seems that optimized protocols like QUIC could benefit from disabling this lower level error correction.
Is this at all possible? Do the wireless physical protocols allow for such a thing? Do the operating systems offer it as a flag?
I did a quick read on the subject and main argument for QUIC seems to be zero roundtrip session establishment - using TLS session resumption. SCTP uses a 4-way handshake.
Also found this comment from 2015: https://news.ycombinator.com/item?id=9639824, and this ietf draft: https://tools.ietf.org/html/draft-joseph-quic-comparison-qui...
Since HTTP is the use case here, it is possible to create a protocol that is optimized for it, whereas TCP cannot be optimized specifically for HTTP.
Source: I've implemented a reliable, stream oriented protocol over UDP which has been in use for many years.
ref: https://docs.microsoft.com/en-us/windows/desktop/WinSock/tcp... https://linux.die.net/man/7/raw
You can try and diddle with chunk size and message prioritization in your application to reduce HOL blocking of low latency messages behind chunks of high throughput data, but your OS will buffer everything in one big queue anyway (because TCP is a single stream and flow control applies to that entire stream as a whole).
How do you fix that? Well you can reduce socket buffer sizes on your TCP connection, and that will fix latency... but small buffer sizes mean your total throughput is limited by round trip time (because of the way the TCP receive windows and positive acknowledgment work). If you're working over a LAN, things will be fine, but over the Internet you're hosed.
Of course, the solution really is to have separate long-lived TCP connections for different kinds of flows, so you can set buffer sizes appropriately... but that's impossible for your browser (which is responsible for opening connections). It has no way to know whether a GET request triggered by an <img> tag is going to yield a 100 byte response or a 100MB response.
h2 failed because it's mux everything into 1 single tcp connection, and it only takes 1 failed tcp to block everything in line.
h2 really need to do demux. But h2 actually can technically do M:N connections, but browsers do only 1:N.
Also h2 is a failed promise. Most sites deliver web assets and page and js in different host, also ws/wss in a different host. Thus renders h2 advantages complete useless.
Just curious, what do you mean? Quickly Googling this, it looks like 1/3 websites use HTTP2 today, which is darn good for a relatively new protocol.
Most sites use h2 by just wrapping http/1.0 behind some h2-enabled CDN or upgrade to latest nginx and call it done.
What about h2 push? Priority? WS inside h2? Nope. No one use them obviously.
I mean gRPC utilized more h2 features than most h2 browsers/CDN do.
I am less worried about what most sites do and more interested in the features offered by implementations. A huge number of sites don't even use https.
Again, the goal of h2 is not to maximize usage of features in the h2 protocol. So judging h2 by that metric does not make any sense. I could just as easily complain that HTTP is a failure because few sites use more than just GET/POST, or because many of the headers defined in the HTTP standard are not commonly used.
I'm curious to hear what you mean by WS inside h2, not sure how that's different. WS is only http for the first part i.e. the upgrade request.
Sure, there's some other stuff in there, server sent goaway in particular is a great way to indicate the server intentionally closed the connection, but the primary objective is to get around congestion control -- which could have been better solved by just adjusting congestion control to pool by destination IP in clients Google could control (at least Android) and on servers Google could control (at least their servers)
But... which use cases of HTTP need us timers? It's not like gmail or other bloated web apps will load faster on my phone because of QUIC?
Anyway, that's mobile. In the datacenter all of these timers are way too high, by several orders of magnitude. 1ms is an outrageously long RTO in a datacenter fabric but 200ms is the minimum RTO allowed by the TCP RFCs.
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.
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.
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.
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?
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.
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...
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-...
You don't really want to drop data for streaming video either, sure, in some cases it might not make a huge difference, but if you drop i-frames, you are going to have quality issues.
I'm not sure if HTTP/3 will have a way to do selective re-sending, but that is how very versatile lossy video streams do it. I-frames can get re-sent while normal frames can be lost.