HTTP over UDP — using the QUIC protocol effectively

QUIC (Quick UDP Internet Connections) is a protocol built on top of UDP that supports all capabilities of TCP, TLS, and HTTP/2, while addressing many of their issues. It's often referred to as a new or 'experimental' protocol, but it has long since moved past the experimental stage: development has been ongoing for over 7 years. During this time, the protocol has not yet become a standard, but it has gained widespread adoption. For example, QUIC is used to accelerate traffic and reduce latency in mobile networks by giants such as Google and Facebook, and the IETF declared its fork the basis for the HTTP/3 standard (given that HTTP/2 only uses 44.8% of websites).

Concept

QUIC was developed as a replacement for the outdated TCP, which was originally designed for wired networks with low packet loss. TCP delivers packets in order, so if one packet is lost, the entire queue halts (head-of-line blocking), which negatively affects the quality and stability of the connection. To avoid massive losses, cellular networks resort to using large buffers, which in turn leads to redundancy and false negative responses from the protocol (bufferbloat). Moreover, TCP spends a significant amount of time establishing a connection: SYN/ACK and TLS requests are sent separately, requiring three roundtrips instead of one, as QUIC does.

Since QUIC combines a TCP replacement with the implementation of TLS 1.3, all connections are always encrypted, making it just as difficult to decrypt such traffic as if it were sent over HTTPS. Additionally, QUIC is implemented at the application level, as a complete replacement of the TCP stack would take ages..

Despite supporting multiplexing in HTTP/2, the head-of-line blocking issue remains due to the necessity of delivering packets in order. QUIC is implemented over UDP, so it inherently has no blocking; to prevent packets from being lost irretrievably, they are numbered and can contain parts from ‘neighbors’, ensuring redundancy. Moreover, QUIC breaks the monolithic queue into multiple streams for different types of requests within a single connection. Thus, when a packet is lost, issues can only arise from one queue (for instance, for transferring a specific file):

Using

Originally, QUIC was developed internally at Google and was primarily tailored for use within the company. In 2013, it was handed over to the IETF for standardization (which is still ongoing), allowing anyone to participate in the protocol's development by proposing what they feel is lacking. The IETF working group organizes annual meetings where new standards are ratified and innovations discussed. This implementation of QUIC is considered the primary one and is the basis for certifying the HTTP/3 standard.

Currently, there is no discussion about making HTTP/3 the primary protocol since it is still incomplete and hardly supported:

However, QUIC can be implemented as a transport between the application and the server, as successfully demonstrated by Uber:

Uber's comment on implementing QUIC

To successfully integrate QUIC and enhance application performance under poor connectivity conditions, we replaced the old stack (HTTP/2 over TLS/TCP) with the QUIC protocol. We utilized the network library Cronet from Chromium Projects, which contains the original Google version of the protocol – gQUIC. This implementation is also continuously improved to follow the latest IETF specification.

First, we integrated Cronet into our Android applications to add QUIC support. The integration was designed to minimize migration costs. Instead of fully replacing the old network stack that used the library OkHttp, we integrated Cronet UNDER the OkHttp API framework. By performing the integration this way, we avoided changes to our network calls (which use Retrofit) at the API level.

Similarly to our approach with Android devices, we implemented Cronet in Uber's iOS applications by intercepting HTTP traffic using API, using NSURLProtocol. This abstraction, provided by the iOS Foundation, handles protocol-specific URL data and ensures that we can integrate Cronet into our iOS applications without significant migration costs.

taken from this translation of the Uber article

On the backend, they handled QUIC connections through Google Cloud lb, which has supported the protocol since mid-2018.

It's not surprising that Google Cloud works excellently with a protocol developed by Google, but what alternatives are there?

Nginx

Not long ago, CloudFlare attempted to combine nginx (which does not support HTTP/3 by default) with their tool Quiche. The implementation is available in the form of a single .patch file, along with an installation tutorial:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

Here, you can connect your modules if necessary

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

You just need to enable HTTP/3 support

events {
    worker_connections  1024;
}

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

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

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering is not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

In regular browsers, it is not yet possible to connect via HTTP/3, but you can take Chrome Canary and run it with the flag --enable-quic, connect to your server or, for instance, to the site quic.rocks and check the connection type in Developer Tools:

Instead of HTTP/3, it shows http2+quic/99, but essentially it's the same.

Other technologies

• QUIC is also supported LiteSpeed (which pompously connected to Facebook via HTTP/3) and progressive Caddy. Apache doesn't support it yet, but work is in progress in full swing.
• On January 21, the draft standard for WebRTC was updated
• Just recently, Microsoft opened the source code of its msquic implementation, which currently does not include all functionalities of the IETF standard, but this is already a significant breakthrough.

Conclusion

Interest in QUIC is inconsistent but growing; work is ongoing for its standardization. New implementations of the protocol are appearing almost every month, and every year more developers are realizing that the future lies with QUIC. There is even a possibility of incorporating the protocol into future versions of the TCP stack, which means that sooner or later the entire internet will shift to more stable and faster connections.

You can already configure QUIC interaction for your infrastructure or even deploy it to browsers—they all plan to add support for the protocol, and the sad statistics from caniuse will soon become more cheerful.

Source: habr.com