HTTP super UDP - bone utiligante la QUIC-protokolon

HTTP super UDP - bone utiligante la QUIC-protokolon

QUIC (Rapidaj UDP-Interretaj Konektoj) estas protokolo al UDP, kiu subtenas ĉiujn funkciojn de TCP, TLS kaj HTTP/2 kaj solvas la plej multajn el iliaj problemoj. Ofte oni nomas ĝin nova aŭ "eksperimenta" protokolo, sed ĝi longe postvivis la eksperimentan etapon: evoluo daŭras pli ol 7 jarojn. Dum ĉi tiu tempo, la protokolo ne sukcesis fariĝi normo, sed ankoraŭ disvastiĝis. Ekzemple, QUIC estas uzata de tiaj gigantoj kiel Guglo kaj Facebook por akceli trafikon kaj redukti prokrastojn en movaj retoj, kaj la IETF deklaris ĝian forkon de la protokolo la bazo por la HTTP/3 normo (kvankam HTTP/2 uzas nur 44.8% retejoj).

Koncepto

QUIC estis evoluigita kiel anstataŭaĵo por la heredaĵo TCP, kiu estis origine dizajnita por malalt-perdaj kablaj retoj. TCP liveras pakaĵetojn en ordo, do se unu pakaĵeto estas perdita, la tuta vico estas ĉesigita (kap-de-linia blokado), kiu negative influas la kvaliton kaj stabilecon de la konekto. Por eviti amasajn perdojn, ĉelaj retoj recurre al uzado de grandaj bufroj, kio siavice kondukas al redundo kaj falsa negativa respondo de la protokolo (bufferbloat). Krome, TCP pasigas multan tempon por establi konekton: SYN/ACK kaj TLS-petoj estas procesitaj aparte, postulante tri rondveturojn anstataŭ unu, kiel faras QUIC.

HTTP super UDP - bone utiligante la QUIC-protokolon

Ĉar QUIC kombinas TCP-anstataŭaĵon kaj efektivigon de TLS 1.3, ĉiuj konektoj ĉiam estas ĉifritaj, kaj malĉifri tian trafikon ne estas pli facila ol se ĝi trairus HTTPS. Krome, QUIC estas efektivigita sur la aplikaĵnivelo, ĉar kompleta anstataŭaĵo de la TCP-stako bezonus eterneco.

Malgraŭ subteno por multipleksado en HTTP/2, la problemo de ĉef-de-linia blokado restis tie pro la bezono liveri pakaĵetojn en ordo. QUIC estas efektivigita aldone al UDP, do ĝi principe ne havas blokadon, kaj por malhelpi pakaĵetojn esti perditaj por ĉiam, ili estas numeritaj kaj povas enhavi partojn de "najbaroj", provizante redundon. Krome, QUIC dividas la monolitan atendovicon en plurajn fadenojn por malsamaj specoj de petoj ene de ununura ligo. Tiel, se pako estas perdita, problemoj povas ekesti nur por unu atendovico (ekzemple, por translokado de specifa dosiero):

HTTP super UDP - bone utiligante la QUIC-protokolon

Uzo

Komence, QUIC estis evoluigita ene de Guglo kaj estis plejparte adaptita por uzo ene de la firmao. En 2013, ĝi estis transdonita al la IETF por normigado (kiu ankoraŭ daŭras), kaj nun ĉiuj povas partopreni en la evoluo de la protokolo proponante tion, kion ili mankas. La laborgrupo de IETF organizas jarkunvenojn dum kiuj nova normo estas aprobita kaj novigoj estas diskutitaj. Ĉi tiu efektivigo de QUIC estas konsiderata la ĉefa kaj estas surbaze de tio, ke la normo HTTP/3 estas atestita.

Ĝis nun oni ne parolas pri inkludo de HTTP/3 kiel ĉefa protokolo, ĉar ĝi ankoraŭ ne estas finita kaj preskaŭ ne estas subtenata:

HTTP super UDP - bone utiligante la QUIC-protokolon

Sed QUIC povas esti efektivigita kiel transporto inter la aplikaĵo kaj la servilo, kio estis sukcese farita ĉe Uber:

La komento de Uber pri la enkonduko de QUIC

Por sukcese enkonstrui QUIC kaj plibonigi aplikaĵon en malbonaj konekteblecaj medioj, ni anstataŭigis la malnovan stakon (HTTP/2 super TLS/TCP) per la QUIC-protokolo. Ni uzis la retbibliotekon Kroneto el Kromaj Projektoj, kiu enhavas la originalan, Guglo-version de la protokolo - gQUIC. Ĉi tiu efektivigo ankaŭ estas konstante plibonigata por sekvi la plej novan specifon de IETF.

Ni unue integris Cronet en niajn Android-aplikaĵojn por aldoni subtenon por QUIC. Integriĝo estis farita tiel, ke kiel eble plej multe redukti la migrajn kostojn. Anstataŭ tute anstataŭigi la malnovan interkonektan stakon, kiu uzis la bibliotekon OkHttp, ni integris Cronet SUB la OkHttp API-kadro. Farante la integriĝon tiel, ni evitis ŝanĝojn al niaj retaj vokoj (kiuj estas uzataj de Reforigo) ĉe la API-nivelo.

Simile al la aliro por Android-aparatoj, ni efektivigis Cronet en Uber-aplikaĵojn en iOS, kaptante HTTP-trafikon de reto. APIuzante NSURLProtokolo. Ĉi tiu abstraktado, provizita de la iOS-Fondaĵo, pritraktas protokolan specifajn URL-datumojn kaj certigas, ke ni povas integri Cronet en niajn iOS-aplikaĵojn sen signifaj migraj kostoj.

prenita de ĉi tiu traduko Uber-artikoloj

Sur la malantaŭo ili kaptis QUIC-konektojn per Google Cloud lb, kiu subtenas protokolon ekde meze de 2018.

Ne estas surprizo, ke Google Cloud funkcias bonege kun la Guglo-evoluinta protokolo, sed kiuj estas la alternativoj?

Nginx

Antaŭ nelonge CloudFlare Mi provis transiri nginx (kiu ne subtenas HTTP/3 defaŭlte) per sia Quiche-ilo. La efektivigo disponeblas kiel ununura .patch-dosiero, kiu venas kun instala lernilo:

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

Ĉi tie vi povas konekti viajn modulojn se necese

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

Restas nur ebligi HTTP/3-subtenon

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';
    }
}

Ankoraŭ ne eblas konekti per HTTP/3 en regulaj retumiloj, sed vi povas uzi Chrome Kanario kaj kuru ĝin kun la flago --enable-quic, iru al via servilo aŭ, ekzemple, la retejo quic.rocks kaj rigardu la konekton en Iloj por Programistoj:
HTTP super UDP - bone utiligante la QUIC-protokolon
Anstataŭ HTTP/3 ĝi estas skribita http2+quic/99, sed ĝi estas esence la sama afero.

Aliaj teknologioj

  • QUIC ankaŭ subteno LiteSpeed (kiu konektita al Fejsbuko per HTTP/3 kun granda fanfaro) kaj progresema caddy. Apache ankoraŭ ne povas fari ĝin, sed laboro estas daŭranta plena svingo.
  • La 21-an de januaro ĝisdatigita skizo normo por WebRTC
  • Ĝuste la alian tagon Microsoft malfermiĝis msquic efektiviga kodo, en kiu ne ĉiuj funkcioj de la IETF-normo ankoraŭ haveblas, sed ĉi tio jam estas granda sukceso.

konkludo

HTTP super UDP - bone utiligante la QUIC-protokolon

Intereso pri QUIC estas malstabila, sed kreskas, kaj laboroj por normigi ĝin. Novaj efektivigoj de la protokolo aperas preskaŭ ĉiumonate, kaj ĉiujare pli kaj pli da programistoj estas konvinkitaj, ke QUIC estas la estonteco. Eblas eĉ inkluzivi la protokolon en estontaj versioj de la TCP-stako, kio signifas, ke pli aŭ malpli frue la tuta Interreto moviĝos al pli stabilaj kaj pli rapidaj konektoj.

Jam nun vi povas agordi QUIC-interago por via infrastrukturo aŭ eĉ doni ĝin al retumiloj - ili ĉiuj planas aldoni subtenon por la protokolo, kaj la malĝoja statistiko kun caniuse fariĝos pli gaja.

HTTP super UDP - bone utiligante la QUIC-protokolon

fonto: www.habr.com

Aldoni komenton