Acestea sunt Întrebări frecvente despre HTTP/2.

toate acestea

Intrebari generale

De ce să revizuiți HTTP?

HTTP/1.1 a funcționat bine pe Web de mai bine de cincisprezece ani, dar vârsta sa începe să se manifeste.

Încărcarea unei pagini web este mai mare decât oricând (consultați statisticile dimensiunii paginii arhivei HTTP) și încărcarea eficientă a tuturor acestor active este dificilă, deoarece HTTP permite practic doar o singură solicitare remarcabilă pentru fiecare conexiune TCP.

În trecut, browserele au folosit mai multe conexiuni TCP pentru a emite cereri paralele. Cu toate acestea, există limite în acest sens; dacă se utilizează prea multe conexiuni, este atât contraproductiv (controlul congestiei TCP este negat efectiv, ceea ce duce la evenimente de congestie care afectează performanța și rețeaua) și este fundamental nedrept (deoarece browserele iau mai mult decât partea lor din resursele rețelei).

În același timp, numărul mare de solicitări înseamnă o mulțime de date duplicate „pe fir”.

Ambii factori înseamnă că solicitările HTTP/1.1 au o mulțime de cheltuieli generale asociate; dacă se fac prea multe solicitări, dăunează performanței.

Acest lucru a condus industria într-un loc în care se consideră cele mai bune practici pentru a face lucruri precum spriting, date: inlining, sharding de domenii și concatenare. Aceste hacks sunt indicații ale problemelor care stau la baza protocolului în sine și cauzează o serie de probleme pe cont propriu atunci când sunt utilizate.

Cine a realizat HTTP/2?

HTTP/2 a fost dezvoltat de Grupul de lucru HTTP al IETF, care menține protocolul HTTP. Este alcătuit dintr-un număr de implementatori HTTP, utilizatori, operatori de rețea și experți HTTP.

Rețineți că, deși lista noastră de corespondență este găzduită pe site-ul W3C, acesta nu este un efort W3C. Cu toate acestea, Tim Berners-Lee și W3C TAG sunt la curent cu progresele WG.

Un număr mare de oameni au contribuit la efort, dar cei mai activi participanți includ ingineri din proiecte „mari” precum Firefox, Chrome, Twitter, stiva HTTP a Microsoft, Curl și Akamai, precum și un număr de implementatori HTTP în limbi precum Python, Ruby și NodeJS.

Pentru a afla mai multe despre participarea la IETF, consultați Tao-ul IETF; puteți, de asemenea, să înțelegeți cine contribuie la specificațiile din graficul contribuitorilor Github și cine implementează pe lista noastră de implementare.

Care este relația cu SPDY?

HTTP/2 a fost discutat pentru prima dată când a devenit evident că SPDY câștiga tracțiune cu implementatorii (cum ar fi Mozilla și nginx) și prezenta îmbunătățiri semnificative față de HTTP/1.x.

După un apel pentru propuneri și un proces de selecție, SPDY/2 a fost ales ca bază pentru HTTP/2. De atunci, au existat o serie de schimbări, pe baza discuțiilor din grupul de lucru și a feedback-ului din partea implementatorilor.

De-a lungul procesului, dezvoltatorii de bază ai SPDY au fost implicați în dezvoltarea HTTP/2, inclusiv Mike Belshe și Roberto Peon.

În februarie 2015, Google și-a anunțat planurile de a elimina suportul pentru SPDY în favoarea HTTP/2.

Este HTTP/2.0 sau HTTP/2?

Grupul de lucru a decis să renunțe la versiunea minoră („.0”), deoarece a provocat o mare confuzie în HTTP/1.x.

Cu alte cuvinte, versiunea HTTP indică doar compatibilitatea firelor, nu seturile de caracteristici sau „marketing”.

Care sunt diferențele cheie față de HTTP/1.x?

La un nivel ridicat, HTTP/2:

  • este binar, în loc de text
  • este complet multiplexat, în loc de ordonat și blocat
  • poate folosi deci o conexiune pentru paralelism
  • folosește compresia antetului pentru a reduce cheltuielile
  • permite serverelor să „împingă” răspunsurile proactiv în cache-urile clientului

De ce este HTTP/2 binar?

Protocoalele binare sunt mai eficiente de analizat, mai compacte „pe fir” și, cel mai important, sunt mult mai puțin predispuse la erori, în comparație cu protocoalele textuale precum HTTP/1.x, deoarece au adesea o serie de avantaje pentru a le ajuta ” Cu lucruri precum gestionarea spațiului alb, scrierea cu majuscule, terminările de linie, liniile goale și așa mai departe.

De exemplu, HTTP/1.1 definește patru moduri diferite de a analiza un mesaj; în HTTP/2, există doar o cale de cod.

Este adevărat că HTTP/2 nu este utilizabil prin telnet, dar avem deja un anumit suport pentru instrumente, cum ar fi un plugin Wireshark.

De ce este multiplexat HTTP/2?

HTTP/1.x are o problemă numită „blocarea capului de linie”, unde efectiv o singură cerere poate fi restantă la o conexiune la un moment dat.

HTTP/1.1 a încercat să remedieze acest lucru cu linii de conducte, dar nu a rezolvat complet problema (un răspuns mare sau lent poate bloca în continuare pe alții în spatele acestuia). În plus, canalizarea a fost considerată foarte dificil de implementat, deoarece mulți intermediari și servere nu o procesează corect.

Acest lucru îi obligă pe clienți să folosească o serie de euristici (adesea ghicitoare) pentru a determina ce solicitări trebuie să pună pe ce conexiune cu originea când; deoarece este obișnuit ca o pagină să încarce de 10 ori (sau mai mult) numărul de conexiuni disponibile, acest lucru poate avea un impact grav asupra performanței, ducând deseori la o „cascadă” de solicitări blocate.

Multiplexarea abordează aceste probleme permițând ca mai multe mesaje de solicitare și răspuns să fie în zbor în același timp; este chiar posibil să amestecați părți ale unui mesaj cu altul pe fir.

Acest lucru, la rândul său, permite unui client să utilizeze o singură conexiune pe origine pentru a încărca o pagină.

De ce doar o conexiune TCP?

Cu HTTP/1, browserele deschid între patru și opt conexiuni pe origine. Deoarece multe site-uri folosesc mai multe origini, acest lucru ar putea însemna că o singură încărcare a paginii deschide mai mult de treizeci de conexiuni.

O aplicație care deschide atât de multe conexiuni rupe simultan o mulțime de ipoteze pe care TCP a fost construit; deoarece fiecare conexiune va începe un flux de date în răspuns, există un risc real ca tampoanele din rețeaua intermediară să se revărseze, provocând un eveniment de congestie și retransmite.

În plus, folosirea a atât de multe conexiuni monopolizează pe nedrept resursele de rețea, „furându-le” de la alte aplicații cu comportament mai bun (de exemplu, VoIP).

Care este avantajul Server Push?

Când un browser solicită o pagină, serverul trimite codul HTML ca răspuns și apoi trebuie să aștepte ca browserul să analizeze HTML și să emită cereri pentru toate activele încorporate înainte ca acesta să poată începe să trimită JavaScript, imagini și CSS.

Server Push îi permite serverului să evite această călătorie dus-întors prin „împingerea” răspunsurilor pe care crede că le va avea nevoie clientul în memoria cache.

Cu toate acestea, împingerea răspunsurilor nu este „magică” - dacă este utilizată incorect, poate afecta performanța. Utilizarea corectă a Server Push este un domeniu continuu de experimentare și cercetare.

De ce avem nevoie de compresie antet?

Patrick McManus de la Mozilla a arătat acest lucru în mod viu, calculând efectul antetelor pentru o încărcare medie a paginii.

Dacă presupuneți că o pagină are aproximativ 80 de materiale (ceea ce este conservator pe web-ul de astăzi) și fiecare solicitare are 1400 de octeți de antete (din nou, nu neobișnuit, datorită cookie-urilor, referitorului etc.), este nevoie de cel puțin 7-8 excursii dus-întors pentru a scoate anteturile „pe fir”. Asta nu contează timpul de răspuns - asta este doar pentru a-i scoate din client.

Acest lucru se datorează mecanismului de pornire lentă a TCP, care împachetează pachetele pe conexiuni noi în funcție de câte pachete au fost recunoscute - limitând efectiv numărul de pachete care pot fi trimise pentru primele câteva călătorii dus-întors.

În comparație, chiar și o compresie ușoară pe anteturi permite acestor solicitări să ajungă pe fir într-un singur dus-întors - poate chiar un singur pachet.

Această cheltuială generală este considerabilă, mai ales când luați în considerare impactul asupra clienților mobili, care văd de obicei o latență dus-întors de câteva sute de milisecunde, chiar și în condiții bune.

De ce HPACK?

SPDY/2 a propus utilizarea unui singur context GZIP în fiecare direcție pentru compresia antetului, care a fost ușor de implementat, dar și eficient.

De atunci, a fost documentat un atac major împotriva utilizării compresiei de flux (cum ar fi GZIP) în cadrul criptării; INFRACȚIUNE.

Cu CRIME, este posibil ca un atacator care are capacitatea de a injecta date în fluxul criptat să „testeze” textul clar și să îl recupereze. Deoarece acesta este Web, JavaScript face acest lucru posibil și au existat demonstrații de recuperare a cookie-urilor și jetoanelor de autentificare folosind CRIME pentru resurse HTTP protejate TLS.

Ca urmare, nu am putut folosi compresia GZIP. Nu găsim alți algoritmi care să fie adecvați pentru acest caz de utilizare, precum și siguri de utilizat, am creat o nouă schemă de compresie specifică antetului care funcționează cu o granularitate grosieră; deoarece anteturile HTTP nu se schimbă adesea între mesaje, acest lucru oferă în continuare o eficiență de compresie rezonabilă și este mult mai sigur.

Poate HTTP/2 să îmbunătățească cookie-urile (sau alte antete)?

Acest efort a fost creat pentru a lucra la o revizuire a protocolului de sârmă - adică, modul în care anteturile HTTP, metodele etc. sunt puse „pe fir”, nu schimbă semantica HTTP.

Asta pentru că HTTP este atât de utilizat. Dacă am folosi această versiune de HTTP pentru a introduce un nou mecanism de stare (un exemplu care a fost discutat) sau pentru a schimba metodele de bază (din fericire, acest lucru nu a fost încă propus), ar însemna că noul protocol a fost incompatibil cu Web-ul existent.

În special, dorim să putem traduce de la HTTP/1 la HTTP/2 și înapoi fără pierderi de informații. Dacă am începe să „curățăm” anteturile (și majoritatea vor fi de acord că anteturile HTTP sunt destul de dezordonate), am avea probleme de interoperabilitate cu o mare parte din Web-ul existent.

A face acest lucru ar crea doar fricțiuni împotriva adoptării noului protocol.

Acestea fiind spuse, Grupul de lucru HTTP este responsabil pentru toate HTTP, nu doar HTTP/2. Ca atare, putem lucra la noi mecanisme care sunt independente de versiune, atâta timp cât sunt compatibile înapoi cu Web-ul existent.

Dar utilizatorii HTTP care nu sunt browser?

Aplicațiile non-browser ar trebui să poată utiliza și HTTP/2, dacă folosesc deja HTTP.

Feedback-ul timpuriu a fost că HTTP/2 are caracteristici bune de performanță pentru „API-urile” HTTP, deoarece API-urile nu trebuie să ia în considerare lucruri cum ar fi solicitarea cheltuielilor generale în proiectarea lor.

Acestea fiind spuse, accentul principal al îmbunătățirilor pe care le luăm în considerare sunt cazurile de utilizare tipice ale navigării, deoarece acesta este cazul de bază al protocolului.

Carta noastră spune asta despre aceasta:

HTTP/2 necesită criptare?

Nu. După o discuție amplă, grupul de lucru nu a avut consens pentru a solicita utilizarea criptării (de exemplu, TLS) pentru noul protocol.

Cu toate acestea, unele implementări au afirmat că vor accepta HTTP/2 numai atunci când este utilizat printr-o conexiune criptată, iar în prezent niciun browser nu acceptă HTTP/2 necriptat.

Ce face HTTP/2 pentru a îmbunătăți securitatea?

HTTP/2 definește un profil TLS care este necesar; aceasta include versiunea, o listă neagră de ciphersuite și extensiile utilizate.

Consultați specificațiile pentru detalii.

Există, de asemenea, o discuție despre mecanisme suplimentare, cum ar fi utilizarea TLS pentru HTTP: // URL-uri (așa-numita „criptare oportunistă”); vezi RFC 8164.

Pot folosi HTTP/2 acum?

În browsere, HTTP/2 este acceptat de cele mai recente versiuni de Edge, Safari, Firefox și Chrome. Alte browsere bazate pe Blink vor accepta, de asemenea, HTTP/2 (de exemplu, Opera și Yandex Browser). Consultați caniuse pentru mai multe detalii.

Există, de asemenea, mai multe servere disponibile (inclusiv asistență beta de pe principalele site-uri Akamai, Google și Twitter) și o serie de implementări Open Source pe care le puteți implementa și testa.

Consultați lista de implementări pentru mai multe detalii.

HTTP/2 va înlocui HTTP/1.x?

Scopul grupului de lucru este ca utilizările tipice ale HTTP/1.x să poată utiliza HTTP/2 și să vadă unele beneficii. Acestea fiind spuse, nu putem forța lumea să migreze și, din cauza modului în care oamenii implementează proxy-uri și servere, este probabil ca HTTP/1.x să fie în uz încă de ceva timp.

Va exista un HTTP/3?

Dacă mecanismul de negociere introdus de HTTP/2 funcționează bine, ar trebui să fie posibilă acceptarea noilor versiuni de HTTP mult mai ușor decât în ​​trecut.

Întrebări de implementare

De ce regulile în jurul Continuării pe cadrele HEADERS?

Continuarea există, deoarece o singură valoare (de exemplu, Set-Cookie) ar putea depăși 16 KiB - 1, ceea ce înseamnă că nu s-ar putea încadra într-un singur cadru. S-a decis că cel mai puțin predispus la erori pentru a rezolva acest lucru a fost acela de a solicita ca toate datele antetelor să vină în cadre back-to-back, ceea ce a facilitat decodarea și gestionarea bufferului.

Care este dimensiunea minimă sau maximă a stării HPACK?

Receptorul controlează întotdeauna cantitatea de memorie utilizată în HPACK și o poate seta la zero la minimum, cu un maxim raportat la numărul întreg reprezentabil maxim într-un cadru SETTINGS, în prezent 2 ^ 32 - 1.

Cum pot evita păstrarea stării HPACK?

Trimiteți o dimensiune a stării setării cadrului SETTINGS (SETTINGS_HEADER_TABLE_SIZE) la zero, apoi RST toate fluxurile până când a fost primit un cadru SETTINGS cu setul de biți ACK.

De ce există un singur context de compresie/control al fluxului?

Propunerile inițiale aveau grupuri de fluxuri, care ar împărtăși contextul, controlul fluxului etc. Deși acest lucru ar aduce beneficii proxy-urilor (și experienței utilizatorilor care le parcurg), acest lucru a adăugat un pic de complexitate. S-a decis să mergem cu simplul lucru de la început, să vedem cât de dureros a fost și să abordăm durerea (dacă există) într-o viitoare revizuire a protocolului.

De ce există un simbol EOS în HPACK?

Codificarea huffman HPACK, din motive de eficiență și securitate a procesorului, împarte șirurile codate huffman la următoarea limită de octeți; poate exista între 0-7 biți de umplutură necesari pentru orice șir particular.

Dacă se ia în considerare decodarea huffman în mod izolat, orice simbol care este mai lung decât umplutura necesară ar funcționa; cu toate acestea, designul HPACK permite compararea bytewise a șirurilor codate huffman. Cerând ca biții simbolului EOS să fie utilizați pentru umplere, ne asigurăm că utilizatorii pot compara bytewise șirurile codate huffman pentru a determina egalitatea. La rândul său, acest lucru înseamnă că multe antete pot fi interpretate fără a fi decodate huffman.

Pot implementa HTTP/2 fără a implementa HTTP/1.1?

Pentru HTTP/2 peste TLS (h2), dacă nu implementați identificatorul ALPN http1.1, atunci nu va trebui să acceptați nici o caracteristică HTTP/1.1.

Pentru HTTP/2 peste TCP (h2c), trebuie să implementați cererea inițială de actualizare.

h2c - numai clienții vor trebui să genereze o cerere OPȚIUNI pentru „*” sau o cerere HEAD pentru „/”, care sunt destul de sigure și ușor de construit. Clienții care doresc să implementeze HTTP/2 vor trebui să trateze răspunsurile HTTP/1.1 fără un cod de stare 101 ca erori.

h2c - numai serverele pot accepta o cerere care conține câmpul de antet Upgrade cu un răspuns 101 fix. Solicitările fără simbolul de actualizare h2c pot fi respinse cu un cod de stare 505 (versiunea HTTP neacceptată) care conține câmpul antet Upgrade. Serverele care nu doresc să proceseze răspunsul HTTP/1.1 ar trebui să respingă fluxul 1 cu un cod de eroare REFUSED_STREAM imediat după trimiterea prefaței conexiunii pentru a încuraja clientul să reîncerce solicitarea prin conexiunea HTTP/2 actualizată.

Este incorect exemplul de prioritate din secțiunea 5.3.2?

Nu. Fluxul B are greutatea 4, fluxul C are greutatea 12. Pentru a determina proporția resurselor disponibile pe care le primește fiecare dintre aceste fluxuri, sumați toate greutățile (16) și împărțiți fiecare greutate a fluxului la greutatea totală. Prin urmare, fluxul B primește un sfert din resursele disponibile, iar fluxul C primește trei sferturi. În consecință, după cum se specifică în specificație: fluxul B primește în mod ideal o treime din resursele alocate fluxului C.

Voi avea nevoie de TCP_NODELAY pentru conexiunile mele HTTP/2?

Da, probabil. Chiar și pentru o implementare din partea clientului care descarcă doar o mulțime de date folosind un singur flux, unele pachete vor fi în continuare necesare pentru a fi trimise înapoi în direcția opusă pentru a atinge viteze maxime de transfer. Fără setarea TCP_NODELAY (permițând în continuare algoritmul Nagle), pachetele de ieșire pot fi reținute pentru o perioadă de timp pentru a le permite să se îmbine cu unul ulterior.

În cazurile în care un astfel de pachet, de exemplu, este un pachet care îi spune peerului că există mai multe ferestre disponibile pentru a trimite date, întârzierea trimiterii acestuia pentru mai multe milisecunde (sau mai multe) poate avea un impact sever asupra conexiunilor de mare viteză.

Întrebări privind implementarea

Cum depan HTTP/2 dacă este criptat?

Există multe modalități de a obține acces la datele aplicației, dar cea mai ușoară este să utilizați keylogging-ul NSS în combinație cu pluginul Wireshark (inclus în lansările recente de dezvoltare). Acest lucru funcționează atât cu Firefox, cât și cu Chrome.

Cum pot folosi HTTP/2 server push?

Apăsarea serverului HTTP/2 permite unui server să furnizeze conținut clienților fără a aștepta o cerere. Acest lucru poate îmbunătăți timpul de recuperare a unei resurse, în special pentru conexiunile cu un produs mare de întârziere a lățimii de bandă, în care timpul dus-întors de rețea cuprinde cea mai mare parte a timpului petrecut pe o resursă.

Împingerea resurselor care variază în funcție de conținutul unei cereri ar putea fi neînțeleaptă. În prezent, browserele folosesc solicitări push numai dacă altfel ar face o solicitare de potrivire (vezi Secțiunea 4 din RFC 7234).

Unele cache nu respectă variațiile din toate câmpurile antetului cererii, chiar dacă sunt listate în câmpul antet Vary. Pentru a maximiza probabilitatea ca o resursă împinsă să fie acceptată, negocierea conținutului este cel mai bine evitată. Negocierea conținutului bazată pe câmpul de antet de codare acceptată este respectată pe scară largă de cache, dar alte câmpuri de antet ar putea să nu fie la fel de bine acceptate.