PREGLED PRISTOPOV K POHITRITVI PRENOSA SPLETNIH STRANI · pages. The description of the protocols...

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Simon Malek Kuzmič

PREGLED PRISTOPOV K POHITRITVI

PRENOSA SPLETNIH STRANI

Diplomsko delo

Maribor, september 2015

PREGLED PRISTOPOV K POHITRITVI PRENOSA SPLETNIH

STRANI

Diplomsko delo

Študent: Simon Malek Kuzmič

Študijski program: univerzitetni študijski program

Telekomunikacije

Mentorica: red. prof. dr. Tatjana Kapus

Somentor: doc. dr. Robert Meolic

Lektorica: prof. Tatjana Caf

ii

Zahvala

Zahvala gre mentorici dr. Tatjani Kapus in dr. Robertu Meolicu za vso pomoč pri izdelavi

diplomskega dela. Prav tako se zahvaljujem celotnemu kolektivu FERI za korektnost in

podporo. Zahvaljujem se tudi mojim najbližjim za podporo pri študiju.

iv

Pregled pristopov k pohitritvi prenosa spletnih

strani

Ključne besede: svetovni splet, spletna stran, protokol.

UDK: 004.774(043.2)

Povzetek

Diplomsko delo zajema opis protokolov HTTP 1.1, SPDY in HTTP 2.0 z namenom, da bi predstavili

značilne metode za pohitritev prenosa spletnih strani. Najprej na kratko razložimo vrste spletnih

strani. Opis protokolov se začne s HTTP 1.1, na katerem temeljita SPDY in HTTP 2.0. Prvi večji

prispevek k pohitritvi delovanja spleta je opisan pri protokolu SPDY. Sledi opis protokola HTTP 2.0

s poudarkom na podobnostih in razlikah med njim in protokolom SPDY. Pri testiranju posameznih

protokolov za izbrano spletno stran so bile ugotovljene razlike v času nalaganja spletne strani in v

količini poslanih ter sprejetih podatkov.

v

An overview of approaches to speeding up web

page transfer

Key words: world wide web, web page, protocol.

UDK: 004.774(043.2)

Abstract

This thesis includes a description of HTTP 1.1, HTTP 2.0 and SPDY protocols in order to present

typical methods for speeding up the transfer of web pages. First, we briefly explain the types of web

pages. The description of the protocols begins with HTTP 1.1, which SPDY and HTTP 2.0 are based

on. The first major contribution to the speed-up of the web is described with the SPDY protocol.

After that, we describe the HTTP 2.0 protocol with an emphasis on similarities and differences

between it and the SPDY protocol. When testing specific protocols for a selected web page, there

were differences in the load time of the web page and the amount of transmitted and received data.

vi

Kazalo vsebine

1 UVOD ............................................................................................................................ 1

2 SVETOVNI SPLET ..................................................................................................... 2

2.1 UVOD V SVETOVNI SPLET ......................................................................................... 2

2.2 ZGODOVINA SVETOVNEGA SPLETA........................................................................... 2

3 STATIČNE IN DINAMIČNE SPLETNE STRANI .................................................. 4

3.1 STATIČNE SPLETNE STRANI ...................................................................................... 4

3.2 DINAMIČNE SPLETNE STRANI ................................................................................... 5

3.2.1 Skupni dostopni vmesnik ..................................................................................... 5

3.2.2 Skriptne tehnologije za dinamične dokumente .................................................... 6

3.3 AKTIVNE SPLETNE STRANI ....................................................................................... 7

3.3.1 Javanski programčki in JavaScript ..................................................................... 7

4 HTTP ............................................................................................................................. 9

4.1 POVEZAVE ............................................................................................................... 9

4.2 METODE ................................................................................................................. 11

4.3 GLAVE SPOROČIL ................................................................................................... 12

4.4 PREDPOMNJENJE .................................................................................................... 14

4.5 HTTPS .................................................................................................................. 15

5 POHITRITEV PRENOSA S PROTOKOLOM SPDY .......................................... 16

5.1 MULTIPLEKSIRANJE IN PRIORITIZACIJA .................................................................. 16

5.2 SLOJ OKVIRJANJA ................................................................................................... 18

5.3 ZAHTEVE IN ODGOVORI HTTP V PROTOKOLU SPDY ............................................. 20

5.4 POTISK S STREŽNIKA .............................................................................................. 21

5.5 POVEZAVE TCP PRI PROTOKOLIH HTTP IN SPDY ................................................ 22

6 POHITRITEV PRENOSA S PROTOKOLOM HTTP 2.0 .................................... 25

6.1 MULTIPLEKSIRANJE ZAHTEV IN ODGOVOROV ........................................................ 25

6.2 BINARNO OKVIRJANJE ............................................................................................ 27

6.3 DOPOLNJEVANJE .................................................................................................... 28

6.4 ZAHTEVE IN ODGOVORI V PROTOKOLU HTTP 2.0 .................................................. 29

6.5 PRIORITIZACIJA TOKOV .......................................................................................... 29

6.6 POTISK S STREŽNIKA .............................................................................................. 30

6.7 STISKANJE GLAV .................................................................................................... 30

6.8 PREHOD NA UPORABO PROTOKOLA HTTP 2.0........................................................ 31

7 PRIJEMI ZA HITER PRENOS V PROGRAMU FIREFOX ............................... 33

7.1 PROGRAM MOZILLA FIREFOX ................................................................................ 33

7.2 VKLJUČITEV INDIKATORJA ZA SPDY IN HTTP 2.0 ................................................ 33

7.3 ORODJE ZA ANALIZO UČINKOVITOSTI PRENOSA SPLETNIH STRANI ......................... 35

7.3.1 Firefoxov omrežni opazovalec .......................................................................... 35

vii

7.3.2 HttpWatch.......................................................................................................... 37

7.4 WIRESHARK ........................................................................................................... 37

7.5 ANALIZA Z ORODJEM HTTPWATCH BASIC EDITION IN FIREFOXOVIM

OPAZOVALCEM .................................................................................................................. 38

7.5.1 Meritve s HttpWatch Basic Edition ................................................................... 39

7.5.2 Meritve s Firefoxovim omrežnim opazovalcem ................................................. 46

7.6 ANALIZA Z WIRESHARKOM .................................................................................... 49

7.6.1 Opazovanje pri protokolu HTTP 1.1 ................................................................. 49

7.6.2 Opazovanje pri protokolu SPDY 3.1 ................................................................. 50

7.6.3 Opazovanje pri protokolih HTTP/2 draft 15 ter HTTP 2.0............................... 52

8 SKLEP ......................................................................................................................... 54

VIRI IN LITERATURA ............................................................................................ 56

viii

Kazalo slik

Slika 3.1: Delovanje statične spletne strani [3]. ................................................................................. 4

Slika 3.2: Delovanje dinamične spletne strani s CGI [3]. .................................................................. 5

Slika 3.3: Tvorjenje dinamičnega dokumenta s skriptom na strežniku [3]. ....................................... 6

Slika 3.4: Aktiven dokument z uporabo javanskega programčka [3]. ............................................... 7

Slika 3.5: Prikaz delovanja JS na spletni strani [3]. ........................................................................... 8

Slika 4.1: Prikaz delovanja različnih načinov povezav [10]. ........................................................... 10

Slika 4.2: Metode, uporabljene pri prenosu spletnih strani [10]. ..................................................... 12

Slika 4.3: Statusne kode odgovorov s strežnika [10]. ...................................................................... 12

Slika 4.4: Predpomnjenje pri HTTP [10]. ........................................................................................ 15

Slika 5.1: Primera blokiranja na čelu vrste pri cevljenju HTTP [11]. .............................................. 16

Slika 5.2: Multipleksiranje in prioritizacija tokov [11]. ................................................................... 17

Slika 5.3 Nadzorni in podatkovni okvir [4]. ..................................................................................... 19

Slika 5.4: Potisk s strežnika SPDY [11]. .......................................................................................... 22

Slika 6.1: Binarno okvirjanje [5]. ..................................................................................................... 26

Slika 6.2: Prepletanje okvirjev več tokov v povezavi [5]. ................................................................ 26

Slika 6.3: Primer uporabe posodobitvenega mehanizma HTTP [5]. ................................................ 32

Slika 7.1: Indikator podpore protokolov HTTP/2 in SPDY za Firefox. ........................................... 34

Slika 7.2: Prikaz indikatorja v vrstici z naslovom spletne strani. ..................................................... 34

Slika 7.3: Indikator, ki prikazuje delovanje protokola SPDY. ......................................................... 34

Slika 7.4: Prikaz posamezne zahteve. .............................................................................................. 35

Slika 7.5: Odgovori na zahteve HTTP. ............................................................................................ 35

Slika 7.6: Prikaz podrobnosti zahteve. ............................................................................................. 36

Slika 7.7: Vrstica s štoparico ter prikazom števila, časa in velikosti vseh zahtev. ........................... 36

Slika 7.8: Grafična predstavitev podatkov o nalaganju. ................................................................... 37

Slika 7.9: Trije parametri za izbiro spletnega protokola. ................................................................. 38

Slika 7.10: Meritev števila povezav TCP in rokovanj SSL 1. .......................................................... 39





Slika 7.15: Meritev velikosti zahtev in odgovorov 1. ...................................................................... 41





Slika 7.20: Meritev časa nalaganja strani 1. ..................................................................................... 43

Slika 7.21: Podrobnejši prikaz prve zahteve pri meritvi 1. .............................................................. 43

Slika 7.22: Podrobnosti glav prve zahteve in odgovora pri meritvi 1. ............................................. 43









ix





Slika 7.35: Rezultat za napolnjen in prazen predpomnilnik 1. ......................................................... 47





Slika 7.40: Prikaz glav sporočil HTTP 1.1. ...................................................................................... 49

Slika 7.41: Prikaz okvirja SYN_STREAM ...................................................................................... 51

Slika 7.42: Metode SPDY. ............................................................................................................... 51

Slika 7.43: Prikaz neberljivih glav. .................................................................................................. 53

x

Uporabljene kratice

ALPN Application Layer Protocol

Negotiation

pogajanje o protokolu

aplikacijskega sloja

ASP Active Server Pages aktivne strežniške strani

CGI Common Gateway Interface skupni prehodni vmesnik

CSS Cascading Style Sheets kaskadne slogovne podloge

DNS Domain Name System sistem domenskih imen

HTML HyperText Markup

Language

jezik za označevanje

hiperteksta

HTTP HyperText Transfer

Protocol

protokol za prenos

hiperteksta

IP Internet Protocol internetni protokol

JS JavaScript

JSP Server Pages javanske strežniške strani

MIME Multipurpose Internet Mail

Extensions

večnamenske razširitve

internetne pošte

NAT Network Address

Translation

prevajanje omrežnih

naslovov

PHP Hypertext Preprocessor predprocesor za hipertekst

RFC Request for Comments zahtevek za komentarje

SOAP Simple Object Access

Protocol

preprosti protokol za dostop

do objektov

SSL Secure Sockets Layer sloj varnih vtičnic

TCP Trasmission Control

Protocol

protokol za nadzor prenosa

TLS Transport Layer Security varnost transportnega sloja

URI Uniform Resource

Identifier

enolični identifikator vira

URL Uniform Resource Locator enolični lokalizator vira

WWW World Wide Web svetovni splet

Pregled pristopov k pohitritvi prenosa spletnih strani

1

1 UVOD

»The invention of the Internet has forever altered the world we live in.«

»Iznajdba interneta je za vedno spremenila svet, v katerem živimo.«

William M. Daley

Število spletnih strani neprestano raste, prav tako pa raste tudi njihova kompleksnost. Arhiv

HTTP [3] prikazuje, da je povprečna velikost spletne strani že presegla 1 MB. Takšno rast

je povzročil nastanek naprednih storitev, kot so Web 2.0, oblačne storitve, izboljšane

zmožnosti spletnih odjemalcev (na primer boljši prikazovalniki) in povečane hitrosti

povezav v omrežju. Ta kompleksnost je povzročila daljše čakanje na odziv spletnih strani.

Že ena sekunda v času pomeni v praksi izgubo strank v primeru trgovine, večina

uporabnikov pa ne more tolerirati čakanja več kot dve sekundi za naložitev spletne strani

[3]. Za zmanjšanje tega časa se je pojavilo kar nekaj predlogov. Med njimi sta protokola

SPDY in HTTP 2.0. Koncept protokola HTTP 2.0 se je porodil iz protokola SPDY. Z delom

na protokolu so začeli, ko je imel SPDY že delovni koncept in je bil pripravljen za uporabo

v spletu. Cilj diplomskega dela je pojasniti osnovno delovanje protokola HTTP 1.1 in

proučiti metode, ki so jih uvedli za pospešitev nalaganja spletnih strani v protokolih SPDY

in HTTP 2.0, ter poudariti razlike v delovanju.

V poglavju 2 bomo na kratko predstavili svetovni splet in njegovo zgodovino. Poglavje 3

opisuje vrste spletnih strani. HTTP 1.1 bo opisan v poglavju 4, saj je nujen za razumevanje

kasnejših poglavij. Poglavje 5 predstavlja protokol SPDY. V poglavju 6 se opisan protokol

HTTP 2.0 in razlike med njim in protokolom SPDY. V poglavju 7 smo analizirali prenos

izbrane spletne strani, ki podpira vse te protokole, z orodjem spletnega brskalnika Firefox,

HttpWatch in z Wiresharkom ter ugotovili razlike v količini prenesenih podatkov, prenosnih

časih in vzpostavljanju povezav do strežnikov za različne protokole.


2

2 SVETOVNI SPLET

2.1 Uvod v svetovni splet

Svetovni splet (na kratko splet) ali v angleščini World Wide Web (WWW) je informacijski

sistem med seboj povezanih hipertekstovnih dokumentov, do katerih lahko pridemo preko

interneta. Posamezne strani dokumentov imenujemo internetne strani in so dosegljive za

uporabnika preko različnih aplikacij za brskanje. Spletne strani lahko vključujejo tekst, slike,

videe in druge multimedijske funkcije [14].

2.2 Zgodovina svetovnega spleta

Iznajdba in začetki implementacije svetovnega spleta segajo med leti 1980 in 1991. Do

konca leta 1990 so bila narejena potrebna orodja za delovanje spleta: »HyperText Transfer

Protocol« (protokol za prenos hiperteksta) (HTTP, različica 0.9), »HyperText Markup

Language« (jezik za označevanje hiperteksta) (HTML), prvi spletni brskalnik, imenovan

»WorldWideWeb«, in strežnik HTTP ter spletni strežnik, ki je vseboval prve spletne strani

o samem projektu. Rast spleta je potekala med letoma 1992 in 1995. Zgodnji uporabniki

spleta, ki ga je razvil CERN, so bili v večini primerov univerzitetne ustanove in fizikalni

laboratoriji. V letu 1993 je bilo po svetu že 500 spletnih strežnikov. Komercializacija

svetovnega spleta se je začela v letu 1996. Komercialni uporabniki so najprej videli

priložnost v brezplačnem sporočanju po spletu. Obdobje med letoma 1999 in 2001 je bilo

obdobje razcveta spleta. Veliko podjetij se je začelo ukvarjati s spletno prodajo in s tem

uspelo. Prav tako so tradicionalni medijiski ponudniki, kot so recimo časopisne hiše, opazili,

da bo splet postajal vse uporabnejši za razpečevanje vsebin in so v tem videli priložnost za

dobiček. Uporaba spleta postane del vsakdanjika okoli leta 2002, sicer ne v takšni meri, kot

je danes. Telekomunikacijska podjetja so imela veliko preseženih zmogljivosti in so zato


3

začela investirati v infrastrukturo. To je pripeljalo do hitrih in cenovno ugodnih internetnih

povezav, s tem pa do boljšega dostopa do svetovnega spleta [12].


4

3 STATIČNE IN DINAMIČNE SPLETNE STRANI

Spletni dokumenti se delijo v tri širše skupine: statične, dinamične in aktivne [3].

3.1 Statične spletne strani

Statični dokumenti so vsebinsko določeni dokumenti, ki so tvorjeni in shranjeni na strežniku.

Odjemalec lahko pridobi le kopijo takega dokumenta. Z drugimi besedami − vsebina

dokumenta je določena takrat, ko se datoteka z njim tvori, in ne takrat, ko se uporabi. Vsebina

se lahko spreminja, vendar je treba narediti spremembe na samem strežniku. Odjemalec ne

more vplivati na spremembe. Ko uporabnik dostopa do dokumenta, se mu pošlje njegova

kopija. Nato se lahko uporabniku vsebina prikaže v brskalniku [3]. Na sliki 3.1 je prikazano

delovanje statične spletne strani.

Slika 3.1: Delovanje statične spletne strani [3].


5

3.2 Dinamične spletne strani

Dinamičen dokument ustvari spletni strežnik vsakič, ko brskalnik zahteva dokument. Ko

prispe zahteva, spletni strežnik požene aplikacijo ali skript, ki tvori dinamični dokument.

Strežnik nato pošlje dokument kot odziv na brskalnikovo zahtevo. Za vsako zahtevo se tvori

nov dokument. Vsebina dinamičnega dokumenta se razlikuje od ene zahteve do druge.

Primer je pridobivanje strani s trenutnim datumom in časom s strežnika, saj se spreminjata

[3].

3.2.1 Skupni dostopni vmesnik

CGI (»Common Gateway Interface« – skupni dostopni vmesnik) je skupek pravil, ki

določajo, kako je dinamičen dokument napisan, kakšen je vnos podatkov v program za

njegovo tvorjenje in kako se mora uporabiti izhodni rezultat [3]. Na sliki 3.2 je prikazano

delovanje dinamične spletne strani z uporabo CGI. Programu, ki deluje v skladu s pravili

CGI, pravimo program CGI.

Slika 3.2: Delovanje dinamične spletne strani s CGI [3].


6

Celotna ideja CGI je izvedba programa na podlagi vhodnih podatkov iz zahteve odjemalca

na samem strežniku in odposlanje rezultatov uporabniku brskalnika. Rezultat je običajno

golo besedilo ali besedilo HTML. Lahko pa so tudi recimo slike ali binarni podatki, navodila

za brskalnik za predpomnjenje rezultata ali navodila strežniku, naj v odgovor pošlje že

obstoječ dokument [3].

3.2.2 Skriptne tehnologije za dinamične dokumente

Če se del dinamičnega dokumenta, ki se mora tvoriti, ne spreminja od zahteve do zahteve,

uporaba tehnologije CGI ni učinkovita. Če uporabljamo CGI, mora program izdelati celoten

dokument vsakokrat, kadar naredimo zahtevo. Rešitev je izdelava datoteke, ki vsebuje stalni

del, napisan z uporabo HTML, in skript (izvorno kodo), ki ga izvede strežnik, da zagotovi

spremenljive podatke [3]. Vse skupaj je prikazano na sliki 3.3.

Slika 3.3: Tvorjenje dinamičnega dokumenta s skriptom na strežniku [3].

Najpogostejše tehnologije za tvorjenje dinamičnih dokumentov z uporabo skriptov so PHP

(»Hypertext Preprocessor« – predprocesor za hipertekst), JSP – (»Java Server Pages« –

javanske strežniške strani) in ASP (»Active Server Pages« – aktivne strežniške strani).


7

3.3 Aktivne spletne strani

3.3.1 Javanski programčki in JavaScript

Za številne aplikacije, ki jih hočemo uporabljati v svetovnem spletu, se mora program ali

skript izvesti na uporabniški strani. V takšnem primeru govorimo o aktivnih spletnih

dokumentih oziroma straneh. Če želimo na primer pognati program, ki bo tvoril animirano

grafiko na zaslonu, ali program, ki komunicira z uporabnikom, mora delovati na mestu, kjer

se animacija ali interakcija dogaja. Ko brskalnik zahteva aktiven dokument, mu strežnik

pošlje kopijo dokumenta ali skripta in le-ta se izvede na mestu odjemalčevega brskalnika

[3].

En način za pripravo aktivnih dokumentov je uporaba javanskih programčkov – »Java

Applet«. Javanski programček je program napisan v javi, ki se nahaja v obliki primerni za

izvajanje na strežniški strani [3]. Na sliki 3.4 je na preprost način predstavljeno njegovo

delovanje. Odjemalec oziroma brskalnik lahko od strežnika zahteva neposredno javanski

programček, lahko pa dobi spletno stran HTML, v kateri je naveden naslov, na katerega

potem pošlje zahtevo za programček.

Slika 3.4: Aktiven dokument z uporabo javanskega programčka [3].

Ideja skriptov iz dinamičnih dokumentov se lahko uporablja tudi za aktivne dokumente. Če


8

je aktivni del dokumenta majhen, je lahko napisan v skriptnem jeziku. Odjemalec ga lahko

istočasno interpretira in izvaja. Skript je v obliki izvorne kode in ne v binarni obliki. Skriptna

tehnologija je v tem primeru večinoma JavaScript (JS) [3]. Primer delovanja je prikazan na

sliki 3.5.

Slika 3.5: Prikaz delovanja JS na spletni strani [3].


9

4 HTTP

Protokol HTTP je protokol aplikacijskega sloja. Je glavni protokol svetovnega spleta, saj se

uporablja za prenos spletnih strani. S HTTP mislimo na HTTP 1.1, ki je definiran v RFC

2616 pod imenom HTTP/1.1 in je dandanes najpogosteje uporabljeni protokol za ta namen.

HTTP je protokol odjemalec – strežnik. Odjemalec pošilja strežniku zahteve, strežnik pa

mu pošilja odgovore. HTTP definira zgradbo sporočil in kako si morata odjemalec in

strežnik pošiljati ta sporočila [9].

4.1 Povezave

Običajen način brskalnika oziroma natančneje odjemalca HTTP za kontaktiranje strežnika

je vzpostavitev povezave TCP (»Transmission Control Protocol« – protokol za nadzor

prenosa) pri vratih 80. Sprva, ko se je uporabljal HTTP 1.0, se je vzpostavila povezava TCP,

po kateri se je poslala ena zahteva in en odgovor [10]. Nato se je povezava sprostila. Takšni

povezavi lahko rečemo neobstojna povezava.

V preteklosti, ko je bila tipična spletna stran vsebovala samo besedilo HTML, je bila ta

metoda primerna. Kakor hitro se je v povprečni spletni strani pojavilo veliko število

vgrajenih povezav na vsebino, kot so recimo ikone in druge stvari za lep izgled, pa je postala

ta metoda predraga. Ta ugotovitev je privedla do HTTP 1.1. Z njim je možno vzpostaviti

povezavo TCP, poslati zahtevo in dobiti odgovor ter nato poslati dodatne zahteve in dobiti

odgovore po isti povezavi. Ta strategija se imenuje tudi ponovna uporaba povezave,

povezave pa obstojne povezave. S tem se zmanjša relativni balast zaradi TCP na posamezno

zahtevo [10]. Možno je tudi cevljenje zahtev. To pomeni, da je na primer možno poslati

zahtevo 2 pred prihodom odgovora na zahtevo 1. Delovanje vseh treh načinov povezav je

prikazano na sliki 4.1.


10

Del (a) prikazuje tri zahteve, drugo za drugo, vsako v ločeni povezavi. To si lahko

predstavljamo kot spletno stran z dvema vgrajenima slikama na istem strežniku. URL-ja

(»Uniform Resource Locator« – enolični lokalizator vira) slik sta znana, ko odjemalec dobi

glavno stran. Nato na teh naslovih zahteva še slike. Dandanes ima povprečna stran okoli 40

drugih objektov [10].

Slika 4.1: Prikaz delovanja različnih načinov povezav [10].

Del (b) prikazuje stran z obstojno povezavo. To pomeni, da se povezava TCP na začetku

odpre. Nato so poslane tri zahteve in šele nato se povezava sprosti. Vidimo, da se vse skupaj

konča hitreje. Za to sta dva razloga. Prvi je, da se ne zapravi čas za vzpostavljanje povezave.

Vsaka povezava TCP zahteva vsaj eno povratno sporočilo za vzpostavitev. Drugi je, da

prenos iste slike poteka hitreje. To je zaradi nadzora zamašitve TCP. Na začetku povezave

TCP uporablja počasni začetek za večanje propustnosti, dokler se ne nauči o obnašanju

omrežne poti. Zaradi tega ogrevalnega obdobja več kratkih povezav TCP potrebuje več časa

za prenos podatkov kot ena dolga [10].

Del (c) prikazuje eno obstojno povezavo in cevljenje zahtev. Natančneje: druga in tretja

zahteva se pošljeta hitro drugo za drugo, takoj ko se pridobi zadosten del glavne strani, da

se prepozna, da je treba pridobiti sliki. Sčasoma sledita odziva na ti zahtevi. Ta metoda

skrajša čas, v katerem strežnik ni zaseden, in tako učinkovitost še izboljša.


11

Pri obstojnih povezavah pa se pojavi vprašanje, kdaj sprostiti povezavo. Medtem ko se stran

nalaga, mora biti povezava odprta. Nato obstaja velika možnost, da bo uporabnik kliknil na

hiperpovezavo, ki bo zahtevala še eno stran s strežnika. Če povezava ostane odprta, se lahko

naslednja zahteva pošlje takoj, morda pa uporabnik še dolgo ne bo kliknil na hiperpovezavo.

V praksi odjemalci in strežniki običajno pustijo obstojne povezave odprte, dokler se po njih

nič ne prenaša vsaj nekaj časa (na primer 60 sekund) ali če imajo veliko število odprtih

povezav in jih morajo nekaj zapreti [10].

4.2 Metode

Čeprav je bil HTTP zasnovan za uporabo v spletu, je namenoma zasnovan splošneje, da bi

bil v prihodnje primeren za različne vrste objektno usmerjene uporabe. V ta namen so si

izmislili operacije, imenovane metode, ki ne omogočajo samo zahtev po spletnih straneh. Ta

splošnost je omogočila razvoj protokola SOAP (»Simple Object Access Protocol« –

preprosti protokol za dostop do objektov). Sporočilo HTTP ima začetno vrstico, ki vsebuje

ukaz zahteve (metodo) ali status odgovora z dodatnimi informacijami. Nato imamo glave,

ki nosijo informacije o sporočilu ali oddajnem sistemu.

Po glavah je prazna vrstica, za njo pa se lahko nahaja koristna vsebina oziroma telo sporočila.

Začetna vrstica in glave so besedilo ASCII. Zgradba prve vrstice v zahtevi je takšna:

vrsta_zahteve URL_zahteve različica_HTTP.

Metode so predstavljene na sliki 4.2. Najpogosteje sta uporabljeni metodi GET in POST.

Metoda GET zahteva od strežnika spletno stran oziroma dokument (»objekt«). Stran je

ustrezno kodirana v MIME (»Multipurpose Internet Mail Extensions« – večnamenske

razširitve internetne pošte). Običajna oblika prve vrstice zahteve GET je GET ime_datoteke

HTTP/1.1, kjer je ime_datoteke URL strani, ki jo zahtevamo. Velika večina zahtev do

spletnih strežnikov uporablja metodo GET.


12

Metoda POST se uporablja, kadar se pošiljajo obrazci. Tako POST kot GET se uporabljata

v spletnih storitvah SOAP. Tako kot GET nosi URL, ampak namesto pridobivanja strani

naloži podatke (vsebino obrazca) na strežnik. Strežnik nato s podatki, v odvisnosti od URL,

nekaj stori. Konceptno jih doda objektu, na primer, da se izvede nakup izdelka. Metoda vrne

stran, ki kaže rezultat.

Vsaka zahteva dobi odgovor, ki vsebuje vsaj eno vrstico. Zgradba prve vrstice v sporočilu

odgovora izgleda tako: različica_HTTP statusna_koda statusna_fraza. Vrste statusnih kod in

konkretni primeri so podani na sliki 4.3.

Slika 4.2: Metode, uporabljene pri prenosu spletnih strani [10].

Slika 4.3: Statusne kode odgovorov s strežnika [10].

4.3 Glave sporočil

Prvi vrstici zahteve lahko sledijo glave z več informacijami. Imenujejo se glave zahteve. V

odgovorih pa so glave odgovora. Nekatere glave se lahko uporabijo v obeh vrstah sporočil

[10].


13

Glava User-Agent omogoča odjemalcu, da obvesti strežnik o svojem brskalniku. Te

informacije strežniku pomagajo, da odgovor prilagodi posameznemu brskalniku.

Štiri vrste glav Accept povedo strežniku, kaj je odjemalec pripravljen sprejeti, če ima

omejene možnosti. Glava Accept določa tipe MIME, ki so dobrodošli (na primer tekst/html).

Glava Accept-Charset določa nabor znakov (na primer ISO-8859-5 ali Unicode-1-1). Glava

Accept-Encoding določa sprejemljive metode stiskanja (na primer gzip). Glava Accept-

Language označuje naravne jezike, sprejemljive za odjemalca. Če ima strežnik možnost

izbire strani, lahko te informacije uporabi za to, da mu pošlje tako, ki mu ustreza. Če strežnik

ne more zadostiti zahtevi, javi napako in zahteva ne uspe.

Glavi If-Modified-Since in If-None-Match se pošiljata v zahtevah in se uporabljata pri

predpomnjenju. Omogočata, da odjemalec pošlje zahtevo za stran samo, če shranjena kopija

ni več veljavna.

Glava Host nastopa v zahtevah in vsebuje ime strežnika. Ime je vzeto iz URL-ja. Ta glava

je obvezna. Uporablja se zato, ker nekateri naslovi IP služijo več imenom DNS, strežnik pa

mora vedeti, kateremu gostiteljskemu računalniku izročiti zahtevo.

Glava Authorization se uporablja takrat, kadar je stran zaščitena. V takem primeru mora

odjemalec v tej glavi dokazati pravico do vpogleda.

Odjemalec uporabi glavo Referer (ta beseda je napačno črkovana različica besede Referrer)

za podajo URL-ja, ki se je skliceval na URL, kateri je zahtevan ta trenutek. V večini

primerov je to URL prejšnje strani. Ta glava je koristna pri sledenju brskanja po spletu.

Glava Set-Cookie v odgovoru pove odjemalcu, kako mu strežnik pošilja piškotek. Pričakuje

se, da odjemalec shrani piškotek in ga vrne v naslednjih zahtevah do strežnika v glavi

Cookie.

Glava Server omogoča strežniku identifikacijo svoje programske opreme v odgovoru.

Glava v odgovoru Last-Modified odjemalcu pove, kdaj je bila predpomnjena stran nazadnje

spremenjena. Glava Expires mu pove, kako dolgo bo stran ostala veljavna. Obe glavi imata

pomembno vlogo pri predpomnjenju.


14

Glavo Location pošlje strežnik takrat, ko mora obvestiti odjemalca naj poskusi z drugim

URL-jem. Uporabi se, kadar je bila stran premaknjena ali kadar mora omogočiti več hkratnih

URL-jev za isto stran (po možnosti na različnih strežnikih). Uporabi se tudi za podjetja, ki

imajo glavno spletno stran v domeni .com, vendar preusmeri odjemalce na nacionalno ali

regionalno stran na podlagi njihovih naslovov IP ali izbranega jezika.

Glava Accept-Ranges napove strežnikovo pripravljenost za ravnanje z zahtevami za del

strani. Glava Date se uporablja v obe smeri ter vsebuje čas in datum, kdaj je bilo sporočilo

poslano, medtem ko glava Range omogoča zahtevo po delu strani.

Glava Etag vsebuje kratko oznako, ki služi kot ime za vsebino poslane strani. Uporablja se

pri predpomnjenju. Glava Cache-Control daje druga navodila, kako predpomniti (oziroma

kako ne predpomniti) strani.

Glava Upgrade je uporabljena za izbiro, ali bo uporabljen drug komunikacijski protokol

namesto HTTP 1.1, kot je recimo novejši protokol HTTP, ali za izbiro uporabe zaščitenega

prenosa. Odjemalcu omogoča sporočanje, kaj podpira, in strežniku, kaj uporablja.

4.4 Predpomnjenje

Pogosto se vračamo na spletne strani, ki smo jih že obiskali. Spletne strani imajo pogosto

vgrajene enake vire. Za primer vzemimo posamezne slike, ki se uporabljajo za navigacijo,

in skripte. Bila bi potrata časa, če bi se morale nalagati vse stvari še enkrat, saj jih je brskalnik

že prejel. Shranjevanje strani za nadaljnjo uporabo se imenuje predpomnjenje. Njegova

prednost je v tem, da v primeru ponovne uporabe ni potreben ponoven prenos, ampak se

prikaže shranjena stran iz predpomnilnika. HTTP omogoča, da odjemalec ugotovi, ali je

primerno uporabiti stran iz predpomnilnika. S tem se zmanjša tako omrežni promet kot

zakasnitev. Strani so običajno shranjene na disku, da jih lahko brskalnik uporabi, ko jih

potrebuje [10]. Predpomnjenje je prikazano na sliki 4.4.


15

HTTP uporablja za ugotavljanje, ali je predpomnjena stran enaka kot tista, ki bi jo naložil iz

omrežja, dve strategiji. Prva je, da se v predpomnilniku pregleda kopija strani za zahtevani

URL. Če je stran še vedno veljavna, potem ni potrebe po ponovnem nalaganju s strežnika.

Veljavnost se ugotovi s primerjavo glave Expires shranjene strani s trenutnim datumom in

časom. Vse strani pa nimajo te glave s časovno dobo, ki pove, kdaj se mora stran ponovno

osvežiti [10]. Poleg tega se stran na strežniku kljub poteku veljavnosti morda ni spremeila

in je ni treba ponovno naložiti. Zato se uporablja še druga strategija. Odjemalec pošlje

strežniku pogojno zahtevo GET, s katero ga vpraša, ali je kopija še veljavna. Če strežnik

ugotovi, da je, pošlje le kratek odgovor, sicer pa celotno stran.

Slika 4.4: Predpomnjenje pri HTTP [10].

4.5 HTTPS

HTTPS ni oznaka za poseben protokol, ampak pomeni, da se HTTP izvaja preko varne

povezave TCP. Za zagotavljanje varnosti je uporabljen protokol SSL (»Secure Sockets

Layer« – sloj varnih vtičnic) oziroma TLS (»Transport Layer Security« – varnost

transportnega sloja), kar na kratko napišemo kot SSL/TLS. S tem se overi obiskano spletno

mesto in varuje zasebnost ter celovitost prenašanih podatkov.


16

5 POHITRITEV PRENOSA S PROTOKOLOM SPDY

SPDY je odprt omrežni protokol za prenos spletnih vsebin. SPDY manipulira s prometom

HTTP s ciljem zmanjšati čas nalaganja spletne strani in izboljšati spletno varnost. Ime SPDY

je blagovna znamka podjetja Google in se izgovori »speedy«. SPDY ni kratica. HTTP

omogoča nekakšno cevljenje, ne pa prioritizacije. Njegovi slabosti sta še nezmožnost

stiskanja glav sporočil in potiskanja virov s strežnika. V protokolu SPDY so za pohitritev

prenosa uvedli multipleksiranje zahtev, prioritizacijo, stiskanje glav sporočil in potiskanje s

strežnika.

5.1 Multipleksiranje in prioritizacija

SPDY multipleksira zahteve in odgovore preko ene same povezave TCP v obliki neodvisnih

tokov [2]. Cevljenje v HTTP-ju omogoča hkratne zahteve HTTP za pošiljanje preko

povezave TCP brez čakanja na ustrezne odzive (slika 4.1 (c)) [11]. Njegova slabost pa je

blokiranje na čelu vrste, ker specifikacija zahteva, da so viri vrnjeni v enakem vrstnem redu,

kot so bili zahtevani. To pa pomeni, da velik vir ali takšen, ki se dolgo pripravlja, lahko

zaustavi vse druge vire (slika 5.1).

Slika 5.1: Primera blokiranja na čelu vrste pri cevljenju HTTP [11].


17

Slika 5.2: Multipleksiranje in prioritizacija tokov [11].

SPDY izvaja cevljenje brez te omejitve. Viri se po povezavi prenašajo v označenih tokovih.

To so neodvisna zaporedja dvosmernih podatkov razdeljenih v okvirje. Označeni tokovi

omogočajo vračanje virov v poljubnem vrstnem redu in prepletanje virov po eni sami

povezavi TCP [11].

Prioritizacija pri SPDY-ju pomeni, da odjemalec lahko določi, da imajo nekateri tokovi in

tako viri pri vračanju višjo prioriteto kot drugi. Za razliko od številnih pristopov k

zagotavljanju kakovosti storitev, ki delajo na prioritiziranju paketov v vrstah v nižjih slojih

protokolnega sklada, prioritizacija v SPDY-ju deluje v aplikacijskem sloju, da lahko

odjemalec določi, kaj je pomembno. Ena od koristi prioritizacije je, da lahko za vire, ki

zavirajo gladek prikaz strani (CSS (»Cascading Style Sheets« – kaskadne slogovne podloge)

in JavaScript), zahtevamo višjo prioriteto. Drug primer uporabe je, da damo višjo prioriteto

virom, ki se morajo prenesti za trenutno vidni zavihek v brskalniku, kot pa tistim, ki jih

zahtevamo za trenutno skritega [11]. Primer multipleksiranja in uporabe prioritet je na sliki

5.2.


18

Vrednosti prioritet tokov so od 0 do 7, pri čemer je 0 najvišja prioriteta [4]. Tako zahteve

kot odgovori tokov z višjo prioriteto naj bi se poslali pred tistimi z nižjo. Slike naj bi imele

najnižjo prioriteto.

5.2 Sloj okvirjanja

Da bi lahko manipulirali s sporočili HTTP, so v SPDY-ju uvedli sloj okvirjanja. Ta sloj ali

t. i. seja se izvaja po obstojni povezavi TCP. Pobudnik za povezavo je odjemalec TCP. Za

najboljše rezultate se pričakuje, da odjemalec ne bo zaprl odprte povezave, dokler uporabnik

ne odide z vseh strani, ki uporabljajo povezavo, ali dokler strežnik ne konča povezave.

Strežniki naj bi pustili povezave odprte, kolikor časa je le možno, vendar lahko končajo

povezavo v primeru, če je nedejavna. Če katera končna točka, bodisi odjemalcec bodisi

strežnik, transportno povezavo zapre, mora najprej poslati okvir GOAWAY [4].

Okvirji SPDY se delijo na nadzorne in podatkovne. Nadzorni okvirji se uporabljajo za

prenos glav zahtev in odgovorov HTTP. Uporabljeni pa so tudi za upravljanje povezave in

javljanje konfiguracijskih možnosti [4]. Podatkovni okvirji se uporabljajo za prenos telesa

sporočil HTTP. Okvirji vsebujejo 8-zlogovno glavo. Prvi bit (C na sliki 5.3) je vedno

nadzorni bit, ki pove, ali je okvir nadzoren ali podatkoven. V nadzornih okvirjih najdemo

oznako različice protokola SPDY, zastavice, dolžino in tip okvirja. Vsebina podatkovnega

polja je odvisna od tipa okvirja. V podatkovnih okvirjih imamo identifikator toka, zastavice

in dolžino koristne vsebine, ki sledi glavi [4].

V samem toku SPDY definira tri različne nadzorne okvirje: SYN_STREAM, ki odpre nov

tok, SYN_REPLY, ki označuje sprejetje tvorjenega toka s strani prejemnika, in

RST_STREAM za izredno končanje toka [4].

Okvir SYN_STREAM omogoča, da pošiljatelj asinhrono tvori tok med končnima točkama.

Z okvirjem SYN_REPLY prejemnik okvirja SYN_STREAM sporoči, da se strinja s

tvorjenjem toka.


19

Slika 5.3 Nadzorni in podatkovni okvir [4].

Okvir RST_STREAM omogoča nenormalno prenehanje toka. Kadar je poslan od ustvarjalca

toka, pomeni, da hoče končati tok. Kadar je poslan od prejemnika, pomeni to napako ali pa

da prejemnik ni hotel sprejeti toka in se mora tok zapreti.

Okvir SETTINGS vsebuje nabor parov identifikator/vrednost za sporočanje konfiguracijskih

podatkov, kako naj končni točki komunicirata. Okvir se lahko pošlje kadarkoli od ene ali

druge končne točke.

Nadzorni okvir PING se uporablja za merjenje krožnega časa od oddajnika. Poslan je lahko

tako od strežnika ali odjemalca.

Okvir GOAWAY se uporablja, da oddajnik sporoči oddaljeni strani, naj preneha tvoriti

tokove v tej seji. Poslan je lahko s strežnika ali odjemalca. Potem ko je okvir poslan, se

pošiljatelj ne bo več odzval na nove okvirje SYN_STREAM v tej seji. Prejemniki tega

okvirja ne smejo več pošiljati dodatnih tokov v tej seji, lahko pa se ustvari nova seja oziroma

povezava za nove tokove. Namen okvirja je prenehanje povezave, ko se končujejo prej

ustvarjeni tokovi.

Okvir HEADERS dodaja v tok dodatne glave. Pošlje se lahko po potrebi v obstoječem toku

kadarkoli. Način uporabe glav v tem okvirju je odvisen od aplikacije.

Okvir WINDOW_UPDATE je nadzorni okvir, ki se uporablja za izvajanje krmiljenja

pretoka v SPDY-ju. Krmiljenje pretoka v SPDY-ju se izvaja po etapah, to je samo med

dvema končnima točkama. Ne sme biti enega ali več posrednikov med odjemalcem in

strežnikom. Krmiljenje pretoka se nanaša samo na podatkovne okvirje (DATA). Sprejemnik

v okvirju WINDOW_UPDATE sporoči oddajniku število dodatnih zlogov (»delta«), ki jih

sme poslati poleg obstoječe preostale velikosti okna. Sprejemniki morajo sprejeti in obdelati


20

vse nadzorne okvirje. Če nimajo virov za to, lahko javijo napako. Krmiljenje pretoka se

lahko nanaša na tok ali na celo povezavo. Tu je primer okvirja, ki se nanaša na tok 3:

Okvirji SYN_STREAM, SYN_REPLY in HEADERS vsebujejo v podatkovnem polju

identifikator toka, ki mu pripadajo, in blok parov ime/vrednost, ki je za prenos vedno

stisnjen. Za stiskanje se uporablja splošnonamenska metoda DEFLATE. Večina

implementacij protokola SPDY uporablja SSL/TLS za varen prenos, prenos pa se lahko

izvaja tudi kar po ne-varnih povezavah TCP.

5.3 Zahteve in odgovori HTTP v protokolu SPDY

Glave zahtev so v SPDY-ju ostale skoraj nespremenjene v primerjavi s HTTP 1.1.

Odjemalec pošlje zahtevo v okvirju SYN_STREAM, ki tvori nov tok. Če zahteva ne vsebuje

telesa, mora biti v okvirju SYN_STREAM nastavljena zastavica FLAG_FIN, kar pomeni,

da odjemalec ne namerava več pošiljati v tem toku. Če zahteva vsebuje telo, FLAG_FIN ni

nastavljen in telo se pošlje, glede na dolžino, v enem ali več podatkovnih okvirjih za

okvirjem SYN_STREAM. V zadnjem podatkovnem okvirju mora bit nastavljena zastavica

FLAG_FIN, da pove, da je konec telesa. Blok imen/vrednosti okvirja SYN_STREAM

vsebuje prvo vrstico in vse glave HTTP zahteve HTTP.

Metoda, URL in različica HTTP iz prve vrstice so zapisani kot vrednosti v parih z imeni

»:method,« »:path« oziroma »:version«. Namesto glave Host je par z imenom »:host«, shema

kot na primer https pa mora biti označena s »:scheme«. Če odjemalec pošlje

SYN_STREAMbrez označene metode, gostitelja, poti, sheme in različice, mora strežnik

odgovoriti z odgovorom HTTP 400 [4].


21

Odgovor strežnika na zahtevo pride z okvirjem SYN_REPLY. Strežnik bo poslal odgovor

takoj, kakor hitro se konča zahteva. Če odziv vsebuje telo, se podobno kot pri

SYN_STREAM pošlje v zaporedju okvirjev DATA in zadnji ima nastavljeno zastavico

FLAG_FIN, ki označuje uspešen konec toka. Če odziv ne vsebuje telesa, lahko okvir

SYN_REPLY vsebuje samo zastavico FLAG_FIN in s tem sporoči, da se ne bo poslalo več

podatkov v toku. Glave HTTP so predstavljene v bloku imen/vrednosti. Statusna koda iz

prve vrstice odziva se zapiše pod imenom »:status«, različica pa spet pod »:version«. V

primeru prejetja SYN_REPLY brez oznake statusa ali oznake različice mora odjemalec

odgovoriti z okvirjem RST_STREAM, ki kaže na napako protokola [4].

Kot vidimo, SPDY v glavnem ohranja semantiko protokola HTTP. Spremembe so predvsem

v sintaksi. V zahtevah in odgovorih morajo biti imena glav v malih črkah. Glave zahtev in

odgovorov Connection, Host, Keep-Alive, Proxy-Connection in Transfer-Encoding niso

veljavne in se ne pošljejo. Uporabniški agenti (odjemalci) morajo podpirati stiskanje gzip.

Odgovor lahko spremlja glava Content-Length, ki je zgolj informativne narave. Če

odjemalec prejme odgovor, v katerem vsota dolžin podatkov okvirjev DATA ni enaka

vrednosti v glavi Content-Lenght, se ta glava ignorira [4]. Če podobno neenakost opazi

strežnik, ko prejme zahtevo, pa mora javiti napako s statusno kodo 400.

5.4 Potisk s strežnika

Ta napredna funkcija omogoča, da strežnik samodejno prične pošiljati vir, kar prikazuje

slika 5.4, ne da bi čakal ustrezen zahtevek odjemalca. Razlog za to je, da strežnik včasih ve,

da se bo moralo poslati več virov za določeno zahtevo. Brez zmožnosti potiska mora

odjemalec dobiti začetni vir in šele nato z zahtevami dobiti preostale vire za zahtevano stran

[4].

Slika 5.4 prikazuje strežnikovo potiskanje vira odjemalcu, ki bi vir zahteval v kratkem.

Potiskanje s strežnika prihrani odvečne zahteve z zanašanjem, da strežnik pozna medsebojno

odvisnost virov in tako ve, kaj poslati odjemalcu [11].


22

Slika 5.4: Potisk s strežnika SPDY [11].

Strežnik za potisk vira do odjemalca odpre nov, enosmeren tok z oddajo okvirja

SYN_STREAM, v katerem označi, na kateri tok se nanaša potisnjeni vir. Glava

SYN_STREAM vsebuje glave »:scheme«, »:host« in »:path«, ki predstavljajo URL

potisnjenega vira. Če je odjemalec na primer zahteval vir v toku 11, se mora strežnikov

potisk nanašati na tok 11. Lahko potisne poljubno število dodatnih tokov do odjemalca,

preden se pošlje zastavica FLAG_FIN na 11. Strežnik sme potisniti samo tiste vire, ki bi se

sicer vrnili na zahtevo GET [4].

5.5 Povezave TCP pri protokolih HTTP in SPDY

Pred standardizacijo HTTP 1.1 v letu 1999 je HTTP 1.0 dovoljeval naložitev samo enega

vira preko ene povezave TCP in le štiri sočasne povezave TCP do kateregakoli danega

strežnika. Pri HTTP 1.1 so uvedli obstojne povezave, po katerih je možno prenašati za več

virov. Hkrati so zmanjšali največje število sočasnih povezav TCP s štirih na dve, kar je

pomenilo zmanjšanje obremenitve strežnika.

Prav tako so se ublažili zastoji prometa v internetu, ki jih je povzročalo naraščanje števila

kratkotrajnih povezav TCP. Prepolovitev števila sočasnih povezav pa je žal zmanjšala

vzporednost prenosa. Pri HTTP 1.1 so predvidevali, da bi to težavo rešilo na novo uvedeno

cevljenje, vendar se je izkazalo, da ga je težko izvesti in da trpi za blokiranjem na čelu vrste

[11].


23

Samo dve sočasni povezavi pomenita zelo ozko grlo za današnje hitre internetne povezave

in kompleksne spletne strani. Prvič, počasni začetek TCP je pogosto pretirano zadržan pri

začetnem dodeljevanju pasovne širine. Potrebnih je precej pošiljanj sem in tja, preden se

povezava zasiti. Do takrat pa je bila večina vsebine morda že prenesena (in to počasneje, kot

bi lahko bila). Drugič, tipična sodobna spletna stran vsebuje več deset ali celo več sto virov,

vendar se lahko zahtevata le dva vira ob kateremkoli času. Brez cevljenja zahtev HTTP ni

mogoče postaviti na čakanje na strežnik, tako da vsaka nova zahteva povzroči dodaten krog.

Ker je večina spletnih virov majhne velikosti, čas potovanja do strežnika pogosto presega

čas za prejem vira od prvega do zadnjega zloga.

Sodobni brskalniki ne upoštevajo standarda HTTP 1.1 in omogočajo šest ali več sočasnih

povezav TCP do enega strežnika. To v veliki meri pomaga, da se obema opisanima težavama

izognemo. Efektivna začetna pasovna širina namreč postane enaka konstanti počasnega

začetka povezave TCP * 6 (namesto * 2) in potrebnih je manj povratnih pošiljanj zaradi višje

možne vzporednosti zahtev. Pogosta praksa med velikimi podjetji, kot so Facebook, Google

in Twitter, je, da »razdrobijo« vire spletne strani preko več domen, da bi omajala politiko

brskalnikov in še povečala sočasnost. V sodobnih brskalnikih se lahko za spletno stran,

razdrobljeno preko štirih domen, vzpostavi 4 * 6 = 24 sočasnih povezav TCP.

Povečanje števila sočasnih povezav z brskalnikovo politiko in drobljenjem lahko izboljša

čas nalaganja, vendar povzroči nove probleme [20]. Sočasne povezave TCP lahko skupaj

presežejo presežejo celotno razpoložljivo pasovno širino, kar lahko povzroči izgubo paketov

[11]. Poleg tega se z večjim številom sočasnih povezav poveča verjetnost izgube pomembnih

nadzornih paketov.

Visoko sočasne povezave TCP prav tako zmanjšajo verjetnost izvajanja hitre ponovne

oddaje na podlagi izgube paketov. Hitra ponovna oddaja je izboljšava protokola TCP, ki

takoj ponovno pošlje paket brez čakanja na potek intervala časovnika, če prejme potrditve

za več paketov, ki sledijo izgubljenemu. Visoko sočasne povezave pridobijo manj pasovne

širine kot ena sama dolgotrajna povezava. Zato je manj verjetno, da bi bilo prejetih in

potrjenih dovolj paketov v dovolj kratkem času, da bi se sprožila hitra ponovna oddaja.


24

Visoko sočasne povezave TCP pomenijo, da je treba vzdrževati več stanj na različnih mestih

v omrežju, na primer v opremi NAT (»Network Address Translation« – prevajanje omrežnih

naslovov). V nekaterih primerih tako stanje povzroči, da strojna ali programska oprema

odpove ali da veliko sočasnih zahtev po odprtju povezav napačno tolmači kot poplavo

segmentov SYN (to je oblika napada s preprečevanjem storitve).

Visoko sočasni kratkotrajni pretoki TCP protokola HTTP spadajo v kategorijo povezav,

pogovorno poznanih tudi kot »mišji pretoki«. Nasprotno je SPDY sposoben uporabiti eno

dolgotrajno povezavo, »slonji pretok«, saj lahko multipleksira in uporabi prednostne zahteve

preko ene same povezave. SPDY zato ohranja prednosti visoko sočasnih povezav HTTP

brez stranskih učinkov [11].


25

6 POHITRITEV PRENOSA S PROTOKOLOM HTTP 2.0

Protokol SPDY je bil uporabljen kot jedro za novejši in hitrejši HTTP 2.0. Ker je SPDY

prikazal določene izboljšave, ki se lahko uvedejo v HTTP 1.1, so se odločili, da posodobijo

zastareli protokol. SPDY je postavil meje za sodobnejši HTTP 2.0, ne da bi kar koli vplivalo

na starejši protokol HTTP 1.1. HTTP 2.0 je že objavljen kot »Proposed Standard« (predlog

standarda) v RFC 7540 pod imenom HTTP/2 [13]. Zagotavlja optimaliziran transport za

semantiko HTTP. Podpira vse glavne značilnosti protokola HTTP 1.1, vendar je še

učinkovitejši. HTTP 2.0 uporablja shemi URI (»Uniform Resource Identifier« – enolični

identifikator vira) http in https, ki sta bili uporabljeni že v HTTP 1.1. Deli si isti privzeti

številki vrat: 80 za HTTP in 443 za HTTPS.

HTTP 2.0 je zelo podoben protokolu SPDY. Osnovna protokolna enota je okvir. Uveden je

sloj okvirjanja nad TCP-jem [6]. V osnovi uporablja enake pristope k pohitritvi prenosa kot

SPDY, le da so nekateri izboljšani. Tako kot SPDY izvaja multipleksiranje in prioritizacijo

tokov po eni povezavi TCP, stiskanje glav in potiskanje s strežnika. Obdržal je semantiko

HTTP 1.1 vključno z metodami HTTP, statusnimi kodami, URI-ji in glavami [5].

6.1 Multipleksiranje zahtev in odgovorov

V jedru zmogljivosti HTTP 2.0 je nov izboljšani binarni sloj okvirjanja, ki narekuje, kako se

bodo sporočila HTTP pošiljala med strežnikom in odjemalcem (slika 6.1).

S HTTP 1.x, če je odjemalec želel več vzporednih zahtev za izboljšanje učinkovitosti, je

potreboval več povezav TCP hkrati. Okvirji v HTTP 2.0 odpravljajo te omejitve in

omogočajo popoln način multipleksiranja zahtev in odgovorov [5].


26

Slika 6.1: Binarno okvirjanje [5].

Tok je dvosmeren tok zlogov ali virtualen kanal v povezavi. Vsak tok ima relativno

prednostno vrednost in edinstven celoštevilski identifikator. Identifikatoriji odjemalčevih

tokov imajo lihe številske vrednosti, strežniški tokovi pa sode, kot v SPDY-ju. To preprečuje

trčenja tokov med odjemalcem in strežnikom.

Sporočilo je celotno zaporedje okvirjev, ki se preslika v logično sporočilo, kot je recimo

zahteva ali odgovor.

Okvir je najmanjša enota komunikacije v HTTP 2.0. Vsak okvir vsebuje glavo, ki vsaj

identificira tok, ki mu okvir pripada, in nosi določeno vrsto podatkov (na primer glave

HTTP, del telesa HTTP).

Slika 6.2: Prepletanje okvirjev več tokov v povezavi [5].


27

Kot pri SPDY-ju se vsa komunikacija lahko izvaja v eni sami povezavi TCP, saj lahko nosi

poljubno mnogo dvosmernih tokov. Vsak tok sestoji iz sporočil, ki so sestavljena iz enega

ali več okvirjev, kateri se lahko med seboj prepletajo, nato pa na podlagi identifikatorja toka

sestavijo v prvotno sporočilo [5].

6.2 Binarno okvirjanje

Vsi okvirji HTTP 2.0 se pričnejo s fiksno glavo velikosti 9 zlogov. Tej sledi koristna vsebina

okvirja. V glavah so polja, dolžina, tip, bitno polje za zastavice, enobitno polje R in 31-bitni

identifikator toka [19].

8-bitno polje tipa določa, kako se razlaga preostali del okvirja. 8-bitno polje zastavice

omogoča bitne zastavice, odvisne od tipa okvirja. 1-bitno polje R je vedno nastavljeno na 0

in se ne uporablja. Identifikator toka edinstveno identificira tok HTTP 2.0 [5]. V okvirjih, ki

se tičejo povezave in ne posameznega toka, je nastavljena vrednost 0.

Okvirji DATA se uporabljajo za pošiljanje poljubnih različno dolgih zaporedij oktetov

nekega toka. En ali več okvirjev DATA je na primer uporabljenih za prenos telesa zahtev in

odgovorov HTTP.

Okvir HEADERS se uporablja za odpiranje toka in nosi čela HTTP v stisnjeni obliki.

Okvir PRIORITY nosi prioriteto v tem okvirju označenega toka. Pošlje ga lahko odjemalec

v vsakem stanju toka, da na novo določi prioriteto toka.

Okvir RST_STREAM omogoča takojšnjo prekinitev toka. Pošlje se na primer takrat, kadar

pride do kakršnekoli napake med prenosom.

Okvir SETTINGS posreduje konfiguracijske parametre, ki vplivajo na to, kako bosta končni

točki komunicirali. Okvir se uporablja tudi za potrditev teh parametrov. Okvir se pošlje z

obeh končnih točk. Vsak prejet parameter nadomesti starejšega. Parametri se obdelujejo v

enakem vrstnem redu, kakor se pošljejo.


28

Okvir PUSH_PROMISE pošlje strežnik, da obvesti odjemalca o nameravanju pričetka

novega toka. Okvir vključuje identifikator novega toka skupaj z nizom glav, ki določajo

dodaten kontekst toka.

Okvir PING se podobno kot pri SPDY-ju uporablja za merjenje krožnega časa od oddajnika.

Prav tako izvemo, ali povezava še deluje. Okvir lahko pošlje katerakoli končna točka.

Okvir GOAWAY se uporablja za sprožitev zaprtja povezave ali pa za signaliziranje resnih

napak v povezavi. Okvir omogoča končnim točkam, da nemoteče nehajo sprejemati nove

tokove in dokonačjo procesiranje prej vzpostavljenih tokov.

Okvir WINDOW_UPDATE je uporabljen za krmiljenje pretoka. Tako kot pri SPDY-ju se

nadzor krmiljenja izvaja na dveh nivojih, v posameznem toku in čez celotno povezavo in na

eni etapi. V okvirju sprejemnik javi, koliko oktetov je pripravljen sprejeti v toku oziroma

povezavi. To omejitev mora oddajnik upoštevati samo za okvirje DATA.

Okvir CONTINUATION je uporabljen za nadaljevanje pošiljanja zaporedja stisnjenih glav.

Poslano je lahko poljubno število takšnih okvirjev, dokler je prejšnji okvir v istem toku in je

okvir HEADERS, PUSH_PROMISE ali CONTINUATION brez nastavljene zastavice

END_HEADERS.

6.3 Dopolnjevanje

Za okvirje DATA, HEADERS in PUSH_PROMISE se lahko uporabi dopolnjevanje

(»padding«). To pomeni, da se na koncu koristne vsebine okvirja doda izbrano število

zlogov, tako imenovanih dopolnjevalnih zlogov, da se zamegli točna velikost okvirja in s

tem ublaži določene vrste napadov v protokolu HTTP. Dopolnjevalni zlogi nimajo pomena.

Za ublažitev napadov, ki se zanašajo na stiskanje, je bolje onemogočiti ali omejiti stiskanje,

kot pa uporabiti dopolnjevanje. Nepravilno izvajano dopolnjevanje je možno zelo lahko

premagati [19]. Dopolnjevanje so uvedli tudi v protokolu SPDY v osnutku 3.2.


29

6.4 Zahteve in odgovori v protokolu HTTP 2.0

V jedru je HTTP 2.0 še vedno protokol zahteva–odgovor. Odjemalec pošlje strežniku

zahtevo in strežnik pripravi odgovor ter ga pošlje nazaj. Le potisk strežnika je izjema.

Zahteva se prične s pošiljanjem okvirja HEADERS za odprtje toka. Vsebuje običajne glave

zahteve HTTP, vsebuje pa tudi tako imenovane psevdoglave: »:method«, ki pove zahtevano

metodo, »:path« zahtevano pot, »:scheme« zahtevano shemo (http, https) in »:authority«, ki

podobno kot glava HTTP 1.1 Host vsebuje del ciljnega URI-ja [18].

Te psevdoglave morajo biti na začetku. Potem lahko okvir HEADERS vsebuje poljubno

število glav zahteve. Če število glav zahtev presega dovoljeno dolžino okvirja, se morajo

poslati okvirji CONTINUATION z dodatnimi glavami. V zadnjem okvirju z glavami se

nastavi zastavica END_HEADERS, ki napove konec glav [18]. Zahteva lahko vsebuje

podatke (na primer zahteva POST). Če zahteva ne vsebuje podatkov, bo imel okvir

HEADERS nastavljeno zastavico END_STREAM, ki pove strežniku, da ni podatkov. V

nasprotnem primeru bo strežnik pričakoval od odjemalca še okvirje DATA. V zadnjem bo

nastavljena zastavica END_STREAM.

Strežnik pošlje odgovor v zaporedju okvirjev enake vrste kot odjemalec zahtevo. Razlika je

le, da je edina psevdoglava »:status«, ki nosi statusno kodo odziva [18].

HTTP 2.0 ne določa, kako se prenese različica protokola ali statusna fraza iz prve vrstice

sporočil HTTP 1.1. Tako kot pri SPDY-ju morajo biti glave HTTP napisane z malimi črkami

[19].

6.5 Prioritizacija tokov

Tudi v protokolu HTTP 2.0 prioritizacija odjemalcu omogoča nastavitve prednosti za

določene tokove, a deluje nekoliko drugače kot v protokolu SDPY [8]. Uporablja odvisnosti

tokov in uteži. Odjemalec lahko za tok nastavi odvisnost od drugega toka, ki pove strežniku,

naj pridobi vire za ta drugi tok namesto za tok, odvisen od njega. Strežnik mora dodeliti vire

odvisnemu toku samo v primeru, če so se vsi tokovi, od katerih je odvisen, zaprli oziroma ni

več mogoče nadaljevati na njih [18].


30

Odvisni tokovi lahko imajo določeno tudi utež z vrednostjo med 1 in 256. Tokovom,

odvisnim od istega toka, se viri dodeljujejo sorazmerno glede na uteži. Na primer, če sta

tokova A in B odvisna od C in ima A utež 1 ter B utež 10, potem bo B pridobil 10-krat toliko

strežnikovih virov kot A. Odvisnost in utež se lahko nastavi ob tvorjenju toka in se lahko

kasneje spremeni z okvirjem PRIORITY. Strežnik lahko nastavljene odvisnosti in uteži

ignorira. Torej se drugače kot prioritete v SPDY-ju jemljejo kot priporočilo in odjemalec se

ne more zanašati na njih [18].

6.6 Potisk s strežnika

Za potisk odgovora do odjemalca strežnik odpre tok s pomočjo okvirja PUSH_PROMISE,

ki vsebuje celoten nabor glav zahteve, ki bi jih strežnik pričakoval v prejeti zahtevi. Okvir

PUSH_PROMISE mora biti povezan z obstoječo odjemalčevo zahtevo, tako da odjemalec

ve, katera zahteva je povzročila potisk. Iz njega mora odjemalec tudi videti, kateri vir bo

potisnjen. Za tem okvirjem lahko strežnik začne pošiljati okvir HEADERS, ki mu sledijo

okvirji DATA, kot za običajen odgovor. HTTP 2.0 ima torej za razliko od SPDY-ja poseben

okvir PUSH_PROMISE za začetek potiskanja [18].

6.7 Stiskanje glav

Vsak prenos HTTP nosi niz glav, uporabljenih za opis prenašanega vira. V HTTP 1.x so

metapodatki vedno poslani kot goli tekst in pomenijo približno od 500 do 800 zlogov balasta

na zahtevo, pogosto pa še več, če so uporabljeni še piškotki HTTP. Za zmanjšanje balasta in

izboljšanje učinkovitosti HTTP 2.0 glave stisne[21].

Namesto ponovnega pošiljanja istih glav za vsako zahtevo in odgovor HTTP 2.0 uporablja

tabele glav za ugotavljanje, katere glave so enake kot prej poslane, in take se ne pošljejo

ponovno [5]. Metoda stiskanja se imenuje HPACK [19]. HPACK deluje tako, da obe končni

točki hranita tabelo glav, tako imenovano dinamično tabelo. Ko ena končna točka pošlje

glavo drugi, ji lahko naroči, naj jo shrani v dinamično tabelo. V primeru ponovnega

pošiljanja te glave se lahko pošlje samo kazalec na glavo v dinamični tabeli [18]. Za stiskanje


31

vsake glave se lahko uporabi Huffmanovo kodiranje [19].

Protokol SPDY verzije 2 je predlagal uporabo enotnega konteksta stiskanja gzip za stiskanje

glav v vsaki smeri, ki je enostavno za uporabo in učinkovito. Gzip uporablja metodo

DEFLATE in je zato lahka tarča napada CRIME [22]. Zato so za HTTP 2.0 uvedli metodo

HPACK, ki naj bi izboljšala odpornost na tak napad.

6.8 Prehod na uporabo protokola HTTP 2.0

HTTP 2.0 prinaša pomembne spremembe zmogljivosti na strani strežnika in odjemalca.

Dobra novica je ta, da sodobni brskalniki uporabljajo učinkovite mehanizme v ozadju, ki

bodo omogočili podporo HTTP 2.0 z minimalno intervencijo za večino uporabnikov. HTTP

1.x bo med nami vsaj še desetletje in večina strežnikov in odjemalcev bo moralo podpirati

tako standard 1.x kot standard 2.0. Odjemalec s podporo HTTP 2.0 bo moral sam odkriti,

kakšna verzija teče na strežniku. Upoštevati je treba dva primera.

Pri prvem gre za začetek nove povezave s protokolom HTTP 2.0 preko TLS. V tem primeru

nova razširitev ALPN (»Application Layer Protocol Negotiation« – pogajanje o protokolu

aplikacijskega sloja) protokola TLS omogoča uporabnikom pogajanje o podpori HTTP 2.0

kot del rednega rokovanja TLS. Odjemalec pošlje seznam podprtih protokolov (npr. HTTP

2.0). Strežnik izbere enega izmed oglaševanih protokolov in potrdi izbiro s pošiljanjem

imena protokola nazaj do odjemalca kot del rednega rokovanja TLS [5].

Vzpostavitev povezave HTTP 2.0 preko nešifriranega kanala zahteva več dela. Ker tako

HTTP 1.0 kot HTTP 2.0 tečeta na istih vratih (80), mora odjemalec v odsotnosti katerekoli

informacije o podpori strežnika za HTTP 2.0 uporabiti mehanizem za nadgradnjo HTTP [5].

To stori tako, da pošlje zahtevo HTTP 1.1, ki vsebuje glavo Upgrade z vrednostjo h2c in

natanko eno glavo HTTP2-Settings (slika 6.3).


32

Slika 6.3: Primer uporabe posodobitvenega mehanizma HTTP [5].

Če strežnik ne podpira HTTP 2.0, lahko za zahtevo takoj pošlje odgovor v obliki HTTP 1.1.

Strežnik, ki podpira HTTP 2.0, sporoči strinjanje z njegovo uporabo z odgovorom »101

Switching Protocols« v formatu HTTP 1.1, nato takoj preklopi na HTTP 2.0 ter lahko prične

pošiljati odgovor v okvirjih HTTP 2.0. Niti v prvem niti v drugem primeru torej niso potrebni

dodatni krogi pošiljanja [5].


33

7 PRIJEMI ZA HITER PRENOS V PROGRAMU FIREFOX

V poglavju 7 bomo izvedli meritve in opazovali dogajanje pri dostopu do izbrane spletne

strani z brskalnikom Firefox s protokoli HTTP 1.1, SPDY in HTTP 2.0 ter analizirali razlike

v rezultatih.

7.1 Program Mozilla Firefox

Mozilla Firefox je brezplačen in odprtokodni spletni brskalnik, ki sta ga razvili Mozilla

Foundation in njena hčerinska družba Mozilla Corporation. Firefox je na voljo za operacijske

sisteme Windows, OS X in Linux, prav tako pa obstajata tudi verziji za mobilne telefone, ki

ju poganjata Android in Firefox OS. Firefox je bil ustanovljen v letu 2002 pod imenom

Phoenix. Že v času verzij beta se je izkazala njegova priljubljenost pri testnih uporabnikih,

saj so pohvalili hitrost, varnost in dodatke v primerjavi s takrat prevladujočim Internet

Explorerjem 6. Firefox je izšel leta 2004 in je imel v 9 mesecih že 60 milijonov prenosov.

Po podatkih iz februarja 2015 ima Firefox 12- do 20-odstotni delež uporabe po vsem svetu

ter je tretji najbolj priljubljen spletni brskalnik. Brskalnik uporablja približno pol milijarde

uporabnikov [15].

Za poskuse s tem brskalnikom smo se odločili zaradi njegove popularnosti in ker omogoča

vse tri protokole, ki nas zanimajo (HTTP 1.1, SPDY 3.1, HTTP 2.0).

7.2 Vključitev indikatorja za SPDY in HTTP 2.0

Na spletni strani https://addons.mozilla.org/sl/firefox/addon/SPDY-indicator/?src=ss [ 29. 7.

2015] lahko dobimo za Firefox indikator, ki pove, kateri protokol podpira določena spletna

stran (slika 7.1). Indikator prikaže, ali se na strežniku uporablja SPDY ali HTTP 2.0 (sliki

7.2 in 7.3).

https://addons.mozilla.org/sl/firefox/addon/spdy-indicator/?src=ss


34

Že ob ogledu naključno izbrane strani se nam je koncu vrstice prikazala modra strela, ki

prikazuje delovanje protokola HTTP 2.0 na najvišjem nivoju dokumenta (slika 7.2).

Indikator za stran prikaže delovanje protokola SPDY za nekatere poddokumente, vključene

na najvišjem nivoju dokumenta (slika 7.3).

Slika 7.1: Indikator podpore protokolov HTTP/2 in SPDY za Firefox.

Slika 7.2: Prikaz indikatorja v vrstici z naslovom spletne strani.

Slika 7.3: Indikator, ki prikazuje delovanje protokola SPDY.


35

7.3 Orodje za analizo učinkovitosti prenosa spletnih strani

Za analizo učinkovitosti prenosa spletnih strani smo uporabili Firefoxovo orodje Omrežje in

HttpWatch. Brskalnik Firefox že sam po sebi vsebuje orodje Omrežje. Vklopiti ga je mogoče

pod možnostmi za razvijalce. HttpWatch je program, ki prav tako analizira prenos spletne

strani, a ga niso razvili pri podjetju Firefox. Za njegovo uporabo smo se odločili, ker

omogoča še podrobnejši pregled prenosa.

7.3.1 Firefoxov omrežni opazovalec

Orodje Omrežje (v nadaljevanju omrežni opazovalec) pokaže vse zahteve HTTP, ki jih

naredi Firefox, kako dolgo traja zahteva skupaj z odgovorom in podrobnosti o vsaki zahtevi.

Vsaka zahteva je prikazana v svoji vrstici, kot kaže slika 7.4.

Slika 7.4: Prikaz posamezne zahteve.

V začetku vrstice je označena vrsta odgovora, prejetega za zahtevo. Pomen oznak je prikazan

na sliki 7.5.

Slika 7.5: Odgovori na zahteve HTTP.


36

Kot vidimo na sliki 7.4, je v stolpcu Metoda napisana vrsta metode zahteve HTTP. Datoteka

pove osnovno ime datoteke, sledi pa njena domena. Vrsta pove tip vira, poslanega v

odgovoru, Preneseno pa nam pokaže število zlogov, ki so se dejansko prenesli za naložitev

vira. Velikost nam pove velikost vira po dekompresiji.

S klikom na vrstico z zahtevo dobimo podrobnejše informacije o zahtevi. Tak primer lahko

vidimo na sliki 7.6. V oknu Časi se prikažejo časi povezovanja, pošiljanja, čakanja,

sprejemanja in razreševanja DNS posameznih zahtev:

Omrežni opazovalec vključuje orodje za analizo učinkovitosti, ki pokaže število, skupno

velikost in trajanje prenosa za naložene vire posameznega tipa. Za zagon analize

učinkovitosti stisnemo štoparico v rdečem kvadratu, na sliki 7.6 je desno spodaj (slika 7.7).

Slika 7.6: Prikaz podrobnosti zahteve.

Slika 7.7: Vrstica s štoparico ter prikazom števila, časa in velikosti vseh zahtev.


37

Slika 7.8: Grafična predstavitev podatkov o nalaganju.

Omrežni opazovalec nato naloži stran dvakrat: enkrat s praznim predpomnilnikom in drugič

z napolnjenim predpomnilnikom (slika 7.8).

7.3.2 HttpWatch

HttpWatch se lahko integrira z Internet Explorerjem in Firefoxom brez ločenega

konfiguriranja ali drugih omrežnih vohljačev. Orodje omogoča podobne stvari kot Firefoxov

omrežni opazovalec in še boljše. S programom si lahko ogledamo izgled glav, piškotkov,

časovni potek nalaganja, značilnosti povezav s protokolom SSL. Analizator nam tudi

omogoča tud shranitev rezultatov meritve, da si jo lahko ogledamo kasneje [17].

Za natančnejšo meritev je možno pobrisati vse piškotke in predpomnilnik pod razdelkom

»Tools«. Omogočeno je tudi dodajanje stolpcev z različnimi informacijami, na primer

Protocol, SSL Handshake, Connect, HTTP/2, SPDY ... Večino meritev smo opravili s tem

orodjem, ker je omogočalo natančnejši pregled informacij o merjenju.

Uporabili smo brezplačno verzijo programa HttpWatch Basic Edition, ki omogoča podrobni

pregled le za prvih 20 spletnih strani Alexa Top 20. Program se lahko dobi na spletni strani

https://www.httpwatch.com/download.

7.4 Wireshark

Wireshark je brezplačen in odprtokodni paketni analizator. Uporablja se za odpravljanje

težav v omrežju, analiziranje ter razvoj programske opreme in komunikacijskih protokolov.

https://www.httpwatch.com/download


38

Uporabniku omogoča, da krmilnike omrežnih vmesnikov, ki omogočijo promiskuitetni

način, da v ta način. To pomeni, da lahko vidimo ves promet, ki teče od nas do strežnika in

nazaj. Wireshrak je programska oprema, ki »razume« zgradbo sporočil različnih omrežnih

protokolov. Lahko razčleni in prikaže polja skupaj z njihovim pomenom, kot je določeno v

različnih omrežnih protokolih [16]. Wireshark uporablja za zajemanje paketov pcap, tako da

lahko zajame pakete samo v omrežjih, ki podpirajo pcap. Podatke je mogoče zajeti »z žice«

preko žive omrežne povezave, možno pa je tudi branje že zajetih podatkov, ki so shranjeni

v datoteki. Podatke je možno zajemati z vmesnikov, kot so ethernet, IEEE 802.11, PPP in

povratna zanka.

7.5 Analiza z orodjem HTTPWatch Basic Edition in Firefoxovim

opazovalcem

Analizirali smo nalaganje strani https://www.google.co.uk. Stran je bila analizirana zato, ker

podpira protokole HTTP 1.1, HTTP/2 in SPDY in je na seznamu Alexa Top 20. Z analizo

smo ugotovili, kateri protokoli delujejo pri različnih nastavitvah v Firefoxu. Na strani

about:config smo spreminjali tri parametre, ki so obkroženi na sliki 7.9.

O merjenju učinkovitosti prenosa Googlove britanske domače spletne strani poroča že

spletni blog [1], vendar smo mi meritve priredili po lastnih potrebah in jih naredili sami.

Meritve s HttpWatch Basic Edition smo opravili tako, da smo vsakokrat posebej počistili

predpomnilnik in nato pričeli z meritvijo.

Slika 7.9: Trije parametri za izbiro spletnega protokola.

https://www.google.co.uk/


39

Za boljšo meritev smo uporabili ukaz netstat (»network statistics«). Netstat se prikliče v

ukazni vrstici v operacijskem sistemu Windows (Command Prompt):

Netstat prikaže trenutno aktivne povezave TCP in povezave, ki se počasi zapirajo. Prikazuje

tako odhodne kot dohodne povezave. Da se pri nalaganju spletne strani ne bi uporabile že

obstoječe povezave do strežnikov, smo pred vsako meritvijo počakali na najmanjše možno

število povezav in jo šele takrat izvedli.

7.5.1 Meritve s HttpWatch Basic Edition

Test #1 – Število povezav TCP in rokovanj SSL med prenosom

Prva meritev je potekala z vsemi tremi parametri nastavljenimi na true. Na sliki 7.10 vidimo,

da ta nastavitev pomeni uporabo protokola HTTP 2.0. Ta protokol bi se izvajal tudi, če bi

bil parameter za SPDY 3.1 enak false.

Slika 7.10: Meritev števila povezav TCP in rokovanj SSL 1.


40

Druga meritev je potekala pri vklopljeni možnosti network.http.spdy.enabled.http2. Ker so

stolpci Protocol, HTTP/2 in SPDY prazni, pomeni, da ta nastavitev povzroči uporabo

protokola HTTP 1.1, seveda v primeru naše strani preko SSL/TLS (slika 7.11).


To smo preverili tudi z izpisom podrobnosti o glavah zahtev in odgovorov (glejte sliko 7.25).

Tretja meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.http2draft

in jo prikazuje slika 7.12. Vidimo, da se je uporabljal protokol HTTP/2 draft 15.


Četrta meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.v3-1. Ta

nastavitev torej pomeni protokol SPDY 3.1 (slika 7.13).



41

Peta meritev je potekala z vsemi možnostmi nastavljenimi na false. Rezultat prikazuje slika

7.14. Uporabil se je protokol HTTP 1.1.


Pri meritvi števila povezav TCP in rokovanj SSL smo dobili enak rezultat pri merjenju za

HTTP/2 draft 15, HTTP 2.0 in SPDY 3.1. Vse tri meritve so pokazale tri povezave TCP in

tri rokovanja SSL, kar pomeni, da se povezujemo na 3 različne strežnike. Oba protokola

podpirata multipleksiranje povezav, kar pomeni zmanjšanje obremenitve za strežnik. Mnoge

zahteve SPDY 3.1, HTTP 2.0 in HTTP/2 draft 15 so izkoristile že vzpostavljeno povezavo

in niso potrebovale vzpostavitve nove. Pri takšnih zahtevah se izpiše obvestilo o pouporabi,

kot na primer:

Pri HTTP 1.1 imamo vzpostavljenih več povezav do enega strežnika, to se vidi pri številu

povezav do istega naslova..

Test #2 – Velikost zahtev in odgovorov

Prva meritev je potekala z vsemi tremi parametri nastavljenimi na true, torej za HTTP 2.0

(slika 7.15).

Slika 7.15: Meritev velikosti zahtev in odgovorov 1.


42

Druga meritev je potekala pri vklopljeni možnosti network.http.spdy.enabled.http2, torej za

HTTP 1.1 (slika 7.16).


Tretja meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.http2draft

(slika 7.17).


Četrta meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.v3-1, (slika

7.18).


Peta meritev je potekala z vsemi možnostmi nastavljenimi na false (slika 7.19).



43

Pri meritvi velikosti zahtev in odgovorov smo dobili dva različna zmagovalca. Pri pošiljanju

zahtev (Sent) sta bila prepričljivo boljša HTTP/2 draft 15 in HTTP 2.0, saj sta imela bistveno

manj poslanih podatkov kot druga dva protokola. Pri pošiljanju odgovorov (Received) je

zmagal SDPY 3.1, saj je prejel najmanj podatkov. V količini poslanih podatkov skoraj ni

razlike med HTTP 1.1 in SPDY, iz česar lahko sklepamo, da brskalnik ne omogoča stiskanja

glav SPDY zaradi varnostne luknje, ki jo povzroča stiskanje pri njem. Pri HTTP 2.0 se za

večjo varnost koristni vsebini lahko dodajo dopolnjevalni zlogi. To je verjetno razlog, da je

količina prejetih podatkov pri njem večja kot pri SPDY-ju.

Test #3 – Čas nalaganja strani

Prva meritev je potekala z vsemi tremi parametri nastavljenimi na true. Čas nalaganja strani

je v stolpcu Time v prvi vrstici na sliki 7.20. Sliki 7.21 in 7.22 prikazujeta časovni potek in

glave pri prvi zahtevi, ki se pošlje za stran.

Slika 7.20: Meritev časa nalaganja strani 1.

Slika 7.21: Podrobnejši prikaz prve zahteve pri meritvi 1.

Slika 7.22: Podrobnosti glav prve zahteve in odgovora pri meritvi 1.


44

Druga meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.http2, torej

za HTTP 1.1 (slike 7.23, 7.24, 7.25).




Tretja meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.http2draft,

torej za HTTP 2.0 draft 15 (slike 7.26, 7.27 in 7.28).




45


Četrta meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.v3-1, torej

za SPDY 3.1 (slike 7.29, 7.30 in 7.31).





46

Peta meritev je potekala z vsemi tremi parametri na false (slike 7.32, 7.33 in 7.34).




Najdaljši čas je naše merjenje prikazalo za protokol HTTP/2 draft 15. Ta pa ni veliko daljši

kot čas pri protokolu HTTP 1.1.Opazimo, da je SPDY 3.1 imel najboljši čas. Zavedati pa se

moramo, da je čas nalaganja odvisen od delovanja strojne opreme računalnikov, kot tudi

programske opreme, obremenitve strežnikov in internetne hitrost oziroma trenutnih razmer

v internetu.

7.5.2 Meritve s Firefoxovim omrežnim opazovalcem

Prva meritev je potekala z vsemi parametri enakimi true, torej za HTTP 2.0. Rezultat

prikazuje slika 7.35.


47

Slika 7.35: Rezultat za napolnjen in prazen predpomnilnik 1.

Druga meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.http2

(HTTP 1.1). Rezultat je na sliki 7.36.


Tretja meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.http2draft.

Rezultat za protokol HTTP 2.0 draft 15 prikazuje slika 7.37.


Četrta meritev je potekala pod vklopljeno možnostjo network.http.spdy.enabled.v3-1, torej

za SPDY 3.1. Rezultat prikazuje slika 7.38.


48


Peta meritev je potekala z vsemi parametri enakimi false, torej za HTTP 1.1. Rezultat

prikazuje slika 7.39.


Velikost naloženih podatkov je tako rekoč enaka pri vseh protokolih, saj smo vedno nalagali

isto stran. Pri merjenju časa smo dobili dva zmagovalca. Pri polnem predpomnilniku je

najhitreje pridobil podatke SDPY 3.1. SPDY 3.1 je bil morda hitrejši od HTTP 2.0 zato, ker

ne uporablja dopolnjevanja. Pri praznem predpomnilniku pa je bil najboljši HTTP 2.0.

Število predpomnjenih odgovorov in zahtev pa je bilo tako kot pri napolnjenem

predpomnilniku kot pri praznem enako pri vseh protokolih.


49

7.6 Analiza z Wiresharkom

Opazovanje prenosa Googlove britanske domače spletne strani z Wiresharkom. Najprej smo

v brskalnikovo vrstico za spletno stran vpisali about:config in nato poiskali parameter

»security.tls.version.max«. Nastavili smo ga na 0. To naj bi pomenilo uporabilo protokola

SSL 3.0 in onemogočilo uporabo protokola TLS. Privzeta vrednost je 3, kar pomeni, da je

omogočen TLS 1.2, ki zagotavlja večjo varnost. Le z vrednostjo 0 smo nato v Wiresharku

lahko videli kodirana sporočila. Pred tem smo morali v operacijskem sistemu Windows

narediti posebno datoteko. Datoteka je bila narejena za shranjevanje vrednosti sejnega

ključa SSL/TLS v tekstovni obliki. Do okna za pripravo smo prišli po naslednji poti: Control

Panel\System and Security\System in nato Advanced system settings. Potem se je odprlo

posebno okno System Properties. Tam smo stisnili gumb Environment Variables in potem

pod User Variables stisnili New in poimenovali novo datoteko ter nastavili pot do nje [7].

7.6.1 Opazovanje pri protokolu HTTP 1.1

Opazovali smo pakete, poslane med odjemalcem in strežnikom. Nastavitev je vsebovala

vrednosti false pri vseh treh možnostih v rdečem okvirju na sliki 7.9..

V programu Wireshark smo v vrstico, v katero se vpiše filter, napisali SSL in nato poiskali

začetek pretoka. Pod informacijskim oknom je moralo pisati Decrypted SSL data. Nato smo

izbrali še Follow SSL stream. Takrat se je prikazalo novo okno (slika 7.40), v katerem smo

lahko razločno prebrali glave sporočil HTTP 1.1.

Slika 7.40: Prikaz glav sporočil HTTP 1.1.


50

Zaključevanje povezav na spodnji sliki nakazuje hkraten obstoj več povezav do različnih

strežnikov:

Obstoj hkratnih povezav do istega strežnika se lahko vidi iz številk vrat povezav (prva je

49867, druga je 49868 in tretja 49870), saj puščice od leve proti desni kažejo do iste črte:

7.6.2 Opazovanje pri protokolu SPDY 3.1

Opazovali smo poslane pakete med odjemalcem in strežnikom. Nastavitev je vsebovala

vrednost true pri network.http.spdy.enabled.v3-1.

Na sliki 7.41 je prikazan eden od okvirjev SYN_STREAM. Za prenos zahteve GET HTTP

1.1 pričenja tok številka 3 s prioriteto 3. Razločno se lahko vidijo uporabljene glave

(:method, :path ...). Ker zahteva ne vsebuje telesa, je nastavljena zastavica FIN.

Primer zaporedja okvirjev enega celotnega toka SPDY je na sliki 7.42. Vidimo, da se je po

pripravi seje pričel tok z okvirjema SYN_STREAM in WINDOW_UPDATE. Sledi okvir

SYN_REPLY, ki skupaj s petimi okvirji DATA nosi odgovor na zahtevo, poslano v tem

toku. Za temi je odjemalec z okvirjem PING izmeril krožno zakasnitev. Nato se pričneta

nova toka.


51

Slika 7.41: Prikaz okvirja SYN_STREAM

Tu je primer okvirja SETTINGS, ki se uporablja za pripravo povezave (seje) in pove

začetno dolžino okna ter število dovoljenih tokov v povezavi:

Slika 7.42: Del zaporedja okvirjev SPDY.


52

Tu je primer pričetka dveh različnih tokov, ki tečeta po isti povezavi do strežnika:

Sledi prikaz začetka in zaključevanja seje pri protokolu SPDY 3.1:

Prikazan je začetek in konec seje pod številko vrat 49918 pri odjemalcu. Vidi se tudi druga

seja (po povezavi TCP s številko vrat 49908).

7.6.3 Opazovanje pri protokolih HTTP/2 draft 15 ter HTTP 2.0

Opazovanje smo opravili vsako posebej, vendar sta obe prikazali neberljive glave. Prikaz

neberljivih glav je na sliki 7.43. Ker Wireshark še nima dobre podpore za dekodiranje

protokolov HTTP 2.0 in HTTP/2 draft 15, nismo mogli opazovati vsebine sporočil teh

protokolov.


53

Slika 7.43: Prikaz neberljivih glav.


54

8 SKLEP

Svetovni splet je informacijski sistem digitalnih dokumentov, ki se je začel v zgodnjih 90.

letih. Do danes je v njem prevladoval protokol HTTP 1.1, vendar počasi prepušča vlogo

nasledniku.

S prvo implementacijo protokola HTTP 1.1 se je svet spleta začel vrteti hitreje. Povezava,

na kateri deluje protokol HTTP 1.1, je povezava TCP. Zaradi hitrega zasičenja povezave so

se pojavile nove tehnologije. Med njimi je cevljenje zahtev in odgovorov. Za izboljšavo

delovanja imamo tudi predpomnjenje, ki deluje tako, da se že obiskane spletne strani hranijo

na računalniku in ne potrebujejo ponovne vzpostavitve povezave.

SPDY je prvi večji poskus posodobitve HTTP 1.1, saj optimalizira delovanje tega protokola.

Zmanjšanje časa nalaganja strani in količine odvečnih podatkov v glavah sporočil sta

privedla do hitrega sprejetja pri uporabnikih. Z implementacijo SPDY-ja v same strežnike

so se izboljšali časi prenosa spletnih strani. Tudi SDPY teče na povezavnem protokolu TCP

in pušča povezavo odprto čim več časa, za razliko od protokola HTTP 1.1 pa ne uporablja

več sočasnih povezav do istega strežnika, ampak multipleksira zahteve in odgovore po eni

povezavi. V SPDY-ju so v ta namen uvedeni okvirji, v katerih se prenašajo zahteve in

odgovori. Zaporedje okvirjev, ki nosi eno zahtevo in odgovor nanjo, se imenuje tok. Tokovi

lahko imajo različne prioritete.

SPDY uporablja izboljšano cevljenje in tako pridobi na času. S stiskanjem zmanjša količino

podatkov glav zahtev in odgovorov, vsebinsko pa so ostale skoraj enake kot glave HTTP

1.1. Novejša tehnologija, ki je prišla s SPDY-jem, je potisk s strežnika, ki omogoča strežniku

začetek prenosa videov, ne da bi čakali na zahtevo. Po tehnologijah, ki so jih uvedli v SPDY-

ju, so se kasneje zgledovali pri snovanju protokola HTTP 2.0. Snovali so ga celo nekateri

isti ljudje kot SPDY.


55

Protokol HTTP 2.0 je obdržal semantiko HTTP 1.1 tako kot SPDY. Uporablja varnejšo

metodo stiskanja glav kot SPDY. Protokol še ni uveden v vseh strežnikih, vendar se počasi

delež le-teh veča.

Tudi v spletnih brskalnikih so počasi začeli uvajati protokola SPDY in HTTP 2.0. V

brskalniku Chrome je HTTP 2.0 že privzet, in Google namerava uvesti popolno podporo

zanj v vse prihodnje generacije brskalnika Chrome (tudi Chrome Canary in Chrome for iOS).

V brskalniku Firefox je podpora za HTTP 2.0 od različice 34. Internet Exporer 11 podpira

HTTP 2.0, vendar le v operacijskem sistemu Windows 10. Microsoftov naslednik Internet

Explorerja je Edge, ki podpira HTTP 2.0 kot privzetega. Povsod deluje HTTP 2.0 preko

povezave TLS, razen v Chrome Canary in Chrome za iOS. Opera in Safari 9 omogočata

povezovanje preko HTTP 2.0. Podatki iz avgusta 2015 kažejo, da ta protokol uporablja 1,2

% vseh spletnih mest [13]. Protokol SPDY uporablja 6,1 % vseh spletnih mest

(http://w3techs.com/technologies/details/ce-spdy/all/all). Vendar se protokol SPDY počasi

umika in prepušča mesto protokolu HTTP 2.0. Google bo opustil SPDY. Podpora zanj v

brskalnikih Chrome bo le še do leta 2016 [23]. Trenutni strežniki, ki podpirajo HTTP 2.0,

so: Akamai Edge Servers, Apache 2.4.12, CDN77 – Content Delivery Network, Jetty 9.3,

LiteSpeed Web Server 5.0, Microsoft IIS, nginx, OpenLiteSpeed (1.3.11, 1.4.8) in Wildfly

9 [13].

http://w3techs.com/technologies/details/ce-spdy/all/all


56

VIRI IN LITERATURA

[1] Blog HttpWatch, A Simple Performance Comparison of HTTPS, SPDY And HTTP 2.0,

16. 1. 2015. Dostopno na: https://blog.httpwatch.com/2015/01/16/a-simple-

performance-comparison-of-HTTPs-SPDY-and-HTTP2/ [9. 8. 2015].

[2] Elkhatib, Y., Tyson, G., Welzl, M. Can SPDY Really Make the Web Faster? V:

Networking Conference, 2014 IFIP. International Conference on Networking,

Trondheim, 2.−4. junij 2014.

[3] Forouzan, B. A. Data Communications and Networking, 4th Edition. New York:

McGraw-Hill, 2007.

[4] Google. SPDY – The Chromium Projects, 2010. Dostopno na:

https://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1 [17.8.2015].

[5] Grigorik, I. Making the Web Faster with HTTP 2.0. Communications of the ACM, 56,

(2013), 12, str. 42−49.

[6] HTTPbis Working Group, Hypertext Transfer Protocol version 2 (HTTP/2), 2015.

Dostopno na: http://http2.github.io/http2-spec/index.html#Overview [26.2.2015].

[7] Shaver, J. Decrypting TLS Browser Traffic With Wireshark – The Easy Way! 2015.

Dostopno na: https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-

wireshark-the-easy-way/ [13.8.2015].

[8] Dorfman J., The Shitft from SDPY to HTTP/2 and What It Means for You, 2015.

Dostopno na: https://www.maxcdn.com/blog/SPDY-HTTP2-shift [13.8.2015].

[9] Kurose, J. F., Ross, K. W. Computer Networking − A Top-Down Approach, 6th Edition.

New Jersey: 2013. Pearson Education, Inc.

[10] Tanenbaum, A. S., Wetherall, D. J. Computer Networks, 5th Edition. Prentice Hall,

2011.

https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/

https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/

https://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1

http://http2.github.io/http2-spec/index.html#Overview

https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/

https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/

https://www.maxcdn.com/blog/spdy-http2-shift%20%5b13


57

[11] Thomas, B., Jurdak, R., Atkinson, I. Improved performance and a proven deployment

strategy make SPDY a potential successor to HTTP. Communications of the ACM, 55,

(2012), 12, str. 64−73.

[12] Wikipedia, History of the World Wide Web, 2015. Dostopno na:

https://en.wikipedia.org/wiki/History_of_the_World_Wide_Web [6. 8. 2015].

[13] Wikipedia, HTTP/2, 2015. Dostopno na: https://en.wikipedia.org/wiki/HTTP/2

[6. 8.2015].

[14] Wikipedia, World Wide Web, 2015. Dostopno na:

https://en.wikipedia.org/wiki/World_Wide_Web [6. 8. 2015].

[15] Wikipedia, Firefox, 2015. Dostopno na: https://en.wikipedia.org/wiki/Firefox [6. 8.

2015].

[16] Wikipedia, Wireshark, 2015. Dostopno na: https://en.wikipedia.org/wiki/Wireshark

[6. 8. 2015].

[17] Simtec Limited, HttpWatch, 2015. Dostopno na: www.httpwatch.com [1. 9. 2015].

[18] Undertow, An in depth overview of HTTP/2, 2015. Dostopno na:

undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html [1. 9. 2015].

[19] RFC 7540, Hypertext Transfer Protocol Version 2 (HTTP/2). IETF, 2015. Dostopno

na: https://tools.ietf.org/html/rfc7540#section-4.3. [1. 9. 2015]

[20] McLachlan, P. Why Domain Sharding is Bad News for Mobile Performance and

Users, 30.oktober 2012. Dostopno na: www.mobify.com/blog/domain-sharding-bad-

news-mobile-performance/ [2. 9. 2015].

[21] Stenberg, D. http2 explained,. Dostopno na: http://daniel.haxx.se/http2/http2-

v1.12.pdf. [27. 8. 2015].

https://en.wikipedia.org/wiki/History_of_the_World_Wide_Web%20%5b6

https://en.wikipedia.org/wiki/HTTP/2

https://en.wikipedia.org/wiki/World_Wide_Web

https://en.wikipedia.org/wiki/Firefox

https://en.wikipedia.org/wiki/Wireshark

http://www.httpwatch.com/

http://undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html

https://tools.ietf.org/html/rfc7540%23section-4.3

http://www.mobify.com/blog/domain-sharding-bad-news-mobile-performance/

http://www.mobify.com/blog/domain-sharding-bad-news-mobile-performance/

http://daniel.haxx.se/http2/http2-v1.12.pdf

http://daniel.haxx.se/http2/http2-v1.12.pdf


58

[22] IETF, HTTP/2 Frequently Asked Questions, 2015. Dostopno na:

https://http2.github.io/faq/#why-hpack [4. 9. 2015].

[23] Wikipedia, SPDY, 2015. Dostopno na: https://en.wikipedia.org/wiki/SPDY [9.

9. 2015].

https://http2.github.io/faq/#why-hpack

https://en.wikipedia.org/wiki/SPDY


59


60


61

PREGLED PRISTOPOV K POHITRITVI PRENOSA SPLETNIH STRANI · pages. The description of the protocols...

Documents

Transcript of PREGLED PRISTOPOV K POHITRITVI PRENOSA SPLETNIH STRANI · pages. The description of the protocols...