HTTP/3

Video: The QUIC-ematic universe season 2020-2021 preview

Posted on by Russell Trafford-Jones

QUIC is an encrypted transport protocol with better performance than HTTP and HTTP/2. While young, it’s already seeing some use in the larger internet companies who are learning how best to harness the optimisations. One of the stark differences is that it’s built on top of UDP rather than TCP. This is one of the main ways it increases efficiency. Freed from TCP’s constant acknowledgement of packets, QUIC also ensures reliable delivery but on its own terms which allows it to prioritise speedy delivery over acknowledgement admin. We’ve covered QUIC before, so if it’s new to you, check out this explainer as this talk is an update on what’s happened in 2020 and the plans for 2021 as QUIC aims to be standardised and much more available.

Lucas Pardue from Cloudflare works on the IETF working group devoted to QUIC and spoke at Demuxed 2020. “The IETF are standardisers” he says with QUIC being on its 31st draft with a move to standardise during 2021 what is called ‘IETF QUIC’ to differentiate from a slightly different version of QUIC from Google. IETF quick, Lucas outlines, delivers secure, reliable stream multiplexing.
 

 

QUIC actually forms a base layer for other applications like HTTP/3 with HTTP semantics to work on top of. Like most modern standards, QUIC is actually a name for more than one document. There is a transport layer, header compression, TLS handshake description and a document for recovery and loss protection. QUIC itself lives on UDP datagrams which is why one of the new options coming is to turn off some of the reliability which has been built on top of UDP to deliver TCP-like reliability for data which doesn’t really need it. One possibility here is running a QUIC tunnel where one QUIC connection actually has many QUIC streams within it. In this circumstance, you only want any one bit of data being protected by one reliable transmission mechanism. So you’d want to be turning off reliable transmission for your internal QUIC streams as they would be protected by the outer QUIC layer. There is a project called MASQUE which is working on this.

As with anything arriving on the market, it’s important to establish interoperability. We see this with the JT-NM and SRT plugfests. Lucas shows us the QUIC interop tester which automatically tests the latest implementations with each other and shows the results in a matrix plus allows access to logs and packet traces.

Lucas reminds us the QUIC streams are a first-class transport primitive providing reliable delivery. Within a stream, data will be delivered in order, but QUIC doesn’t specify how to schedule multiplexed streams. HTTP3 initially borrowed HTTP/2’s prioritisation scheme but found a better way to prioritise which is currently being discussed and finalised. Lucas has been working on quiche, Cloudflare’s own implementation of QUIC and shows a three-step process to getting quiche up and running.

Web Transport is another offering from QUIC which complements WebSocket which gives web apps better access to QUIC itself. The Chome Origin Trial explains how this is built in Chrome. Lucas talks about a test project he built on top of existing examples which is hosted at http3.wtf

Lucas ends by summarising the coming year: The working group is aiming to deliver documents to an IETF last call ahead of publication. The community will continue to get deployment experience as new users ar already working on enabling the technology and there is still work to be done on other adopted work items as well as considering others. Lucas ends by encouraging viewers to join in with the community,

Watch now!
Speaker

Lucas Pardue Lucas Pardue
Senior Software Engineer, Cloudflare
Co-Chair of the QUIC working group, IETF

Video: HTTP over QUIC is the next generation

Posted on by Russell Trafford-Jones

There’s a lot to like about HTTP/3 from encryption as standard, faster set-up time, better compression and promises better throughput by removing head-of-line blocking. A new protocol making its way through the IETF and based on QUIC, this could have a real impact on anyone involved in streaming.

wolfSSL’s Daniel Stenberg and cURL maintainer, talks to us about HTTP/3 but starts at the beginning with HTTP 1 and 1/1. He outlines some of the issues we had in 1997 such as head-of-line blocking and ephemeral TCP connections. Zooming forward to 2005, HTTP/2 comes on the scene with a single HTTP connection, thus removing the significant overhead of ephemeral TCP connections. HTTP/2 went with a ‘streamed’ connection and could have multiple such streams but one thing that wasn’t solved was head-of-line blocking.

Before moving beyond HTTP/2, Daniel describes the problems that have set in due to ‘ossification’, that is to say, that the routers that time forgot which are still on very old, and often buggy TCP implementations. Innovating is very difficult if replacing the TCP within even a subset of boxes would mean I wasn’t able to send my website globally.

Addressing this ‘ossification’ issue, QUIC has stepped in. Developed on UDP instead of TCP QUIC solves a number of problems. First off, moving from TCP to UDP allows the protocol to live in userspace making it easier to update. Working on UDP instead of TCP means that the protocol regains control of the retransmissions allowing for something more efficient than TCP’s strict acknowledgement rules.

So QUIC becomes the transport layer of HTTP/3. Freeing ourselves from TCP, Daniel explains, allows us to remove the TCP head-of-line blocking problem. HTTP/3 on QUIC brings with it faster handshakes and a connection ID. This connection ID allows you to change IP addresses and still maintain your connection which is a significant improvement on what has gone before. Daniel continues by explaining more benefits of QUICK and HTTP/3 such as its encryption and the ability to have multiple streams.

Daniel finishes up outlining eight challenges for HTTP/3. These include the fact that up to 7% of QUICK attempts fail, dealing with ‘fall back’ algorithms, UDP having seen historically low usage and are less optimised as well as the downsides of userland protocol stacks being that it’s harder to get a standard.

Watch now!
Download the presentation
Speakers

Daniel Stenberg Daniel Stenberg
curl master, wolfSSL
main author,

Video: HTTP/3 ?

Posted on by Russell Trafford-Jones

There’s a lot to like about HTTP/3 from encryption as standard, faster set-up time, better compression and promises better throughput by removing head of line blocking. A new protocol making its way through the IETF and based on QUIC, this could have a real impact to anyone involved in streaming.

Nick Shadrin from F5, focussed on NGINX, explains what the trade-offs are, the benefits, how it works and the likely implementation timelines. Nick starts with a look at HTTP from version 0.9 in the early 90s through to HTTP/2. This lays the groundwork for understanding HTTP/3. We quickly move on to looking at the latency improvements that HTTP/3 brings, particularly for high-latency connections where an improvement of up to four-times could be seen.

Nick outlines the benefits of the protocol such as the move of the transport layer out of the kernel. TCP is baked in to the kernel, but QUIC is not which allows for a faster pace of evolution of the protocol to improve it over time. Although TCP has changed since its inception, the rate of change is very slow since there are so many TCP devices, many of which can’t be updated or updates are very difficult. Built-in encryption is great, although browsers have mandated security with HTTP/2 over and above the specification. However, HTTP/3 goes one step further and also encrypts sequence numbers which helps reduce side-channel attacks.

Another useful addition for modern uses is connections based on connection ID. This means that even if the IP changes mid connection, the server can continue to immediately respond to requests on from the new IP as it’s still identifying with the same connection ID.

Nick talks through the different types of protocol negotiations starting with HTTP. It’s easy to upgrade HTTP to HTTPS with a simple 30x redirect. He discusses HSTS, Websockets use with upgrade headers, the way HTTP 1.x negotiates up to HTTP/2 and finally explains the ‘Alt-Svc’ header. The difficulty with moving from HTTP/2 to 3 is that the it’s not just a change in flavour of HTTP, but a lot of the network stack adjusts.

Looking towards the challenges, Nick points to the need for all boxes to understand HTTP/3 for full support to be practical on the internet at large, citing HTTP/2 adoption being only at 40% after three years – HTTP/2 being a TCP based. Another starting issue is UDP having had less attention than TCP in terms of optimisation, so there are currently cases where it’s much faster and times when it’s lower.

In practical terms, life is made harder by not having a plaintext version, since all tools will have to be able to support the encrypted data and, at this stage in its evolution the toolset is still basic.

Watch now!
Speaker

Nick Shadrin Nick Shadrin
Software Architect, NGINX
F5

Video: There and back again: reinventing UDP streaming with QUIC

Posted on by Russell Trafford-Jones

QUIC is an encrypted transport protocol for increased performance compared to HTTP but will this help video streaming platforms? Often conflated with HTTP/3, QUIC is a UDP-based way evolution of HTTP/2 which, in turn, was a shake-up of the standard HTTP/1.1 delivery method of websites. HTTP/3 uses the same well-known security handshake from TLS 1.3 that is well adopted now in websites around the world to provide encryption by default. Importantly, it creates a connection between the two endpoints into which data streams are multiplexed. This prevents the need to constantly be negotiating new connections as found in HTTP/1.x so helping with speed and efficiency. These are known as QUIC streams.

QUIC streams provide reliable delivery, explains Lucas Pardue from Cloudflare, meaning it will recover packets when they are lost. Moreover, says Lucas, this is done in an extensible way with the standard specifying a basic model, but this is extensible. Indeed, the benefit of basing this technology on UDP is that changes can be done, programmatically, in user-space in lieu of the kernel changes that are typically needed for improved TCP handling on which HTTP/1.1, for example, is based.

QUIC hailed from a project of the same name created by Google which has been taken in by the IETF and, in the open community, honed and rounded into the QUIC we are hearing about today which is notably different from the original but maintaining the improvements proved in the first release. HTTP/3 is the syntax which is a development on from HTTP/2 which uses the QUIC transport protocol underneath or as Lucas would say, “HTTP/3 is the HTTP application mapping to the QUIC transport layer.” Lucas is heavily involved within the IETF effort to standardise HTTP/3 and QUIC so he continues in this talk to explain how QUIC streams are managed, identified and used.

It’s clear that QUIC and HTTP/3 are being carefully created to be tools for future, unforeseen applications with clear knowledge that they have wide applicability. For that reason, we are already seeing projects to add datagrams and RTP into the mix, to add multiparty or multicast. In many ways mimicking what we already have in our local networks. Putting them on QUIC can enable them to work on the internet and open up new ways of delivering streamed video.

The talk finishes with a nod to the fact that SRT and RIST also deliver many of the things QUIC delivers and Lucas leaves open the question of which will prosper in which segments of the broadcast market.

The Broadcast Knowledge has well over 500 talks/videos on many topics so to delve further into anything discussed above, just type into the search bar on the right. Or, for those who like URLs, just add your search query to the end of this URL https://thebroadcastknowledge.com/tag/.

Lucas has already written in detail about his work and what HTTP 3 is on his Cloudflare blog post.

Watch now!
Speaker

Lucas Pardue Lucas Pardue
Senior Software Engineer,
Cloudflare