DIPLOMATERVEZSI FELADAT

Molnr Gbor
mrnk informatikus hallgat rszre

Kliens gyorsttr hasznlatra pl

web-gyorstsi megoldsok
Jl ismert tny, hogy a Web-tartalmak letltsi ideje jelentsen megnhet, ha a
hlzati ksleltets nagy. E jelensg megelzsnek egy egyszer mdja, hogy bizonyos
tartalmakat elre letltnk egy a klienshez kzel lev HTTP-proxyba. Mobil hlzatokon
azonban a rdis interfsz mr jelents ksleltetseket okozhat, ezrt olyan mdszerekre lenne
szksg, amelyek kzvetlenl a kliens gyorsttrba tudnak eltlteni.
A jellt feladata:
Tekintse t a webgyorstshoz kapcsold irodalmat, belertve a kapcsold korbbi
egyetemi szakdolgozat tmkat is;
Tegyen javaslatot Web kliens gyorsttrba eltlt megoldsokra; elssorban a kliens
ltal mr mindenkppen lekrni kvnt tartalmak (pldul a mr lekrt html lap
begyazott tartalmai) eltltse a cl, de olyan megoldsok is rdekesek lehetnek,
amelyek j hatkonysggal jsoljk meg a letlteni kvnt tartalmakat;
A vizsglat terjedjen ki olyan megoldsokra is, ahol az eltlt logika meghatrozza,
hogy adott kliens milyen forrst vlasszon az eltltsre. Forrsknt itt szba jhet a
kliens krnyezetben lev msik kliens is, aki mr korbban letlttte az adott
tartalmat, s most tovbb tudja osztani azt, egy peer-to-peer tartalommegoszt
algoritmust hasznlva;
Ksztsen egy prototpust, amellyel vizsglni lehet a javasolt megoldsokat egy
hipotetikus, vltoztathat svszlessg hlzati krnyezetet felttelezve;
Elemezze az eltltsi algoritmus hatkonysgt a prototpus segtsgvel;
A munka minden fzist rszletesen dokumentlja.
Tanszki konzulens: Dr. Vida Rolland, egyetemi docens
Kls konzulens: Dr. Mihly Attila, Ericsson Magyarorszg
Budapest, 2012. 03. 04.
Dr. Henk Tams
tanszkvezet

Budapesti Mszaki s Gazdasgtudomnyi Egyetem

Villamosmrnki s Informatikai Kar
Tvkzlsi s Mdiainformatikai Tanszk

Kliens gyorsttr hasznlatra pl

web-gyorstsi megoldsok
Diplomaterv

Ksztette
Molnr Gbor

Konzulensek
dr. Mihly Attila
dr. Vida Rolland

2013. mjus 26.

Tartalomjegyzk
Tartalomjegyzk

III

Nyilatkozat

VII

Kivonat

IX

Abstract

XI

Bevezet

1. Egy weboldal betltsnek folyamata

1.1. ttekints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2. Beolvassi algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3. Erforrsok letltse . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4. Vgjtk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5. Speculative parsing optimalizci . . . . . . . . . . . . . . . . . . . .

1.6. Fggsgi grfok . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6.1. A fggsgi grf megkonstrulsa . . . . . . . . . . . . . . . . 10

1.7. Esettanulmny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7.1. Jellsek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.7.2. A szkriptek betltse . . . . . . . . . . . . . . . . . . . . . . . 13
1.7.3. A tartalom betltse s statisztikk gyjtse . . . . . . . . . . 14
1.7.4. A hirdetsek megjelentse . . . . . . . . . . . . . . . . . . . . 15
1.7.5. Tovbbi elemzs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2. Ismert optimalizcik

17

2.1. Mrhet mennyisgek . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1. HTTP krsenknti mrszmok . . . . . . . . . . . . . . . . . 17
2.1.2. Globlis mrszmok . . . . . . . . . . . . . . . . . . . . . . . 18
2.2. Mreszkzk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1. A bngsz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2. tcpdump, Wireshark . . . . . . . . . . . . . . . . . . . . . . . 21
III

2.3. Optimalizcik kategorizlsa . . . . . . . . . . . . . . . . . . . . . . 22

2.3.1. Szereplk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.2. Hlzati rtegek . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4. Eltlts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.1. Korai kutatsok . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.2. Megvltozott krnyezet . . . . . . . . . . . . . . . . . . . . . . 27
2.4.3. Ma is hasznlt, illetve szabvnyostott megoldsok . . . . . . . 27
3. Optimalizls eltltssel egy j megkzelts

33

3.1. Eltlts a HTTP proxy-ba . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.1. Elrhet nyeresg . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2. Architektra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.3. Elvrsok egy eltlt implementcival szemben . . . . . . . 37
3.1.4. Biztonsg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.5. Statikus elemzs

. . . . . . . . . . . . . . . . . . . . . . . . . 40

3.1.6. Dinamikus elemzs . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2. Eltlts a kliensbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.1. A kliensbe val eltltssel elrhet nyeresg . . . . . . . . . . 45
3.2.2. Mdostott hidden iframe technika . . . . . . . . . . . . . . . 45
3.2.3. Hlzati forgalom priorizls . . . . . . . . . . . . . . . . . . . 47
4. Prototpus s mrsi eredmnyek

49

4.1. Mreszkzk s reproduklhatsg . . . . . . . . . . . . . . . . . . . 49

4.1.1. measure.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.2. http-box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.3. pseudo.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.4. Idztsi viszonyok . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2. Hlzati krnyezet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1. Traffic Control . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.2. MTU, buffermretek s egyb belltsok . . . . . . . . . . . . 57
4.3. Mrsi konfigurci . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4. Feldolgozs, sszehasonlts . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.1. HTTP alap hlzati forgalom vizualizcija . . . . . . . . . . 59
4.4.2. Egy optimalizci hatsa . . . . . . . . . . . . . . . . . . . . . 62
4.5. Prototpus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5.1. Virtulis bngszk . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5.2. Priorizls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6. Mrsi eredmnyek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
IV

5. sszefoglals

71

Ksznetnyilvnts

73

brk jegyzke

75

Irodalomjegyzk

77

Fggelk
82
F.1. Az origo.hu fggsgi grfjhoz tartoz erforrsok . . . . . . . . . . 82

VI

HALLGATI NYILATKOZAT
Alulrott Molnr Gbor, szigorl hallgat kijelentem, hogy ezt a diplomatervet
meg nem engedett segtsg nlkl, sajt magam ksztettem, csak a megadott forrsokat (szakirodalom, eszkzk stb.) hasznltam fel. Minden olyan rszt, melyet sz
szerint, vagy azonos rtelemben, de tfogalmazva ms forrsbl tvettem, egyrtelmen, a forrs megadsval megjelltem.
Hozzjrulok, hogy a jelen munkm alapadatait (szerz, cm, angol s magyar
nyelv tartalmi kivonat, kszts ve, konzulensek neve) a BME VIK nyilvnosan
hozzfrhet elektronikus formban, a munka teljes szvegt pedig az egyetem bels
hlzatn keresztl (vagy autentiklt felhasznlk szmra) kzztegye. Kijelentem,
hogy a benyjtott munka s annak elektronikus verzija megegyezik. Dkni engedllyel titkostott diplomatervek esetn a dolgozat szvege csak 3 v eltelte utn
vlik hozzfrhetv.

Budapest, 2013. mjus 26.

Molnr Gbor
hallgat

VIII

Kivonat
Az elmlt vekben a web egy fontos platformm vlt. Nem sokkal ezeltt mg csak
egyszer dokumentumok publiklsra hasznltk, manapsg pedig sokak szmra
a tartalomfogyaszts, a kzssgi kommunikci s a vsrls egyik elsdleges helyszne. A tartalommal egytt fejldtek a web mkdst meghatroz szabvnyok s
az azokat implementl bngszk. A bngszprogramokat fejleszt cgek kztt
egszsges verseny alakult ki a hasznlhatsg s a teljestmny tern, ami egyre jobb
felhasznli lmnyhez vezet. Ezt a folyamatot tovbb ersti az internetkapcsolatok
sebessgnek folyamatos nvekedse.
Nem csak a bngszk, hanem az internetszolgltatk s a weboldalak tulajdonosai is sokat javthatnak a weboldalak teljestmnyn. Mindegyik fl specilis szerepet
jtszik egy weboldal letltsnek folyamatban, s olyan informcik birtokban van,
ami a tbbiek szmra nem elrhet, ez pedig klnbz optimalizlsi mdszereket
tesz lehetv.
Az egyik, kzvettk ltal hasznlhat mdszer a tartalmak eltltse a gyorsttrba. Az eltlts trtnhet a kzvetthz, vagy akr kzvetlenl a klienshez
is. A diplomamunkm tmja ilyen tpus optimalizcik vizsglata, valamint j
mdszerek kidolgozsa s implementlsa. Megoldst keresek arra a krdsre, hogy
pontosan mely tartalmakat lehet eltlteni s milyen felttelek mellett, illetve megvizsglom a tartalom klienshez val eljuttatsra hasznlhat mdszerek elnyeit,
htrnyait s teljestmny jellemzit. A kidolgozott technikkat egy prototpus segtsgvel, szimullt hlzati krnyezetben is letesztelem, s a hatkonysgukat a
mrsi eredmnyekkel igazolom.

IX

Abstract
The web became an important platform in the past years. Not long ago, it was
used only for publishing simple documents, and now its the primary platform of
content distribution, social communication and shopping for many. The content, the
standards that define the web and the browsers implementing them were developed
hand in hand. There is a never ending race between browser companies to achieve
better performance and usability, and that leads to a constantly improving overall
user experience. This is amplified by the improving speed of internet connections.
But browsers are not the only player in this game. Web authors, hosting companies
and internet service providers all play special role in improving the performance and
user experience on the web. All of them have a different view of the same process,
and different means to influence and improve it.
One of the methods that intermediaries can use is prefetching web content to a
local cache to make it instantly accessible when it is needed. It is also possible to
push the content from the proxy to the client if needed. The topic of this thesis is the
examination of existing optimizations of this type, and exploration and implementation of new type of optimizations based on it. I will answer the questions concerning
the limitations of content prefetching, and look at the advantages, disadvantages
and performance characteristics of the means of it. The new prefetch methods will
be tested and verified with a prototype implementation using a simulated network.

XI

XII

Bevezet
A dolgozat a kvetkezkppen pl fel. Az els fejezet rviden bemutatja egy weboldal betltsnek folyamatt. Ez a fejezet minden olyan ismeretet tartalmaz, ami
a tbbi fejezet megrtshez szksges. A fejezet egy esettanulmnnyal zrul, amire
a ksbbiekben sok plda alapul.
A msodik fejezet bevezets a webes optimalizcik vilgba. Elszr azt mutatom
meg, hogy melyek azok a mrszmok, amik jl lerjk a felhasznl ltal megtapasztalt betltsi sebessget, s emiatt az optimalizcik fontos clpontjai. Ehhez
kapcsoldan rviden kitrek arra is, hogy ezeket a mennyisgeket hogyan lehet hatkonyan megmrni. Ezutn egy olyan szempontrendszert mutatok be, ami alapjn
a klnbz mdszereket csoportostani, kategorizlni lehet. A fejezet utols, s egyben legfontosabb rsze az eltlts alap optimalizcikrl szl. Ez tartalmazza a
tmval kapcsolatos kutatsok s a gyakorlatban is alkalmazott mdszerek lerst.
A harmadik fejezet az ltalam kidolgozott, eltltsre alapul optimalizcikat
mutatja be. Ez kt f egysgre bonthat. Az els rsz a tartalmak proxy-ba val
eltltsvel, mg a msodik a klienshez val eljuttatsukkal foglalkozik.
A negyedik fejezet a harmadik fejezetben bemutatott mdszerekhez ksztett prototpus implementcit s az azon elvgzett mrseket ismerteti. Itt rszletesen foglalkozom a mrsek reproduklhatsgnak krdsvel, a kifejlesztett mreszkzkkel s a fellltott teszt hlzat konfigurcijval. Ezek az eszkzk nem csak
a mrsek elvgzsben, hanem az egyes optimalizcik fejlesztsi folyamatban is
fontos szerepet kaptak. A fejezet a mrsi eredmnyek bemutatsval zrul.
Az utols fejezet a konklzik levonsrl s a lert mdszerek lehetsges tovbbfejlesztsrl szl.

1. fejezet
Egy weboldal betltsnek folyamata
1.1. ttekints
A bngsz elsdleges feladata HTML (HyperText Markup Language) dokumentumok letltse s megjelentse. A kvetkezkben Tali Garsiel lerst [19] alapul vve
rviden ttekintem, hogy egy modern bngsz hogyan jelent meg egy weboldalt.
A f vezrfonalat az 1.1. bra szemllteti. Ez a webkit bngszmotor megjelentsi
folyamatt brzolja, de a tbbi nylt forrskd bngsz is hasonl elvek alapjn
mkdik. Ezek a bngszk a piac tbb mint ktharmadt fedik le [36].
A weben az egyes erforrsok URL (Uniform Resource Locator) alapjn azonosthatk, gy egy weboldal letltst is egy URL megadsval kezdemnyezheti a
felhasznl. Az URL tartalmazza a kapcsolatfelvtelhez szksges adatokat (a szerver domain nevt vagy IP cmt, a portot s a protokollt) s egy sztringet ami a
tartalmat a szerver szmra egyrtelmen azonostja (tvonal).
Miutn a bngsz a megfelel protokollt hasznlva letlttte a HTML oldalt,
elkezdi beolvasni azt. A beolvass folyamatt nyelvi elemzsnek (parsing) nevezzk,
amit a bngsz nyelvi elemzje (parser) vgez. Egy HTML oldal rengeteg klnfle
mdon hivatkozhat kls erforrsokat, amik a megjelentshez szksgesek. Ezeket
a bngsz a beolvassi folyamat sorn kezdi el letlteni. A leggyakoribb ilyen kls
HTML

Stylesheets

HTML parser

CSS parser

DOM Tree

Layout

Attachment

Render Tree

Style rules

1.1. bra. A Webkit bngszmotor f folyamata

Painting

Display

erforrsok a kpek, a szkriptek s a stluslapok. A HTML szabvny rgzti a beolvassi folyamat pontos menett, amit a kvetkez pontban rszletesebben ismertetek.
A nyelvi elemzs kimenete a document objektum, ami a dokumentum aktulis llapott ler DOM (Document Object Model) fa gykere. A fa egyes cscsai kezdetben
egy-egy HTML tag-nek felelnek meg, ksbb azonban a HTML kdtl fggetlenl
vltozhat a DOM. A cscsok elnevezse: node, element vagy elem.
A megjelents tovbbi lpseit alapveten a DOM fa s a stluslapok hatrozzk
meg. A CSS (Cascading Style Sheet) stluslapok egyszer megjelentsi utastsokat
tartalmaznak (pl. a httr szne legyen kk), amiket a bngsz a hozzjuk tartoz kivlaszt kifejezsek (pl. minden cmsor) alapjn a megfelel DOM node-okhoz
rendel. Az gy ltrejv megjelenthet objektumokat egy msik, erre a clre optimalizlt fban trolja (Render Tree). Ezek a megjelentend objektumok egymsra
is hatssal vannak (pl. ha kt kp egyms alatt van, akkor az els magassga meghatrozza a msodik pozcijt). Az egyes objektumok elrendezst a reflow vagy
layout algoritmus ezen hatsok figyelembe vtelvel szmolja ki. Az utols lps a
vizlis elemek kirajzolsa.
A folyamat egyik legfontosabb jellemzje, hogy az egyes lpsek nem szigoran
sorban kvetik egymst. Jobb modell az, ha az egyes folyamatok kztt csvezetkek
futnak, amiken keresztl folyamatosan rkeznek a bementi adatok, amiket feldolgozva az egyes folyamatok ellltjk a kimenetket. A HTML feldolgozsa pldul mr
akkor elkezddik, amikor mg csak a fjl nhny darabja rkezett meg a hlzatrl.
A megjelents pedig mr jval azeltt elkezddik, hogy minden hivatkozott kls
erforrs letltdne.

1.2. Beolvassi algoritmus

A HTML5 szabvny [4] pontosan definilja a parser ltal kvetend algoritmust
(8.2. rsz: Parsing HTML documents). A folyamat magja mint a legtbb parser
esetben a tokenekre bonts (amit a tokenizer vagy lexer vgez), s a fapts. A
ltrejv ft a HTML esetben DOM-nak nevezzk. A szabvny parser modelljnek
klnlegessge, hogy lehetv teszi a szkriptek futtatst.
A web szkript nyelve a JavaScript. A nyelv futsi modellje egyszl s esemnyvezrelt. Ez a futsi modell klnsen jl illeszkedik aszinkron mveletek (pl. hlzati
lekrdezsek) kezelshez s felhasznli felletek programozshoz.
Kdok beillesztsre tbb lehetsg is van: a forrskd megadhat a HTML-be
gyazva, vagy hivatkozhat kls erforrsknt. A szabvny alapveten nem tesz klnbsget e kt varici kztt: a szkripteket (nhny ksbbiekben bemutatott kivteltl eltekintve) akkor kell lefuttatni, amikor a parser az adott <script> tag-et elri.
4

A lefut szkriptnek hozzfrse van az adott ponton mr felptett DOM rszlethez, valamint kpes a dokumentumba HTML kdot injektlni a document.write()
fggvny segtsgvel. Utbbi esetben a parsert reentrns mdon kell meghvni, hogy
feldolgozza az jonnan beszrt HTML rszletet.
Ez egy egyszer s kiszmthat modell, viszont egy naiv bngsz impleNetwork
mentci esetn nagyon lass oldalbetltshez vezet. Amikor a parser egy
kls fjlknt hivatkozott szkriptet taByte Stream
ll, akkor megll, letlti a fjlt, majd
Decoder
lefuttatja s tovbblp. Tbb egyms
utn hivatkozott szkript esetn ez egy
Input Stream
letlts-futtats-letlts-futtats ciklusPreprocessor document.write()
hoz vezet, ami egy vals (nem 0 ksleltets) hlzaton nagyon lass.
Erre kt megolds is szletett. Az
Tokenizer
egyik a bngszk ltal hasznlt speculative parsing optimalizci, amirl az
1.5. pontban lesz rszletesebben sz. A
Tree
Script
msik az aszinkron szkriptek hasznlaConstruction
Execution
ta. Egy <script> tag aszinkronknt jellhet meg az async attribtum hasznlatval. Egy ilyen szkript nem blokDOM
kolja a parsert, s kzvetlenl azutn fut
le, hogy befejezdtt a letltse.
1.2. bra. A HTML5 parser modelje [4]
A szkriptek futtatsn tl a parser
kezdemnyezi az egyes kls erforrsok
letltst is. Kls erforrs lehet pldul kp, begyazott HTML oldal (iframe),
vagy CSS stluslap. Ezek nem blokkoljk a folyamatot: ltrehoznak egy-egy letltsi
feladatot, amit tadnak a hlzati rtegnek. Egy esetben azonban mgis blokkolhat
egy stluslap betltse: mivel egy szkript lekrdezhet a mr beolvasott DOM-bl
olyan adatokat is, amik egy stluslaptl fggnek (pl. egy adott elem szne), ezrt a
kdfuttatst a <script> tag-et megelz stluslapok betltsnek meg kell elznie.
Amikor a parser elrte a dokumentum vgt, ltrehozza a DOMContentLoaded
esemnyt a document objetkumon. Kzvetlenl ez utn lefutnak a szkriptek ltal
ehhez az esemnyhez regisztrlt esemnykezel fggvnyek.

1.3. Erforrsok letltse

A bngsz hlzati rtegnek feladata, hogy a megadott URL-ekhez tartoz erforrsokat a megfelel protokoll hasznlatval letltse. A web legelterjedtebb tviteli
protokollja a HTTP [15] (HyperText Tranfer Protocol). Tovbb hasznlatos mg a
HTTPS [32] (HTTP Secure), ami biztonsgos tviteteli rteg fltt mkdik, s a
SPDY [3] (speedy), ami a titkosts mellett sok ms szolgltatst is nyjt.
A HTTP mindkt elterjedtebb alternatvja megtartotta a HTTP szemantikjt,
ezrt rdemes nhny mondatban ttekinteni a HTTP protokoll mkdst. Alapveten egy olyan krs-vlasz alap szveges protokollrl van sz, ami egy folyam-alap
tviteli rteget (legegyszerbb esetben TCP) felttelez.
A krs minden esetben a kvetkez rszekbl ll:

protokoll verzi megjellse

metdus: a krs tpust azonost sztring (pl. lekrs, feltlts)
tvonal, vagy a teljes URL
fejlcek: egy kulcs-rtk prokbl ll lista
test: opcionlis, tetszleges formtum adat (pl. fjl feltltse esetn)

A szabvny tbb fejlc nvhez meghatrozott jelentst trst, ezek hasznlata a

Host fejlc kivtel mind opcionlis. A Host fejlc adja meg azt a domain nevet,
amelyet feloldva a kliens a szerver IP cmt megkapja. Erre azrt van szksg, mert
egy adott IP cm s port prossal meghatrozott szerver tbb klnbz weboldalt
is hosztolhat. Ebben az esetben tbb domain nv is tartozik a szerver IP cmhez,
s a Host fejlc alapjn hatrozhat meg, hogy a kliens melyik weboldalra kvncsi.
A vlasz tartalma:

protokoll verzi megjellse

sttuszkd, ami azonostja a vlasz tpust (siker, hiba, tirnyts, stb.)
fejlcek
test: opcionlis, tetszleges formtum adat (pl. a vlaszknt visszakldtt
fjl)

Egy tipikus HTTP krsben az tvonal-azonost egy fjlnevet ad meg, a szerver

pedig vlaszknt ezt a fjlt kldi vissza. Erre egy plda az 1.1. tblzatban lthat. Ez termszetesen csak a lehetsgek kis rsze, az URL azonosthat brmit (pl.
adatbzis bejegyzseket), a vlasz pedig lehet akr dinamikusan generlt is.
A szabvny 1.0 verzija minden krs-vlasz prhoz megkvetelte egy kln TCP
kapcsolat felptst, majd lebontst. Ez a kapcsolat felptsnek lasssga miatt
(3 lpses kzfogs) alacsony teljestmnyhez vezetett, ezrt az 1.1 verzi mr lehetv teszi a TCP kapcsolatok jrahasznostst, teht egy vlasz megrkezse utn
6

GET /index.html HTTP/1.1

Host: www.example.com
User-Agent: curl/7.24.0
Accept: */*

HTTP/1.1 200 OK
Date: Mon, 23 May 2012 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: none
Content-Length: 12
Connection: close
Content-Type: text/plain
Hello World!

1.1. tblzat. HTTP krs s vlasz plda

a kapcsolat nyitva hagyhat s jabb krs kldhet rajta. A szabvny meghatrozza azt is, hogy egy kliens legfeljebb 2 perzisztens TCP kapcsolatot hasznlhat
egy adott szerver elrsre a tlterhels elkerlse miatt, a gyakorlatban a modern
bngszk ltalban 6 TCP kapcsolatot tartanak fent szerverenknt. A bngsz
hlzati rtegnek feladatai kz tartozik a krsek hozzrendelse az egyes TCP
kapcsolatokhoz.

1.4. Vgjtk
Amikor a parser befejezte a mkdst, mg valsznleg vannak olyan erforrsok,
amik nem tltdtek le teljesen. Ezeket a bngsz feladat objektumokkal reprezentlja s feladatsorokban trolja. Az oldal betltse akkor nyilvnthat befejezettnek,
ha nincs tbb olyan feladat fggben vagy folyamatban, ami ezt megakadlyozn.
A szabvny rszletesen felsorolja azokat a feladattpusokat, amik ebbe a kategriba esnek. Ide tartozik gyakorlatilag minden hlzatot rint feladat, valamint a
vlaszok feldolgozsa s megjelentse is. Nem tartoznak ebbe a kategriba pldul
az idztk ltal ltrehozott feladatok, amik a megfelel idpontban egy esemnyt
fognak generlni.
Amikor az sszes ilyen betltst blokkol feladat elfogyott, a bngsz ltrehozza
a load esemnyt a dokumentum window objektumn, s rtesti a felhasznlt, hogy
a weboldal betltdtt. A felhasznl rtestse ltalban a betlts folyamatt jelz
homokra kurzor, illetve folyamatjelz sv elrejtst jelenti.

1.5. Speculative parsing optimalizci

A modern bngszk tbb olyan ltalnosan elterjedt mdszert is hasznlnak, ami
meggyorstja a weboldalak betltst. Az egyik legfontosabb, hogy a HTML beolvassi folyamat elindtsa eltt lefuttatnak egy msik parsert is, ami feltrkpezi a
7

dokumentumban tallhat kls hivatkozsokat. Ezt a lps a speculative parsing,

s a clja, hogy az olyan szkripteket, amik nagy valsznsggel kelleni fognak, minl
hamarabb el lehessen kezdeni letlteni.
A speculative parsing hatst a kvetkez egyszer HTML pldn szemlltetem:
<!DOCTYPE html>
<html lang="hu">
<head>
<script src="2.js"></script>
<script src="3.js"></script>
<script src="4.js"></script>
</head>
<body></body>
</html>
1.3. bra. Plda weboldal: 1.html

Mivel a szkriptek hasznlhatjk a document.write fggvnyt, a bngsz nem

lehet biztos benne, hogy a HTML ltal hivatkozott minden JavaScript tnylegesen kelleni fog. Elkpzelhet pldul, hogy az els hivatkozott szkript (2.js) a
document.write-ot hasznlva egy HTML megjegyzs jelet (<!--) r ki. Ebben
az esetben a dokumentum htralev rsze a megjegyzs rszv vlik, ezrt nem kell
letlteni s lefuttatni a tbbi szkriptet. A gyakorlatban viszont nagyon ritka, hogy
hasonl trtnik, s ha ilyen mgis elfordul, az nyugodtan tekinthet programozsi
hibnak a weboldal fejleszti rszrl. Ha a speculative parsing ltal adott jslat
tves, az felesleges HTTP letltsekhez vezet, de nem jr rosszabb kvetkezmnnyekkel.
A weboldal letltse a speculative parsing nlkl egy teljesen sorostott folyamat lenne, ami a hlzati erforrsoknak csak egy csekly rszt tudn kihasznlni.
Az 1.4. bra szemllteti a weboldal betltsnek folyamatt az optimalizci nlkl
s speculative parsing optimalizcival. A krk az egyes erforrsok letltst, a
ngyzetek a szkriptek futtatst, a hatszgek a HTML beolvass egyes szakaszait, a
kzttk lev lek pedig a sorrendezsi knyszereket jellik. Lthat, hogy a speculative parsing esetn a szkriptek letltst a bngsz prhuzamostja. A futtatsukat
tovbbra is a szabvny ltal meghatrozott mdon, a hivatkozs sorrendjben vgzi
el.
Jelljk az x. erforrs letltsi idejt dx -el, a weboldal betltsi idejt D-vel. A
futtatsi idket elhanyagolva s a dx valsznsgi vltozkat fggetlennek tekintve
a weboldal betltsi ideje az optimalizci hasznlata nlkl, illetve hasznlatval:
8

1.4. bra. A weboldal betltse speculative parsing optimalizci hasznlata nlkl (fell), illetve hasznlatval (alul)

Dstandard = d1 + d2 + d3 + d4 > d1 + max(d2 , d3 , d4 ) = Dspeculative

(1.1)

1.6. Fggsgi grfok

Az elz pontban szemlltetsknt hasznlt grftpussal nevezzk fggsgi grfnak jl lerhat az, hogy hogyan zajlik egy weboldal betltsnek folyamata. gy
talltam, hogy ez a grf nem csak betlts folyamatnak karakterizlsa miatt fontos, hanem jellemzi a betlts gyorsasgt is rdemben meghatrozzk (az adott
weboldal ltal betlttt tartalmak mrete s termszetesen a hlzati viszonyok mellett).
Egy lehetsges definci a kvetkez: nevezzk fggsgi grfnak azt a grfot,
aminek a cscsai a weboldal megjelentsvel kapcsolatos elvgzend mveleteket
reprezentljk, a kztk lev irnytott lek pedig azt mutatjk meg, hogy a kt
vgponthoz tartoz mveletek kzl melyiket kell felttlenl a msik eltt elvgezni.
Tipikus feladatok pldul:

egy erforrs letltse

egy szkript futtatsa
a HTML egy rszletnek feldolgozsa
egy stluslap feldolgozsa

Fggsgi viszony van pldul egy szkript letltse s futtatsa kztt, vagy kt
szkript futtatsa kztt, ha azokat a HTML egyms utn hivatkozza (mert a feldolgozs sorban trtnik). Egy mvelet elvgzse fgghet egyszerre tbb msik mvelettl is: pldul ha egy szvegdoboznak (pl. <div> elem) egy stluslap meghatroz
9

egy httrkpet, akkor a kp betltse csak akkor kezddhet el, ha a stluslap betltdtt, befejezdtt a beolvassa s a HTML parser is eljutott az adott elemhez.
Elkpzelhet olyan fggsgi viszony is, amikor egy mvelet elvgzshez csak az
szksges, hogy a fggsgei kzl legalbb az egyik teljesljn. Pldul ha egy kpet kt klnbz szkript is betlt, s a kp gyorsttrazhat, akkor a kp letltse
akkor fog megtrtnni, amikor a kt szkript kzl az egyik lefut. Az ilyen fggsgeket a fggsgi grfokon szaggatott vonallal jellm.
Egy specilis fggsgi tpus az, amikor egy szkript expliciten utastja a bngszt egy erforrs letltsre (pl. ltrehoz egy kpet egy adott URL-lel, vagy HTTP
lekrdezst indt egy API [Application Programming Interface] fel). Ezt a lekrdezst mindenkpp el kell vgezni ahhoz, hogy az oldal betltdjn, de ahhoz, hogy
elkezddhessen, elszr le kell futnia az adott szkriptnek. Szintn egy specilis fggsgi viszony, ha egy HTTP vlaszban a bngsz egy 302-es vagy 301-es kdszm
vlaszt kap, ami tirnytst jelent, teht a keresett erforrs egy msik URL-en
tallhat meg. Ilyenkor ahhoz, hogy a msik URL-t a bngsz megkapja s elkezdhesse a msodik lekrdezst el kell vgeznie elszr az els lekrdezst, teht ez is
egyfajta fggsgi viszony. A fggsgi grfokon azoknl az leknl, ahol nem egyrtelm (a HTML parsing algoritmusbl nem kikvetkeztethet) a fggsg mibenlte,
mindenhol feltntetek egy rvid JavaScript kdrszletet vagy HTTP sttuszkdot.
Fontos megjegyezni, hogy egy szkript futtatsa a fggsgi grfban azt jelenti,
hogy az adott helyen lefut a szkript egy rsze. Ez nem jelenti azt, hogy ugyanaz,
vagy egy ugyanabban a fjlban tallhat msik kdrszlet ne futhatna le egy msik helyen (pldul egy esemny bekvetkezsnel hatsra). Ilyen tulajdonsg a
HTML beolvassa is, teht a grfban tbb helyen is megjelenhet ugyanazon HTML
beolvassa. Ilyenkor klnbz rszek beolvassrl van sz, s az egyes beolvassi
lpsek kztti fggsgek a HTML kd egyes rszeinek sorrendisgt tkrzi (teht
pl. ahhoz hogy a kd msodik felt be lehessen olvasni, elszr az els felt kell).

1.6.1. A fggsgi grf megkonstrulsa

Nem trivilis feladat egy weboldal fggsgi grfjnak feldertse. Szksg van ugyanis arra, hogy minden trtns naplzhat legyen, s hogy a naplbl kiderljn az
esemnyek kztti ok-okozati kapcsolat.
Ehhez segtsget nyjt a Google Chrome bngsz Timeline funkcija, ami lehetv teszi az sszes esemny, szkript futtats s hlzati forgalom monitorozst, s
rszlegesen kinyerhetk belle az ok-okozati viszonyok is. Ennek egyik nagy hinyossga, hogy az esemnyeknl nem lthat az esemny forrsa, pl. egy load esemnynl
nem egyrtelm, hogy az az egyik iframe-ben lev HTML dokumentum load esemnye, vagy csak egy szkript tag betltse fejezdtt be. A Timeline funkcirl
10

rszletesebben a 2.2.1. pontban rok.

Emellett elengedhetetlen a szkriptek forrskdjnak tanulmnyozsa, amit nehezt, hogy ezek tbbnyire csak minimalizlt formban rhetek el. Mivel a JavaScript egy interpretlt nyelv, s nem szabvnyostottak hozz binris formtumot,
a szkriptek csak forrskd formjban terjeszthetk. A forrskd mrete viszont jelentsen cskkenthet a vltozk tnevezsvel, a formzshoz hasznlt whitespace
karakterek eltvoltsval s ms transzformcikkal: ezt a folyamatot szoks minimalizlsnak nevezni. Hasznlata teljesen bevett gyakorlatnak szmt. Egy ilyen
forrskd a megfelel eszkzkkel olvashatbb formra hozhat, de a vltozk tnevezse miatti informciveszts megnehezti az rtelmezst.

1.7. Esettanulmny
Ebben az alfejezetben egy nagy ltogatottsg magyar webportl pldjn mutatom be, hogyan zajlik egy weboldal letltse. A vlasztsom az origo.hu-ra esett,
mert a cmoldala rengeteg tartalommal van megtltve, tbb begyazott hirdetst
is megjelent, s bonyolultsgban jl reprezentlja a tbbi magyar hroldalt. Azrt
nem egy klfldi, mg nagyobb forgalm oldalt vlasztottam, mert ezek rendkvl
jl optimalizltak, gy nem reprezentljk elg hen a felhasznlk ltal megltogatott weboldalak tbbsgt. A ksbbiekben az origo.hu pldjt hasznlom a mrsi
mdszerek s az optimalizcik bemutatsra is.
Az origo.hu 2012. oktber 15-ei cmoldalnak fggsgi grfja a 1.5. brn lthat.
Az egyes erforrsok URL-je helyett mindenhol egy sorszm szerepel az tlthatsg
kedvrt. Az F.1. fggelkben megtallhat az egyes sorszmokhoz tartoz URL-ek
listja. Szintn a jobb tlthatsg miatt hasznltam nhny specilis jellst, ezeket
a kvetkezkben rviden megmagyarzom. Ezutn ismertetem a betlts folyamatt
a fggsgi grf alapjn.

11

12
1.5. bra. Az origo.hu fggsgi grfja

1.7.1. Jellsek
Sok prhuzamosan vgezhet, egymshoz hasonl lekrdezst sszevontam nagyobb
egysgekbe. Ilyen pldul 16., 17., 18., 23., 26. s 27. letlts: ez esetben egyms
melletti <img> tag-ekben hivatkozott kpekrl van sz. Mivel ezeknl a kivlt ok
azonos (a HTML parser az adott helyre rt), s egymstl nem fggnek, ezrt az
sszevons nem jrt informcivesztssel.
A 9. stluslap feldolgozst s a 10. szkript letltst tbbszr is szerepeltettem
az brn annak ellenre, hogy ezek nem rszekre bontott mveletek (az index.html
beolvassval ellenttben, ami tbb rszletben trtnik). Ennek oka az volt, hogy
csak gy lehetett a legjobb elrendezst biztostani.
A DOMContentLoaded esemny bekvetkezse utn a 11. szkript t iframe-et hoz
ltre klnbz URL-ekkel. Ezek kzl ngy ugyanarra a HTML sablonra pl, s
csak a fjlok utols rsze tr el. Van teht a feldolgozsban egy kzs rsz, amin
mindegyik iframe keresztl megy: ezt szaggatott vonallal bekeretezve jelltem. Ez
azt is jelenti, hogy a kzs rszben hivatkozott szkriptek akkor kezdenek el letltdni, amikor a ngy iframe kzl a leggyorsabb elr ide. Amikor a tbbi is eljut ebbe
a szakaszba, nem indulnak j letltsek, hanem megvrjk a folyamatban lev letltsek eredmnyt, s mivel ezek az erforrsok gyorsttrazhatak, ezrt a letlttt
szkripteket fogja futtatni a tbbi iframe is.

1.7.2. A szkriptek betltse

A kiindulpont az origo.hu domain (0. lekrdezs). Innen csak egy tirnytst kap
vissza a bngsz, ami a f webszerver nyitoldalra mutat, ez a www.origo.hu/
index.html (1. lekrdezs).
Az els nhny megrkez vlaszcsomag utn elindul a speculative parsing, s
elkezdi letlteni a begyazott szkriptek kzl azokat, amik a dokumentum elejn
jelennek meg (2-9. lekrdezs). Miutn az egsz HTML megrkezett a hlzaton, a
bngsz elkezdi letlteni a HTML fjl vgn hivatkozott 10. szkriptet is.
A HTML parser is elindul, viszont a 8. szkriptet hivatkoz <script> tag-nl
megll, s vrja, hogy ez s a 9. stluslap letltdjn. A 11. csak egy tirnyts utn
elrhet, ezrt ez rkezik meg legksbb, s br ekkorra valsznleg a 9. stluslap s
2-8. szkriptek mind letltdtek, csak a 8.-at lehet lefuttatni, a tbbi a 11.-re vr1 .
Miutn a 11. letltse befejezdtt, a parser lefuttatja sorrendben a 11., 6., 5., 4.,
3., s 2. szkriptet, s tovbbhalad a dokumentum beolvassval. A 2. ltrehoz egy
async attribtummal rendelkez <script> tag-et (ez egy Google Analytics analitikai
szkript), aminek a letltse elindul, a futsa pedig rgtn megkezddik majd, mihelyt
1

Ez egy n. head of line blocking tpus problma.

13

letltdtt.

1.7.3. A tartalom betltse s statisztikk gyjtse

A parser a HTML kvetkez rsznek feldolgozsa kzben megtallja a 14. s 15.
kpet s elkezdi letlteni azokat. Ebben a szakaszban rengeteg olyan elemet is tall
a parser, amihez 9. stluslap CSS szablyai kpeket rendelnek, ezek letltst is megkezdi. Egy rvid begyazott szkript lefuttatsa utn (ami a nvnapok kiiratsban
segdkezik) egy jabb hasonl szakasz kvetkezik 6 kppel s 21, CSS szablyok ltal
meghatrozott kppel.
Ebben a szakaszban tallhat egy iframe-be gyazott oldal is, ami ltszlag egy
kpet tlt be (87.), valjban azonban ez 1x1-es mret, s a betlts clja mindssze az, hogy az iframe-ben fut szkript a kp URL-jben kzlhesse a ww392.
smartadserver.com szerverrel a felhasznl monitornak felbontst, hogy az ksbb ehhez igazodva tudjon hirdetseket kldeni. Az ilyen tpus kpeket web bugnak (magyarul web poloska) nevezik [34], s legtbbszr forgalomszmllsra, statisztika gyjtsre hasznljk ket.
Az index.html 835. sorban kezdd begyazott kd a document.write() fggvny segtsgvel ltrehoz egy jabb <script> tag-et, aminek az URL-jt a ltrehozs eltt egy vletlen szmmal egszti ki. A vletlen szm megjelense az URL-ben
azt eredmnyezi, hogy az erforrst biztosan nem gyorsttrazza sem a kliens, sem
pedig a kliens s a szerver kztt ll esetleges HTTP proxy. A parser itt megll, s
megvrja, mg az jonnan ltrejtt 40. szkript betltdik, mivel ez nem egy async
szkript. A fjl tartalma ez: //empty, teht egyetlen JavaScript kommentet tartalmaz. Errl a szkriptrl felttelezhetjk, hogy a szerepe kimerl a forgalomszmllsban, mivel a szerver minden krlmnyek kztt megkapja a HTTP lekrdezst,
mg akkor is, ha az oldal sszes tbbi rsze gyorsttrbl tltdik.
Miutn megrkezett a vlasz, a parser tovbblphet. 3 <img> tag s 19 CSS ltal
meghatrozott kp letltsnek elindtsa utn egy jabb mrkd kvetkezik az
1192.sorban, ami egy 1x1-es kp ltrehozsval az URL-ben kzli az audit.median.
hu-val a monitor felbontst s egy vletlen szmot (ez egy jabb web bug).
Az 1202-edik sorban lev kd csak egy globlis vltozt (pp_gemius_identifier)
llt be, amit a soron kvetkez xgemius.js (10.) hasznl valsznleg egy hirdeti
profil azonostsra. Az xgemius.js egy kpet hoz ltre, amely szintn 1x1 pixel
nagysg, s az URL-ben kzli a kperny felbontst, sznmlysgt s a hirdeti
profil azonostt a hu.hit.gemius.pl oldallal, amely a vlaszban nhny cookie-t is
bellt a ltogat ksbbi azonostsa cljbl. Az index.html utols soraiban egy
begyazott JavaScript mg meghvja a 8. inicializl fggvnyt, de az egyelre nem
generl jabb lekrdezseket.
14

1.7.4. A hirdetsek megjelentse

Itt vget r a HTML beolvassa, gy a parser ltrehozza a DOMContentLoaded esemnyt. Ekkor aktivizldnak az erre az esemnyre feliratkozott szkriptek: a 3. s
az 5. a cmlap megjelentsrt felels, nhny kp URL-jt lltjk be, a hirdetsekrt a 11. felels, ami 1 msodperces ksleltets utn kezdi el mkdst: felveszi a
kapcsolatot az ad.adverticum.net hirdetsi szerverrel.
Az ad.adverticum.net-tel val kommunikcira az n. JSONP (JavaScript Object Notation with Padding) technikt [26] hasznlja, ami a kvetkezkppen mkdik. A kommunikci kezdemnyezje ltrehoz s beszr egy <script> tag-et a
dokumentumba, ami a clszerverhez ktd URL-re hivatkozik. Az URL-ben lehetnek paramterek kdolva. A szerver a vlaszban dinamikusan generlt JavaScript
kdot kld, ami nhny globlis vltozt llt be. Amikor a letlts befejezdik, lefut
a szerver ltal generlt kd, majd a <script> tag-en keletkezik egy load esemny,
aminek hatsra a felad kd esemnykezelje lefut, s kiolvassa a globlis vltozk
rtkt.
A 11. teht JSONP hasznlatval elkldi a kliens sszes relevns adatt a szervernek (88.), a szerver pedig a vlaszban meghatrozza az iframe-ekben, s kpekknt
betltend hirdetsek listjt. A vlasz alapjn ltrehozza az iframe-eket (89-92.),
illetve a kpeket (95-99.) majd jabb JSONP lekrdezst indt (94.), s az jonnan
kapott utols iframe-et is ltrehozza (104.). Mindkt vlasz utn kld visszacsatolst
a ctag.hu-nak egy-egy URL-ben paramterezett rejtett kp formjban (93., 105.).
A 92. iframe valsznleg egy jabb statisztika miatt kell, mert csak egy 1x1es kpet jelent meg. A valdi hirdetsek (a 89-91. s a 104. iframe) ugyanarra a
HTML sablonra plnek. Mindegyik ugyanazt a ngy kzs szkriptet hasznlja, majd
egyedi kdok kvetkeznek, amik a hirdets rdemi rszt jelentik meg. Ezek kzs
jellemzje, hogy ahogy a grfon is ltszik csak egyms utn sorosan betlthet
HTTP krseket hasznlnak, gy jval kitoljk a weboldal load esemnyt.
A hirdetsek betltse utn vgre ksznek nyilvntja a bngsz az oldalt, s
ltrehozza a load esemnyt.

1.7.5. Tovbbi elemzs

A dolgozat tovbbi rszben tbbszr visszatrek az origo.hu pldjhoz, s tovbbi
kvetkeztetseket vonok le a weboldal felptsvel, optimalizcijval kapcsolatban.

15

16

2. fejezet
Ismert optimalizcik
Ebben a fejezetben a jelenleg is hasznlt optimalizcikat mutatom be. A fejezet
elejn azokat a mrhet mennyisgeket, illetve a mrskre hasznlhat eszkzket veszem sorra, amiken lemrhet egy-egy mdszer hatsa. ltalban ezeknek a
mrszmoknak a maximalizlsa illetve minimalizlsa a cl.
Ezutn rviden ttekintem, hogy milyen szempontok szerint lehet kategorizlni a
klnbz technikkat. Ilyen szempont pldul az, hogy a letltsi folyamatban rszt
vev szereplk kzl kik vesznek rszt a vgrehajtsban, vagy az, hogy a mdszer
melyik hlzati rtegekben mkdik.
A fejezet utols rszben a dolgozat f tmjt ad eltltses optimalizcikat
tekintem t. Itt manapsg is ismert s hasznlt technikkrl lesz sz, mg az ltalam
kidolgozott mdszerekkel a kvetkez fejezetben foglalkozom.

2.1. Mrhet mennyisgek

2.1.1. HTTP krsenknti mrszmok
A krseket a HTML parser, a DOM fa s a stluslapok sszekapcsolst vgz
komponens vagy a futtatott szkriptek kezdemnyezik. A krshez tartoz feladat a
bngsz hlzati rteghez kerl. A hlzati rteg feloldja a domain nevet, majd
egy HTTP krst hoz ltre, amit egy meglev vagy egy jonnan ltrehozott TCP
kapcsolathoz rendel. Ha van olyan nyitott TCP kapcsolat a clszerver fel, ami ppen
szabad, akkor ezt hasznlja. Ha nincs, de a nyitott TCP kapcsolatok szma nem ri
el a maximlis rtket (ltalban szerverenknt 6), akkor egy j kapcsolatot nyit.
Ha pedig nem lehet tbb kapcsolatot nyitni s minden meglev foglalt, akkor a
krs vrakozik amg egy kapcsolat fel nem szabadul. Elszr a krs fejlce, majd a
krshez (opcionlisan) csatolt adatok kerlnek ki a hlzatra. Bizonyos id elteltvel
megrkeznek a vlasz HTTP fejlcei, majd a teste is. Amikor a vlasz utols csomagja
is megrkezett, a krst a hlzati rteg lezrja.
17

Ebben a folyamatban 5 fontos esemnyt rdemes kiemelni:

1.
2.
3.
4.

a hlzati rteg megkapja a krs paramtereit

a HTTP krs fejlce (vagy annak els rsze, ha tl nagy) kikerl a hlzatra
a HTTP krs utols csomagja kikerl a hlzatra
megrkezik az els vlaszcsomag a HTTP vlasz fejlccel (vagy annak egy
rszvel)
5. megrkezik az utols vlaszcsomag
Egy krs jellemezhet az 1. esemny idblyegvel s az egyes esemnyek kztt
eltelt idvel. Ha nem fjlfeltltsrl van sz s a HTTP krs fejlce nem tl nagy,
akkor a 2. s 3. esemny egybeesik. Mivel egy weboldal letltse kzben mindkt
krlmny nagyon ritka, a ksbbiekben elhanyagolom ezt az idintervallumot. A
krs fontos jellemzje a kldtt s a fogadott adatmennyisg is.

2.1.2. Globlis mrszmok

A weboldal betltsi idejt az els fejezet alapjn legegyszerbben a load esemnyig
eltelt idvel lehet kifejezni. A load egy jl definilt esemny, amit az sszes bngsz hasonlan implementl. Valjban azonban nem ilyen egyszer a betltsi id
defincija s mrse.
Az els problma az, hogy a load esemnyhez csak egy idblyeget lehet rgzteni. Ahhoz, hogy az addig eltelt id megllapthat legyen, szksg van egy msik
idblyegre, ami az oldalbetlts kezdett jelli. Az oldalbetlts folyamatban az
els olyan pont, amikor JavaScript kd futhat, s rgztheti ezt az idblyeget, az
a HTML feldolgozs kezdete, feltve hogy a kd a HTML legelejn tallhat. A
HTML feldolgozs elindulsig azonban elszr fel kell oldani az URL-hez tartoz
domain-nevet, fel kell pteni a TCP kapcsolatot a szerverig stb. Ez a szakasz becslsek szerint az oldalbetltsi id akr 20%-t is kiteheti [30]. Erre a problmra
egyszer megoldst nyjt a szabvnyosts alatt ll, de a modern bngszk ltal
mr tmogatott Navigation Timing API [38], amin keresztl a JavaScript kdok
lekrdezhetik ezeket az adatokat.
Egy msik, sokkal jelentsebb problma, hogy a load-ig eltelt id nem minden
esetben jl fejezi ki a felhasznli lmny minsgt. Elkpzelhet kt olyan weboldal,
amiknl ez a mrszm megegyezik, de a felhasznl szemszgbl az egyik sokkal
gyorsabban betltdik. Ennek az az oka, hogy felhasznli szempontbl a bngsz
ltal adott explicit visszajelzsnl (folyamatjelz sv jelzi, hogy tltdik az oldal)
fontosabb az, hogy mikor jelenik meg a kpernyn a tartalom. Tovbb bonyoltja a
helyzetet, hogy a tartalom fokozatosan jelenik meg.
A Speed Index [39] egy olyan mrszm, amit ezeket a problmkat figyelembe
18

vve dolgoztak ki: alapja a felhasznl ltal lthat tartalom vltozsa az id elrehaladtval, egszen az oldalbetlts vgig. A Speed Index defincija a kvetkez
egyenlettel rhat le, ahol a c(t) egy [0, 1] rtkkszlet fggvny, ami azt adja meg,
hogy az adott idpontban a lthat tartalom mekkora rsze tltdtt be:
Zend
S=
1 c(t)dt

(2.1)

A Speed Index mrse azonban nem egyszer: pontosan definilni kell az end
esemnyt (amit az animlt kpek, hirdetsek megneheztenek), s kiszmtshoz
szksg van a weboldal betltsrl kszlt videfelvtelre. Valszn, hogy a jvben a teljestmny mrst lehetv tev webes szabvnyok a Speed Index ltal
meghatrozott irnyba fognak tovbblpni, de egyelre minden npszer teljestmny elemz eszkz (WebPagetest1 , Google Analytics Site Speed2 , Torbit Insight3 ,
mPulse4 , HTTP Archive5 ) a load-ig eltelt idt tekinti elsdleges mrszmnak[35].
A Speed Index mrsnek komplexitsa miatt a tovbbiakban elsdleges mrszmknt n is a load-ig eltelt idre fogok hivatkozni.

2.2. Mreszkzk
2.2.1. A bngsz
A leghatkonyabb mreszkz maga a bngsz: a legtbb modern bngsz rendelkezik valamilyen beptett analitikai eszkzzel. A diplomamunka elksztse sorn a
vlasztsom a Chromium bngszre6 esett, mert amellett, hogy grafikus fellet
eszkzket biztost a betltsi folyamat elemzshez (Developer Tools), elrhetv
teszi az sszes adatot egy jl dokumkentlt WebSocket [24] alap interfszen (Remote Debugging Protocol [8]) keresztl is. Valjban maga a Developer Tools is
csak egy webalkalmazs, ami ezt az interfszt hasznlva ri el az adatokat. A szabvnyos interfsz meglte rendkvl jl automatizlhatv teszi a mrsi folyamatot.
A kvetkez nhny bekezdsben a Chromium ltal szolgltatott adatokat tekintem
t, de a legtbb bngsz nagyon hasonl adatsorokat tesz elrhetv a fejleszti
eszkzeiben.
A Chromium Developer Tools az informcikat tbb panelen jelenti meg. Az
optimalizcik szempontjbl a kt legfontosabb panel a Timeline (idvonal) s
1

http://www.webpagetest.org/
https://support.google.com/analytics/answer/1205784
3
https://secure.torbit.com/insight/
4
http://www.soasta.com/products/mpulse/
5
http://httparchive.org/
6
http://www.chromium.org/
2

19

2.1. bra. Chromium Network panel

2.2. bra. Chromium Timeline panel

a Network (hlzat). Mindkt panel esemnysorokat vizualizl, s ugyanezeket az

esemnysorokat le lehet tlteni a Remote Debugging Protocol segtsgvel JSON
(JavaScript Object Notation) formtumban [11].
A Network panel a kvetkez esemnyeket jelenti meg, s teszi elrhetv az RDP
protokollon:

HTTP krs kezdemnyezse

krs megvlaszolsa cache-bl
vlasz fejlc megrkezse
adatcsomag megrkezse
a vlasz utols darabjnak megrkezse
hiba bekvetkezse

A Timeline naplbejegyzsekhez tartoz esemnyek:

HTML parser futtatsa

szkriptfuttats (fggvnyekre lebontva)
DOM esemnyek (DOMContentLoaded, load, stb.)
HTTP krs tadsa a hlzati rtegnek, vlasz fejlc rkezse, adatcsomag
rkezse, vlasz vge
20

 HTTP vlasz feldolgozsnak vge (a vlaszra vr szkriptek, egyb folyamatok lefutsnak vge)
idztk indtsa, trlse, lejrata
JavaScript garbage collector futsa
reflow/layout szmts
kirajzols a kpernyre
Fontos megemlteni, hogy ezekben a naplkban az az idpont szerepel, amikor a
bngsz a hlzati rtegnek tadta a HTTP krst, valamint az, amikor elkrte az
adott vlaszcsomagot, nem pedig az, hogy a hlzatra mikor kerlt ki vagy mikor
rkezett meg egy adatcsomag. A HTTP tirnytsokat is elrejti a hlzati rteg,
ezrt ezek sem szerepelnek a naplkban. A Timeline egyik hinyossga, hogy az
egyes DOM esemnyekhez nem trstja az esemnyt kivlt objektumot. gy nem
lehet klnbsget tenni pldul egy iframe load esemnye s a f dokumentum load
esemnye kztt.
A bngsz beptett fejleszti eszkzei mellett ltezik nhny JavaScript-bl elrhet API is, ami a teljestmny adatok legkrdezst teszik lehetv. Ezek kzl
a mr emltett Navigation Timing API-t rdemes kiemelni. Mivel a Remote Debugging Protocol JavaScript futtatst is lehetv teszi, ezrt a Navigation Timing
adatok is lekrhetk a protokollon keresztl.

2.2.2. tcpdump, Wireshark

Ez a kt eszkz7 a hlzati forgalom felvtelre s elemzsre hasznlhat. Ha a
felvtelt a mrsben rszt vev gpek egyikn futtatjuk, akkor figyelembe kell venni
a felvtellel jr processzorterhelst is, mert befolysolhatja a mrs rdemi rszt
vgz processzeket. A tcpdump gy is konfigurlhat, hogy a megjelentst mellzze
s csak egy fjlba rgztse a felvett hlzati forgalmat, ezrt felvtelkor ezt rdemes
hasznlni.
A Wireshark rengeteg hasznos eszkzt biztost a hlzati forgalom felvtelek elemzshez, pldul:

HTTP krsek listzsa

TCP kapcsolatok listzsa
TCP kapcsolatok tartalmnak megjelentse
az egyes csomagok pontos adatainak megjelentse

Alacsony svszlessg hlzatokon (mint amilyenek a mobil hlzatok) fontos

megvizsglni, hogy a weboldal letltsi folyamat milyen hatkonyan hasznlja ki a
7

http://www.tcpdump.org/, http://www.wireshark.org/

21

2.3. bra. Wireshark IO graph. A webszerver az 5555-s porton fut, a szrk a forgalom
kt irnyt vlasztjk szt.

rendelkezsre ll svszlessget, s hogy az egyes HTTP lekrdezsek ebbl hogyan

rszesednek. A Wireshark-ban erre az IO Graph nev eszkz hasznlhat, ami az
idegysgenknt tvitt adatok hisztogramjt jelenti meg. A diagramhoz klnbz
szrk adhatk meg, s az ezekre illeszked csomagok a diagramon klnbz sznnel
jelennek meg.
Ahogy a 2.3. brn is lthat, az eszkz nagy hinyossga tbbek kztt, hogy
egyszerre legfeljebb t szr adhat meg, emiatt nem lehet egy diagramon brzolni
az sszes HTTP lekrdezs rszesedst.

2.3. Optimalizcik kategorizlsa

2.3.1. Szereplk
Egy weboldal betltshez rengeteg klnbz szerepl ltal fejlesztett s zemeltett
szoftver s hlzati eszkz egyttmkdsre van szksg. Ezek mindegyike befolysolhatja azt, hogy egy weboldal betltdsi folyamata mennyire hatkony. Legfontosabb termszetesen maga a weboldal s az azon hasznlt third-party szoftverek
minsge, de rdemben befolysolhatja a teljestmnyt a webszerver, a klnbz
kzvettk (pl. HTTP proxy-k) s a felhasznl bngszje is.
Ahhoz, hogy egy weboldal teljestmny szempontjbl hatkony legyen, a weboldal
fejleszti rszrl a bngsz mkdsnek alapos ismeretre, folyamatos mrsre s
visszacsatolsra van szksg. A legtbb esetben ez tl idignyes s kltsges folyamat, ezrt a webfejlesztk ltalban klszablyokra s bevlt mdszerekre alapoznak. Lteznek olyan szoftverek, amik pontosan ezt a tpus optimalizcit segtik.
Ilyen pldul a Google Chrome bngszhz fejlesztett PageSpeed Tools kiegszt8
8

https://developers.google.com/speed/pagespeed/

22

s a WebPagetest9 is.
A kvetkez lpcsfokot azok a szoftverek jelentik, amiket a weboldal zemeltetje
a webszerver eltti rtegben vagy webszerver beplmodulknt hasznlhat. Ezek
a szoftverek akr a weboldal struktrjt is mdosthatjk gy, hogy hatkonyabb
legyen a betltse. Ehhez olyan informcikat is felhasznlhatnak, amiket nem a
weboldalbl nyernek ki automatikusan, hanem a weboldal zemeltetjtl kapnak
meg konfigurcis fjl formjban. Az ilyen informcik jelentsen nvelhetik a hatkonysgot. Ilyen pldul a HAProxy10 s a Google Page Speed Service11 .
Az internetszolgltatknak rdekben ll az, hogy az gyfeleik minl gyorsabbnak rzkeljk a szolgltatsukat. Ezrt sok szolgltat alkalmaz olyan optimalizl
szoftvert, ami a webszerver s a felhasznl bngszje kztt kzvetti s esetleg mdostja a forgalmat gy, hogy a felhasznl ltal rzkelt minsg (QoE - Quality of
Experience) javuljon. Ezek a szoftverek az elz tpusnl jval messzebb helyezkednek el a tartalomtl, s nincs hozzfrsk az zemeltettl szrmaz informcikhoz. Hozzfrhetnek viszont a hlzattal kapcsolatos adatokhoz, pldul ismerhetik
a rendelkezsre ll svszlessget s a tipikus ksleltetst. Ennek megfelelen ltalban ms mdszereket hasznlnak, mint az elbb bemutatott optimalizlk. Ilyen
optimalizcikat valstanak meg pldul a ByteMobile termkei12 .
A bngszk a beptett optimalizcik mellett aktv szerepet vllalhatnak egy
msik szerepl ltal kezdemnyezett optimalizcis folyamatban: elkpzelhet olyan
megolds az elbb felsorolt rtegekben, ami a weboldal tartalmt gy mdostja,
hogy egy JavaScript vagy HTML kdot szr be. Ebben az esetben ez a kd aztn a
bngszben lefutva egyttmkdik a kdot beszr szereplvel.

2.3.2. Hlzati rtegek

Egy msik szempont az, hogy ha az adott optimalizcis technika a hlzati forgalmat manipullja, akkor az melyik hlzati rtegben mkdik. Az egyes szereplk
mdosthatjk a weboldal tartalmt
optimalizlhatnak a HTTP protokoll rtegben
manipullhatjk a forgalmat az alsbb hlzati rtegekben
A kzvettk ezeket implementlhatjk a bngszk s a webszerverek szmra tltszan vagy a kliensben expliciten belltott HTTP proxy hasznlatval. Az
olyan, kzvettk ltal hasznlt optimalizcikat, amik a weboldal tartalmnak mdostsval jrnak, intrusive-nak, az olyanokat pedig, ahol erre nincs szksg non9

https://code.google.com/p/webpagetest/
http://haproxy.1wt.eu/
11
https://developers.google.com/speed/pagespeed/service
12
http://www.bytemobile.com/products-applications/web.html
10

23

weboldalak

HTTP lekrdezsek

felhasznli navigci

2.4. bra. Felhasznli modell alapja a weben

intrusive-nak nevezzk. Az intrusive technikk hasznlata mindig kockzatosabb,

mert elfordulhat, hogy hatsukra egy-egy weboldal nem fog megfelelen mkdni.
Ezeket a technikkat teht nagyon krltekinten kell megtervezni s hasznlni.

2.4. Eltlts
Az eltlts vagy prefetch egy olyan optimalizci, amit az informatika sok terletn
hasznlnak arra, hogy elrejtsk egy rendszer mkdsnek (sokszor elkerlhetetlen)
lasssgt a rendszer felhasznli ell. Mkdsnek alapja hogy bizonyos krseket
mr azeltt elkezd a rendszer kiszolglni, hogy azokat a felhasznl kezdemnyezte
volna. Ehhez mindenkppen szksg van egy modellre, amit a felhasznl viselkedsnek elrejelzsre fel lehet hasznlni. Ez a modell sohasem tkletes, emiatt
lehetnek rosszul elrejelzett krsek. Az eltlts teht mindig egy kompromisszumot jelent: elkpzelhet, hogy az elre teljestett krsek kzl nem lesz mindenre
szksg, s ez erforrsok pazarlsval jr.
A modern opercis rendszerek mindegyike hasznl eltltst a rendszer induls folyamatnak gyorstsra: az elz boot folyamatok napli alapjn a szksget
fjlokat mr a folyamat legelejn elkezdik beolvasni a merevlemezrl a memriba
[33]. Erre azrt van szksg, mert a boot folyamatban sokszor egymst vltjk a
CPU-intenzv s az IO-intenzv rszek. Az eltlts hatsra ezek kvzi prhuzamosthatk, s gy mindkt erforrst hatkonyan hasznlja ki a folyamat.
A weben az eltlts azt jelenti, hogy bizonyos HTTP krseket valamelyik szerepl (bngsz, proxy, stb.) mg azeltt elindt, hogy a felhasznl erre expliciten
utastst adott volna. A felhasznli modell vza a legtbb esetben ugyanaz: a felhasznl egy utat jr be az egyes weblapokon keresztl (linkeket kvetve, vagy URL24

eket megadva), s kzben a bngsz letlti az adott weblaphoz tartoz erforrsokat. Ezt a modellt az 2.4. bra szemllteti. Ha az eltlt algoritmus (ami brmelyik
szereplnl futhat) a felhasznli modell alapjn megjsolt egy lekrdezst, akkor a
cl mindig az, hogy a krsre adott vlaszt kzelebb juttassa a klienshez, hogy ha a
krs tnylegesen bekvetkezik, akkor a vlasz gyorsabban megrkezhessen.
Ebbl a nagyon ltalnos jellemzsbl is ltszik, hogy az egyes eltltsi megoldsok sok paramter mentn klnbzhetnek. rdemes ezeket a paramtereket megvizsglni, hogy tfog kpet kapjunk a lehetsges megoldsokrl. Az egyik legjobb
szempontrendszert Bouras s Konidaris [6] dolgozta ki, ami a kvetkez elemekbl
ll:
Kik? Kik vesznek rszt az eltltsi folyamatban?
Mit? Pontosan melyek azok a HTTP lekrdezsek, amiket elre kell illetve elre
lehet hozni? A krdsre ltalban egy algoritmus ad vlaszt, ami a felhasznli
modell alapjn vlaszt ki krseket.
Hogyan? Hogyan adjk t az egyes szereplk egymsnak az eltlttt krseket s
vlaszokat?
Mikor? Mikor trtnik az adattvitel? Trtnhet pldul akkor, amikor a felhasznl az elzleg letlttt weboldal tartalmt elolvassa.
A webes eltlts a 90-es vek msodik felben nagyon npszer kutatsi tma
volt. Az alfejezet tovbbi rszben elszr ezeket a kutatsokat mutatom be. A
tma irnti rdeklds a kvetkez vtizedben jelentsen visszaesett, de a felvzolt
rendszerek egyes elemeit az elmlt vekben elkezdtk hasznlni, s szabvnyostani.
Ezeket rviden ismertetem.

2.4.1. Korai kutatsok

Az egyik els webes eltltssel foglalkoz cikket Padmanabhan s Mogul publiklta
1996-ban [31]. Sok elremutat megfigyelst s javaslatot tettek, amik egy rsze ma
mr szabvnyosts alatt van (errl rszletesebben a 2.4.3. pontban lesz sz). Az
ltaluk lert rendszerben az eltlts kt szerepl kzremkdsvel valsul meg. Az
adott weboldal webszervere statisztikkat gyjt a felhasznlk viselkedsrl, s ez
alapjn tesz elrejelzseket, amiket HTTP fejlcek formjban juttat el a kliensnek.
A kliensprogram az aktulis helyzete (szabad hlzati kapacits, energiagazdlkodsi
megfontolsok, stb.) alapjn dnt arrl, hogy elkezdi-e az eltltst.
Az ltaluk javasolt egyszer elrejelz logika egy fjlrendszerekhez hasznlt eltlt algoritmuson [22] alapul. Ebben a smban a szerver minden letlttt erforrshoz
25

image1.gif

0.5

0.5
home.html

0.9

0.2

about.html

0.5

0.01

image2.gif

2.5. bra. Padmanabhan s Mogul modellje

megfigyeli, hogy a kliens utna milyen ms erforrsokat krt le. Az adatokat egy
irnytott grfban trolja el, ahol minden egyes lhez egy valsznsg van rendelve.
Az A-bl B-be mutat len lev rtk azt mondja meg, hogy mennyi a valsznsge
annak, hogy A lekrdezse utn w lekrdezsen bell a kliens lekrte B-t, ahol a
w ablakmret az algoritmus egy paramtere. A grf egy lehetsges llapota a 2.5.
brn lthat.
Ez a sma valjban egy egyszer elsrend (memriamentes) Markov-lncot r
le. Az elrejelz algoritmusok fejldst vgig a Markov-lnc modell hatrozta meg.
Davidson ttekintse [13] szerint a legtbb modell m-edrend Markov lncot hasznl,
de vannak olyanok is, amik az elrhet informcik alapjn slyozzk a klnbz
rend Markov lnc modelleket a jobb hatkonysg elrse rdekben. Ilyen a Prediction by Partial Matching algoritmus is, amit eredetileg adattmrtshez hasznltak,
s elrejelzshez elszr Vitter s Krishnan [37] javasolta. Chierichetti et al. [7] kutatsa szerint a magasabb rend Markov lncok j kzeltst adnak a felhasznli
viselkedsre. Ez igazolja az ilyen algoritmusok ltjogosultsgt.
A felptett modell hatkonysga nagy mrtkben fgg a rendelkezsre ll informciktl. A klnbz szereplk a webes forgalom klnbz nzeteit ltjk:
A felhasznl bngszje a felhasznl sszes lekrdezst ltja.
Egy kzvett (proxy) egy adott felhasznli kr krsei kzl azokat ltja,
amik nem voltak benne a bngsz gyorsttrban.
Egy webszerver a hozz berkez (nem-gyorsttrazott) krseket ltja a weboldal sszes felhasznljtl.
Mindegyik szerepl az informcik egy rszhalmazhoz fr hozz, s az alkalmazott
eltlt algoritmusokat ennek megfelelen kell finomhangolni. Az eltlt algoritmus
mellett az eltlts mdja is eltr attl fggen, hogy mely szereplk vesznek rszt
a folyamatban, ennek megfelelen klnbz megoldsok szlettek szerver-kliens,
proxy-kliens s szerver-proxy eltltsre.
26

Az eltlts megvalstsra szinte csak olyan megoldsok szlettek, amik mkdshez mdostani kell a bngsz-szoftvereket, a webszervereket illetve a HTTP
protokollt. Nagyon kevs olyan megolds van, amihez nem kell a bngsz s a
webszerver explicit tmogatsa. Ezek a szoftverek azonban ltalban nagyon bonyolultak, emiatt kevs konkrt implementci ltott napvilgot. A mdszerek kirtkelsnl ezrt ltalban szimulcikra tmaszkodnak, s olyan, publikusan is elrhet
HTTP szerver naplkat hasznlnak, mint pldul az 1995-s EPA-HTTP adatbzis
[5] vagy az 1996-os UC Berkeley Home IP Web Traces [21].
Ez all kivtelt jelent nhny szerver-proxy tpus eltlt rendszer, ami praktikusan megvalsthat csak a proxy mdostsval [29, 6, 27, 25]. Ezek arra alapulnak,
hogy a proxy a gyorsttrba eltlt bizonyos tartalmakat, ha az elrejelz algoritmus szerint a felhasznl azokat hamarosan lekri.

2.4.2. Megvltozott krnyezet

Az eltltssel kapcsolatos kutatsok legaktvabb idszaka 1996 s 2000 kz esett,
s kevs 2004 utni cikket lehet tallni. Azta azonban drasztikusan megvltozott a
vilghl. A weboldalak nagy rsze dinamikusan generlt (emiatt a HTML ltalban nem gyorsttrazhat), rengeteg szkript fut rajtuk, tovbb sok a third-party
tartalom (reklmok, begyazott tartalmak). Egy weboldalhoz 1995-ben tlagosan
kevesebb mint 3 erforrs (kp, stluslap, stb) tartozott, mg ez a szm 2012-ben
megkzeltleg 100 volt [40]. A weboldalak tlagos mretnek alakulst az 2.6. bra mutatja be.
A legtbb javasolt Markov-lnc alap modell szmtsi s trolsi ignye ltalban exponencilisan n a lnc rendjnek nvekedsvel. A rend viszont arnyosan
kell hogy njn a a weboldalakhoz tartoz lekrdezsek szmval, ha a HTTP lekrdezsek elrejelzsrl van sz. Erre egy lehetsges megolds az, hogy nem a HTTP
lekrdezseket figyelik meg, s jsoljk meg az elrejelz algoritmusok, hanem a felhasznl ltal megltogatott weboldalak cmt, s ezutn egy kvetkez lpsben
prblnak kvetkeztetni a konkrt HTTP lekrdezsekre. Ez egy manapsg tlagosnak mondhat weboldal esetn viszont nem trivilis feladat, ahogy az esettanulmny
lersbl (1.7. rsz) is ltszik.

2.4.3. Ma is hasznlt, illetve szabvnyostott megoldsok

A gyakorlatban egyelre nem terjedtek el a felhasznlk viselkedst automatikusan elrejelz webes rendszerek. Ennek ellenre van nhny terlet, ahol sikeresen
hasznlnak eltltsre alapul megoldsokat. Az egyik, mr ltott plda a speculative parsing (1.5. rsz). Ebben az alfejezetben ezeket a gyakorlatban is hasznlt
27

120

1000

Erforrsok sszmrete
Erforrsok szma

100

800

80

600

60

400

40

200

20

Erforrsok szma

Erforrsok sszmrete (kbyte)

1200

0
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012

2.6. bra. Egy tlagos weboldal mretnek vltozsa 1995 s 2012 kztt

<link href="stiluslap.css" rel="stylesheet" type="text/css">

<style> /* Inline CSS */ </style>
<script src="script.js"></script>
<script> /* Inline JavaScript */ </script>
<img src="kep.png">
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADIA...">
2.7. bra. HTML kd kls hivatkozssal, s begyazva

mdszereket mutatom be rviden.

Inlining
Az eltlts egy egyszer formja az inlining vagy begyazs. Mkdsnek alapja,
hogy egy kzvett, vagy a webszerver a HTML kd statikus elemzse utn a hivatkozott szkripteket, stluslapokat, kpeket letlti s begyazza a HTML-be. Ezt az
teszi lehetv, hogy a HTML tmogatja az ilyen tpus erforrsok begyazst s
URL alapjn val hivatkozst is. Ezt a 2.7. brn lthat kdrszlet szemllteti. Ez
azrt tekinthet eltltsnek, mert a HTML tvitelvel egyidben tulajdonkppen
eltlti a rendszer azokat az erforrsokat, amire a bngsznek a megjelents sorn
szksge lesz.
28

Egy ezen az elven mkd proxy szerver a kvetkez lpseken megy vgig:
1.
2.
3.
4.
5.

rkezik egy HTTP lekrdezs, s ezt tovbbtja

megrkezik a vlasz, ami egy HTML fjl
a HTML feldolgozsa utn letlti a hivatkozott erforrsokat
a letlttt tartalmakat begyazza a HTML-be
elkldi a kliensnek a kiegsztett HTML fjlt

Ez a mdszer azonban sok htrnnyal is jr. Az egyik problma, ami HTTP

proxy-ban val hasznlat esetn jelentkezik, hogy kliens emiatt ksbb kezdheti meg a
feldolgozst, mert meg kell vrnia, amg a proxy letlti s begyazza az erforrsokat.
Egy msik, hasonlan fontos problma a cache kezelse. A begyazott erforrsok
nem kerlnek be a bngsz gyorsttrba, mert az csak URL alapjn hivatkozott
erforrsokat trol, emiatt minden alkalommal jra le kell tlteni ket.
Ezt a tpus eltltst felhasznlja a ByteMobile s a Google Page Speed Service
is. A ByteMobile az sszes szkriptet s stluslapot begyazza, mg a Page Speed
Service csak a nagyon kis fjlokat. Ez utbbi viselkedsre a dokumentci13 ad magyarzatot:
There is a tradeoff here between requests and cacheability: including the
resources directly in the HTML avoids making an additional request to
the external resource, but if the resource file is large (and doesnt change
often), it may be better to keep it separate from the HTML so that it
can be cached by the browser.
A begyazs teht csak kis mret vagy gyakran vltoz erforrsoknl elnys. A
Page Speed Service a weboldal zemeltetjvel egyttmkdve meg tudja llaptani,
hogy melyek ezek tartalmak. Egy ltalnos proxy esetn azonban ez csak a HTTP
vlaszbl derl ki, teht meg kell vrni a hivatkozott erforrsok letltst, emiatt
ezt a mdszert hasznlva a HTML letltsnek ksleltetse elkerlhetetlen.
A SPDY s a HTTP/2 protokoll
Az elmlt vekben felmerlt az igny a HTTP protokoll kvetkez, hatkonyabb
verzijnak kidolgozsra. A Google elkezdte a SPDY protokoll [3] fejlesztst, ami
aztn a jelenleg a szabvnyostsi folyamat elejn jr HTTP/2 [2] alapja lett. Az
j protokollok ltal nyjtott elnyk a kvetkezk:
A HTTP/1.1 szemantikja teljes mrtkben megmarad (metdusok, fejlcek,
stb.), csak a hlzati forgalom formtuma vltozik, gy a meglev alkalmazsokat nem kell mdostani.
13

https://developers.google.com/speed/docs/pss/InlineSmallResources

29

Fejlcek tmrtse.
Multiplexels: tbb krs hatkony multiplexlsa egyetlen TCP szlon.
A vlaszok priorizlsnak lehetsge.
Szerver oldalon kezdemnyezett krsek lehetsge.

A multiplexels lehetv teszi, hogy egy szerver s egy kliens kztt mindssze
egyetlen TCP kapcsolat pljn ki, s ezen keresztl prhuzamosan tetszleges szm HTTP krs utazzon. Ez jelents elrelps a HTTP-hez kpest, ahol akr 6
prhuzamos TCP kapcsolat pl ki, s a prhuzamos krsek szma kapcsolatonknt 1. A prhuzamos krsek kztt a kliens prioritsi sorrendet llthat fel.
Az eltlts szempontjbl legfontosabb kpessg a szerver oldalrl kezdemnyezett krsek lehetv ttele. Ez arra hasznlhat, hogy a szerver a kliens gyorsttrba helyezzen el erforrsokat. Ha a kliens gyorsttrban mr szerepel az adott
erforrs, akkor visszautasthatja a krst. Ez a megolds az inlining minden elnyt megrzi, de a htrnyait nem rkli: a csatolt erforrsokat a kliens krse
nlkl, ugyanazon a TCP szlon lehet elkldeni, de a HTML ksleltetse nlkl s
a gyorsttrazs helyes kezelsvel.
Prefetch hintek
A Mozilla bngsz a 2003-ban kiadott 1.2-es verziban vezette be a link prefetch
kpessget [28], ami kpess tette a bngszt arra, hogy fogadja a webszerver eltltsre vonatkoz javaslatait. Ezt a kpessget a Mozilla bngszbl szrmaz Firefox
is 2003 ta tmogatja. A szerver kt mdon jelezheti az eltltsi javaslatot: a HTTP
Link fejlcet hasznlva, vagy a <link> HTML tag hasznlatval. Az utbbi vltozat bekerlt a HTML5 szabvnyba is, de mg nem implementlja minden nagyobb
bngsz. Ez a sma gyakorlatilag megegyezik azzal, amit Padmanabhan s Mogul
1996-ban javasolt [31].
A SPDY protokoll tmogatja az n. server hint kpessget, ami gyakorlatilag
a Link fejlc tvtelt jelenti. Ezt a kliens oldali SPDY implementcik mg nem
implementltk.
A Google bngszi a <link> tag tbb kiterjesztett vltozatt is tmogatjk. A
rel attribtum hasznlatval lehet megadni, hogy milyen tpus eltltsrl van
sz:
prefetch: a megadott erforrs eltltse, ha van szabad kapacits
subresource: olyan erforrs, ami biztosan kelleni fog az oldal betltshez,
ezrt minl hamarabb le kell tlteni 14
14

http://www.chromium.org/spdy/link-headers-and-server-hint/
link-rel-subresource

30

 prerender: olyan URL, amire a felhasznl nagyon nagy valsznsggel fog

naviglni (pl. az els keressi tallat egy keresben), ezrt rdemes lehet a
httrben az oldal betltst megkezdeni 15
DNS prefetch s TCP kapcsolatkezels
Nem tartalom eltlts, de elrejelzsre alapul az is, ahogyan a Chrome s a Chromium bngsz hlzati rtege a DNS lekrdezseket s a TCP kapcsolatok felptst
kezeli. Ezek a bngszk a felhasznl viselkedsre, s az adott weboldal mltbli felptsre alapozva megprbljk a DNS lekrdezseket elrehozni, s a TCP
kapcsolatokat elre felpteni azokhoz a webszerverekhez, ahov valsznsthet,
hogy HTTP krseket kell majd kldeni [23]. Az tletet elszr Cohen s Kaplan
publiklta 2002-ben [9].

15

https://developers.google.com/chrome/whitepapers/prerender

31

32

3. fejezet
Optimalizls eltltssel egy j
megkzelts
Ebben a fejezetben egy j, eltltsre alapul optimalizcit mutatok be, ami sokban
klnbzik az eddig ismert mdszerektl. Ez a kzvettk ltal hasznlhat technika
nem ignyli a kliensek s a szerverek mdostst s jl hasznlhat nagy ksleltets
(pl. mobil) hlzatokban. A hasznlhatsg alapfelttele, hogy a hlzati kapcsolat a
kzvett s a webszerver kztt nagyobb kapacits legyen (nagyobb svszlessg,
kisebb ksleltets), mint a kliens s a kzvett kztt.
Az els jelents klnbsg az eltlts idpontja. Az elz fejezetben ismertetett,
kzvettk ltal hasznlhat megoldsok legtbbszr azt hasznljk ki, hogy a felhasznl egy oldal betltse utn valamennyi idt eltlt az oldalon, s csak ezutn
lp tovbb. Ebben, a hlzat szempontjbl kihasznlatlan idsvban trtnik az
eltlts, amikor az eltlt logika megprbl olyan weboldalakat letlteni, amiket
a felhasznl a kvetkez lpsben megltogathat.
Az ltalam javasolt eltlt megolds akkor lp mkdsbe, amikor a felhasznl
egy weboldal betltst kezdmemnyezi. A bngsz ilyenkor elszr a HTML oldal
letltst kezdi el, s ezutn az els fejezetben bemutatott mdon tovbblp a hivatkozott tartalmakra. A HTTP proxy-ban fut eltlt logika a HTML alapjn indtja
el az eltltsi folyamatot, s a gyors internetkapcsolatnak ksznheten mg azeltt
letlti az elrejelzett tartalmakat, hogy azokat a kliens elkrn. Ez idelis esetben
tkletes eltlt logika mellett olyan hatssal jr, mintha a HTML fjl kivtelvel
az egsz tartalom a proxy-ban lett volna a weboldal betltsnek kezdetekor. Ezt a
megoldst hasznlva teht nincs szksg a felhasznlk viselkedsnek elrejelzsre.
A msik f klnbsg az ltalam javasolt eltlt logika. A ma hasznlt, HTML
elemzsre pl megoldsok a 3.1.5. pontban bemutatsra kerl statikus elemzst
hasznljk. Ez egy tipikus mai weboldal esetn viszonylag rosszul teljest, mert a tartalom egy jelents rszt ma mr szkriptek generljk. Ezt a problmt a dinamikus
33

elemzs bevezetsvel oldom meg, ami jelentsen hatkonyabb az ilyen lekrdezsek

elrejelzsben.
Az eltlts a legegyszerbb esetben a proxy gyorsttrba trtnik, de bemutatok olyan megoldsokat is, amik lehetv teszik a tartalmak eljuttatst a klienshez.

3.1. Eltlts a HTTP proxy-ba

Elszr azt az esetet mutatom be, amikor a proxy-ba trtnik az eltlts. Amikor
egy HTTP proxy azt ltja, hogy a felhasznl egy HTML oldalt kr le, szinte
biztos, hogy azt az oldal ltal hivatkozott erforrsok letltse fogja kvetni. Ha a
proxy-ba ptett logika kpes ezeket a krseket elrejelezni a HTML alapjn, akkor
az ezekre adott vlaszok mr a proxy-ban lesznek, amikor a kliens lekri azokat.
Ezzel jelentsen cskken a krs megvlaszolshoz szksges idt, s gy gyorsabban
tltdik be a weboldal a kliensnl.

3.1.1. Elrhet nyeresg

Idelis esetben minden lekrdezst sikeresen elrejelez, s a kliens lekrdezsnek berkezsig letlt a proxy. Ez a kliens szmra ugyanolyan gyorsulst jelent, mintha
megltogatott weboldal szervere a hlzatban hozz kzelebb, a proxy helyre kerlne. A kiindul llapotban a kliens-webszerver ksleltets rtke megegyezik a kliensproxy s a proxy-webszerver ksleltetsek sszegvel. Az optimalizci hatsra ez
lecskken a kliens-proxy rtkre, teht a ksleltetsbeli nyeresg a proxy-webszerver
ksleltetssel egyezik meg.
A 3.1. bra az origo.hu betltsi idejt mutatja a ksleltets s a svszlessg
fggvnyben. Az bra alapjn meghatrozhat, hogy adott krlmnyek kztt
legfeljebb milyen nyeresget jelenthet a proxy-ba val eltlts. Pldul 1,5Mbit/s
kliens-proxy svszlessg, 30ms kliens-proxy ksleltets s 20ms proxy-webszerver
ksleltets esetn a letltsi id 8683ms. Felttelezhet, hogy a szk keresztmetszetet
a kliens-proxy hlzati kapcsolat jelenti, ezrt a proxy-webszerver svszlessg nem
befolysolja a letltsi idt. Ha a svszlessg vltozatlan marad s a webszerverproxy ksleltets az eltlts miatt figyelmen kvl hagyhat, akkor a letltsi id
7814ms lesz, teht a nyeresg 10%. Ha felttelezzk, hogy a proxy-webszerver ksleltets rtke adott, akkor meghatrozhat, hogy milyen arny az elrhet nyeresg
a kliens-proxy svszlessg s ksleltets fggvnyben. Ezt a 3.2 bra szemllteti
10ms s 20ms ksleltets esetn.
34

14
13
12

Betltsi id [s]

11
10
9
8
7

1Mbit/s
1.5Mbit/s
2.3Mbit/s
3.4Mbit/s
5Mbit/s

6
5
4

10

20

30

40

50
60
Ksleltets [ms]

70

80

90

100

3.1. bra. Az origo betltsi ideje a svszlessg s a ksleltets fggvnyben

1Mbit/s
1.5Mbit/s
2.3Mbit/s
3.4Mbit/s
5Mbit/s

Elrhet nyeresg [%]

20

15

10

0
20+10

40+10

60+10

80+10

20+20

40+20

Kliens-proxy + proxy-webszerver ksleltets [ms]

3.2. bra. Az eltlts ltal elrhet nyeresg

35

60+20

80+20

Eltlt
Proxy cache
Kliens

Eltlt
gyorsttr

Webszerver

3.3. bra. Az eltlt bels felptse

3.1.2. Architektra
Az optimalizci implementlshoz kt funckionlis egysgre van szksg: egy eltltre s egy eltlt gyorsttrra (3.3. bra). Az eltlt gyorsttr teremti meg
a kapcsolatot az eltlt s a klvilg kztt, az eltlt feladata pedig az, hogy
egy HTML fjlt alapul vve megjsolja, hogy a kliens rszrl milyen lekrdezsek
fognak kvetkezni. Az eltlt akkor aktivldik, amikor a kliens egy HTML oldalt
tlt le.
Kt eltlt algoritmust ismertetek a 3.1.5. s a 3.1.6. pontban, de eltte az eltlt gyorsttr feladatt mutatom be, majd megvizsglom, hogy milyen elvrsokat
kell teljestenie az eltlt implementciknak.
Az eltlt gyorsttr egy specilis HTTP cache. Feladata az, hogy fogadja s
megvlaszolja az eltlt s a kliens krseit. Bizonyos kritriumok alapjn eldnti, hogy mikor tekinthet azonosnak egy olyan krs, ami a klienstl rkezett, s
egy olyan, ami az eltlttl. Minden ilyen krs-prhoz csak egy HTTP lekrdezst
indt, mgpedig akkor, amikor a krs-pr els fele megrkezik. A vlaszt mindkt flnek tovbbtja. Azrt fontos, hogy az eltlt is megkapja az ltala indtott krsekre
rkezett vlaszokat, mert elkpzelhet, hogy ezt felhasznlva tovbbi krseket tud
megjsolni. Amikor a krs-prra adott vlasz megrkezett, s azt sikeresen tovbbtotta mindkt flnek, akkor a krst lezrtnak nyilvntja. Olyan eset is elfordulhat,
hogy egy krs prja soha nem rkezik meg. Ilyenkor az eltlt gyorsttr valamilyen szemtgyjtsi stratgit hasznlva (pldul egy idzt lejrtakor) lezrja a
krst.
Ez a feladat annyiban klnbzik egy hagyomnyos gyorsttr feladattl, hogy
egyrszt minden lekrdezst csak rvid tvon trol (a kvetkez ugyanolyan krs
erejig), msrszt olyan krseket is tovbbthat a kt flnek, amik alapveten nem
gyorsttrazhatak. Teht fontos, hogy az eltlt gyorsttr nem veszi figyelembe a HTTP vlasz fejlcekben megadott kritriumokat a gyorsttrazhatsggal
kapcsolatban. Ez a mkdsi md egybknt szinkronban van azzal, ahogyan a bngszk a dupliklt krseket kezelik. Ha egy krsre mg nem rkezett vlasz, s egy
ugyanolyan krst kellene elindtani, akkor a vlasz gyorsttrazhatsgtl fg36

Elrejelzett krsek

Kliens krsek

Felesleges
Helyes

Elszalasztott

Rossz

3.4. bra. A kliens s az eltlt ltal indtott krsek

getlenl dnthet gy a bngsz, hogy nem indtja el a msodik krst. A HTML5

szabvny [4] ezt gy fogalmazza meg:
If the resource is identified by an absolute URL, and the resource is
to be obtained using an idempotent action (such as an HTTP GET or
equivalent), and it is already being downloaded for other reasons (e.g.
another invocation of this algorithm), and this request would be identical
to the previous one (e.g. same Accept and Origin headers), and the user
agent is configured such that it is to reuse the data from the existing
download instead of initiating a new one, then use the results of the
existing download instead of starting a new one.

3.1.3. Elvrsok egy eltlt implementcival szemben

Az eltlt ltal indtott lekrdezseket kategrikba lehet sorolni az elrejelzs sikeressge alapjn. A kategorizlst a 3.4. bra szemllteti. A legfontosabb elvrs,
hogy minl nagyobb tfeds legyen az eltlt ltal megjsolt lekrdezsek halmaza s a kliens ltal valban elindtott lekrdezsek halmaza kztt. Az ide tartoz
lekrdezseket az eltlt helyesen jelzi elre. A kt halmaz klnbsge olyan lekrdezseket tartalmaz, amiket az eltlt nem tudott megjsolni, illetve amiket
feleslegesen jsolt meg, mert azutn nem trsult hozz vals lekrdezs. A feleslegesen megjsolt lekrdezseket kt csoportba lehet besorolni. Az els csoportban azok
a lekrdezsek vannak, amik miatt felesleges svszlessget hasznlt fel a szerver, de
ms problmt nem okoznak. A msodik csoport az olyan tves elrejelzsekbl ll,
amik mellkhatsokkal jrhatnak, teht adatvesztst vagy ms problmkat okozhatnak a felhasznlnak. Mindenkppen elvrs egy eltltvel szemben, hogy ne
generljon ilyen lekrdezseket.
Nem egyszer azonban eldnteni, hogy egy lekrdezs melyik csoportba tartozik.
Ennek eldntshez olyan informcikra van szksg, amik a proxy szerverben az
adott krs ltrejttekor nem llnak rendelkezsre. Kt krdst kell megvlaszolni:
37

 Fog-e a kliens ugyanolyan krst generlni?

A krs a szerveren a milyen mellkhatsokat fog okozni?
A msodik krds fontosabb, mert ha egy eltlt ezt meg tudja vlaszolni, akkor
nem generl rossz, teht kros mellkhatsokkal jr krseket, s emiatt biztonsgos
a hasznlata. A msik krds a hatkonysg szempontjbl fontos: minl tbb olyan
krst kell generlni, amihez a kliens is fog azonos krst kldeni.

3.1.4. Biztonsg
Mivel a biztonsg a legfontosabb kvetelmny, rviden megvizsglom, hogy hogyan
lehet eldnteni egy krsrl, hogy biztonsgos-e.
Egy HTTP krs megvlaszolsa legtbbszr egy fjl beolvasst s visszaadst
jelenti. Azonban emellet (vagy ehelyett) tetszleges logika is trsthat hozz. Elkpzelhet pldul, hogy a GET http://www.example.com/d?id=3 lekrdezs a 3.
kpet adja vissza egy fotalbumbl, de az is, hogy a 3-as azonostj levl vgleges
trlst kezdemnyezi.
J tmpontot ad a HTTP/1.1 szabvny szemantikval foglalkoz rsze [17], ami
expliciten definilja a biztonsgos lekrdezseket (kiemels tlem):
4.2.1. Safe Methods
Request methods are considered safe if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect,
any state change on the origin server as a result of applying a safe method
to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the
origin server.
This definition of safe methods does not prevent an implementation from
including behavior that is potentially harmful, not entirely read-only, or
which causes side-effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior
and cannot be held accountable for it. For example, most servers append
request information to access log files at the completion of every response,
regardless of the method, and that is considered safe even though the log
storage might become full and crash the server. Likewise, a safe request
initiated by selecting an advertisement on the Web will often have the
side-effect of charging an advertising account.
Of the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe.
38

The purpose of distinguishing between safe and unsafe methods is to allow

automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it
allows a user agent to apply appropriate constraints on the automated
use of unsafe methods when processing potentially untrusted content.
A user agent SHOULD distinguish between safe and unsafe methods
when presenting potential actions to a user, such that the user can be
made aware of an unsafe action before it is requested.
When a resource is constructed such that parameters within the effective
request URI have the effect of selecting an action, it is the resource
owners responsibility to ensure that the action is consistent with the
request method semantics. For example, it is common for Web-based
content editing software to use actions within query parameters, such
as "page?do=delete". If the purpose of such a resource is to perform an
unsafe action, then the resource MUST disable or disallow that action
when it is accessed using a safe request method. Failure to do so will
result in unfortunate side- effects when automated processes perform
a GET on every URI reference for the sake of link maintenance, prefetching, building a search index, etc.
Sajnos a szabvny ezen elrsait ltalban nem tartjk be a weboldalak. Nagyon
sok olyan GET metdusra pl API van hasznlatba, ami mellkhatsokat okoz.
Kifejezetten gyakoriak az ilyen API-k a hirdetsek esetn. gy gondolom, hogy a
szabvny ltal javasolt t nem jrhat, nem lehet egyszeren kijelenteni, hogy a mellkhatsokrt nem felels az eltlt algoritmus. Ugyanezt a problmt rszletesen
kifejti Brian D. Davison az Assertion: Prefetching With GET Is Not Good [12] cm cikkben. egy j HTTP metdus bevezetst javasolja, amit az eltltst vgz
programok biztonsggal hasznlhatnak, mert soha nem jr mellkhatsokkal. Ez a
javaslat nem kapott elg figyelmet, s nem szabvnyostottk, ezrt a webszerverek
sem tmogatjk.
A mellkhatsok elrejelzsre egy msik, biztonsgosabb utat vlasztottam: azt
kell megvizsglnia az eltltnek, hogy mirt jtt ltre az adott krs. Egy HTTP krs kzli a szerverrel, hogy a kivlt ok a kliensben bekvetkezett. Pldul egy email
trlsre utast HTTP lekrdezs kivlt oka az, hogy a felhasznl trls gombra
kattintott, a krs pedig errl tjkoztatja a szervert. Ha egy krs kivlt oka olyan,
amitl valsznleg nem fgg semmi a szerver oldalon, akkor felttelezhetjk, hogy
a krsnek nem lesznek mellkhatsai.
Ilyen kivlt ok lehet pldul az, hogy a weboldal HTML kdja kpknt hivatkozik
egy adott erforrst. Ez azt okozza, hogy ha a felhasznl bngszjben az erforrs
39

nincs gyorsttrazva, akkor elindul egy HTTP lekrdezs. Mivel a weboldalt hosztol szerver kldte a HTML kdot, ezrt a lekrdezs bekvetkezse semmilyen j
informcit nem kzl vele azon fell, hogy az adott erforrs nincs a kliens gyorsttrban. Biztosak lehetnk benne, hogy ez a HTTP krs semmilyen mellkhatshoz
nem vezet, mert a lekrs nem kzl rdemi informcit a szerverrel.
Ms a helyzet az olyan lekrdezseknl, amik lnyeges krlmnyektl pldul
felhasznli interakciktl, a bngszben trolt adatoktl vagy a bngsz krnyezetvel kapcsolatos adatoktl fggnek. Egy szkript pldul kzlheti a szerverrel
egy HTTP lekrdezs formjban a kliens kpernyfelbontst (mint ahogy az esettanulmnyban is trtnt), hogy aztn a szerver ez alapjn egy megfelel mret
hirdetst kldjn. Az ilyen tpus krsek hibs elrejelzst minden eltlt implementcinak el kell kerlnie.
Ez alapjn a kvetkez ttelt lehet megfogalmazni:
Ha egy HTTP lekrdezs rdemi informcit kzl a szerverrel, akkor
felttelezhet, hogy van mellkhatsa, ha viszont csak trivilis, vagy lnyegtelen informcikat, akkor felttelezhet, hogy nincs.

3.1.5. Statikus elemzs

A lehet legegyszerbb eltlt implementci a HTML fjlok vizsglatn alapul.
Egy HTML parser fggvnyknyvtrat hasznlva beolvassa a kliens ltal lekrt
HTML fjlt, kls hivatkozsokat keres benne, s elkezdi letlteni azokat. Ezek a
kls hivatkozsok lehetnek pldul kpek, stluslapok vagy szkriptek. Stluslapok
esetn egy CSS parser hasznlatval megoldhat az is, hogy az eltlt a stluslap
ltal hivatkozott kpeket is letltse.
Statikust elemzst hasznl kt optimalizl proxy implementci is: a Wcol [25] s
a ByteMobile. Az elbbi csak letlti a statikus elemzs sorn elrejelzett tartalmakat.
Az utbbi viszont letlti s be is gyazza a HTML-be (a begyazs rszletesebb
lerst lsd a 2.4.3. rszben).
Egy ilyen, statikus elemzst hasznl implementcinak szmos htrnya van. A
legszembetnbb problma az, hogy nem futtatja a begyazott szkripteket. Ez kt
kvetkezmnnyel is jr. Egyrszt nem minden krst tud elrejelzni. Az origo.hu
esetn a fggsgi grf alapjn megllapthat, hogy az sszesen 124 krsbl a
HTML kd parse-olsval 21, a CSS parse-olsval s HTML-hez illesztsvel pedig tovbbi 48 krs jelezhet elre. Msrszt az is elkpzelhet, hogy tvesen jelez
elre lekrseket. A HTML szabvnyban rgztett parse-olsi algoritmus (lsd 1.2.
rsz) sajtossgai miatt az eltlt nem lehet biztos benne, hogy a statikus elemzssel kinyert erforrsokat a bngsz valban le fogja krni. Elkpzelhet, hogy egy
40

szkript a document.write() fggvnyt hasznlva gy mdostja a HTML-t, hogy a

hivatkozott erforrsok egy rszt a bngsz ne krje le.
Egy msik problma a CSS feldolgozst rinti: nem biztos, hogy a CSS fjlban hivatkozott sszes kpre szksg lesz az oldal megjelentshez. Elkpzelhet pldul,
hogy a weboldal egy egyestett CSS fjlt hasznl az sszes HTML dokumentumban, de mindegyik dokumentumra a CSS szablyoknak csak egy kis rszhalmaza
alkalmazhat.
Ezek a problmk a szerver oldali mellkhatsok szempontjbl nem kritikusak,
mert a generlt felesleges lekrdezsek csak lnyegtelen informcikat (pl. a kliens
bngszje nem futtatja a szkripteket, vagy hogy hibsan mkdik a CSS parser-e)
kzlnek a szerverrel. Ezek az informcik is csak gy nyerhetek ki a webszerveren,
ha az folyamatosan vizsglja az egyes krsek kztti sszefggseket, ami nagyon
valszntlen. Ami ennl fontosabb, hogy a statikus elemzsre alapul eltlt csak
az erforrsok egy rszhalmazt tudja elrejelezni, valamint hogy felesleges lekrdezseket generlhat.
Az, hogy emiatt mennyivel rosszabbul teljest ez az eltlt algoritmus az idelis eltlthz kpest, a vizsglt weboldaltl fgg. Az origo.hu esetn pldul a
vesztesg jelents (a HTML s a CSS beolvassa esetn krlbell 50%). Tovbbi
kutats trgya lehet annak feldertse, hogy ez a problma ms weboldalakat milyen
mrtkben rint.

3.1.6. Dinamikus elemzs

A kvetkez eltlt algoritmus a statikus elemzs problmit oldja meg, ezltal
a legtbb esetben jobban teljest annl. Ez az algoritmus egy j, elszr ltalam
felvetett tletre alapul.
Egy program vizsglatra kt elterjedt megkzelts ltezik: a statikus s a dinamikus elemzs. A statikus elemzs a kd lefuttatsa nlkl von le kvetkeztetseket
a program mkdsrl, mg a dinamikus analzis a kd viselkedst futtats kzben vizsglja. A statikus elemzst vgz algoritmusok ltalban egy-egy specilis
clterletre fkuszlnak, s nem kpesek a program egsznek viselkedst lerni.
A dinamikus elemzsnl a kdot egy virtulis krnyezetben lefuttatva az figyelhet
meg, hogy a program hogyan lp interakciba a krnyezetvel. Az eltlt algoritmus esetn a vizsglt program egy weboldalt betlt bngsz (virtulis bngsz),
a krnyezet pedig a hlzat, teht a krnyezetvel val interakci HTTP lekrdezsek indtst jelenti. Ebben az esetben teht clrevezet lehet a dinamikus elemzs
hasznlata a weboldal elemzsre.
Ahhoz, hogy egy virtulis bngszn alapul eltlt mkdkpes legyen, egy
nagyon fontos problmt kell megoldani: biztostani kell azt, hogy a virtulis bng41

sz a klienssel mindenben azonos krseket generljon. Ha ez nem lehetsges, akkor

legalbb azt, hogy minden krsrl eldnthet legyen, hogy azt a kliens is el fogja
indtani, vagy pedig tves elrejelzsrl van sz.
Egy weboldal a futsa sorn rengeteg olyan informcit felhasznlhat, amit a
krnyezettl krdez le. A krnyezete magban foglalja az aktulis szmtgpet, a
felhasznlt, a bngszt s mg sok ms tnyezt. Ezeket az adatokat feldolgozza, s
bizonyos esetekben HTTP krsek formjban kzli az t hosztol webszerverekkel.
Elemzssel minden HTTP krsrl eldnthet, hogy az elindtshoz, s a krs
ltal kzlt adatok sszelltshoz milyen okok vezettek. Egy virtulis bngsz
esetn azokat a lekrdezseket kell figyelmen kvl hagyni, amik olyan adatokat
felhasznlva, vagy olyan esemnyek hatsra indultak el, amik a kliensnl s a proxynl klnbznek. Ha pldul egy szkript lekrdezi az aktulis idt, majd ezt egy
HTTP krsben kzli egy szerverrel, akkor errl a lekrdezsrl teljes biztonsggal
llthat, hogy a virtulis bngsz helytelen adatokkal fogja megtlteni, mert a kt
krnyezetben az rk nem lehetnek teljesen szinkronban.
Dinamikus elemzsre alapul eltlts esetn teht egybeesik a biztonsg, s a
hatkonysg biztostsnak kulcsa: ki kell szrni azokat a lekrdezseket, amik a
bngsz krnyezetbl szrmaz informcikat hasznlnak fel.
Hogy lehet egy lekrdezsrl automatikusan megllaptani, hogy milyen ok-okozati
sszefggsek rvn jtt ltre? Lehetne pldul a virtulis bngsz JavaScript futtatmotorjt gy mdostani, hogy minden vltoz rtkrl szmon tartsa azt, hogy
milyen ms rtkek lehettek r hatssal. Pldul ha az a vltoz rtke fgg egy
vletlenszm rtktl s b vltoz rtke fgg egy URL paramtertl, akkor a c =
a + b vltoz rtke fgg mindkt krlmnytl. Ezt az informatikai biztonsgtechnikban taint checking-nek nevezik. A JavaScript futtatmotorok azonban komplex
szoftverek, emiatt ezt nagyon nehz lenne implementlni a virtulis bngszben.
Egy egyszerbb megoldshoz vezet a kvetkez gondolatmenet. Nem felttlenl
szksges pontosan feltrkpezni, hogy egy HTTP lekrdezs mitl fgg, mert enlkl is megllapthat, hogy fgg-e valamelyik krnyezeti hatstl. Nevezzk vletlenszer krnyezetnek az olyan virtulis krnyezetet, ami minden lekrdezsre vletlenszer rtkekkel vlaszol. Egy vletlenszer krnyezetben fut bngszben
betltd weboldal rszben randomizlt HTTP lekrdezseket fog elindtani. Azrt
csak rszben, mert azok a lekrdezsek, amik meglte, illetve tartalma nem fgg a
krnyezettl, minden esetben ugyangy fognak megjelenni. Kt, vletlenszer krnyezetben prhuzamosan futtatot bngsz esetn knny megllaptani, hogy mely
lekrdezsek fggnek a krnyezettl: azok, amiket a kt bngsz ms paramterekkel
indt el. Azok a lekrdezsek, amik nem fggnek a krnyezettl, mindkt bngsznl ugyangy fognak megjelenni. Ez alapjn teht kiszrhetek a veszlyes, illetve

42

a felesleges krsek.
Informcihinyos lekrdezsek kezelse
Az elbb lertak alapjn megklnbztethetk azok a lekrdezsek, amik olyan informcikat hasznlnak fel, amik a proxy-ban nem llnak rendelkezsre. Ezeket a
lekrdezseket nevezzk informcihinyos lekrdezseknek. Ezeket nem lehet tovbbtani, mert felesleges vagy rossz lekrdezsek. Ehelyett az eltlt implementci
ezeket eldobhatja, vagy valamilyen specilis mdon kezelheti.
Az ilyen krsek eldobsa, teht megvlaszolatlanul hagysa ahhoz vezethet, hogy
a weboldal betltse egy ponton megll, s nem lp tovbb. Ez akkor fordulhat el,
hogyha egy ilyen blokkolt krstl a fggsgi grfban sok ms lekrdezs fgg. Az
origo.hu pldjra visszatrve: a 88-as lekrdezs a hirdet szerverekkel informcikat kzl a kliensrl, s a vlaszban a megjelentend hirdetsek listjt adja vissza.
Az eltlt algoritmus teht a krs eldobsa esetn nem lesz kpes eltlteni a
hirdetseket.
Egy sokkal hatkonyabb megolds az, ha az ilyen informcihinyos lekrdezseket
szinkronizcis pontknt kezeljk. Ez azt jelenti, hogy az eltlt algoritmus megprblja azonostani azt a krst, ami a klienstl szrmazik, s a blokkolt krs-prnak
felel meg, majd az erre a krsre kapott vlaszt tovbbtja a virtulis bngszknek.
Ezutn a virtulis bngszk tovbblphetnek, s ha nincs tbb ilyen lekrdezs,
akkor befejezhetik az oldal betltst.
rdemes megvizsglni, hogy egy ilyen szituciban problmt jelentene-e azaz
vezetne-e hibsan elrejelzett lekrdezsekhez az, hogy a virtulis bngszk egy
ilyen vlasz megrkezse utn sem fogjk ismerni azokat az informcikat, amik
alapjn a kliens a lekrdezst elindtotta. Egy lekrdezs, ami ez utn szletik, az
tbb forrsbl hordozhat informcit. Ha az j krs indtshoz csak a vlaszban
rkezett adatokra van szksg, akkor mindkt virtulis bngsz, valamint a kliens
is ugyanazt a lekrdezs fogja elindtani. Ha a krs indtshoz tbb forrsbl van
szksg informcira, akkor a kt virtulis bngsz klnbz lekrdezst indt,
s jabb szinkronizcis pont jn ltre. Hibsan elrejelzett lekrdezsre teht nem
kerlhet sor, ezrt a mdszer biztonsgosan hasznlhat.
HTTP stik kezelse
Egy msik megoldand problma a klnbz domainekhez tartoz HTTP stik
(vagy cookie-k ) kezelse. A sti egy olyan, a bngsz ltal trolt, domain nevekhez
kttt rvid szveges informci, amit a weboldalon fut szkriptek, vagy az adott
domain-hez tartoz webszerver llthat be. A bngsz minden egyes HTTP krshez
elkldi az adott domain-hez tartoz stiket a Cookie HTTP fejlcben.
43

Amikor a kliens az eltltst elindt HTML oldalt lekri, akkor a proxy a lekrdezsbl rtesl arrl, hogy a kliens az adott domain-hez milyen trstott stiket trol.
Az ehhez a domainhez tartoz elrejelzett lekrdezsekhez ezt a stit trsthatja,
hogy a lekrdezs pontosan olyan legyen, mint amit a kliens el fog indtani.
Ezt viszont nem tudja megtenni az olyan erforrsoknl, amiket olyan domain-rl
kell betlteni, amihez a kliens mg nem kldtt lekrdezst. Ilyen esetben a proxy
nem tudja, hogy a kliens az adott domain-hez milyen stiket trol. Ilyenkor szintn
egy specilis szinkronizcis pontot kell ltrehozni, ami egszen addig blokkol, amg
a klienstl nem rkezik egy lekrdezs erre a domain-re, amibl mr kinyerhet a
sti rtke. Ezutn az erre a domain-re rkez krseket mr problma nlkl tudja
az eltlt kezelni.

rtkels
Ez az eltlt algoritmus teht nagy biztonsggal elrejelez minden olyan lekrdezst, ami nem fgg a proxy ltal elrhetetlen (csak a kliens ltal ismert) informciktl. Ennl nagyobb hatkonysg kt mdon rhet el: a biztonsg feladsval vagy
a kliens ltal birtokolt informcik proxy-ba juttatsval. Az els lehetsg vlemnyem szerint nem vllalhat (lsd a 3.1.4. pontot), a msodikat pedig nagyon krlmnyes megvalstani, ha figyelembe vesszk azt, hogy milyen nagy (s a HTML5
adattrol API-k megjelensvel egyre nagyobb) az az informcimennyisg, amit a
kliens trolni kpes. A vletlen szmok s az ra szinkronizci problmjt pedig ez
sem oldan meg. Emiatt ez az eltlt algoritmus az elbb emltett alapfeltteleket
elfogadva optimlisnak nevezhet.
A mdszer legnagyobb problmja az erforrsignye. Egy weboldal tartalmnak
elrejelzshez kt virtulis bngsz futtatsra van szksg. Nagy szm kliens
esetn ezek jelents terhelst jelenthetnek egy proxy szervernek.
Az origo.hu esetn ez az elrejelz algoritmus jelentsen jobban teljest a statikus
elemzsnl, ami a 124 krsbl a HTML kd feldolgozsval 21, a CSS beolvassval pedig tovbbi 48 krs jelez elre. Ez az sszes lekrdezs 56%-a. A virtulis
bngszt hasznl mdszer ltal elrejelezhet krsek szma 115, ami 93%-os pontossgnak felel meg. Termszetesen nem mindegy, hogy ezek a krsek a fggsgi
grfban hol helyezkednek el. Ebben az esetben a 9 informcihinyos lekrdezs kzl 2 van kedveztlen helyen (a 40. s a 88. szkript), a tbbi a fggsgi grfban
kevsb fontos helyen szerepel, gy nem htrltat ms lekrdezseket.
44

3.2. Eltlts a kliensbe

A kliensbe val eltltshez teljes mrtkben jrahasznosthatk az elz pontban
ismertetett technikk. A proxy a fenti mdszereket hasznlva elkezdheti eltlteni az
egyes erforrsokat, s a megfelel eszkzk birtokban ezeket mr azeltt elkezdheti
a kliensnek elkldeni anlkl, hogy az krte volna ket. Erre a problmra sajnos
nincsenek egyszer megoldsok, mert a HTTP krs-vlasz alap protokoll, ezrt
csak a kliens kezdemnyezhet, a szerver pedig a hozz berkezett krsekre vlaszol.
A kvetkezkben olyan megoldst keresek, ami a kliensbe val eltltst megvalstja. A fontosabb szempontok:
kompatiblits: Hasznlhat-e a jelenleg elterjedt bngszkkel?
overhead : Trtnhet-e felesleges adattvitel s ez hogyan befolysolja a weboldal teljestmnyt?
gyorsasg: Az eltlts hatsra hamarabb kerl-e az erforrs a klienshez, s
ha igen, mennyivel?
Az idelis megolds teht hasznlhat a jelenleg is elterjedt bngszkkel, kevs
overheaddel jr, s a szksges erforrsokat mg az eltt eljuttatja a klienshez, hogy
az elkezdte volna lekrni.

3.2.1. A kliensbe val eltltssel elrhet nyeresg

A kliensbe trtn eltltssel elrhet nyeresget a 4. fejezetben ismertetett mreszkzkkel becsltem meg. A szerverbe val eltltshez kpest elrhet nyeresget
a 3.5. bra mutatja be.

3.2.2. Mdostott hidden iframe technika

A szerver ltal kezdemnyezet adattvitel problmja nem j, s mr tbb megolds szletett r. Kezdetben a meglev HTML elemeket s JavaScript API-kat
hasznltk specilis mdon, ksbb tbb j, erre a clra ltrehozott API (WebSocket, Server-Sent Events) is szabvnyostsra kerlt a HTML5 rszeknt. Ezeknek a
mdszereknek a kzs jellemzje, hogy adattvitelt tesznek lehetv. Ahhoz, hogy
az eltlts megvalsthat legyen, az tvitt adatokat valamilyen mdon a bngsz
gyorsttrba kellene elhelyezni a megfelel URL-hez trstva, de ez sajnos nem
lehetsges. Ennek ellenre az egyik ilyen mdszert bemutatom, mert egy mdostott
vltozata mr jl hasznlhat.
Azokra a technikkra, amik ms clra szabvnyostott ptelemeket hasznlnak,
a szakirodalom ltalban Comet gyjtnvvel hivatkozik [10]. Az egyik ilyen Comet
45

20
1Mbit/s
1.5Mbit/s

2.5Mbit/s
3.5Mbit/s

5Mbit/s

Elrhet nyeresg [%]

15

10

-5

20

40

60
80
100
120
Kliens-proxy ksleltets [ms]

140

160

3.5. bra. A kliensbe val eltltssel elrhet nyeresg a szerverbe val eltltshez
kpest

vltozat a hidden iframe mdszer. Az alaptlet az, hogy a weboldal HTML kdjban
van egy rejtett <iframe> tag (ami begyazott HTML dokumentumok megjelentsre hasznlhat, de jelen esetben a felhasznl szmra nem lthat) egy megfelel
URL-el, a szerver pedig a HTML tartalmat nem egyszerre kldi el, hanem streameli. Amikor a szerver informcit akar kzlni, akkor elkldi a HTML egy jabb
darabjt, ami mindig egy-egy <script> tag-et tartalmaz, a tag-ben lev begyazott
JavaScript kd pedig egy fggvnyhvs segtsgvel kzli a szerver ltal kldtt informcit az oldalon fut tbbi kddal (az zenet cmzettjvel). Az iframe soha nem
tltdik be teljesen, ezrt ezt forever iframe techniknak is nevezik.
Az elbb bemutatott mdszer <script> tag-eket s bennk JavaScript kdrszleteket streamel. De ugyangy lehet akr <img> tag-eket is kldeni, aminek hatsra a
bngsz a hivatkozott kpeket letlti, s ha gyorsttrazhat, akkor eltrolja. Ez
jl illeszkedik a dinamikus elemzshez is, mert tudja kezelni a folyamatosan rkez
j eltltend linkeket, nem kell egyszerre elkldeni az erforrsok listjt.
A szkriptek s stluslapok kezelse nem ilyen egyszer, mert ha az eltlt iframeben megjelenik egy ilyen (<script> vagy <link>) tag, akkor a bngsz ezt nem
csak letlti, hanem le is futtatja. JavaScript esetn nem lehet elre tudni, hogy mit
eredmnyez a kd lefutsa (elkpzelhet, hogy felugr ablakot nyit meg, elindtja
46

egy vide vagy egy hangfjl lejtszst, stb.), ezrt ezt el kell kerlni. Ugyanez
a problma a stluslapoknl is fennll: egy stluslap elindthatja ms erforrsok
(pl. kpek, ms stluslapok) letltsk a krnyezettl fggen, de az iframe-ben
klnbzik a krnyezete a vals weboldaltl, s gy teljesen felesleges letltseket
indthat el. Ezen fell a stluslapok is tartalmazhatnak begyazott JavaScript kdot.
Ezek a nehzsgek azonban megkerlhetk, ha az sszes erforrst, tpustl fggetlenl <img> tag-ek hivatkozzk. Erre az a magyarzat, hogy a gyorsttrazs
mkdst a HTML-tl teljesen fggetlen HTTP szabvny hatrozza meg [16], ami
nem veszi figyelembe, hogy a krs milyen tag hatsra indult el. Ha teht egy
erforrs gy kerlt be a gyorsttrba, hogy az a weboldal kpknt hivatkozta, akkor ha utna ugyanazt az erforrst stluslapknt is hivatkozza a weboldal, akkor a
gyorsttrbl kapja meg a vlaszt.
Ha az adott erforrs mr eleve a gyorsttrban van, akkor az eltlt iframeben val hivatkozs hatsra nem indul el a letltse, gy a mdszer nem jr a
hlzati erforrsok pazarlsval. Itt teht nem jelentkezik az inlining esetben ltott
gyorsttrazsi problma.
sszefoglalsul, ez technika a kvetkez lpsekbl ll:
1. a proxy szerver a HTML kdba beszr egy rejtett iframe-et, forrsknt egy
adott URL-t megadva
2. a bngsz lekri az iframe tartalmt a megadott URL-rl (ez brmi lehet, de
az tkzsek elkerlse miatt fontos, hogy ne egy ltez URL legyen)
3. a proxy megkapja a HTTP krst, de nem tovbbtja, hanem streamelni az
iframe tartalmt
4. az elkldtt HTML rszletek mindig <img> tag-ek
5. amikor az eltlt logika meghatroz egy olyan URL-t, amit a kliens le fog
krni, akkor a szerver elkld egy <img> tag-et, aminek az src attribtuma az
eltltend URL
6. a bngsz megkapja s feldolgozza a HTML rszleteket, majd letlti, s eltrolja a gyorsttrban a megadott URL-eket
7. a weboldal hivatkozza az eltlttt tartalmat, s a vlaszt a gyorsttrbl
kapja meg
8. az eltlt logika teljes lefutsa utn a streamels befejezhet

3.2.3. Hlzati forgalom priorizls

A SPDY s a HTTP/2 protokoll lehetv teszi, hogy a kliens jelezze, hogy mely
erforrsok milyen prioritsak a weboldal betltse szempontjbl. A szerver a jelzsnek megfelelen vagy a sajt dntseire alapulva temezheti a hlzati forgalmat.
47

Ez eltlts esetn felhasznlhat annak megoldsra, hogy az eltlts mindig csak

a f forgalom mellett megmarad szabad svszlessget hasznlja fel. Egy jrulkos
elny, hogy a priorizls tovbbi optimalizcikat tesz lehetv. Megoldhat pldul
az, hogy a kliens a letltsi folyamat elejn egyszerre lekrt JavaScript fjlokat olyan
sorrendben kapja meg, ahogyan a HTML hivatkozza azokat, gy nem alakul ki az
esettanulmnynl ltott head of line blocking jelensg a szkriptek futtatsnl.
A legtbb kliens s szerver ezt egyelre nem implementlja, illetve sok kliens a
ezeket a protokollokat sem tmogatja. Emiatt rtelme lehet egy olyan szerver oldali
priorizls implementcinak, ami kpes eldnteni a kliens segtsge nlkl, hogy
mely erforrsok milyen prioritsak, valamint kpes a prioritsokat akr HTTP
lekrdezsek esetn is rvnyesteni.
Ha elrhet egy priorizls implementci, akkor a szervernek valamilyen logika
alapjn meg kell hatroznia az egyes HTTP vlaszok prioritst. Az eltltshez
tartoz vlaszok mindig a legkisebb prioritst kapjk. A tbbi erforrs rangsorolshoz fel lehet hasznlni valamilyen heurisztikt, vagy akr a virtulis bngszkbl
szrmaz informcit is.
Egy lehetsges heurisztikt a HTML parser mkdst alapul vve lehet kidolgozni. Minden nem aszinkron szkript blokkolja a parser futst, ezrt a lehet leggyorsabban el kell juttatni azokat a klienshez, mghozz olyan sorrendben, ahogy azok
a HTML kdban megjelennek. A szkriptek lefutshoz szksg van a CSS fjlokra,
ezrt ha a HTML-ben egy szkriptet egy stluslap elz meg, akkor elszr azt kell
letlteni. A parser mellett a msik f szempont az lehet, hogy az olyan erforrsok,
amiket rtelmezve a kliens jabb lekrdezseket generl, minl hamarabb jussanak
el a klienshez. Ez lehetv teszi, hogy a vlaszok megtltsk a hlzati kapacitst,
gy jobb betltsi idt eredmnyezve. A stluslapok, s szkriptek ltalban jabb
lekrdezseket generlnak, ez is indokolja a nagyobb prioritst. A kpek mindig a
alacsony prioritst kapnak, mert ltalban semmilyen tovbbi lekrdezst nem indt
be egy kp sikeres betltse.

48

4. fejezet
Prototpus s mrsi eredmnyek
Ez a fejezet a virtulis bngszket hasznl optimalizci hatkonysgnak igazolshoz elvgzett mrseket mutatja be. A mrsek elvgzshez tbb sajt eszkzt
is fejlesztettem, amiket nylt forrskd projektknt publikltam. Ezek abban nyjtanak segtsget, hogy egy weboldal letltst kontrolllt laboratriumi krlmnyek
kztt, megbzhatan s reproduklhatan lehessen lemrni. A reproduklhatsgot
klnsen nehz elrni, mert manapsg az sszes webes tartalom dinamikusan generlt, gy hatkony segdeszkzk nlkl lehetetlen ktszer ugyanazt a tartalmat
letlteni1 . A mrsi eszkzk s konfigurci ismertetse utn a mrsi eredmnyek
kirtkelshez s sszehasonltshoz hasznlt ismert, valamint jonnan ltrehozott
eszkzk bemutatsa kvetkezik. Ezek utn a prototpus s az azon vgzett mrsek
eredmnyeinek lersa kvetkezik.

4.1. Mreszkzk s reproduklhatsg

A mrsek elvgzshez a 2.2. pontban lert eszkzket (Chromium, tcpdump) hasznlom, de ezeknek nincsenek olyan parancssori kapcsoli, amik mrsek tbbszr
elvgzsre s az eredmnyek (pl. Timeline napl) mentsre lennnek hasznlhatk.
Ezrt ennek a feladatnak a megoldsra egy measure.js nev sajt eszkzt rtam.
Ez az alfejezet ennek a bemutatsval indul.
A measure.js-t hasznlva mr el lehetne kezdeni egy-egy weboldal tesztelst.
Azonban semmi nem biztostja, hogy egy weboldal kt oldalletltse ugyangy fog
lezajlani. St, egy weboldal fggsgi grfja legtbbszr nem statikus, hanem futsonknt klnbz. Sok tnyez befolysolhatja, pldul az aktulis dtum, a bngsz ltal generlt vletlen szmok (pl. a megjelentend hirdetsek kivlasztsnl),
a klnbz szerverek ltal visszaadott vlaszok (amik szintn fgghetnek rengeteg
dolgotl), a gyorsttrazott erforrsok, az elmentett HTTP stik, a Web Storage
1

Ktszer nem lpsz ugyanabba a folyba (Kr.e. 6. szzad, Hrakleitosz)

49

s ms bngszhz kttt adatbzisok tartalma stb. Az sem felttelezhet, hogy a

vizsglt weboldal webszerverei kt tkletesen azonos krsre ugyangy fognak vlaszolni, ezrt egy weboldal letltsi folyamat megismtlse csak egy konkrt lefuts
felvtelvel, majd visszajtszsval lehetsges.
A problma kt rszre bonthat. Egyrszt a felvtel sorn rgzteni kell az egyes
HTTP krseket s a rjuk adott vlaszokat, ksbb ezeket kell reproduklni. Msrszt
rgzteni kell a bngsz klnbz adatbzisainak kiindulsi llapott, a bngsz
ltal generlt vletlen szmokat s a futsi krnyezet minden olyan tulajdonsgt,
amit egy lefut szkript lekrdezhet (dtum, id, felbonts, sznmlysg, bngsz
azonost, ablakmret stb.). Visszajtszskor a bngsznek mindenben az eredeti
lefutshoz hasonlan kell viselkednie. Az alfejezet msodik felben a kt problma
megoldshoz ksztett eszkzket mutatom be.

4.1.1. measure.js
A mrsek elvgzshez tartoz feladatokat automatizlja az ltalam rt measure.js
szkript. A futtatshoz a node.js2 szerver oldali JavaScript futtatkrnyezet szksges. A program a kpessgeit jl bemutatja a parancssori kapcsolk listja:
--path p: A mrsi eredmny fjlok az adott helyre kerljenek a fjlrendszerben.
--network: Mentse a Network naplbejegyzseket (.network kiterjesztssel).
--timeline: Mentse a Timeline naplbejegyzseket (.timeline kiterjesztssel).
--capture intf: Mentse az intf interfsz hlzati forgalmt (.pcap kiterjesztssel).
--times n: A mrseket n alkalommal ismtelje meg.
--save list: Az n mrs kzl csak a list ltal megadottakat mentse. A
list egy vesszvel elvlasztott lista, aminek lehetsges tagjai: all (mindet),
average (az tlaghoz legkzelebbit), median (a medint), best (a legjobbat),
worst (a legrosszabbat) s summary (az sszefoglalt). A rendezs alapja a
letltsi id.
--print s: A standard outputra kirand szveg. A kapcsos zrjelek kztt
megadott JavaScript kifejezsek helyre a kirtkels utn kapott rtkek kerlnek, pl: "A mrsek tlaga: {Math.round(average)}ms" "A mrsek
tlaga: 11354ms".
--preload list: A f url eltt a list vesszvel elvlasztott listban szerepl
URL-eket tltse be. Ez a bngsz cache elre megadott llapotba hozsra
2

http://www.nodejs.org/

50

hasznlhat.
Az egyb paramteket parancssori argumentumknt tadja a mrsek sorn indtott bngszknek. Ezek kztt a paramterek kztt lehet tadni clpont weboldal
cmt is. Az elmentett adatok a pcap fjl kivtelvel JSON formtumak.
Plda a program hasznlatra:
node measure.js \
--times 5 --network --timeline --capture lo \
--path origo --save summary,best,worst --print {average}, {median} \
--incognito --disable-plugins \
http://origo.hu
Az gy indtott program
tszr megnyitja a http://origo.hu weboldalt
bngszknt egy-egy inkognit mdban, letiltott beplmodulokkal (pl. Flash)
fut Chromiumot hasznlva,
elmenti a leggyorsabb s a leglassabb mrsek network, timeline s hlzati logjait (origo.worst.network, origo.best.network, origo.worst.timeline,
stb. nven),
az origo.summary fjlba pedig az sszefoglalt (az egyes mrsek betltsi
id szerint rendezett Navigation Timing rtkeit, az tlagot, a szrst s a
medint),
majd kirja az tlagos s a medin betltsi idt.
Az elkszlt program nylt forrskd. Az aktulis verzi a kvetkez cmrl tlthet le: https://github.com/molnarg/measure.js.

4.1.2. http-box
A HTTP krsek felvtelre s visszajtszsra lteznek elrhet nylt forrs szoftverek (pl. mitm-proxy3 ), viszont ezek egyike sem a teljestmnyt figyelembe vve
lett kialaktva. Azt tapasztaltam, hogy a magas CPU hasznlat miatt torzultak a
mrsi eredmnyek, ezrt ms alternatvt kellett tallnom. gy dntttem, hogy
egy pehelysly, teljestmnyorientlt HTTP visszajtsz programot ksztek.
gy szletett meg a node.js alap, nylt forrskd http-box alkalmazs, ami
HTTP krsek felvtelre s visszajtszsra hasznlhat4 . Felvtelkor HTTP proxyknt mkdik, s rgzti a keresztlmen HTTP forgalmat. Lejtszskor szintn
3
4

http://mitmproxy.org/
A projekt elrhet a https://github.com/molnarg/http-box cmen.

51

HTTP proxy-knt mkdik, de nem tovbbtja a krseket a hlzatra, hanem egy

felvtel alapjn vlaszolja meg azokat. Konfigurlhat gy is, hogy azokat a krseket, amiket nem tud a felvtel alapjn megvlaszolni, tovbbtsa a hlzatra.
A felvtelek trolsi formtumnak kialaktsakor az elsdleges szempont a knny
feldolgozhatsg, mdosthatsg volt. Egy felvtel sok fjlbl ll, minden HTTP
krshez tartozik egy JSON formtum metaadat fjl .http.json kiterjesztssel,
s egy adatfjl, ha a vlasz tartalmazott adatot. Az adatfjl kiterjesztse a vlasz MIME-tpustl fgg (Content-Type HTTP fejlc), pl. text/html tpus esetn
a kiterjeszts .html. Felvtelkor a fjlok elnevezse a krs sorszmhoz igazodik
(teht a 3. krsnl pl. 002.http.json s 002.png), visszajtszskor a fjlok elnevezse nem jtszik szerepet, a program egy adott mappban megkeresi az sszes
.http.json kiterjeszts fjlt, beolvassa azokat, s betlti az ltaluk hivatkozott
adatfjlokat.
Visszajtszskor a program elre beolvassa az sszes meta- s adatfjlt a memriba, teht ezutn mr nem korltozza a visszajtszs teljestmnyt a fjlok elrsnek s beolvassnak ideje. A node.js HTTP szerver komponense mint ahogy
a beptett fggvnyknyvtainak tbbsge egy jl optimalizlt C++ alap implementci, teht ez sem jelenthet teljestmny problmt.
A program a kvetkez parancssori argumentumokat fogadja:

record dir vagy replay dir: Felvtel/lejtszs a dir mappba/mappbl.

--port port: Az adott porton fusson a beptett HTTP proxy.
--spdy: SPDY protokoll hasznlata HTTP helyett.
--inject script: A megadott JavaScript fjl injektlsa a HTML vlaszok
elejre.

4.1.3. pseudo.js
A bngsz krnyezetnek visszajtszsval kapcsolatos problmt egy olyan virtulis krnyezetet hasznlatval a legegyszerbb megoldani, ami determinisztikus s
knnnyen reproduklhat. Ezt a krnyezetet hasznlva mind felvtelkor, mind lejtszskor biztosthat, hogy a weboldal ugyangy tltdjn be (feltve, hogy a szerver
ltal kldtt vlaszok mindkt esetben ugyanazok).
A bngsz adatbzisainak s gyorsttrainak szempontjbl a lehet legegyszerbb ilyen virtulis krnyezet a Chromium inkognit mdja. Az inkognit md hasznlatakor egy j, teljesen res ideiglenes profilt hoz ltre a bngsz. Ezt hasznlva
biztos, hogy a klnbz adatbzisok kezdeti llapota mindig azonos: res. A vletlen szm generls reproduklsa s a krnyezet elrhet adatainak lemsolsa
ms megkzeltst ignyelnek. Ebben az esetben egyszerbb azt elrni, hogy ezeket
52

a lekrdezsek el se rjenek a bngszig, hanem azokat egy, a weboldalba injektlt

szkript vlaszolja meg.
A JavaScript dinamikus termszete miatt akr a bngszkbe ptett, HTML
szabvnyban rgztett API-k is gond nlkl felldefinilhatk futsidben. A vletlen szm generlst vgz Math.random() fggvny pldul felldefinilhat egy
JavaScript-ben implementlt pszeudorandom genertorral, ami egy megadott magrtkhez mindig ugyanazt a szmsorozatot generlja. A krnyezetrl informcikat
visszaad fggvnyek s beptett objektumok hasonl mdon felldefinilhatk,
hogy mindig egy adott rtket adjanak vissza.
Mivel nem talltam ilyen virtulis krnyezetet implementl nylt forrskd
projektet, egy sajt megolds ltrehozsa s publiklsa mellett dntttem5 . Az elkszlt pseudo.js fjl a http-box --inject kapcsoljval hasznlhat, s a kvetkez
kpessgekkel rendelkezik:
A Math.random() fggvny helyettestse David Bau pszeudorandom implementcijval [1].
A beptett dtum fggvnyek mdostsa gy, hogy mindig egy adott dtummal trjenek vissza.
A window.navigator objektum kitltse elre megadott rtkekkel.
A window, a window.screen s a window.document szlessg s magassg
adatainak felldefinilsa.
Az Array.prototype.sort() helyettestse Justin Force merge-sort implementcijval [18].
A bngsz JSON szerializl fggvnynek helyettestse Douglas Crockford
eredeti JSON szerializl kdjnak [11] egy mdostott vltozatval, ami nem
hasznlja a for ... in nyelvi szerkezetet.
A pseudo.js megprblja elfedni a bngszk kztti klnbsgeket is, hogy a weboldal felvtele tesztelhet legyen klnbz bngszkben. Az utols kt kpessg a
bngszfggetlensg biztostshoz fontos, a tbbi a determinisztikus krnyezetet
hatrozza meg.
Sajnos nem fedhetk el teljesen az egyes JavaScript futtatmotorok kztti apr klnbsgek. Pldul a nyelv for ... in ciklusnak mkdst az ECMAScript
szabvny [14] nem definilja elg pontosan. Ez a ciklus egy objektum attribtumain
iterl vgig, viszont az attribtumok rendezsi elvt a szabvny szndkosan nem
rgzti. Az egyes futtatkrnyezetekben az iterci sorrendjt az adott implementci ltal hasznlt alacsony szint adatszerkezetek dntik el. A V8 JavaScript motor
pldul elre veszi az olyan attribtum neveket, amik egsz szmm konvertlhat5

A projekt elrhet a https://github.com/molnarg/pseudo.js cmen.

53

ak6 , mg a legtbb implementci nem klnbzteti meg ezeket az egyb kulcsoktl.

Az elbbi problma miatt nem minden esetben tehet teljesen bngszfggetlenn egy felvtel csak egy virtulis krnyezet hasznlatval, hanem szksg lehet a
felvtel mdostsra is. A legtbb esetben azonban nem jelent gondot az iterci
implementcifggsge.

4.1.4. Idztsi viszonyok

Egy mrs tbbszri lefuttatsa esetn klnbz idztsi viszonyok lphetnek fel.
Ez akr azt is okozhatja, hogy kt, vletlen szm generlsra alapoz kd klnbz
sorrendben fut le. Ez azrt jelenthet gondot, mert a psudo.js vletlenszm genertora
mindig egy adott sorrendben generlja a szmokat, teht elfordulhat, hogy a kt
kdrszlet az idztstl fggen klnbz vletlenszmokat kap, s emiatt a kt
lefuts mskpp megy vgbe. Ez csak gy kszblhet ki, hogy a vletlenszm
genertor helyett egy mindig azonos szmot visszaad fggvnyt hasznlunk. Erre az
elvgzett mrseim sorn nem volt szksg, de elkpzelhet olyan szituci, amikor
szksges a csere.
Egy msik mellkhats, amivel szmolni kell az az, hogy az idztsi viszonyoktl
fggen a load esemny bizonyos erforrsok betltse eltt, vagy utn is bekvetkezhet. Teht nem lehet egyrtelmen meghatrozni az erforrsok azon halmazt,
amit a load bekvetkezshez be kell tlteni.
Az origo.hu betltsi folyamata pldul kt plus. Ennek oka az 1.5. brn lthat egy msodperces ksleltetsben keresend. Ha a hlzat megfelelen gyors, s
az idzt lejrta eltt befejezdik minden olyan fgg folyamat ami addig elindult,
akkor bekvetkezik a load esemny. Ha viszont valamirt mg marad fgg folyamat az idzt lejrtakor, akkor mg a load bekvetkezse eltt elindulnak jabb
folyamatok, amik eltoljk a bejezst amg az sszes jonnan indult folyamat be nem
fejezdik. ltalnos esetben a megoldst a load-ig eltelt id helyett egy msik mrszm kijellse jelentheti (lsd a 2.1.2. rszt). Jelen esetben azonban egy msik
utat vlasztottam.
Az origo.hu esetn a load egysgestst a 11. szkript mdostsval rtem el.
Amg az idzt aktv, addig folyamatosan prbl egy olyan kpet betlteni, amit
a visszajtsz szerver csak 400ms-es ksleltetssel ad vissza. Egszen addig jra s
jra betlti a kpet, amg az idzt le nem jr. Ez egy nhny bjtos kp, teht
rdemben nem befolysolja a hlzati forgalmat, viszont megakadlyozza, hogy a
load az idzt lejrta eltt kvetkezzen be.
A 4.1. brn lthat a weboldal betltsi folyamatnak szrsa a mdosts eltt
6

A kapcsold Chromium hibajegy: http://code.google.com/p/chromium/issues/detail?

id=883

54

1200
Eredeti
Mdostott

1000

Szrs [ms]

800
600
400
200
0

1.5

2.5
3 3.5
Svszlessg [Mbit/s]

7.5

10

4.1. bra. Az origo.hu eredeti s mdostott vltozatnak szrsa

s utn (pontonknt 20 mrs esetn). Jl lthat, hogy az 1.5 - 3.5 Mbit/s svban
klnsen nagy volt a szrs. Ennek az az oka, hogy ebben a svban a mindkt
fajta lefuts elfordult. Kisebb svszlessgek esetna load mindig eltoldott, mg
nagyobb svszlessgek esetn mindig az idzt lejrta eltt kvetkezett be. Mindkt
esetben kisebb szrs volt tapasztalhat, mint a kzps svban. A mdosts utn
a szrs szinte vgig a viszonylag alacsony 200 - 350ms svban maradt.

4.2. Hlzati krnyezet

A klnbz optimalizcik kirtkelsnl fontos, hogy a hatst hlzati viszonyok
szles skljn tesztelni lehessen. Ehhez valamilyen hlzat szimulcis krnyezetre
van szksg, amiben tetszs szerint llthatk az egyes csompontok kztti hlzati
kapcsolatok paramterei. Mivel ebben az esetben csak nhny csompontrl van sz,
egy viszonylag egyszer megoldst vlasztottam a teljes rtk hlzatszimulcis
megoldsok (pl. ns-37 ) helyett. Vlasztsom a Linux kernel beptett Traffic Control
(tc) kpessgre esett.

4.2.1. Traffic Control

A tc segtsgvel az egyes hlzati interfszek sorbanllsi mdszere (queueing discipline, vagy qdisc) hatrozhat meg. Egy qdisc nagyon egyszer API-n keresztl
7

http://www.nsnam.org/

55

id=$RANDOM
u32="u32 match ip
tc qdisc add dev
tc class add dev
tc filter add dev
tc qdisc add dev

dst 192.168.1.1 match ip dport 80 0xffff"

eth0 root
handle 1:
htb
eth0 parent 1:
classid 1:$id htb rate 1Mbit
eth0 parent 1:
$u32 flowid 1:$id
eth0 parent 1:$id
netem delay 10ms

4.2. bra. Plda a tc parancs hasznlatra

kommunikl a kernellel. Amikor egy hlzati interfszen egy csomagot kell kikldeni, a kernel az interfszhez tartoz qdisc-nek adja t a csomagot, majd kzvetlenl
ezutn prbl annyi csomagot kivenni a qdisc-bl, amennyit a hlzati driver elfogad. A hlzati driver ltal egyszerre elfogadott adatmennyisg fgg a hlzat
sebessgtl s a bels buffereinek mrettl. Egy qdisc teht egy bels logikval
rendelkez buffernek tekinthet a hlzati driver s a kernel kztt. Ebbl is ltszik,
hogy a tc segtsgvel csak a kimen forgalom manipullhat, de a hlzati krnyezet
szimullshoz ez is elg.
A legegyszerbb qdisc a FIFO (First In First Out) elven mkd pfifo s bfifo
qdisc. A klnbsg mindssze annyi, hogy az egyik meghatrozott mennyisg csomagot, a msik meghatrozott sszmret csomagot kpes egyszerre trolni. Ha
nincs tbb hely, akkor az adott csomagot visszautastja, s a kernel eldobja azt.
Lteznek osztlyoz (classful) qdisc-ek is. Ezek bels szerkezete olyan, hogy osztlyokat tartalmaznak, amikhez egy-egy jabb qdisc rendelhet hozz. Az ilyen sorbanllsi mdokhoz mindig tartoznak n. filterek, amik azt hatrozzk meg, hogy
egy j bejv csomagot melyik osztlyhoz kell hozzrendelni. Amikor egy osztlyoz
qdisc-tl a kernel csomagot kr, az a bels logikjnak megfelelen dnti el, hogy
melyik osztlybl vesz ki csomagot. Az egyik ilyen osztlyoz qdisc a prio qdisc,
aminl az egyes osztlyokhoz prioritsok rendelhetek. Amikor a kernel csomagot
kr egy prio qdisc-tl, akkor az elszr a legmagasabb priorits osztlyt (illetve
az ahhoz tartoz qdisc-et) prblja kirteni. Ha onnan nem kap elg csomagot, a
msodik legmagasabb priorits osztllyal folytatja, s gy tovbb.
A felhasznlhat svszlessg befolysolsra alkalmas a HTB (Hierarchical Token
Buffer) qdisc. Ez egy olyan osztlyoz qdisc, ami az egyes osztlyokhoz tartoz
forgalom svszlessgt az osztlyhoz megadott rtkben maximlja. A csomagok
besorolst osztlyokba a fentiekben lert mdon filterek vgzik, illetve megadhat
egy alaprtelmezett osztly is. Nem elg azonban csak a svszlessg korltozst
szimullni, legalbb olyan fontos a ksleltets szimullsa is. Erre, s ms hlzati
jelensgek (pl. csomagveszts, csomagduplikls, bithibk) szimullsra alkalmas a
netem qdisc. Az utols hinyz sszetev a megfelel filter. Az u32 filter alkalmas
arra, hogy a csomagokat IP, s TCP fejllemezk szerint sorolja osztlyokba.
56

A 4.2. bra egy pldt mutat be a tc parancs hasznlatra (a 192.168.1.1:80

szerverhez kimen forgalom limitlsa 1Mbit/s-re s ksleltetse 10ms-el).
A tc-t hasznlva akr a loopback interfszen is hozhatk ltre hasonl korltozsok. Kt, loopback interfszen kommunikl program esetn mindkt fl ltal kldtt
csomagok kimen csomagknt jelennek meg az interfszen, ezrt ebben az esetben
mindkt irny szablyozhat a tc-vel. Ezt kihasznlva egy gpen is ltrehozhat
egyszer virtulis hlzat, amiben az egyes processzek kztti kommunikci paramterei szabadon bellthatk. Ez olyan mrsek esetn jelenthet csak gondot, ahol a
kommunikl processzek nagy CPU kapacitst ignyelnek. Ilyen esetben a folyamatok egymssal versengnek a szmtsi kapacitsrt, ami torzthatja az eredmnyeket,
ezrt ilyen esetben rdemes a kt folyamatot kln gpre helyezni.

4.2.2. MTU, buffermretek s egyb belltsok

A tc-t hasznlva a mrsek elvgzse sorn megjelent nhny olyan problma, ami azt
okozta, hogy a szimullt hlzat viselkedse jelentsen eltrt egy vals hlzattl.
Ezekre sikerlt megoldst tallni, amiket ebben az alfejezetben ismertetek.
A netem qdisc buffermrete alaprtelmezs szerint 1000 csomag. Ha figyelembe vesszk a loopback interfsz alaprtelmezett MTU (Maximum Transfer Unit)
rtkt, ami a Fedora Linux disztribci esetn pldul 16436, akkor knnyen kiszmolhat, hogy egy alaprtelmezett belltsokkal ltrehozott netem qdisc krlbell 16Mb adatot bufferel, ami risi rtk. Ilyen bufferels mellett a Bufferbloat [20] jelensg minden hatsa megjelenik. Mivel a TCP protokoll torldsvezrls
(congestion control) algoritmusa a csomagvesztsekre alapozva tapasztalja ki a
hlzat maximlis kapacitst, s ekkora buffer mellett soha nem trtnik csomagveszts, ez a szablyoz algoritmus nem fog megfelelen mkdni. Folyamatosan
nvelni fogja az ablakmretet (prblja megtlteni a hlzat kapacitst), s csak
akkor szleli hogy problma van, amikor nem kap idben nyugtkat az elkldtt
csomagokra. Az elkldtt rengeteg csomag ettl fggetlenl mg a bufferben van,
s az jabb kldtt csomagok csak akkor rkeznek meg, ha az sszes addigi csomag
clba rt. A felsbb rteg szmra ez a jelensg gy jelenik meg, hogy a TCP folyam
csak nagy ksleltetssel tudja a neki tadott adatokat tovbbtani.
A problma megoldshoz cskkenteni kell a netem buffermrett. Az az adatmennyisg, ami egy hasonl paramter vals csatornban egyszerre ton lehet, kiszmolhat a svszlessgnek s a ksleltetsnek szorzataknt (Bandwidth-Delay
Product, BDP). Egy szimullt csatorna akkor viselkedik teht a vals csatornhoz
hasonlan, ha a buffermrete ezzel egyenl. Mivel a netem limit paramtere csomagszmot fogad, ezrt az idelis buffermretet elszr el kell osztani az interfsz
MTU-jval, s az gy kapott csomagszmot kell tadni.
57

loopback intf.
Traffic Control, HTTP

Fjlrendszer
Webszerver szimulci

Proxy + optimalizl logika

Felvtel
Vezrls

Mrs vezrl logika

Traffic Control,
HTTP

Bngsz

Mrsi adatok
Fjlrendszer

loopback intf.
vezrls, naplzs
4.3. bra. Mrsi sszellts

A loopback interfsz esetben van nhny tovbbi fontos bellts. Az MTU mrete
egy vals hlzathoz kpest alaprtelmezs szerint tbb mint tzszeres. Ezt rdemes a
tipikus 1500-as rtkre lltani. Ezen kvl legtbbszr alaprtelmezs szerint be van
kapcsolva nhny optimalizci: TSO (Large Segment Offloading), GSO (Generic
Segmentation Offload), GRO (Generic Receive Offload) s SG (Scatter-Gather I/O).
Ezek mindegyike azt a clt szolglja, hogy a hlzati krtya hardveres gyorstst
kihasznlja. A legtbb hlzati krtya pldul kpes egy nagy TCP szegmensbl tbb
kisebb szegmens ltrehozni hardveres gyorstssal, gy tehermentestve az opercis
rendszert. Ezekkel az optimalizcikkal viszont elveszik a kontroll a hlzati forgalom
felett, s a tc nem fog megfelelen mkdni, ezrt rdemes kikapcsolni ezeket az
ethtool -K lo tso off gso off gro off sg off paranccsal.

4.3. Mrsi konfigurci

A dolgozat tmjhoz kapcsold optimalizcikhoz szksg van egy, a felhasznl
s a webszerver kztt fut HTTP proxy-ra, ami befolysolni tudja az tmen forgalmat. Mivel a weboldal betltse s nhny optimalizci is CPU-ignyes, ezrt a
mrsi konfigurciban a proxy s a kliens nem egy gpen fut. Ezzel elkerlhet az,
hogy a kt folyamat a processzoridrt versenyezzen, s ezltal torzuljon a mrsi
eredmny. Ez azzal a tovbbi elnnyel is jr, hogy teljesen kikszbli a loopback
interfszhez kthet problmkat, s a forgalom egy vals hlzaton kzlekedik. A
webszervert szimull http-box nem processzorignyes, ezrt gond nlkl futtathat
a HTTP proxy-val egy gpen.
58

A mrsi sszelltst a 4.3. bra szemllteti. Az A gpen fut egy http-box, ami
a webszerver feladatt ltja el. Ugyanezen a gpen fut egy HTTP proxy, ami az optimalizcikat implementlja, s a krseket a http-box-hoz tovbbtja. A kt folyamat
kztt a tc szimullja a hlzati kapcsolatot a loopback interfszen. A B gpen fut
a measure.js szkript, ami az aktulis hlzati viszonyok kztt elvgzi a megfelel mrseket. A kt gp kztti hlzati paramtereket a kt gp egyttmkdve
szimullja: mindkt gp a kimen forgalmat korltozza a tc hasznlatval.
A mrseket a B gpen fut shell szkript koordinlja, ami SSH-n (Secure SHell)
keresztl parancsokat futtathat a msik gpen is. A szkript a lefutsakor vgigiterl a
hlzati paramterek s optimalizcik egy halmazn: az egyes konfigurcihoz elszr belltja hlzati viszonyokat a tc hasznlatval, majd elindtja a HTTP proxyt
az A gpen a megfelel optimalizcik engedlyezsvel, vgl a measure.js hasznlatval lefuttatja a mrst. Az eredmnyeket az adott konfigurcinak megfelel
nvvel menti a fjlrendszerbe, s tblzatos formjban kirja az egyes konfigurcikhoz tartoz tlagos betltsi idket s szrsokat.

4.4. Feldolgozs, sszehasonlts

Egy-egy mrs elvgzsekor rengeteg feldolgozsra vr adat keletkezik. Minden
egyes konfigurcihoz tartozik a belltsoktl fggen 10-30 lefuts, s lefutsonknt egy-egy Network s Timeline napl, hlzati forgalom felvtel s Navigation
Timing adatsor. ltalban elg csak az tlagos, a legjobb s a legrosszabb lefutst
elmenteni, azonban ha egy mrssorozat sok hlzati konfigurcit tesztel, akkor a
keletkez naplfjlok szma mg gy is knnyen elrheti a nhny szz darabot. A feldolgozshoz ezrt elengedhetetlenek a hatkony segdeszkzk. A 2.2. pontban mr
volt sz a Chromium-rl s a Wrieshark-rl. Ezek a naplfjlok elemzsnl nagyon
hasznos eszkzk, de ezek mellett nhny sajt fejleszts programot is hasznltam
a mrsek kirtkelshez. Ebben az alfejezetben ezeket a segdeszkzket mutatom
be rviden.

4.4.1. HTTP alap hlzati forgalom vizualizcija

A hlzati forgalom elemzsnl a Wireshark egyik eszkze a 2.3. brn lthat IO
Graph. Ennl a diagram tpusnl legfeljebb t szr adhat meg, emiatt nem lehet
egy diagramon brzolni az sszes HTTP lekrdezs rszesedst. Mivel fontosnak
tartottam a hlzati forgalomnak ezt a szempontjt vizualizlni, sajt eszkzket
ksztettem a problma megoldsra.
A vgleges megoldsig tbb iterci utn jutottam el. Az els vizualizl program
a Chromium Network log adatait hasznlta fel, s olyan halmozott oszlop diag59

Felhasznlt svszlessg [kbit/s]

3500
3000
2500
2000
1500
1000
500
0
0

10

20

30

40

50
60
Id [0.1s]

70

80

90

100

4.4. bra. Az origo.hu IO diagramja HTTP krsenknti bontsban

ramot brzolt, amin a downstream irny hlzati forgalom lthat, s minden

HTTP vlasz kln sznnel van jellve. Erre mutat egy pldt a 4.4. bra. Ennek a
megkzeltsnek tbb htrnya is van. Az els, hogy a HTTP lekrdezsek nagy szma miatt a lekrdezsekhez tartoz oszlopokat nehz gy sznezni, hogy mindegyik
egyrtelmen megklnbztethet legyen. Ezrt a diagram leginkbb egy tblzatkezel szoftverben megtekintve hasznos, mert ott az egeret az adott oszlop fl hzva
rgtn ltszik, hogy melyik lekrdezsrl van sz. Egy msik problma az, hogy a
network napl azt mutatja meg, hogy egy-egy adatcsomag mikor jutott el a bngsz
hlzati rtegbl a fentebbi rtegekhez. Ha a bngsz CPU-intenzv szmtsokat
vgez, akkor kzben nem kr csomagokat a hlzati rtegtl, ezrt azok sszegylnek
egy bufferben, majd ezeket egyszerre kri el a bngsz. Ez magyarzza a grafikonon
megjelen magas oszlopokat.
Az utbbi problmt csak gy lehet megoldani, hogy a Network log adatai helyett
a hlzati forgalom felvtelt hasznlja fel a program. A msik problma megoldshoz a hisztogram helyett egy msik fajta megjelentst vlasztottam.
A hisztogram idrsenknt aggreglt adatokat brzol, gy egy tetszlegesen nagy
adathalmazt meg tud jelenteni kompakt mdon (az idrst megfelel mretnek
vlasztva). Mivel egy oldalletlts ltalban rvid folyamat, ezrt aggregls nlkl,
csomagonknt is megjelenthet, azaz nincs szksg a hisztogram kompaktsgra.
Egy csomag tvitele nem pontszer esemny, hanem a mretvel arnyos (s a hlzat svszlessgvel fordtottan arnyos) kiterjedse van, ezrt az id tengelyen egy
60

id

4.5. bra. Hisztogram (fell) s az egyes csomagok megjelentse (alul)

id

1.

3.

2.

4.

4.

4.

4.

4.

4.6. bra. HTTP tranzakci szakaszai (1. kapcsolat-felpts, 2. krs kldse s vrakozs, 3. vlasz rkezse), s a vlaszhoz tartoz csomag-brsztk (4.)

szakasznak feleltethet meg. Egy erre pl diagramot mutat a 4.5. bra, ahol a
csomagok egy-egy fggleges svnak feleltethetk meg. A hlzat kihasznltsgt a
svok gyakorisga s mrete alapjn lehet felmrni, krlbell olyan pontossggal,
ahogy a hisztogramrl is.
Egy ilyen csomag alap brn a valamilyen szempontbl sszetartoz csomagok
knnyen kiemelhetk sznezssel. Az egyes HTTP tranzakcik elklntsre azonban
a sznezs nmagban mg nem elegend, mert egy tlagos weboldal sokkal tbb
erforrsbl ll, mint ahny szn knnyen megklnbztethet. Ehelyett az egyes
HTTP vlaszokhoz egy-egy vzszintes svot rendeltem hozz, ami idben kijelli a
HTTP krs egyes szakaszait s a krshez tartoz csomagokat (4.6. bra).
Az egyes krsek idben rszlegesen fedhetik egymst, ezrt a krseket jelz vzszintes svokat sorokba kell rendezni. Ez all kivtelt kpeznek az azonos TCP kapcsolaton lezajl krsek, mert ezek mindig egyms utn kvetkeznek. Emiatt az
sszes HTTP tranzakcit magba foglal brn az egy TCP kapcsolathoz tartoz
krseket egy sorba rendeztem, gy minden krsrl megllapthat, hogy melyik
szlon zajlott le, s hogy ugyanazon a szlon mg milyen krsek voltak.
A HTTP krsekhez tartoz metaadatokat kt mdon lehet megjelenteni. Papr
alap brnl a fggsgi grfhoz hasonlan az egyes lekrdezseket rdemes sor61

szmozni, s egy kln tblzatban megadni a krsekhez tartoz metaadatokat.

Szmtgpes megjelents esetn jobb mdszer a tooltip ablak hasznlata, ami
akkor jelenik meg, amikor az egr az adott krs felett van.
sszefoglalva, az ltalam hasznlt megolds elemei:

a vzszintes tengely az idt jelenti

az bra a szerver-kliens irny (downstream) hlzati forgalmat jelenti meg
a csomagok az tviteli idnek megfelel szlessg fggleges svok
a csomagok sznezhetk TCP kapcsolat, HTTP vlasz, domain nv, vagy tartalom tpus szerint
a HTTP krsek vzszintes svok, amik kiemelik a hozzjuk tartoz csomagokat, s a tranzakci egyes szakaszait
a krsek sorokba vannak rendezve, amik egy-egy TCP szlnak felelnek meg
a krsek metaadatai szmozssal vagy felugr ablakokkal jellhetk
A lert vizualizcis mdszert egy nylt forrskd webalkalmazsknt valstottam meg, ami a http://molnarg.github.io/http-vis/ cmen rhet el. A 4.7.
bra az origo.hu letltst brzolja az elbb bemutatott mdszerrel. Ugyanez az
bra a program weboldaln egyszeren betlthet mint pldafelvtel.

4.4.2. Egy optimalizci hatsa

Egy optimalizci hatsnak vizsglatnl ssze lehet hasonltani egy optimalizcival s egy optimalizci nlkl kszlt Timeline adatsort. Erre a Chromium nem
biztost eszkzket, ezrt egy egyszer szkriptet rtam a problma megoldsra. A
klnbsg vizualizcijn az ltszik, hogy mely lekrdezsek kezddtek hamarabb,
tartottak rvidebb ideig vagy vrakoztak kevesebbet a vlaszra. Erre a diagram tpusra mutat pldt a 4.8. bra, ami egy statikus elemzssel mkd eltlt proxy
hatst mutatja.

62

63
4.7. bra. Az origo.hu letltse egy 1Mbit-es kapcsolaton

4.5. Prototpus
A dinamikus elemzst hasznl eltlt HTTP proxy prototpust a node.js platformon, JavaScript nyelven implementltam. Az elkszlt program kt virtulis bngszt futtat, s segtsgkkel a proxy szerverbe tlti le az elrejelzett tartalmakat.
A prototpus klienshez men forgalmat kpes priorizlni is.

4.5.1. Virtulis bngszk

A dinamikus elemzsnek azon rszt nem implementltam, ami az informcihinyos krsek kezelst oldja meg. Ehelyett a kt bngszt a prototpus ugyanabban
a virtulis krnyezetben futtatja, amit a kliens is hasznl, s emiatt ugyanazokat
a krseket generljk, gy nem fordulnak el problms krsek. Implementltam
viszont az eltlt gyorsttrat, s a virtulis bngszk eltt lev szr logikt,
ami csak az azonos krseket engedi tovbb.
A gyakorlatban val hasznlathoz olyan bngszre van szksg, ami kpes grafikus fellet nlkl, minl kevesebb erforrst felhasznlva futni. Tbb ilyen headless
bngsz implementci is ltezik (pl. PhantomJS8 ). A prototpusban elszr a
PhantomJS-t hasznltam, de ksbb Chromium-ra cserltem, mert annak a hlzati rtege jobban optimalizlt, s gy gyorsabban kpes elrejelzseket adni.
A proxy-hoz egy ilyen virtulis bngsz gy kapcsoldhat, hogy a proxy a visszacsatols interfszen (linuxon lo interfsz) egy vletlenszer porton elkezdi a bejv
HTTP lekrdezseket figyelni, majd a bngszt gy indtja el, hogy ezt a portot
HTTP proxy-knt hasznlja. Az gy a ltrejv bngszfolyamat minden HTTP krse a proxyban fut eltlt logikn megy keresztl, s az vgrehajtja a szksges
szrst, gyorsttrazst s tovbbtst.

4.5.2. Priorizls
Egy priorizlst hasznl optimalizci implementcija kt egymstl fggetlen
egysgbl ll: a prioritsokat meghatroz logikbl s a priorizlst megvalst
rszbl.
Az els egysget a prototpus esetn egy elre meghatrozott lista helyettesti,
amit a 3.2.3. pontban ismertetett heurisztika alapjn lltottam ssze az origo.hu
weboldalhoz.
A msodik egysghez kt klnbz implementcit ksztettem. Az els a SPDY
protokoll beptett priorizl kpessgt hasznlja fel, mg a msodik a HTTP krsekhez tartoz TCP kapcsolatokat manipullja, gy egy olyan klienssel is kom8

http://phantomjs.org/

64

Klnbsg [ms]
-1800 -1600 -1400 -1200 -1000

-800

-600

-400

-200

200

400

600

800 1000

1
2
3
4
5
6
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
103
104
105
109
110
111
115
116
117
118
119
120
121
122
124

Induls
Vrakozs
Fogads

Lekrdezs sorszma

4.8. bra. Klnbsg egy optimalizlt s egy optimalizlatlan oldalbetlts kztt

65

patibilis, ami nem tmogatja a SPDY protokollt. A node.js SPDY implementcija

azonban jelenleg csak egy nagyon kezdetleges temez implementcival rendelkezik,
emiatt a priorizlsnak nem volt rdemi hatsa.
A TCP kapcsolatokat manipull mdszert alkalmazs szinten implementltam.
Ez azt jelenti, hogy a program a TCP kapcsolatokrl rkez visszajelzsek alapjn
dnti el, hogy mikor rja ki a kapcsolatokhoz tartoz adatfolyamokba az adatokat.
A TCP adatfolyamok egyetlen visszajelzst tudnak adni, ami jelzi, hogy van-e mg
szabad hely a bels adatpufferkben. Ha az alkalmazs gyorsabb temben rja az
adatokat, mint ahogy a hlzat kpes elkldeni azokat, akkor a puffer megtelik,
majd lassan jra kirl. Ez az egy visszajelzs azonban elg egy priorizl algoritmus megvalstshoz. A mdszer alapja, hogy mindig csak a legnagyobb priorits
vlaszhoz tartoz adatot lehet kirni. Az rst kt esemny llthatja le: elfogy az
adat, vagy a folyam puffere megtelik. Az els esetben tovbb lehet lpni a kvetkez
prioritsi szintre, a msodik esetben fel kell fggeszteni az rst addig, amg jra fel
nem szabadul valamennyi puffer hely. Az algoritmus teht a kvetkez:
1.
2.
3.
4.

Vlaszd ki a legnagyobb priorits, kirand adattal rendelkez folyamot.

Kezdd el kirni az adatokat a kivlasztott folyamba.
Ha elfogynak az ehhez a folyamhoz tartoz adatok, akkor lpj az 1. pontra.
Ha a folyam adatpuffere megtelik, akkor fggeszd fel az adatok rst. Amikor
a folyam jelzi, hogy jra szabad, akkor lpj az 1. pontra.

Ez az algoritmus viszonylag j priorizlst tesz lehetv, de sok esetben nem

hatkony. A legnagyobb problma, hogy a TCP kapcsolatok szmnak nvekedsvel
romlik a hatkonysga. Fontos paramter ugyanis az, hogy sszesen mennyi puffer
van az alkalmazs, s a hlzat kztt. Sok TCP kapcsolat esetn ez megn, ami
intuitvan azt jelenti, hogy az alkalmazs csak ezen a nagy bufferen keresztl fr
hozz a hlzathoz, s gy kevsb tarthatja kontroll alatt a kimen adatfolyamot.
Egy ennl hatkonyabb priorizls implementcinak valamelyik alacsonyabb hlzati rtegben kell mkdnie. Egy ilyen implementcihoz hasznlhat lenne pldul a Linux Traffic Control gy, hogy a szablyrendszert az alkalmazs folyamatosan
az aktulis TCP folyamokhoz igaztja.
A priorizls hatsa jl ltszik a letltsi folyamat IO grafikonjn (4.9. bra). A f
klnbsg a szkriptek letltse utni szakadk mretnek cskkense. Ezt az okozza, hogy a bngsz a szkripteket rgtn a megrkezsk utn tudja futtatni, mert a
priorizls miatt sorrendben rkeznek, s nem kell megvrni tbb, rossz sorrendben
rkez szkript letltst, amiket azutn egyms utn futtatnia kell. Alapveten ez
a brszts CPU terhels okozta azt, hogy egy ideig nem indtott a bngsz jabb
lekrdezseket. A priorizls mkdse a krsenknt lebontott IO diagramon el66

4.9. bra. Az origo.hu IO diagramja a priorizls alkalmazsa eltt s utn

3
4

5
6

7
8

9
10

11

1.5
1
0.5
0
1.5
1
0.5
0

0s

1s

2s

3s

4s

4.10. bra. Rszlet az origo.hu IO diagramjbl HTTP krsenknti bontsban priorizls nlkl s priorizlssal

s szakaszn (4.10. bra) is ellenrizhet. Jl ltszik, hogy az egyes krsek kztt

sokkal kevesebb az tfeds, s megvltozott a sorrend az eredeti diagramhoz kpest.

4.6. Mrsi eredmnyek

A mrsek futtatsakor azt is figyelembe vettem, hogy a hlzati tvitel milyen
protokollon (HTTP vagy SPDY) zajlik, s hogy az tvitel tmtrtett vagy tmrtetlen. A mrseket minden esetben gy vgeztem, hogy a hlzati paramterek
kzl egy kivlasztott paramter egy intervallumon futott vgig, a tbbi hlzati paramter vltozatlan volt. Az egyes hlzati konfigurcikhoz az eltlts, protokoll
s tmrts minden kombincijt lemrtem.

67

Felhasznlt svszlessg [Mbit/s]

1
2

15
SPDY+PC
HTTP+PC
SPDY+C
HTTP+C

14
13

Betltsi id [s]

12
11
10
9
8

SPDY+P
HTTP+P
SPDY
HTTP

7
6

20

60

80

100

SPDY+P
HTTP+P
SPDY

40
Nyeresg a sima HTTP-hez kpest [%]

40

20

40

60

80

100

60

80

100

SPDY+PC
HTTP+PC
SPDY+C

30

20

10

0
0

20

40

60

80

100

20

40

Szerver-proxy ksleltets [ms]

4.11. bra. Az origo betltsi ideje (fell) s az optimalizcik nyeresge (alul) SPDY,
eltlts (P), valamint tmrts (C) hasznlatval. A szerver-proxy svszlessg 50Mbit. A kliens-proxy ksleltets 50ms, a svszlessg 1Mbit.

68

17
SPDY+PC
HTTP+PC
SPDY+C
HTTP+C

16
15

Betltsi id [s]

14
13
12
11
10
9
SPDY+P
HTTP+P
SPDY
HTTP

8
7
6

20

60

80 100 120 140 160

20

SPDY+P
HTTP+P
SPDY

40
Nyeresg a sima HTTP-hez kpest [%]

40

40

60

80 100 120 140 160

SPDY+PC
HTTP+PC
SPDY+C

30

20

10

-10

20

40

60

80 100 120 140 160

20

40

60

80 100 120 140 160

Kliens-proxy ksleltets [ms]

4.12. bra. Az origo betltsi ideje (fell) s az optimalizcik nyeresge (alul) SPDY,
eltlts (P), valamint tmrts (C) hasznlatval. A kliens-proxy svszlessg 1Mbit. A szerver-proxy ksleltets 50ms, a svszlessg 50Mbit.

69

Betltsi id [s]

21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5

SPDY+P
HTTP+P
SPDY
HTTP

SPDY+P
HTTP+P
SPDY

50
Nyeresg a sima HTTP-hez kpest [%]

SPDY+PC
HTTP+PC
SPDY+C
HTTP+C

SPDY+PC
HTTP+PC
SPDY+C

40

30

20

10

0
0

Kliens-proxy svszlessg [Mbit/s]

4.13. bra. Az origo betltsi ideje (fell) s az optimalizcik nyeresge (alul) SPDY,
eltlts (P), valamint tmrts (C) hasznlatval. A kliens-proxy ksleltets 50ms. A szerver-proxy ksleltets 50ms, a svszlessg 50Mbit.

70

5. fejezet
sszefoglals
A diplomamunkmban a webes teljestmnyoptimalizls tmakrnek rvid bemutatsa utn egy j, kzvettk ltal hasznlhat optimalizcikat javasoltam, majd
ennek hatsossgt egy prototpus implementcival elvgzett mrs-sorozat segtsgvel igazoltam.
Ezek az optimalizcik az elterjedt statikus elemzs helyett dinamikus elemzst
hasznlnak, ami a felhasznl ltal futtatott bngsz viselkedst az eddigi mdszereknl pontosabban kpes elrejelezni. A szakirodalomban fellelhet megoldsok
ltalban a felhasznl viselkedsnek elrejelzsre alapoznak, ezzel szemben az
ltalam javasolt algoritmus csak akkor indul el, amikor a felhasznl egy j weboldalra navigl, s a bngsz az els HTTP lekrdezst elindtja. Ennek ellenre ha a
HTTP proxy internetkapcsolata elg gyors, akkor az elrhet nyeresg ahhoz hasonl, mintha a felhasznl viselkedst sikeresen elrejelezte volna egy algoritmus. Az
alkalmazott mdszer egyik elnye az, hogy ily mdon a feleslegesen letlttt (a felhasznl ltal nem krt) adatmennyisg minimalizlhat, ami egy fontos szempont
a szk keresztmetszet mobil hlzatok esetn.
A virtulis bngszk hasznlatval trtn eltlts bemutatsa sorn rszletesen megvizsgltam azt is, hogy a HTTP krsek mellkhatsait hogyan lehet felmrni mg azeltt, hogy a krs kikerlne a hlzatra. A mellkhatsokkal rendelkez
HTTP krsek kezelsre kidolgozott, eltlt implementcik ltal hasznlhat szablyrendszer a dolgozat egyik f eredmnye. A virtualis bngszkre s priorizlsra
alapul mdszerek a meglev eltlt megoldsok s a szakirodalom ismeretben
ttrnek szmtanak, ezekre szabadalmi eljrst kezdemnyeztnk.
A prototpus kifejlesztse, valamint a mrs-sorozat elksztse s elvgzse sorn sok olyan jrahasznlhat eszkzt hoztam ltre, amiket aztn nylt forrskd
projektknt publikltam, ezltal mindenki szmra elrhetek. Ezek jl kiegsztik a
bngszk beptett fejleszti eszkzeinek s a hlzati forgalom vizsglatra hasznlhat szoftverek kpessgeit.
71

Tovbbi kutats trgyt kpezi a mdszer azon kpessgeinek mrsi eredmnyekkel val igazolsa, amiket a prototpusban az egyszersg kedvrt egyelre nem
implementltam. Ilyen a kliensbe val eltlts s a problms krsek kezelse.
Emellett a mellkhatsokra vonatkoz megllaptsokat fel lehet hasznlni tovbbi,
eltltssel kapcsolatos optimalizcik kidolgozshoz.

72

Ksznetnyilvnts
Szretnm megksznni a konzulenseim, dr. Mihly Attila s dr.Vida Rolland munkjt, akik a dolgozat rsa sorn mindvgig hasznos tancsokkal lttak el. Ksznm
tovbb Papp Zsfinak, hogy a szveget rengetegszer tolvasta, s a magyar nyelv
helyes hasznlatban segtsgemre volt.

73

74

brk jegyzke
1.1. A Webkit bngszmotor f folyamata . . . . . . . . . . . . . . . . .

1.2. A HTML5 parser modelje [4] . . . . . . . . . . . . . . . . . . . . . . .

1.3. Plda weboldal: 1.html . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4. A weboldal betltse speculative parsing optimalizci hasznlata

nlkl (fell), illetve hasznlatval (alul) . . . . . . . . . . . . . . . .

1.5. Az origo.hu fggsgi grfja . . . . . . . . . . . . . . . . . . . . . . . 12

2.1. Chromium Network panel . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2. Chromium Timeline panel . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3. Wireshark IO graph. A webszerver az 5555-s porton fut, a szrk a
forgalom kt irnyt vlasztjk szt. . . . . . . . . . . . . . . . . . . . 22
2.4. Felhasznli modell alapja a weben . . . . . . . . . . . . . . . . . . . 24
2.5. Padmanabhan s Mogul modellje . . . . . . . . . . . . . . . . . . . . 26
2.6. Egy tlagos weboldal mretnek vltozsa 1995 s 2012 kztt . . . . 28
2.7. HTML kd kls hivatkozssal, s begyazva . . . . . . . . . . . . . . 28
3.1. Az origo betltsi ideje a svszlessg s a ksleltets fggvnyben

. 35

3.2. Az eltlts ltal elrhet nyeresg . . . . . . . . . . . . . . . . . . . 35

3.3. Az eltlt bels felptse . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4. A kliens s az eltlt ltal indtott krsek . . . . . . . . . . . . . . . 37
3.5. A kliensbe val eltltssel elrhet nyeresg a szerverbe val eltltshez kpest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1. Az origo.hu eredeti s mdostott vltozatnak szrsa . . . . . . . . 55
4.2. Plda a tc parancs hasznlatra . . . . . . . . . . . . . . . . . . . . . 56
4.3. Mrsi sszellts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4. Az origo.hu IO diagramja HTTP krsenknti bontsban . . . . . . . 60
4.5. Hisztogram (fell) s az egyes csomagok megjelentse (alul) . . . . . 61
4.6. HTTP tranzakci szakaszai (1. kapcsolat-felpts, 2. krs kldse s
vrakozs, 3. vlasz rkezse), s a vlaszhoz tartoz csomag-brsztk
(4.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
75

4.7. Az origo.hu letltse egy 1Mbit-es kapcsolaton . . . . . . . . . . . . .

4.8. Klnbsg egy optimalizlt s egy optimalizlatlan oldalbetlts kztt
4.9. Az origo.hu IO diagramja a priorizls alkalmazsa eltt s utn . . .
4.10. Rszlet az origo.hu IO diagramjbl HTTP krsenknti bontsban
priorizls nlkl s priorizlssal . . . . . . . . . . . . . . . . . . . .
4.11. Az origo betltsi ideje (fell) s az optimalizcik nyeresge (alul)
SPDY, eltlts (P), valamint tmrts (C) hasznlatval. A szerverproxy svszlessg 50Mbit. A kliens-proxy ksleltets 50ms, a svszlessg 1Mbit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.12. Az origo betltsi ideje (fell) s az optimalizcik nyeresge (alul)
SPDY, eltlts (P), valamint tmrts (C) hasznlatval. A kliensproxy svszlessg 1Mbit. A szerver-proxy ksleltets 50ms, a svszlessg 50Mbit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.13. Az origo betltsi ideje (fell) s az optimalizcik nyeresge (alul)
SPDY, eltlts (P), valamint tmrts (C) hasznlatval. A kliensproxy ksleltets 50ms. A szerver-proxy ksleltets 50ms, a svszlessg 50Mbit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

63
65
67
67

68

69

70

Irodalomjegyzk
[1] David Bau: Random seeds, coded hints, and quintillions. 2010. janur. http://davidbau.com/archives/2010/01/30/random_seeds_coded_
hints_and_quintillions.html.
[2] M. Belshe R. Peon M. Thomson A. Melnikov: Hypertext transfer protocol version 2.0 - working draft, 2013. may. http://http2.github.io/
http2-spec/.
[3] Mike Belshe Roberto Peon: SPDY Protocol - Draft 3, 2012. http://www.
chromium.org/spdy/spdy-protocol/spdy-protocol-draft3.
[4] Robin
Berjon Travis
Leithead Erika
Doyle
Navara Edward
OConnor Silvia Pfeiffer: HTML5: A vocabulary and associated APIs
for HTML and XHTML, 2012. oktber. http://www.w3.org/TR/2012/
WD-html5-20121025/.
[5] Laura Bottomley: Epa-http server logs, 1995. aug. http://ita.ee.lbl.gov/
html/contrib/EPA-HTTP.html.
[6] Christos Bouras Agisilaos Konidaris: Predictive prefetching on the web and its
potential impact in the wide area. World Wide Web, 7. vf. (2004), 143179. p.
[7] Flavio Chierichetti Ravi Kumar Prabhakar Raghavan Tamas Sarlos: Are
web users really markovian? In Proceedings of the 21st international conference on World Wide Web, WWW 12 konferenciasorozat. New York, NY, USA,
2012, ACM, 609618. p. ISBN 978-1-4503-1229-5.
URL http://doi.acm.org/10.1145/2187836.2187919. 10 p.
[8] Chrome developer tools: Remote debugging protocol v1.0, 2012. prilis.
https://developers.google.com/chrome-developer-tools/docs/
protocol/1.0/index.
[9] Edith Cohen Haim Kaplan: Prefetching the means for document transfer: a
new approach for reducing web latency. Computer Networks, 39. vf. (2002) 4.
77

sz., 437455. p.
URL http://dblp.uni-trier.de/db/journals/cn/cn39.html#CohenK02a.
[10] Dave Crane Phil McCarthy: Comet and Reverse Ajax: The Next-Generation
Ajax 2.0. 2008, Apress. ISBN 1590599985, 9781590599983.
[11] Douglas Crockford: Introducing JSON. http://www.json.org/.
[12] Brian D. Davison: Assertion: Prefetching with get is not good, 2001.
[13] Brian D. Davison: Learning web request patterns, 2004.
[14] ECMAScript Language Specification, Edition 5.1, 2011. jnius. http://www.
ecma-international.org/publications/standards/Ecma-262.htm.
[15] R. Fielding J. Gettys J. Mogul H. Frystyk L. Masinter P. Leach T. Berners-Lee: RFC2616 hypertext Transfer Protocol HTTP/1.1,
1999. jnius. http://www.w3.org/TR/2012/WD-html5-20121025/.
[16] R. Fielding M. Nottingham J. Reschke: Hypertext Transfer Protocol (HTTP/1.1): Caching, 2013. februr. http://www.ietf.org/id/
draft-ietf-httpbis-p6-cache-22.txt.
[17] R. Fielding M. Nottingham J. Reschke: Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content, 2013. februr. http://tools.ietf.org/
html/draft-ietf-httpbis-p2-semantics-22.
[18] Justin Force: Add Stable Merge Sort to Array and jQuery prototypes.
2011.
oktber.
http://splatoperator.com/2011/10/
add-stable-merge-sort-to-array-and-jquery-prototypes/.
[19] Tali Garsiel: How browsers work. http://taligarsiel.com/Projects/
howbrowserswork1.htm.
[20] Jim
Gettys:
The
criminal
mastermind:
bufferbloat!
2010.
december.
http://gettys.wordpress.com/2010/12/03/
introducing-the-criminal-mastermind-bufferbloat/.
[21] Steven D. Gribble: Uc berkely home ip http traces, 1996. nov. http://ita.ee.
lbl.gov/html/contrib/UCB.home-IP-HTTP.html.
[22] James Griffioen Randy Appleton: Reducing file system latency using a predictive approach. 1994, 197207. p.
78

[23] Ilya Grigorik: Chrome networking: Dns prefetch & tcp preconnect,
2012.
jun.
http://www.igvita.com/2012/06/04/
chrome-networking-dns-prefetch-and-tcp-preconnect/.
[24] Ian Hickson: The WebSocket API, 2012. szeptember. http://www.w3.org/TR/
2012/CR-websockets-20120920/.
[25] Ken ichi Chinen: Www collector - the prefetching proxy server for www, 1994.
http://www.jaist.ac.jp/~k-chinen/pg/wcol/.
[26] Bob Ippolito: Remote JSON - JSONP, 2005. dec. http://bob.ippoli.to/
archives/2005/12/05/remote-json-jsonp/.
[27] Thomas M. Kroeger Darrell D. E. Long Jeffrey C. Mogul: Exploring the bounds of web latency reduction from caching and prefetching, 1997.
[28] Link prefetching faq, 2003. mar. https://developer.mozilla.org/en-US/
docs/Link_prefetching_FAQ.
[29] Tong Sau Loon Vaduvur Bharghavan Tong Sau Loon Vaduvur Bharghavan:
Alleviating the latency and bandwidth problems in www browsing. In Proceedings of the 1997 USENIX Symposium on Internet Technology and Systems
(konferenciaanyag). 1997, 219230. p.
[30] Patrick Meenan: How Fast is Your Web Site? Queue, 11. vf. (2013. mrcius)
2. sz., 60:6060:70. p. ISSN 1542-7730. http://queue.acm.org/detail.cfm?
id=2446236.
[31] Venkata N. Padmanabhan Jeffrey C. Mogul: Using predictive prefetching to
improve world wide web latency. COMPUTER COMMUNICATION REVIEW,
26. vf. (1996), 2236. p.
[32] E. Rescorla: RFC2818 HTTP Over TLS, 2000. mjus. http://www.w3.org/
TR/2012/WD-html5-20121025/.
[33] Mark Russinovich David A. Solomon: Windows Internals: Including Windows
Server 2008 and Windows Vista, Fifth Edition. 5th. kiad. 2009, Microsoft Press.
ISBN 0735625301, 9780735625303.
[34] Richard M. Smith: The Web Bug FAQ, 1999. nov. http://w2.eff.org/
Privacy/Marketing/web_bug.html.
[35] Steve Souders: Moving beyond window.onload(), 2013. may. http://www.
stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/.
79

[36] StatCounter: Top 5 Browsers on May 2013, 2012. december. http://gs.

statcounter.com/#browser-ww-monthly-201305-201305-bar.
[37] Jeffrey Scott Vitter P. Krishnan: Optimal prefetching via data compression,
1995.
[38] Zhiheng Wang: Navigation timing API, 2012. jlius. http://dvcs.w3.org/hg/
webperf/raw-file/tip/specs/NavigationTiming/Overview.html.
[39] WebPagetest documentation - Speed Index. https://sites.google.com/a/
webpagetest.org/docs/using-webpagetest/metrics/speed-index.
[40] websiteoptimization.com webportl: Average web page size triples since 2008, 2012. nov. http://www.websiteoptimization.com/speed/tweak/
average-web-page/.

80

81

Fggelk
F.1. Az origo.hu fggsgi grfjhoz tartoz erforrsok
#

URL

000

http://origo.hu/

001

http://www.origo.hu/index.html

002

http://static.origos.hu/s/20120130/js/cimlap/season.js

003

http://static.origos.hu/s/20121010/js/cimlap/cimlap11_min.js

004

http://static.origos.hu/s/20110831/js/kozos/origolib_min.js

005

http://static.origos.hu/s/20110831/js/cimlap/jquery.jcarousel.js

006

http://static.origos.hu/s/201109/js/kozos/jquery-1.5.1.min.js

007

http://ad.adverticum.net/g3.js

008

http://static.origos.hu/s/20110831/js/cimlap/dataCollector_ctag_cookie2customtarget.js

009

http://static4.origos.hu/s/20120914/css/cimlap/cimlap11-dev.css

010

http://static.origos.hu/s/20110910/js/kozos/xgemius.js

011

http://ad.adverticum.net/scripts/goa3/main/2.3.4/goa3.js

012

http://www.google-analytics.com/ga.js

013

http://static4.origos.hu/s/1235/img/cimlap/hirdetes-vertical.png

014

http://static3.origos.hu/s/img/idojaras/cimlap/Brief_d7_32.png

015

http://static2.origos.hu/images/cimlap/new/ok-keresd.gif

016

http://static8.origos.hu/i/1210/20121015-delkina-yangshuo-kinai-halasz-kormorannal1.jpg

017

http://static6.origos.hu/i/1210/20121012-l8217aquila-2009es-foldrenges-romok-osszedolt-hazak
.jpg

018

http://static5.origos.hu/i/1210/20121015-a-pletykafeszek-gossip-girl.jpg

019

http://static1.origos.hu/i/1208/201208161.jpg

020

http://static4.origos.hu/s/1235/img/cimlap/freemail-enter-bg.png

021

http://static4.origos.hu/s/1235/img/cimlap/iwiw-enter-bg.png

022

http://static4.origos.hu/s/1235/img/cimlap/sprites.png

023

http://static3.origos.hu/s/20110824/img/cimlap/static.png

024

http://static4.origos.hu/s/1235/img/cimlap/search-bg.png

025

http://static4.origos.hu/s/1235/img/cimlap/search-bgs.png

026

http://static2.origos.hu/i/1210/20121012-egy-no-viragot-visz-hozzatartozoja.jpg

027

http://static5.origos.hu/i/1210/20121015-chrysta-bell3.jpg

028

http://static4.origos.hu/s/1235/img/cimlap/keres-bent-bg.png

029

http://static.origos.hu/s/img/cimlap/lenia.png

030

http://ww392.smartadserver.com/call/adif/123920/1393318/Origo_HU.betclic/625x30/[timestamp]/n
o?[countgo]

031

http://static4.origos.hu/s/1235/img/cimlap/social-enter-bg.png

032

http://static4.origos.hu/s/img/cimlap/blog-video-ikon.png

033

http://static4.origos.hu/i/1210/201210152.gif

034

http://static4.origos.hu/s/1235/img/cimlap/nav-bg.png

035

http://static4.origos.hu/s/1235/img/cimlap/megtobb-icon.png

036

http://static4.origos.hu/s/1235/img/cimlap/kevesebb-icon.png

037

http://static4.origos.hu/s/1235/img/cimlap/weyer-vonal.png

038

http://static4.origos.hu/s/1235/img/cimlap/news-bullet.png

039

http://static4.origos.hu/s/1235/img/cimlap/topstory_bottom.png

040

http://ad.adverticum.net/js.prm?zona=2130011&ord=93122804

82

URL

041

http://static4.origos.hu/s/1235/img/cimlap/rate-bg.png

042

http://static4.origos.hu/s/1235/img/cimlap/up-icon.png

043

http://static4.origos.hu/s/1235/img/cimlap/down-icon.png

044

http://static4.origos.hu/s/1235/img/cimlap/rate-bottom.png

045

http://static4.origos.hu/s/1235/img/cimlap/kep-icon.png

046

http://static4.origos.hu/s/1235/img/cimlap/sport-bg.png

047

http://static4.origos.hu/s/2347/img/szponzoraciok/betclick/cimlap_betclick.jpg

048

http://static4.origos.hu/s/1235/img/cimlap/video-icon.png

049

http://static4.origos.hu/s/img/cimlap/cimlap-life-bg.png

050

http://static4.origos.hu/s/1235/img/cimlap/life-logo.png

051

http://static4.origos.hu/s/1235/img/cimlap/legfriss-bg.png

052

http://static4.origos.hu/s/1235/img/cimlap/miez-icon.png

053

http://static.origos.hu/s/012/img/cimlap/postr-szponz.png

054

http://audit.median.hu/cgi-bin/track.cgi?uc=12828368072738&dc=1&ui=10577@s=1366x768@u=htt
p%3A//www.origo.hu/index.html@r=

055

http://hu.hit.gemius.pl/_1344358980000/rexdot.gif?l=30&id=.cA7Mm7_HEhW_ocRqQjuTbeO71wwEy
eu..OM_r0BuyD.y7&fr=1&fv=-&tz=-120&href=http%3A//www.origo.hu/index.html&ref=&screen=1366
x768&col=24

056

http://static4.origos.hu/s/1235/img/cimlap/news-comment.png

057

http://static4.origos.hu/s/1235/img/cimlap/news-share.png

058

http://ad.adverticum.net/detect.js

059

http://static4.origos.hu/s/1235/img/cimlap/postr-logo.png

060

http://static4.origos.hu/s/1235/img/cimlap/postr-blog-bg.png

061

http://static4.origos.hu/s/img/cikk/ad-bullet-a53342.png

062

http://static4.origos.hu/s/1235/img/cimlap/photo-in-bg.png

063

http://static4.origos.hu/s/12356/img/cimlap/mediagroup-logo.png

064

http://static.origos.hu/s/012/img/cimlap/postr-szponz-csoki.png

065

http://static.origos.hu/s/1235/img/cimlap/apro-logo.png

066

http://static.origos.hu/s/1235/img/cimlap/apro-fl-bg.png

067

http://static.origos.hu/s/1235/img/cimlap/apro-bottom.png

068

http://static.origos.hu/s/1235/img/cimlap/apro-bg.png

069

http://static.origos.hu/s/1235/img/cimlap/apro-reload.png

070

http://static4.origos.hu/s/1235/img/cimlap/footer-irjon.png

071

http://static4.origos.hu/s/1235/img/cimlap/footer-rss.png

072

http://ww392.smartadserver.com/a/diff/392/1393318/ishow7.asp?1393318;123920;0;[timestamp]
;M;systemtarget=%24a%3D0t%3B%24cn%3DHU_05%3B%24isp%3D0%3B%24qc%3D1312528198%3B%24ql%3Dun
known%3B%24qpc%3D1191%3B%24qpp%3D0%3B%24qt%3D194_1573_9941t%3B%24b%3D16230%3B%24o%3D9999

073

http://hu.hit.gemius.pl/__/_1344358980000/rexdot.gif?l=30&id=.cA7Mm7_HEhW_ocRqQjuTbeO71ww
Eyeu..OM_r0BuyD.y7&fr=1&fv=-&tz=-120&href=http%3A//www.origo.hu/index.html&ref=&screen=13
66x768&col=24

074

http://static4.origos.hu/s/1235/img/cimlap/footer-archivum.png

075

http://static4.origos.hu/s/1235/img/cimlap/footer-mobil.png

076

http://static.origos.hu/i/1209/20120905-bankkartya.jpg

077

http://static4.origos.hu/s/1235/img/cimlap/footer-cimke.png

078

http://static4.origos.hu/s/1235/img/cimlap/footer-hirlevel.png

079

http://static.origos.hu/i/1109/20110913napelemna.jpg

080

http://static.origos.hu/i/1210/20121015-falusi.jpg

081

http://static4.origos.hu/s/1235/img/cimlap/footer-border.png

082

http://static4.origos.hu/s/1235/img/cimlap/boutique-bg.png

083

http://static4.origos.hu/s/0819/img/cimlap/sprites.png

084

http://ww392.smartadserver.com/diff/392/1393318/show7.asp?1393318;123920;0;[timestamp];M
;systemtarget=%24a%3D0t%3B%24cn%3DHU_05%3B%24isp%3D0%3B%24qc%3D1312528198%3B%24ql%3Dunkn
own%3B%24qpc%3D1191%3B%24qpp%3D0%3B%24qt%3D194_1573_9941t%3B%24b%3D16230%3B%24o%3D9999

085

http://ww392.smartadserver.com/a/track/jsinfo.asp?sw=1920&sh=1080

086

http://ww392.smartadserver.com/a/track/jsinfo.asp?sw=1366&sh=768

087

http://ww392.smartadserver.com/shim.gif

83

URL

088

http://ad.adverticum.net/z?s=JSONP&p=eyJoIjoid3d3Lm9yaWdvLmh1IiwicSI6IiIsInUiOiJodHRwOi8
vd3d3Lm9yaWdvLmh1L2luZGV4Lmh0bWwiLCJkIjp7ImwiOiJodSIsImsiOnsiMTIiOjIsIjI0IjoxLCI1NSI6MSw
iMjA1IjoxLCJvcmlnbyI6MiwiLSI6MiwibWFneWFyb3JzesOhZyI6MSwicGlhY3ZlemV0xZEiOjEsInBvcnTDoWx
qYSI6MSwibGVnZnJpc3NlYmIiOjF9LCJjIjpudWxsLCJyIjoiIn0sImNUIjpudWxsLCJsY1QiOmZhbHNlLCJwSSI
6NDUxNDY3MjIzNjk1NzQ4NTQwLCJzIjpudWxsLCJ0RCI6e319&c=eyJ0Ijp7fSwidiI6IjIuMy40IiwiYiI6eyJ3Z
WJraXQiOnRydWUsInNhZmFyaSI6dHJ1ZX0sImJWIjoiNTM2LjExIiwiYkwiOiJodSIsImJQIjp7ImphdmEiOjAsI
mZsYXNoIjpudWxsLCJzbCI6MH0sInMiOnsidyI6MTM2NiwiaCI6Njc5LCJkIjoyNCwibVciOjEzNjYsIm1IIjo3N
jh9fQ%3D%3D&z=eyJ6Ijp7IjM1NzI2Ijp7InAiOjgwfSwiMzU3MjgiOnsicCI6NDB9LCIzNTc2OSI6eyJwIjo5MH0
sIjE2MTcyMTYiOnsicCI6MTAwfSwiMTYzMTc0NiI6eyJwIjo1MH0sIjE2MzE3NDciOnsicCI6MTB9LCIxNjMxNzQ
4Ijp7InAiOjMwfSwiMTYzMTc0OSI6eyJwIjoyMH0sIjE2MzE3NTAiOnsicCI6MTV9LCIxODU2OTUwIjp7InAiOjl
9LCIxODU3NjQzIjp7InAiOjh9LCIxODU3NjUyIjp7InAiOjd9LCIxODY4NTMyIjp7InAiOjUwfX19&cb=_jqjsp

089

http://ad.adverticum.net/external/2098585.html?goa3&v&externalhost=%2F%2Fad.adverticum.ne
t%2Fexternal&statichost=%2F%2Fad.adverticum.net%2Fbanners&location=%2F%2Fad.adverticum.ne
t%2Fbanners%2F2098575%2F&target=_blank&timestamp=1344358980000&referer=&referer.e=&cthre
f=http%3A%2F%2Fad.adverticum.net%2FC%2F35726%2F2098638%2F209858500%2F451467223695748540%
2Fwww.origo.hu%2F2098579%3Fu%3D121015844378521&cthref.e=http%253A%252F%252Fad.adverticum
.net%252FC%252F35726%252F2098638%252F209858500%252F451467223695748540%252Fwww.origo.hu%2
52F2098579%253Fu%253D121015844378521&zone=35726&goal=2098638&banner=2098585&pageiid=45146
7223695748540&PAGEIID=451467223695748540&LOCATION=www.origo.hu&l=www.origo.hu&ord=4514672
23695748540&uniqueID=451467223695748540&imgpre=%2F%2Fad.adverticum.net%2Fbanners%2F209857
5%2F&zona=35726&kampany_id=2098638&UNIQUEID=121015844378521&url%3A2098579=http%3A%2F%2Fad
.adverticum.net%2FC%2F35726%2F2098638%2F209858500%2F451467223695748540%2Fwww.origo.hu%2F
2098579%3Fu%3D121015844378521&url.e%3A2098579=http%253A%252F%252Fad.adverticum.net%252FC%
252F35726%252F2098638%252F209858500%252F451467223695748540%252Fwww.origo.hu%252F2098579%
253Fu%253D121015844378521&title=Advertisement+%2335726

090

http://ad.adverticum.net/external/2114688.html?goa3&v&externalhost=%2F%2Fad.adverticum.ne
t%2Fexternal&statichost=%2F%2Fad.adverticum.net%2Fbanners&location=%2F%2Fad.adverticum.ne
t%2Fbanners%2F2114686%2F&target=_blank&timestamp=1344358980000&referer=&referer.e=&cthre
f=http%3A%2F%2Fad.adverticum.net%2FC%2F35728%2F2114695%2F211468800%2F451467223695748540%
2Fwww.origo.hu%2F2114689%3Fu%3D121015844378521&cthref.e=http%253A%252F%252Fad.adverticum
.net%252FC%252F35728%252F2114695%252F211468800%252F451467223695748540%252Fwww.origo.hu%2
52F2114689%253Fu%253D121015844378521&zone=35728&goal=2114695&banner=2114688&pageiid=45146
7223695748540&PAGEIID=451467223695748540&LOCATION=www.origo.hu&l=www.origo.hu&ord=4514672
23695748540&uniqueID=451467223695748540&imgpre=%2F%2Fad.adverticum.net%2Fbanners%2F211468
6%2F&zona=35728&kampany_id=2114695&UNIQUEID=121015844378521&url%3A2114689=http%3A%2F%2Fad
.adverticum.net%2FC%2F35728%2F2114695%2F211468800%2F451467223695748540%2Fwww.origo.hu%2F
2114689%3Fu%3D121015844378521&url.e%3A2114689=http%253A%252F%252Fad.adverticum.net%252FC%
252F35728%252F2114695%252F211468800%252F451467223695748540%252Fwww.origo.hu%252F2114689%
253Fu%253D121015844378521&title=Advertisement+%2335728

091

http://ad.adverticum.net/external/2107758.html?goa3&v&externalhost=%2F%2Fad.adverticum.ne
t%2Fexternal&statichost=%2F%2Fad.adverticum.net%2Fbanners&location=%2F%2Fad.adverticum.ne
t%2Fbanners%2F2107720%2F&target=_blank&timestamp=1344358980000&referer=&referer.e=&cthre
f=http%3A%2F%2Fad.adverticum.net%2FC%2F35769%2F2107766%2F210775800%2F451467223695748540%
2Fwww.origo.hu%2F2107751%3Fu%3D121015844378521&cthref.e=http%253A%252F%252Fad.adverticum
.net%252FC%252F35769%252F2107766%252F210775800%252F451467223695748540%252Fwww.origo.hu%2
52F2107751%253Fu%253D121015844378521&zone=35769&goal=2107766&banner=2107758&pageiid=45146
7223695748540&PAGEIID=451467223695748540&LOCATION=www.origo.hu&l=www.origo.hu&ord=4514672
23695748540&uniqueID=451467223695748540&imgpre=%2F%2Fad.adverticum.net%2Fbanners%2F210772
0%2F&zona=35769&kampany_id=2107766&UNIQUEID=121015844378521&url%3A2107751=http%3A%2F%2Fad
.adverticum.net%2FC%2F35769%2F2107766%2F210775800%2F451467223695748540%2Fwww.origo.hu%2F
2107751%3Fu%3D121015844378521&url.e%3A2107751=http%253A%252F%252Fad.adverticum.net%252FC%
252F35769%252F2107766%252F210775800%252F451467223695748540%252Fwww.origo.hu%252F2107751%
253Fu%253D121015844378521&title=Advertisement+%2335769

092

http://ad.adverticum.net/external/tracking/2104902_tr.html

093

http://ctag.hu/dc/cs?p30=35726-2098585-2098638%2C35728-2114688-2114695%2C35769-2107758-2
107766%2C1631746-2141253-2141255%2C1631747-2108307-2042515%2C1631748-2104902-2104936%2C1
631749-1922598-1922631%2C1856950-1900206-1900214%2C1857643-1860601-1860603%2C1857652-186
0606-1860608%2C&p12=ADV-tag-o-cimlap&p13=451467223695748540&p26=1103035954090651194202

84

URL

094

http://ad.adverticum.net/z?s=JSONP&p=eyJoIjoid3d3Lm9yaWdvLmh1IiwicSI6IiIsInUiOiJodHRwOi8
vd3d3Lm9yaWdvLmh1L2luZGV4Lmh0bWwiLCJkIjp7ImwiOiJodSIsImsiOnsiMTIiOjIsIjI0IjoxLCI1NSI6MSw
iMjA1IjoxLCJvcmlnbyI6MiwiLSI6MiwibWFneWFyb3JzesOhZyI6MSwicGlhY3ZlemV0xZEiOjEsInBvcnTDoWx
qYSI6MSwibGVnZnJpc3NlYmIiOjF9LCJjIjpudWxsLCJyIjoiIn0sImNUIjpudWxsLCJsY1QiOmZhbHNlLCJwSSI
6NDUxNDY3MjIzNjk1NzQ4NTQwLCJzIjpbMzU3NjksMjEwNzc2NiwxNjM3MjI1LDIxMDc3MjAsMjEwNzc1ODAwLDI
xMDc3NTEsMTYzMTc0NiwyMTQxMjU1LDE3NzA2MzEsMjE0MTI0NSwyMTQxMjUzMDAsMjE0MTI0NiwzNTcyNiwyMDk
4NjM4LDE2MDc4OTgsMjA5ODU3NSwyMDk4NTg1MDAsMjA5ODU3OSwxNjMxNzQ4LDIxMDQ5MzYsMTYwNzg5OCwyMDk
4Njg4LDIxMDQ5MDIwMCwyMTA0OTAzLDE2MzE3NDksMTkyMjYzMSwxNTk0NDc1LDE5MjI0NzksMTkyMjU5ODAwLDI
wODY0NjUsMzU3MjgsMjExNDY5NSwxNzI3MjM4LDIxMTQ2ODYsMjExNDY4ODAwLDIxMTQ2ODksMTYzMTc0NywyMDQ
yNTE1LDE1OTQ5NjQsMjA0MjQ4OSwyMTA4MzA3MDAsMjA0MjQ5NiwxODU2OTUwLDE5MDAyMTQsMTYwNzgwNSwxODY
wNTQ4LDE5MDAyMDYwMCwxOTAwMjA3LDE4NTc2NDMsMTg2MDYwMywxNjA3ODA1LDE4NjA1NDgsMTg2MDYwMTAwLDE
4NjA2MDIsMTg1NzY1MiwxODYwNjA4LDE2MDc4MDUsMTg2MDU0OCwxODYwNjA2MDAsMTg2MDYwN10sInREIjp7fX0
%3D&c=eyJjIjp7InUiOiIxMjEwMTU4NDQzNzg1MjEiLCJoIjoiY2F0di04MC05OS01MC0yMTkuY2F0di5icm9hZGJ
hbmQuaHUiLCJzIjoxMzUwMjUyMDAwMDAwfSwidCI6e30sInYiOiIyLjMuNCIsImIiOnsid2Via2l0Ijp0cnVlLCJ
zYWZhcmkiOnRydWV9LCJiViI6IjUzNi4xMSIsImJMIjoiaHUiLCJiUCI6eyJqYXZhIjowLCJmbGFzaCI6bnVsbCw
ic2wiOjB9LCJzIjp7InciOjEzNjYsImgiOjY3OSwiZCI6MjQsIm1XIjoxMzY2LCJtSCI6NzY4fX0%3D&z=eyJ6Ijp
7IjE2NzE3MjciOnsicCI6NzB9fX0%3D&cb=_jqjsp

095

http://ad.adverticum.net/banners/2141245//0002141247.jpg

096

http://ad.adverticum.net/banners/2042489//0002108265.jpg

097

http://ad.adverticum.net/banners/1860548//0002073256.jpg

098

http://ad.adverticum.net/banners/1860548//0001860560.jpg

099

http://ad.adverticum.net/banners/1860548//0002034636.jpg

100

http://ad.adverticum.net/scripts/external.js

101

http://ad.adverticum.net/scripts/doDocWrite.js

102

http://ad-emea.doubleclick.net/ad/N5971.156445.ORIGO.HU/B6884366.18;sz=1x1;ord=[timestam
p]?

103

http://ad.adverticum.net/scripts/gwloader.js

104

http://ad.adverticum.net/external/2111709.html?goa3&v&externalhost=%2F%2Fad.adverticum.ne
t%2Fexternal&statichost=%2F%2Fad.adverticum.net%2Fbanners&location=%2F%2Fad.adverticum.ne
t%2Fbanners%2F2111660%2F&target=_blank&timestamp=1344358980000&referer=&referer.e=&cthre
f=http%3A%2F%2Fad.adverticum.net%2FC%2F1671727%2F2111662%2F211170900%2F45146722369574854
0%2Fwww.origo.hu%2F2111703%3Fu%3D121015844378521&cthref.e=http%253A%252F%252Fad.advertic
um.net%252FC%252F1671727%252F2111662%252F211170900%252F451467223695748540%252Fwww.origo.
hu%252F2111703%253Fu%253D121015844378521&zone=1671727&goal=2111662&banner=2111709&pageiid
=451467223695748540&PAGEIID=451467223695748540&LOCATION=www.origo.hu&l=www.origo.hu&ord=4
51467223695748540&uniqueID=451467223695748540&imgpre=%2F%2Fad.adverticum.net%2Fbanners%2F
2111660%2F&zona=1671727&kampany_id=2111662&UNIQUEID=121015844378521&url%3A2111703=http%3A
%2F%2Fad.adverticum.net%2FC%2F1671727%2F2111662%2F211170900%2F451467223695748540%2Fwww.o
rigo.hu%2F2111703%3Fu%3D121015844378521&url.e%3A2111703=http%253A%252F%252Fad.adverticum.
net%252FC%252F1671727%252F2111662%252F211170900%252F451467223695748540%252Fwww.origo.hu%
252F2111703%253Fu%253D121015844378521&title=Advertisement+%231671727

105

http://ctag.hu/dc/cs?p30=1671727-2111709-2111662%2C&p12=ADV-tag-o-cimlap&p13=45146722369
5748540&p26=1103035954090651194202

106

http://kwuxodsaud/

107

http://iscympnino/

108

http://bxplutxezu/

109

http://ad.adverticum.net/scripts/goAdverticum1.25.js

110

http://s0.2mdn.net/viewad/2468712/1x1.gif

111

http://pbid.fxdepo.com/engine?site=131821;size=728x90;linktarget=_blank;mimetype=js;rnd
=(randomNumber)

112

http://huomdgde.adocean.pl/_1344358980000/ad.js?id=1cgMoXCk7YSfB8SI195Q.XHNToLfL1snpD4u8X
t_EhL.W7/redir=http://ad.adverticum.net/C/35728/2114695/211468800/451467223695748540/www
.origo.hu/2114689?u=121015844378521&ct0=

113

http://hugde.adocean.pl/_1344358980000/ad.js?id=xeWcRY.v7PJPiGP2cdGWgkxq31jedC7mmDwXwAP8p
13.m7/redir=http://ad.adverticum.net/C/1671727/2111662/211170900/451467223695748540/www.o
rigo.hu/2111703?u=121015844378521&ct0=

114

http://ad-emea.doubleclick.net/adi/N5971.156445.ORIGO.HU/B6884366.3;sz=250x250;ord=134435
8980000?

85

URL

115

http://hugde.adocean.pl/*/_1344358980000/ad.js?id=xeWcRY.v7PJPiGP2cdGWgkxq31jedC7mmDwXwA
P8p13.m7/redir=http://ad.adverticum.net/C/1671727/2111662/211170900/451467223695748540/w
ww.origo.hu/2111703?u=121015844378521&ct0=

116

http://huomdgde.adocean.pl/*/_1344358980000/ad.js?id=1cgMoXCk7YSfB8SI195Q.XHNToLfL1snpD4u
8Xt_EhL.W7/redir=http://ad.adverticum.net/C/35728/2114695/211468800/451467223695748540/w
ww.origo.hu/2114689?u=121015844378521&ct0=

117

http://ad.doubleclick.net/noidadi/N5971.156445.ORIGO.HU/B6884366.3;sz=250x250;ord=1344358
980000?

118

http://ghu.hit.gemius.pl/_1344358980000/redot.gif?id=d6ZKtsu9s96g2Y6VcaFBM5bx.D5sHNhpiD.d
mGNBsyv.Q7/fastid=2305843009233898309/stparam=kmniqxfkmy

119

http://hugde.adocean.pl/files/js/billboard_gao_lib.js

120

http://huomdgde.adocean.pl/files/js/billboard_gao_lib.js

121

http://huomdgde.hit.gemius.pl/_1344358980000/redot.gif?id=nGfldoinZQHoIxmoD3dMdrbtzbt8jNu
Wr3MxI2aQ.9P.87/fastid=2305843009233913121/stparam=qffpolphda

122

http://c1135878.r78.cf3.rackcdn.com/dc_ad_135085.js?tracker=http://ad.doubleclick.net/cli
ck%3Bh%3Dv8/3d0f/3/0/%2a/w%3B261733406%3B0-0%3B0%3B85870605%3B237-250/250%3B50082985/5007
2813/1%3B%3B%7Esscs%3D%3f&cb=7238969

123

http://ads4.fxdepo.com/ads/02/52/71/27_252166LeverageAdvantage_br2_728x90_hun.jpg

124

http://c1135878.r78.cf3.rackcdn.com/ad_image_135085.gif

125

http://ctag.hu/dc/js/DataCollector.js?p4=http&p5=www.origo.hu&p6=%2Findex.html&p12=tag-o
-cimlap&p13=451467223695748540&p14=1366&p15=679&p17=4000&p24=null&p26=1103035954090651194
202&p27=2.1.4.sp0&p29=null&p32=&p33=&p36=

86