http3 / Quic - Upcoming transport layer network protocol

[ASTRAPI]

 

QUIC (pronounced 'quick') is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described to the IETF.

Although its name was initially proposed as the acronym for "Quick UDP Internet Connections",IETF's use of the word QUIC is not an acronym; it is simply the name of the protocol.

Among other applications, QUIC improves performance of connection-oriented web applications that are currently using TCP. It does this by establishing a number of multiplexed connections between two endpoints over User Datagram Protocol (UDP). This works hand-in-hand with HTTP/2's multiplexed connections, allowing multiple streams of data to reach all the endpoints independently, and hence independent of packet losses involving other streams. In contrast, HTTP/2 hosted on Transmission Control Protocol (TCP) can suffer head-of-line-blocking delays of all multiplexed streams if any of the TCP packets are delayed or lost.

QUIC's secondary goals include reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. It also moves congestion control algorithms into the user space at both endpoints, rather than the kernel space, which it is claimed will allow these algorithms to improve more rapidly. Additionally, the protocol can be extended with forward error correction (FEC) to further improve performance when errors are expected, and this is seen as the next step in the protocol's evolution.

QUIC aims to be nearly equivalent to a TCP connection but with much-reduced latency. It does this primarily through two changes that rely on the understanding of the behaviour of HTTP traffic.[

It is low-latency by design. The protocol has also been designed to be secure – because there is no cleartext version of the protocol (since everything is routed through TLS 1.3), it’s both highly secure and not subject to the issues of ossification. TLS traffic is neither understandable nor “scannable” in terms of inspection by standard middleboxes, and thus, the traffic is simply routed rather than held up.

QUIC is also designed to be very fast. By offering 0-RTT and 1-RTT (Round Trip Time) handshakes against the TCP 3-way handshakes, the transfer process of QUIC is very fast. QUIC is highly reliable, due to its support of the aforementioned additional streams, meaning that data transmission is assured with greater speed and accuracy. This reliability, combined with speed, offers superior congestion control and stream re-transmission. In fact, the main issue raised against HTTP/3 – the fact that it utilizes UDP, a relatively unreliable transport method – is largely negated by these facets.

 

QUIC decided to use TLS 1.3 as the foundation for the crypto and security layer to avoid inventing something new and instead lean on a trustworthy and existing protocol.

However, while doing this, the working group also decided that to really streamline the use of TLS in QUIC, it should only use "TLS messages" and not "TLS records" for the protocol.

 

Why HTTP/3 and QUIC Matter

Here’s the short explanation: Web browsers, web servers, and other critical pieces of web infrastructure are getting support for a new standard named HTTP/3, which uses QUIC. This is a more modern version of HTTP, which web browsers use to communicate with web servers and send data back and forth.

HTTP/3 has been rewritten to send data more quickly with better resistance to errors. It has built-in encryption, too. That means more speed and security. It’s not just data transfer speed, either: HTTP/3 should reduce latency as well, meaning websites will start loading more quickly after you click or tap a link.

The average person never needs to know about HTTP/3 and QUIC. People who run websites and develop web software have some work to do, but it’s all going to be transparent to the average person. One day, your web browser and the websites you use will start communicating over HTTP/3 instead, and the web will get better and better as more sites opt to use HTTP/3.

 

Even faster connection establishment with QUIC 0-RTT resumption

Zero means zero

Quic goes a step further, and allows clients to send application data in the very first roundtrip of the connection, without requiring any other handshake to be completed beforehand.

 

After all, QUIC already shaved a full round-trip off of a typical connection’s handshake by merging the transport and cryptographic handshakes into one.

By reducing the handshake by an additional roundtrip, QUIC achieves real 0-RTT connection establishment.

 

Implementation:

For the end user there is no reason to worry about it at all as when the major browses enable it by default, they will use it without even know it.

Browsers like Chrome and Firefox support it but users must manually enable it at the moment.

My feeling is that in the next 1-3 months we will have it by default on our browsers.

To enable it is very easy by using one click in Cloudflare and for your web server like Nginx it will be supported in the next version release 1.1.7.9 !

I have already test it even if Nginx officially don' support it yet by using the Cloudflare Nginx patch for it for version: 1.16.1.

# Enable QUIC and HTTP/3.
listen 443 quic reuseport;

# Enable HTTP/2 (optional).
listen 443 ssl http2;

 This will enable both HTTP/2 and HTTP/3 on the TCP/443 and UDP/443 ports respectively. 

Testing the result back then:

curl-http3 -V
curl 7.67.0-DEV (x86_64-pc-linux-gnu) libcurl/7.67.0-DEV BoringSSL zlib/1.2.11 brotli/1.0.7 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 quiche/0.1.0-alpha4
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Largefile libz NTLM NTLM_WB PSL SSL UnixSockets

curl tests against some HTTP/3 QUIC h3-23 draft enabled sites where you notice key indicators for HTTP/3 QUIC

the draft version the curl client sent request for:

Sent QUIC client Initial, ALPN: h3-23

Getting a response:

HTTP/3 200

Checking cloudflare-quic.com:

curl-http3 --http3 -4Iv https://cloudflare-quic.com
*   Trying 104.20.106.50:443...
* Sent QUIC client Initial, ALPN: h3-23
* h3 [:method: HEAD]
* h3 [:path: /]
* h3 [:scheme: https]
* h3 [:authority: cloudflare-quic.com]
* h3 [user-agent: curl/7.67.0-DEV]
* h3 [accept: */*]
* Using HTTP/3 Stream ID: 0 (easy handle 0x55ee98c45e60)
> HEAD / HTTP/3
> Host: cloudflare-quic.com
> user-agent: curl/7.67.0-DEV
> accept: */*
>
< HTTP/3 200
HTTP/3 200
< date: Thu, 27 Sep 2019 08:14:22 GMT
date: Thu, 27 Sep 2019 08:14:22 GMT
< content-type: text/html
content-type: text/html
< content-length: 106072
content-length: 106072
* Added cookie __cfduid="d3d016fd2063af06f1f06e7b9f774e1fd1569462455" for domain cloudflare-quic.com, path /, expire 1600998455
< set-cookie: __cfduid=d3d016fd2063af06f1f06e7b9f774e1fd1569462455; expires=Fri, 25-Sep-20 08:14:22 GMT; path=/; domain=.cloudflare-quic.com; HttpOnly; Secure
set-cookie: __cfduid=d3d016fd2063af06f1f06e7b9f774e1fd1569462455; expires=Fri, 25-Sep-20 08:14:22 GMT; path=/; domain=.cloudflare-quic.com; HttpOnly; Secure
< alt-svc: h3-23=":443"; ma=86400
alt-svc: h3-23=":443"; ma=86400
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
server: cloudflare
< cf-ray: 51c1921aeadcc5f0-EWR
cf-ray: 51c1921aeadcc5f0-EWR
* Connection #0 to host cloudflare-quic.com left intact

 

Kernels and CPU load:

 

Both Google and Facebook have mentioned that their wide scale deployments of QUIC require roughly twice the amount of CPU than the same traffic load does when serving HTTP/2 over TLS.

Some explanations for this include

• the UDP parts in primarily Linux is not at all as optimized as the TCP stack is, since it has not traditionally been used for high speed transfers like this.

• TCP and TLS offloading to hardware exist, but that is much rarer for UDP and basically non-existing for QUIC.

   

Some videos for better understanding:

and

 

You can easily check your website by using Curl or your browser Dev tools or by using:

https://gf.dev/http3-test

Info:

https://en.wikipedia.org/wiki/QUIC

 

Enjoy ! 🙂