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

121–130 of 149 posts

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

#121

Post by samoa42 »

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?

was going to say "of course, why would the router care for layer4 proto" but then again, netgear is like a synonym for "unpredictable crappy middlebox".

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

#122

Post by samoa42 »

gear54rus wrote: post #110
mrlala wrote: post #78

Earlier quoted context omitted.

But being an SPA I'm sure it's a billion times more manageable for them to maintain instead of a javascript hack nightmare. So, yeah of course you can always make something lightning fast.. but can you manage it, or even develop it properly in the first place?

SPA is not synonymous with slowness, this meme needs to die already.

not sure where you think this meme (never heard of it) was brought up itt.

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

#123

Post by chrismorgan »

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 the fact that the browser is now using only one connection.

HTTP/3 is a binary protocol over QUIC which is over UDP. Requests are multiplexed. If it works, it should be fairly uniformly better than both HTTP/1 and HTTP/2, because you can think of it as roughly HTTP/2 minus the bad parts of TCP. However, on a few networks (business networks typically, I think) it won’t work because they have firewalls that hate unknown UDP traffic.

(HTTP/3 is not actually just HTTP/2 over QUIC; HTTP/2’s header compression scheme HPACK is stateful in a way that depends on TCP’s sequential nature so that it couldn’t work over QUIC without completely reintroducing the head-of-line blocking problem, so it’s replaced with a variant that mitigates that problem substantially, called QPACK. But other than that, I think they’re roughly the same. Don’t quote me on that, though, it’s a few years since I read the specs and I’ve forgotten it all, not to mention that the specs have changed plenty in that time.)

I think this is a fair summary, but I don’t have any practical experience with HTTP/3, so I welcome any corrections.

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

#124

Post by Cthulhu_ »

DarkCrusader2 wrote: post #111
harrygeez wrote: post #45

I feel like I belong in the minority who like the new Facebook SPA. It loads shockingly fast on my computer, almost instantaneous even

I feel the same with Twitter re-design too. Everyone was hating the re-design when it was launched but my twitter use increased from once or twice a week to couple of times a day after the new design. It is amazingly fast(on desktop at least), behaves in all the right ways you would expect, you never lose you position anywhere, using back button always works properly, gracefully handles connection loss, and again, it…

People dislike change, but I don't believe big companies change their design on a whim; they do a ton of research, and while some may complain, they know it'll be an improvement over their existing designs.

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

#125

Post by chrismorgan »

kelnos wrote: post #42
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.

I expect HTTP/2 and HTTP/1.1 will still be with us for decades; orgs that block UDP will be able to continue to do so, and the rare HTTP/3-only website will just be inaccessible. Even if there's a new killer app that requires QUIC, I imagine an org backward enough to disallow UDP will just not care about that app.

I expect HTTP/2 to disappear completely, to the point of browsers removing support for it probably even within a decade. Everything that works over HTTP/2 should work over HTTP/1.1, even if at a slight cost, and HTTP/3 should be uniformly superior to HTTP/2, except in those rare cases of UDP-blocking firewalls, which situation I expect to improve over time. Given the complexity and maintenance burden of the protocol and more importantly the upgrade mechanism, I think browsers will be happy to remove HTTP/2 in favour of the old reliable HTTP/1.1 (which is certainly not going anywhere) and HTTP/3 once they see very little using it any more, and absolutely nothing needing to use it.

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

#126

Post by hinkley »

MichaelMoser123 wrote: post #101

I guess NAS (network access storage) would really benefit from QUIC; one could treat each file transfer as a separate session, so that a lost packet will not cause all the sessions to stall. Did any of the NAS protocols adopt QUIC already? Are they working on it?

rsync, please and thank you.

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

#127

Post by swyx »

nwienert wrote: post #67
harrygeez wrote: post #62

Earlier quoted context omitted.

I've personally experienced this many times using Safari. Pages that take up a lot of memory just straight up freeze and start chugging.

I have a feeling this may be React related. Safari is on average far, far faster on any site. But I have a larger React site that slows down quite a bit more than Chrome. Perhaps related to the const+let vs var bug the other day.

unlikely - any production build of React would transpile down to var for IE support

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

#128

Post by swyx »

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…

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?

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

#129

Post by chrismorgan »

swyx wrote: post #128
chrismorgan wrote: post #123

Earlier quoted context omitted.

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…

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-Svc header on an HTTP response, but that means that the browser won’t use HTTP/3 for the first request. I think that might be what browsers are doing now (rather than racing TCP and UDP). But I think the direction things are heading is to optionally advertise this stuff over DNS as well, which would allow browsers to go straight to HTTP/3 if the relevant DNS records say it’s OK to: https://blog.cloudflare.com/speeding-up-https-and-http-3-neg....

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

#130

Post by swyx »

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-…

you have a gift for explaining these things. thank you!
Post reply on HN