{"id":81847,"date":"2020-05-17T01:42:34","date_gmt":"2020-05-16T23:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic"},"modified":"2020-05-17T01:42:34","modified_gmt":"2020-05-16T23:42:34","slug":"http-po-udp-ispolzuem-s-polzoj-protokol-quic","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP over UDP \u2014 using the QUIC protocol effectively","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (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%<\/a><\/noindex> of websites).<\/a><\/noindex><\/p>\n

Concept<\/h2>\n

\nQUIC 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<\/a><\/noindex>), 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<\/a><\/noindex>). Additionally, TCP takes a considerable amount of time to establish a connection: SYN\/ACK and TLS requests are handled separately, requiring three round trips instead of one, as is the case with QUIC.<\/p>\n

\"HTTP
\n
\nSince 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.<\/i>.<\/p>\n

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 \u2018neighbors\u2019, 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):<\/p>\n

\"HTTP
\n<\/p>\n

Using <\/h2>\n

\nOriginally, 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.<\/p>\n

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

\"HTTP
\n
\nHowever, QUIC can be implemented as a transport between the application and the server, as successfully demonstrated by Uber:<\/p>\n

\n

Uber's comment on implementing QUIC<\/i><\/h3>\n

\nTo 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<\/a><\/noindex> from Chromium Projects<\/a><\/noindex>, which contains the original Google version of the protocol \u2013 gQUIC. This implementation is also continuously improved to follow the latest IETF specification.<\/p>\n

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<\/a><\/noindex>, we integrated Cronet UNDER the OkHttp API framework. By performing the integration this way, we avoided changes to our network calls (which use Retrofit<\/a><\/noindex>) at the API level.<\/p>\n

Similarly to our approach with Android devices, we implemented Cronet in Uber's iOS applications by intercepting HTTP traffic using API<\/a><\/noindex>, using NSURLProtocol<\/a><\/noindex>. 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.<\/p><\/blockquote>\n

taken from this translation<\/a><\/noindex> of the Uber article<\/i><\/p>\n

On the backend, they handled QUIC connections through Google Cloud lb, which has supported the protocol<\/a><\/noindex> since mid-2018.<\/p>\n

It's not surprising that Google Cloud works excellently with a protocol developed by Google, but what alternatives are there?<\/p>\n

Nginx<\/h3>\n

\nNot long ago, CloudFlare attempted to combine<\/a><\/noindex> 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:<\/p>\n

curl -O https:\/\/nginx.org\/download\/nginx-1.16.1.tar.gz\ntar xvzf nginx-1.16.1.tar.gz\ngit clone --recursive https:\/\/github.com\/cloudflare\/quiche\ncd nginx-1.16.1\npatch -p01 < ..\/quiche\/extras\/nginx\/nginx-1.16.patch<\/code><\/pre>\n
\nHere, you can connect your modules if necessary<\/p>\n
.\/configure                          \t\n   \t--prefix=$PWD                       \t\n   \t--with-http_ssl_module              \t\n   \t--with-http_v2_module               \t\n   \t--with-http_v3_module               \t\n   \t--with-openssl=..\/quiche\/deps\/boringssl \n   \t--with-quiche=..\/quiche\n make<\/code><\/pre>\n
\nYou just need to enable HTTP\/3 support<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Enable QUIC and HTTP\/3.\n        listen 443 quic reuseport;\n\n        # Enable HTTP\/2 (optional).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Enable all TLS versions (TLSv1.3 is required for QUIC).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # Request buffering is not currently supported for HTTP\/3.\n        proxy_request_buffering off;\n\n        # Add Alt-Svc header to negotiate HTTP\/3.\n        add_header alt-svc 'h3-27=\"443\"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nIn regular browsers, it is not yet possible to connect via HTTP\/3, but you can take Chrome Canary<\/a><\/noindex> and run it with the flag --enable-quic<\/code>, connect to your server or, for instance, to the site quic.rocks and check the connection type in Developer Tools:
\n\"HTTP
\nInstead of HTTP\/3, it shows http2+quic\/99<\/code>, but essentially it's the same.<\/p>\n
Other technologies<\/h3>\n
<\/p>\n