HTTP преку UDP - добро искористување на протоколот QUIC

HTTP преку UDP - добро искористување на протоколот QUIC

QUIC (Quick UDP Internet Connections) е протокол на врвот на UDP кој ги поддржува сите карактеристики на TCP, TLS и HTTP/2 и ги решава повеќето од нивните проблеми. Често се нарекува нов или „експериментален“ протокол, но одамна ја надживеа експерименталната фаза: развојот трае повеќе од 7 години. За тоа време, протоколот не успеа да стане стандард, но сепак стана широко распространет. На пример, QUIC се користи од такви гиганти како Google и Facebook за да се забрза сообраќајот и да се намалат одложувањата во мобилните мрежи, а IETF го прогласи својот дел од протоколот како основа за HTTP/3 стандардот (иако HTTP/2 користи само 44.8% сајтови).

Концепт

QUIC беше развиен како замена за наследениот TCP, кој првично беше дизајниран за жичени мрежи со мала загуба. TCP ги испорачува пакетите по ред, па ако еден пакет се изгуби, целата редица е запрена (блокирање на главата на линијата), што негативно влијае на квалитетот и стабилноста на врската. За да се избегнат огромни загуби, мобилните мрежи прибегнуваат кон користење на големи бафери, што пак доведува до вишок и лажно негативен одговор на протоколот (тампон). Покрај тоа, TCP троши многу време за воспоставување врска: SYN/ACK и TLS барањата одат одделно, барајќи три повратни патувања наместо едно, како што тоа го прави QUIC.

HTTP преку UDP - добро искористување на протоколот QUIC

Бидејќи QUIC комбинира замена на TCP и имплементација на TLS 1.3, сите конекции се секогаш шифрирани, а дешифрирањето на таквиот сообраќај не е полесно отколку ако се одвива преку HTTPS. Покрај тоа, QUIC се имплементира на ниво на апликација, бидејќи би била потребна целосна замена на оџакот TCP вечноста.

И покрај поддршката за мултиплексирање во HTTP/2, проблемот со блокирање на главната линија остана таму поради потребата да се доставуваат пакетите во ред. QUIC е имплементиран на врвот на UDP, така што во принцип нема блокирање, и за да се спречи засекогаш губење на пакетите, тие се нумерирани и можат да содржат делови од „соседи“, обезбедувајќи вишок. Покрај тоа, QUIC ја дели монолитната редица на повеќе нишки за различни типови на барања во рамките на една врска. Така, ако некој пакет се изгуби, може да се појават проблеми само за една редица (на пример, за пренос на одредена датотека):

HTTP преку UDP - добро искористување на протоколот QUIC

Користете

Првично, QUIC беше развиен во рамките на Google и беше во голема мера прилагоден за употреба во рамките на компанијата. Во 2013 година тој беше префрлен во IETF за стандардизација (која сè уште е во тек), а сега секој може да учествува во развојот на протоколот со предлагање на она што му недостасува. Работната група на IETF организира годишни состаноци за време на кои се одобрува нов стандард и се дискутира за иновациите. Оваа имплементација на QUIC се смета за главна и врз основа на неа е сертифициран стандардот HTTP/3.

Засега не се зборува за вклучување на HTTP/3 како главен протокол, бидејќи сè уште не е завршен и речиси не е поддржан:

HTTP преку UDP - добро искористување на протоколот QUIC

Но, QUIC може да се имплементира како транспорт помеѓу апликацијата и серверот, што беше успешно направено во Uber:

Коментарот на Uber за воведувањето на QUIC

За успешно вградување на QUIC и подобрување на перформансите на апликацијата во средини со слаба поврзаност, го заменивме стариот стек (HTTP/2 преку TLS/TCP) со протоколот QUIC. Ја користевме мрежната библиотека Кронет на Проекти на Chromium, кој ја содржи оригиналната, Google верзија на протоколот - gQUIC. Оваа имплементација, исто така, постојано се подобрува за да ја следи најновата спецификација на IETF.

Прво го интегриравме Cronet во нашите апликации за Android за да додадеме поддршка за QUIC. Интеграцијата беше спроведена на таков начин што ќе ги намали трошоците за миграција колку што е можно повеќе. Наместо целосно да се замени стариот мрежен стек што ја користеше библиотеката OkHttp, го интегриравме Cronet ПОД рамката OkHttp API. Правејќи ја интеграцијата на овој начин, избегнавме промени во нашите мрежни повици (кои ги користат Retrofit) на ниво на API.

Слично на пристапот за уредите со Android, го имплементиравме Cronet во Uber апликациите на iOS, пресретнувајќи HTTP сообраќај од мрежата APIкористејќи NSURLПротокол. Оваа апстракција, обезбедена од Фондацијата iOS, се справува со податоци за URL специфични за протоколот и гарантира дека можеме да го интегрираме Cronet во нашите iOS апликации без значителни трошоци за миграција.

земено од овој превод Убер статии

На задниот дел фатија 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 {
        # 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';
    }
}

Сè уште не е можно да се поврзете преку HTTP/3 во обичните прелистувачи, но можете да го користите Хром Канари и водете го со знамето --enable-quic, одете на вашиот сервер или, на пример, на страницата quic.rocks и погледнете го типот на врската во Алатки за програмери:
HTTP преку UDP - добро искористување на протоколот QUIC
Наместо HTTP/3 пишува http2+quic/99, но во суштина е иста работа.

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

  • Поддршка и QUIC LiteSpeed (кој се поврза на Facebook преку HTTP/3 со голема помпа) и прогресивен Caddy. Апачи сè уште не може да го направи тоа, но работата е во тек полн замав.
  • Ажурирано на 21 јануари нацрт стандард за WebRTC
  • Само пред некој ден се отвори Мајкрософт msquic код за имплементација, во кој сè уште не се достапни сите функции од стандардот IETF, но ова е веќе голем напредок.

Заклучок

HTTP преку UDP - добро искористување на протоколот QUIC

Интересот за QUIC е нестабилен, но расте и се работи на негова стандардизација. Нови имплементации на протоколот се појавуваат речиси секој месец, а секоја година се повеќе програмери се убедени дека QUIC е иднината. Дури е можно да се вклучи протоколот во идните верзии на стекот TCP, што значи дека порано или подоцна целиот Интернет ќе се префрли на постабилни и побрзи врски.

Веќе сега можете да ја конфигурирате интеракцијата QUIC за вашата инфраструктура или дури и да ја дадете на прелистувачите - сите тие планираат да додадат поддршка за протоколот, а тажната статистика со каниус ќе стане повесел.

HTTP преку UDP - добро искористување на протоколот QUIC

Извор: www.habr.com

Додадете коментар