12 ms·

HTTP/3: from root to tip

340 points by jgrahamc 8y ago

getcrunk 8y ago
A thing I always notice about new tech is a failure to simply and concicsely explain what it is. I had to click through a few links and I still couldn’t find a one paragraph summary of what quic was. If it doesn’t have a large number of influencers mind share it won’t move quickly (don’t mean that absolutely)
- jbergstroem 8y ago
  The second paragraph opens up with a “what is quic” and links to another post. Perhaps give that a read?
- scegit 8y ago
  You can read about IETF QUIC here https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ HTTP over QUIC is now HTTP/3. "HTTP/3 is just a new HTTP syntax that works on IETF QUIC, a UDP-based multiplexed and secure transport"
- aboutruby 8y ago
  QUIC is likely to be implemented first by large internet service providers (Google (who made it), Amazon, Cloudflare, etc.) and there slowly come to all the various open source projects and various software installed on every computer. Just having the major internet services and browsers implementing it already makes a sizable difference.
- deleted 8y ago
  [deleted]
- spc476 8y ago
  A crude, TL;DR is that QUIC is just TCP over UDP.
  - getcrunk 8y ago
    That’s all I wanted lol thanks
cryptonector 8y ago
Is it the case that HTTP/3, like HTTP/2, will not change the semantics of HTTP in any way? One thing that drives me nuts, for example, is that Expect: 100-continue exists but has no criticality, so a user-agent can't tell at all if the 100 continue will be coming, or if a 2xx, 3xx, 4xx, or 5xx response will be sent immediately. In principle the user-agent could use OPTIONS to detect if the server implements Expect: for the target resource, but there is no guarantee that a server that supports Expect: will note that in responses to OPTIONS. Some clients implement a timeout then begin sending the request body, but suppose when they do so the server's 3xx/4xx/5xx response is already in-flight? Then the server will expect a new request, not a request body, next from the user-agent. What a mess. And, of course, Expect: is a very important feature. It's needed to avoid sending data that cannot be recreated, or without having to cache it in order to resend it if the request failed with a 401, say. What I'd like to see is a hard requirement that OPTIONS must indicate whether the server supports Expect:. I'm not sure much more than that can be done to fix the problem. But obviously, a new transport for HTTP can't change this sort of semantics, as one might be gatewaying to/from HTTP/1.1.
- Matthias247 8y ago
  Is that really a HTTP/[2|3] problem, or a problem of those servers? As far as I understood the HTTP/2 spec (have read this, but not HTTP/3), it is allowed for servers to send an arbitrary amount of informational headers (incl. 100-continue) before sending the actual headers and response body. So everything to handle these kinds of requests should be in place. If the server ignores the "Expect: 100-continue" there is obviously nothing the other side can do, but that's the same in HTTP/1.1. What I am a bit unsure about is actually how things like "transfer-encoding: chunked" or the various "connection" headers are supposed to be handled in servers/clients/libraries that are supposed to handle HTTP/1.1 and HTTP/2. Is this supposed to be automatically set on the lower level, depending on the actual protocol type. And the application level HTTP client or handler on server just sees the body as a stream? I'm not sure if that happens currently in common libraries, or whether they would forward these things if a client is connected via HTTP/1.1 and not when it's connected via HTTP/2.
  - 8y ago
Matthias247 8y ago
Great article about the HTTP history! Only one thing I would change: The article mentions the term "syntax" very often, but I don't it is the best choice. When I read syntax, I think about something human-readable, e.g. about programming language syntax. What is really meant is "wire-level encoding" or "serialization format". I think [wire-level] encoding might be the most common used term for protocols.
- garmaine 8y ago
  Which is also syntax. It’s the correct word choice.
  - javajosh 8y ago
    This is not my understanding of the word "syntax". Indeed, if you read https://en.wikipedia.org/wiki/TCP/IP_Illustrated https://en.wikipedia.org/wiki/TCP/IP_Illustrated you'll not see the word "syntax" used to describe the protocol layout. So, basically I agree that the word is misused in the post. I think "layout" might work better.
    - cryptonector 8y ago
      It's one of those words whose meanings in the industry vary a fair bit contextually. So, for example, ASN.1 defines syntax for expressing schemas (ITU-T x.680 and others in the x.68x series), and also encoding rules (x.690 and others in the x.69x series). XDR is one standard for both, syntax and encoding. In HTTP land syntax is used to refer to encoding. In HTTP/1.x, because the protocol is textual and specified in ABNF, syntax can refer to both things equally well. In HTTP/{2,3} this is no longer the case but it doesn't matter, we continue to use "syntax" to refer to the encoding.
  - hak8or 8y ago
    While it may be correct as per the defneition of the word, it's usage in that manner is (as far as I can tell) extremely rare if not non existent in the industry (embedded systems, computer engineering, microcontroller work, etc). Therefore, even if it is correct in the literal sense, it's usage this way introduces so much confusion (due to it meaning something else in those fields), it's effectively incorrect.
oxymoron 8y ago
Here’s another good intro, from a few days ago, by Daniel Stenberg of curl fame: https://daniel.haxx.se/blog/2019/01/23/http-3-talk-on-video/ https://daniel.haxx.se/blog/2019/01/23/http-3-talk-on-video/ He also has a free book about HTTP 3, over here: https://daniel.haxx.se/blog/2018/11/26/http3-explained/ https://daniel.haxx.se/blog/2018/11/26/http3-explained/
maxk42 8y ago
This is bullshit. Entrenching TLS in web standards is just handing the keys to the internet over to malicious government entities. We need security without TLS.
- ggm 8y ago
  Could you expand your thesis a bit?
  - est31 8y ago
    I think maxk42 is worried about the TLS certificate root zone which contains many governments. Just look here [1] and search for "government", you'll find various governments mentioned directly. Others are present indirectly, like the german government through the D-TRUST certificates that are operated by the 100% federally-owned company Bundesdruckerei. In the days before things like Certificate Transparency and HSTS preload lists, this was very worrysome because any of these governments could just freely impersonate any website they wanted to decrypt their access to. TLS is very vulnerable to this. SSH still has the TOFU model that is less vulnerable and TLS+TOFU is possible with HPKP but Chrome removed it. I can understand the reasons for the removal but it still had negative consequences. However, Google/Chrome is very avid about Certificate Transparency and many high-value domains are in the HSTS preload list with hardcoded CAs so we are in a better situation than just 5 years ago and I think it is going to improve going forward. So no reason to discard TLS entirely with some kind of nirvana fallacy, but of course, being aware of the problems is always a good thing. [1]: https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport https://ccadb-public.secure.force.com/mozilla/IncludedCACert...
    - ggm 8y ago
      Thanks. That was helpful. With letsencrypt it feels like this problem is not the problem it used to be, because most certificates are now self asserted.
      - est31 8y ago
seabrookmx 8y ago
Tangentially related.. like HTTP, Websockets currently operate over TCP. Is there plans to port them to QUIC as well? It's been many years since my networking class but I'd assume Websockets would stand to gain quite a bit as well.
- denormalfloat 8y ago
  Websockets (the protocol) are mostly defunct in comparison to HTTP/2 and QUIC. Porting websocket based code should mean converting it to HTTP{2,3}. The main reason that's not possible today is due to large existing library support for websockets on both the server side and directly in browsers.
  - gizzlon 8y ago
    I disagree. Websockets sweet-spot is still the "server wants to send messages to the client" usecase. This does not work (as well) with http/2. Dunno about /3, but it's really a fundamentally different model than the reques/reply of http.
- est31 8y ago
  Websockets are largely obsolete because nowadays, if you create a HTTP/2 fetch request, any existing keepalive connection to that server is used, so the overhead that pre-HTTP/2 XHR connections needed is lost and with it the advantage of Websockets.
  - crgwbr 8y ago
    Honestly curious: how would you use HTTP{2,3} to push a real-time message from server to client without a WebSocket? Are we back to just long polling?
    - Matthias247 8y ago
      You can use server-sent-events or use do some custom streaming format inside the response body. The latter might not work well, due to the fact that arbitrary streaming APIs might not yet be exposed by all browsers (ReadableStream on fetch API: https://caniuse.com/#feat=streams https://caniuse.com/#feat=streams).
RKearney 8y ago
Does CloudFlare support HTTP/2 back to the Origin yet? Or are they still afraid this will destroy the selling point of their Railgun feature?
- manigandham 8y ago
  It does not: https://support.cloudflare.com/hc/en-us/articles/214534978-Are-the-HTTP-2-or-SPDY-protocols-supported-between-Cloudflare-and-the-origin-server- https://support.cloudflare.com/hc/en-us/articles/214534978-A...
- jgrahamc 8y ago
  I'd happily answer the first question, but your second question is flat out dumb.
  - jbergstroem 8y ago
    How do you see argo tunnel fit in this scope? It obviously has other features (cert management, internal routing) - but you'd have to keep competing against http standards with your protocol, no?
    - jgrahamc 8y ago
      Argo Tunnel doesn't 'compete against web standards'. I'm really surprised that people are somehow claiming that Cloudflare is against the open web in some way when we've done so much to progress it (e.g. through early support for SPDY and HTTP/2 and now with QUIC including an open source QUIC implementation in Rust). Argo Tunnel does a specific thing: make a connection from a client's server to Cloudflare (rather than the other way around). This is helpful from a scaling perspective (why have a load balancer when we can do it?) and a security perspective (no open ports). If there was a standard that did the same thing as Argo Tunnel we'd adopt it.
      - jbergstroem 8y ago
        I didn't mean to imply that it is competing with open web standards; I apologize if it came out that way. I was trying to make the case that for instance performance benefits in http3 wouldn't apply to the connection that Argo maintains to origin since it is a different protocol and what your thoughts was on this.
kpcyrd 8y ago
Did anybody look into how this is going to work with proxies? It seems fairly naive to standardize this without having a solution for that.
- sowbug 8y ago
  QUIC connections are always encrypted and authenticated, so they should work just fine with a CONNECT-style proxy that supports UDP. (I don't know for sure; I'm just reasoning from first principles.) EDIT: after thinking a few minutes, I'm not sure a "UDP proxy" is a meaningful concept except in very limited circumstances such as forwarding only to a single destination, because there's no connection to establish that a proxy server could know anything about. Maybe proxy servers don't have a place in a QUIC world.
- tomassre 8y ago
  Could be client HTTP/3 --> proxy HTTP/1 --> backend gcloud load balancer docs: https://cloud.google.com/load-balancing/docs/https/#QUIC https://cloud.google.com/load-balancing/docs/https/#QUIC
- lucaspardue 8y ago
  Do you mean forward proxies? The HTTP/3 draft currently specifies how the CONNECT method is used. At present, it only allows you to create an onward TCP connection. So you have a QUIC connection between client and proxy, and a TCP connection between proxy and server. Like so QUIC TCP client <----> proxy <----> server Unfortuantely, this means that a HTTP/3 client has to tunnel HTTP/1.1 or HTTP/2 to the target server. I realised this was a shortcoming last year and prepared an I-D called HiNT that explores the problem space and some candidate solutions: https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-network-tunnelling/ https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-n... This was presented, along with some nicer tunnel diagrams, at the IETF 102 meeting. Slides in pdf: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/hint-helium.pdf https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102...
tylerl 8y ago
TL;DR: The new QUIC standard being produced changes the way in which certain HTTP concepts are encoded; it's not just an added layer upon which existing HTTP/2 bits can written. Because the format changes, the protocol number must be bumped as well.
electrotype 8y ago
I'm curious on why the upgrade mecanism to tell the server you understand and prefere HTTP3 is different from the one used to upgrade to a Websocket connection? It doesn't seem to use the "Connection: Upgrade" and "Upgrade: XXX" headers but rather "Alt-Svc"... I'm a total newbie on the topic, so I'm curious about this.
- treve 8y ago
  Because you aren't just switching the 'format on the wire', you are switching from TCP to UDP, which requires a new IP connection.
benbristow 8y ago
HTTP/2 only just seems to be gaining traction. Isn't even a default on NGINX (hidden behind a server config option) and now we're moving to HTTP/3?
- teacpde 8y ago
  I think what makes http3 really desirable and convincing to migrate to is its improvements on mobile networking which is prevailing nowadays.
erickj 8y ago
The proliferation of future protocols that will never fully be adopted is simply creating an fractious and overly complicated mess. examples: IPv6 migration. This is the best case, given that it was a necessity to combat the exhausting pool of IPv4 addresses. Even such only ~25% client adoption after 10 years. And worse support from websites in the alexa top 1,000,000 (https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/ https://www.internetsociety.org/resources/2018/state-of-ipv6...) HTTP/2. Roughtly 35% adoption (by site) in the Alexa top 1,000,000. https://http2.netray.io/stats.html https://http2.netray.io/stats.html HTTP/3. Obviously less. Now I'm not trying to make this point from the position of the grumpy old man who doesn't want to learn something new. I love new tech, and obviously the research and development of new protocols over the past 30'ish years has created an explosion of new industry and communication patterns that have indisputably changed the world and shaped modern life. However... the marginal benefit of each protocol advancement is directly related to it's usage (so I assume). The benefit the world saw (from the user perspective) when switching from HTTP/2.0 from HTTP/1.1 was arguably zero (I'm not saying it was exactly "zero", but I could argue that it was imperceptible). With bridge technologies like WebSockets and BOSH/Comet/"Hanging POSTS" it could be argued that HTTP/2 was effectively a bandwidth optimization in most users lives (those users that use the sites that offer support). However, the additional complexity for developers to leverage these optimizations is detracting from the development of otherwise useful service offerings in the form of opportunity cost. This is because nearly every optimization inherently incurs a complexity cost, e.g. supporting both HTTP/1.1 and HTTP/2 is obviously more complex than simply supporting the former. And you are supporting it even if your deployment process abstracts the details away from you, e.g. debugging customer issues. Formulating HTTP/3 when support for HTTP/2 is below 30% is simply an example of standards bodies working on a tiny "easy" problem (make the web go faster.. which is important) rather than face the bigger problem, i.e. helping to scale the worlds service providers a seamless migration path to adopt said new technology. /rant from a grumpy old man
- Meai 8y ago
  I think adoption could be improved so much if the standards commitee released a javascript and C library for whatever they end up deciding. The javascript implementation should be heavily commented, super easy to understand and basically be the documentation of the standard and the C library (or libraries) should be performance tuned tiny modules that can be called upon by other languages. You may ask: Why javascript? Well the reasons are too many to enumerate and immediately 50 people would come here to disagree and say that they prefer their own language but basically it boils down to there being no fancy features to get in the way of understanding an algorithm. The reasons for C are almost the same, it's easy to understand but with the added advantage of being interopable with just about anything on the planet and fast. Even for http2 after many many years and lots of searching, you basically have to use nghttp2 as the only usable http2 C library and its source code is mixed together with various c++ components. Isn't it always like this? I mean don't these standards committees have to write the algorithms out anyway, why not make a usable module out of it in source code form? I suspect it's because in reality the standard gets sponsored by Google whose engineers have already written c++ implementations that are tied to dozens of their own libraries and subcomponents and integrated into the chrome build system etc etc. Well that still doesn't change the fact that it would be better for everyone else if they released a simple to understand implementation in js and C.
otabdeveloper1 8y ago
I think you meant "Google (c) HTTP/3". Let me check with the legal department and get back to you pronto.
prdonahue 8y ago
If you're interested on working on HTTP/3, QUIC, and the author of this post, we're hiring a Product Manager for this team in our London office: https://boards.greenhouse.io/cloudflare/jobs/1251515?gh_jid=1251515 https://boards.greenhouse.io/cloudflare/jobs/1251515?gh_jid=....

340 points by jgrahamc 8y ago

A thing I always notice about new tech is a failure to simply and concicsely explain what it is. I had to click through a few links and I still couldn’t find a one paragraph summary of what quic was. If it doesn’t have a large number of influencers mind share it won’t move quickly (don’t mean that absolutely)

jbergstroem 8y ago
The second paragraph opens up with a “what is quic” and links to another post. Perhaps give that a read?
scegit 8y ago
You can read about IETF QUIC here https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ HTTP over QUIC is now HTTP/3. "HTTP/3 is just a new HTTP syntax that works on IETF QUIC, a UDP-based multiplexed and secure transport"
aboutruby 8y ago
QUIC is likely to be implemented first by large internet service providers (Google (who made it), Amazon, Cloudflare, etc.) and there slowly come to all the various open source projects and various software installed on every computer. Just having the major internet services and browsers implementing it already makes a sizable difference.
deleted 8y ago
[deleted]
spc476 8y ago
A crude, TL;DR is that QUIC is just TCP over UDP.
- getcrunk 8y ago
  That’s all I wanted lol thanks

cryptonector 8y ago

Is it the case that HTTP/3, like HTTP/2, will not change the semantics of HTTP in any way? One thing that drives me nuts, for example, is that Expect: 100-continue exists but has no criticality, so a user-agent can't tell at all if the 100 continue will be coming, or if a 2xx, 3xx, 4xx, or 5xx response will be sent immediately. In principle the user-agent could use OPTIONS to detect if the server implements Expect: for the target resource, but there is no guarantee that a server that supports Expect: will note that in responses to OPTIONS. Some clients implement a timeout then begin sending the request body, but suppose when they do so the server's 3xx/4xx/5xx response is already in-flight? Then the server will expect a new request, not a request body, next from the user-agent. What a mess. And, of course, Expect: is a very important feature. It's needed to avoid sending data that cannot be recreated, or without having to cache it in order to resend it if the request failed with a 401, say. What I'd like to see is a hard requirement that OPTIONS must indicate whether the server supports Expect:. I'm not sure much more than that can be done to fix the problem. But obviously, a new transport for HTTP can't change this sort of semantics, as one might be gatewaying to/from HTTP/1.1.

Matthias247 8y ago
Is that really a HTTP/[2|3] problem, or a problem of those servers? As far as I understood the HTTP/2 spec (have read this, but not HTTP/3), it is allowed for servers to send an arbitrary amount of informational headers (incl. 100-continue) before sending the actual headers and response body. So everything to handle these kinds of requests should be in place. If the server ignores the "Expect: 100-continue" there is obviously nothing the other side can do, but that's the same in HTTP/1.1. What I am a bit unsure about is actually how things like "transfer-encoding: chunked" or the various "connection" headers are supposed to be handled in servers/clients/libraries that are supposed to handle HTTP/1.1 and HTTP/2. Is this supposed to be automatically set on the lower level, depending on the actual protocol type. And the application level HTTP client or handler on server just sees the body as a stream? I'm not sure if that happens currently in common libraries, or whether they would forward these things if a client is connected via HTTP/1.1 and not when it's connected via HTTP/2.
- 8y ago

Matthias247 8y ago

Great article about the HTTP history! Only one thing I would change: The article mentions the term "syntax" very often, but I don't it is the best choice. When I read syntax, I think about something human-readable, e.g. about programming language syntax. What is really meant is "wire-level encoding" or "serialization format". I think [wire-level] encoding might be the most common used term for protocols.

garmaine 8y ago
Which is also syntax. It’s the correct word choice.
- javajosh 8y ago
  This is not my understanding of the word "syntax". Indeed, if you read https://en.wikipedia.org/wiki/TCP/IP_Illustrated https://en.wikipedia.org/wiki/TCP/IP_Illustrated you'll not see the word "syntax" used to describe the protocol layout. So, basically I agree that the word is misused in the post. I think "layout" might work better.
  - cryptonector 8y ago
    It's one of those words whose meanings in the industry vary a fair bit contextually. So, for example, ASN.1 defines syntax for expressing schemas (ITU-T x.680 and others in the x.68x series), and also encoding rules (x.690 and others in the x.69x series). XDR is one standard for both, syntax and encoding. In HTTP land syntax is used to refer to encoding. In HTTP/1.x, because the protocol is textual and specified in ABNF, syntax can refer to both things equally well. In HTTP/{2,3} this is no longer the case but it doesn't matter, we continue to use "syntax" to refer to the encoding.
- hak8or 8y ago
  While it may be correct as per the defneition of the word, it's usage in that manner is (as far as I can tell) extremely rare if not non existent in the industry (embedded systems, computer engineering, microcontroller work, etc). Therefore, even if it is correct in the literal sense, it's usage this way introduces so much confusion (due to it meaning something else in those fields), it's effectively incorrect.

oxymoron 8y ago

Here’s another good intro, from a few days ago, by Daniel Stenberg of curl fame: https://daniel.haxx.se/blog/2019/01/23/http-3-talk-on-video/ https://daniel.haxx.se/blog/2019/01/23/http-3-talk-on-video/ He also has a free book about HTTP 3, over here: https://daniel.haxx.se/blog/2018/11/26/http3-explained/ https://daniel.haxx.se/blog/2018/11/26/http3-explained/

maxk42 8y ago

This is bullshit. Entrenching TLS in web standards is just handing the keys to the internet over to malicious government entities. We need security without TLS.

ggm 8y ago
Could you expand your thesis a bit?
- est31 8y ago
  I think maxk42 is worried about the TLS certificate root zone which contains many governments. Just look here [1] and search for "government", you'll find various governments mentioned directly. Others are present indirectly, like the german government through the D-TRUST certificates that are operated by the 100% federally-owned company Bundesdruckerei. In the days before things like Certificate Transparency and HSTS preload lists, this was very worrysome because any of these governments could just freely impersonate any website they wanted to decrypt their access to. TLS is very vulnerable to this. SSH still has the TOFU model that is less vulnerable and TLS+TOFU is possible with HPKP but Chrome removed it. I can understand the reasons for the removal but it still had negative consequences. However, Google/Chrome is very avid about Certificate Transparency and many high-value domains are in the HSTS preload list with hardcoded CAs so we are in a better situation than just 5 years ago and I think it is going to improve going forward. So no reason to discard TLS entirely with some kind of nirvana fallacy, but of course, being aware of the problems is always a good thing. [1]: https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport https://ccadb-public.secure.force.com/mozilla/IncludedCACert...
  - ggm 8y ago
    Thanks. That was helpful. With letsencrypt it feels like this problem is not the problem it used to be, because most certificates are now self asserted.
    - est31 8y ago

seabrookmx 8y ago

Tangentially related.. like HTTP, Websockets currently operate over TCP. Is there plans to port them to QUIC as well? It's been many years since my networking class but I'd assume Websockets would stand to gain quite a bit as well.

denormalfloat 8y ago
Websockets (the protocol) are mostly defunct in comparison to HTTP/2 and QUIC. Porting websocket based code should mean converting it to HTTP{2,3}. The main reason that's not possible today is due to large existing library support for websockets on both the server side and directly in browsers.
- gizzlon 8y ago
  I disagree. Websockets sweet-spot is still the "server wants to send messages to the client" usecase. This does not work (as well) with http/2. Dunno about /3, but it's really a fundamentally different model than the reques/reply of http.
est31 8y ago
Websockets are largely obsolete because nowadays, if you create a HTTP/2 fetch request, any existing keepalive connection to that server is used, so the overhead that pre-HTTP/2 XHR connections needed is lost and with it the advantage of Websockets.
- crgwbr 8y ago
  Honestly curious: how would you use HTTP{2,3} to push a real-time message from server to client without a WebSocket? Are we back to just long polling?
  - Matthias247 8y ago
    You can use server-sent-events or use do some custom streaming format inside the response body. The latter might not work well, due to the fact that arbitrary streaming APIs might not yet be exposed by all browsers (ReadableStream on fetch API: https://caniuse.com/#feat=streams https://caniuse.com/#feat=streams).

RKearney 8y ago

Does CloudFlare support HTTP/2 back to the Origin yet? Or are they still afraid this will destroy the selling point of their Railgun feature?

manigandham 8y ago
It does not: https://support.cloudflare.com/hc/en-us/articles/214534978-Are-the-HTTP-2-or-SPDY-protocols-supported-between-Cloudflare-and-the-origin-server- https://support.cloudflare.com/hc/en-us/articles/214534978-A...
jgrahamc 8y ago
I'd happily answer the first question, but your second question is flat out dumb.
- jbergstroem 8y ago
  How do you see argo tunnel fit in this scope? It obviously has other features (cert management, internal routing) - but you'd have to keep competing against http standards with your protocol, no?
  - jgrahamc 8y ago
    Argo Tunnel doesn't 'compete against web standards'. I'm really surprised that people are somehow claiming that Cloudflare is against the open web in some way when we've done so much to progress it (e.g. through early support for SPDY and HTTP/2 and now with QUIC including an open source QUIC implementation in Rust). Argo Tunnel does a specific thing: make a connection from a client's server to Cloudflare (rather than the other way around). This is helpful from a scaling perspective (why have a load balancer when we can do it?) and a security perspective (no open ports). If there was a standard that did the same thing as Argo Tunnel we'd adopt it.
    - jbergstroem 8y ago
      I didn't mean to imply that it is competing with open web standards; I apologize if it came out that way. I was trying to make the case that for instance performance benefits in http3 wouldn't apply to the connection that Argo maintains to origin since it is a different protocol and what your thoughts was on this.

kpcyrd 8y ago

Did anybody look into how this is going to work with proxies? It seems fairly naive to standardize this without having a solution for that.

sowbug 8y ago
QUIC connections are always encrypted and authenticated, so they should work just fine with a CONNECT-style proxy that supports UDP. (I don't know for sure; I'm just reasoning from first principles.) EDIT: after thinking a few minutes, I'm not sure a "UDP proxy" is a meaningful concept except in very limited circumstances such as forwarding only to a single destination, because there's no connection to establish that a proxy server could know anything about. Maybe proxy servers don't have a place in a QUIC world.
tomassre 8y ago
Could be client HTTP/3 --> proxy HTTP/1 --> backend gcloud load balancer docs: https://cloud.google.com/load-balancing/docs/https/#QUIC https://cloud.google.com/load-balancing/docs/https/#QUIC
lucaspardue 8y ago
Do you mean forward proxies? The HTTP/3 draft currently specifies how the CONNECT method is used. At present, it only allows you to create an onward TCP connection. So you have a QUIC connection between client and proxy, and a TCP connection between proxy and server. Like so QUIC TCP client <----> proxy <----> server Unfortuantely, this means that a HTTP/3 client has to tunnel HTTP/1.1 or HTTP/2 to the target server. I realised this was a shortcoming last year and prepared an I-D called HiNT that explores the problem space and some candidate solutions: https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-network-tunnelling/ https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-n... This was presented, along with some nicer tunnel diagrams, at the IETF 102 meeting. Slides in pdf: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/hint-helium.pdf https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102...

tylerl 8y ago

TL;DR: The new QUIC standard being produced changes the way in which certain HTTP concepts are encoded; it's not just an added layer upon which existing HTTP/2 bits can written. Because the format changes, the protocol number must be bumped as well.

electrotype 8y ago

I'm curious on why the upgrade mecanism to tell the server you understand and prefere HTTP3 is different from the one used to upgrade to a Websocket connection? It doesn't seem to use the "Connection: Upgrade" and "Upgrade: XXX" headers but rather "Alt-Svc"... I'm a total newbie on the topic, so I'm curious about this.

treve 8y ago
Because you aren't just switching the 'format on the wire', you are switching from TCP to UDP, which requires a new IP connection.

benbristow 8y ago

HTTP/2 only just seems to be gaining traction. Isn't even a default on NGINX (hidden behind a server config option) and now we're moving to HTTP/3?

teacpde 8y ago
I think what makes http3 really desirable and convincing to migrate to is its improvements on mobile networking which is prevailing nowadays.

erickj 8y ago

The proliferation of future protocols that will never fully be adopted is simply creating an fractious and overly complicated mess. examples: IPv6 migration. This is the best case, given that it was a necessity to combat the exhausting pool of IPv4 addresses. Even such only ~25% client adoption after 10 years. And worse support from websites in the alexa top 1,000,000 (https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/ https://www.internetsociety.org/resources/2018/state-of-ipv6...) HTTP/2. Roughtly 35% adoption (by site) in the Alexa top 1,000,000. https://http2.netray.io/stats.html https://http2.netray.io/stats.html HTTP/3. Obviously less. Now I'm not trying to make this point from the position of the grumpy old man who doesn't want to learn something new. I love new tech, and obviously the research and development of new protocols over the past 30'ish years has created an explosion of new industry and communication patterns that have indisputably changed the world and shaped modern life. However... the marginal benefit of each protocol advancement is directly related to it's usage (so I assume). The benefit the world saw (from the user perspective) when switching from HTTP/2.0 from HTTP/1.1 was arguably zero (I'm not saying it was exactly "zero", but I could argue that it was imperceptible). With bridge technologies like WebSockets and BOSH/Comet/"Hanging POSTS" it could be argued that HTTP/2 was effectively a bandwidth optimization in most users lives (those users that use the sites that offer support). However, the additional complexity for developers to leverage these optimizations is detracting from the development of otherwise useful service offerings in the form of opportunity cost. This is because nearly every optimization inherently incurs a complexity cost, e.g. supporting both HTTP/1.1 and HTTP/2 is obviously more complex than simply supporting the former. And you are supporting it even if your deployment process abstracts the details away from you, e.g. debugging customer issues. Formulating HTTP/3 when support for HTTP/2 is below 30% is simply an example of standards bodies working on a tiny "easy" problem (make the web go faster.. which is important) rather than face the bigger problem, i.e. helping to scale the worlds service providers a seamless migration path to adopt said new technology. /rant from a grumpy old man

Meai 8y ago
I think adoption could be improved so much if the standards commitee released a javascript and C library for whatever they end up deciding. The javascript implementation should be heavily commented, super easy to understand and basically be the documentation of the standard and the C library (or libraries) should be performance tuned tiny modules that can be called upon by other languages. You may ask: Why javascript? Well the reasons are too many to enumerate and immediately 50 people would come here to disagree and say that they prefer their own language but basically it boils down to there being no fancy features to get in the way of understanding an algorithm. The reasons for C are almost the same, it's easy to understand but with the added advantage of being interopable with just about anything on the planet and fast. Even for http2 after many many years and lots of searching, you basically have to use nghttp2 as the only usable http2 C library and its source code is mixed together with various c++ components. Isn't it always like this? I mean don't these standards committees have to write the algorithms out anyway, why not make a usable module out of it in source code form? I suspect it's because in reality the standard gets sponsored by Google whose engineers have already written c++ implementations that are tied to dozens of their own libraries and subcomponents and integrated into the chrome build system etc etc. Well that still doesn't change the fact that it would be better for everyone else if they released a simple to understand implementation in js and C.

otabdeveloper1 8y ago

I think you meant "Google (c) HTTP/3". Let me check with the legal department and get back to you pronto.

prdonahue 8y ago

If you're interested on working on HTTP/3, QUIC, and the author of this post, we're hiring a Product Manager for this team in our London office: https://boards.greenhouse.io/cloudflare/jobs/1251515?gh_jid=1251515 https://boards.greenhouse.io/cloudflare/jobs/1251515?gh_jid=....