> we refer to QUIC and HTTP/3 together as QUIC My understand is that HTTP/3 always means QUIC is used according to the standard. But that QUIC can be used for other protocols as well. FB's terminology seems to be backwards.
[deleted]
The majority of Facebook's traffic now uses QUIC and HTTP/3
81–90 of 149 posts
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#82> we refer to QUIC and HTTP/3 together as QUIC My understand is that HTTP/3 always means QUIC is used according to the standard. But that QUIC can be used for other protocols as well. FB's terminology seems to be backwards.
It's rather frustrating when people do this; for the rest of the article, when saying QUIC do they mean theur terminology that is actually QUIC and HTTP/3 or do they mean QUIC the TCP alternative? They use both.
Why are there two meanings of QUIC in the first place?
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#83Earlier quoted context omitted.
It's rather frustrating when people do this; for the rest of the article, when saying QUIC do they mean theur terminology that is actually QUIC and HTTP/3 or do they mean QUIC the TCP alternative? They use both.
Why are there two meanings of QUIC in the first place?
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 protocol and TLS but the whole stack, even TCP. At the IETF this work was split into two pieces, the IETF's QUIC is just the TCP replacement, an encrypted connection-oriented reliable protocol. So the HTTP part of the problem is being standardised as HTTP/3
Google's QUIC "gQUiC" will be obsolete once the standardized protocol is finished. Right now a Chrome talking to e.g. GMail uses gQUIC, once the standards work is firmed up it'll speak HTTP/3 and then maybe a year later Google's sites will discontinue gQUIC because it's just maintenance effort with no residual value.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#84I 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'm totally on board with having more than one protocol available (especially since UDP is so much more flexible), but what is it about TCP specifically that precludes its use for p2p? Is it easier to get through NATs et al with UDP?
TCP has an explicit client and server (some caveats here). The userspace API for TCP requires you to do a connect, which does the TCP handshake in the TCP stack, before you can send traffic.
For UDP, you just specify the destination IP and port, and send packets.
For TCP, new incoming SYNs to most (S)NAT addresses will just get dropped - especially CGNAT - making it impossible to communicate in that direction. If you're both in that situation (really common, actually), you just can't talk to each other.
For UDP, the packets will also get dropped on the receiver side. However, the act of sending the packet will often cause the originator's side's NAT to register that five-tuple (source and destination IP and port + UDP proto), which would allow the other side to reply. If both sides do this with the same IP/port pairs, then magically they can communicate - some of the time, at least. There's a lot more involved (for example, how do you know your own external IP address behind NAT?) - read up on STUN - https://en.wikipedia.org/wiki/STUN - for more details.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#85Is QUIC implemented at the kernel level like TCP/UDP, or is it entirely userland? Is it encapsulated in UDP packets?
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#86By the way, even though it is not yet turned on by default, http3 support is present in Firefox and can be activated by toggling 'network.http.http3.enabled' in about:config to true. I have had it enabled for a few weeks and everything seems okay except that rarely I've noticed a few sites not loading the first time I visit them but needing a 'refresh', but I'm not sure if this is because of the new QUIC code or just…
Beware that there have been some issues with Google sites not loading or being very slow with Firefox's HTTP/3 implementation. Some of these were Firefox bugs and some were Google server bugs. But I use HTTP/3 in Firefox Nightly and use Gmail and Google Docs all day long without major breakage these days.
I would avoid enabling QUIC manually anywhere anyway for now, Google controls both endpoints and the RFC so it clearly has an advantage there.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#87I feel like I belong in the minority who like the new Facebook SPA. It loads shockingly fast on my computer, almost instantaneous even
SPA? Ah, single page app
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#88Is QUIC implemented at the kernel level like TCP/UDP, or is it entirely userland? Is it encapsulated in UDP packets?
Most implementations[1] implement it in userland, but this is by no means a requirement. There is no implementation for the Linux kernel presently, but both msquic and F5's QUIC implementation can run in their respective kernels.
QUIC is indeed built on top of UDP datagrams, much in the same way TCP is built (typically) on top of IP datagrams.
[1] https://github.com/quicwg/base-drafts/wiki/Implementations
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#89Am I reading the IETF status incorrectly or is HTTP/3 still i draft status? Why on earth are they implementing a protocol that is in draft status?
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#90Am I reading the IETF status incorrectly or is HTTP/3 still i draft status? Why on earth are they implementing a protocol that is in draft status?
This is how the IETF and protocol development works[1]. In fact, it is strongly encouraged for participants to implement and deploy drafts before they are finalized. Otherwise you risk finalizing something with a lot of deployment problems.