Izvor: SIS Wiki

Skoči na: orijentacija, traži

Jelena Jelinić, Nikolina Magdić

Sadržaj

Uvod

Google developeri Mike Belshe i Roberto Peon krajem 2009. godine krenuli s razvojem bržeg interneta i to su pokušali ostvariti novim protokolom SPDY. Posljednjih trinaest godina u upotrebi je ista verzija HTTP-a koja više nije dovoljno dobra za današnje zahtjeve.

Ciljevi SPDY-a su [4]:

  •50% smanjenja vremena učitavanja stranice
  •Smanjiti složenost implementacije
  •Izbjegnuti promjene sadržaja putem web autora
  •Riješiti suradnju preko open-source softvera

Trenutno SPDY podržava Google Chrome, Mozilla Firefox i Amazonov Silk pretraživač za Kindle, implementirana je verzija 2, a na verziji 3 se trenunto radi.

SPDY dizajn i svojstva

SPDY dodaje sloj veze na vrh SSL-a koji dopušta višestruke istovremene streamove preko jedne jedine TCP veze. Uobičajeni HTTP GET i POST poruke su ostale iste, a SPDY je specificirao novi framing format za šifriranje i prijenos podataka preko žice.

Slika 2.1: SPDY dizajn

SPDY/2 temelji se na HTTP/1.1. tj. zadržava istu semantiku, ali zamjenjuju aspekte prijenosa sa jednostavnijim pristupom. Tri osnovne značajke koje utječu na ubrzanje učitavanje stranice [4]:

Multipleksirani stream - temeljna prednost SPDY-a je da se višestruki resurs može preuzeti putem jedne TCP veze. Pretpostavlja se da će klijent otvoriti jednu TCP vezu na svaki poslužitelj i zatražiti sve resurse poslužitelja preko te jedne veze. Takav način korištenja TCP veze omogućuje algoritam u TCP da izbjegne zagušenje za učinkovitije upravljanje protokom podataka preko mreže. Također klijent može uključivati više zahtjeva u jednoj poruci, čime se smanjuje opterećenje i broj vremena obilaska potrebnih za početak prijenosa datoteka za request beyond the first. Iako je takav način sličan HTTP-ovom 'pipelining-u', razlika koju je uveo SPDY je ta da poslužitelj može prenijeti sve resurse paralelno bez HOL blocking problema koji se može pojaviti u HTTP pipeliningu.

Zahtjev prioriteta – dok SPDY može poslužiti za smanjenje ukupnog vremena učitavanja stranice, jedna nuspojava stream multipleksiranja je da resurs kritične stranice može biti dostavljen sporije zbog istodobne isporuke manje kritičnih resursa. Da bi to spriječili, SPDY pruža način klijentima koji označava relativne prioritete za traženim resursima. Na primjer, ako JavaScript biblioteka traži u poretku za generiranje URL-ova za resurse dodatne stranice, klijent može zatražiti da biblioteka bude dostavljena s najvećim prioritetom tako da se ne drži do onih naknadno zahtjevanih.

HTTP zaglavlje kompresije – SPDY nalaže da HTTP zaglavlja budu kompresirana da bi smanjila broj prenesenih bajtova. HTTP kompresija zaglavlja je Internet standard, ali se ne koristi često dok Googleov SPDY to zahtjeva. To bi mogao biti prilično mali dobitak na odgovor zaglavlja, ali to može pružiti značajnu prednost na zahtjeve (koji u mnogim slučajevima su u cijelosti zaglavlja). Na primjer, svaki zahtjev od posebnog klijenta posebnom serveru uključuje identičan korisnički-agent string (koji može biti u više od 100 bajtova) i u nekim slučajevima isti kolačić je poslan u svakom zahtjevu. Chromovi i Firefox developeri su postigli približno 90% kompresije zaglavlja koristeći predloženu zlib kompresiju. To bi moglo omogućiti mnogo više zahtjeva upakiranih u svaki paket zahtjeva.

SPDY također ima dvije napredne značajke koje se mogu koristiti u određenim slučajevima[4]:

'Push poslužitelj (eng. Server Push)' Glavna razlika s obzirom na dosadašnji način rada interneta, jest da poslužitelj može također inicirati stream da bi poslao web resurse koje klijent uopće nije zatražio, a poslužitelj je prepoznao da mu trebaju. Očekuje se da će klijent gurnuti resurse u cache i dohvatiti po potrebi. Ova funkcija se može koristiti i za guranje resursa za srodne stranice koje bi korisnik vjerojatno zatražio.

Savjet poslužitelja (eng. Server Hint) Server Hint je mehanizam gdje server može obavijestiti klijenta o resursima koji će biti potrebni prije nego ih klijent može otkriti. Server ne šalje cijeli sadržaj resursa,nego samo URL kao dio ranijeg dogovora. Klijent tada može potvrditi svoju cache memoriju (potencijalno čak eliminirajući potrebu za GET-if-modified-since) i formalno će zatražiti resurs samo ako je potrebno. Server Hint je implementiran korištenjem LINK zaglavlja s HTTP i preklapa se s postojećim semantikama veze. Usporedna te divje napredne značajke prikazana je u tablici

Slika 2.2: Usporedba

Za sigurniju komunikaciju SPDY/2 korisiti šifriranu (TLS) vezu.

Razlozi su sljedeći [4]:

TLS (eng. Transport Layer Security) radi tako da se poslužitelj i klijent dogovaraju o načinu šifriranja prije uspostavljanja veze.Umjesto da SPDY uvede novi URI(eng. Uniform Resource Identifier) spdy://URI, pomoću NPN-a (eng. Next Protocol Nefotiation) dopušta korištenje https:// URI i za klijente koji ne podržavaju SPDY kao što je Internet Explorer.

TLS prolazi kroz firewall i zaobilazi posrednike. Mnogi HTTP zahtjevi obrađeni su transparentim proxy-embez znanja korisnika. To može predstavljati problem za primjenu SPDY-a ako bude potrebno unaprijediti posrednike za novi protokol.

Implementacija SPDY-a na poslužitelju

Postoje mnoge implementacije SPDY-a na poslužitelju, međutim još su u fazi razvoja. Trenutno postoje dvije implementacije koje podržavaju SPDY/2. Prva je Chrome "FLIP poslužitelj" koja je također opensource, a služi za testiranje razlika između HTTP-a i SPDY-a. Druga je Javascrip implementacija node-spdy koja je razvijena na node.js. Također postoji i modul za Apache web poslužitelj i naziva se mod_pagespeed kojem je cilj automatski izvršiti optimizaciju na web aplikacijama. Trenutno SPDY koriste pretraživači Chrome, Mozilla Firefox i Opera. Također, Silk pretraživač na Amazon Kindle Fire tabletu koristi SPDY/2 da bi se spajao na Amazon BC2. Web stranice koje koriste SPDY su Facebook, Twitter, te svi Google-ovi servisi kao što su Gmail, Googledocs, Picasa, Google+ i Googleovo kodirano istraživanje.

Dva sloja SPDY protokola

HTTP koristi višestruka povezivanja za istodobnost i to uzrokuje probleme kao što su: vrijeme obilaska za uspostavljanje veze, kašnjenja sporog starta i racionalizacija veze od strane klijenta. Zbog toga SPDY dodaje framing layer za multipleksirane višestruke streamove koji se odvijaju istodobno preko jedne TCP veze. Framing layer je optimalan za aplikacije koje rade preko HTTP-a, a sada mogu raditi i preko SPDY uz minimalne ili nikakve izmjene.

SPDY Framing Layer

SPDY framing layer (sesija) izvršava se na vrhu pouzdanog TCP protokola. Klijent je inicijator TCP veze.

Framing

Nakon što je veza uspostavljena klijenti i poslužitelji razmjenjuju uokvirene poruke (eng. Framed messages). Postoje dvije vrste okvira, a to su: kontrolni i podatkovni. Zaglavlje je uobičajeno od 8 bajtova. Prvi je kontrolni bit koji upućuje na to koja je vrsta okvira, znači podatkovni ili kontrolni. U kontrolnom okviru nalazi se broj verzije, tip okvira, zastavice i duljina. Podatkovni okviri sadrže ID strujanja (ID stream), zastavice i duljinu payloada.

Kontrolni okvir [3]

Slika 3.1: Kontrolni okvir

Kontrolni bit: 'C' bit nagoviještava da li se radi o kontrolnoj poruci i u ovom sluačju ta vrijednost je uvijek 1.

Verzija: broj verzije SPDY protokola, trenutno je zadnje verzija 3.

Vrsta kontrolnog okvira: SYN_STREAM, SYN_REPLAY, RST_STREAM, SETTINGS, PING, GOAWAY, HEADERS, WINDOW_UPDATE, CREDENTIAL.

Zastavice: Zastavice koje se odnose na kontrolni okvir i razlikuju se od podatkovnog.

Duljina: neododijeljena 24-bitna vrijednost koja predstavlja broj bajtova nakon polja duljine.

Podatak: dužina i oblik podatka ovise o vrsti kontrolnog okvira

Podatkovni okvir [3]

Slika 3.2: Podatkovni okvir

Kontrolni bit: za podatkovne okvire ova vrijednost je uvijk 0

Stream-ID: 31-bitna vrijednost identificira strujanje

Zastavice:

0x01 = FLAG_FIN – označava da je taj okvir zadnji koji se prenosi tim strujanjem

0x02 = FLAG_COMPRESS – označava da su podaci u tom okviru kompresirani

Dužina: nedodijeljena 24-bitna vrijednost koja predstavlja broj bajtova nakon polja dužine. Ukupna veličina podatkovnog okvira je 8 bajtova + duljina.

Podaci: varijabilna dužina payloada koja je definirana u polju dužine.

Stream

Streamovi su nezavisne sekvence dvosjmernih podataka podijljenih u okvire sa sljedećim svojstvima:

Mogu bit kreirani od strane klijenta kao i poslužitelja

Mogu nositi set zaglavlja parova ime/vrijednost

Mogu istovremeno slati podatke izmjenično s drugim streamovima

Mogu biti otkazani

Stream okviri Da bi SPDY upravljao životnim ciklusom streama definirana su 3 kontrolna okvira:

SYN_STREAM – otvara stream

SYN_REPLY – daljinsko saznanje o novom streamu

RST_STREAM – zatvara stream

Stvaranje streama

Stream se kreira slanjem kontrolnog okvira SYN_STREAM. Ako poslužitelj inicira stream tada Stream_ID mora biti paran, a ako je klijent tajkoji započinje tada Stream_ID mora biti neparan. Stvaranjem streama sa svake strane veze Stream_ID obavezno mora rasti. Ako dođe do nepravilnosti primjerice da krajnja točka primi SYN_STREAM kojem je ID manji nego bilo koji prethodno primljeni SYN_STREAM tada mora izbaciti PROCOL_ERROR. Odmah nakon kreiranja streama šalje se HEADERS ili DATA okvir, nije potrebno čekati primatelja da potvrdi.

Prioritet streama

Onaj tko kreira stream odmah mu dodjeljuje i prioritet koji se kreće u rasponu od 0 do 7. 0 predstavlja najviši prioritet, a 7 najniži.

Izmjena podataka

Nakon što je stream kreiran njime se može slati proizvoljan iznos podataka, tj. podaci će slati sve dok ne dođe okvir koji sadrži FLAG_FIN zastavicu. FLAF_FIN zastavica može biti postavljena na SYN_STREAM, SYN_REPLY, HEADERS i DATA okvirima. Nakon što je poslana FLAG_FIN zastavica, stream se smatra poluzatvorenim.

Poluzatvoreni stream

Kada jedna strana pošalje okvir s postavljenom zastavicom FLAG_FIN tada se stream smatra poluzatvorenim. Pošiljatelj okvira s tom postavljenom zastavicom dalje ne smije slati okvire na taj stream, a kada su obje strane poluzatvorene tada je stream prekinut.

Zatvaranje streama

Postoje tri različita načina na koji se stream može završiti:

Normalni završetak: kada obje strane imaju poluzatvoreni stream slanjem okvira sa FLAG_FIN zastavicom, stream je završen.

Isprekidani završetak: klijent i poslužitelj u bilo kojem trenutnu mogu poslati kontrolni okvir RST_STREAM koji sadrži kod pogreške i upozorava da nešto nije u redu. U slučaju da pošiljatelj šalje taj okvir on ukazuje da ne može dovršiti stream i da neće dalje slati podatke. Ako je RST_STREAM poslan od primatelja tada pošiljatelj opet treba prestati sa slanjem podataka.

Rušenje TCP veze: moguće je da dođe do problema s TCP vezom dok stream još nije završen, tada krajnja točka mora pretpostaviti da se dogodila neka neubičajena situacija i da stream neće biti potpun.

Upravljanje problemima sesije

Pogreške koje smetaju u oblikovanju framing layera ili koje mogu pokvariti stanje komprestije spadaju u probleme upravljanja sesijom. Kada se dogodi pogreška krajnja točka mora poslati GOAWAY okvir sa brojem posljednjeg streama udaljene krajnje točke i kod pogreške koji objašnjava zašto je sesija prekinuta. Krajnja točka nakon slanja GOAWAY strema također mora zatvoriti TCP vezu.

Upravljanje problemima streama

Pogreške streama odnose se na posebne ID streama koje ne utječu na obradu drugih streamova u framing layeru. Ako se dogodi takva vrsta pogreške, krajnja točka mora poslati okvir RST_STREAM koji sadrži ID streama gdje se pogreška dogodila i status te pogreške. Nakon slanja RST_STREAMA stream je zatvorena za krajnju točku koja je slala podatke.

Protok podataka

Putem TCP-a šalju se pojedinačni streamovi na kojima SPDY multipleksira više logičkih streamova, klijenti i poslužitelji moraju inteligentno izmjenjivati poruke za istodobne sesije.

Vrste kontrolnih okvira

SYN_STREAM

SYN_STREAM kontrolni okvir dopušta pošiljatelju asinkrono kreiranje streama između krajnjih točaka.

SYN_REPLY ukazuje na prihvaćanje streama kreiranog od strane primatelja okvira SYN_STREAM.

RST_STREAM omogućava nepravilna prekidanja streama. Ako je poslan od strane pošiljatelja ukazuje na to da on sam želi prekinuti stream, u suprotnom slučaju poslan je od primatelja i ukazuje da ne želi primiti podatke ili da se dogodila neka pogreška.

PING je kontrolni okvir koji služi za mjerenje minimalnog vremena obilaska (RTT) od pošialjtelja. Može biti poslan od klijenta i poslužitelja. Primatelji PING okvira trebaju što prije poslati identičan okvir pošilajtelju, tj. ako postoje neki drugi podaci na čekanju PING dobiva najviši prioritet.

GOAWAY je kontrolni okvir koji ukazuje udaljenoj strani veze da prestane s kreiranjem streama za tu sesiju. Također može biti poslana od strane klijenta i poslužitelja. Svrha ove poruke je omogućiti krajnjoj točki da jednostavno prestane primati nove streamove, dok još uvijek procesira streamove koje je ranije uspostavila. Primjerice ako HTTP klijent šalje POST u isto vrijeme kada poslužitelj prekine vezu, klijent ne može znati da li je poslužitelj započeo s obradom POST zahtjeva, zbog toga poslužitelj šalje GOAWAY da bi pokazao da je prestao raditi.

HTTP raslojavanje preko SPDY-a (eng. HTTP Layering over SPDY)

SPDY je kompatibilan s trenutnim temeljnim web aplikacijama, tj. semantika zaglavlja zahtjev/odgovor je sačuvana iako je sintaksa prenesene semantike promijenjena.

Korištenje GOAWAY

GOAWAY poruka koju pruža SPDY se koristi kada se zatvara veza od strane klijenta ili servera. Bez GOAWAY poruke, HTTP ima situaciju gdje klijent šalje zahtjev (novi SYN_STREAM) u trenutku kada server zatvara vezu i tada klijent ne može znati da li je server primio stream ili ne. Server može ukazati klijentu da li je zahtjev obrađen ili nije korištenjem brojem zadnjeg streama (eng. last-stream-id). Neki poslužitelji mogu poslati GOAWAY i odmah prekinuti vezu bez čekanja završetka aktivnog streama.

GOAWAY će koristiti poslužitelji koji žele jednostavan prekid, te će poslati GOAWAY kako bi osigurali vrijeme za završetak aktivnog streama prije okončanja veze.

Ako SPDY klijent zatvara vezu, on isto mora poslati GOAWAY poruku.

Ako ishod prekida veze nije primio daljinski SYN_STREAM, GOAWAY će sadržavati nulu kao broj zadnjeg streama.

HTTP Zahtjev/Odgovor

Zahtjev

Slanjem SYN_STREAM okvira klijent inicira zahtjev. SYN_STREAM okvir postavlja FLAG_FIN za zahtjeve koji ne sadrže tijela, dok kod zahtjeva koji sadrže tijela ne postavlja. Da bi se naznačio kraj tijela, posljednji okviri će postaviti FLAG_FIN.

Poglavlje SYN_STREAM ime/vrijednost će sadržavati sva HTTP zaglavlja koja su povezana sa HTTP zahtjevom. SPDY blok zaglavlja je nepromijenjen u odnosu na HTTP blok zaglavlja sa sljedećim razlikama:

Prva linija zahtjeva se odvija u ime/vrijednost paru kao i druga HTTP zaglavlja i mora biti prisutna:

„metoda“ – HTTP metoda za taj zahtjev (npr. „GET“, „POST“, „HEAD“, itd.)

„put“ – URL put za URL s prefiksom „/“. Npr. http://www.google.com/search?q=dogs gdje bi put bio „/search?q=dogs“.

„verzija“ – HTTP verzija ovog zahtjeva (npr. HTTP/1.1“)

Osim toga, sljedeće dva para ime/vrijednost također moraju biti predstavljeni u svakom zahtjevu.

„:host“ – hostport dio URL-a za ovaj zahtjev (npr www.google.com:1234). Ovo zaglavlje je isto kao HTTP 'Host' zaglavlje.

„shema“ – shema za URL zahtjev, npr. „https“

Korisnički agenti moraju podržavati gzip kompresiju, te poslužitelj uvijek mora poslati sadržaj kodiran s gzip.

Odgovor

Na klijentov zahtjev server odgovara SYN_REPLY okvirom. Podaci će biti poslani nakon SYN_REPLY okvira putem niza podatkovnih okvira, a posljednji podatkovni okvir će sadržavati FLAG_FIN koji ukazuje na uspješni kraj streama.

Linija statusa odgovora se odvija u parovima ime/vrijednost kao i druga HTTP zaglavlja i moraju biti prisutni:

„.status“ – HTTP kod statusa odgovora (npr. „200“ ili „200 OK“)

„.version“ – the HTTP verzija odgovora (npr. „HTTP/1.1“)

Provjera

Ako klijent šalje zahtjev na server koji zahtjeva provjeru, server može odgovoriti s odgovorom "401 neovlašteni" i uključiti zaglavlje koje definira shemu provjere koja će se koristiti.

Postoje četiri opcije za proxy provjeru. Basic i Digest su stateless provjere što znači da su identične kao i kod obavljanja provjere preko HTTP-a. NTLM i Negotiate (SPNEGO) su razvijene od strane Microsofta te su stateful.

Usporedba sa HTTP-om

Danas svima poznat pojam HTTP (Hyper Text Transfer Protocol) odnosi se na skup pravila za prijenos hipertekstualnih dokumenta između dva računala. Radi na principu zahtjev – odgovor. Računalo 'A' (klijent) uspostavlja vezu sa računalom 'B' (poslužitelj) tijekom koje zahtjeva neki sadržaj. Poslužitelj prima zahtjev i šalje ga klijentu. Taj način funkcionirao je već desetak godina, međutim današnje web stranice zahtijevaju puno veću propusnost (eng. latency) nego prije i tu je Google odlučio ponuditi brže rješenje. Značajke HTTP-a koje spriječavaju optimalne performanse: Jedan zahtjev po vezi.HTTP može dohvatiti samo jedan resurs po vremenu, kašnjenje poslužitelja od 500 ms sprječava ponovno korištenje TCP protokola za dodatne zahtjeve. Pretraživači zaobilaze takav problem koristeći višestruka spajanja, od 2008. godine većina pretraživača koristi 6 spajanja po domeni.

Poslužitelj ne može poslati zahtjev, već samo korisnik, čak i u slučaju kada zna da korisnik treba resurs. Poslužitelj može samo čekati da primi zahtjev od korisnika.

Nekompresirani zahtjevi i zaglavlja odgovora. Zaglavlje zahtjeva variva od 200 bajta do preko 2KB. Danas web stranice koriste jako puno kolačića i korisničkih agenata stoga je 700 – 800 B tipična veličina zaglavlja. Smanjenjem podataka u zaglavlju može se utjecati na propusnost pri slanju zahtjeva.

Suvišna zaglavlja. Postoje zaglavlja koja se neprestano šalju, a to je nepotrebno. Primjerice, zaglavlja korisničkog agenta, poslužitelja i primitka su generalno statična i ne treba ih ponovno slati.

Sadržaj uvijek treba slati u kompresiranom formatu, a kod HTTP je to opcionalno.

HTTP/2.0

Iz prethodnog poglavlja vidljiva su ograničenja HTTP kojeg poznajemo i zato tim Hypertext Protocol Bis (httpbis) iz IEFT (Internet Engineering Task Force) radi na njegovom nasljedniku. HTTP 2.0. mora bit performansama bolji od starog, ali semantika i kompatibilnost s postojećim aplikacijama ostaju iste.

Očekuje se da će HTTP 2.0:

U većini slučajeva znatno i mjerljivo poboljšati percipirajuću latentnost krajnjeg korisnika, preko HTTP 1.1 koristeći TCP Rješavanje HOL blokiranja (head of line blocking) u HTTP-u

Ne zahtijeva višestruka spajanja na poslužitelj da bi omogućio usporednost, tako poboljšava iskoristivost TCP-a, pogotovo s obzirom na kontrolu zagušenja.

Zadržava semantiku HTTP 1.1., koristeći postojeću dokumentaciju, uključujući HTTP metode, status kodove, URI-ove i ako je moguće polja zaglavlja

Za novu inačicu HTTP-a, osim Google-a i Microsoft je ponudio rješenje koje je slično SPDY-u, ali s dodatkom za aplikacije i mobilne uređaje. Generalno, Google-ov glavni cilj je SPDY-jem ubrzati učitavanje web stranica, a Microsoft tvrdi da to nije jedino što se može unaprijediti.

Microsoft HTTP Speed+Mobility

Sa HTTP Speed+Mobility žele ukazati na neke druge probleme kao što je trajnost baterije mobilnih uređaja i trošak propusnosti internet veze koji igraju veliku ulogu u Windows 8. Primjerice Push poslužitelj (Server Push) je jedan od zadanih svojstava SPDY-a a to bi moglo smetati uređajima koji koriste internetsku vezu s ograničenim prometom, stoga predlažu da se takva svojstva dodaju kao ekstenzije umjesto da su zadana u HTTP 2.0 specifikacijama.

Protokol obuhvaća četiri dijela:[6]

1. Pregovaranje - uspostavljanje veze (eng. Handshake)je WebSocker Upgrade s dodatnim zaglavljima

2. Sloj veze - definira održavanje i framing HTTP Speed+Mobility veze kao što je definirano u WebSocket ekstenziji

3. Multipleksiranje unutar sesije:definira framing i održavanje za višestruke HTTP zahtjeve preko jedne HTTP Spees+Mobility veze. Taj prijedlog je preuzet iz SPDY-a.

4. Stvaranje slojeva u HTTP-u: jednako kao u SPDY

WebSocket protokol osigurava osnovni model za uspostavljanje dvostrane veze između klijenta i poslužitelja. To je mehanizam za uspostavljanje veze između klijenta i poslužitelja i opcionalno osigurava vezu TLS-om. Također i set kontrolnih poruka za odražavanje veze (PING-PONG) kao i za zatvaranje (CLOSE).

U njihovom prijedlogu navodi se sljedeće:

Zadržavanje postojeće HTTP semantike kao i postojećeg načina zahtjev/odgovor. Svaka promjena treba biti dodana kao ekstenzija

Zadražva integritet slojevite arihtekture

Korisiti postojeće standarde kada je to lakše za protokol koji radi s trenutnom web infrastrukturom uključujući switch, rutere, proxy, load balancers, sustave sigurnosti, DNS poslužitelje i NAT. Primjerice predlažu ponovnu upotrebu WebSocket rukovanja i framing mehanizama za uspostavljanje dvosmjerne veze koja je kompatibilna s postojećim proxy poslužiteljima i modelima povezivanja.

Biti široko primjenjiv i fleksibilan kao i trenutni protokol te zadržati kontrolu klijenta nad sadržajem. Primjerice nije nužno koristiti TLS ili kompresiju, već to daju na izbor korisniku ovisno o njegovim komunikacijskim potrebama i sigurnosti.

Računaju na potrebe klijenata moderinh tehnologija, uključujući efikasno korištenje energije i internetsku vezu s ograničenim pristupom.

Može se zaključiti da zaista postoje velike sličnosti između Microsoftovog i Googleovog prijedloga. Primjerice za većinu framing layera imaju istu sintaksu SYN_STREAM, SYN_RESET, SYN_REPLAY, HEADERS itd.

Primjer: SPDY performanse na mobilnim mrežama

U istraživanju je korišteno:[6]

Mobitel i pretraživač: Chrome za Android ima SPDY verziju 2 i trenutno je jedini mobilni pretraživač koji podržava SPDY. Na mobitelu je instalirana Android 4.0 verzija softvera poznatija pod imenom Ice Cream Sandwich, a model mobitela je Samusng Galaxy Nexus. Za potrebe istraživanja korišten je Chromov remote debugging interface koji pokreće pretraživač na mobitelu, čisti cache i druga stanja, inicira učitavanje web stranice i prima Chrome developer tools poruke za određivanje vremena učitavanja stranica i druga mjerenja performansi.

Mjerene web stranice: izabrano je 77 URL-ova sa 31 poznate web stranice. Da bi osigurali da će mobitel svaki put dohvatiti isti sadržaj koristili su Web Page Replay.

Konfiguracija poslužitelja: potrebno je koristiti poslužitelj koji podržava SPDY, pa je za potrebe ovog istraživanja upotrjebljen interni Googleov poslužitelj Google Front End. GFE i Web Page Replay poslužitelj odvijali su se na različitim Linux stolnim računalima unutar iste LAN mreže. Sav sadržaj web stranica je bio spremljen na lokalnom serveru kako bi se eliminirali dodatni izvori propusnosti. Mobitelova /etc/host datoteka je modificirana da vraća IP GFE poslužitelja za sva traženja domene, posebno izolirajući mobitel i stolno računalo od Interneta. Istraživanje nije uključivalo stvarno DNS vrijeme traženja.

Nepromijenjeni mrežni uvjeti: da bi smanjili varijabilnost vremena učitavanja web stranica, mobiteli su bili povezani USB-om na stolno računalo, a Dummynet-om su mjereni efekti učitavanja. Simulirana je 3G mreža sa bandwithom od 1 Mbps prema mreži, a 2 Mbps sa mreže i RTT-om od 150 ms.

Skupljanje podataka: za svako učitavanje snimano je vrijeme učitavanja stranice zabilježeno u pretraživaču, kao i detaljno praćenje Chrome remote debug poruka koje su korištene za rekonstrukciju waterfalla vremena učitavanja svake stranice.

Gornja konfiguracija je prikazana na slici

Istraživanje se odvijalo u dvije postavke:

1. SPPY: dohvaća 77 URL-ova preko GFE-a koristeći SPDY

2. HTTP: dohvaća 77 URL-ova preko GFE koristeći HTTP

SPDY koristi jednu SSL konekciju po domeni, dok HTTP koristi višestruke paralelne konekcije da bi dohvatio resurse sa poslužitelja.

Graf pokazuje vrijeme učitavanja za svih 77 web stranica koristeći HTTP i SPDY. Gotovo u svim slučajevima SPDY je brži nego HTTP, vrijeme učitavanja smanjilo se za oko 23%

Graf pokazuje prosječno smanjeno vrijeme učitavanja stranica SPDY-em za svaku mjerenu web streanicu.

Vidljivo da je ostvarena ušteda učitavanje web stranica mobilnom mrežom 3G, naravno da postoje uvjeti na koje se ne može utjecati ali smanjenje učitavanja od 23% nije zanemarivo.

Primjer 2

Pomoću Googleovog alata Benchmark Page Load time, ispitali smo brzinu učitavanja stranice www.twitter.com za koju znamo da podržava SPDY.

Na slici je vidljivo da je stranica www.twiter.com učitana 10 puta. Alatom se mogu testirati samo stranice koje podržavaju SPDY, stoga su rezultati testiranja približni.