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 EgyetemVillamosmrnki s Informatikai Kar

Tvkzlsi s Mdiainformatikai Tanszk

Kliens gyorsttr hasznlatra plweb-gyorstsi megoldsok

Diplomaterv

Ksztette KonzulensekMolnr Gbor dr. Mihly Attila

dr. Vida Rolland

2013. mjus 26.

Tartalomjegyzk

Tartalomjegyzk III

Nyilatkozat VII

Kivonat IX

Abstract XI

Bevezet 1

1. Egy weboldal betltsnek folyamata 31.1. ttekints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Beolvassi algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. Erforrsok letltse . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4. Vgjtk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5. Speculative parsing optimalizci . . . . . . . . . . . . . . . . . . . . 71.6. Fggsgi grfok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6.1. A fggsgi grf megkonstrulsa . . . . . . . . . . . . . . . . 101.7. Esettanulmny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.7.1. Jellsek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.7.2. A szkriptek betltse . . . . . . . . . . . . . . . . . . . . . . . 131.7.3. A tartalom betltse s statisztikk gyjtse . . . . . . . . . . 141.7.4. A hirdetsek megjelentse . . . . . . . . . . . . . . . . . . . . 151.7.5. Tovbbi elemzs . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2. Ismert optimalizcik 172.1. Mrhet mennyisgek . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1. HTTP krsenknti mrszmok . . . . . . . . . . . . . . . . . 172.1.2. Globlis mrszmok . . . . . . . . . . . . . . . . . . . . . . . 18

2.2. Mreszkzk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.1. A bngsz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.2. tcpdump, Wireshark . . . . . . . . . . . . . . . . . . . . . . . 21

III

2.3. Optimalizcik kategorizlsa . . . . . . . . . . . . . . . . . . . . . . 222.3.1. Szereplk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.2. Hlzati rtegek . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4. Eltlts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4.1. Korai kutatsok . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4.2. Megvltozott krnyezet . . . . . . . . . . . . . . . . . . . . . . 272.4.3. Ma is hasznlt, illetve szabvnyostott megoldsok . . . . . . . 27

3. Optimalizls eltltssel egy j megkzelts 33

3.1. Eltlts a HTTP proxy-ba . . . . . . . . . . . . . . . . . . . . . . . 343.1.1. Elrhet nyeresg . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.2. Architektra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.3. Elvrsok egy eltlt implementcival szemben . . . . . . . 373.1.4. Biztonsg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.5. Statikus elemzs . . . . . . . . . . . . . . . . . . . . . . . . . 403.1.6. Dinamikus elemzs . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2. Eltlts a kliensbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2.1. A kliensbe val eltltssel elrhet nyeresg . . . . . . . . . . 453.2.2. Mdostott hidden iframe technika . . . . . . . . . . . . . . . 453.2.3. Hlzati forgalom priorizls . . . . . . . . . . . . . . . . . . . 47

4. Prototpus s mrsi eredmnyek 49

4.1. Mreszkzk s reproduklhatsg . . . . . . . . . . . . . . . . . . . 494.1.1. measure.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.1.2. http-box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.1.3. pseudo.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.1.4. Idztsi viszonyok . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2. Hlzati krnyezet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.1. Traffic Control . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.2. MTU, buffermretek s egyb belltsok . . . . . . . . . . . . 57

4.3. Mrsi konfigurci . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.4. Feldolgozs, sszehasonlts . . . . . . . . . . . . . . . . . . . . . . . 59

4.4.1. HTTP alap hlzati forgalom vizualizcija . . . . . . . . . . 594.4.2. Egy optimalizci hatsa . . . . . . . . . . . . . . . . . . . . . 62

4.5. Prototpus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.5.1. Virtulis bngszk . . . . . . . . . . . . . . . . . . . . . . . . 644.5.2. Priorizls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.6. Mrsi eredmnyek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

IV

5. sszefoglals 71

Ksznetnyilvnts 73

brk jegyzke 75

Irodalomjegyzk 77

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

V

VI

HALLGATI NYILATKOZAT

Alulrott Molnr Gbor, szigorl hallgat kijelentem, hogy ezt a diplomatervetmeg nem engedett segtsg nlkl, sajt magam ksztettem, csak a megadott forr-sokat (szakirodalom, eszkzk stb.) hasznltam fel. Minden olyan rszt, melyet szszerint, vagy azonos rtelemben, de tfogalmazva ms forrsbl tvettem, egyrtel-men, a forrs megadsval megjelltem.

Hozzjrulok, hogy a jelen munkm alapadatait (szerz, cm, angol s magyarnyelv tartalmi kivonat, kszts ve, konzulensek neve) a BME VIK nyilvnosanhozzfrhet elektronikus formban, a munka teljes szvegt pedig az egyetem belshlzatn keresztl (vagy autentiklt felhasznlk szmra) kzztegye. Kijelentem,hogy a benyjtott munka s annak elektronikus verzija megegyezik. Dkni enge-dllyel titkostott diplomatervek esetn a dolgozat szvege csak 3 v eltelte utnvlik hozzfrhetv.

Budapest, 2013. mjus 26.

Molnr Gborhallgat

VIII

Kivonat

Az elmlt vekben a web egy fontos platformm vlt. Nem sokkal ezeltt mg csakegyszer dokumentumok publiklsra hasznltk, manapsg pedig sokak szmraa tartalomfogyaszts, a kzssgi kommunikci s a vsrls egyik elsdleges hely-szne. A tartalommal egytt fejldtek a web mkdst meghatroz szabvnyok saz azokat implementl bngszk. A bngszprogramokat fejleszt cgek kzttegszsges verseny alakult ki a hasznlhatsg s a teljestmny tern, ami egyre jobbfelhasznli lmnyhez vezet. Ezt a folyamatot tovbb ersti az internetkapcsolatoksebessgnek folyamatos nvekedse.

Nem csak a bngszk, hanem az internetszolgltatk s a weboldalak tulajdono-sai is sokat javthatnak a weboldalak teljestmnyn. Mindegyik fl specilis szerepetjtszik egy weboldal letltsnek folyamatban, s olyan informcik birtokban van,ami a tbbiek szmra nem elrhet, ez pedig klnbz optimalizlsi mdszerekettesz lehetv.

Az egyik, kzvettk ltal hasznlhat mdszer a tartalmak eltltse a gyors-ttrba. Az eltlts trtnhet a kzvetthz, vagy akr kzvetlenl a klienshezis. A diplomamunkm tmja ilyen tpus optimalizcik vizsglata, valamint jmdszerek kidolgozsa s implementlsa. Megoldst keresek arra a krdsre, hogypontosan mely tartalmakat lehet eltlteni s milyen felttelek mellett, illetve meg-vizsglom a tartalom klienshez val eljuttatsra hasznlhat mdszerek elnyeit,htrnyait s teljestmny jellemzit. A kidolgozott technikkat egy prototpus se-gtsgvel, szimullt hlzati krnyezetben is letesztelem, s a hatkonysgukat amrsi eredmnyekkel igazolom.

IX

X

Abstract

The web became an important platform in the past years. Not long ago, it wasused only for publishing simple documents, and now its the primary platform ofcontent distribution, social communication and shopping for many. The content, thestandards that define the web and the browsers implementing them were developedhand in hand. There is a never ending race between browser companies to achievebetter performance and usability, and that leads to a constantly improving overalluser experience. This is amplified by the improving speed of internet connections.

But browsers are not the only player in this game. Web authors, hosting companiesand internet service providers all play special role in improving the performance anduser experience on the web. All of them have a different view of the same process,and different means to influence and improve it.

One of the methods that intermediaries can use is prefetching web content to alocal cache to make it instantly accessible when it is needed. It is also possible topush the content from the proxy to the client if needed. The topic of this thesis is theexamination of existing optimizations of this type, and exploration and implementa-tion of new type of optimizations based on it. I will answer the questions concerningthe limitations of content prefetching, and look at the advantages, disadvantagesand performance characteristics of the means of it. The new prefetch methods willbe tested and verified with a prototype implementation using a simulated network.

XI

XII

Bevezet

A dolgozat a kvetkezkppen pl fel. Az els fejezet rviden bemutatja egy web-oldal betltsnek folyamatt. Ez a fejezet minden olyan ismeretet tartalmaz, amia tbbi fejezet megrtshez szksges. A fejezet egy esettanulmnnyal zrul, amirea ksbbiekben sok plda alapul.

A msodik fejezet bevezets a webes optimalizcik vilgba. Elszr azt mutatommeg, hogy melyek azok a mrszmok, amik jl lerjk a felhasznl ltal megta-pasztalt betltsi sebessget, s emiatt az optimalizcik fontos clpontjai. Ehhezkapcsoldan rviden kitrek arra is, hogy ezeket a mennyisgeket hogyan lehet ha-tkonyan megmrni. Ezutn egy olyan szempontrendszert mutatok be, ami alapjna klnbz mdszereket csoportostani, kategorizlni lehet. A fejezet utols, s egy-ben legfontosabb rsze az eltlts alap optimalizcikrl szl. Ez tartalmazza atmval kapcsolatos kutatsok s a gyakorlatban is alkalmazott mdszerek lerst.

A harmadik fejezet az ltalam kidolgozott, eltltsre alapul optimalizcikatmutatja be. Ez kt f egysgre bonthat. Az els rsz a tartalmak proxy-ba valeltltsvel, mg a msodik a klienshez val eljuttatsukkal foglalkozik.

A negyedik fejezet a harmadik fejezetben bemutatott mdszerekhez ksztett pro-totpus implementcit s az azon elvgzett mrseket ismerteti. Itt rszletesen fog-lalkozom a mrsek reproduklhatsgnak krdsvel, a kifejlesztett mreszk-zkkel s a fellltott teszt hlzat konfigurcijval. Ezek az eszkzk nem csaka mrsek elvgzsben, hanem az egyes optimalizcik fejlesztsi folyamatban isfontos szerepet kaptak. A fejezet a mrsi eredmnyek bemutatsval zrul.

Az utols fejezet a konklzik levonsrl s a lert mdszerek lehetsges tovbb-fejlesztsrl szl.

1

2

1. fejezet

Egy weboldal betltsnek folyamata

1.1. ttekints

A bngsz elsdleges feladata HTML (HyperText Markup Language) dokumentu-mok letltse s megjelentse. A kvetkezkben Tali Garsiel lerst [19] alapul vverviden ttekintem, hogy egy modern bngsz hogyan jelent meg egy weboldalt.A f vezrfonalat az 1.1. bra szemllteti. Ez a webkit bngszmotor megjelentsifolyamatt brzolja, de a tbbi nylt forrskd bngsz is hasonl elvek alapjnmkdik. Ezek a bngszk a piac tbb mint ktharmadt fedik le [36].

A weben az egyes erforrsok URL (Uniform Resource Locator) alapjn azono-sthatk, gy egy weboldal letltst is egy URL megadsval kezdemnyezheti afelhasznl. Az URL tartalmazza a kapcsolatfelvtelhez szksges adatokat (a szer-ver domain nevt vagy IP cmt, a portot s a protokollt) s egy sztringet ami atartalmat 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 klnflemdon hivatkozhat kls erforrsokat, amik a megjelentshez szksgesek. Ezeketa bngsz a beolvassi folyamat sorn kezdi el letlteni. A leggyakoribb ilyen kls

HTML HTML parser

CSS parser

DOM Tree

Style rules

Attachment Render Tree

Layout

Display

Painting

Stylesheets

1.1. bra. A Webkit bngszmotor f folyamata

3

erforrsok a kpek, a szkriptek s a stluslapok. A HTML szabvny rgzti a beolva-ssi folyamat pontos menett, amit a kvetkez pontban rszletesebben ismertetek.A nyelvi elemzs kimenete a document objektum, ami a dokumentum aktulis lla-pott ler DOM (Document Object Model) fa gykere. A fa egyes cscsai kezdetbenegy-egy HTML tag-nek felelnek meg, ksbb azonban a HTML kdtl fggetlenlvltozhat a DOM. A cscsok elnevezse: node, element vagy elem.

A megjelents tovbbi lpseit alapveten a DOM fa s a stluslapok hatrozzkmeg. A CSS (Cascading Style Sheet) stluslapok egyszer megjelentsi utastsokattartalmaznak (pl. a httr szne legyen kk), amiket a bngsz a hozzjuk tarto-z kivlaszt kifejezsek (pl. minden cmsor) alapjn a megfelel DOM node-okhozrendel. Az gy ltrejv megjelenthet objektumokat egy msik, erre a clre opti-malizlt fban trolja (Render Tree). Ezek a megjelentend objektumok egymsrais hatssal vannak (pl. ha kt kp egyms alatt van, akkor az els magassga meg-hatrozza a msodik pozcijt). Az egyes objektumok elrendezst a reflow vagylayout algoritmus ezen hatsok figyelembe vtelvel szmolja ki. Az utols lps avizlis elemek kirajzolsa.

A folyamat egyik legfontosabb jellemzje, hogy az egyes lpsek nem szigoransorban kvetik egymst. Jobb modell az, ha az egyes folyamatok kztt csvezetkekfutnak, amiken keresztl folyamatosan rkeznek a bementi adatok, amiket feldolgoz-va az egyes folyamatok ellltjk a kimenetket. A HTML feldolgozsa pldul mrakkor elkezddik, amikor mg csak a fjl nhny darabja rkezett meg a hlzatrl.A megjelents pedig mr jval azeltt elkezddik, hogy minden hivatkozott klserforrs letltdne.

1.2. Beolvassi algoritmus

A HTML5 szabvny [4] pontosan definilja a parser ltal kvetend algoritmust(8.2. rsz: Parsing HTML documents). A folyamat magja mint a legtbb parseresetben a tokenekre bonts (amit a tokenizer vagy lexer vgez), s a fapts. Altrejv ft a HTML esetben DOM-nak nevezzk. A szabvny parser modelljnekklnlegessge, hogy lehetv teszi a szkriptek futtatst.

A web szkript nyelve a JavaScript. A nyelv futsi modellje egyszl s esemnyve-zrelt. Ez a futsi modell klnsen jl illeszkedik aszinkron mveletek (pl. hlzatilekrdezsek) kezelshez s felhasznli felletek programozshoz.

Kdok beillesztsre tbb lehetsg is van: a forrskd megadhat a HTML-begyazva, vagy hivatkozhat kls erforrsknt. A szabvny alapveten nem tesz k-lnbsget e kt varici kztt: a szkripteket (nhny ksbbiekben bemutatott kiv-teltl eltekintve) akkor kell lefuttatni, amikor a parser az adott tag-et elri.

4

A lefut szkriptnek hozzfrse van az adott ponton mr felptett DOM rszlet-hez, valamint kpes a dokumentumba HTML kdot injektlni a document.write()fggvny segtsgvel. Utbbi esetben a parsert reentrns mdon kell meghvni, hogyfeldolgozza az jonnan beszrt HTML rszletet.

Network

Byte StreamDecoder

Input StreamPreprocessor

Tokenizer

TreeConstruction

DOM

ScriptExecution

document.write()

1.2. bra. A HTML5 parser modelje [4]

Ez egy egyszer s kiszmthat mo-dell, viszont egy naiv bngsz imple-mentci esetn nagyon lass oldalbe-tltshez vezet. Amikor a parser egykls fjlknt hivatkozott szkriptet ta-ll, akkor megll, letlti a fjlt, majdlefuttatja s tovbblp. Tbb egymsutn hivatkozott szkript esetn ez egyletlts-futtats-letlts-futtats ciklus-hoz vezet, ami egy vals (nem 0 kslel-tets) hlzaton nagyon lass.

Erre kt megolds is szletett. Azegyik a bngszk ltal hasznlt specu-lative parsing optimalizci, amirl az1.5. pontban lesz rszletesebben sz. Amsik az aszinkron szkriptek hasznla-ta. Egy tag aszinkronknt je-llhet meg az async attribtum hasz-nlatval. Egy ilyen szkript nem blok-kolja a parsert, s kzvetlenl azutn futle, hogy befejezdtt a letltse.

A szkriptek futtatsn tl a parserkezdemnyezi az egyes kls erforrsokletltst is. Kls erforrs lehet pldul kp, begyazott HTML oldal (iframe),vagy CSS stluslap. Ezek nem blokkoljk a folyamatot: ltrehoznak egy-egy letltsifeladatot, amit tadnak a hlzati rtegnek. Egy esetben azonban mgis blokkolhategy stluslap betltse: mivel egy szkript lekrdezhet a mr beolvasott DOM-blolyan adatokat is, amik egy stluslaptl fggnek (pl. egy adott elem szne), ezrt akdfuttatst a tag-et megelz stluslapok betltsnek meg kell elznie.

Amikor a parser elrte a dokumentum vgt, ltrehozza a DOMContentLoadedesemnyt a document objetkumon. Kzvetlenl ez utn lefutnak a szkriptek ltalehhez az esemnyhez regisztrlt esemnykezel fggvnyek.

5

1.3. Erforrsok letltse

A bngsz hlzati rtegnek feladata, hogy a megadott URL-ekhez tartoz erfor-rsokat a megfelel protokoll hasznlatval letltse. A web legelterjedtebb tviteliprotokollja a HTTP [15] (HyperText Tranfer Protocol). Tovbb hasznlatos mg aHTTPS [32] (HTTP Secure), ami biztonsgos tviteteli rteg fltt mkdik, s aSPDY [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. Alapve-ten egy olyan krs-vlasz alap szveges protokollrl van sz, ami egy folyam-alaptviteli 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 aHost 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, mertegy adott IP cm s port prossal meghatrozott szerver tbb klnbz weboldaltis 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 szerverpedig vlaszknt ezt a fjlt kldi vissza. Erre egy plda az 1.1. tblzatban ltha-t. 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 TCPkapcsolat felptst, majd lebontst. Ez a kapcsolat felptsnek lasssga miatt(3 lpses kzfogs) alacsony teljestmnyhez vezetett, ezrt az 1.1 verzi mr lehe-tv teszi a TCP kapcsolatok jrahasznostst, teht egy vlasz megrkezse utn

6

GET /index.html HTTP/1.1 HTTP/1.1 200 OKHost: www.example.com Date: Mon, 23 May 2012 22:38:34 GMTUser-Agent: curl/7.24.0 Server: Apache/1.3.3.7 (Unix)Accept: */* Etag: "3f80f-1b6-3e1cb03b"

Accept-Ranges: noneContent-Length: 12Connection: closeContent-Type: text/plain

Hello World!

1.1. tblzat. HTTP krs s vlasz plda

a kapcsolat nyitva hagyhat s jabb krs kldhet rajta. A szabvny meghat-rozza azt is, hogy egy kliens legfeljebb 2 perzisztens TCP kapcsolatot hasznlhategy adott szerver elrsre a tlterhels elkerlse miatt, a gyakorlatban a modernbngszk ltalban 6 TCP kapcsolatot tartanak fent szerverenknt. A bngszhlzati rtegnek feladatai kz tartozik a krsek hozzrendelse az egyes TCPkapcsolatokhoz.

1.4. Vgjtk

Amikor a parser befejezte a mkdst, mg valsznleg vannak olyan erforrsok,amik nem tltdtek le teljesen. Ezeket a bngsz feladat objektumokkal reprezen-tlja 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 kategri-ba esnek. Ide tartozik gyakorlatilag minden hlzatot rint feladat, valamint avlaszok feldolgozsa s megjelentse is. Nem tartoznak ebbe a kategriba pldulaz idztk ltal ltrehozott feladatok, amik a megfelel idpontban egy esemnytfognak generlni.

Amikor az sszes ilyen betltst blokkol feladat elfogyott, a bngsz ltrehozzaa load esemnyt a dokumentum window objektumn, s rtesti a felhasznlt, hogya weboldal betltdtt. A felhasznl rtestse ltalban a betlts folyamatt jelzhomokra kurzor, illetve folyamatjelz sv elrejtst jelenti.

1.5. Speculative parsing optimalizci

A modern bngszk tbb olyan ltalnosan elterjedt mdszert is hasznlnak, amimeggyorstja a weboldalak betltst. Az egyik legfontosabb, hogy a HTML beol-vassi 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, minlhamarabb el lehessen kezdeni letlteni.

A speculative parsing hatst a kvetkez egyszer HTML pldn szemlltetem:

1.3. bra. Plda weboldal: 1.html

Mivel a szkriptek hasznlhatjk a document.write fggvnyt, a bngsz nemlehet biztos benne, hogy a HTML ltal hivatkozott minden JavaScript tnylege-sen kelleni fog. Elkpzelhet pldul, hogy az els hivatkozott szkript (2.js) adocument.write-ot hasznlva egy HTML megjegyzs jelet (

1.4. bra. A weboldal betltse speculative parsing optimalizci hasznlata nlkl (fe-ll), 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 grf-nak jl lerhat az, hogy hogyan zajlik egy weboldal betltsnek folyamata. gytalltam, hogy ez a grf nem csak betlts folyamatnak karakterizlsa miatt fon-tos, hanem jellemzi a betlts gyorsasgt is rdemben meghatrozzk (az adottweboldal ltal betlttt tartalmak mrete s termszetesen a hlzati viszonyok mel-lett).

Egy lehetsges definci a kvetkez: nevezzk fggsgi grfnak azt a grfot,aminek a cscsai a weboldal megjelentsvel kapcsolatos elvgzend mveleteketreprezentljk, a kztk lev irnytott lek pedig azt mutatjk meg, hogy a ktvgponthoz 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 ktszkript futtatsa kztt, ha azokat a HTML egyms utn hivatkozza (mert a feldol-gozs sorban trtnik). Egy mvelet elvgzse fgghet egyszerre tbb msik mve-lettl is: pldul ha egy szvegdoboznak (pl. elem) egy stluslap meghatroz

9

egy httrkpet, akkor a kp betltse csak akkor kezddhet el, ha a stluslap be-tltdtt, befejezdtt a beolvassa s a HTML parser is eljutott az adott elemhez.Elkpzelhet olyan fggsgi viszony is, amikor egy mvelet elvgzshez csak azszksges, hogy a fggsgei kzl legalbb az egyik teljesljn. Pldul ha egy k-pet kt klnbz szkript is betlt, s a kp gyorsttrazhat, akkor a kp letltseakkor fog megtrtnni, amikor a kt szkript kzl az egyik lefut. Az ilyen fggs-geket a fggsgi grfokon szaggatott vonallal jellm.

Egy specilis fggsgi tpus az, amikor egy szkript expliciten utastja a bng-szt egy erforrs letltsre (pl. ltrehoz egy kpet egy adott URL-lel, vagy HTTPlekrdezst indt egy API [Application Programming Interface] fel). Ezt a lekrde-zst mindenkpp el kell vgezni ahhoz, hogy az oldal betltdjn, de ahhoz, hogyelkezddhessen, elszr le kell futnia az adott szkriptnek. Szintn egy specilis fgg-sgi viszony, ha egy HTTP vlaszban a bngsz egy 302-es vagy 301-es kdszmvlaszt kap, ami tirnytst jelent, teht a keresett erforrs egy msik URL-entallhat meg. Ilyenkor ahhoz, hogy a msik URL-t a bngsz megkapja s elkezd-hesse a msodik lekrdezst el kell vgeznie elszr az els lekrdezst, teht ez isegyfajta fggsgi viszony. A fggsgi grfokon azoknl az leknl, ahol nem egyr-telm (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 m-sik helyen (pldul egy esemny bekvetkezsnel hatsra). Ilyen tulajdonsg aHTML beolvassa is, teht a grfban tbb helyen is megjelenhet ugyanazon HTMLbeolvassa. Ilyenkor klnbz rszek beolvassrl van sz, s az egyes beolvassilpsek kztti fggsgek a HTML kd egyes rszeinek sorrendisgt tkrzi (tehtpl. 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 ugyan-is arra, hogy minden trtns naplzhat legyen, s hogy a naplbl kiderljn azesemnyek kztti ok-okozati kapcsolat.

Ehhez segtsget nyjt a Google Chrome bngsz Timeline funkcija, ami lehe-tv teszi az sszes esemny, szkript futtats s hlzati forgalom monitorozst, srszlegesen kinyerhetk belle az ok-okozati viszonyok is. Ennek egyik nagy hinyos-sga, hogy az esemnyeknl nem lthat az esemny forrsa, pl. egy load esemnynlnem egyrtelm, hogy az az egyik iframe-ben lev HTML dokumentum load ese-mnye, 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 ne-

hezt, hogy ezek tbbnyire csak minimalizlt formban rhetek el. Mivel a Ja-vaScript egy interpretlt nyelv, s nem szabvnyostottak hozz binris formtumot,a szkriptek csak forrskd formjban terjeszthetk. A forrskd mrete viszont je-lentsen cskkenthet a vltozk tnevezsvel, a formzshoz hasznlt whitespacekarakterek eltvoltsval s ms transzformcikkal: ezt a folyamatot szoks mi-nimalizlsnak nevezni. Hasznlata teljesen bevett gyakorlatnak szmt. Egy ilyenforrskd a megfelel eszkzkkel olvashatbb formra hozhat, de a vltozk tne-vezse miatti informciveszts megnehezti az rtelmezst.

1.7. Esettanulmny

Ebben az alfejezetben egy nagy ltogatottsg magyar webportl pldjn muta-tom be, hogyan zajlik egy weboldal letltse. A vlasztsom az origo.hu-ra esett,mert a cmoldala rengeteg tartalommal van megtltve, tbb begyazott hirdetstis megjelent, s bonyolultsgban jl reprezentlja a tbbi magyar hroldalt. Azrtnem egy klfldi, mg nagyobb forgalm oldalt vlasztottam, mert ezek rendkvljl optimalizltak, gy nem reprezentljk elg hen a felhasznlk ltal megltoga-tott weboldalak tbbsgt. A ksbbiekben az origo.hu pldjt hasznlom a mrsimdszerek 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 tlthatsgkedvrt. Az F.1. fggelkben megtallhat az egyes sorszmokhoz tartoz URL-eklistja. Szintn a jobb tlthatsg miatt hasznltam nhny specilis jellst, ezeketa kvetkezkben rviden megmagyarzom. Ezutn ismertetem a betlts folyamatta fggsgi grf alapjn.

11

1.5. bra. Az origo.hu fggsgi grfja

12

1.7.1. Jellsek

Sok prhuzamosan vgezhet, egymshoz hasonl lekrdezst sszevontam nagyobbegysgekbe. Ilyen pldul 16., 17., 18., 23., 26. s 27. letlts: ez esetben egymsmelletti tag-ekben hivatkozott kpekrl van sz. Mivel ezeknl a kivlt okazonos (a HTML parser az adott helyre rt), s egymstl nem fggnek, ezrt azsszevons nem jrt informcivesztssel.

A 9. stluslap feldolgozst s a 10. szkript letltst tbbszr is szerepeltettemaz brn annak ellenre, hogy ezek nem rszekre bontott mveletek (az index.htmlbeolvassval ellenttben, ami tbb rszletben trtnik). Ennek oka az volt, hogycsak gy lehetett a legjobb elrendezst biztostani.

A DOMContentLoaded esemny bekvetkezse utn a 11. szkript t iframe-et hozltre klnbz URL-ekkel. Ezek kzl ngy ugyanarra a HTML sablonra pl, scsak a fjlok utols rsze tr el. Van teht a feldolgozsban egy kzs rsz, aminmindegyik iframe keresztl megy: ezt szaggatott vonallal bekeretezve jelltem. Ezazt is jelenti, hogy a kzs rszben hivatkozott szkriptek akkor kezdenek el letltd-ni, amikor a ngy iframe kzl a leggyorsabb elr ide. Amikor a tbbi is eljut ebbea szakaszba, nem indulnak j letltsek, hanem megvrjk a folyamatban lev letl-tsek eredmnyt, s mivel ezek az erforrsok gyorsttrazhatak, ezrt a letltttszkripteket fogja futtatni a tbbi iframe is.

1.7.2. A szkriptek betltse

A kiindulpont az origo.hu domain (0. lekrdezs). Innen csak egy tirnytst kapvissza 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, selkezdi letlteni a begyazott szkriptek kzl azokat, amik a dokumentum elejnjelennek meg (2-9. lekrdezs). Miutn az egsz HTML megrkezett a hlzaton, abngsz elkezdi letlteni a HTML fjl vgn hivatkozott 10. szkriptet is.

A HTML parser is elindul, viszont a 8. szkriptet hivatkoz tag-nlmegll, s vrja, hogy ez s a 9. stluslap letltdjn. A 11. csak egy tirnyts utnelrhet, ezrt ez rkezik meg legksbb, s br ekkorra valsznleg a 9. stluslap s2-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 egyasync attribtummal rendelkez tag-et (ez egy Google Analytics analitikaiszkript), aminek a letltse elindul, a futsa pedig rgtn megkezddik majd, mihelyt

1Ez 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 talla parser, amihez 9. stluslap CSS szablyai kpeket rendelnek, ezek letltst is meg-kezdi. Egy rvid begyazott szkript lefuttatsa utn (ami a nvnapok kiiratsbansegdkezik) egy jabb hasonl szakasz kvetkezik 6 kppel s 21, CSS szablyok ltalmeghatrozott kppel.

Ebben a szakaszban tallhat egy iframe-be gyazott oldal is, ami ltszlag egykpet tlt be (87.), valjban azonban ez 1x1-es mret, s a betlts clja mind-ssze az, hogy az iframe-ben fut szkript a kp URL-jben kzlhesse a ww392.smartadserver.com szerverrel a felhasznl monitornak felbontst, hogy az k-sbb ehhez igazodva tudjon hirdetseket kldeni. Az ilyen tpus kpeket web bug-nak (magyarul web poloska) nevezik [34], s legtbbszr forgalomszmllsra, sta-tisztika gyjtsre hasznljk ket.

Az index.html 835. sorban kezdd begyazott kd a document.write() fgg-vny segtsgvel ltrehoz egy jabb tag-et, aminek az URL-jt a ltreho-zs eltt egy vletlen szmmal egszti ki. A vletlen szm megjelense az URL-benazt eredmnyezi, hogy az erforrst biztosan nem gyorsttrazza sem a kliens, sempedig a kliens s a szerver kztt ll esetleges HTTP proxy. A parser itt megll, smegvrja, mg az jonnan ltrejtt 40. szkript betltdik, mivel ez nem egy asyncszkript. A fjl tartalma ez: //empty, teht egyetlen JavaScript kommentet tartal-maz. Errl a szkriptrl felttelezhetjk, hogy a szerepe kimerl a forgalomszml-lsban, 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 tag s 19 CSS ltalmeghatrozott kp letltsnek elindtsa utn egy jabb mrkd kvetkezik az1192.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 hirdetiprofil azonostsra. Az xgemius.js egy kpet hoz ltre, amely szintn 1x1 pixelnagysg, s az URL-ben kzli a kperny felbontst, sznmlysgt s a hirdetiprofil azonostt a hu.hit.gemius.pl oldallal, amely a vlaszban nhny cookie-t isbellt a ltogat ksbbi azonostsa cljbl. Az index.html utols soraiban egybegyazott JavaScript mg meghvja a 8. inicializl fggvnyt, de az egyelre nemgenerl jabb lekrdezseket.

14

1.7.4. A hirdetsek megjelentse

Itt vget r a HTML beolvassa, gy a parser ltrehozza a DOMContentLoaded ese-mnyt. Ekkor aktivizldnak az erre az esemnyre feliratkozott szkriptek: a 3. saz 5. a cmlap megjelentsrt felels, nhny kp URL-jt lltjk be, a hirdetse-krt a 11. felels, ami 1 msodperces ksleltets utn kezdi el mkdst: felveszi akapcsolatot az ad.adverticum.net hirdetsi szerverrel.

Az ad.adverticum.net-tel val kommunikcira az n. JSONP (JavaScript Ob-ject Notation with Padding) technikt [26] hasznlja, ami a kvetkezkppen m-kdik. A kommunikci kezdemnyezje ltrehoz s beszr egy tag-et adokumentumba, ami a clszerverhez ktd URL-re hivatkozik. Az URL-ben lehet-nek paramterek kdolva. A szerver a vlaszban dinamikusan generlt JavaScriptkdot kld, ami nhny globlis vltozt llt be. Amikor a letlts befejezdik, lefuta szerver ltal generlt kd, majd a tag-en keletkezik egy load esemny,aminek hatsra a felad kd esemnykezelje lefut, s kiolvassa a globlis vltozkrtkt.

A 11. teht JSONP hasznlatval elkldi a kliens sszes relevns adatt a szerver-nek (88.), a szerver pedig a vlaszban meghatrozza az iframe-ekben, s kpekkntbetltend hirdetsek listjt. A vlasz alapjn ltrehozza az iframe-eket (89-92.),illetve a kpeket (95-99.) majd jabb JSONP lekrdezst indt (94.), s az jonnankapott utols iframe-et is ltrehozza (104.). Mindkt vlasz utn kld visszacsatolsta 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 1x1-es kpet jelent meg. A valdi hirdetsek (a 89-91. s a 104. iframe) ugyanarra aHTML sablonra plnek. Mindegyik ugyanazt a ngy kzs szkriptet hasznlja, majdegyedi kdok kvetkeznek, amik a hirdets rdemi rszt jelentik meg. Ezek kzsjellemzje, hogy ahogy a grfon is ltszik csak egyms utn sorosan betlthetHTTP krseket hasznlnak, gy jval kitoljk a weboldal load esemnyt.

A hirdetsek betltse utn vgre ksznek nyilvntja a bngsz az oldalt, sltrehozza a load esemnyt.

1.7.5. Tovbbi elemzs

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

15

16

2. fejezet

Ismert optimalizcik

Ebben a fejezetben a jelenleg is hasznlt optimalizcikat mutatom be. A fejezetelejn azokat a mrhet mennyisgeket, illetve a mrskre hasznlhat eszkz-ket veszem sorra, amiken lemrhet egy-egy mdszer hatsa. ltalban ezeknek amrszmoknak a maximalizlsa illetve minimalizlsa a cl.

Ezutn rviden ttekintem, hogy milyen szempontok szerint lehet kategorizlni aklnbz technikkat. Ilyen szempont pldul az, hogy a letltsi folyamatban rsztvev szereplk kzl kik vesznek rszt a vgrehajtsban, vagy az, hogy a mdszermelyik hlzati rtegekben mkdik.

A fejezet utols rszben a dolgozat f tmjt ad eltltses optimalizcikattekintem t. Itt manapsg is ismert s hasznlt technikkrl lesz sz, mg az ltalamkidolgozott 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 vgzkomponens vagy a futtatott szkriptek kezdemnyezik. A krshez tartoz feladat abngsz hlzati rteghez kerl. A hlzati rteg feloldja a domain nevet, majdegy HTTP krst hoz ltre, amit egy meglev vagy egy jonnan ltrehozott TCPkapcsolathoz rendel. Ha van olyan nyitott TCP kapcsolat a clszerver fel, ami ppenszabad, akkor ezt hasznlja. Ha nincs, de a nyitott TCP kapcsolatok szma nem riel a maximlis rtket (ltalban szerverenknt 6), akkor egy j kapcsolatot nyit.Ha pedig nem lehet tbb kapcsolatot nyitni s minden meglev foglalt, akkor akrs vrakozik amg egy kapcsolat fel nem szabadul. Elszr a krs fejlce, majd akrshez (opcionlisan) csatolt adatok kerlnek ki a hlzatra. Bizonyos id elteltvelmegrkeznek a vlasz HTTP fejlcei, majd a teste is. Amikor a vlasz utols csomagjais megrkezett, a krst a hlzati rteg lezrja.

17

Ebben a folyamatban 5 fontos esemnyt rdemes kiemelni:

1. a hlzati rteg megkapja a krs paramtereit2. a HTTP krs fejlce (vagy annak els rsze, ha tl nagy) kikerl a hlzatra3. a HTTP krs utols csomagja kikerl a hlzatra4. 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 kztteltelt 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 mindktkrlmny nagyon ritka, a ksbbiekben elhanyagolom ezt az idintervallumot. Akrs 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 esemnyigeltelt idvel lehet kifejezni. A load egy jl definilt esemny, amit az sszes bng-sz hasonlan implementl. Valjban azonban nem ilyen egyszer a betltsi iddefincija s mrse.

Az els problma az, hogy a load esemnyhez csak egy idblyeget lehet rgz-teni. Ahhoz, hogy az addig eltelt id megllapthat legyen, szksg van egy msikidblyegre, ami az oldalbetlts kezdett jelli. Az oldalbetlts folyamatban azels olyan pont, amikor JavaScript kd futhat, s rgztheti ezt az idblyeget, aza HTML feldolgozs kezdete, feltve hogy a kd a HTML legelejn tallhat. AHTML feldolgozs elindulsig azonban elszr fel kell oldani az URL-hez tartozdomain-nevet, fel kell pteni a TCP kapcsolatot a szerverig stb. Ez a szakasz becs-lsek szerint az oldalbetltsi id akr 20%-t is kiteheti [30]. Erre a problmraegyszer megoldst nyjt a szabvnyosts alatt ll, de a modern bngszk ltalmr tmogatott Navigation Timing API [38], amin keresztl a JavaScript kdoklekrdezhetik ezeket az adatokat.

Egy msik, sokkal jelentsebb problma, hogy a load-ig eltelt id nem mindenesetben jl fejezi ki a felhasznli lmny minsgt. Elkpzelhet kt olyan weboldal,amiknl ez a mrszm megegyezik, de a felhasznl szemszgbl az egyik sokkalgyorsabban betltdik. Ennek az az oka, hogy felhasznli szempontbl a bngszltal adott explicit visszajelzsnl (folyamatjelz sv jelzi, hogy tltdik az oldal)fontosabb az, hogy mikor jelenik meg a kpernyn a tartalom. Tovbb bonyoltja ahelyzetet, hogy a tartalom fokozatosan jelenik meg.

A Speed Index [39] egy olyan mrszm, amit ezeket a problmkat figyelembe

18

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

S =

end0

1 c(t)dt (2.1)

A Speed Index mrse azonban nem egyszer: pontosan definilni kell az endesemnyt (amit az animlt kpek, hirdetsek megneheztenek), s kiszmtshozszksg van a weboldal betltsrl kszlt videfelvtelre. Valszn, hogy a jv-ben a teljestmny mrst lehetv tev webes szabvnyok a Speed Index ltalmeghatrozott irnyba fognak tovbblpni, de egyelre minden npszer teljest-mny 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 mr-szmknt 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 rendel-kezik valamilyen beptett analitikai eszkzzel. A diplomamunka elksztse sorn avlasztsom a Chromium bngszre6 esett, mert amellett, hogy grafikus felleteszkzket biztost a betltsi folyamat elemzshez (Developer Tools), elrhetvteszi az sszes adatot egy jl dokumkentlt WebSocket [24] alap interfszen (Re-mote Debugging Protocol [8]) keresztl is. Valjban maga a Developer Tools iscsak egy webalkalmazs, ami ezt az interfszt hasznlva ri el az adatokat. A szab-vnyos interfsz meglte rendkvl jl automatizlhatv teszi a mrsi folyamatot.A kvetkez nhny bekezdsben a Chromium ltal szolgltatott adatokat tekintemt, de a legtbb bngsz nagyon hasonl adatsorokat tesz elrhetv a fejlesztieszkzeiben.

A Chromium Developer Tools az informcikat tbb panelen jelenti meg. Azoptimalizcik szempontjbl a kt legfontosabb panel a Timeline (idvonal) s

1http://www.webpagetest.org/2https://support.google.com/analytics/answer/12057843https://secure.torbit.com/insight/4http://www.soasta.com/products/mpulse/5http://httparchive.org/6http://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 azesemnysorokat 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 RDPprotokollon:

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 folyama-tok lefutsnak vge) idztk indtsa, trlse, lejrata JavaScript garbage collector futsa reflow/layout szmts kirajzols a kpernyre

Fontos megemlteni, hogy ezekben a naplkban az az idpont szerepel, amikor abngsz a hlzati rtegnek tadta a HTTP krst, valamint az, amikor elkrte azadott vlaszcsomagot, nem pedig az, hogy a hlzatra mikor kerlt ki vagy mikorrkezett meg egy adatcsomag. A HTTP tirnytsokat is elrejti a hlzati rteg,ezrt ezek sem szerepelnek a naplkban. A Timeline egyik hinyossga, hogy azegyes DOM esemnyekhez nem trstja az esemnyt kivlt objektumot. gy nemlehet klnbsget tenni pldul egy iframe load esemnye s a f dokumentum loadesemnye kztt.

A bngsz beptett fejleszti eszkzei mellett ltezik nhny JavaScript-bl el-rhet API is, ami a teljestmny adatok legkrdezst teszik lehetv. Ezek kzla mr emltett Navigation Timing API-t rdemes kiemelni. Mivel a Remote De-bugging Protocol JavaScript futtatst is lehetv teszi, ezrt a Navigation Timingadatok is lekrhetk a protokollon keresztl.

2.2.2. tcpdump, Wireshark

Ez a kt eszkz7 a hlzati forgalom felvtelre s elemzsre hasznlhat. Ha afelvtelt a mrsben rszt vev gpek egyikn futtatjuk, akkor figyelembe kell vennia felvtellel jr processzorterhelst is, mert befolysolhatja a mrs rdemi rsztvgz processzeket. A tcpdump gy is konfigurlhat, hogy a megjelentst mellzzes csak egy fjlba rgztse a felvett hlzati forgalmat, ezrt felvtelkor ezt rdemeshasznlni.

A Wireshark rengeteg hasznos eszkzt biztost a hlzati forgalom felvtelek elem-zshez, 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) fontosmegvizsglni, hogy a weboldal letltsi folyamat milyen hatkonyan hasznlja ki a

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

21

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

rendelkezsre ll svszlessget, s hogy az egyes HTTP lekrdezsek ebbl hogyanrszesednek. A Wireshark-ban erre az IO Graph nev eszkz hasznlhat, ami azidegysgenknt tvitt adatok hisztogramjt jelenti meg. A diagramhoz klnbzszrk adhatk meg, s az ezekre illeszked csomagok a diagramon klnbz sznneljelennek meg.

Ahogy a 2.3. brn is lthat, az eszkz nagy hinyossga tbbek kztt, hogyegyszerre legfeljebb t szr adhat meg, emiatt nem lehet egy diagramon brzolniaz sszes HTTP lekrdezs rszesedst.

2.3. Optimalizcik kategorizlsa

2.3.1. Szereplk

Egy weboldal betltshez rengeteg klnbz szerepl ltal fejlesztett s zemeltettszoftver s hlzati eszkz egyttmkdsre van szksg. Ezek mindegyike befoly-solhatja azt, hogy egy weboldal betltdsi folyamata mennyire hatkony. Legfon-tosabb termszetesen maga a weboldal s az azon hasznlt third-party szoftverekminsge, de rdemben befolysolhatja a teljestmnyt a webszerver, a klnbzkzvettk (pl. HTTP proxy-k) s a felhasznl bngszje is.

Ahhoz, hogy egy weboldal teljestmny szempontjbl hatkony legyen, a weboldalfejleszti rszrl a bngsz mkdsnek alapos ismeretre, folyamatos mrsre svisszacsatolsra van szksg. A legtbb esetben ez tl idignyes s kltsges folya-mat, ezrt a webfejlesztk ltalban klszablyokra s bevlt mdszerekre alapoz-nak. Lteznek olyan szoftverek, amik pontosan ezt a tpus optimalizcit segtik.Ilyen pldul a Google Chrome bngszhz fejlesztett PageSpeed Tools kiegszt8

8https://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. Ezeka szoftverek akr a weboldal struktrjt is mdosthatjk gy, hogy hatkonyabblegyen a betltse. Ehhez olyan informcikat is felhasznlhatnak, amiket nem aweboldalbl nyernek ki automatikusan, hanem a weboldal zemeltetjtl kapnakmeg konfigurcis fjl formjban. Az ilyen informcik jelentsen nvelhetik a ha-tkonysgot. Ilyen pldul a HAProxy10 s a Google Page Speed Service11.

Az internetszolgltatknak rdekben ll az, hogy az gyfeleik minl gyorsabb-nak rzkeljk a szolgltatsukat. Ezrt sok szolgltat alkalmaz olyan optimalizlszoftvert, ami a webszerver s a felhasznl bngszje kztt kzvetti s esetleg m-dostja a forgalmat gy, hogy a felhasznl ltal rzkelt minsg (QoE - Quality ofExperience) javuljon. Ezek a szoftverek az elz tpusnl jval messzebb helyezked-nek el a tartalomtl, s nincs hozzfrsk az zemeltettl szrmaz informcik-hoz. Hozzfrhetnek viszont a hlzattal kapcsolatos adatokhoz, pldul ismerhetika rendelkezsre ll svszlessget s a tipikus ksleltetst. Ennek megfelelen lta-lban ms mdszereket hasznlnak, mint az elbb bemutatott optimalizlk. Ilyenoptimalizcikat valstanak meg pldul a ByteMobile termkei12.

A bngszk a beptett optimalizcik mellett aktv szerepet vllalhatnak egymsik szerepl ltal kezdemnyezett optimalizcis folyamatban: elkpzelhet olyanmegolds 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 abngszben lefutva egyttmkdik a kdot beszr szereplvel.

2.3.2. Hlzati rtegek

Egy msik szempont az, hogy ha az adott optimalizcis technika a hlzati forgal-mat 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 szm-ra tltszan vagy a kliensben expliciten belltott HTTP proxy hasznlatval. Azolyan, kzvettk ltal hasznlt optimalizcikat, amik a weboldal tartalmnak m-dostsval jrnak, intrusive-nak, az olyanokat pedig, ahol erre nincs szksg non-

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

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 terletnhasznlnak arra, hogy elrejtsk egy rendszer mkdsnek (sokszor elkerlhetetlen)lasssgt a rendszer felhasznli ell. Mkdsnek alapja hogy bizonyos krseketmr azeltt elkezd a rendszer kiszolglni, hogy azokat a felhasznl kezdemnyeztevolna. Ehhez mindenkppen szksg van egy modellre, amit a felhasznl viselke-dsnek elrejelzsre fel lehet hasznlni. Ez a modell sohasem tkletes, emiattlehetnek rosszul elrejelzett krsek. Az eltlts teht mindig egy kompromisszu-mot jelent: elkpzelhet, hogy az elre teljestett krsek kzl nem lesz mindenreszksg, s ez erforrsok pazarlsval jr.

A modern opercis rendszerek mindegyike hasznl eltltst a rendszer indu-ls folyamatnak gyorstsra: az elz boot folyamatok napli alapjn a szksgetfjlokat mr a folyamat legelejn elkezdik beolvasni a merevlemezrl a memriba[33]. Erre azrt van szksg, mert a boot folyamatban sokszor egymst vltjk aCPU-intenzv s az IO-intenzv rszek. Az eltlts hatsra ezek kvzi prhuzamo-sthatk, s gy mindkt erforrst hatkonyan hasznlja ki a folyamat.

A weben az eltlts azt jelenti, hogy bizonyos HTTP krseket valamelyik sze-repl (bngsz, proxy, stb.) mg azeltt elindt, hogy a felhasznl erre explicitenutastst adott volna. A felhasznli modell vza a legtbb esetben ugyanaz: a fel-hasznl egy utat jr be az egyes weblapokon keresztl (linkeket kvetve, vagy URL-

24

eket megadva), s kzben a bngsz letlti az adott weblaphoz tartoz erforrso-kat. Ezt a modellt az 2.4. bra szemllteti. Ha az eltlt algoritmus (ami brmelyikszereplnl futhat) a felhasznli modell alapjn megjsolt egy lekrdezst, akkor acl mindig az, hogy a krsre adott vlaszt kzelebb juttassa a klienshez, hogy ha akrs tnylegesen bekvetkezik, akkor a vlasz gyorsabban megrkezhessen.

Ebbl a nagyon ltalnos jellemzsbl is ltszik, hogy az egyes eltltsi megold-sok sok paramter mentn klnbzhetnek. rdemes ezeket a paramtereket meg-vizsglni, hogy tfog kpet kapjunk a lehetsges megoldsokrl. Az egyik legjobbszempontrendszert Bouras s Konidaris [6] dolgozta ki, ami a kvetkez elemekblll:

Kik? Kik vesznek rszt az eltltsi folyamatban?

Mit? Pontosan melyek azok a HTTP lekrdezsek, amiket elre kell illetve elrelehet hozni? A krdsre ltalban egy algoritmus ad vlaszt, ami a felhasznlimodell alapjn vlaszt ki krseket.

Hogyan? Hogyan adjk t az egyes szereplk egymsnak az eltlttt krseket svlaszokat?

Mikor? Mikor trtnik az adattvitel? Trtnhet pldul akkor, amikor a felhasz-nl az elzleg letlttt weboldal tartalmt elolvassa.

A webes eltlts a 90-es vek msodik felben nagyon npszer kutatsi tmavolt. Az alfejezet tovbbi rszben elszr ezeket a kutatsokat mutatom be. Atma irnti rdeklds a kvetkez vtizedben jelentsen visszaesett, de a felvzoltrendszerek 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 publiklta1996-ban [31]. Sok elremutat megfigyelst s javaslatot tettek, amik egy rsze mamr szabvnyosts alatt van (errl rszletesebben a 2.4.3. pontban lesz sz). Azltaluk lert rendszerben az eltlts kt szerepl kzremkdsvel valsul meg. Azadott weboldal webszervere statisztikkat gyjt a felhasznlk viselkedsrl, s ezalapjn tesz elrejelzseket, amiket HTTP fejlcek formjban juttat el a kliensnek.A kliensprogram az aktulis helyzete (szabad hlzati kapacits, energiagazdlkodsimegfontolsok, stb.) alapjn dnt arrl, hogy elkezdi-e az eltltst.

Az ltaluk javasolt egyszer elrejelz logika egy fjlrendszerekhez hasznlt eltl-t algoritmuson [22] alapul. Ebben a smban a szerver minden letlttt erforrshoz

25

home.html

image1.gif

image2.gif

about.html0.9

0.5

0.5

0.2

0.5

0.01

2.5. bra. Padmanabhan s Mogul modellje

megfigyeli, hogy a kliens utna milyen ms erforrsokat krt le. Az adatokat egyirnytott 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 valsznsgeannak, hogy A lekrdezse utn w lekrdezsen bell a kliens lekrte B-t, ahol aw 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 rle. Az elrejelz algoritmusok fejldst vgig a Markov-lnc modell hatrozta meg.Davidson ttekintse [13] szerint a legtbb modellm-edrend Markov lncot hasznl,de vannak olyanok is, amik az elrhet informcik alapjn slyozzk a klnbzrend Markov lnc modelleket a jobb hatkonysg elrse rdekben. Ilyen a Predic-tion by Partial Matching algoritmus is, amit eredetileg adattmrtshez hasznltak,s elrejelzshez elszr Vitter s Krishnan [37] javasolta. Chierichetti et al. [7] ku-tatsa szerint a magasabb rend Markov lncok j kzeltst adnak a felhasznliviselkedsre. Ez igazolja az ilyen algoritmusok ltjogosultsgt.

A felptett modell hatkonysga nagy mrtkben fgg a rendelkezsre ll infor-mciktl. 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 web-

oldal sszes felhasznljtl.

Mindegyik szerepl az informcik egy rszhalmazhoz fr hozz, s az alkalmazotteltlt algoritmusokat ennek megfelelen kell finomhangolni. Az eltlt algoritmusmellett az eltlts mdja is eltr attl fggen, hogy mely szereplk vesznek rszta folyamatban, ennek megfelelen klnbz megoldsok szlettek szerver-kliens,proxy-kliens s szerver-proxy eltltsre.

26

Az eltlts megvalstsra szinte csak olyan megoldsok szlettek, amik mk-dshez mdostani kell a bngsz-szoftvereket, a webszervereket illetve a HTTPprotokollt. Nagyon kevs olyan megolds van, amihez nem kell a bngsz s awebszerver explicit tmogatsa. Ezek a szoftverek azonban ltalban nagyon bonyo-lultak, emiatt kevs konkrt implementci ltott napvilgot. A mdszerek kirtke-lsnl ezrt ltalban szimulcikra tmaszkodnak, s olyan, publikusan is elrhetHTTP 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 praktiku-san megvalsthat csak a proxy mdostsval [29, 6, 27, 25]. Ezek arra alapulnak,hogy a proxy a gyorsttrba eltlt bizonyos tartalmakat, ha az elrejelz algorit-mus 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 avilghl. A weboldalak nagy rsze dinamikusan generlt (emiatt a HTML ltal-ban nem gyorsttrazhat), rengeteg szkript fut rajtuk, tovbb sok a third-partytartalom (reklmok, begyazott tartalmak). Egy weboldalhoz 1995-ben tlagosankevesebb mint 3 erforrs (kp, stluslap, stb) tartozott, mg ez a szm 2012-benmegkzeltleg 100 volt [40]. A weboldalak tlagos mretnek alakulst az 2.6. b-ra mutatja be.

A legtbb javasolt Markov-lnc alap modell szmtsi s trolsi ignye ltal-ban exponencilisan n a lnc rendjnek nvekedsvel. A rend viszont arnyosankell hogy njn a a weboldalakhoz tartoz lekrdezsek szmval, ha a HTTP lekr-dezsek elrejelzsrl van sz. Erre egy lehetsges megolds az, hogy nem a HTTPlekrdezseket figyelik meg, s jsoljk meg az elrejelz algoritmusok, hanem a fel-hasznl ltal megltogatott weboldalak cmt, s ezutn egy kvetkez lpsbenprblnak kvetkeztetni a konkrt HTTP lekrdezsekre. Ez egy manapsg tlagos-nak mondhat weboldal esetn viszont nem trivilis feladat, ahogy az esettanulmnylersbl (1.7. rsz) is ltszik.

2.4.3. Ma is hasznlt, illetve szabvnyostott megoldsok

A gyakorlatban egyelre nem terjedtek el a felhasznlk viselkedst automatiku-san elrejelz webes rendszerek. Ennek ellenre van nhny terlet, ahol sikeresenhasznlnak eltltsre alapul megoldsokat. Az egyik, mr ltott plda a specu-lative parsing (1.5. rsz). Ebben az alfejezetben ezeket a gyakorlatban is hasznlt

27

0200

400

600

800

1000

1200

1995

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

2010

2011

2012

0

20

40

60

80

100

120Erforrsok

sszmrete(kby

te)

Erforrsok

szm

a

Erforrsok sszmreteErforrsok szma

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

/* Inline CSS */

/* Inline JavaScript */

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 hivat-kozott szkripteket, stluslapokat, kpeket letlti s begyazza a HTML-be. Ezt azteszi lehetv, hogy a HTML tmogatja az ilyen tpus erforrsok begyazst sURL alapjn val hivatkozst is. Ezt a 2.7. brn lthat kdrszlet szemllteti. Ezazrt tekinthet eltltsnek, mert a HTML tvitelvel egyidben tulajdonkppeneltlti a rendszer azokat az erforrsokat, amire a bngsznek a megjelents sornszksge lesz.

28

Egy ezen az elven mkd proxy szerver a kvetkez lpseken megy vgig:

1. rkezik egy HTTP lekrdezs, s ezt tovbbtja2. megrkezik a vlasz, ami egy HTML fjl3. a HTML feldolgozsa utn letlti a hivatkozott erforrsokat4. a letlttt tartalmakat begyazza a HTML-be5. elkldi a kliensnek a kiegsztett HTML fjlt

Ez a mdszer azonban sok htrnnyal is jr. Az egyik problma, ami HTTPproxy-ban val hasznlat esetn jelentkezik, hogy kliens emiatt ksbb kezdheti meg afeldolgozst, mert meg kell vrnia, amg a proxy letlti s begyazza az erforrsokat.Egy msik, hasonlan fontos problma a cache kezelse. A begyazott erforrsoknem kerlnek be a bngsz gyorsttrba, mert az csak URL alapjn hivatkozotterforrsokat trol, emiatt minden alkalommal jra le kell tlteni ket.

Ezt a tpus eltltst felhasznlja a ByteMobile s a Google Page Speed Serviceis. A ByteMobile az sszes szkriptet s stluslapot begyazza, mg a Page SpeedService csak a nagyon kis fjlokat. Ez utbbi viselkedsre a dokumentci13 ad ma-gyarzatot:

There is a tradeoff here between requests and cacheability: including theresources directly in the HTML avoids making an additional request tothe external resource, but if the resource file is large (and doesnt changeoften), it may be better to keep it separate from the HTML so that itcan be cached by the browser.

A begyazs teht csak kis mret vagy gyakran vltoz erforrsoknl elnys. APage Speed Service a weboldal zemeltetjvel egyttmkdve meg tudja llaptani,hogy melyek ezek tartalmak. Egy ltalnos proxy esetn azonban ez csak a HTTPvlaszbl derl ki, teht meg kell vrni a hivatkozott erforrsok letltst, emiattezt 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, hatkonyabbverzijnak kidolgozsra. A Google elkezdte a SPDY protokoll [3] fejlesztst, amiaztn a jelenleg a szabvnyostsi folyamat elejn jr HTTP/2 [2] alapja lett. Azj 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 alkalmaz-sokat nem kell mdostani.

13https://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 mindsszeegyetlen TCP kapcsolat pljn ki, s ezen keresztl prhuzamosan tetszleges sz-m HTTP krs utazzon. Ez jelents elrelps a HTTP-hez kpest, ahol akr 6prhuzamos TCP kapcsolat pl ki, s a prhuzamos krsek szma kapcsolaton-knt 1. A prhuzamos krsek kztt a kliens prioritsi sorrendet llthat fel.

Az eltlts szempontjbl legfontosabb kpessg a szerver oldalrl kezdemnye-zett krsek lehetv ttele. Ez arra hasznlhat, hogy a szerver a kliens gyorst-trba helyezzen el erforrsokat. Ha a kliens gyorsttrban mr szerepel az adotterforrs, akkor visszautasthatja a krst. Ez a megolds az inlining minden el-nyt megrzi, de a htrnyait nem rkli: a csatolt erforrsokat a kliens krsenlkl, ugyanazon a TCP szlon lehet elkldeni, de a HTML ksleltetse nlkl sa gyorsttrazs helyes kezelsvel.

Prefetch hintek

A Mozilla bngsz a 2003-ban kiadott 1.2-es verziban vezette be a link prefetchkpessget [28], ami kpess tette a bngszt arra, hogy fogadja a webszerver eltl-tsre vonatkoz javaslatait. Ezt a kpessget a Mozilla bngszbl szrmaz Firefoxis 2003 ta tmogatja. A szerver kt mdon jelezheti az eltltsi javaslatot: a HTTPLink fejlcet hasznlva, vagy a HTML tag hasznlatval. Az utbbi vlto-zat bekerlt a HTML5 szabvnyba is, de mg nem implementlja minden nagyobbbngsz. Ez a sma gyakorlatilag megegyezik azzal, amit Padmanabhan s Mogul1996-ban javasolt [31].

A SPDY protokoll tmogatja az n. server hint kpessget, ami gyakorlatilaga Link fejlc tvtelt jelenti. Ezt a kliens oldali SPDY implementcik mg nemimplementltk.

A Google bngszi a tag tbb kiterjesztett vltozatt is tmogatjk. Arel attribtum hasznlatval lehet megadni, hogy milyen tpus eltltsrl vansz:

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

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

30

prerender: olyan URL, amire a felhasznl nagyon nagy valsznsggel fognaviglni (pl. az els keressi tallat egy keresben), ezrt rdemes lehet ahttrben az oldal betltst megkezdeni 15

DNS prefetch s TCP kapcsolatkezels

Nem tartalom eltlts, de elrejelzsre alapul az is, ahogyan a Chrome s a Chromi-um bngsz hlzati rtege a DNS lekrdezseket s a TCP kapcsolatok felptstkezeli. Ezek a bngszk a felhasznl viselkedsre, s az adott weboldal mltb-li felptsre alapozva megprbljk a DNS lekrdezseket elrehozni, s a TCPkapcsolatokat elre felpteni azokhoz a webszerverekhez, ahov valsznsthet,hogy HTTP krseket kell majd kldeni [23]. Az tletet elszr Cohen s Kaplanpubliklta 2002-ben [9].

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

31

32

3. fejezet

Optimalizls eltltssel egy jmegkzelts

Ebben a fejezetben egy j, eltltsre alapul optimalizcit mutatok be, ami sokbanklnbzik az eddig ismert mdszerektl. Ez a kzvettk ltal hasznlhat technikanem ignyli a kliensek s a szerverek mdostst s jl hasznlhat nagy ksleltets(pl. mobil) hlzatokban. A hasznlhatsg alapfelttele, hogy a hlzati kapcsolat akzvett 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 fel-hasznl egy oldal betltse utn valamennyi idt eltlt az oldalon, s csak ezutnlp tovbb. Ebben, a hlzat szempontjbl kihasznlatlan idsvban trtnik azeltlts, amikor az eltlt logika megprbl olyan weboldalakat letlteni, amiketa felhasznl a kvetkez lpsben megltogathat.

Az ltalam javasolt eltlt megolds akkor lp mkdsbe, amikor a felhasznlegy weboldal betltst kezdmemnyezi. A bngsz ilyenkor elszr a HTML oldalletltst kezdi el, s ezutn az els fejezetben bemutatott mdon tovbblp a hivat-kozott tartalmakra. A HTTP proxy-ban fut eltlt logika a HTML alapjn indtjael az eltltsi folyamatot, s a gyors internetkapcsolatnak ksznheten mg azelttletlti az elrejelzett tartalmakat, hogy azokat a kliens elkrn. Ez idelis esetben tkletes eltlt logika mellett olyan hatssal jr, mintha a HTML fjl kivtelvelaz egsz tartalom a proxy-ban lett volna a weboldal betltsnek kezdetekor. Ezt amegoldst hasznlva teht nincs szksg a felhasznlk viselkedsnek elrejelzsre.

A msik f klnbsg az ltalam javasolt eltlt logika. A ma hasznlt, HTMLelemzsre pl megoldsok a 3.1.5. pontban bemutatsra kerl statikus elemzsthasznljk. Ez egy tipikus mai weboldal esetn viszonylag rosszul teljest, mert a tar-talom egy jelents rszt ma mr szkriptek generljk. Ezt a problmt a dinamikus

33

elemzs bevezetsvel oldom meg, ami jelentsen hatkonyabb az ilyen lekrdezsekelrejelzsben.

Az eltlts a legegyszerbb esetben a proxy gyorsttrba trtnik, de bemuta-tok 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. Amikoregy HTTP proxy azt ltja, hogy a felhasznl egy HTML oldalt kr le, szintebiztos, hogy azt az oldal ltal hivatkozott erforrsok letltse fogja kvetni. Ha aproxy-ba ptett logika kpes ezeket a krseket elrejelezni a HTML alapjn, akkoraz ezekre adott vlaszok mr a proxy-ban lesznek, amikor a kliens lekri azokat.Ezzel jelentsen cskken a krs megvlaszolshoz szksges idt, s gy gyorsabbantltdik be a weboldal a kliensnl.

3.1.1. Elrhet nyeresg

Idelis esetben minden lekrdezst sikeresen elrejelez, s a kliens lekrdezsnek be-rkezsig letlt a proxy. Ez a kliens szmra ugyanolyan gyorsulst jelent, minthamegltogatott weboldal szervere a hlzatban hozz kzelebb, a proxy helyre kerl-ne. A kiindul llapotban a kliens-webszerver ksleltets rtke megegyezik a kliens-proxy s a proxy-webszerver ksleltetsek sszegvel. Az optimalizci hatsra ezlecskken a kliens-proxy rtkre, teht a ksleltetsbeli nyeresg a proxy-webszerverksleltetssel egyezik meg.

A 3.1. bra az origo.hu betltsi idejt mutatja a ksleltets s a svszlessgfggvnyben. Az bra alapjn meghatrozhat, hogy adott krlmnyek kzttlegfeljebb milyen nyeresget jelenthet a proxy-ba val eltlts. Pldul 1,5Mbit/skliens-proxy svszlessg, 30ms kliens-proxy ksleltets s 20ms proxy-webszerverksleltets esetn a letltsi id 8683ms. Felttelezhet, hogy a szk keresztmetszeteta kliens-proxy hlzati kapcsolat jelenti, ezrt a proxy-webszerver svszlessg nembefolysolja a letltsi idt. Ha a svszlessg vltozatlan marad s a webszerver-proxy ksleltets az eltlts miatt figyelmen kvl hagyhat, akkor a letltsi id7814ms lesz, teht a nyeresg 10%. Ha felttelezzk, hogy a proxy-webszerver kslel-tets rtke adott, akkor meghatrozhat, hogy milyen arny az elrhet nyeresga kliens-proxy svszlessg s ksleltets fggvnyben. Ezt a 3.2 bra szemllteti10ms s 20ms ksleltets esetn.

34

45

6

7

8

9

10

11

12

13

14

10 20 30 40 50 60 70 80 90 100

Betltsi

id[s]

Ksleltets [ms]

1Mbit/s1.5Mbit/s2.3Mbit/s3.4Mbit/s5Mbit/s

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

0

5

10

15

20

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

Elrhetny

eresg

[%]

Kliens-proxy + proxy-webszerver ksleltets [ms]

1Mbit/s1.5Mbit/s2.3Mbit/s3.4Mbit/s5Mbit/s

20+20 40+20 60+20 80+20

3.2. bra. Az eltlts ltal elrhet nyeresg

35

Kliens Eltltgyorsttr

Eltlt

Proxy cache

Webszerver

3.3. bra. Az eltlt bels felptse

3.1.2. Architektra

Az optimalizci implementlshoz kt funckionlis egysgre van szksg: egy el-tltre s egy eltlt gyorsttrra (3.3. bra). Az eltlt gyorsttr teremti mega kapcsolatot az eltlt s a klvilg kztt, az eltlt feladata pedig az, hogyegy HTML fjlt alapul vve megjsolja, hogy a kliens rszrl milyen lekrdezsekfognak kvetkezni. Az eltlt akkor aktivldik, amikor a kliens egy HTML oldalttlt le.

Kt eltlt algoritmust ismertetek a 3.1.5. s a 3.1.6. pontban, de eltte az eltl-t gyorsttr feladatt mutatom be, majd megvizsglom, hogy milyen elvrsokatkell teljestenie az eltlt implementciknak.

Az eltlt gyorsttr egy specilis HTTP cache. Feladata az, hogy fogadja smegvlaszolja az eltlt s a kliens krseit. Bizonyos kritriumok alapjn eldn-ti, hogy mikor tekinthet azonosnak egy olyan krs, ami a klienstl rkezett, segy olyan, ami az eltlttl. Minden ilyen krs-prhoz csak egy HTTP lekrdezstindt, mgpedig akkor, amikor a krs-pr els fele megrkezik. A vlaszt mindkt fl-nek tovbbtja. Azrt fontos, hogy az eltlt is megkapja az ltala indtott krsekrerkezett vlaszokat, mert elkpzelhet, hogy ezt felhasznlva tovbbi krseket tudmegjsolni. Amikor a krs-prra adott vlasz megrkezett, s azt sikeresen tovbb-totta mindkt flnek, akkor a krst lezrtnak nyilvntja. Olyan eset is elfordulhat,hogy egy krs prja soha nem rkezik meg. Ilyenkor az eltlt gyorsttr vala-milyen szemtgyjtsi stratgit hasznlva (pldul egy idzt lejrtakor) lezrja akrst.

Ez a feladat annyiban klnbzik egy hagyomnyos gyorsttr feladattl, hogyegyrszt minden lekrdezst csak rvid tvon trol (a kvetkez ugyanolyan krserejig), msrszt olyan krseket is tovbbthat a kt flnek, amik alapveten nemgyorsttrazhatak. Teht fontos, hogy az eltlt gyorsttr nem veszi figyelem-be a HTTP vlasz fejlcekben megadott kritriumokat a gyorsttrazhatsggalkapcsolatban. Ez a mkdsi md egybknt szinkronban van azzal, ahogyan a bn-gszk a dupliklt krseket kezelik. Ha egy krsre mg nem rkezett vlasz, s egyugyanolyan krst kellene elindtani, akkor a vlasz gyorsttrazhatsgtl fg-

36

Kliens krsekElrejelzett krsek

Felesleges

Rossz

Helyes 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 HTML5szabvny [4] ezt gy fogalmazza meg:

If the resource is identified by an absolute URL, and the resource isto be obtained using an idempotent action (such as an HTTP GET orequivalent), and it is already being downloaded for other reasons (e.g.another invocation of this algorithm), and this request would be identicalto the previous one (e.g. same Accept and Origin headers), and the useragent is configured such that it is to reuse the data from the existingdownload instead of initiating a new one, then use the results of theexisting 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 si-keressge alapjn. A kategorizlst a 3.4. bra szemllteti. A legfontosabb elvrs,hogy minl nagyobb tfeds legyen az eltlt ltal megjsolt lekrdezsek halma-za s a kliens ltal valban elindtott lekrdezsek halmaza kztt. Az ide tartozlekrdezseket az eltlt helyesen jelzi elre. A kt halmaz klnbsge olyan le-krdezseket tartalmaz, amiket az eltlt nem tudott megjsolni, illetve amiketfeleslegesen jsolt meg, mert azutn nem trsult hozz vals lekrdezs. A feleslege-sen megjsolt lekrdezseket kt csoportba lehet besorolni. Az els csoportban azoka lekrdezsek vannak, amik miatt felesleges svszlessget hasznlt fel a szerver, dems problmt nem okoznak. A msodik csoport az olyan tves elrejelzsekbl ll,amik mellkhatsokkal jrhatnak, teht adatvesztst vagy ms problmkat okoz-hatnak a felhasznlnak. Mindenkppen elvrs egy eltltvel szemben, hogy negenerljon ilyen lekrdezseket.

Nem egyszer azonban eldnteni, hogy egy lekrdezs melyik csoportba tartozik.Ennek eldntshez olyan informcikra van szksg, amik a proxy szerverben azadott 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, akkornem generl rossz, teht kros mellkhatsokkal jr krseket, s emiatt biztonsgosa hasznlata. A msik krds a hatkonysg szempontjbl fontos: minl tbb olyankrst kell generlni, amihez a kliens is fog azonos krst kldeni.

3.1.4. Biztonsg

Mivel a biztonsg a legfontosabb kvetelmny, rviden megvizsglom, hogy hogyanlehet eldnteni egy krsrl, hogy biztonsgos-e.

Egy HTTP krs megvlaszolsa legtbbszr egy fjl beolvasst s visszaadstjelenti. Azonban emellet (vagy ehelyett) tetszleges logika is trsthat hozz. El-kpzelhet 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 vglegestrlst kezdemnyezi.

J tmpontot ad a HTTP/1.1 szabvny szemantikval foglalkoz rsze [17], amiexpliciten definilja a biztonsgos lekrdezseket (kiemels tlem):

4.2.1. Safe Methods

Request methods are considered safe if their defined semantics are es-sentially 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 methodto a target resource. Likewise, reasonable use of a safe method is not ex-pected to cause any harm, loss of property, or unusual burden on theorigin server.

This definition of safe methods does not prevent an implementation fromincluding behavior that is potentially harmful, not entirely read-only, orwhich causes side-effects while invoking a safe method. What is impor-tant, however, is that the client did not request that additional behaviorand cannot be held accountable for it. For example, most servers appendrequest information to access log files at the completion of every response,regardless of the method, and that is considered safe even though the logstorage might become full and crash the server. Likewise, a safe requestinitiated by selecting an advertisement on the Web will often have theside-effect of charging an advertising account.

Of the request methods defined by this specification, the GET, HEAD,OPTIONS, and TRACE methods are defined to be safe.

38

The purpose of distinguishing between safe and unsafe methods is to allowautomated retrieval processes (spiders) and cache performance optimiza-tion (pre-fetching) to work without fear of causing harm. In addition, itallows a user agent to apply appropriate constraints on the automateduse of unsafe methods when processing potentially untrusted content.

A user agent SHOULD distinguish between safe and unsafe methodswhen presenting potential actions to a user, such that the user can bemade aware of an unsafe action before it is requested.

When a resource is constructed such that parameters within the effectiverequest URI have the effect of selecting an action, it is the resourceowners responsibility to ensure that the action is consistent with therequest method semantics. For example, it is common for Web-basedcontent editing software to use actions within query parameters, suchas "page?do=delete". If the purpose of such a resource is to perform anunsafe action, then the resource MUST disable or disallow that actionwhen it is accessed using a safe request method. Failure to do so willresult in unfortunate side- effects when automated processes performa GET on every URI reference for the sake of link maintenance, pre-fetching, building a search index, etc.

Sajnos a szabvny ezen elrsait ltalban nem tartjk be a weboldalak. Nagyonsok olyan GET metdusra pl API van hasznlatba, ami mellkhatsokat okoz.Kifejezetten gyakoriak az ilyen API-k a hirdetsek esetn. gy gondolom, hogy aszabvny ltal javasolt t nem jrhat, nem lehet egyszeren kijelenteni, hogy a mel-lkhatsokrt nem felels az eltlt algoritmus. Ugyanezt a problmt rszletesenkifejti Brian D. Davison az Assertion: Prefetching With GET Is Not Good [12] c-m cikkben. egy j HTTP metdus bevezetst javasolja, amit az eltltst vgzprogramok biztonsggal hasznlhatnak, mert soha nem jr mellkhatsokkal. Ez ajavaslat nem kapott elg figyelmet, s nem szabvnyostottk, ezrt a webszervereksem tmogatjk.

A mellkhatsok elrejelzsre egy msik, biztonsgosabb utat vlasztottam: aztkell megvizsglnia az eltltnek, hogy mirt jtt ltre az adott krs. Egy HTTP k-rs kzli a szerverrel, hogy a kivlt ok a kliensben bekvetkezett. Pldul egy emailtrlsre utast HTTP lekrdezs kivlt oka az, hogy a felhasznl trls gombrakattintott, a krs pedig errl tjkoztatja a szervert. Ha egy krs kivlt oka olyan,amitl valsznleg nem fgg semmi a szerver oldalon, akkor felttelezhetjk, hogya krsnek nem lesznek mellkhatsai.

Ilyen kivlt ok lehet pldul az, hogy a weboldal HTML kdja kpknt hivatkozikegy adott erforrst. Ez azt okozza, hogy ha a felhasznl bngszjben az erforrs

39

nincs gyorsttrazva, akkor elindul egy HTTP lekrdezs. Mivel a weboldalt hosz-tol szerver kldte a HTML kdot, ezrt a lekrdezs bekvetkezse semmilyen jinformcit nem kzl vele azon fell, hogy az adott erforrs nincs a kliens gyorst-trban. Biztosak lehetnk benne, hogy ez a HTTP krs semmilyen mellkhatshoznem vezet, mert a lekrs nem kzl rdemi informcit a szerverrel.

Ms a helyzet az olyan lekrdezseknl, amik lnyeges krlmnyektl pldulfelhasznli interakciktl, a bngszben trolt adatoktl vagy a bngsz krnye-zetvel kapcsolatos adatoktl fggnek. Egy szkript pldul kzlheti a szerverrelegy HTTP lekrdezs formjban a kliens kpernyfelbontst (mint ahogy az eset-tanulmnyban is trtnt), hogy aztn a szerver ez alapjn egy megfelel mrethirdetst kldjn. Az ilyen tpus krsek hibs elrejelzst minden eltlt imple-mentcinak el kell kerlnie.

Ez alapjn a kvetkez ttelt lehet megfogalmazni:

Ha egy HTTP lekrdezs rdemi informcit kzl a szerverrel, akkorfelttelezhet, hogy van mellkhatsa, ha viszont csak trivilis, vagy l-nyegtelen 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 lekrtHTML fjlt, kls hivatkozsokat keres benne, s elkezdi letlteni azokat. Ezek akls hivatkozsok lehetnek pldul kpek, stluslapok vagy szkriptek. Stluslapokesetn egy CSS parser hasznlatval megoldhat az is, hogy az eltlt a stluslapltal hivatkozott kpeket is letltse.

Statikust elemzst hasznl kt optimalizl proxy implementci is: a Wcol [25] sa ByteMobile. Az elbbi csak letlti a statikus elemzs sorn elrejelzett tartalmakat.Az utbbi viszont letlti s be is gyazza a HTML-be (a begyazs rszletesebblerst lsd a 2.4.3. rszben).

Egy ilyen, statikus elemzst hasznl implementcinak szmos htrnya van. Alegszembetnbb problma az, hogy nem futtatja a begyazott szkripteket. Ez ktkvetkezmnnyel is jr. Egyrszt nem minden krst tud elrejelzni. Az origo.huesetn a fggsgi grf alapjn megllapthat, hogy az sszesen 124 krsbl aHTML kd parse-olsval 21, a CSS parse-olsval s HTML-hez illesztsvel pe-dig tovbbi 48 krs jelezhet elre. Msrszt az is elkpzelhet, hogy tvesen jelezelre lekrseket. A HTML szabvnyban rgztett parse-olsi algoritmus (lsd 1.2.rsz) sajtossgai miatt az eltlt nem lehet biztos benne, hogy a statikus elemzs-sel kinyert erforrsokat a bngsz valban le fogja krni. Elkpzelhet, hogy egy

40

szkript a document.write() fggvnyt hasznlva gy mdostja a HTML-t, hogy ahivatkozott erforrsok egy rszt a bngsz ne krje le.

Egy msik problma a CSS feldolgozst rinti: nem biztos, hogy a CSS fjlban hi-vatkozott sszes kpre szksg lesz az oldal megjelentshez. Elkpzelhet pldul,hogy a weboldal egy egyestett CSS fjlt hasznl az sszes HTML dokumentum-ban, de mindegyik dokumentumra a CSS szablyoknak csak egy kis rszhalmazaalkalmazhat.

Ezek a problmk a szerver oldali mellkhatsok szempontjbl nem kritikusak,mert a generlt felesleges lekrdezsek csak lnyegtelen informcikat (pl. a kliensbngszje 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 nagyonvalszntlen. Ami ennl fontosabb, hogy a statikus elemzsre alapul eltlt csakaz erforrsok egy rszhalmazt tudja elrejelezni, valamint hogy felesleges lekrde-zseket generlhat.

Az, hogy emiatt mennyivel rosszabbul teljest ez az eltlt algoritmus az ide-lis eltlthz kpest, a vizsglt weboldaltl fgg. Az origo.hu esetn pldul avesztesg jelents (a HTML s a CSS beolvassa esetn krlbell 50%). Tovbbikutats trgya lehet annak feldertse, hogy ez a problma ms weboldalakat milyenmrtkben rint.

3.1.6. Dinamikus elemzs

A kvetkez eltlt algoritmus a statikus elemzs problmit oldja meg, ezltala legtbb esetben jobban teljest annl. Ez az algoritmus egy j, elszr ltalamfelvetett tletre alapul.

Egy program vizsglatra kt elterjedt megkzelts ltezik: a statikus s a dina-mikus elemzs. A statikus elemzs a kd lefuttatsa nlkl von le kvetkeztetseketa program mkdsrl, mg a dinamikus analzis a kd viselkedst futtats kz-ben vizsglja. A statikus elemzst vgz algoritmusok ltalban egy-egy specilisclterletre fkuszlnak, s nem kpesek a program egsznek viselkedst lerni.A dinamikus elemzsnl a kdot egy virtulis krnyezetben lefuttatva az figyelhetmeg, hogy a program hogyan lp interakciba a krnyezetvel. Az eltlt algorit-mus esetn a vizsglt program egy weboldalt betlt bngsz (virtulis bngsz),a krnyezet pedig a hlzat, teht a krnyezetvel val interakci HTTP lekrdez-sek indtst jelenti. Ebben az esetben teht clrevezet lehet a dinamikus elemzshasznlata a weboldal elemzsre.

Ahhoz, hogy egy virtulis bngszn alapul eltlt mkdkpes legyen, egynagyon fontos problmt kell megoldani: biztostani kell azt, hogy a virtulis bng-

41

sz a klienssel mindenben azonos krseket generljon. Ha ez nem lehetsges, akkorlegalbb azt, hogy minden krsrl eldnthet legyen, hogy azt a kliens is el fogjaindtani, vagy pedig tves elrejelzsrl van sz.

Egy weboldal a futsa sorn rengeteg olyan informcit felhasznlhat, amit akrnyezettl krdez le. A krnyezete magban foglalja az aktulis szmtgpet, afelhasznlt, a bngszt s mg sok ms tnyezt. Ezeket az adatokat feldolgozza, sbizonyos esetekben HTTP krsek formjban kzli az t hosztol webszerverekkel.Elemzssel minden HTTP krsrl eldnthet, hogy az elindtshoz, s a krsltal kzlt adatok sszelltshoz milyen okok vezettek. Egy virtulis bngszesetn azokat a lekrdezseket kell figyelmen kvl hagyni, amik olyan adatokatfelhasznlva, vagy olyan esemnyek hatsra indultak el, amik a kliensnl s a proxy-nl klnbznek. Ha pldul egy szkript lekrdezi az aktulis idt, majd ezt egyHTTP krsben kzli egy szerverrel, akkor errl a lekrdezsrl teljes biztonsggalllthat, hogy a virtulis bngsz helytelen adatokkal fogja megtlteni, mert a ktkrnyezetben az rk nem lehetnek teljesen szinkronban.

Dinamikus elemzsre alapul eltlts esetn teht egybeesik a biztonsg, s ahatkonysg biztostsnak kulcsa: ki kell szrni azokat a lekrdezseket, amik abngsz krnyezetbl szrmaz informcikat hasznlnak fel.

Hogy lehet egy lekrdezsrl automatikusan megllaptani, hogy milyen ok-okozatisszefggsek rvn jtt ltre? Lehetne pldul a virtulis bngsz JavaScript futta-tmotorjt gy mdostani, hogy minden vltoz rtkrl szmon tartsa azt, hogymilyen ms rtkek lehettek r hatssal. Pldul ha az a vltoz rtke fgg egyvletlenszm rtktl s b vltoz rtke fgg egy URL paramtertl, akkor a c =a + b vltoz rtke fgg mindkt krlmnytl. Ezt az informatikai biztonsgtech-nikban taint checking-nek nevezik. A JavaScript futtatmotorok azonban komplexszoftverek, emiatt ezt nagyon nehz lenne implementlni a virtulis bngszben.

Egy egyszerbb megoldshoz vezet a kvetkez gondolatmenet. Nem felttlenlszksges pontosan feltrkpezni, hogy egy HTTP lekrdezs mitl fgg, mert enl-kl is megllapthat, hogy fgg-e valamelyik krnyezeti hatstl. Nevezzk vlet-lenszer krnyezetnek az olyan virtulis krnyezetet, ami minden lekrdezsre v-letlenszer rtkekkel vlaszol. Egy vletlenszer krnyezetben fut bngszbenbetltd weboldal rszben randomizlt HTTP lekrdezseket fog elindtani. Azrtcsak rszben, mert azok a lekrdezsek, amik meglte, illetve tartalma nem fgg akrnyezettl, minden esetben ugyangy fognak megjelenni. Kt, vletlenszer kr-nyezetben prhuzamosan futtatot bngsz esetn knny megllaptani, hogy melylekrdezsek fggnek a krnyezettl: azok, amiket a kt bngsz ms paramterekkelindt el. Azok a lekrdezsek, amik nem fggnek a krnyezettl, mindkt bngsz-nl 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 in-formcikat hasznlnak fel, amik a proxy-ban nem llnak rendelkezsre. Ezeket alekrdezseket nevezzk informcihinyos lekrdezseknek. Ezeket nem lehet tovb-btani, mert felesleges vagy rossz lekrdezsek. Ehelyett az eltlt implementciezeket eldobhatja, vagy valamilyen specilis mdon kezelheti.

Az ilyen krsek eldobsa, teht megvlaszolatlanul hagysa ahhoz vezethet, hogya 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. Azorigo.hu pldjra visszatrve: a 88-as lekrdezs a hirdet szerverekkel informci-kat kzl a kliensrl, s a vlaszban a megjelentend hirdetsek listjt adja vissza.Az eltlt algoritmus teht a krs eldobsa esetn nem lesz kpes eltlteni ahirdetseket.

Egy sokkal hatkonyabb megolds az, ha az ilyen informcihinyos lekrdezseketszinkronizcis pontknt kezeljk. Ez azt jelenti, hogy az eltlt algoritmus megpr-blja azonostani azt a krst, ami a klienstl szrmazik, s a blokkolt krs-prnakfelel 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 azazvezetne-e hibsan elrejelzett lekrdezsekhez az, hogy a virtulis bngszk egyilyen vlasz megrkezse utn sem fogjk ismerni azokat az informcikat, amikalapjn a kliens a lekrdezst elindtotta. Egy lekrdezs, ami ez utn szletik, aztbb forrsbl hordozhat informcit. Ha az j krs indtshoz csak a vlaszbanrkezett adatokra van szksg, akkor mindkt virtulis bngsz, valamint a kliensis ugyanazt a lekrdezs fogja elindtani. Ha a krs indtshoz tbb forrsbl vanszksg informcira, akkor a kt virtulis bngsz klnbz lekrdezst indt,s jabb szinkronizcis pont jn ltre. Hibsan elrejelzett lekrdezsre teht nemkerlhet 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 nevekhezkttt rvid szveges informci, amit a weboldalon fut szkriptek, vagy az adottdomain-hez tartoz webszerver llthat be. A bngsz minden egyes HTTP krshezelkldi az adott domain-hez tartoz stiket a Cookie HTTP fejlcben.

43

Amikor a kliens az eltltst elindt HTML oldalt lekri, akkor a proxy a lekrde-zsbl 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-rlkell betlteni, amihez a kliens mg nem kldtt lekrdezst. Ilyen esetben a proxynem tudja, hogy a kliens az adott domain-hez milyen stiket trol. Ilyenkor szintnegy specilis szinkronizcis pontot kell ltrehozni, ami egszen addig blokkol, amga klienstl nem rkezik egy lekrdezs erre a domain-re, amibl mr kinyerhet asti rtke. Ezutn az erre a domain-re rkez krseket mr problma nlkl tudjaaz eltlt kezelni.

rtkels

Ez az eltlt algoritmus teht nagy biztonsggal elrejelez minden olyan lekrde-zst, ami nem fgg a proxy ltal elrhetetlen (csak a kliens ltal ismert) informci-ktl. Ennl nagyobb hatkonysg kt mdon rhet el: a biztonsg feladsval vagya kliens ltal birtokolt informcik proxy-ba juttatsval. Az els lehetsg vlem-nyem szerint nem vllalhat (lsd a 3.1.4. pontot), a msodikat pedig nagyon krl-mnyes megvalstani, ha figyelembe vesszk azt, hogy milyen nagy (s a HTML5adattrol API-k megjelensvel egyre nagyobb) az az informcimennyisg, amit akliens trolni kpes. A vletlen szmok s az ra szinkronizci problmjt pedig ezsem oldan meg. Emiatt ez az eltlt algoritmus az elbb emltett alapfeltteleketelfogadva optimlisnak nevezhet.

A mdszer legnagyobb problmja az erforrsignye. Egy weboldal tartalmnakelrejelzshez kt virtulis bngsz futtatsra van szksg. Nagy szm kliensesetn ezek jelents terhelst jelenthetnek egy proxy szervernek.

Az origo.hu esetn ez az elrejelz algoritmus jelentsen jobban teljest a statikuselemzsnl, ami a 124 krsbl a HTML kd feldolgozsval 21, a CSS beolvas-sval pedig tovbbi 48 krs jelez elre. Ez az sszes lekrdezs 56%-a. A virtulisbngszt hasznl mdszer ltal elrejelezhet krsek szma 115, ami 93%-os pon-tossgnak felel meg. Termszetesen nem mindegy, hogy ezek a krsek a fggsgigrfban hol helyezkednek el. Ebben az esetben a 9 informcihinyos lekrdezs k-zl 2 van kedveztlen helyen (a 40. s a 88. szkript), a tbbi a fggsgi grfbankevsb fontos helyen szerepel, gy nem htrltat ms lekrdezseket.

44

3.2. Eltlts a kliensbe

A kliensbe val eltltshez teljes mrtkben jrahasznosthatk az elz pontbanismertetett technikk. A proxy a fenti mdszereket hasznlva elkezdheti eltlteni azegyes erforrsokat, s a megfelel eszkzk birtokban ezeket mr azeltt elkezdhetia kliens