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

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

Концепцията

QUIC е разработен като замяна на остарелия TCP, който първоначално беше проектиран за проводникови мрежи с нисък процент на загуби. TCP доставя пакетите в ред, така че при загуба на един пакет цялата опашка се блокира (head-of-line blocking), което негативно влияе на качеството и стабилността на връзката. За да се избегнат масови загуби, мобилните мрежи прибягват до използването на големи буфери, което от своя страна води до излишъци и фалшиви негативни реакции на протокола (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 Projects, която съдържа оригиналната, версионната версия на протокола - 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 ще стане по-радостна.

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

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