Întrebări frecvente despre HTTP2
Acestea sunt Întrebări frecvente despre HTTP/2.
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.