HTTP over UDP - use the QUIC protocol to good use

QUIC (Quick UDP Internet Connections) is a protocol over UDP that supports all the features of TCP, TLS and HTTP/2 and solves most of their problems. It is often called a new or "experimental" protocol, but it has long outlived the experimental stage: development has been going on for more than 7 years. During this time, the protocol did not have time to become a standard, but still became widespread. For example, QUIC is used to speed up traffic and reduce latency in mobile networks by giants such as Google and Facebook, and the IETF has declared its protocol fork the basis for the HTTP/3 standard (despite HTTP/2 using only 44.8% sites).

Concept

QUIC was developed as a replacement for the outdated TCP, which was originally designed for wired networks with a low percentage of losses. TCP delivers packets in order, so when one packet is lost, the entire queue is added (head-of-line blocking), which negatively affects the quality and stability of the connection. To avoid massive losses, cellular networks resort to the use of large buffers, which in turn leads to redundancy and false negative protocol response (bufferbloat). In addition, TCP spends a lot of time establishing a connection: SYN / ACK and TLS requests go separately, requiring three roundtrips instead of one, as QUIC does.

Since QUIC combines the replacement of TCP and the implementation of TLS 1.3, all connections are always encrypted, decrypting such traffic is no easier than if it went over HTTPS. In addition, QUIC is implemented at the application level, as how a complete replacement of the TCP stack would take eternity.

Despite the support for multiplexing in HTTP/2, the problem of head-of-line blocking remained there due to the need to deliver packets in order. QUIC is implemented on top of UDP, so it does not have blocking in principle, and so that packets are not lost forever, they are numbered and may contain parts of their “neighbors”, providing redundancy. In addition, QUIC splits a monolithic queue into several threads for different types of requests within a single connection. Thus, if a packet is lost, only one queue can have problems (for example, to transfer a specific file):

Using

Initially, QUIC was developed within Google and was largely tailored for use within the company. In 2013, it was submitted to the IETF for standardization (which is still ongoing), and now everyone can participate in the development of the protocol by offering what it lacks. The IETF Working Group organizes annual meetings where a new standard is approved and innovations are discussed. This implementation of QUIC is considered the main one and it is on its basis that the HTTP / 3 standard is certified.

So far, the inclusion of HTTP / 3 as the main protocol is out of the question, because it is not yet finished and is almost not supported:

But QUIC can be implemented as a transport between the application and the server, which was successfully done in Uber:

Uber comment on QUIC implementation

In order to successfully embed QUIC and improve application performance in poor connectivity, we have replaced the old stack (HTTP/2 over TLS/TCP) with the QUIC protocol. We used the network library Cronet of Chromium Projects, which contains the original, Google version of the protocol - gQUIC. This implementation is also constantly being improved to follow the latest IETF specification.

We first integrated Cronet into our Android apps to add QUIC support. The integration was carried out in such a way as to minimize the cost of migration. Instead of completely replacing the old networking stack that used the library OkHttp, we have integrated Cronet UNDER the OkHttp API framework. By integrating in this way, we avoided changes to our network calls (which use Retrofit) at the API level.

Similar to the Android approach, we have implemented Cronet in Uber iOS apps by intercepting HTTP traffic from network APIusing 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 Uber articles

On the backend, they caught QUIC connections through Google Cloud lb, which supports the protocol since mid 2018.

It's no surprise that Google Cloud works great with the protocol developed by Google, but what are the alternatives?

Nginx

Not so long ago CloudFlare tried to cross nginx (which doesn't know HTTP/3 by default) with its Quiche tool. The implementation is available as a single .patch file, which comes 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

It remains only 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 in 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 ordinary browsers, connecting via HTTP / 3 will not work yet, but you can take Chrome Canary and run it with flag --enable-quic, go to your server or, for example, the quic.rocks site and see the connection type in Developer Tools:

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

Other technologies

• QUIC also support LiteSpeed (which connected to Facebook over HTTP/3 with great fanfare) and progressive Caddy. Apache does not yet know how, but work is in progress full swing.
• January 21 updated draft standard for WebRTC
• Just the other day, Microsoft opened msquic implementation code, in which not all the functions from the IETF standard are available yet, but this is already a big breakthrough.

Conclusion

Interest in QUIC is unstable, but growing, work is underway on its standardization. New implementations of the protocol appear almost every month, and every year more and more developers are convinced that the future belongs to QUIC. Even the inclusion of the protocol in future versions of the TCP stack is allowed, which means that sooner or later the entire Internet will move to more stable and faster connections.

Already now you can set up QUIC interaction for your infrastructure or even give it to browsers - they all plan to add protocol support, and sad statistics with caniuse will become more fun.

Source: habr.com