HTTP/1 sau HTTP/2 pentru un web mai rapid

Obiective HTTP/2

Internet Engineering Task Force (IETF) a aprobat standardul HTTP/2 propus in februarie 2015. HTTP/2 este prima actualizare majora a HTTP (Hypertext Transfer Protocol) de la HTTP/1.1, care a fost standardizat in 1999. Obiectivul principal al HTTP/2 este de a mentine compatibilitatea la nivel inalt cu HTTP/1.1, scazand in acelasi timp latenta. Cu alte cuvinte, evitati sa spargeti Web-ul in timp ce il faceti mai rapid.

Originile SPDY

De la sfarsitul anului 2009, Google a dezvoltat un protocol experimental numit SPDY (pronuntat rapid). SPDY este o marca comerciala a Google si nu un acronim. HTTP/2 sa bazat initial pe experimentul SPDY. De fapt, multi dezvoltatori de baza SPDY au fost implicati in dezvoltarea HTTP/2. Incepand cu februarie 2015, Google a anuntat ca suportul pentru SPDY va fi retras in favoarea HTTP/2 si apoi va fi retras complet in 2016.

HTTP/1.1

In timp ce HTTP/1.1 ne-a servit bine din 1999, a fost proiectat pentru computere si web-ul din acea vreme. Inutil sa spun ca HTTP este de mult asteptat pentru o actualizare. Pentru a descrie cum functioneaza HTTP/1, am realizat urmatoarea diagrama. Urmati numerele si veti vedea ca incepe cu clientul (eventual un browser web) care stabileste o conexiune HTTP/1 la serverul din dreapta.

(2) Clientul/browserul trimite apoi o cerere GET (metoda HTTP) pentru pagina site-ului index.html.
(3) Reprezinta serverul care raspunde cu resursa solicitata.
(4-7) Pentru exemplul nostru simplu, acest ciclu cerere-raspuns continua pentru foile de stil si scripturile in sprijinul acestui document HTML.
(8) In cele din urma, conexiunea HTTP/1 este inchisa.

HTTP/1 sau HTTP/2

Blocarea capului de linie

Dupa cum puteti vedea, clientul/browserul petrece mult timp asteptand fiecare resursa. Deoarece HTTP/1 nu poate face solicitari simultane printr-o singura conexiune, browserele incearca de obicei sa accelereze procesul prin deschiderea mai multor conexiuni.

Conexiuni scumpe

In timp ce conexiunile multiple ajuta, din perspectiva retelei de computere, fiecare este foarte costisitor de deschis. Datorita acestei cheltuieli, browserele moderne sunt limitate la maximum 6-8 conexiuni HTTP/1.1. Cu multe site-uri web care necesita acum 80 sau mai multe resurse, aceste limitari creeaza un blocaj semnificativ de performanta.

Conducte HTTP

HTTP/1.1 a incercat sa corecteze acest blocaj de performanta cu o tehnica numita HTTP Pipelining. Din pacate, a permis totusi un singur raspuns mare sau lent pentru a bloca toate celelalte care au urmat. HTTP Pipelining nu este greu de implementat, este imposibil. Niciun browser modern nu acceptă HTTP Pipelining, deoarece multi intermediari si servere nu reusesc sa-l proceseze corect.

Multiplexare HTTP/2

Multiplexarea permite mesajelor multiple cerere-raspuns sa fie in zbor printr-o singura conexiune HTTP/2, in acelasi timp. Pentru a demonstra cat de mult mai eficienta poate fi o conexiune HTTP/2, am pregatit o comparatie paralela cu HTTP/1. Chiar si in acest exemplu simplist cu doar trei resurse necesare, retineti cat de repede poate incepe redarea paginii web.

Extrapolati aceasta comparatie la o situatie mai comuna de 80 de resurse necesare agravate de costul a 6-8 conexiuni HTTP/1.1 si eficienta unei singure conexiuni HTTP/2 devine clara.

HTTP/1 sau HTTP/2

Factori suplimentari de performanta HTTP/2

Pe langă multiplexare, HTTP/2 este binar in loc de text, cum ar fi HTTP/1. In comparatie cu protocoalele textuale, protocoalele binare sunt mai eficiente de analizat, mai compacte „pe fir” si mai putin predispuse la erori.

HTTP/2 reduce, de asemenea, supraincarcarea prin comprimarea antetelor sale, in timp ce HTTP/1 nu.

Server Push

Server Push este un mecanism HTTP/2 pentru trimiterea datelor inainte ca clientii sa le solicite. De exemplu, daca se face o solicitare pentru pagina dvs. de pornire, serverul ar putea raspunde cu pagina de pornire plus logo-ul si foile de stil, deoarece stie ca clientul va avea nevoie de toate. Acest lucru este in esenta acelasi cu introducerea tuturor resurselor intr-un document HTML, cu exceptia faptului ca resursele impinse ar putea fi stocate in cache.

Un dezavantaj al Server Push este posibila redundanta in cazurile in care clientul a stocat deja in cache resursele. Acesta este motivul pentru care va recomand sa folositi Server Hints.

Aveti nevoie de ajutor cu Linux Server sau WordPress?