Ce este HTTP/3 - Informații despre noul protocol rapid bazat pe UDP

TL;DR

În noiembrie 2018, Internet Engineering Task Force (IETF) sa întâlnit la Bangkok și a fost adoptat un nou Internet-Draft. Protocolul de transport QUIC, un succesor HTTP/2, a fost redenumit HTTP/3.

HTTP/3 se bazează pe User Datagram Protocol (UDP) și este deja utilizat de companii de internet importante, cum ar fi Google și Facebook. Dacă utilizați Chrome și vă conectați la un serviciu Google, probabil că utilizați deja QUIC.

Noua versiune a protocolului HTTP beneficiază de protocolul UDP bare-metal, de nivel scăzut și definește multe dintre noile caracteristici care erau în versiunile anterioare ale HTTP la nivelul TCP. Aceasta oferă o modalitate de a rezolva constrângerile din cadrul infrastructurii de internet existente.

Primele rezultate sunt promițătoare, iar când expiră Internet Draft de IETF, în august 2021, ne putem aștepta ca HTTP/3 să fie promovat ca un nou standard HTTP de a treia generație.

Progresul HTTP/3 în 2022

Unii spun că foamea industriei web pentru mai multă viteză și latență mai mică este egalată doar de foamea Google Chrome pentru mai multă memorie RAM.

În urmă cu câțiva ani, am publicat un articol despre HTTP/2, un standard care, potrivit W3Techs, a atins acum o rată de adoptare la nivel mondial de aproximativ 45%. Și conform Can I Use, este, de asemenea, acceptat de toate browserele web moderne. Totuși, aici suntem, scriind un articol despre următoarea versiune a protocolului, HTTP/3.

HTTP/3 este, la momentul scrierii acestui articol, un Internet-Draft sau ID IETF, ceea ce înseamnă că este în prezent în considerare pentru un viitor standard de internet de către Internet Engineering Task Force – un organism internațional de standarde de internet , responsabil de definirea și promovarea standardelor de protocol de internet convenite, cum ar fi TCP, IPv6, VoIP, Internetul lucrurilor etc.

Este un organism deschis care unește industria web și facilitează discuțiile despre direcția internetului. În prezent, faza „Internet Draft” a HTTP/3 este ultima fază înainte ca propunerile să fie promovate la nivelul de Request-for-Comments (sau RFC-uri), pe care le putem considera, în toate intențiile și scopurile, definiții oficiale ale protocolului internet.

Chiar dacă HTTP/3 nu este încă un protocol de internet oficial, multe companii și proiecte au început deja să adauge suport HTTP/3 în produsele lor.

Suport browser web pentru HTTP/3

În fața browserului web, Chrome v87, Firefox v88 și Edge v87 au toate HTTP/3 activat în mod implicit. Pentru utilizatorii Safari, opțiunea de a activa HTTP/3 a fost adăugată în Safari Technology Preview v104. Cu toate acestea, suportul HTTP/3 nu este disponibil momentan în versiunea stabilă a Safari.

Suport bibliotecă pentru HTTP/3

Pentru dezvoltatorii care doresc să folosească tehnologiile HTTP/3, multe biblioteci populare au adăugat deja suport pentru HTTP/3. Deoarece HTTP/3 este încă în faza de Internet Schiță, trebuie să vă asigurați că sunteți conectat la cele mai recente actualizări atunci când lucrați cu una dintre bibliotecile de mai jos.

• Python – http3 și aioquic
• Rugina – quiche, neqo și quinn
• C – nghttp3 și lsquic
• Du-te – quicgo
• JavaScript – Node.js

Suport de infrastructură pentru HTTP/3

În ceea ce privește infrastructura, Cloudflare a fost lider cu suport pentru HTTP/3 în întreaga sa rețea edge. Aceasta înseamnă că site-urile cu Cloudflare activat pot profita de îmbunătățirile de securitate și performanță ale HTTP/3 fără nicio muncă suplimentară.

La Kinsta, toate site-urile pe care le găzduim sunt protejate de integrarea noastră gratuită Cloudflare. Pe lângă un firewall la nivel de întreprindere și protecție DDoS, clienții Kinsta au și acces la HTTP/3!

Pentru a testa dacă site-ul dvs. acceptă HTTP/3, puteți utiliza Instrumentul de testare HTTP/3 de la Geekflare. Pur și simplu introduceți domeniul dvs. și apăsați butonul „Verificați HTTP/3”, iar instrumentul vă va anunța dacă site-ul dvs. este activat pentru HTTP/3.

Dacă site-ul dvs. acceptă HTTP/3, ar trebui să vedeți un mesaj ca cel de mai jos. Deoarece kinstalife.com este găzduit pe Kinsta, HTTP/3 este pe deplin acceptat datorită integrării noastre Cloudflare.

De asemenea, puteți utiliza inspectorul browserului pentru a verifica compatibilitatea HTTP/3. Pentru acest exemplu, vom folosi cea mai recentă versiune de Google Chrome, care acceptă HTTP/3.

Pentru a deschide inspectorul, faceți clic dreapta pe pagină și faceți clic pe „Inspectați” și navigați la fila „Rețea”. În coloana „Protocol”, puteți vedea protocolul HTTP utilizat pentru conexiune. Conexiunile HTTP/2 apar ca „h2”, în timp ce conexiunile HTTP/3 apar ca „h3-XX” (XX se referă la un anumit proiect HTTP/3). După cum puteți vedea în imaginea de mai jos, kinstalife.com acceptă conexiuni peste „h3-29”, ceea ce înseamnă „HTTP/3 Draft 29”.

Acum că am trecut peste starea actuală a HTTP/3, haideți să aruncăm o privire profundă în unele dintre diferențele dintre HTTP/2 și HTTP/3!

Un pic de fundal – A început cu HTTP/2

HTTP/2 a adus unele îmbunătățiri serioase cu descărcări neblocante, pipeline și server push, care ne-au ajutat să depășim unele limitări ale protocolului TCP de bază. Ne-a permis să minimizăm numărul de cicluri cerere-răspuns și strângeri de mână.

HTTP/2 a făcut posibilă împingerea mai multor resurse într-o singură conexiune TCP – multiplexarea. De asemenea, am primit mai multă flexibilitate în ordonarea descărcărilor statice, iar paginile noastre nu mai sunt acum constrânse de o progresie liniară a descărcărilor.

În practică, aceasta înseamnă că acum o resursă javascript mare nu este neapărat egală cu un punct de sufocare pentru toate celelalte resurse statice care își așteaptă rândul.

Adăugați la aceste lucruri antetul HTTP/2 compresia HPACK și formatul binar implicit de transfer de date și avem, în multe cazuri, un protocol semnificativ mai eficient.

Implementările majore ale browserului au făcut ca site-urile web să implementeze criptarea – SSL – pentru a putea beneficia de beneficiile HTTP/2 – și uneori acest lucru a generat o suprasarcină de calcul care a făcut ca îmbunătățirile de viteză să nu fie observate. Au existat chiar și unele cazuri în care utilizatorii au raportat o încetinire după trecerea la HTTP/2.

Să spunem doar că primele zile ale adoptării acestei versiuni nu au fost pentru cei slabi de inimă.

Implementarea Nginx nu avea și caracteristica server-push, bazându-se pe un modul. Și modulele Nginx nu sunt modulele tale obișnuite Apache pe care le poți copia doar – NGINX trebuie să fie recompilat cu acestea.

În timp ce unele dintre aceste probleme sunt rezolvate acum, dacă ne uităm la întreaga stivă de protocoale, vedem că constrângerea principală se află la un nivel mai scăzut decât a îndrăznit HTTP/2 să se aventureze.

Pentru a elabora acest lucru, vom diseca stiva de protocoale de internet de astăzi de la stratul inferior până în sus. Dacă doriți să aflați mai multe despre fundalul HTTP/2, asigurați-vă că consultați ghidul nostru final HTTP/2.

Protocol Internet (IP)

Protocolul Internet (IP) definește partea de jos a întregii topologii a internetului. Este partea stivei de internet care, putem spune cu siguranță, nu este negociabilă fără a schimba totul, inclusiv înlocuirea întregii infrastructuri hardware, de la routere la servere și chiar mașinile utilizatorilor finali.

Așadar, în timp ce revizuirea protocolului ar putea fi datorată, un efort atât de amplu nu este la orizont în acest moment, în principal pentru că nu am venit cu o alternativă viabilă, revoluționară, dar compatibilă cu înapoi.

Putem urmări începuturile protocolului IP încă din 1974, la o lucrare publicată de Institutul de Ingineri Electrici și Electronici și scrisă de Vint Cerf și Bob Cahn. Detaliază pachetele trimise printr-o rețea, direcționându-le prin adrese IP și adrese definite numeric ale nodurilor dintr-o rețea/rețele. Protocolul a definit formatul acestor pachete sau datagrame - anteturile și sarcina utilă.

După definiția RFC 760 din 1980, IETF s-a stabilit cu definiția utilizată pe scară largă până în prezent, în Request For Comments 791. Aceasta este a patra versiune a protocolului, dar am putea spune că este prima versiune de producție.

Folosește adrese pe 32 de biți, ceea ce stabilește o constrângere pentru numărul de adrese la aproximativ 4 miliarde. Această limitare este explicația misterului de ce utilizatorii de internet non-business primesc „adrese IP dinamice” de către furnizorii lor de servicii de internet, iar o IP statică este considerată o „valoare adăugată” și adesea supusă taxelor suplimentare.

Ei raționalizează.

Nu a trecut mult până când s-a realizat că adresele pe 32 de biți nu sunt suficiente, iar deficitul se profila, așa că au fost publicate multe RFC-uri încercând să facă față acestui lucru. Deși aceste soluții sunt utilizate pe scară largă astăzi și fac parte din viața noastră de zi cu zi, probabil că este sigur să spunem că aceste soluții sunt hack-uri.

Înscrieți-vă pentru Newsletter

Vrei să știi cum ne-am crescut traficul peste 1000%?

Alăturați-vă celor peste 20.000 de persoane care primesc buletinul nostru de știri săptămânal cu sfaturi despre WordPress!

Abonează-te acum

Internet Protocol versiunea 6 sau IPv6 a venit ca o modalitate de a aborda aceste limitări, inclusiv pentru a fi adoptate treptat față de versiunea anterioară. A fost creat un proiect de document standard pentru IETF în 1998 și a fost ridicat la un standard de internet în 2017.

În timp ce spațiul de adrese IPv4 a fost limitat de lungimea adresei de 32 de biți, standardul IPv6 a primit 128 de biți sau 3,4 * 10 ^ 38 de adrese posibile. Acest lucru ar trebui să fie suficient pentru a ne dura ceva timp.

Potrivit Google și conectivitatea IPv6 în rândul utilizatorilor săi, adoptarea IPv6 este puțin peste 35% în iunie 2021.

IP este un strat rudimentar al stivei de internet, care definește cele mai de bază lucruri, fără garanții de livrare, integritatea datelor sau ordonarea pachetelor transmise. Pe cont propriu nu este de încredere. Formatul antetului IPv4 prevede suma de verificare a antetului, pe care nodurile de transmisie o folosesc pentru a verifica integritatea antetului. Acest lucru îl face diferit de versiunea IPv6, care se bazează pe stratul de legătură de dedesubt, permițându-i să fie mai rapid.

Înțelegerea rolului TCP și UDP

Acum este timpul să explorați unde HTTP/3 se potrivește cu TCP și UDP.

TCP

În timp ce IP este stratul de bază al tuturor comunicațiilor noastre online de astăzi, TCP (Transmission Control Protocol) este o parte de nivel superior a suitei de protocoale de internet, oferind fiabilitatea necesară pentru web, e-mail, transfer de fișiere (FTP) - pentru straturi de aplicare/protocoale ale internetului.

Aceasta include stabilirea conexiunii în mai multe etape, cu strângere de mână, ordinea asigurată a pachetelor și retransmiterea pachetelor pierdute. Oferă feedback (Acks) despre livrare expeditorului și așa mai departe. Există, de asemenea, calculul sumei de control pentru a detecta erorile.

Toate aceste lucruri indică o mulțime de pași care fac din TCP un protocol de încredere, făcându-l o bază a celor mai notorii servicii de internet pe care le folosim astăzi.

Specificațiile sale care datează din 1974 (RFC 675) și 1981 (RFC 793) nu s-au schimbat substanțial până în prezent.

Fiabilitatea pe care o oferă TCP nu este, totuși, fără costuri. Costul general al tuturor călătoriilor dus-întors cerute de strângeri de mână, feedback de livrare, garanții de comandă și sume de control care ar putea fi considerate slabe și redundante. A făcut din TCP un blocaj al stivei de protocoale moderne. HTTP/2 a atins un platou de îmbunătățiri ale vitezei care pot fi obținute pe lângă TCP.

UDP

User Datagram Protocol (UDP) este, de asemenea, una dintre părțile Internet Protocol Suite, cu specificațiile sale datând din 1980 (RFC 768).

Este, după cum sugerează și numele, un protocol fără conexiune bazat pe datagrame. Ceea ce înseamnă că nu există strângeri de mână și nu există asigurări de comandă sau livrare. Aceasta înseamnă că orice pași posibili pentru asigurarea livrării, integrității datelor și a altor lucruri sunt lăsați la nivelul stratului de aplicație. Aceasta înseamnă că o aplicație construită pe UDP poate alege strategiile pe care le va folosi în funcție de cazul concret sau poate, eventual, să folosească elemente ale stratului de legătură, cum ar fi sumele de control, pentru a evita supraîncărcarea.

Deoarece UDP este răspândit la fel ca TCP, face posibilă obținerea de îmbunătățiri fără a necesita actualizări de firmware pe o gamă largă de dispozitive conectate la internet sau modificări semnificative ale sistemelor de operare.

Implementarea noilor protocoale este îngreunată de multe firewall-uri, NAT, routere și alte casete intermediare care permit doar implementarea TCP sau UDP între utilizatori și serverele la care trebuie să ajungă. – HTTP/3 explicat

Acest thread de pe Hacker News ne poate ajuta să începem să înțelegem raționamentul din spatele construirii noii versiuni HTTP peste stiva de rețea existentă, mai degrabă decât să o reinventăm (deși există mai mult decât atât).

Specificația formatului de pachete UDP este mai degrabă minimă, antetul său constă din portul sursă, portul de destinație, lungimea, în octeți, antetul și pachetul de date și suma de control. Suma de control poate fi utilizată pentru a verifica integritatea datelor atât pentru antet, cât și pentru partea de date a pachetului.

Suma de verificare este opțională atunci când stratul de protocol de bază este IPv4 și obligatorie cu IPv6. Până acum, UDP a fost folosit pentru lucruri precum sincronizarea ceasului sistemelor computerizate (NTP), aplicații VoIP, streaming video, sistemul DNS și protocolul DHCP.

QUIC și HTTP/3

QUIC (Quick UDP Internet Connections) a fost implementat pentru prima dată de Google în 2012. Acesta redefinește limitele straturilor de rețea, bazându-se pe protocolul UDP de nivel inferior, redefinind strângerile de mână, caracteristicile de fiabilitate și caracteristicile de securitate în „spațiul utilizatorului”, evitând nevoia de modernizarea nucleelor ​​de sisteme la nivel de internet.

La fel ca și în cazul HTTP/2, un progres care a fost condus de SPDY sau rapid de la Google, HTTP/3 se va baza din nou pe aceste realizări.

În timp ce HTTP/2 ne-a oferit multiplexarea și a atenuat blocarea capului de linie, este constrâns de TCP. Puteți utiliza o singură conexiune TCP pentru mai multe fluxuri multiplexate împreună pentru a transfera date, dar atunci când unul dintre aceste fluxuri suferă o pierdere de pachet, întreaga conexiune (și toate fluxurile sale) sunt ținute ostatice, ca să spunem așa, până când TCP își face treaba ( retransmite pachetul pierdut).

Aceasta înseamnă că toate pachetele, chiar dacă sunt deja transmise și în așteptare, în bufferul nodului destinație, sunt blocate până când pachetul pierdut este retransmis. Daniel Stenberg, în cartea sa despre http/3, numește acest lucru un „bloc de șef de linie bazat pe TCP”. El susține că, cu o pierdere de pachete de 2%, utilizatorii se vor descurca mai bine cu HTTP/1, cu șase conexiuni pentru a acoperi acest risc.

QUIC nu este constrâns de acest lucru. Cu QUIC bazat pe protocolul UDP fără conexiune, conceptul de conexiune nu poartă limitările TCP și eșecurile unui flux nu trebuie să influențeze restul.

După cum a spus Lucas Pardue de la Cloudflare:

Axându-se pe fluxurile UDP, QUIC realizează multiplexarea fără a fi nevoit să se apropie de o singură conexiune TCP. QUIC își construiește conexiunea la un nivel mai înalt decât TCP. Noile fluxuri din conexiunile QUIC nu sunt forțate să aștepte ca celelalte să se termine. Conexiunile QUIC beneficiază, de asemenea, de eliminarea overhead de handshake TCP, ceea ce reduce latența.

Oamenii de la Cisco au realizat un videoclip interesant care explică strângerea de mână în trei căi a TCP:

În timp ce QUIC elimină caracteristicile de fiabilitate TCP, o compensează deasupra stratului UDP, oferind retransmiterea pachetelor, comandă și așa mai departe. Google Cloud Platform a introdus suportul QUIC pentru echilibratoarele de încărcare în 2018 și a înregistrat o îmbunătățire a timpului mediu de încărcare a paginii cu 8% la nivel global și cu până la 13% în regiunile în care latența este mai mare.

Între Google Chrome, YouTube, Gmail, căutarea Google și alte servicii, Google a reușit să implementeze QUIC pe o bucată frumoasă de internet, fără să aștepte IETF. Inginerii Google susțin că în 2017, 7% din traficul de internet a fost deja efectuat prin QUIC.

Versiunea Google de QUIC s-a concentrat doar pe transportul HTTP, folosind sintaxa HTTP/2. Oamenii de la IETF (cei responsabili cu standardizarea QUIC), au decis că versiunea IETF a QUIC ar trebui să poată transporta mai mult decât HTTP. Deocamdată, totuși, orice lucru asupra protocoalelor non-HTTP prin QUIC este în așteptare.

Încă un lucru pe care grupul de lucru al IETF a decis că versiunea standardizată va folosi criptarea TLS 1.3 în loc de soluția personalizată Google. TLS 1.3, în comparație cu versiunile mai vechi, contribuie și la viteza protocolului, deoarece strângerile de mână necesită mai puține călătorii dus-întors. Kinsta acceptă TLS 1.3 pe toate serverele noastre și pe CDN-ul nostru Kinsta.

În acest moment, Google continuă să folosească propria sa versiune de QUIC în produsul său, în timp ce își direcționează eforturile de dezvoltare către standardele IETF. Majoritatea celorlalți jucători de internet se bazează pe versiunea IETF (cei doi diferă în alte aspecte, în afară de criptare).

Dacă deschidem Chrome Dev Tools și încărcăm unele dintre produsele Google, cum ar fi Gmail, în coloana Protocol din fila Rețea, vom vedea că se încarcă o mulțime de resurse prin versiunea Google a protocolului QUIC. Acesta este și cazul produselor Google precum Analytics, Google Tag Manager etc.

Cloudflare a publicat o actualizare foarte extinsă despre progresul standardizării.

În timp ce UDP oferă QUIC și HTTP/3 câteva avantaje inerente, aduce și unele provocări.

TCP a fost protocolul mainstream de ani de zile, în timp ce UDP nu, așa că sistemele de operare și stiva de software pentru acesta, în general, nu sunt la fel de optimizate. În consecință, există o încărcare/cerințele CPU mult mai mari cu QUIC, după unele estimări, de două ori mai mult decât cu HTTP/2.

Optimizările merg adânc la nucleul sistemelor de operare și la firmware-ul diferitelor routere și dispozitive. Acest ghid de reglare Red Hat poate arunca mai multă lumină asupra subiectului pentru cei mai înclinați din punct de vedere tehnic.

Am putea spune că QUIC încearcă să reproiecteze funcțiile TCP pe lângă un protocol mai minimal și mai flexibil.

Conexiunile QUIC, despre care am menționat mai devreme, combină TLS și strângeri de mână de transport. Odată stabilite, acestea sunt identificate prin CID-uri unice (ID-uri de conectare). Aceste ID-uri persistă în timpul modificărilor IP și pot ajuta la securizarea descărcărilor neîntrerupte, de exemplu, la trecerea de la 4G la WiFi. Acest lucru este relevant, mai ales pentru că tot mai mult trafic de internet este efectuat pe dispozitivele mobile. Pot apărea întrebări dacă acest element este conceput de Google pentru a facilita o mai bună urmărire a utilizatorilor între diferite conexiuni și furnizori de internet.

TLS este obligatoriu și este menit să îngreuneze dispozitivele din mijloc să modifice sau să adulmece traficul. De aceea, nu este rar să vezi furnizori și furnizori de firewall precum Cisco care văd protocolul UDP ca pe o problemă și să ofere modalități de a-l dezactiva. Este mai greu pentru intermediari să inspecteze și să supravegheze sau să filtreze traficul QUIC.

Fluxurile QUIC sunt trimise prin conexiuni QUIC, unidirecționale sau bidirecționale. Fluxurile au ID-uri care identifică inițiatorul și dacă fluxul este unidirecțional sau bidirecțional și servesc, de asemenea, controlului fluxului în flux.

În timp ce QUIC este un protocol de nivel de transport, HTTP este nivelul de deasupra acestuia, un protocol de nivel de aplicație sau un protocol de aplicație.

Deoarece retrocompatibilitatea este de cea mai mare importanță, IETF a promovat implementarea HTTP/3 și va include versiunea veche (HTT1 sau HTTP/2) în răspuns. Acesta va include un antet care informează clientul că HTTP/3 este disponibil, împreună cu informații despre port/gazdă, așa cum este descris în RFC 7838.

Acesta este diferit de HTTP/2, în care transportul poate fi negociat în cadrul TLS handshake. Dar, din moment ce IETF a adoptat aproape HTTP/3 bazat pe QUIC ca următor standard, ne putem aștepta ca clienții web să anticipeze suportul HTTP/3 din ce în ce mai mult. Este posibil ca clienții să memoreze în cache datele de la conexiunile HTTP/3 anterioare și să se conecteze direct (zero-round-trip sau 0-RTT) în vizitele ulterioare la aceeași gazdă.

rezumat

Există unii care cred că, având în vedere că standardul HTTP/2 nu este încă pe deplin adoptat, poate fi prea devreme pentru a face un impuls larg pentru HTTP/3. Acesta este un punct valid, dar, așa cum am menționat, acest protocol a văzut deja teste și implementări la scară largă. Google a început să-l testeze încă din 2015, precum și Facebook în 2017.

În 2022, avem suport HTTP/3 de la browsere majore precum Google Chrome și Brave. În ceea ce privește infrastructura, serverele web precum Litespeed și Nginx au ambele implementări funcționale ale HTTP/3, în timp ce furnizorii de rețea precum Cloudflare au implementat deja suport complet pentru HTTP/3.

În acest moment, HTTP/3 este încă în faza Internet Draft, iar cea mai recentă revizuire urmează să expire în august 2021. Anul acesta va fi incitant, deoarece ne putem aștepta să vedem mișcarea importanților furnizori de software de a implementa noul standard.