HTTP/3: Opțiuni practice de implementare (Partea 3)

Bună ziua și bun venit la ultima parte a acestei serii de trei părți despre noile protocoale HTTP/3 și QUIC! Dacă după cele două părți anterioare — istoricul HTTP/3 și conceptele de bază și caracteristicile de performanță HTTP/3 — ești convins că începerea utilizării noilor protocoale este o idee bună (și ar trebui să fii!), atunci această piesă finală include toate trebuie să știi pentru a începe!

Mai întâi, vom discuta ce modificări trebuie să faceți paginilor și resurselor dvs. pentru a utiliza în mod optim noile protocoale (aceasta este partea ușoară). În continuare, ne vom uita la cum să configurați servere și clienți (aceasta este partea grea, dacă nu utilizați o rețea de livrare de conținut (CDN)). În cele din urmă, vom vedea ce instrumente puteți folosi pentru a evalua impactul asupra performanței noilor protocoale (aceasta este partea aproape imposibilă, cel puțin deocamdată).

Modificări ale paginilor și resurselor

Să începem cu câteva vești bune: dacă sunteți deja pe HTTP/2, probabil că nu va trebui să schimbați nimic în paginile sau resursele dvs. când treceți la HTTP/3! . Acest lucru se datorează faptului că, așa cum am explicat în partea 1 și partea 2, HTTP/3 seamănă mai mult cu HTTP/2-over-QUIC, iar caracteristicile de nivel înalt ale celor două versiuni au rămas aceleași. Ca atare, orice modificări sau optimizări făcute pentru HTTP/2 vor funcționa în continuare pentru HTTP/3 și invers.

Cu toate acestea, dacă încă sunteți pe HTTP/1.1 sau ați uitat de tranziția la HTTP/2 sau nu ați modificat niciodată lucrurile pentru HTTP/2, atunci s-ar putea să vă întrebați care au fost acele modificări și de ce au fost necesare. Cu toate acestea, chiar și astăzi ar fi greu să găsiți un articol bun care să detalieze cele mai bune practici nuanțate . Acest lucru se datorează faptului că, așa cum am afirmat în introducerea părții 1, o mare parte din conținutul HTTP/2 timpuriu era prea optimist cu privire la cât de bine ar funcționa în practică, iar unele dintre ele, sincer, aveau greșeli majore și sfaturi proaste. Din păcate, o mare parte din această dezinformare persistă astăzi. Aceasta este una dintre principalele mele motivații în scrierea acestei serii pe HTTP/3, pentru a preveni ca acest lucru să se repete.

Cea mai bună sursă nuanțată all-in-one pentru HTTP/2 pe care o pot recomanda în acest moment este cartea HTTP/2 în acțiune de Barry Pollard. Cu toate acestea, deoarece aceasta este o resursă plătită și nu vreau să fiți lăsat să ghiciți aici, am enumerat câteva dintre punctele principale de mai jos, împreună cu modul în care se leagă de HTTP/3:

1. Conexiune unică

Cea mai mare diferență între HTTP/1.1 și HTTP/2 a fost trecerea de la 6 la 30 de conexiuni TCP paralele la o singură conexiune TCP subiacentă. Am discutat puțin în partea 2 despre cum o singură conexiune poate fi în continuare la fel de rapidă ca și conexiunile multiple, din cauza modului în care controlul congestiei poate provoca pierderi mai mari sau mai devreme de pachete cu mai multe conexiuni (ceea ce anulează beneficiile pornirii lor agregate mai rapide). HTTP/3 continuă această abordare, dar „doar” trece de la o conexiune TCP la una QUIC. Această diferență în sine nu face atât de mult (reduce în principal supraîncărcarea pe partea serverului), dar duce la majoritatea punctelor următoare.

2. Partajarea serverului și coalescerea conexiunii

Trecerea la configurarea unei singure conexiuni a fost destul de dificilă în practică, deoarece multe pagini au fost împărțite pe diferite nume de gazdă și chiar pe servere (cum ar fi img1.example.com și img2.example.com ). Acest lucru se datorează faptului că browserele au deschis doar până la șase conexiuni pentru fiecare nume de gazdă individual, deci fiind permise mai multe conexiuni! Fără modificări ale acestei configurații HTTP/1.1, HTTP/2 ar deschide în continuare mai multe conexiuni, reducând cât de bine ar putea funcționa efectiv alte caracteristici, cum ar fi prioritizarea (vezi mai jos).

Ca atare, recomandarea inițială a fost de a anula fragmentarea serverului și de a consolida resursele pe un singur server cât mai mult posibil. HTTP/2 a oferit chiar și o caracteristică pentru a face tranziția de la o configurare HTTP/1.1 mai ușoară, numită coalescere a conexiunii. În linii mari, dacă două nume de gazdă se rezolvă la aceeași IP de server (folosind DNS) și utilizează un certificat TLS similar, atunci browserul poate reutiliza o singură conexiune chiar și între cele două nume de gazdă .

În practică, coalescerea conexiunii poate fi dificil de realizat, de exemplu din cauza mai multor probleme subtile de securitate care implică CORS. Chiar dacă îl configurați corect, puteți ajunge cu ușurință la două conexiuni separate. Chestia este că nu este întotdeauna rău . În primul rând, din cauza prioritizării și multiplexării prost implementate (vezi mai jos), conexiunea unică ar putea fi cu ușurință mai lentă decât utilizarea a două sau mai multe. În al doilea rând, folosirea prea multor conexiuni ar putea cauza pierderea timpurie a pachetelor din cauza controlorilor de congestie concurenți. Folosind doar câteva (dar totuși mai mult de unul), totuși, ar putea echilibra frumos creșterea congestiei cu performanțe mai bune, în special în rețelele de mare viteză. Din aceste motive, cred că un pic de sharding este încă o idee bună (să zicem, două până la patru conexiuni), chiar și cu HTTP/2. De fapt, cred că majoritatea configurațiilor moderne HTTP/2 funcționează la fel de bine ca ele, deoarece mai au câteva conexiuni suplimentare sau încărcări de la terți în calea lor critică.

3. Gruparea resurselor și integrarea

În HTTP/1.1, puteți avea doar o singură resursă activă per conexiune, ceea ce duce la blocarea head-of-line (HoL) la nivel HTTP. Deoarece numărul de conexiuni a fost limitat la 6 până la 30, gruparea resurselor (unde subresursele mai mici sunt combinate într-o singură resursă mai mare) a fost o bună practică de lungă durată. Vedem și astăzi acest lucru în bundlere precum Webpack. În mod similar, resursele au fost adesea integrate în alte resurse (de exemplu, CSS critic a fost introdus în HTML).

Cu HTTP/2, totuși, o singură conexiune multiplexează resurse, astfel încât să puteți avea mult mai multe solicitări restante pentru fișiere (spus altfel, o singură solicitare nu mai ocupă una dintre puținele voastre conexiuni prețioase). Acest lucru a fost interpretat inițial ca: „ Nu mai trebuie să ne grupăm sau să integrăm resursele pentru HTTP/2 ”. Această abordare a fost promovată a fi mai bună pentru stocarea în cache cu granulație fină, deoarece fiecare subresursă ar putea fi memorată în cache individual și pachetul complet nu a trebuit să fie redescărcat dacă una dintre ele se schimba. Acest lucru este adevărat, dar doar într-o măsură relativ limitată.

De exemplu, puteți reduce eficiența compresiei, deoarece aceasta funcționează mai bine cu mai multe date. În plus, fiecare cerere sau fișier suplimentar are o suprasarcină inerentă, deoarece trebuie gestionată de browser și server. Aceste costuri se pot ridica, de exemplu, pentru sute de fișiere mici, comparativ cu câteva mari. În propriile noastre teste timpurii, am găsit randamente în scădere serioasă la aproximativ 40 de fișiere. Deși aceste numere sunt probabil puțin mai mari acum, solicitările de fișiere nu sunt încă la fel de ieftine în HTTP/2 așa cum se prevedea inițial . În cele din urmă, resursele care nu sunt integrate au un cost suplimentar de latență, deoarece fișierul trebuie solicitat. Acest lucru, combinat cu problemele de prioritizare și de împingere a serverului (vezi mai jos), înseamnă că și astăzi este mai bine să introduceți o parte din CSS-ul dvs. critic. Poate că într-o zi propunerea pachetelor de resurse va ajuta în acest sens, dar nu încă.

Toate acestea sunt, desigur, valabile și pentru HTTP/3. Totuși, am citit că oamenii susțin că multe fișiere mici ar fi mai bune față de QUIC, deoarece mai multe fluxuri independente active simultan înseamnă mai multe profituri din eliminarea blocării HoL (așa cum am discutat în partea 2). Cred că ar putea exista ceva adevăr în acest lucru, dar, așa cum am văzut și în partea 2, aceasta este o problemă extrem de complexă, cu o mulțime de parametri în mișcare. Nu cred că beneficiile ar depăși celelalte costuri discutate, dar sunt necesare mai multe cercetări. (Un gând revoltător ar fi ca fiecare fișier să fie dimensionat exact pentru a se încadra într-un singur pachet QUIC, ocolind complet blocarea HoL. Voi accepta drepturi de autor de la orice startup care implementează un pachet de resurse care face acest lucru. ;))

4. Prioritizare

Pentru a putea descărca mai multe fișiere pe o singură conexiune, trebuie să le multiplexați cumva. După cum sa discutat în partea 2, în HTTP/2, această multiplexare este condusă folosind sistemul său de prioritizare. Acesta este motivul pentru care este important să aveți cât mai multe resurse solicitate și pe aceeași conexiune - pentru a le putea prioritiza în mod corespunzător între ele! După cum am văzut, totuși, acest sistem era foarte complex , ceea ce face ca acesta să fie adesea prost folosit și implementat în practică (vezi imaginea de mai jos). Acest lucru, la rândul său, a însemnat că alte recomandări pentru HTTP/2 - cum ar fi gruparea redusă, deoarece cererile sunt ieftine și fragmentarea redusă a serverului, pentru a utiliza în mod optim conexiunea unică (vezi mai sus) - s-au dovedit a avea performanțe slabe în practică.

Din păcate, acesta este ceva despre care tu, ca dezvoltator web obișnuit, nu poți face mare lucru, deoarece este în principal o problemă în browserele și serverele în sine. Cu toate acestea, puteți încerca să atenuați problema nefolosind prea multe fișiere individuale (ceea ce va reduce șansele pentru priorități concurente) și utilizând în continuare fragmentarea (limitată). O altă opțiune este să utilizați diferite tehnici de influență a priorităților, cum ar fi încărcare leneră, JavaScript async și defer și sugestii de resurse, cum ar fi preload . Pe plan intern, acestea modifică în principal prioritățile resurselor, astfel încât acestea să fie trimise mai devreme sau mai târziu. Cu toate acestea, aceste mecanisme pot (și suferă) de bug-uri. În plus, nu vă așteptați să puneți o preload pe o mulțime de resurse și să faceți lucrurile mai repede: dacă totul este dintr-o dată o prioritate ridicată, atunci nimic nu este! Este chiar foarte ușor să întârziești resursele critice folosind lucruri precum preload .

După cum s-a explicat și în partea 2, HTTP/3 schimbă fundamental elementele interne ale acestui sistem de prioritizare. Sperăm că acest lucru înseamnă că vor exista mai puține erori și probleme cu implementarea sa practică, așa că cel puțin unele dintre acestea ar trebui rezolvate. Cu toate acestea, nu putem fi siguri încă, deoarece puține servere și clienți HTTP/3 implementează pe deplin acest sistem astăzi. Cu toate acestea, conceptele fundamentale ale prioritizării nu se vor schimba . Tot nu veți putea folosi tehnici precum preload fără a înțelege cu adevărat ce se întâmplă în interior, deoarece s-ar putea să vă prioritizeze greșit resursele.

5. Server Push și primul zbor

Server push permite unui server să trimită date de răspuns fără a aștepta mai întâi o solicitare din partea clientului. Din nou, acest lucru sună grozav în teorie și ar putea fi folosit în loc de resurse integrate (vezi mai sus). Cu toate acestea, așa cum sa discutat în partea 2, push este foarte dificil de utilizat corect din cauza problemelor legate de controlul congestiei, memorarea în cache, prioritizarea și stocarea tampon. În general, este mai bine să nu îl utilizați pentru încărcarea generală a paginilor web decât dacă știți cu adevărat ce faceți și, chiar și atunci, probabil ar fi o micro-optimizare. Totuși, cred că ar putea avea un loc cu API-uri (REST), unde puteți împinge subresurse legate în răspunsul (JSON) pe o conexiune încălzită. Acest lucru este valabil atât pentru HTTP/2, cât și pentru HTTP/3.

Pentru a generaliza puțin, consider că s-ar putea face remarci similare pentru reluarea sesiunii TLS și 0-RTT, fie prin TCP + TLS sau prin QUIC. După cum s-a discutat în partea 2, 0-RTT este similar cu server push (așa cum este folosit de obicei) prin aceea că încearcă să accelereze primele etape ale încărcării unei pagini. Cu toate acestea, asta înseamnă că este la fel de limitat în ceea ce poate realiza în acel moment (cu atât mai mult în QUIC, din cauza preocupărilor de securitate). Ca atare, o micro-optimizare este, din nou, modul în care probabil trebuie să reglați lucrurile la un nivel scăzut pentru a beneficia cu adevărat de ea. Și să cred că odată am fost foarte încântat să încerc să combin server push cu 0-RTT.

Ce înseamnă totul?

Toate cele de mai sus se rezumă la o simplă regulă generală: aplicați majoritatea recomandărilor tipice HTTP/2 pe care le găsiți online, dar nu le duceți la extrem .

Iată câteva puncte concrete care sunt valabile în principal atât pentru HTTP/2, cât și pentru HTTP/3:

1. Distribuiți resursele pe aproximativ una până la trei conexiuni pe calea critică (cu excepția cazului în care utilizatorii dvs. sunt în mare parte pe rețele cu lățime de bandă redusă), folosind preconnect și dns-prefetch acolo unde este necesar.
2. Agrupați subresurse în mod logic pe cale sau caracteristică sau pe frecvență de schimbare. Cinci până la zece resurse JavaScript și cinci până la zece resurse CSS pe pagină ar trebui să fie bine. Introducerea CSS-ului critic poate fi încă o optimizare bună.
3. Utilizați funcții complexe, cum ar fi preload , cu moderație.
4. Utilizați un server care acceptă corect prioritizarea HTTP/2. Pentru HTTP/2, recomand H2O. Apache și NGINX sunt în mare parte OK (deși ar putea face mai bine), în timp ce Node.js trebuie evitat pentru HTTP/2. Pentru HTTP/3, lucrurile sunt mai puțin clare în acest moment (vezi mai jos).
5. Asigurați-vă că TLS 1.3 este activat pe serverul dvs. web HTTP/2.

După cum puteți vedea, deși departe de a fi simplă, optimizarea paginilor pentru HTTP/3 (și HTTP/2) nu este știință rachetă. Ceea ce va fi mai dificil, însă, este configurarea corectă a serverelor, clienților și instrumentelor HTTP/3.

Servere și rețele

După cum probabil ați înțeles până acum, QUIC și HTTP/3 sunt protocoale destul de complexe. Implementarea lor de la zero ar presupune citirea (și înțelegerea!) a sute de pagini răspândite pe mai mult de șapte documente. Din fericire, mai multe companii au lucrat la implementări open-source QUIC și HTTP/3 de peste cinci ani, așa că avem mai multe opțiuni mature și stabile din care să alegem.

Unele dintre cele mai importante și stabile includ următoarele:

Cu toate acestea, multe (poate cele mai multe) dintre aceste implementări se ocupă în principal de chestiile HTTP/3 și QUIC; nu sunt cu adevărat servere web cu drepturi depline . Când vine vorba de serverele dvs. tipice (gândiți-vă la NGINX, Apache, Node.js), lucrurile au fost puțin mai lente, din mai multe motive. În primul rând, câțiva dintre dezvoltatorii lor au fost implicați cu HTTP/3 de la început, iar acum trebuie să joace catch-up. Mulți ocolesc acest lucru folosind una dintre implementările enumerate mai sus intern ca biblioteci, dar chiar și această integrare este dificilă.

În al doilea rând, multe servere depind de biblioteci TLS terțe, cum ar fi OpenSSL. Acest lucru se datorează, din nou, pentru că TLS este foarte complex și trebuie să fie sigur, așa că cel mai bine este să reutilizați munca existentă, verificată. Cu toate acestea, în timp ce QUIC se integrează cu TLS 1.3, îl folosește în moduri mult diferite de modul în care interacționează TLS și TCP . Aceasta înseamnă că bibliotecile TLS trebuie să furnizeze API-uri specifice QUIC, lucru pe care dezvoltatorii lor au fost mult timp reticenți sau lenți să le facă. Problema aici este în special OpenSSL, care a amânat suportul QUIC, dar este folosit și de multe servere. Această problemă s-a înrăutățit atât de mult încât Akamai a decis să înceapă un fork specific QUIC al OpenSSL, numit quictls. În timp ce există alte opțiuni și soluții alternative, suportul TLS 1.3 pentru QUIC este încă un blocant pentru multe servere și este de așteptat să rămână așa pentru ceva timp.

Urmează o listă parțială de servere web complete pe care ar trebui să le puteți utiliza imediat, împreună cu suportul lor actual HTTP/3:

• Apache
  Suportul este neclar în acest moment. Nu s-a anunțat nimic. Probabil că are nevoie și de OpenSSL. (Totuși, rețineți că există o implementare Apache Traffic Server.)
• NGINX
  Aceasta este o implementare personalizată. Acesta este relativ nou și încă extrem de experimental. Este de așteptat să fie fuzionat cu NGINX principal până la sfârșitul anului 2021. Acesta este relativ nou și încă extrem de experimental. Rețineți că există un patch pentru a rula biblioteca quiche a Cloudflare și pe NGINX, care este probabil mai stabilă pentru moment.
• Node.js
  Aceasta folosește biblioteca ngtcp2 intern. Este blocat de progresul OpenSSL, deși intenționează să treacă la QUIC-TLS fork pentru a face ceva să funcționeze mai devreme.
• IIS
  Suportul este neclar în acest moment și nu a fost anunțat nimic. Totuși, probabil va folosi biblioteca MsQuic intern.
• Hipercorn
  Aceasta integrează aioquic, cu suport experimental.
• Caddy
  Aceasta folosește Quick-go, cu suport complet.
• H2O
  Acesta se folosește rapid, cu suport complet.
• Litespeed
  Aceasta folosește LSQUIC, cu suport complet.

Rețineți câteva nuanțe importante:

• Chiar și „sprijinul complet” înseamnă „atât de bun cum este în acest moment”, nu neapărat „gata de producție”. De exemplu, multe implementări nu acceptă încă pe deplin migrarea conexiunii, 0-RTT, server push sau prioritizarea HTTP/3 .
• Alte servere care nu sunt listate, cum ar fi Tomcat, nu au făcut încă niciun anunț (din cunoștințele mele).
• Dintre serverele web enumerate, doar Litespeed, patch-ul NGINX de la Cloudflare și H2O au fost realizate de oameni strâns implicați în standardizarea QUIC și HTTP/3, astfel încât acestea sunt cel mai probabil să funcționeze cel mai devreme.
  

După cum puteți vedea, peisajul serverului nu este încă pe deplin acolo, dar cu siguranță există deja opțiuni pentru configurarea unui server HTTP/3. Cu toate acestea, pur și simplu rularea serverului este doar primul pas. Configurarea acestuia și a restului rețelei este mai dificilă.

Configurarea Rețelei

După cum sa explicat în partea 1, QUIC rulează peste protocolul UDP pentru a facilita implementarea. Acest lucru, totuși, înseamnă în principal doar că majoritatea dispozitivelor de rețea pot analiza și înțelege UDP. Din păcate, asta nu înseamnă că UDP este permis universal . Deoarece UDP este adesea folosit pentru atacuri și nu este esențial pentru munca de zi cu zi normală în afară de DNS, multe rețele (corporate) și firewall-uri blochează aproape în întregime protocolul. Ca atare, probabil că UDP trebuie să fie permis în mod explicit către/de la serverele dvs. HTTP/3 . QUIC poate rula pe orice port UDP, dar se așteaptă ca portul 443 (care este de obicei folosit și pentru HTTPS peste TCP) să fie cel mai comun.

Cu toate acestea, mulți administratori de rețea nu vor dori să permită doar UDP en-gros. În schimb, vor dori în mod special să permită QUIC peste UDP. Problema este că, după cum am văzut, QUIC este aproape în întregime criptat. Acestea includ metadate la nivel QUIC, cum ar fi numerele de pachete, dar și, de exemplu, semnale care indică închiderea unei conexiuni. Pentru TCP, firewall-urile urmăresc în mod activ toate aceste metadate pentru a verifica comportamentul așteptat. (Am văzut o strângere de mână completă înainte de pachetele care transportă date? Urmează pachetele modele așteptate? Câte conexiuni deschise există?) După cum am văzut în partea 1, acesta este exact unul dintre motivele pentru care TCP nu mai este practic evolutiv. Cu toate acestea, datorită criptării QUIC, firewall-urile pot face mult mai puțin din această logică de urmărire la nivel de conexiune , iar câțiva biți pe care îi pot inspecta sunt relativ complexi.

Ca atare, mulți furnizori de firewall recomandă blocarea QUIC până când își pot actualiza software-ul. Chiar și după aceea, totuși, multe companii ar putea să nu dorească să-l permită, deoarece suportul QUIC pentru firewall va fi întotdeauna mult mai mic decât caracteristicile TCP cu care sunt obișnuiți.

Toate acestea sunt și mai complicate de caracteristica de migrare a conexiunii. După cum am văzut, această caracteristică permite conexiunea să continue de la o nouă adresă IP fără a fi nevoie să efectueze o nouă strângere de mână, prin utilizarea ID-urilor de conexiune (CID). Cu toate acestea, pentru firewall, aceasta va arăta ca și cum o nouă conexiune este folosită fără a utiliza mai întâi o strângere de mână, care ar putea fi la fel de bine un atacator care trimite trafic rău intenționat. Firewall-urile nu pot folosi doar CID-urile QUIC, deoarece se schimbă și în timp pentru a proteja confidențialitatea utilizatorilor! Ca atare, va fi nevoie ca serverele să comunice cu firewall-ul despre care sunt așteptate CID-uri , dar niciunul dintre aceste lucruri nu există încă.

Există preocupări similare pentru echilibratoarele de încărcare pentru configurații la scară mai mare. Aceste mașini distribuie conexiunile de intrare pe un număr mare de servere back-end. Traficul pentru o singură conexiune trebuie, desigur, întotdeauna direcționat către același server back-end (ceilalți nu ar ști ce să facă cu el!). Pentru TCP, acest lucru s-ar putea face pur și simplu pe baza 4-tuplului, deoarece asta nu se schimbă niciodată. Cu migrarea conexiunii QUIC, totuși, aceasta nu mai este o opțiune. Din nou, serverele și echilibratorii de încărcare vor trebui să convină cumva asupra CID-urilor să aleagă pentru a permite rutarea deterministă . Spre deosebire de configurația firewall, totuși, există deja o propunere de a configura acest lucru (deși acest lucru este departe de a fi implementat pe scară largă).

În cele din urmă, există și alte considerente de securitate de nivel superior, în principal în jurul atacurilor 0-RTT și a atacurilor distribuite de refuzare a serviciului (DDoS). După cum sa discutat în partea 2, QUIC include deja câteva atenuări pentru aceste probleme, dar în mod ideal, vor folosi și linii suplimentare de apărare în rețea. De exemplu, serverele proxy sau edge ar putea bloca anumite solicitări 0-RTT să ajungă la back-end-urile reale pentru a preveni atacurile de reluare. Alternativ, pentru a preveni atacurile de reflexie sau atacurile DDoS care trimit doar primul pachet de strângere de mână și apoi nu mai răspund (numit SYN flood în TCP), QUIC include caracteristica de reîncercare. Acest lucru permite serverului să valideze că este un client bine comportat, fără a fi nevoie să păstreze nicio stare între timp (echivalentul cookie-urilor TCP SYN). Acest proces de reîncercare are loc cel mai bine, desigur, undeva înaintea serverului back-end - de exemplu, la echilibrarea încărcăturii. Din nou, acest lucru necesită o configurare și o comunicare suplimentară, totuși.

Acestea sunt doar cele mai importante probleme pe care administratorii de rețea și de sistem le vor avea cu QUIC și HTTP/3. Mai sunt câteva, dintre care unele am vorbit. Există, de asemenea, două documente de însoțire separate pentru RFC-urile QUIC care discută aceste probleme și posibilele lor atenuări (parțiale).

Ce înseamnă totul?

HTTP/3 și QUIC sunt protocoale complexe care se bazează pe o mulțime de echipamente interne. Nu toate acestea sunt încă pregătite pentru prime time , deși aveți deja câteva opțiuni pentru a implementa noile protocoale pe back-end-urile dvs. Cu toate acestea, va dura probabil câteva luni până la chiar ani pentru ca cele mai importante servere și biblioteci subiacente (cum ar fi OpenSSL) să fie actualizate.

Chiar și atunci, configurarea corectă a serverelor și a altor intermediari de rețea, astfel încât protocoalele să poată fi utilizate într-o manieră sigură și optimă, nu va fi banală în configurațiile la scară mai mare. Veți avea nevoie de o echipă bună de dezvoltare și operațiuni pentru a face corect această tranziție.

Ca atare, mai ales în primele zile, probabil că cel mai bine este să vă bazați pe o companie mare de găzduire sau pe CDN pentru a configura și configura protocoalele pentru dvs. După cum sa discutat în partea 2, acolo este cel mai probabil că QUIC va plăti oricum, iar utilizarea unui CDN este una dintre optimizările cheie ale performanței pe care le puteți face. Personal, aș recomanda utilizarea Cloudflare sau Fastly, deoarece au fost strâns implicați în procesul de standardizare și vor avea cele mai avansate și bine reglate implementări disponibile.

Clienți și QUIC Discovery

Până acum, am luat în considerare suportul pe server și în rețea pentru noile protocoale. Cu toate acestea, mai multe probleme trebuie depășite și din partea clientului.

Înainte de a ajunge la asta, să începem cu câteva vești bune: majoritatea browserelor populare au deja suport (experimental) HTTP/3! Mai exact, la momentul scrierii, iată starea suportului (vezi și caniuse.com):

• Google Chrome (versiunea 91+) : activat implicit.
• Mozilla Firefox (versiunea 89+) : activat implicit.
• Microsoft Edge (versiunea 90+) : activat implicit (folosește Chromium intern).
• Opera (versiunea 77+) : activată implicit (folosește Chromium intern).
• Apple Safari (versiunea 14) : în spatele unui steag manual. Va fi activat implicit în versiunea 15, care este în prezent în previzualizarea tehnologiei.
• Alte browsere : Încă nu sunt semnale de care să fiu conștient (deși alte browsere care folosesc Chromium intern, cum ar fi Brave, ar putea, teoretic, să înceapă să-l activeze).

Rețineți câteva nuanțe:

• Majoritatea browserelor se lansează treptat, prin care nu toți utilizatorii vor primi suportul HTTP/3 activat în mod implicit de la început. Acest lucru se face pentru a limita riscurile ca o singură eroare trecută cu vederea să afecteze mulți utilizatori sau ca implementările de server să devină supraîncărcate. Ca atare, există o mică șansă ca, chiar și în versiunile recente de browser, să nu obțineți HTTP/3 în mod implicit și să fie necesar să îl activați manual.
• Ca și în cazul serverelor, suportul HTTP/3 nu înseamnă că toate caracteristicile au fost implementate sau sunt utilizate în acest moment. În special, 0-RTT, migrarea conexiunii, împingerea serverului, compresia dinamică a antetului QPACK și prioritizarea HTTP/3 ar putea să lipsească, să fie dezactivate, utilizate cu moderație sau configurate prost.
• Dacă doriți să utilizați HTTP/3 la nivelul clientului în afara browserului (de exemplu, în aplicația nativă), atunci ar trebui să integrați una dintre bibliotecile enumerate mai sus sau să utilizați cURL. Apple va aduce în curând suport nativ HTTP/3 și QUIC în bibliotecile sale de rețea încorporate pe macOS și iOS, iar Microsoft adaugă QUIC la kernel-ul Windows și mediul lor .NET, dar suport nativ similar nu a fost (din cunoștințele mele) anunțat pentru alte sisteme precum Android.

Alt-Svc

Chiar dacă ați configurat un server compatibil HTTP/3 și utilizați un browser actualizat, ați putea fi surprins să descoperiți că HTTP/3 nu este de fapt utilizat în mod consecvent . Pentru a înțelege de ce, să presupunem că sunteți browserul pentru un moment. Utilizatorul dvs. v-a cerut să navigați la example.com (un site web pe care nu l-ați mai vizitat până acum) și ați folosit DNS pentru a rezolva acest lucru la un IP. Trimiteți unul sau mai multe pachete de handshake QUIC la acel IP. Acum mai multe lucruri pot merge prost:

1. Este posibil ca serverul să nu accepte QUIC.
2. Una dintre rețelele intermediare sau firewall-urile ar putea bloca complet QUIC și/sau UDP.
3. Pachetele de strângere de mână se pot pierde în tranzit.

Totuși, de unde ați ști (care) una dintre aceste probleme a apărut ? În toate cele trei cazuri, nu veți primi niciodată un răspuns la pachetele de strângere de mână. Singurul lucru pe care îl puteți face este să așteptați, în speranța că ar putea primi un răspuns. Apoi, după un timp de așteptare (timeout), puteți decide că există într-adevăr o problemă cu HTTP/3. În acel moment, veți încerca să deschideți o conexiune TCP la server, în speranța că HTTP/2 sau HTTP/1.1 va funcționa.

După cum puteți vedea, acest tip de abordare ar putea introduce întârzieri majore, mai ales în anii inițiali, când multe servere și rețele nu vor accepta încă QUIC. O soluție ușoară, dar naivă, ar fi pur și simplu să deschideți atât o conexiune QUIC, cât și o conexiune TCP în același timp și apoi să utilizați orice strângere de mână finalizată mai întâi . Această metodă se numește „curse de conexiune” sau „globi oculari fericiți”. Deși acest lucru este cu siguranță posibil, are cheltuieli generale considerabile. Chiar dacă conexiunea care se pierde este aproape imediat închisă, totuși ocupă ceva memorie și timp CPU atât pe client, cât și pe server (mai ales când se utilizează TLS). În plus, există și alte probleme cu această metodă care implică rețelele IPv4 versus IPv6 și atacurile de reluare discutate anterior (pe care discuția mea le acoperă mai detaliat).

Ca atare, pentru QUIC și HTTP/3, browserele preferă să joace în siguranță și să încerce QUIC doar dacă știu că serverul îl acceptă . Ca atare, prima dată când un nou server este contactat, browserul va folosi numai HTTP/2 sau HTTP/1.1 printr-o conexiune TCP. Serverul poate spune browserului că acceptă și HTTP/3 pentru conexiunile ulterioare. Acest lucru se face prin setarea unui antet HTTP special pe răspunsurile trimise înapoi prin HTTP/2 sau HTTP/1.1. Acest antet se numește Alt-Svc , care înseamnă „servicii alternative”. Alt-Svc poate fi folosit pentru a informa un browser că un anumit serviciu este accesibil și prin intermediul unui alt server (IP și/sau port), dar permite și indicarea protocoalelor alternative. Acest lucru poate fi văzut mai jos în figura 1.

La primirea unui antet Alt-Svc valid care indică suportul HTTP/3, browserul va stoca acest lucru în cache și va încerca să configureze o conexiune QUIC de atunci înainte. Unii clienți vor face acest lucru cât mai curând posibil (chiar și în timpul încărcării inițiale a paginii - vezi mai jos), în timp ce alții vor aștepta până când conexiunile TCP existente sunt închise. Aceasta înseamnă că browserul va folosi HTTP/3 numai după ce a descărcat mai întâi cel puțin câteva resurse prin HTTP/2 sau HTTP/1.1 . Chiar și atunci, nu este o navigare lină. Browserul știe acum că serverul acceptă HTTP/3, dar asta nu înseamnă că rețeaua intermediară nu îl va bloca. Ca atare, cursele de conexiune sunt încă necesare în practică. Deci, s-ar putea să ajungeți în continuare cu HTTP/2 dacă rețeaua întârzie cumva strângerea de mână QUIC suficient. În plus, dacă conexiunea QUIC nu reușește să se stabilească de câteva ori la rând, unele browsere vor pune intrarea în cache Alt-Svc într-o listă de refuz pentru o perioadă de timp, fără a încerca HTTP/3 pentru un timp. Ca atare, poate fi util să ștergeți manual memoria cache a browserului dacă lucrurile se comportă, deoarece asta ar trebui să golească și legările Alt-Svc . În cele din urmă, s-a demonstrat că Alt-Svc prezintă unele riscuri serioase de securitate. Din acest motiv, unele browsere impun restricții suplimentare, de exemplu, cu privire la porturile care pot fi utilizate (în Chrome, serverele dvs. HTTP/2 și HTTP/3 trebuie să fie ambele pe un port sub 1024 sau ambele pe un port superior sau egal). la 1024, altfel Alt-Svc va fi ignorat). Toată această logică variază și evoluează extrem de mult între browsere, ceea ce înseamnă că obținerea de conexiuni HTTP/3 coerente poate fi dificilă , ceea ce face, de asemenea, dificilă testarea noilor setări.

Se lucrează în desfășurare pentru a îmbunătăți oarecum acest proces Alt-Svc în doi pași. Ideea este de a folosi noi înregistrări DNS numite SVCB și HTTPS, care vor conține informații similare cu cele din Alt-Svc . Ca atare, clientul poate descoperi că un server acceptă HTTP/3 în timpul pasului de rezoluție DNS, ceea ce înseamnă că poate încerca QUIC încă de la prima încărcare a paginii, în loc să trebuiască mai întâi să treacă prin HTTP/2 sau HTTP/1.1. Pentru mai multe informații despre aceasta și Alt-Svc , consultați capitolul Almanah web de anul trecut despre HTTP/2.

După cum puteți vedea, Alt-Svc și procesul de descoperire HTTP/3 adaugă un nivel de complexitate implementării deja provocatoare de server QUIC, deoarece:

• va trebui întotdeauna să vă implementați serverul HTTP/3 lângă un server HTTP/2 și/sau HTTP/1.1;
• va trebui să configurați serverele HTTP/2 și HTTP/1.1 pentru a seta anteturile Alt-Svc corecte pe răspunsurile lor.

Deși acest lucru ar trebui să fie gestionabil în setările la nivel de producție (deoarece, de exemplu, o singură instanță Apache sau NGINX va accepta probabil toate cele trei versiuni HTTP în același timp), ar putea fi mult mai enervant în setul de testare (local) - ups -uri (mă văd deja că am uitat să adaug anteturile Alt-Svc sau să le încurc). Această problemă este agravată de o lipsă (actuală) a jurnalelor de eroare ale browserului și a indicatorilor DevTools, ceea ce înseamnă că a afla de ce exact configurarea nu funcționează poate fi dificilă.

Probleme suplimentare

De parcă nu ar fi suficient, o altă problemă va face testarea locală mai dificilă: Chrome vă îngreunează foarte mult utilizarea certificatelor TLS autosemnate pentru QUIC . Acest lucru se datorează faptului că certificatele TLS neoficiale sunt adesea folosite de companii pentru a decripta traficul TLS al angajaților lor (astfel încât aceștia să poată, de exemplu, să își scaneze firewall-urile în traficul criptat). Cu toate acestea, dacă companiile ar începe să facă asta cu QUIC, am avea din nou implementări personalizate de middlebox care își fac propriile presupuneri despre protocol. Acest lucru i-ar putea duce la încălcarea potențialului suport al protocolului în viitor, ceea ce am încercat să prevenim prin criptarea QUIC atât de extinsă în primul rând! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

Ce înseamnă totul?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Farul Google

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog și qvis

După cum arată discuția de mai sus, poate fi dificil să analizați comportamentul HTTP/3 folosind doar Lighthouse sau WebPageTest în acest moment. Din fericire, alte instrumente de nivel inferior sunt disponibile pentru a ajuta în acest sens. În primul rând, excelentul instrument Wireshark are suport avansat pentru QUIC și poate diseca experimental și HTTP/3. Acest lucru vă permite să observați ce pachete QUIC și HTTP/3 trec de fapt prin cablu. Cu toate acestea, pentru ca acest lucru să funcționeze, trebuie să obțineți cheile de decriptare TLS pentru o anumită conexiune, pe care majoritatea implementărilor (inclusiv Chrome și Firefox) vă permit să le extrageți folosind variabila de mediu SSLKEYLOGFILE . Deși acest lucru poate fi util pentru unele lucruri, a afla cu adevărat ce se întâmplă, în special pentru conexiuni mai lungi, ar putea implica multă muncă manuală. De asemenea, veți avea nevoie de o înțelegere destul de avansată a funcționării interioare a protocoalelor.

Din fericire, există o a doua opțiune, qlog și qvis. qlog este un format de înregistrare bazat pe JSON, special pentru QUIC și HTTP/3, care este acceptat de majoritatea implementărilor QUIC. În loc să se uite la pachetele care trec prin cablu, qlog captează aceste informații direct pe client și server, ceea ce îi permite să includă câteva informații suplimentare (de exemplu, detalii de control al congestiei). De obicei, puteți declanșa ieșirea qlog atunci când porniți servere și clienți cu variabila de mediu QLOGDIR . (Rețineți că în Firefox, trebuie să setați preferința network.http.http3.enable_qlog . Dispozitivele Apple și Safari folosesc QUIC_LOG_DIRECTORY . Chrome încă nu acceptă qlog.)

Aceste fișiere qlog pot fi apoi încărcate în suita de instrumente qvis la qvis.quictools.info. Acolo, veți obține o serie de vizualizări interactive avansate care facilitează interpretarea traficului QUIC și HTTP/3 . qvis are și suport pentru încărcarea capturilor de pachete Wireshark (fișiere .pcap ) și are suport experimental pentru fișierele netlog ale Chrome, astfel încât să puteți analiza și comportamentul Chrome. Un tutorial complet despre qlog și qvis depășește scopul acestui articol, dar mai multe detalii pot fi găsite sub formă de tutorial, sub formă de lucrare și chiar în format talk-show. De asemenea, puteți să mă întrebați direct despre ele, deoarece sunt principalul implementator al qlog și qvis. ;)

Cu toate acestea, nu mă iluzi că majoritatea cititorilor de aici ar trebui să folosească vreodată Wireshark sau qvis, deoarece acestea sunt instrumente de nivel destul de scăzut. Totuși, deoarece avem puține alternative în acest moment, vă recomand cu tărie să nu testați pe scară largă performanța HTTP/3 fără a utiliza acest tip de instrument , pentru a vă asigura că știți cu adevărat ce se întâmplă pe fir și dacă ceea ce vedeți este într-adevăr explicat de din interiorul protocolului și nu de alți factori.

Ce înseamnă totul?

După cum am văzut, configurarea și utilizarea HTTP/3 prin QUIC poate fi o chestiune complexă și multe lucruri pot merge prost. Din păcate, nu există nici un instrument bun sau vizualizare care să expună detaliile necesare la un nivel adecvat de abstractizare. Acest lucru face foarte dificil pentru majoritatea dezvoltatorilor să evalueze potențialele beneficii pe care HTTP/3 le poate aduce site-ului lor în acest moment sau chiar să valideze că configurarea lor funcționează conform așteptărilor.

A te baza doar pe valori de nivel înalt este foarte periculos, deoarece acestea ar putea fi denaturate de o multitudine de factori (cum ar fi emularea nerealistă a rețelei, lipsa de funcții pe clienți sau servere, utilizarea doar parțială a HTTP/3 etc.). Chiar dacă totul a funcționat mai bine, așa cum am văzut în partea 2, diferențele dintre HTTP/2 și HTTP/3 vor fi probabil relativ mici în majoritatea cazurilor, ceea ce face și mai dificilă obținerea informațiilor necesare de la nivel înalt. instrumente fără suport HTTP/3 vizat.

Ca atare, recomand să lăsăm măsurătorile de performanță HTTP/2 versus HTTP/3 pentru încă câteva luni și să ne concentrăm în schimb pe a ne asigura că setările noastre de pe server funcționează conform așteptărilor . Pentru aceasta, este cel mai ușor să utilizați WebPageTest în combinație cu parametrii de linie de comandă ai Google Chrome, cu o alternativă la curl pentru probleme potențiale - aceasta este în prezent cea mai consistentă configurație pe care o pot găsi.

Concluzie și concluzii

Dragă cititor, dacă ați citit întreaga serie din trei părți și ați ajuns aici, vă salut ! Chiar dacă ați citit doar câteva secțiuni, vă mulțumesc pentru interesul acordat acestor protocoale noi și interesante. Acum, voi rezuma principalele concluzii din această serie, voi oferi câteva recomandări cheie pentru lunile și anul următor și, în sfârșit, vă voi oferi câteva resurse suplimentare, în cazul în care doriți să aflați mai multe.

rezumat

În primul rând, în partea 1, am discutat că HTTP/3 a fost necesar în principal din cauza noului protocol de transport QUIC . QUIC este succesorul spiritual al TCP și integrează toate cele mai bune practici ale sale, precum și TLS 1.3. Acest lucru a fost necesar în principal deoarece TCP, datorită implementării și integrării sale omniprezente în casetele de mijloc, a devenit prea inflexibil pentru a evolua. Utilizarea de către QUIC a UDP și criptarea aproape completă înseamnă că (sperăm) trebuie doar să actualizăm punctele finale în viitor pentru a adăuga noi funcții, care ar trebui să fie mai ușor. QUIC, totuși, adaugă și câteva capabilități noi interesante. În primul rând, transportul combinat și strângerea de mână criptografică a lui QUIC este mai rapidă decât TCP + TLS și poate folosi caracteristica 0-RTT. În al doilea rând, QUIC știe că transportă mai multe fluxuri de octeți independenți și poate fi mai inteligent cu privire la modul în care gestionează pierderile și întârzierile, atenuând problema blocării head-of-line. În al treilea rând, conexiunile QUIC pot supraviețui utilizatorilor care se mută într-o rețea diferită (numită migrare a conexiunii) prin etichetarea fiecărui pachet cu un ID de conexiune. În cele din urmă, structura flexibilă de pachete a QUIC (folosind cadre) îl face mai eficient, dar și mai flexibil și extensibil în viitor. În concluzie, este clar că QUIC este protocolul de transport de ultimă generație și va fi folosit și extins pentru mulți ani de acum încolo .

În al doilea rând, în partea 2, am aruncat o privire critică asupra acestor noi funcții, în special a implicațiilor lor de performanță . În primul rând, am văzut că utilizarea UDP de către QUIC nu o face ca prin magie să fie mai rapidă (și nici mai lent), deoarece QUIC folosește mecanisme de control a congestionării foarte asemănătoare cu TCP pentru a preveni supraîncărcarea rețelei. În al doilea rând, strângerea de mână mai rapidă și 0-RTT sunt mai multe micro-optimizări, deoarece sunt într-adevăr doar cu o călătorie dus-întors mai rapide decât o stivă optimizată TCP + TLS, iar adevăratul 0-RTT al QUIC este afectat și mai mult de o serie de probleme de securitate care pot limita utilitatea acestuia. În al treilea rând, migrarea conexiunii este într-adevăr necesară doar în câteva cazuri specifice și înseamnă totuși resetarea ratelor de trimitere, deoarece controlul congestiei nu știe câte date poate gestiona noua rețea. În al patrulea rând, eficacitatea eliminării blocării head-of-line de la QUIC depinde foarte mult de modul în care datele fluxului sunt multiplexate și prioritizate. Abordările care sunt optime pentru a recupera din pierderea pachetelor par dăunătoare cazurilor generale de utilizare a performanței de încărcare a paginilor web și invers, deși este nevoie de mai multe cercetări. În al cincilea rând, QUIC ar putea fi cu ușurință mai lent la trimiterea pachetelor decât TCP + TLS, deoarece API-urile UDP sunt mai puțin mature și QUIC criptează fiecare pachet individual, deși acest lucru poate fi în mare măsură atenuat în timp. În al șaselea rând, HTTP/3 în sine nu aduce cu adevărat funcții noi de performanță majore, dar în principal reprocesează și simplifică elementele interne ale caracteristicilor cunoscute HTTP/2. În cele din urmă, unele dintre cele mai interesante caracteristici legate de performanță pe care le permite QUIC (multipath, date nesigure, WebTransport, corecția erorilor de redirecționare etc.) nu fac parte din standardele de bază QUIC și HTTP/3, ci sunt mai degrabă extensii propuse care vor lua mai mult timp să fie disponibil. În concluzie, aceasta înseamnă că probabil că QUIC nu va îmbunătăți prea mult performanța utilizatorilor din rețelele de mare viteză, dar va fi important în principal pentru cei care se află pe rețele lente și mai puțin stabile .

În cele din urmă, în această parte 3, ne-am uitat la cum să folosim și să implementăm practic QUIC și HTTP/3 . În primul rând, am văzut că cele mai bune practici și lecțiile învățate din HTTP/2 ar trebui doar să se transfere la HTTP/3. Nu este nevoie să vă schimbați strategia de grupare sau inline și nici să vă consolidați sau fragmentați ferma de servere. Server push nu este încă cea mai bună caracteristică de utilizat, iar preload poate fi, în mod similar, o pușcă puternică. În al doilea rând, am discutat că ar putea dura ceva timp până când pachetele de server web de la raft să ofere suport complet HTTP/3 (parțial din cauza problemelor de suport pentru bibliotecile TLS), deși o mulțime de opțiuni open-source sunt disponibile pentru cei care adoptă timpurie și mai multe CDN-uri majore au o ofertă matură. În al treilea rând, este clar că majoritatea browserelor majore au suport (de bază) HTTP/3, chiar și activat implicit. Există totuși diferențe majore în ceea ce privește modul și când folosesc practic HTTP/3 și noile sale caracteristici, așa că înțelegerea comportamentului lor poate fi o provocare. În al patrulea rând, am discutat că acest lucru este agravat de lipsa suportului explicit HTTP/3 în instrumente populare precum Lighthouse și WebPageTest, ceea ce face deosebit de dificilă compararea performanței HTTP/3 cu HTTP/2 și HTTP/1.1 în acest moment. În concluzie, HTTP/3 și QUIC nu sunt probabil încă pregătite pentru primetime, dar în curând vor fi .

Recomandări

Din rezumatul de mai sus, s-ar putea părea că aduc argumente puternice împotriva utilizării QUIC sau HTTP/3. Cu toate acestea, este chiar opus punctului pe care vreau să îl spun.

În primul rând, așa cum sa discutat la sfârșitul părții 2, chiar dacă utilizatorul dvs. „mediu” ar putea să nu întâlnească câștiguri majore de performanță (în funcție de piața țintă), o parte semnificativă a publicului dvs. va vedea probabil îmbunătățiri impresionante . 0-RTT ar putea salva doar o singură călătorie dus-întors, dar asta poate însemna totuși câteva sute de milisecunde pentru unii utilizatori. Este posibil ca migrarea conexiunii să nu susțină descărcări rapide în mod constant, dar cu siguranță îi va ajuta pe cei care încearcă să preia acel PDF într-un tren de mare viteză. Pierderea de pachete pe cablu ar putea fi în rafală, dar conexiunile wireless ar putea beneficia mai mult de eliminarea blocării head-of-line de către QUIC. În plus, acești utilizatori sunt cei care ar întâmpina de obicei cea mai proastă performanță a produsului și, în consecință, ar fi cel mai puternic afectați de aceasta. Dacă te întrebi de ce contează asta, citește faimoasa anecdotă despre performanța web a lui Chris Zacharias.

În al doilea rând, QUIC și HTTP/3 vor deveni mai bune și mai rapide în timp . Versiunea 1 s-a concentrat pe realizarea protocolului de bază, păstrând funcții de performanță mai avansate pentru mai târziu. Ca atare, consider că merită să începeți acum să investiți în protocoale, pentru a vă asigura că le puteți folosi și noile funcții la un efect optim atunci când acestea devin disponibile în continuare. Având în vedere complexitatea protocoalelor și aspectele de desfășurare a acestora, ar fi bine să vă acordați puțin timp pentru a vă familiariza cu ciudateniile lor. Chiar dacă nu doriți să vă murdăriți încă mâinile, câțiva furnizori importanți de CDN oferă suport pentru HTTP/3 pentru „flip the switch” (în special, Cloudflare și Fastly). Mă străduiesc să găsesc un motiv să nu încerc asta dacă folosești un CDN (ceea ce, dacă îți pasă de performanță, chiar ar trebui să faci).

Ca atare, deși nu aș spune că este esențial să începeți să utilizați QUIC și HTTP/3 cât mai curând posibil, cred că există deja o mulțime de beneficii și vor crește doar în viitor .

Lectură suplimentară

Deși acesta a fost un corp lung de text, din păcate, nu face decât să zgârie suprafața tehnică a protocoalelor complexe care sunt QUIC și HTTP/3.

Mai jos veți găsi o listă de resurse suplimentare pentru învățarea continuă, mai mult sau mai puțin în ordinea crescătoare a profunzimii tehnice:

• „HTTP/3 explicat”, Daniel Stenberg
  Această carte electronică, de către creatorul cURL, rezumă protocolul.
• „HTTP/2 în acțiune”, Barry Pollard
  Această carte excelentă completă despre HTTP/2 are sfaturi reutilizabile și o secțiune despre HTTP/3.
• @programmingart, Twitter
  Tweeturile mele sunt în mare parte dedicate QUIC, HTTP/3 și performanței web (inclusiv știri) în general. Vedeți, de exemplu, discuțiile mele recente despre funcțiile QUIC.
• „YouTube”, Robin Marx
  Cele peste 10 discuții aprofundate ale mele acoperă diverse aspecte ale protocoalelor.
• „Blogul Cloudlare”
  Acesta este produsul principal al unei companii care rulează și un CDN pe partea laterală.
• „Blogul rapid”
  Acest blog are discuții excelente despre aspecte tehnice, încorporate într-un context mai larg.
• QUIC, RFC-urile reale
  Veți găsi link-uri către documentele IETF QUIC și HTTP/3 RFC și alte extensii oficiale.
• Blogul inginerilor IIJ: Explicații tehnice profunde excelente ale detaliilor caracteristicilor QUIC.
• Lucrări academice HTTP/3 și QUIC, Robin Marx
  Lucrările mele de cercetare acoperă multiplexarea și prioritizarea fluxului, instrumente și diferențe de implementare.
• QUIPS, EPIQ 2018 și EPIQ 2020
  Aceste lucrări de la atelierele academice conțin cercetări aprofundate despre securitate, performanță și extensii ale protocoalelor.

Cu aceasta, vă las, dragă cititor, cu o înțelegere mult îmbunătățită, sperăm, a acestei noi lumi curajoase. Sunt mereu deschis la feedback, așa că vă rog să-mi spuneți ce părere aveți despre această serie!