Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The majority of Facebook's traffic now uses QUIC and HTTP/3

engineering.fb.com

Post reply on HN
Print view View original

131–140 of 149 posts

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#131

Post by M2Ys4U »

CppCoder wrote: post #117
tialaramex wrote: post #83

Earlier quoted context omitted.

Some years back, Google had two experimental pieces of work to try to speed up HTTP named QUIC and SPDY (as in "Quick" and "Speedy"). The output from the experiments was new standardization efforts at the IETF. Google's SPDY, which was a binary HTTP protocol over TLS, eventually resulted in HTTP/2 which there's a fair chance you use today. The other idea, QUIC, is a much bigger lift. It replaces not just the HTTP pro…

In here and in the article it sound as if QUIC or HTTP3 use or build a new Internet Protocol, while it was my understanding it _simply_ uses UDP to create a better version of TCP. Of course an all new IP would be great, but the issue is it would take very long for all the soft and hardware to support it and UDP is simply there. I would prefer for a new HTTP to go an all new way, leaving behind UDP and TCP and build s…

I don't think it's unreasonable to state that we will never deploy a new IP protocol again.

At least not one that works over the general Internet - controlled intra-organisation networks might possibly be able to do so, but very rarely.

There are too many broken machines on the Internet that assume all IP traffic is one of TCP, UDP and ICMP. And far too many are configured to screw up ICMP too.

So new protocols MUST use TCP or UDP as their base layer instead of raw IP.

So yes, QUIC uses UDP, but that should be considered an implementation detail. A hack for the lack of IP support on the Internet.

HTTP/3 uses QUIC like HTTP/1 and HTTP/2 use TCP + TLS, but QUIC is not limited to use by HTTP/3.

QUIC's development has been, basically, paused while HTTP/3 is finalised and then the IETF will pick up where it left off and work out how other higher-layer protocols will work using QUIC as the transport layer.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#132

Post by tialaramex »

chrismorgan wrote: post #129
swyx wrote: post #128

Earlier quoted context omitted.

this was a remarkably concise summary, nicely done. one clarification/question I had was I think all connections start as http1 by default, then a request to upgrade to http2 is sent. does the same happen for http3? does it go from 1 to 3 or 1 to 2 to 3?

HTTP/2 over cleartext uses an HTTP/1.1 Upgrade header field, yes, so that it’s an extra request. But HTTP/2 over TLS can use application-layer protocol negotiation (ALPN) so that the HTTP/2 negotiation piggybacks on the TLS handshake: the TLS ClientHello includes “I speak h2”, and the ServerHello response includes “OK, let’s do h2”. HTTP/3 negotiation I’m not certain about. Its existence can be broadcast with an Alt-…

HTTP/2 without TLS is basically not a thing.

The HTTP/2 specification tells you how you could in principle do this, but no popular browsers implement it and so far as I know no popular servers do so either.

So in practice it's always ALPN, a modern browser specifies that it would prefer h2 and servers that speak HTTP/2 select that during TLS handshaking. As with SNI this means it is not secret yet (but it could be protected by Encrypted Client Hello)

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#133

Post by jbjohns »

CppCoder wrote: post #117
tialaramex wrote: post #83

Earlier quoted context omitted.

Some years back, Google had two experimental pieces of work to try to speed up HTTP named QUIC and SPDY (as in "Quick" and "Speedy"). The output from the experiments was new standardization efforts at the IETF. Google's SPDY, which was a binary HTTP protocol over TLS, eventually resulted in HTTP/2 which there's a fair chance you use today. The other idea, QUIC, is a much bigger lift. It replaces not just the HTTP pro…

In here and in the article it sound as if QUIC or HTTP3 use or build a new Internet Protocol, while it was my understanding it _simply_ uses UDP to create a better version of TCP. Of course an all new IP would be great, but the issue is it would take very long for all the soft and hardware to support it and UDP is simply there. I would prefer for a new HTTP to go an all new way, leaving behind UDP and TCP and build s…

Well, I think UDP is about as minimal as can be when using IP. So it makes sense to use to design a potential TCP replacement.

Having said that, I wish we could replace the "port" concept. With the size of address space IPV6 allows, 16 bits for ports is looking a bit small.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#134

Post by jbjohns »

toast0 wrote: post #108
tialaramex wrote: post #104

Earlier quoted context omitted.

This is a hefty bet. The gamble is that you're very good at this, and so you'll deliver better performance with HTTP/2 than the client could have got from HTTP/3, but even if you actually are right by a slim margin you're likely to suffer the same pushback from users as if you were wrong. The only scenarios where this is a smart bet are where competitors allow HTTP/3 and have noticeably worse performance. If it's clo…

What users are going to notice? Browsers and almost everything else is going to fallback to TCP and move on, because there are too many broken networks to bother. Kind of like how most big sites clamp TCP MSS at 1440 instead of 1460; there's too many PPPoE or IPIP tunneled links with broken path mtu, and too many clients without working/enabler path mtu blackhole detection to bother making a fuss about it. Just move…

I think people will notice as BYOD gets more and more standard. There is already a situation in my company that everyone who is part of the BYOD initiative doesn't even use their company laptop anymore because everything is so much slower.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#135

Post by chrismorgan »

tialaramex wrote: post #132
chrismorgan wrote: post #129

Earlier quoted context omitted.

HTTP/2 over cleartext uses an HTTP/1.1 Upgrade header field, yes, so that it’s an extra request. But HTTP/2 over TLS can use application-layer protocol negotiation (ALPN) so that the HTTP/2 negotiation piggybacks on the TLS handshake: the TLS ClientHello includes “I speak h2”, and the ServerHello response includes “OK, let’s do h2”. HTTP/3 negotiation I’m not certain about. Its existence can be broadcast with an Alt-…

HTTP/2 without TLS is basically not a thing. The HTTP/2 specification tells you how you could in principle do this, but no popular browsers implement it and so far as I know no popular servers do so either. So in practice it's always ALPN, a modern browser specifies that it would prefer h2 and servers that speak HTTP/2 select that during TLS handshaking. As with SNI this means it is not secret yet (but it could be pr…

You are quite correct.

Browsers did initially implement h2c (HTTP/2 cleartext), but before the dust had really settled, they decided “no, let’s use this opportunity to keep pushing people to adopt TLS” (if you want the performance improvements of HTTP/2, you have to go secure first) and so they ripped it out again. So h2c is much more an academic concept than a real-world thing.

Closely related is the general trend browser makers have agreed on to prefer to make new things only available in secure contexts, with https://w3c.github.io/webappsec-secure-contexts/ explaining and providing various rationale. There’s a genuine security aspect to it, but it’s also definitely about pushing people to do security properly. (“If you want to use this new feature, switch your site to HTTPS first.”)

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#136

Post by jsjohnst »

kortilla wrote: post #113
codetrotter wrote: post #48

Earlier quoted context omitted.

Thanks for clarifying. Guess it's a good thing I never tried to enter the betting industry haha

Yeah, nobody would ever place a bet if the best payout was less than what you put in...

I know you were just making a point, but I want to point out that the “nobody” part is certainly not true, as sad as that is. Generally something like that is considered fraud/deception, but it does happen.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#137

Post by tialaramex »

jbjohns wrote: post #133
CppCoder wrote: post #117

Earlier quoted context omitted.

In here and in the article it sound as if QUIC or HTTP3 use or build a new Internet Protocol, while it was my understanding it _simply_ uses UDP to create a better version of TCP. Of course an all new IP would be great, but the issue is it would take very long for all the soft and hardware to support it and UDP is simply there. I would prefer for a new HTTP to go an all new way, leaving behind UDP and TCP and build s…

Well, I think UDP is about as minimal as can be when using IP. So it makes sense to use to design a potential TCP replacement. Having said that, I wish we could replace the "port" concept. With the size of address space IPV6 allows, 16 bits for ports is looking a bit small.

For a trivial connection-oriented protocol the ports are part of a 4-tuple (my-address, my-port, your-address, your-port) so the 16-bit port isn't a big problem there. It doesn't matter at all whether this port is being used for something else in regards to any other combination of remote address and port since that's not a match.

And for fancier protocols it doesn't matter anyway because they have their own concept of a connection identifier. WireGuard for example doesn't care at all, packets arrive and either they're authenticated or they aren't, it silently discards all packets that aren't authenticated, QUIC optionally has a connection ID that can survive changing the 4-tuple as far as I remember.

If you wish you did have more ports, the IPv6 address space makes it pretty cheap to just acquire more addresses on your network and use those, but I do not sense much appetite because people don't feel like they're short of ports.

You do see people spinning up more addresses to not need SNI or similar. If you have sixty virtual machines on one hardware box, having sixty IPv6 addresses, one per VM, means now the packets for VM #4 and VM #18 are separated on the wire, which might be convenient but that doesn't feel like it's due to running out of ports, it's just more convenient.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#138

Post by jrockway »

mjoras wrote: post #115
jrockway wrote: post #97

Why is the response time chart missing an x axis? What competitive advantage in the social networking space do they gain by not telling me their p99 request time?

Policy reasons is all I can say unfortunately.

That seems normal... but in this particular case, it's kind of weird because anyone can make requests and observe how long they take. So nothing is really being hidden.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#139

Post by Guthur »

chrismorgan wrote: post #123
BatteryMountain wrote: post #116

Can anyone make a tidy article/post that outlines exactly how each protocol differs (v1 vs v2 vs v3) on the network level. Obviously most of us understand the high level differences but what does the mechanisms and payloads look like on lower levels. A side by side comparison would be great. Pro's & con's of each would be great. Would older hardware (say a 10 year old netgear router) be able to use v3 without pain?

HTTP/1 is a plain text protocol over TCP. Requests are sequential per connection. Browsers tend to use up to six connections at a time to work around this. HTTP/2 is a binary protocol over TCP. Requests are multiplexed. It’s normally better than HTTP/1, but in environments with higher packet loss rates (e.g. remote mobile networks) it can perform markedly worse than HTTP/1, because of TCP head-of-line blocking and th…

I'm wondering if we're giving up too much with the move away from clear text to binary, reminds me of systemd.

Considering so much of the internet traffic is not text media was it necessary.

I feel there is a slight possibility of a Google optimisation for a problem they perceive. And then no one questions because brrr faster brrr.

But I'm conscious I might come across as a bit of a Luddite, but it's mostly musing.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#140

Post by api »

nomel wrote: post #43
api wrote: post #31

I am really happy Google and others are pushing QUIC, but for only one main reason: networks that disallow UDP will now be considered "broken." Without something to push UDP usage its possible we could end up with a TCP-only Internet that would make P2P connectivity more or less impossible.

Maybe someday a giant will push UDP broadcast. That would be neat.

That would require a ton of core upgrades and would be hard to implement without enormous abuse potential, so not very likely.
Post reply on HN