ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 18
Abonament PDF

Editorial nr. 18

Ovidiu Dolha
Requirements engineer
@ISDC
DIVERSE

O scurtă privire în istoria și dezvoltarea protocolului HTTP (Hypertext Transfer Protocol), pentru a înțelege mai bine modificările propuse pentru versiunea 2.0.

Nevoia de evoluție a protocolului HTTP

HTTP este unul din protocoalele care au alimentat evoluția spectaculoasă a Internetului: permite clienților să comunice cu serverele, fundamentul a ceea ce este azi Internetul. A fost conceput inițial ca un protocol simplu care să asigure transferul unui fișier de la un server către un client (versiunea 0.9 propusă în 1991). Succesul incontestabil al protocolului face ca azi miliarde de dispozitive să fie capabile să comunice folosind HTTP (versiunea curenta 1.1). Variația extraordinară de conținut și de aplicații disponibile azi, împreună cu cerințele utilizatorilor pentru interacțiuni rapide împing HTTP 1.1 peste limitele imaginate de cei care l-au proiectat. Prin urmare, pentru a satisface următorul salt în performanța Internetului este necesară o nouă versiune a protocolului, care să rezolve limitările actuale și să permită o nouă clasă de aplicații, mai performante.

Latență versus lățime de bandă

Latența și lățimea de bandă sunt două caracteristici care dictează performanța traficului de date în rețea.

Latența (dus/dus-întors) se referă la durata în care un pachet se propagă de la sursă la destinație(dus) și retur(dus-întors)

Lățimea de bandă este capacitatea maximă a unui canal de comunicare.

Ca o analogie cu instalațiile sanitare ale unei locuințe, putem considera lățimea de bandă ca fiind diametrul unei țevi pentru apă. Un diametru mai mare permite să treacă mai multă apă. Pe de altă parte, în situația în care țeava e goală, indiferent de diametrul ei, apa va ajunge la destinație doar după ce va străbate întreaga lungime a țevii (latența).

Este intuitiv să judecăm performanța unei conexiuni în funcție de lățimea de bandă (o conexiune de 10 Mbps este mai bună decât una de 5 Mbps), dar lățimea de bandă nu este singurul factor care controlează performanța: de fapt, din cauza particularității aplicațiilor web de a utiliza mai multe conexiuni de scurtă durată, lantența influențează mai mult performanța decât lățimea de bandă.

Figura 1 - Evoluția timpului de încărcare a unei pagini (milisecunde) în funcție de lățimea de bandă (Megabit/s). Reprodusă din Mike Belshe - More Bandwidth Doesn"t Matter (much)
Figura 2 - Evoluția timpului de încărcare a unei pagini (milisecunde) în funcție de latență. Reprodusă din Mike Belshe - More Bandwidth Doesn"t Matter (much)

Concluzia acestor observații este că orice îmbunatățire în lantența comunicației are un efect direct asupra vitezei aplicațiilor web. Dacă prin îmbunătățirea protocoalelor am putea reduce necesarul de comunicare între cele două capete ale unei conexiuni, atunci am putea transfera aceleași date într-un timp mai scurt. Acesta este unul din obiectivele asumate de HTTP 2.0.

Scurtă incursiune în TCP

Pentru a înțelege limitările versiunii 1.1 este util să ne uităm puțin la protocolul TCP (Transmission Control Protocol), care asigură transportul datelor între client și server:

  • la stabilirea unei conexiuni este nevoie de un schimb de trei mesaje (three-way-handshake) între client și server, înainte de trimiterea oricărui pachet de date. Prin urmare latența conexiunii se reflectă direct în viteza cu care se transferă datele.
  • TCP este optimizat pentru conexiunile cu durată mare și pentru transferul unei cantități mari de date pe aceeași conexiune: după stabilirea unei conexiuni un server va crește gradual numărul de pachete trimise către client pe măsură ce primește confirmarea livrării lor (algoritmul slow start). Astfel, lățimea de bandă nu va fi folosită integral imediat ce se realizează conexiunea. Prin contrast, majoritatea aplicațiilor web declanșează multe conexiuni de scurtă durată pentru a transfera conținut (conform HTTP Archive o aplicație web este compusă în medie din 90 de resurse - conținut HTML, Javascript, imagini etc.).

Deși funcționarea HTTP nu este condiționată de TCP ca protocol de transport, unul din obiectivele HTTP 2.0 este modificarea standardului pentru a profita de aceste particularități ale nivelului de transport în scopul îmbunătățirii substanțiale a vitezei percepute de utilizatorii aplicațiilor web.

Limitările HTTP 1.1

Unul din obiectivele HTTP 1.1 a fost de a îmbunătăți performanțele HTTP. Din păcate, deși standardul specifică lucruri cum ar fi procesarea cererilor în paralel (request pipelening), practica a invalidat aplicarea lor din cauza imposibilității utilizării corecte. În acest moment majoritatea browser-elor dezactivează în mod implicit această opțiune. Drept urmare, HTTP 1.1 impune o ordine strictă a cererilor adresate unui server: un client inițiază o cerere către server și trebuie să aștepte răspunsul înainte de a iniția altă cerere pe aceeași conexiune. Astfel, un răspuns de dimensiuni mai mari poate bloca o conexiune fără a permite procesarea altor cereri ale clientului în acest timp. Mai mult, serverul nu are posibilitatea de a acționa conform priorității cererilor unui client.

Dezvoltatorii de aplicații web au găsit soluții de evitare a acestor limitări, care în acest moment sunt considerate practici recomandate pentru performanța aplicațiilor web:

  • majoritatea browser-elor deschid până la șase conexiuni simultane către același domeniu - ca o alternativă la imposibilitatea practică de a cere mai multe resurse în paralel pe aceeași conexiune; am menționat deja că o pagină este compusă în medie din 90 de resurse; dezvoltatorii web au supralicitat această facilitate și distribuie conținut pe domenii diferite (domain sharding) pentru a forța descărcarea cât mai multor resurse în paralel
  • fișierele de același tip (Javascript, CSS - Cascading Style Sheets, imagini) sunt concatenate într-o singură resursă (resource bundling, image sprites) pentru a evita penalizarea impusă de HTTP la descărcarea multor resurse de dimensiuni mici; unele fișiere sunt incluse direct în sursa paginii pentru a evita complet o nouă cerere HTTP.

Deși aceste metode sunt considerate "bune practici de dezvoltare" ele derivă din limitările curente ale standardul HTTP și creează alte probleme: utilizarea mai multor conexiuni și a mai multor domenii pentru a servi o singură pagină care duce la congestionarea rețelelor, operații suplimentare inutile (căutari DNS, inițieri de conexiuni TCP) și încărcarea suplimentară a serverelor și a intermediarilor din rețea (mai multe socketuri ocupate pentru a servi mai multe cereri); concatenarea fișierelor de același tip împiedică stocarea lor eficientă pe client (caching) și contravine modularității aplicațiilor. HTTP 2.0 adresează aceste limitări.

HTTP 2.0: design și obiective

Efortul de îmbunătățire a standardului HTTP este unul considerabil. Ținând cont de răspândirea actuală a protocolului intenția este de a aduce îmbunătățiri clare cu privire la aspectele menționate mai sus, nu de a rescrie sau modifica substanțial specificațiile actuale.

Principalele intenții ale noii versiuni:

  • să îmbunătățească viteza de încărcare a paginilor față de versiunea 1.1,
  • să utilizeze paralelizarea cererilor dar prin intermediul unei singure conexiuni TCP,
  • să păstreze semantica existentă în versiunea 1.1 cu privire la metode, coduri de raspuns, header-e,
  • să definească interacțiunea cu versiunea 1.1.

Paralelizarea cererilor în HTTP 2.0

Schimbarea majoră introdusă în versiunea 2.0 este felul în care conținutul unei cereri HTTP este transmis între server și client. Conținutul este binar, cu scopul de a permite mai multe cereri și răspunsuri în paralel peste aceeași conexiune TCP.

Următoarele noțiuni sunt utile pentru a înțelege mai bine cum anume se realizează paralelizarea cererilor și răspunsurilor:

  • Stream - un schimb de mesaje bidirecțional în cadrul unei conexiuni. Fiecare stream are un identificator și o prioritate.
  • Frame (cadru) - unitatea de bază de comunicare în HTTP 2.0 conținând o zonă de header care identifică stream-ul din care face parte și o zonă de date.
  • Mesaj - o secvență de cadre (frame) care formează un mesaj în HTTP (cerere sau răspuns).

În cadrul unei conexiuni pot exista un număr nelimitat de stream-uri bidirectionale. Comunicarea în cadrul unui stream se realizează prin mesaje, care sunt formate din cadre (frame). Cadrele pot fi livrate în orice ordine și vor fi reasamblate de către client. Acest mecanism de descompunere și recompunere a mesajelor este similar cu cel existent la nivelul protocolului TCP. Este cea mai importantă schimbare din HTTP 2.0, pentru că permite dezvoltatorilor web următoarele:

  • să inițieze mai multe cereri în paralel și să proceseze mai multe răspunsuri în paralel,
  • să folosească o singură conexiune pentru aceste cereri și răspunsuri,
  • să reducă timpul de încărcare al unei pagini datorită reducerii latenței,
  • să elimine din aplicațiile web modificările specifice versiunii 1.1 făcute cu scopul de a îmbunătăți performanța.

Server push

Una din limitările evidente in HTTP 1.1 este imposibilitatea serverului de a trimite răspunsuri multiple pentru o singură cerere a unui client. În cazul unei pagini web,serverul știe că pe lângă conținutul HTML clientul va avea nevoie și de resurse Javascript, imagini, etc. . De ce să nu eliminăm complet nevoia clientului de a cere aceste resurse și să dăm posibilitatea serverului să le trimită ca răspunsuri suplimentare cererii inițiale a clientului? Aceasta este motivația funcționalității numită server push. Funcționalitatea este la fel cu ceea ce se realizează în HTTP 1.1 prin includerea conținutului unor resurse direct în pagina trimisă clientului (inlining). Totuși, marele avantaj al metodei server push este că dă posibilitatea clientului de a stoca în cache resursele astfel primite evitând apeluri ulterioare.

Compresia header-elor

În HTTP 1.1 fiecare cerere făcută de client conține toate header-ele aferente domeniului serverului. În practică aceasta adaugă între 500 și 800 de bytes fiecărei cereri. Îmbunătățirea adusă de HTTP 2.0 este de a nu mai transmite header-ele care nu se schimbă.Ne bazăm pe faptul că avem o singură conexiune deschisă cu serverul, deci serverul poate deduce că o cerere nouă va avea aceleași header-e asemena celei precedente, în caz că nu specificăm altceva. În plus, toată informația cuprinsă în header-e este comprimată pentru eficientizare.

Scurtă privire în viitor

HTTP 2.0 este încă un standard aflat în lucru. Majoritatea ideilor care stau la baza lui au fost preluate din protocolul SPDY, inițiat de Google. SPDY continuă să existe în paralel cu efortul de standardizare a HTTP 2.0 pentru a oferi un teren de încercare și validare a ideilor experimentale. Calendarul anunțat în acest moment presupune ca în toamna anului 2014 specificația HTTP 2.0 să fie finală, urmând ca după acel moment să fie disponibile implementări.

Bazat pe succesul extraordinar al HTTP, versiunea 2.0 încearcă să corecteze limitările actuale și să ofere mecanisme cu care dezvoltarea Internetului să poată fi susținută în continuare.

LANSAREA NUMĂRULUI 87

Prezentări articole și
Panel: Project management

Joi, 19 Septembrie, ora 18:00
Hugo (The Office), Cluj-Napoca

Înregistrează-te

Facebook Meetup

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects