Get best of the week

HTTP over UDP - use the QUIC protocol with benefit



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 the new or “experimental” protocol, but it has long survived the stage of the experiment: development has been ongoing for more than 7 years. During this time, the protocol did not manage to become a standard, but it was still widely used. For example, such giants as Google and Facebook use QUIC to speed up traffic and reduce latency in mobile networks, and the IETF announced its fork of the protocol as the basis for the HTTP / 3 standard (despite the fact that HTTP / 2 uses only 44.8% of sites).

Concept


QUIC was developed as a replacement for legacy TCP, which was originally designed for wired networks with a low percentage of losses. TCP delivers packets in order, so when a packet is lost, the entire queue ( head-of-line blocking ) rises , 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 reactions ( bufferbloat ). In addition, TCP spends a lot of time establishing a connection: SYN / ACK and TLS requests go separately, requiring three roundtripes 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 not easier than if it went via HTTPS. In addition, QUIC is implemented at the application level, as it would take forever to completely replace the TCP stack .

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

image

Using


QUIC was originally developed internally by Google and was largely tailored for use internally. In 2013, he was transferred to the IETF for standardization (which is still ongoing), and now everyone can participate in the development of the protocol by proposing what he lacks. The IETF working group organizes annually meetings, within which a new standard is approved and innovations are discussed. This QUIC implementation is considered the main one and it is on its basis that the HTTP / 3 standard is certified.

So far, we are not talking about enabling HTTP / 3 as the main protocol, 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


QUIC , (HTTP/2 TLS/TCP) QUIC. Cronet Chromium Projects, , – gQUIC. , IETF.

Cronet Android-, QUIC. , . , , OkHttp, Cronet OkHttp API. , ( Retrofit) API.

Android-, Cronet Uber iOS, HTTP- API, NSURLProtocol. , iOS Foundation, - URL- , Cronet iOS- .
taken from this translation of an Uber article

On the backend, they caught QUIC connections through Google Cloud lb, which has been supporting the protocol since mid-2018.

Not surprisingly, the 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 by default does not know HTTP / 3) with its Quiche tool. The implementation is available as a single .patch file, which has an installation tutorial included:

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

All that remains is 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 normal browsers, connecting via HTTP / 3 is not yet possible, but you can take Chrome Canary and run it with a flag --enable-quic, go to your server or, for example, the quic.rocks website and see the connection type in Developer Tools:

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

Other technology



Conclusion




Interest in QUIC is unstable, but growing, work is underway to standardize it. New protocol implementations appear almost every month, and every year more and more developers are convinced that the future lies with QUIC. It is even possible to include the protocol in future versions of the TCP stack, which means that sooner or later the entire Internet will move to more stable and faster connections.

Already, you can configure 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.


More articles:


All Articles