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 Nyilatkozat Kivonat Abstract 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III VII IX XI 1 3 3 4 6 7 7 9

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. Trac Control . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.2. MTU, buermretek s egyb belltsok . . . . . . . . . . . . 57 4.3. Mrsi kongurci . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Ksznetnyilvnts brk jegyzke Irodalomjegyzk

71 73 75 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 dene 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 amplied 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 dierent view of the same process, and dierent means to inuence 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 veried 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 kongurcijval. 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

HTML parser

DOM Tree

Layout

Attachment

Render Tree

Painting

Stylesheets

CSS parser

Style rules

Display

1.1. bra. A Webkit bngszmotor f folyamata

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 reow vagy layout algoritmus ezen hatsok gyelembe 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 denilja 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 denci 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 bug nak (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 prol 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 prol 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 denilt esemny, amit az sszes bngsz hasonlan implementl. Valjban azonban nem ilyen egyszer a betltsi id dencija 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 gyelembe 18

vve dolgoztak ki: alapja a felhasznl ltal lthat tartalom vltozsa az id elrehaladtval, egszen az oldalbetlts vgig. A Speed Index dencija 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:
end

S=
0

1 c(t)dt

(2.1)

A Speed Index mrse azonban nem egyszer: pontosan denilni 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 grakus 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 2

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/

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 reow/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 gyelembe kell venni a felvtellel jr processzorterhelst is, mert befolysolhatja a mrs rdemi rszt vgz processzeket. A tcpdump gy is kongurlhat, 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 kongurcis 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 nonhttps://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 9

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 meggyelst 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 home.html 0.5 0.2 about.html

0.5

0.9 image2.gif

0.01

2.5. bra. Padmanabhan s Mogul modellje

meggyeli, 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 nomhangolni. 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 gyelik 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

1200 Erforrsok sszmrete (kbyte) 1000 800 600 400 200 0 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 Erforrsok sszmrete Erforrsok szma

120 100 80 60 40 20 0 Erforrsok szma

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 tradeo 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 le 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
http://www.chromium.org/spdy/link-headers-and-server-hint/ link-rel-subresource
14

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 gyelmen 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 11 Betltsi id [s] 10 9 8 7 6 5 4 10 20 30 40 50 60 Ksleltets [ms] 70 80 1Mbit/s 1.5Mbit/s 2.3Mbit/s 3.4Mbit/s 5Mbit/s 90 100

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

20 Elrhet nyeresg [%]

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

15

10

0
20+10 40+10 60+10 80+10 20+20 40+20 60+20 80+20

Kliens-proxy + proxy-webszerver ksleltets [ms]

3.2. bra. Az eltlts ltal elrhet nyeresg

35

Eltlt Proxy cache Kliens Eltlt gyorsttr

3.3. bra. Az eltlt bels felptse

Webszerver

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 gyelembe 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 Felesleges Helyes Rossz

Kliens krsek

Elszalasztott

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 identied 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 congured 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 denilja a biztonsgos lekrdezseket (kiemels tlem): 4.2.1. Safe Methods Request methods are considered safe if their dened 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 denition of safe methods does not prevent an implementation from including behavior that is potentially harmful, not entirely read-only, or which causes side-eects 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 les 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-eect of charging an advertising account. Of the request methods dened by this specication, the GET, HEAD, OPTIONS, and TRACE methods are dened 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 eective request URI have the eect 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- eects 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 gyelmet, 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 gyelhet 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 gyelmen 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 gyelembe 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 15 Elrhet nyeresg [%] 2.5Mbit/s 3.5Mbit/s 5Mbit/s

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 gyelembe, 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 kongurci 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 gyelembe 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. Kongurlhat 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 prolt 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 felldenilhatk futsidben. A vletlen szm generlst vgz Math.random() fggvny pldul felldenilhat 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 felldenilhatk, 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 felldenilsa. 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 denilja 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
A kapcsold Chromium hibajegy: http://code.google.com/p/chromium/issues/detail? id=883
6

54

1200 1000 800 Szrs [ms] 600 400 200 0 Eredeti Mdostott

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 Trac Control (tc) kpessgre esett.

4.2.1. Trac 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 buereinek mrettl. Egy qdisc teht egy bels logikval rendelkez buernek 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 pfo s bfo 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. lterek, 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 Buer) 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 lterek 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 lter. Az u32 lter 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, buermretek 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 buermrete alaprtelmezs szerint 1000 csomag. Ha gyelembe 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 buerel, ami risi rtk. Ilyen buerels mellett a Buerbloat [20] jelensg minden hatsa megjelenik. Mivel a TCP protokoll torldsvezrls (congestion control) algoritmusa a csomagvesztsekre alapozva tapasztalja ki a hlzat maximlis kapacitst, s ekkora buer 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 buerben 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 buermrett. 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 buermrete ezzel egyenl. Mivel a netem limit paramtere csomagszmot fogad, ezrt az idelis buermretet elszr el kell osztani az interfsz MTU-jval, s az gy kapott csomagszmot kell tadni. 57

Fjlrendszer A Felvtel Vezrls Webszerver szimulci

loopback intf. Trac Control, HTTP Proxy + optimalizl logika

Trac Control, HTTP

B Mrsi adatok Fjlrendszer

Mrs vezrl logika

Bngsz 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 Ooading), GSO (Generic Segmentation Ooad), GRO (Generic Receive Ooad) 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 kongurci

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 kongurciban 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 kongurcihoz 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 kongurcinak megfelel nvvel menti a fjlrendszerbe, s tblzatos formjban kirja az egyes kongurcikhoz tartoz tlagos betltsi idket s szrsokat.

4.4. Feldolgozs, sszehasonlts

Egy-egy mrs elvgzsekor rengeteg feldolgozsra vr adat keletkezik. Minden egyes kongurcihoz 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 kongurcit 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

3500 Felhasznlt svszlessg [kbit/s] 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 buerben, majd ezeket egyszerre kri el a bngsz. Ez magyarzza a grakonon 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.

2.

3.

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 grakus 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 gyelni, 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 0
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

200

400

600

800 1000

Induls Vrakozs Fogads

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

Lekrdezs sorszma

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 adatpuerkben. Ha az alkalmazs gyorsabb temben rja az adatokat, mint ahogy a hlzat kpes elkldeni azokat, akkor a puer 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 puere 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 puer 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 adatpuere 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 puer van az alkalmazs, s a hlzat kztt. Sok TCP kapcsolat esetn ez megn, ami intuitvan azt jelenti, hogy az alkalmazs csak ezen a nagy bueren 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 Trac Control gy, hogy a szablyrendszert az alkalmazs folyamatosan az aktulis TCP folyamokhoz igaztja. A priorizls hatsa jl ltszik a letltsi folyamat IO grakonjn (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

1 2

3 4

5 6

7 8

9 10

11

Felhasznlt svszlessg [Mbit/s]

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 gyelembe 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 kongurcikhoz az eltlts, protokoll s tmrts minden kombincijt lemrtem.

67

15 14 13 12 Betltsi id [s] 11 10 9 8 7 6 SPDY+P HTTP+P SPDY HTTP

0 20 40 60 80 100 0 20 40 60 80 100

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

40 Nyeresg a sima HTTP-hez kpest [%]

SPDY+P HTTP+P SPDY

SPDY+PC HTTP+PC SPDY+C

30

20

10

0
0 20 40 60 80 100 0 20 40 60 80 100

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 16 15 14 Betltsi id [s] 13 12 11 10 9 8 7 6
0 20

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

SPDY+P HTTP+P SPDY HTTP

40 60 80 100 120 140 160 0 20 40 60 80 100 120 140 160

40 Nyeresg a sima HTTP-hez kpest [%]

SPDY+P HTTP+P SPDY

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

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

SPDY+P HTTP+P SPDY HTTP

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

Betltsi id [s]

50 Nyeresg a sima HTTP-hez kpest [%]

SPDY+P HTTP+P SPDY

SPDY+PC HTTP+PC SPDY+C

40

30

20

10

0
0 1 2 3 4 5 6 0 1 2 3 4 5 6

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 Zsnak, 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) . . . . . . . . . . . . . . . . 3 5 8 9

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63 65 67 67

68

69

70

76

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 Pfeier: 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 Specication, 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: buerbloat! 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 Grioen Randy Appleton: Reducing le 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 Jerey 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 Jerey 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] Jerey 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
# 000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 URL http://origo.hu/ http://www.origo.hu/index.html http://static.origos.hu/s/20120130/js/cimlap/season.js http://static.origos.hu/s/20121010/js/cimlap/cimlap11_min.js http://static.origos.hu/s/20110831/js/kozos/origolib_min.js http://static.origos.hu/s/20110831/js/cimlap/jquery.jcarousel.js http://static.origos.hu/s/201109/js/kozos/jquery-1.5.1.min.js http://ad.adverticum.net/g3.js http://static.origos.hu/s/20110831/js/cimlap/dataCollector_ctag_cookie2customtarget.js http://static4.origos.hu/s/20120914/css/cimlap/cimlap11-dev.css http://static.origos.hu/s/20110910/js/kozos/xgemius.js http://ad.adverticum.net/scripts/goa3/main/2.3.4/goa3.js http://www.google-analytics.com/ga.js http://static4.origos.hu/s/1235/img/cimlap/hirdetes-vertical.png http://static3.origos.hu/s/img/idojaras/cimlap/Brief_d7_32.png http://static2.origos.hu/images/cimlap/new/ok-keresd.gif http://static8.origos.hu/i/1210/20121015-delkina-yangshuo-kinai-halasz-kormorannal1.jpg http://static6.origos.hu/i/1210/20121012-l8217aquila-2009es-foldrenges-romok-osszedolt-hazak .jpg http://static5.origos.hu/i/1210/20121015-a-pletykafeszek-gossip-girl.jpg http://static1.origos.hu/i/1208/201208161.jpg http://static4.origos.hu/s/1235/img/cimlap/freemail-enter-bg.png http://static4.origos.hu/s/1235/img/cimlap/iwiw-enter-bg.png http://static4.origos.hu/s/1235/img/cimlap/sprites.png http://static3.origos.hu/s/20110824/img/cimlap/static.png http://static4.origos.hu/s/1235/img/cimlap/search-bg.png http://static4.origos.hu/s/1235/img/cimlap/search-bgs.png http://static2.origos.hu/i/1210/20121012-egy-no-viragot-visz-hozzatartozoja.jpg http://static5.origos.hu/i/1210/20121015-chrysta-bell3.jpg http://static4.origos.hu/s/1235/img/cimlap/keres-bent-bg.png http://static.origos.hu/s/img/cimlap/lenia.png http://ww392.smartadserver.com/call/adif/123920/1393318/Origo_HU.betclic/625x30/[timestamp]/n o?[countgo] http://static4.origos.hu/s/1235/img/cimlap/social-enter-bg.png http://static4.origos.hu/s/img/cimlap/blog-video-ikon.png http://static4.origos.hu/i/1210/201210152.gif http://static4.origos.hu/s/1235/img/cimlap/nav-bg.png http://static4.origos.hu/s/1235/img/cimlap/megtobb-icon.png http://static4.origos.hu/s/1235/img/cimlap/kevesebb-icon.png http://static4.origos.hu/s/1235/img/cimlap/weyer-vonal.png http://static4.origos.hu/s/1235/img/cimlap/news-bullet.png http://static4.origos.hu/s/1235/img/cimlap/topstory_bottom.png http://ad.adverticum.net/js.prm?zona=2130011&ord=93122804

82

# 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055

URL http://static4.origos.hu/s/1235/img/cimlap/rate-bg.png http://static4.origos.hu/s/1235/img/cimlap/up-icon.png http://static4.origos.hu/s/1235/img/cimlap/down-icon.png http://static4.origos.hu/s/1235/img/cimlap/rate-bottom.png http://static4.origos.hu/s/1235/img/cimlap/kep-icon.png http://static4.origos.hu/s/1235/img/cimlap/sport-bg.png http://static4.origos.hu/s/2347/img/szponzoraciok/betclick/cimlap_betclick.jpg http://static4.origos.hu/s/1235/img/cimlap/video-icon.png http://static4.origos.hu/s/img/cimlap/cimlap-life-bg.png http://static4.origos.hu/s/1235/img/cimlap/life-logo.png http://static4.origos.hu/s/1235/img/cimlap/legfriss-bg.png http://static4.origos.hu/s/1235/img/cimlap/miez-icon.png http://static.origos.hu/s/012/img/cimlap/postr-szponz.png 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= 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 http://static4.origos.hu/s/1235/img/cimlap/news-comment.png http://static4.origos.hu/s/1235/img/cimlap/news-share.png http://ad.adverticum.net/detect.js http://static4.origos.hu/s/1235/img/cimlap/postr-logo.png http://static4.origos.hu/s/1235/img/cimlap/postr-blog-bg.png http://static4.origos.hu/s/img/cikk/ad-bullet-a53342.png http://static4.origos.hu/s/1235/img/cimlap/photo-in-bg.png http://static4.origos.hu/s/12356/img/cimlap/mediagroup-logo.png http://static.origos.hu/s/012/img/cimlap/postr-szponz-csoki.png http://static.origos.hu/s/1235/img/cimlap/apro-logo.png http://static.origos.hu/s/1235/img/cimlap/apro-fl-bg.png http://static.origos.hu/s/1235/img/cimlap/apro-bottom.png http://static.origos.hu/s/1235/img/cimlap/apro-bg.png http://static.origos.hu/s/1235/img/cimlap/apro-reload.png http://static4.origos.hu/s/1235/img/cimlap/footer-irjon.png http://static4.origos.hu/s/1235/img/cimlap/footer-rss.png 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 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 http://static4.origos.hu/s/1235/img/cimlap/footer-archivum.png http://static4.origos.hu/s/1235/img/cimlap/footer-mobil.png http://static.origos.hu/i/1209/20120905-bankkartya.jpg http://static4.origos.hu/s/1235/img/cimlap/footer-cimke.png http://static4.origos.hu/s/1235/img/cimlap/footer-hirlevel.png http://static.origos.hu/i/1109/20110913napelemna.jpg http://static.origos.hu/i/1210/20121015-falusi.jpg http://static4.origos.hu/s/1235/img/cimlap/footer-border.png http://static4.origos.hu/s/1235/img/cimlap/boutique-bg.png http://static4.origos.hu/s/0819/img/cimlap/sprites.png 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 http://ww392.smartadserver.com/a/track/jsinfo.asp?sw=1920&sh=1080 http://ww392.smartadserver.com/a/track/jsinfo.asp?sw=1366&sh=768 http://ww392.smartadserver.com/shim.gif

056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072

073

074 075 076 077 078 079 080 081 082 083 084

085 086 087

83

# 088

URL 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 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 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 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 http://ad.adverticum.net/external/tracking/2104902_tr.html 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

089

090

091

092 093

84

# 094

URL 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 http://ad.adverticum.net/banners/2141245//0002141247.jpg http://ad.adverticum.net/banners/2042489//0002108265.jpg http://ad.adverticum.net/banners/1860548//0002073256.jpg http://ad.adverticum.net/banners/1860548//0001860560.jpg http://ad.adverticum.net/banners/1860548//0002034636.jpg http://ad.adverticum.net/scripts/external.js http://ad.adverticum.net/scripts/doDocWrite.js http://ad-emea.doubleclick.net/ad/N5971.156445.ORIGO.HU/B6884366.18;sz=1x1;ord=[timestam p]? http://ad.adverticum.net/scripts/gwloader.js 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 http://ctag.hu/dc/cs?p30=1671727-2111709-2111662%2C&p12=ADV-tag-o-cimlap&p13=45146722369 5748540&p26=1103035954090651194202 http://kwuxodsaud/ http://iscympnino/ http://bxplutxezu/ http://ad.adverticum.net/scripts/goAdverticum1.25.js http://s0.2mdn.net/viewad/2468712/1x1.gif http://pbid.fxdepo.com/engine?site=131821;size=728x90;linktarget=_blank;mimetype=js;rnd =(randomNumber) 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= 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= http://ad-emea.doubleclick.net/adi/N5971.156445.ORIGO.HU/B6884366.3;sz=250x250;ord=134435 8980000?

095 096 097 098 099 100 101 102 103 104

105 106 107 108 109 110 111 112

113

114

85

# 115

URL 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= 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= http://ad.doubleclick.net/noidadi/N5971.156445.ORIGO.HU/B6884366.3;sz=250x250;ord=1344358 980000? http://ghu.hit.gemius.pl/_1344358980000/redot.gif?id=d6ZKtsu9s96g2Y6VcaFBM5bx.D5sHNhpiD.d mGNBsyv.Q7/fastid=2305843009233898309/stparam=kmniqxfkmy http://hugde.adocean.pl/files/js/billboard_gao_lib.js http://huomdgde.adocean.pl/files/js/billboard_gao_lib.js http://huomdgde.hit.gemius.pl/_1344358980000/redot.gif?id=nGfldoinZQHoIxmoD3dMdrbtzbt8jNu Wr3MxI2aQ.9P.87/fastid=2305843009233913121/stparam=qffpolphda 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 http://ads4.fxdepo.com/ads/02/52/71/27_252166LeverageAdvantage_br2_728x90_hun.jpg http://c1135878.r78.cf3.rackcdn.com/ad_image_135085.gif 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=

116

117 118 119 120 121 122

123 124 125

86