HTTP/2: ce înseamnă noul protocol WWW pentru utilizatorul obişnuit

[pulse.exe]

Internet Engineering Task Force a anunţat acum două zile că a definitivat noul protocol HTTP/2, iar de standardizarea acestuia ne mai desparte doar etapa verificării finale tehnice şi editoriale RFC. Noul protocol este cea mai importantă îmbunătăţire a infrastructurii World Wide Web din ultimii 16 ani, însă ce este totuşi protocolul HTTP/2 şi care sunt avantajele pe care le acesta le are în faţa actualului HTTP/1.1, care a fost standardizat în 1999?

 

De ce avem nevoie de HTTP/2?

 

HTTP a apărut odată cu primul server World Wide Web şi cu limbajul de descriere a paginii HTML, acest protocol fiind fundamentul tehnologic pe care s-a construit întregul Web pe care îl vedem şi îl folosim zilnic. Implementat într-o formă primitivă în 1991, HTTP a fost finalizat în 1996 şi a evoluat la actuala versiune 1.1 trei ani mai târziu. Asociat adesea doar cu browser-ele, HTTP nu este folosit însă doar pentru transferul resurselor Web obişnuite, adică fişiere HTML, pagini de stil CSS sau imagini, ci este utilizat de multe alte aplicaţii pentru streaming-ul audio/video, pentru transferul de fişiere, pentru mesagerie şi uneori chiar pentru VoIP.

 

Un protocol simplu şi omniprezent, HTTP/1.1 are însă câteva deficienţe. Atunci când clientul, (indiferent dacă este vorba de un browser sau o altă aplicaţie) trimite o cerere pentru accesarea unei resurse, serverul deschide o sesiune de transfer şi trimite înapoi datele necesare pentru afişarea informaţiei cerute. Pe vremea când paginile Web erau încă simple, limitările HTTP/1.1 nu erau nici ele atât de evidente, însă pe măsură ce site-urile au început să folosească tot mai mult cod HTML5, JavaScript, CSS şi elemente media audio/video/Flash bogate, arhitectura HTTP a început să dea semne de oboseală.

 

În mod normal, HTTP/1.1 permite transferul mai multor elemente în cadrul unei sesiuni prin intermediul unei unice conexiuni TCP, însă modul de lucru secvenţial al protocolului face ca orice întârziere apărută în procesarea sau transmiterea unui element să provoace întârzierea întregului lanţ care urmează după acesta. În practică, această problemă se face remarcată prin creşterea latenţelor şi mărirea duratelor de încărcare ale unei pagini sau ale unei alte resurse online. Pentru a evita această problemă, unele implementări HTTP/1.1 au limitat sesiunile la transferul unui singur element, practic o revenire la modul de lucru HTTP/1.0, însă această metodă de lucru s-a împiedicat la rândul ei de numărul foarte mare de conexiuni TCP de un client, de limitele serverelor Web, de limitele browser-elor şi de latenţele induse de multiplele negocieri TCP necesare pentru fiecare sesiune HTTP în parte.

 

Ce este HTTP/2?

 

De-a lungul timpului, HTTP/1.1 a primit câteva extensii utile, cum ar fi de pildă HTTP Pipeline, însă nici una dintre acestea nu a adresat problemele fundamentale ale protocolului şi toate s-au lovit de alte deficienţe deja existente. Prima încercare serioasă de îmbunătăţire a fost protocolul SPDY, care a fost dezvoltat de către Google, iar acesta a trebuit să împace două aspecte. Pe de o parte, SPDY a trebuit să folosească o singură conexiune TCP pentru conectarea bidirecţională între server şi client, economisind astfel resursele, însă pe de altă parte a trebuit să eficiente transferul secvenţial prin înlocuirea lui cu mai multe căi paralele de transfer. Plastic vorbind, SPDY a înlocuit o stradă cu o singură bandă cu o şosea cu mai multe benzi paralele şi a adăugat un dispecer s-a ocupat de sortarea vehiculelor în funcţie de tonaj şi viteză pentru a fluidiza cât mai bine traficul.

 

 

HTTP/2 într-o singură imagine

 

Pe lângă multiplexare şi prioritizare, SPYD a adăugat şi alte îmbunătăţiri. Protocolul dezvoltat de către Google a îmbunătăţit latenţele deoarece clientul nu mai face atâtea apeluri iar serverul nu mai este nevoit să răspundă la toate, a comprimat header-ele pentru a reduce şi mai mult latenţa, a adăugat un suport push care-i permite serverului să împingă în avans datele de care clientul va avea nevoie şi le-a completat cu o criptare generală TLS care creează un tunel sigur prin care circulă datele.

 

 

Deşi SDPY este un protocol deschis care a evoluat din 2009 până acum şi a ajuns la versiunea 3.1, a devenit clar că un protocol suportat oficial de către Internet Engineering Task Force ar fi o idee mai bună. Preluând cele mai multe dintre specificaţiile SPDY, la care s-au adăugat pe parcurs modificările aduse de Microsoft HTTP Speed+Mobility şi Network-Friendly HTTP Upgrade, HTTP/2 a devenit treptat un standard bine definit care este acum gata să dea piept cu Internetul.

 

 

Trebuie remarcat totuşi că HTTP/2 nu este o simplă împachetare a vechiului SPDY într-un nou ambalaj. HTTP/2 aduce o serie de îmbunătăţiri importante, printre care se remarcă multiplexarea datelor furnizate de mai multe servere în cadrul unicului canal TCP folosit, diferenţiindu-se astfel de modul de lucru SPDY, care era nevoit să deschidă câte un canal pentru fiecare server accesat. Modul în care sunt stabilite şi controlate priorităţile pachetelor a fost perfecţioant şi a devenit mai eficient. O altă îmbunătăţire este schimbarea algoritmului de compresie a datelor, HTTP/2 renunţând la gzip din SPDY în favoarea algoritmul propriu HPACK şi îmbunătăţind astfel atât performanţa cât şi securitatea.

 

Cât de bun este HTTP/2 şi când îl vom vedea la lucru?

 

Prima întrebare este una dificilă deoarece avantajele HTTP/2 variază în funcţie de tipul de date transferate. O serie de teste făcute cu precursorul SPYD au arătat îmbunătăţiri ale vitezei de încărcare a paginilor care variază între 12 şi 48 de procente, iar alte teste recente arată că, deşi HTTP/2 mai are unele mici deficienţe, acesta îşi învinge părintele SPDY şi desfiinţează bătrânul HTTP/1.1. Utilizatorii trebuie să se aştepte deci la viteze mai mari de încărcare iar aceste îmbunătăţiri vor deveni treptat vizibile în cadrul tuturor browser-elor şi aplicaţiilor care folosesc HTTP.

 

 

Îmbunătăţirile aduse de SPDY (si HTTP/2) conform Twitter

 

În acest moment, HTTP/2 este implementat doar în cadrul browser-elor Microsoft Internet Explorer 11 (doar pe Windows 10), Mozilla Firefox 34 (activat implicit începând cu versiunea 36) şi Google Chrome 40 (neactivat încă în mod implicit). De partea cealaltă, suportul HTTP/2 este implementat în cadrul serverelor Microsoft IIS (Windows 10) şi OpenLiteSpeed, în timp ce faimoasele nginx şi Apache au suport SPDY şi probabil că vor primi module adiţionale pentru HTTP/2 în lunile care vor urma. World Wide Web nu se va schimba în mod cert peste noapte, însă probabil că peste douăsprezece luni vom vedea deja actualizări specifice pentru toate browser-ele, platformele pentru dezvoltare software şi servere.

 

Deşi HTTP/2 este o îmbunătăţire semnificativă a actualului HTTP/1.1, acesta nu schimbă însă şi modul în care clienţii şi serverele interacţionează între ele. HTTP/2 păstrează sintaxa, metodele de interacţiune, codurile de semnalizare şi schema de adresa a resurselor, ceea ce înseamnă că tranziţia de la HTTP/1.1 la HTTP/2 va fi practic invizibilă pentru utilizatori. Aşa cum utilizatorii Chrome sau Firefox au vizitat site-uri care au început să folosească SPDY fără să remarce ceva neobişnuit, tot aşa se va întâmpla şi în cazul migrării la HTTP/2. De asemenea, HTTP/2 este compatibil cu standardele anterioare, iar în cazul în care ori clientul ori serviciul online accesa nu-l implementează, comunicarea se va face prin intermediul vechiului HTTP/1.1.

 

HTTP/2 nu are şi deficienţe?

 

Ca orice altă tehnologie, nici HTTP/2 nu este perfect şi este criticat pentru anumite aspecte. Mai întâi de toate, toate prezentările vorbesc despre criptarea TLS 1.2 şi avantajele acesteia, însă această securizare suplimentară nu este în realitate obligatorie deoarece HTTP/2 poate funcţiona la fel de bine şi în cazul HTTP şi în cazul HTTPS. Criptarea este însă promovată intens de către Internet Engineering Task Force iar Microsoft, Mozilla şi Google au afirmat că nu intenţionează să implementeze HTTP/2 fără criptare, ceea ce înseamnă că aceasta este de-facto obligatorie. Iar acest lucru este o problemă.

 

Mai întâi de toate, criptarea TLS implică utilizarea unor certificate de securitate. Acest aspect nu este o problemă pentru companiile mari, însă proprietarii site-urilor de mai mică anvergură vor descoperi repede că certificatele de securitate sunt cam scumpe şi necesită reînnoiri periodice.

 

Terminalele mobile ar putea fi şi ele afectate de această criptare obligatorie. Criptarea şi decriptarea datelor necesită cicluri suplimentare de procesare, iar dacă acest lucru nu este deranjant în clipa de faţă, autonomia ar putea avea de suferit atunci când întregul Web va necesita criptare.

 

În final, unii specialişti sunt nemulţumiţi deoarece HTTP/2 nu implementează anumite facilităţi suplimentare de natură să asigure intimitatea utilizatorilor, cum ar fi de pildă abandonarea fişierelor cookie în favoarea unor identificatori de sesiune care pot fi controlaţi de către utilizatori.