Performanță și eficiență: Lucrul cu HTTP/3

HTTP/3 este la orizont, urmând imediat HTTP/2 – care, probabil, este încă foarte tânăr. Având în vedere că a durat 16 ani pentru a trece de la HTTP/1.1 la HTTP/2, ar trebui să fie cineva cu adevărat preocupat de HTTP/3?

Răspunsul scurt: Da, este important și ar trebui să fii la curent cu el. Este la fel cum HTTP/2 a făcut modificări semnificative de la HTTP/1.1 prin trecerea de la ASCII la binar. HTTP/3 face din nou modificări semnificative, de data aceasta prin comutarea transportului de bază de la TCP la UDP.

Deși HTTP/3 este încă în faza de proiectare, specificația oficială fiind o schiță, este deja implementată și există șanse mari să găsiți o versiune a acestuia care rulează astăzi în rețeaua dvs.

Dar există câteva noi dileme generate de modul în care funcționează HTTP/3. De asemenea, care este beneficiul? Și ce trebuie să știe inginerii de rețea, administratorii de sistem și dezvoltatorii?

Problema principală: performanță și eficiență

Dezvoltatorii de site-uri și aplicații construiesc în general cu intenția ca creațiile lor să fie utilizate efectiv. Uneori, baza de audiență este limitată, dar de multe ori ideea este doar de a obține cât mai mulți utilizatori. Desigur, cu cât un site web devine mai popular, cu atât poate obține mai multe venituri.

O întârziere de 100 de milisecunde în timpul de încărcare a site-ului web poate afecta ratele de conversie cu 7 procente.

Raportul Akamai de performanță online cu amănuntul: milisecundele sunt critice (2017)

Altfel spus, un site de comerț electronic cu vânzări de 40.000 USD pe zi ar pierde anual un milion de dolari din cauza unei astfel de întârzieri.

De asemenea, nu este un secret pentru nimeni că performanța unui site este absolut esențială pentru ca un site să devină mai popular. Cercetarea privind cumpărăturile online continuă să găsească legături între ratele de respingere crescute și timpii de încărcare mai lungi și între loialitatea cumpărătorilor și performanța site-ului în timpul experienței de cumpărături.

Cercetările au mai constatat că:

• 47% dintre consumatori se așteaptă ca o pagină web să se încarce în 2 secunde sau mai puțin.
• 40% dintre oameni abandonează un site web care durează mai mult de 3 secunde pentru a se încărca.

Și aceasta a fost starea de răbdare a cumpărătorilor online de acum peste un deceniu . Deci performanța este critică, iar HTTP/2 și HTTP/3 înseamnă ambele performanțe mai bune ale site-ului.

HTTP/2? …Ce-i asta?

O bună înțelegere a protocolului HTTP/2 este crucială pentru înțelegerea HTTP/3. În primul rând, de ce a fost nevoie de HTTP/2?

HTTP/2 a început ca un proiect Google numit SPDY, rezultatul unui studiu care a raportat că cea mai mare problemă de performanță pe web a fost latența . Autorul a concluzionat că „mai multă lățime de bandă nu contează (mult)”:

Dacă facem o analogie între instalații sanitare și Internet, putem considera lățimea de bandă a Internetului ca fiind diametrul conductei de apă. O conductă mai mare transportă un volum mai mare de apă și, prin urmare, puteți livra mai multă apă între două puncte.

În același timp, oricât de mare ar fi conducta dvs., dacă conducta este goală și doriți să obțineți apă dintr-un punct în altul, este nevoie de timp pentru ca apa să circule prin conductă. În limbajul internetului, timpul necesar apei pentru a călători de la un capăt al conductei la celălalt și înapoi se numește timp dus-întors sau RTT .

Mike Belshe

În studiu, reducerea timpului de încărcare a paginii a fost scopul. Acesta a arătat că creșterea lățimii de bandă ajută inițial, deoarece trecerea de la 1 Mbps la 2 Mbps înjumătățește timpul de încărcare a paginii. Cu toate acestea, beneficiile se stabilesc foarte repede.

În schimb, scăderea latenței are un beneficiu constant și obține cele mai bune rezultate.

HTTP HOL: Problema de blocare a șefului de linie

Principala cauză a latenței în protocolul HTTP/1 este problema de blocare a capului de linie. Paginile web (aproape întotdeauna) necesită mai multe resurse: CSS, JavaScript, fonturi, imagini, AJAX/XMR etc. Aceasta înseamnă că browserul web trebuie să facă mai multe solicitări către server. Cu toate acestea, nu sunt necesare toate resursele pentru ca pagina să devină utilă.

Cu HTTP/1.0 a fost necesar ca browserul să completeze o solicitare complet, inclusiv să primească răspunsul complet, înainte de a începe următoarea solicitare. Totul trebuia făcut în ordine. Fiecare cerere ar bloca linia de cereri, de unde și numele.

În încercarea de a compensa problema de blocare HOL, browserele web realizează mai multe conexiuni simultane la un singur server. Dar au fost nevoiți să limiteze în mod arbitrar acest comportament: serverele, stațiile de lucru și rețelele pot deveni supraîncărcate cu prea multe conexiuni.

HTTP/1.1 a introdus mai multe îmbunătățiri pentru a ajuta la rezolvarea problemei. Principalul este pipelining , permițând browserelor web să înceapă noi solicitări fără a fi nevoie să aștepte ca cererile anterioare să fie finalizate. Acest lucru a îmbunătățit semnificativ timpii de încărcare în medii cu latență scăzută.

Dar totuși necesită ca toate răspunsurile să sosească secvenţial în ordinea în care au fost făcute, astfel încât capul de linie este încă blocat. În mod surprinzător, o mulțime de servere încă nu profită de această caracteristică.

În mod interesant, HTTP/1.1 a introdus și keep-alive , care a permis browserelor să evite suprasolicitarea creării unei noi conexiuni TCP pentru fiecare solicitare HTTP. Aceasta a fost o încercare timpurie de a rezolva o problemă de performanță derivată din TCP. A fost atât de ineficient încât majoritatea experților în performanță îl descurajează, deoarece blochează serverul cu prea multe conexiuni inactive. Vom arunca o privire mai atentă la TCP mai jos, precum și la modul în care această problemă a fost rezolvată prin HTTP/2.

Soluția de blocare HTTP HOL a HTTP/2

HTTP/2 a introdus multiplexarea cerere-răspuns printr-o singură conexiune. Nu numai că un browser poate începe o nouă solicitare în orice moment, dar răspunsurile pot fi primite în orice ordine — blocarea este complet eliminată la nivel de aplicație.

Ca rezultat direct, acest lucru înseamnă că serverele web cu cunoștințe HTTP/2 pot maximiza eficiența - mai multe despre asta mai târziu.

Deși multiplexarea cerere-răspuns este caracteristica principală pentru HTTP/2, aceasta include câteva alte caracteristici semnificative. Cititorii pot observa că toate sunt oarecum legate.

Încadrare binară HTTP/2

HTTP/2 comută standardul protocolului HTTP de la un model ASCII cerere-răspuns ineficient, citibil de om, la o încadrare binară eficientă. Nu mai este doar o cerere și un răspuns:

Cu HTTP/2, browserele vorbesc cu serverele prin fluxuri bidirecționale cu mai multe mesaje, fiecare constând din mai multe cadre.

HTTP/2 HPACK (compresie antet)

Noua compresie a antetului HTTP/2, folosind formatul HPACK, economisește o mulțime de lățime de bandă pentru majoritatea site-urilor. Acest lucru se datorează faptului că majoritatea antetelor sunt aceleași pentru cererile trimise în cadrul unei conexiuni.

Cloudflare raportează economii semnificative de lățime de bandă datorită exclusiv HPACK:

• Compresie de 76% pentru anteturile de intrare
• Reducere cu 53% a traficului total de intrare
• Compresie de 69% pentru anteturile de ieșire
• Reducerea cu 1,4% până la 15% a traficului total de ieșire

Desigur, folosirea mai puțină lățime de bandă înseamnă, în general, un site web mai rapid.

Prioritizarea fluxului HTTP/2 și Push pe server

Iată unde multiplexarea HTTP/2 permite serverului să maximizeze eficiența. Multiplexarea ajută la furnizarea de resurse mai rapide (de exemplu, JavaScript din memorie cache) înaintea celor mai lente (de exemplu, imagini mari, JSON generat de baze de date etc.). Dar permite, de asemenea, o creștere suplimentară a performanței prin prioritizarea fluxului HTTP/2.

Prioritizarea fluxului vă ajută să vă asigurați că aspectele aproape gata ale unei pagini sunt finalizate în întregime, fără a fi nevoie să așteptați ca alte solicitări care necesită mult resurse să se termine. Acest lucru se realizează printr-un arbore de dependență ponderat. Acest arbore este folosit pentru a informa serverul care răspunsuri ar trebui să aloce cele mai multe resurse de sistem pentru a le servi.

Acest lucru este deosebit de important pentru aplicațiile web progresive (PWA). De exemplu, să presupunem că o pagină are patru fișiere JavaScript. Două sunt pentru funcționalitatea paginii și două sunt pentru anunțuri. Cel mai rău scenariu este să încărcați jumătate din JS funcțional și jumătate din JS publicitar și apoi să continuați să încărcați imagini mari, înainte de a încărca oricare dintre JS-ul rămas. În acest caz, nimic din pagină nu funcționează inițial, deoarece totul trebuie să aștepte cea mai lentă resursă.

Cu prioritizarea fluxului, browserele web pot instrui serverul să trimită ambele fișiere JS cu funcționalitatea paginii înainte de a trimite oricare dintre fișierele JavaScript de publicitate. În acest fel, utilizatorii nu trebuie să aștepte ca reclamele să se încarce complet înainte de a utiliza funcționalitatea paginii. Deși timpul general de încărcare nu s-a îmbunătățit, performanța percepută a fost semnificativ crescută. Din păcate, acest comportament în browser-ul web este încă o problemă de algoritmi, mai degrabă decât ceva specificat de dezvoltatorii web.

În același sens, funcția de push server a HTTP/2 permite serverului să trimită răspunsuri către browser pentru solicitările pe care nu le-a făcut încă! Serverul poate profita de lacunele în transmisie, utilizând eficient lățimea de bandă prin preîncărcarea în browser a resurselor pe care serverul știe că le va solicita în curând. O parte din speranța de aici este eliminarea practicii de resource inline, care doar umfla resursele și le face să dureze mai mult pentru încărcare.

Din păcate, ambele caracteristici necesită multă configurare atentă de către dezvoltatorii web pentru a reuși cu adevărat. Pur și simplu activarea acestora nu este suficientă.

HTTP/2 aduce în mod clar multe avantaje potențiale — unele dintre ele mai ieftine decât altele. Cum se descurcă ei în lumea reală?

Adoptarea HTTP vs HTTP/2

SPDY a fost creat în 2009. HTTP/2 a fost standardizat în 2015. SPDY a devenit numele unei ramuri de dezvoltare instabile a codului, HTTP/2 devenind versiunea finală. Rezultatul este că SPDY a devenit învechit, iar HTTP/2 este de obicei standardul pe care îl urmează toată lumea.

După standardizare, adoptarea HTTP/2 (sau „h2”) a crescut rapid la aproximativ 40% din primele 1.000 de site-uri web. Acest lucru a fost determinat în principal de furnizorii mari de găzduire și cloud care au implementat asistență în numele clienților lor. Din păcate, câțiva ani mai târziu, adoptarea HTTP/2 a încetinit și majoritatea internetului este încă pe HTTP/1.

Lipsa suportului de browser pentru modul text clar HTTP/2

Au existat multe apeluri pentru HTTP/2 pentru a face din criptare o parte obligatorie a standardului. În schimb, standardul a definit atât modurile criptate (h2) cât și cele de text clar (h2c). Ca atare, HTTP/2 ar putea înlocui HTTP/1 în întregime.

În ciuda standardului, toate browserele web actuale acceptă numai HTTP/2 prin conexiuni criptate și nu implementează în mod intenționat modul text clar. În schimb, browserele se bazează pe modul de compatibilitate inversă HTTP/1 pentru a accesa servere nesigure. Acesta este un rezultat direct al unui impuls ideologic de a asigura securitatea implicită a web-ului.

De ce HTTP/3? Și cum este diferit?

Odată cu problema de blocare a capului de linie HTTP soluționată acum de HTTP/2, dezvoltatorii de protocole și-au îndreptat atenția către următorul cel mai mare driver de latență: problema de blocare a capului de linie TCP .

Protocolul de control al transmisiei (TCP)

Rețelele IP (protocol de internet) se bazează pe ideea că computerele își trimit pachete reciproc. Un pachet este doar date cu unele informații de adresare atașate în partea de sus.

Dar, de obicei, aplicațiile trebuie să se ocupe de fluxuri de date. Pentru a realiza această iluzie, protocolul de control al transmisiei (TCP) prezintă aplicațiilor o conductă prin care poate curge un flux de date. Ca și în cazul majorității conductelor, există garanția că datele vor ieși din conductă în aceeași ordine în care intră, cunoscută și sub numele de „primul intrat, primul ieșit” (FIFO). Aceste caracteristici au făcut ca TCP să fie foarte util și adoptat pe scară largă.

Ca parte a garanțiilor de livrare a datelor pe care le oferă TCP, acesta trebuie să fie capabil să facă față unei game largi de situații. Una dintre cele mai complexe probleme este cum să livrezi toate datele atunci când o rețea este supraîncărcată, fără a înrăutăți situația pentru toată lumea. Algoritmul pentru aceasta se numește controlul congestiei și este o parte în continuă evoluție a specificațiilor internetului. Fără un control suficient al congestiei, internetul se oprește.

În octombrie '86, Internetul a avut primul dintre ceea ce a devenit o serie de „prăbușiri de congestie”. În această perioadă, fluxul de date de la LBL la UC Berkeley (site-uri separate de 400 de metri și trei hop-uri IMP) a scăzut de la 32 Kbps la 40 bps.

V. Jacobson (1988)

Aici intervine problema de blocare a head-of-line TCP.

Problemă de blocare TCP HOL

Controlul congestiei TCP funcționează prin implementarea mecanismelor de backoff și retransmisie pentru pachete, utilizate ori de câte ori este detectată pierderea pachetelor. Backoff are scopul de a ajuta la calmarea rețelei. Retransmiterea asigură că datele sunt în cele din urmă livrate.

Aceasta înseamnă că datele TCP pot ajunge la destinație în afara ordinului și este responsabilitatea părții care primește să reordoneze pachetele înainte de a le reasambla în flux. Din păcate, aceasta înseamnă că un singur pachet pierdut poate face ca întregul flux TCP să fie întrerupt în timp ce serverul așteaptă retransmiterea acestuia. Prin urmare, capul de linie este blocat.

Un alt proiect de la Google și-a propus să rezolve această problemă prin introducerea unui protocol numit QUIC.

Protocolul QUIC este construit pe UDP în loc de TCP, iar QUIC formează baza pentru HTTP/3.

Ce este UDP?

Protocolul de datagramă utilizator (UDP) este o alternativă la TCP. Nu oferă iluzia unui flux sau aceleași garanții pe care le oferă TCP. În schimb, oferă pur și simplu o modalitate ușoară de a plasa date într-un pachet, de a le adresa unui alt computer și de a le trimite. Este nesigur , neordonat și nu vine cu nicio formă de control al congestiei.

Scopul său este să fie ușor și să ofere caracteristicile minime necesare pentru a permite comunicarea. În acest fel aplicația își poate implementa propriile garanții. Acest lucru este adesea foarte util în aplicațiile în timp real. De exemplu, în apelurile telefonice, utilizatorii preferă în general să primească 90% din date imediat, decât 100% din date în cele din urmă.

Soluția TCP HOL pentru HTTP/3

Rezolvarea problemei de blocare a TCP HOL a necesitat mai mult decât trecerea la UDP, deoarece este încă necesar să se garanteze livrarea tuturor datelor și să se evite colapsurile congestiei rețelei. Protocolul QUIC este conceput pentru a face toate acestea, oferind o experiență optimizată de tip HTTP peste UDP.

Pe măsură ce QUIC preia controlul asupra gestionării fluxului, încadrării binare etc., nu mai sunt multe de făcut HTTP/2 atunci când rulează pe QUIC. Aceasta face parte din factorul de conducere pentru ca această nouă combinație de QUIC + HTTP să fie standardizată ca HTTP/3.

Notă: Există multe versiuni de QUIC, deoarece protocolul a fost în dezvoltare și implementat în medii de producție de ani de zile. Există chiar și o versiune specifică Google numită GQUIC. Ca atare, este important să facem o distincție între vechile protocoale QUIC și noul standard HTTP/3.

Întotdeauna criptat

HTTP/3 include criptare care împrumută în mare măsură de la TLS, dar nu o folosește direct. Una dintre principalele provocări de implementare pentru HTTP/3 este bibliotecile TLS/SSL care trebuie modificate pentru a adăuga noua funcționalitate necesară.

Această modificare se datorează faptului că HTTP/3 diferă de HTTPS în ceea ce privește ceea ce criptează. Cu protocolul HTTPS mai vechi, doar datele în sine sunt protejate de TLS, lăsând vizibile multe metadate de transport. În HTTP/3, atât datele, cât și protocolul de transport sunt protejate. Aceasta ar putea suna ca o caracteristică de securitate și este. Dar se procedează astfel pentru a evita o mare parte din suprasarcina prezentă în HTTP/2. Prin urmare, criptarea protocolului de transport, precum și a datelor, face de fapt protocolul mai performant.

Impactul HTTP/3 asupra infrastructurii de rețea

HTTP/3 nu este lipsit de controverse. Principalele preocupări sunt legate de infrastructura de rețea.

HTTP/3 la nivelul clientului

Din partea clientului, este destul de obișnuit ca traficul UDP să fie puternic limitat și/sau blocat. Aplicarea acestor restricții la HTTP/3 înfrânge punctul de vedere al protocolului.

În al doilea rând, este destul de comun ca HTTP să fie monitorizat și/sau interceptat. Chiar și cu trafic HTTPS, rețelele urmăresc în mod regulat elementele de transport de text clar ale protocolului pentru a determina dacă ar trebui să întrerupă conexiunea în scopul de a împiedica accesul la anumite site-uri web din anumite rețele sau în anumite regiuni. În unele țări, acest lucru este chiar impus de lege pentru anumiți furnizori de servicii. Criptarea obligatorie în HTTP/3 face acest lucru imposibil.

Nu este vorba doar de filtrare la nivel guvernamental. Multe universități, biblioteci publice, școli și case cu părinți îngrijorați aleg în mod activ fie să blocheze accesul la anumite site-uri web, fie cel puțin să păstreze un jurnal al site-urilor vizitate. Criptarea obligatorie în HTTP/3 face acest lucru imposibil.

Este de remarcat faptul că în prezent este posibilă filtrarea limitată. Acest lucru se datorează faptului că câmpul de indicație a numelui serverului (SNI) – care poartă numele de gazdă al site-ului web, dar nu calea, parametrii de interogare etc. – nu este încă criptat. Dar acest lucru se va schimba în viitorul apropiat odată cu introducerea ESNI (SNI criptat), care a fost adăugat recent la standardul TLS.

HTTP/3 pe partea serverului

Pe partea de server, cea mai bună practică este să blocați orice porturi și protocoale care nu așteaptă trafic, ceea ce înseamnă că acum administratorii de server trebuie să deschidă UDP 443 pentru HTTP/3, în loc să se bazeze pe regulile TCP 443 existente.

În al doilea rând, infrastructura de rețea poate face sesiunile TCP lipicioase , ceea ce înseamnă că vor fi întotdeauna direcționate către același server, chiar dacă prioritățile de rutare se schimbă. Deoarece HTTP/3 rulează peste UDP – care este fără sesiune – infrastructura de rețea trebuie actualizată pentru a urmări ID-urile de conexiune specifice HTTP/3, care au fost lăsate necriptate în mod special pentru a ajuta la rutarea sticky.

În al treilea rând, este destul de obișnuit ca HTTP să fie inspectat pentru a detecta abuzurile, pentru a monitoriza problemele obișnuite de securitate, pentru a detecta și a preveni răspândirea malware-ului și a virușilor etc. Acest lucru nu este posibil cu HTTP/3 din cauza criptării sale. Totuși, opțiunile în care dispozitivul de interceptare are o copie a cheilor de securitate sunt încă posibile, presupunând că dispozitivele implementează suport HTTP/3.

În cele din urmă, mulți administratori se opun nevoii de a gestiona și mai multe certificate SSL, deși aceasta este o problemă mai mică acum, deoarece serviciile precum Let's Encrypt sunt disponibile.

Până când nu vor exista soluții bine-cunoscute și acceptate pe scară largă pentru a aborda aceste preocupări, cred că este posibil ca multe rețele mari să blocheze pur și simplu HTTP/3.

Impactul HTTP/3 asupra dezvoltării web

Nu sunt multe de care să vă faceți griji pe acest front. Prioritizarea fluxului HTTP/2 și funcțiile de push server sunt încă prezente în HTTP/3. Merită ca dezvoltatorii web să se familiarizeze cu aceste funcții dacă doresc să își optimizeze cu adevărat performanța site-ului.

Folosind HTTP/3 chiar acum

Utilizatorii Google Chrome sau browserul Chromium cu sursă deschisă sunt deja setați pentru utilizarea HTTP/3. Lansările de calitate de producție ale serverelor HTTP/3 sunt încă puțin îndepărtate – specificația nu este complet finalizată la momentul scrierii acestui articol. Dar, între timp, există o mulțime de instrumente cu care să te joci și atât Google, cât și Cloudflare au impus deja suport pentru mediile lor de producție.

Cel mai simplu mod de a-l încerca este să folosești Caddy în Docker. Pentru aceasta este necesar un certificat SSL, așa că o adresă IP accesibilă public facilitează lucrurile. Pașii sunt:

1. Configurare DNS. Obțineți un nume de gazdă funcțional care este live pe internet, de exemplu, numele dvs. de yourhostname.example.com IN A 192.0.2.1 .
2. Crearea Caddyfile. Ar trebui să conțină aceste rânduri:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Rularea Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic în afara Docker, caddy --quic .
2. Rularea chromium cu QUIC activat: chromium --enable-quic
3. (Opțional) Instalarea unei extensii Protocol Indicator.
4. Navigarea la serverul activat pentru QUIC , unde ar trebui să fie vizibil un browser de fișiere.

De asemenea, dezvoltatorii își pot testa serverele cu următoarele instrumente utile:

• Testul HTTP/2 al Keycdn
• HTTP3Check de la LiteSpeed
• Testul de server SSL al Qualys

Multumesc pentru lectura!