5 ms·

> 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

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

microcolonel 6y ago
I think they're talking about Google QUIC, which formed the basis for both IETF QUIC and HTTP/3; Facebook has been deploying Google QUIC for a long while now maybe, AFAIK. The people at fault here are probably the IETF lol.
- mjoras 6y ago
  We never deployed Google QUIC. It was always IETF QUIC. Referring to them together as QUIC was just for expedience, since the main benefits came from the QUIC layer, not the HTTP layer. HTTP/3 implies IETF QUIC. IETF QUIC itself can be used for non-HTTP protocols, though, just like TCP can be used for protocols that aren't HTTP/2.
  - microcolonel 6y ago
    Thank you for the clarification. I'm sure you're looking forward to WebTransport+QUIC as well, I know I am. I'm already doing some little tweaks to our WebSocket RPC and bulk transfer layers to resemble WebTransport so it's an easy drop-in when the QUIC transport becomes available, or when there's a reasonable implementation of WebTransport+HTTP/3 (the other middle ground). Maybe I can publish the virtual “WebSocketTransport” thing once I'm satisfied with it.
alexchamberlain 6y ago
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.
- mjoras 6y ago
  As I said below, the blog is more focused on QUIC itself rather than HTTP/3. The bulk of the improvements we see are from QUIC as a transport layer, rather than the changes in HTTP/3.
- pvorb 6y ago
  Why are there two meanings of QUIC in the first place?
  - tialaramex 6y ago
    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.
    - m3at 6y ago
      Good and concise explanation thank you
    - CppCoder 6y ago
      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 something new. Then support fallback over HTTP1/2 until everything else caught up.
deleted 6y ago
[deleted]

microcolonel 6y ago

I think they're talking about Google QUIC, which formed the basis for both IETF QUIC and HTTP/3; Facebook has been deploying Google QUIC for a long while now maybe, AFAIK. The people at fault here are probably the IETF lol.

mjoras 6y ago
We never deployed Google QUIC. It was always IETF QUIC. Referring to them together as QUIC was just for expedience, since the main benefits came from the QUIC layer, not the HTTP layer. HTTP/3 implies IETF QUIC. IETF QUIC itself can be used for non-HTTP protocols, though, just like TCP can be used for protocols that aren't HTTP/2.
- microcolonel 6y ago
  Thank you for the clarification. I'm sure you're looking forward to WebTransport+QUIC as well, I know I am. I'm already doing some little tweaks to our WebSocket RPC and bulk transfer layers to resemble WebTransport so it's an easy drop-in when the QUIC transport becomes available, or when there's a reasonable implementation of WebTransport+HTTP/3 (the other middle ground). Maybe I can publish the virtual “WebSocketTransport” thing once I'm satisfied with it.

alexchamberlain 6y ago

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.

mjoras 6y ago
As I said below, the blog is more focused on QUIC itself rather than HTTP/3. The bulk of the improvements we see are from QUIC as a transport layer, rather than the changes in HTTP/3.
pvorb 6y ago
Why are there two meanings of QUIC in the first place?
- tialaramex 6y ago
  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.
  - m3at 6y ago
    Good and concise explanation thank you
  - CppCoder 6y ago
    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 something new. Then support fallback over HTTP1/2 until everything else caught up.

deleted 6y ago

[deleted]