🥇HTTP по UDP — използвайте с полза протокол QUIC

QUIC (Quick UDP Internet Connections) е протокол над UDP, който поддържа всички възможности на TCP, TLS и HTTP/2 и решава повечето от техните проблеми. Често го наричат нов или 'експериментален' протокол, но той отдавна е преминал етапа на експеримент: разработката му продължава повече от 7 години. През това време протоколът не успя да стане стандарт, но все пак получи широко разпространение. Например, QUIC се използва за ускоряване на трафика и намаляване на закъсненията в мобилните мрежи от гиганти като Google и Facebook, а IETF обяви неговия fork за основа на стандарта HTTP/3 (при условие, че HTTP/2 използва само 44,8% от сайтовете).

Концепция

QUIC е разработен като заместител на остарялото TCP, което първоначално е било настроено за жични мрежи с нисък процент загуби. TCP доставя пакетите последователно, така че при загуба на един пакет, цялата опашка спира (head-of-line blocking), което негативно се отразява на качеството и стабилността на връзката. За да се избегнат масови загуби, мобилните мрежи прибягват до използването на големи буфери, което от своя страна води до излишък и false negative реакция на протокола (bufferbloat). Освен това, TCP отделя много време за установяване на връзка: SYN/ACK и TLS заявки вървят отделно, изискващи три roundtrip-а вместо един, както прави QUIC.

Тъй като QUIC съчетава замяна на TCP и реализация на TLS 1.3, всички връзки винаги са криптирани, а разшифроването на такъв трафик не е по-лесно, отколкото ако преминава през HTTPS. Освен това, QUIC е реализиран на приложно ниво, тъй като пълната замяна на TCP стека би отнела вечност.

. Въпреки че поддържа мултиплексиране в HTTP/2, проблемът с head-of-line blocking там остава поради необходимостта пакетите да се доставят последователно. QUIC е реализиран над UDP, затова при него блокировките просто не съществуват, а за да се предотвратят загуби на пакети, те получават номерации и могат да съдържат части от 'съседите', осигурявайки излишък. Освен това, QUIC разделя монолитната опашка на няколко потока за различни типове заявки в рамките на една връзка. По този начин, при загуба на пакет, проблеми могат да възникнат единствено в една опашка (например, при предаване на конкретен файл):

Използването

Първоначално QUIC беше разработен вътре в Google и основно се фокусираше върху вътрешната употреба. През 2013 г. той беше предаден на IETF за стандартизация (която все още продължава), и сега всеки може да участва в развитието на протокола, предлагайки необходимите му подобрения. Работната група на IETF организира ежегодни срещи, на които се одобрява нов стандарт и се обсъждат нововъведения. Тази реализация на QUIC се счита за основна и именно на нейна база се сертифицира стандартът HTTP/3.

Все още не се говори за включването на HTTP/3 като основен протокол, тъй като той все още не е завършен и почти не се поддържа:

Но QUIC може да бъде реализиран като транспорт между приложението и сървъра, което успешно направиха в Uber:

Коментар на Uber относно внедряването на QUIC
За успешно интегриране на QUIC и подобряване на производителността на приложението при условия на лоша свързаност, ние заменихме стария стек (HTTP/2 върху TLS/TCP) с протокола QUIC. Използвахме мрежовата библиотека Cronet от Проекти на Chromium, която съдържа оригиналната, версия на протокола на Google – gQUIC. Тази реализация също така постоянно се усъвършенства, за да отговаря на последната спецификация на IETF.
Първо интегрирахме Cronet в нашите Android приложения, за да добавим поддръжка за QUIC. Интеграцията беше извършена по начин, който минимизира разходите по миграция. Вместо да заменим напълно стария мрежов стек, който използва библиотеката OkHttp, ние интегрирахме Cronet ПОД фреймворка OkHttp API. Чрез този подход избегнахме промени в нашите мрежови извиквания (които използват Retrofit) на ниво API.
По подобен начин с подхода към Android устройствата, интегрирахме Cronet в приложенията на Uber за iOS, прехващайки HTTP трафика от мрежовите API, използвайки NSURLProtocol. Тази абстракция, предоставена от iOS Foundation, обработва протокол-специфичните URL данни и гарантира, че можем да интегрираме Cronet в нашите iOS приложения без значителни миграционни разходи.

взето от този превод статия на Uber

На бекенда те улавяха QUIC връзки чрез Google Cloud lb, който поддържа протокола от средата на 2018 г.

Не е изненада, че Google Cloud прекрасно работи с протокола, разработен от Google, но какви са алтернативите?

Nginx

Скоро CloudFlare опита да комбинира nginx (който по подразбиране не поддържа HTTP/3) с инструмента Quiche. Реализацията е налична като един .patch файл, придружен от тук урок за инсталация:

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

Тук можете да добавите свои модули при необходимост

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

Остава само да активирате поддръжката на HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Активирайте QUIC и HTTP/3.
        listen 443 quic reuseport;

        # Активирайте HTTP/2 (по желание).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Активирайте всички TLS версии (TLSv1.3 е задължителен за QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Буферирането на заявки не е в момента поддържано за HTTP/3.
        proxy_request_buffering off;

        # Добавете Alt-Svc заглавие за преговори за HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

В обикновени браузъри свързването чрез HTTP/3 засега не е възможно, но можете да вземете Chrome Canary и да го стартирате с флага --enable-quic, да се свържете със своя сървър или например с сайта quic.rocks и да видите типа на свързването в Developer Tools:

Вместо HTTP/3 се пише http2+quic/99, но по същество е едно и също.

Други технологии

QUIC също поддържат LiteSpeed (които с голямо помпене се свързваха с Facebook чрез HTTP/3) и прогресивен Caddy. Apache все още не поддържа, но работата продължава с пълна пара.
На 21 януари беше обновен черновика на стандарта за WebRTC
Тъкмо преди дни Microsoft публикува кода на своята реализация msquic, в която все още не са налични всички функции от стандарта IETF, но това вече е голям напредък.

Заключение

Интересът към QUIC е нестабилен, но нараства, работи се по стандартизацията му. Нови реализации на протокола се появяват почти всеки месец, а с всяка година все повече разработчици се убеждават, че бъдещето е в QUIC. Допуска се дори включването на протокола в бъдещите версии на TCP стека, а това означава, че рано или късно целият интернет ще премине на по-устойчиви и бързи свързвания.

Вече сега можете да настроите QUIC взаимодействие за своята инфраструктура или дори да го предоставяте на браузъри — те всички планират да добавят поддръжка на протокола, а тъжната статистика с caniuse ще стане по-радостна.

Източник: habr.com