IETF publishes HTTP/3 RFC to take the web from TCP to UDP
(2022/06/07)
- Reference: 1654589714
- News link: https://www.theregister.co.uk/2022/06/07/http3_rfc_9114_published/
- Source link:
The Internet Engineering Task Force on Monday published the RFC for HTTP/3, the third version of hypertext transport protocol.
As explained in an IETF [1]summary :
The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.
Let's unpack that a little.
QUIC stands for “Quick UDP Internet Connections” and was [2]created by Google and revealed in 2013. Google developed QUIC to address the fact that Transport Control Protocol (TCP) needs a few back-and-forths to establish a connection and start moving data. It therefore produces long round-trip times which can translate into a poor user experience. QUIC instead uses the User Datagram Protocol (UDP) to carry traffic. UDP reduces the number of round trips between client and server, so speeds things up. This matters a lot on mobile networks, which when Google cooked up QUIC were slow and sparse. Mobile networks remain a very contested resource, so anything that speeds them up is welcome.
Google liked QUIC so much that in 2020 the ad giant [3]baked it into its own Chrome browser and enabled it on its own services – a combo that in theory makes the experience of selling your digital soul to Google more pleasant (or at least involves fewer moments of delay and frustration than selling your soul to others).
[4]
Cloudflare implemented QUIC as an option in [5]2018 .
[6]
[7]
Microsoft also liked QUIC so much it created its own version and [8]open-sourced it . NGINX added HTTP/3 support.
But while QUIC's prevalence increased, much of the world's data traffic was still carried over HTTP/2, which relies on TCP. Slow, verbose, flaky, TCP.
[9]
So when networking boffins started to contemplate HTTP/3, way back in 2016, mapping it to QUIC made sense as a way to speed the web. But they also made sure HTTP/3 and HTTP/2 could co-exist.
[10]TCP alternative QUIC reaches IETF's Standards Track after eight years of evolution
[11]New IETF draft reveals Egyptians invented pyramids to sharpen razor blades
[12].org owner Internet Society puts its money where its mouth is with additional IETF funding
On Monday June 6, their efforts effort produced [13]RFC 9114 – a proposed standard.
The [14]full RFC is over 20,000 words long and explains HTTP/3 in extraordinary detail.
HTTP/3 is already making waves. Cloudflare has [15]revealed that its observations of the web suggest it is already the second-most-prevalent version of HTTP, but still a long way behind HTTP/2.
[16]
Cloudflare HTTP version prevalence
HTTP/3 is the blue line. Click to enlarge
Cloudflare's analysis suggests 80 percent of HTTP/3 traffic comes from the Chrome browser. Quelle surprise .
The publication of the HTTP/3 RFC is not the end of the matter, because RFC stands for "Request for Comments" – meaning HTTP/3 awaits final signoff.
It's unlikely that won't happen, as so many web heavyweights helped to create HTTP/3 that its passage to become a standard is all but assured.
[17]
But HTTP/3 still has critics, and competitors. Apache has held off adding the protocol to its web server, arguing that its own HTTPD does a fine job. [18]Privacy advocates continue to worry about QUIC, as do [19]networking wonks who've found its promised speed boost is elusive. So HTTP/3 is not a panacea.
But the debut of RFC 9114 is nonetheless a big moment. As Cloudflare put it: "Today, a cluster of Internet standards were published that rationalize and modernize the definition of HTTP."
There are not many days on which such statements can be uttered. ®
Get our [20]Tech Resources
[1] https://www.rfc-editor.org/info/rfc9114
[2] https://www.theregister.com/2013/07/10/http_20_ietf_draft_lands/
[3] https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://blog.cloudflare.com/the-quicening/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2020/05/04/microsoft_reveals_msquic_quic_implementation/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2021/05/31/quic_becomes_standard/
[11] https://www.theregister.com/2021/05/20/new_ietf_draft_reveals_egyptians/
[12] https://www.theregister.com/2020/12/03/internet_society_ietf/
[13] https://www.rfc-editor.org/info/rfc9114
[14] https://datatracker.ietf.org/doc/rfc9114/
[15] https://blog.cloudflare.com/cloudflare-view-http3-usage/
[16] https://regmedia.co.uk/2022/06/07/supplied_cloudflare_http_version_prevelance.png
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://www.theregister.com/2021/01/30/quic_fingerprinting_flaw/
[19] https://www.theregister.com/2021/08/04/dissecting_performance_of_production_quic/
[20] https://whitepapers.theregister.com/
As explained in an IETF [1]summary :
The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.
Let's unpack that a little.
QUIC stands for “Quick UDP Internet Connections” and was [2]created by Google and revealed in 2013. Google developed QUIC to address the fact that Transport Control Protocol (TCP) needs a few back-and-forths to establish a connection and start moving data. It therefore produces long round-trip times which can translate into a poor user experience. QUIC instead uses the User Datagram Protocol (UDP) to carry traffic. UDP reduces the number of round trips between client and server, so speeds things up. This matters a lot on mobile networks, which when Google cooked up QUIC were slow and sparse. Mobile networks remain a very contested resource, so anything that speeds them up is welcome.
Google liked QUIC so much that in 2020 the ad giant [3]baked it into its own Chrome browser and enabled it on its own services – a combo that in theory makes the experience of selling your digital soul to Google more pleasant (or at least involves fewer moments of delay and frustration than selling your soul to others).
[4]
Cloudflare implemented QUIC as an option in [5]2018 .
[6]
[7]
Microsoft also liked QUIC so much it created its own version and [8]open-sourced it . NGINX added HTTP/3 support.
But while QUIC's prevalence increased, much of the world's data traffic was still carried over HTTP/2, which relies on TCP. Slow, verbose, flaky, TCP.
[9]
So when networking boffins started to contemplate HTTP/3, way back in 2016, mapping it to QUIC made sense as a way to speed the web. But they also made sure HTTP/3 and HTTP/2 could co-exist.
[10]TCP alternative QUIC reaches IETF's Standards Track after eight years of evolution
[11]New IETF draft reveals Egyptians invented pyramids to sharpen razor blades
[12].org owner Internet Society puts its money where its mouth is with additional IETF funding
On Monday June 6, their efforts effort produced [13]RFC 9114 – a proposed standard.
The [14]full RFC is over 20,000 words long and explains HTTP/3 in extraordinary detail.
HTTP/3 is already making waves. Cloudflare has [15]revealed that its observations of the web suggest it is already the second-most-prevalent version of HTTP, but still a long way behind HTTP/2.
[16]
Cloudflare HTTP version prevalence
HTTP/3 is the blue line. Click to enlarge
Cloudflare's analysis suggests 80 percent of HTTP/3 traffic comes from the Chrome browser. Quelle surprise .
The publication of the HTTP/3 RFC is not the end of the matter, because RFC stands for "Request for Comments" – meaning HTTP/3 awaits final signoff.
It's unlikely that won't happen, as so many web heavyweights helped to create HTTP/3 that its passage to become a standard is all but assured.
[17]
But HTTP/3 still has critics, and competitors. Apache has held off adding the protocol to its web server, arguing that its own HTTPD does a fine job. [18]Privacy advocates continue to worry about QUIC, as do [19]networking wonks who've found its promised speed boost is elusive. So HTTP/3 is not a panacea.
But the debut of RFC 9114 is nonetheless a big moment. As Cloudflare put it: "Today, a cluster of Internet standards were published that rationalize and modernize the definition of HTTP."
There are not many days on which such statements can be uttered. ®
Get our [20]Tech Resources
[1] https://www.rfc-editor.org/info/rfc9114
[2] https://www.theregister.com/2013/07/10/http_20_ietf_draft_lands/
[3] https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://blog.cloudflare.com/the-quicening/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2020/05/04/microsoft_reveals_msquic_quic_implementation/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2021/05/31/quic_becomes_standard/
[11] https://www.theregister.com/2021/05/20/new_ietf_draft_reveals_egyptians/
[12] https://www.theregister.com/2020/12/03/internet_society_ietf/
[13] https://www.rfc-editor.org/info/rfc9114
[14] https://datatracker.ietf.org/doc/rfc9114/
[15] https://blog.cloudflare.com/cloudflare-view-http3-usage/
[16] https://regmedia.co.uk/2022/06/07/supplied_cloudflare_http_version_prevelance.png
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yp8hxQoavnButDs9jvOC5gAAAIc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://www.theregister.com/2021/01/30/quic_fingerprinting_flaw/
[19] https://www.theregister.com/2021/08/04/dissecting_performance_of_production_quic/
[20] https://whitepapers.theregister.com/
Re: TCP needs a few back-and-forths
David Harper 1
"The biggest benefits will come when retrieving "pages" that have lots of distinct elements coming from the same source."
Isn't that what the HTTP "Keep-Alive" persistent connection feature was designed to deliver, way back in the late 1990s?
Re: TCP needs a few back-and-forths
Warm Braw
The difference is that a (single) persistent connection can only retrieve resources serially whereas QUIC allows many to be retrieved in parallel - in theory with less overhead than multiple TCP connections.
Optimisation...
Harry Kiri
OK, yeah, I can see both sides of the argument here, but personally I like the transport layer to be not closely coupled with the application as this is a bad idea long-term. Whenever different system elements are closely coupled to give an integrated improvement in performance, that's good for today and less so for all of the tomorrows. Through-life support and all that.
Plus, as I've got older, the first and second rules of optimisation make more and more sense.
TCP needs a few back-and-forths
And TLS needs some more. The main gains in QUIC come from merging and streamlining the transport and security layers and from the ability to multiplex multiple data streams within one "connection".
The biggest benefits will come when retrieving "pages" that have lots of distinct elements coming from the same source.
TCP implementations are usually outside user space, which gives the OS some control over the fair scheduling of resources. QUIC implementations are currently mostly part of the application (in this case the browser) and it will be interesting to see how well-behaved they are if they find wider uses.