ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 21
Abonament PDF

Înapoi în viitor: Http 2.0

Rareș Rusu
Inginer Software
@Betfair



PROGRAMARE


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 144

Modern Agile

joi, 20 iunie, ora 18:00

sediul msg systems Romania

Facebook Meetup StreamEvent YouTube

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Colors in projects