HTTP/3: from root to tip

https://blog.cloudflare.com/http-3-from-root-to-tip/

by jgrahamc • 7 years ago

340 88 7 years ago

blog.cloudflare.com

getcrunk2• 7 years 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• 7 years ago

The second paragraph opens up with a “what is quic” and links to another post. Perhaps give that a read?

scegit• 7 years ago

You can read about IETF QUIC here 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• 7 years 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.

spc476• 7 years ago

A crude, TL;DR is that QUIC is just TCP over UDP.

getcrunk2• 7 years ago

That’s all I wanted lol thanks

cryptonector10• 7 years 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.

jayd162• 7 years ago

Its annoying but the "check and then attempt" pattern just doesn't cut it. There are going to be unexpected issues so you end up always having to handle exceptions anyway.

cryptonector10• 7 years ago

You always have to handle exceptions, but if you can insist on early 3xx/4xx (at least 401) responses, then you can avoid caching any part of the request body. For example, consider something like:

  $ huge_fast_source | curl --negotiate -x POST ...

Here curl might respond to 401s by authenticating to the server, and if it can know that a 401 is coming, then it can simply not read from stdin (thus flow-controlling the huge, fast source) until it has seen 100-continue, which might require a second request. This is very nice.

The fact that it can't be had reliably is rather annoying.

Matthias2476• 7 years 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.

cryptonector10• 7 years ago

The real is that the server is allowed to defer decisions about authentication and authorization until it has seen some or all of the request body, therefore the server might not respond until it has seen part of the body, but the user-agent wants to know whether it can get an immediate response to a POST/PUT in order to avoid sending the body until it knows the server is ready to sink it, and the user-agent is resource constrained and cannot cache the request body, say:

  - the user-agent wants an early 2xx/4xx from the server
  - the server is allowed to defer
  - the user-agent has no reliable way to force the
    server to decide early -- the user-agent can only
    ask nicely for a 100-continue / early 2xx/4xx
  - and the user-agent has no reliable way to determine
    if the server does support Expect: 100-continue

What the user-agent wants is for the server to send any 3xx/401 responses early, else commit to not-401 by sending 100-continue. The server can still defer 2xx/403 responses, though preferably not 403s, until it sees some/all of the request body.

The only fix I can think of is to REQUIRE that OPTIONS responses indicate whether the server supports this or not. An HTTP/2 or 3 gateway to an HTTP/1.1 server (or vice versa) could be configured to indicate support / no support for Expect: 100-continue.

In particular, there is no way for a new version of HTTP to give a user-agent a way to force the server to support early decisions. The servers exist already, and the are as they are.

treve2• 7 years ago

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

As you suspected these headers are 'special' and don't exist in HTTP/2.

cryptonector10• 7 years ago

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.

Section 8.1.2.2 of RFC 7540 [0] covers most of what you ask except that it doesn't explain how chunked transfer-encoding maps to HTTP/2, and section 8.1.3 [1] shows an example of mapping chunked transfer-encoding onto HTTP/2 data frames.

Basically, in HTTP/2 all transfers are necessarily "chunked" into DATA frames [2] (necessarily because of multiplexing of channels!), and Content-Length -when present- merely indicates what all the chunks must add up to.

  [0] https://tools.ietf.org/html/rfc7540#section-8.1.2.2
  [1] https://tools.ietf.org/html/rfc7540#section-8.1.3
  [2] https://tools.ietf.org/html/rfc7540#section-6.1

Matthias2476• 7 years 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.

garmaine2• 7 years ago

Which is also syntax. It’s the correct word choice.

javajosh• 7 years ago

This is not my understanding of the word "syntax". Indeed, if you read 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.

hak8or• 7 years 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• 7 years 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/

He also has a free book about HTTP 3, over here: https://daniel.haxx.se/blog/2018/11/26/http3-explained/

maxk422• 7 years 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.

ggm3• 7 years ago

Could you expand your thesis a bit?

est313• 7 years 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/IncludedCACert...

zzzcpan• 7 years ago

I think his point is about censorship and mostly about the US, where it's done covertly and there is a lot of influence over organizations that provide tech infrastructure. The government can therefore force those organizations to "voluntarily" participate in censorship programs or deny the service to someone effectively censoring it for almost everyone. Google, Facebook, Twitter already participate in such programs, but of course avoid calling them government censorship.

denormalfloat2• 7 years ago

Ok, what do you want to replace it with? You can't complain about the existing system without offering an alternative. Saying the existing system sucks doesn't help move the Internet towards something better.

maxk422• 7 years ago

You could embed public keys in DNS records for one. But I'll admit I was hoping someone who understands security better than I do would jump in.

All I know is that centralized certificate authorities act as choke-points malicious governments can use to censor information.

emilfihlman• 7 years ago

You can't complain about the existing system without offering an alternative.

Yes, you can, and yes, you should. Or are you saying you shouldn't file bug reports unless you can provide a patch?

Get real.

JoshTriplett2• 7 years ago

Entrenching TLS in web standards is just handing the keys to the internet over to malicious government entities.

As opposed to cleartext, which hands your content over to everyone.

Also, certificate transparency means that it's going to be impossible for someone to MITM a TLS connection by forging a valid CA certificate for the domain without giant warning bells going off everywhere.

seabrookmx3• 7 years 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.

denormalfloat2• 7 years 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.

gizzlon2• 7 years 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.

est313• 7 years 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• 7 years 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?

Matthias2476• 7 years ago

It's true that HTTP/2 could eventually replace lots of websocket use-cases, and integrate better with other HTTP code (e.g. frameworks, authentication, etc).

However currently if you need streaming and message ordering guarantees in both direction, you are currently still limited to websockets. HTTP might become more useful once body streaming APIs in both directions are available in browsers.

lucaspardue2• 7 years ago

There is still a place for WebSockets in HTTP/2. The fairly recent RFC 8441 defines a mechanism to reserve a single HTTP/2 stream for bidirectional WebSockets.

It is feasible for a similar mechanism for also work for HTTP/3, just no-one has gone to the effort yet.

https://tools.ietf.org/html/rfc8441

RKearney• 7 years 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• 7 years ago

It does not: https://support.cloudflare.com/hc/en-us/articles/214534978-A...

kpcyrd• 7 years 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• 7 years 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• 7 years ago

Could be client HTTP/3 --> proxy HTTP/1 --> backend

gcloud load balancer docs: https://cloud.google.com/load-balancing/docs/https/#QUIC

lucaspardue2• 7 years 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-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...

tylerl• 7 years 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• 7 years 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.

treve2• 7 years 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• 7 years 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• 7 years ago

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

erickj2• 7 years 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...)

HTTP/2. Roughtly 35% adoption (by site) in the Alexa top 1,000,000. 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• 7 years 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.

21• 7 years ago

I'm not sure what you're talking about. Supporting HTTP/2.0 for my site was literally just adding the "http2" word to the listen directive of nginx. Since it's also used as a reverse proxy, the backend app server remained HTTP/1.1.

And you still notice the difference in site loading speed if your site has a lot of static assets.

erickj2• 7 years ago

How much traffic does your site serve? I'm not saying that turning the feature on is difficult. Anyone reading hacker news can go and configure their webserver to start serving this traffic....

but I can tell you that a site serving serious production loads (let's just say 100 qps)... nobody is just "flipping a config" and sending the protocol out the door.

prdonahue• 7 years 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=....

HTTP/3: from root to tip

Related Stories