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.