}w!"#$%&'()+,-./012345<ya

}w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Analýza času stráveného na webových stránkách BAKALÁŘSKÁ PRÁCE Kamil Andoniadis Brno, jaro 2015

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Kamil Andoniadis Vedoucí práce: RNDr. Marek Kumpošt, Ph.D ii

Poděkování Chtěl bych poděkovat svému vedoucímu RNDr. Marku Kumpoštovi, Ph.D. a konzultantu Mgr. Karolu Kubandovi za hodnotné rady a připomínky při řešení této práce. Dále bych chtěl poděkovat rodině a přátelům za trpělivost, kterou se mnou měli v době psaní vlastní práce. iii

Shrnutí Cíl této práce je měřit čas strávený na webových stránkách všemi uživateli lokální sítě tak, aby si nemuseli na své zařízení instalovat žádné sledovací aplikace. Zároveň naměřené informace ukládat do databáze a zprostředkovávat je pomocí jednoduché vizualizace. Teoretická část se zabývá existujícími nástroji na analýzu času stráveného na webových stránkách, jejich vzájemným odlišnostem a významem proxy serveru pro tuto práci. Výstupem práce je modifikovaný proxy server, který vkládá měřící skript do všech html dokumentů směřujících do lokální sítě a webový server, který přijímá a zpracovává naměřené informace. iv

Klíčová slova proxy server, javascript, html, analýza času, databáze v

Obsah Úvod.................................. 1 1 Motivace.............................. 3 1.1 Proxy Server......................... 3 1.1.1 Typy Proxy..................... 4 1.1.2 Význam Proxy................... 5 1.2 Možnosti dostupné analýzy................ 6 1.2.1 Analýza času na webové stránce......... 7 1.2.2 Analýza času jednoho uživatele......... 7 1.2.3 Analýza času na bráně............... 9 1.3 Měřící skript......................... 9 2 Návrh................................ 10 2.1 Architektura řešení..................... 10 2.1.1 Návrh Měřícího algoritmu............. 10 2.2 Uvažované Proxy servery................. 11 2.3 Uvažované Web servery.................. 13 2.4 Uvažované databáze.................... 14 3 Řešení............................... 16 3.1 Popis navrženého měřícího scriptu............ 16 3.1.1 Měření aktivity uživatele na stránce....... 16 3.1.2 Struktura html a iframe.............. 18 3.1.3 Posílání dat webovému serveru.......... 21 3.2 Modifikace Tinyproxy................... 23 3.2.1 Komprese/Decomprese html dokumentu.... 25 3.2.2 Místo vložení měřícího skriptu.......... 27 3.3 Webový server Express nad platformou Node.js a databáze PostgreSQL..................... 31 3.3.1 Použití Node.js................... 32 3.3.2 PostgreSQL a Tabulky databáze......... 33 3.3.3 Vizualizace naměřených dat............ 33 3.4 Úprava dat v databázi................... 36 vi

Závěr.................................. 38 Příloha A Soubory odevzdané v IS............... 39 Příloha B Vytvořené soubory................... 40 Příloha C Upravené soubory................... 41 vii

Úvod Žádná instituce nechce, aby její zaměstnanci využívali prostředky instituce pro své soukromé účely. Slovní zákaz není žádná bariéra a zaměstnanec tak může nehlídané prostředky používat, jak uzná za vhodné. To platí i v případě internetu, který není pouze jednoúčelový nástroj, ale zprostředkovává nám komunikaci, přístup k důležitým informacím i zábavě. Internetová komunikace se dá snadno sledovat a stejně snadno filtrovat nebo úplně blokovat. Co pro jednu instituci je pouze zábavou může pro druhou být cílem, proto záleží na managementu každé instituce, jak s informacemi o čase stráveném zaměstnanci na internetu naloží. Spokojený pracovník je efektivní pracovník, a proto zakazovat uživatelům přístup kvůli občasným krátkodobým návštěvám stránek nesouvisících s cíly instituce není vhodným přístupem. Cíl této práce je měřit čas strávený na webových stránkách všemi uživateli lokální sítě tak, aby si nemuseli na své zařízení instalovat žádné sledovací aplikace. Zároveň naměřené informace ukládat do databáze a zprostředkovávat je pomocí jednoduché vizualizace. K tomuto účelu upravím proxy server tak, aby vkládal měřící skript do každého html dokumentu, který směřuje do lokální sítě, a vytvořím webový server, který přijímá a zpracovává naměřené informace. Ve své práci se zabývám pouze komunikací nešifrovaným protokolem HTTP [2]. Vkládání měřícího skriptu do šifrovaného dokumentu by navíc vyžadovalo aby proxy server rozdělil komunikaci, cílovému serveru poslal svůj veřejný klíč, odpověd serveru dešifroval, pozměnil obsah a znovu zašifroval pomocí veřejného klíče uživatele. Těmto problémům se ale ve své práci nevěnuji. V první kapitole zmíním význam a funkcionality, které může proxy server implementovat. Zároveň popíši existující nástroje na analýzu času stráveného na webových stránkách a vysvětlím, v čem 1

se liší od cíle této práce. V druhé kapitole uvedu stručný popis všech uvažovaných i zvolených komponent, jejich vzájemnou komunikaci a navrhnu měřící skript. V poslední kapitole se zabývám praktickou částí, která se skládá z implementace měřícího skriptu, webového serveru s databází a modifikace proxy serveru. V závěru zhodnotím, čeho jsem dosáhl a zmíním možnosti dalšího rozšíření. 2

Kapitola 1 Motivace Z analýzy sít ového provozu mohu získat požadavek, čas jeho odeslání i obsah odpovědi na požadavek, ale informace, jak dlouho měl uživatel stánku zobrazenou, zůstává ukryta. Musel jsem do prohlížeče uživatele vložit skript, který měří dobu zobrazené stránky a naměřená data posílá do databáze. Bylo by neefektivní nutit každého uživatele k instalaci sledovací aplikace na každé své zařízení, které bude v síti používat. A v případě, že by se na některá zařízení zapomnělo, byla by data a následná analýza neúplná. Snazší je modifikovat odpověd na každý požadavek vložením jednoduchého skriptu, který bude vykonávat zmíněnou funkcionalitu. Abych mohl modifikovat odpovědi serverů z internetu, potřebuji sledovat komunikaci procházející bránou do lokální sítě na aplikační úrovni a to prostřednictvím Proxy serveru. 1.1 Proxy Server Proxy je počítačový proces často používaný jako firewall nebo jeho součást, který navazuje spojení mezi klientem a serverovým počítačovým systémem tím, že se klientu jeví jako cílový server a serveru jako klient. Proxy není striktně určen pro serverové stanice a tak může být spuštěn i na osobním počítači [4]. Firewall Internetová brána, která omezuje provoz datové komunikace z jedné sítě do druhé. Firewall typicky chrání menší vnitřní sít nebo i jen jednoho uživatele před větší sítí jako je internet. Firewall aplikuje pravidla bezpečnostní politiky a řídí provoz mezi sítěmi [5]. Brána (anglicky Gateway) Mechanismus spojující dvě nebo více po- 3

1. MOTIVACE čítačových sítí s podobnou funkcionalitou ale odlišnou implementací a umožňující komunikaci dvěma zařízením z různých sítí. Brána je rozhraní mezi dvěma počítačovými sítěmi. V teorii uvažujeme bránu na jakékoli vrstvě OSI referenčního modelu. V praxi brána pracuje na třetí vrstvě jako router a sedmé jako Proxy server. Pokud dvě sítě poskytují zařízením své služby pomocí jiných protokolů, může brána přeložit jeden protokol do druhého nebo jinak usnadnit komunikaci [4]. OSI (anglicky Open Systems Interconnection) Sedmi vrstevný referenční model standardu ISO-ITU-T I7498. Architektura komunikace různých vrstev v počítačových sítích. Vrstvy od nejvyšší po nejnižší jsou Aplikační, Prezenční, Relační, Transportní, Sít ová, Datového spoje a Fyzická [4]. 1.1.1 Typy Proxy Forward Proxy - Tento typ Proxy vykonává v lokální síti funkci brány. Uživatel posílá své požadavky Proxy serveru, který požadavek přeposílá cílovému serveru. Odpověd pak podle zaměření zpracuje a posílá klientovi (obrázek 1.1). Obrázek 1.1: Forward Proxy 1. Open Proxy Proxy server přístupný všem v internetu, jehož cílem je většinou zabezpečená komunikace s klientem a jeho anonymizace (obrázek 1.2). Reverse Proxy Vykonává funkci brány pro serverová pole. Klientovi se reverse Proxy jeví jako cílový server, ale jeho požadavek 1. http://www.tutorialspoint.com/internet_technologies/ proxy_servers.htm 4

1. MOTIVACE Obrázek 1.2: Open Proxy 2. je přeposílán dál ke skutečnému serveru. Reverse Proxy často mívá i jiné funkcionality například šifrování, komprese a vyvažování zátěže(obrázek 1.3). Obrázek 1.3: Reverse Proxy 3. 1.1.2 Význam Proxy Proxy server komunikuje s koncovými uzly na aplikační úrovni a díky tomu může provést detailní rozbor každé přijaté informace a rozhodnout se co s informací udělá dál. Některé funkcionality, které mohou Proxy implementovat: Autentizace Proces ověřování identity uživatele za účelem zpřístupnění systémových zdrojů. Proxy může rozlišovat mezi uživatelskými účty i příslušnost ke skupině, na jejichž základě pak zpřístupnit sít ové služby a komunikace. 2. http://www.tutorialspoint.com/internet_technologies/ proxy_servers.htm 3. http://www.tutorialspoint.com/internet_technologies/ proxy_servers.htm 5

1. MOTIVACE Filtrování Součástí firewallu bývá podpora filtrování, díky níž je možné implementovat pravidla bezpečnostní politiky i politiky přístupu. Příklad některých běžných metod pro filtrování obsahu: URL, DNS blacklist, URL regex filtering, MIME filtering nebo filtering založený na klíčových slovech v obsahu 4. Šifrování Podpora šifrovaného spojení mezi klientem a Proxy. Kešování Kešovací Proxy urychluje spojení mezi klientem a Proxy tím, že lokálně ukládá odpovědi serverů na časté dotazy klientů. Kvůli této funkcionalitě vznikly Proxy servery. Komprese Pomáhá urychlit přenos dat po síti mezi klientem a serverem. Komprese může snížit velikost přenášených dat až desetinásobně. Anonymita - Proxy modifikuje hlavičky dotazu odeslané klientem tak, aby nikdo z vnější strany sítě nemohl identifikovat uživatele ani zařízení, ze kterého dotaz odeslal. Logování Zaznamenává informace o požadavcích klienta i odpovědi serveru, zpravidla čas přijetí požadavku i odpovědi, metoda HTTP požadavku, požadované URL nebo množství přenesených dat. 1.2 Možnosti dostupné analýzy Při delším čase stráveném prací na počítači je člověk snadno rozptýlen, zaujme jej chytrá reklama, vyhledá si své oblíbené internetové stránky a než se vzpamatuje, ztratí mnoho času. Detailní analýza času, který uživatel stráví na internetu, poskytuje spoustu informací o tom, kdy byl uživatel rozptýlen, čím a jak dlouho. Ze záznamů navštívených URL je možné určit zájmy uživatele i jeho pohyb na stránkách. Z většího množství informací o jedné stránce můžeme vyčíst čím je atraktivní a čím naopak zcela nezajímavá. Dlouho- 4. http://cs.wikipedia.org/wiki/proxy_server 6

1. MOTIVACE dobější analýza ukazuje informace o návycích uživatelů a změnách jejich osobních zájmů. Existuje celá řada nástrojů pomocí níž lze provádět takovou analýzu času. Dovolil jsem si je rozdělit do tří kategorií podle zaměření. 1.2.1 Analýza času na webové stránce Měřící skript je součástí zdrojového kódu webové stránky, měření je prováděno v prohlížeči uživatele, ale data jsou asociována pouze s jednou konkrétní stránkou. Pro analytiky je v tomto případě důležitější zajímavost webu a struktura stránky. Naopak konkretizace uživatele je prováděna na úrovni států a relací. Z průzkumů 5 vychází, že více jak 50% webových stránek, které používají nástroj pro analýzu, používá právě Google Analytics. Google Analytics 6 Statistický nástroj, který umožňuje majitelům webových stránek sledovat pohyb návštěvníků na jejich stránkách, jejich demografické údaje i jimi provedené konverze. Majitel webových stránek musí jen vložit službou vygenerovaný skript na každou stránku, ze které chce získat nějaké informace. A v účtu Google Analytics určí jaké statistiky chce sledováním získat. Google Analytics má opravdu bohatou nabídku možného nastavení sledování. Mimo sledování času a pohybu, který uživatel strávil na stránce, umí Google Analytics zjistit i několik stránek, které uživatel navštívil před sledovaným webem a tím zjistit z kterých webů přichází návštěvníci a kde se vyplatí mít reklamy a kde ne. Umí rozlišit mezi návštěvníkem a zákazníkem, který splnil nějaký z předem určených cílů nákup zboží, stažení souboru, použití aplikace a zjistit o něm i demografické údaje jazyk, země, zařízení, prohlížeče, operační systém. 1.2.2 Analýza času jednoho uživatele Analýzu provádí aplikace běžně instalována na osobním počítači uživatele, kde měření neovlivní výpadek sítě ani nepředvídané 5. http://w3techs.com/technologies/overview/traffic_ analysis/all 6. http://www.google.com/intl/cs_all/analytics/features/ index.html 7

1. MOTIVACE ukončení prohlížeče. Takový nástroj bývá často rozšířen i o analýzu času, který uživatel tráví v rámci počítače mimo webový prohlížeč. Tyto nástroje jsou vynikající pro analýzy vlastního času, nicméně v globálním měřítku nemají reálné využití. Pro tuto kategorii jsem vybral dva zástupce ResqueTime a Manic Time. RescueTime 7 Mobilní i počítačová aplikace, která sbírá informace o čase stráveném v rámci operačního systému a tyto informace posílá ke zpracování na web RescueTime. Tato aplikace kategorizuje každý spuštěný program i každou webovou stránku aby mohla později rozhodnout, zda byl čas strávený na počítači využit k zábavě nebo práci. RescueTime umožňuje uživateli změnit některá standardní nastavení, která se týkají kategorií. Například pokud je uživatel správce webu se zábavou, nebude chtít, aby jeho čas strávený na tomto webu byl řazen do kategorie zábavy a následně vyhodnocen jako neproduktivní. RescueTime zobrazuje naměřené informace v souhrnných statistikách za měřené období jednoho dne, týdne, měsíce nebo roku s pohledy na webové stránky a aplikace, kategorie, produktivitu uživatele nebo stanovené cíle. ManicTime 8 Aplikace je spustitelná pouze na platformě.net, má vlastní databázi a na rozdíl od RescueTime neposílá žádná data po síti a vše vyhodnocuje lokálně. ManicTime zobrazuje informace pouze na časové ose jednoho dne, kde uživatel vidí, kolik času strávil s konkrétní aplikací a v případě webového prohlížeče, kterého stránky navštívil. Do této časové osy může uživatel označit, kdy pracoval například na firemním projektu i offline aktivity jako konference a firemní hovory. A na základě těchto značek vygeneruje ManicTime report, který je tou nejzajímavější statistikou této aplikace. Ostatní statistiky zobrazují pouze nejpoužívanější aplikace a nejnavštěvovanější webové stránky. 7. https://www.rescuetime.com/features 8. http://www.manictime.com/ 8

1. MOTIVACE 1.2.3 Analýza času na bráně V předchozích dvou kategoriích jsem uvedl analýzu prováděnou přímo na webové stránce, která zahrnovala mnoho uživatelů, ale pouze jednu konkrétní stránku a analýzu prováděnou na počítači uživatele, která zahrnovala analýzu více stránek, ale pouze jednoho konkrétního uživatele. V tomto případě analýza zahrnuje všechna zařízení internetového provozu schované za jednou konkrétní bránou a všechny jejich požadavky na webové stránky. Do této kategorie patří opravdu málo použitelných nástrojů, většinou jde o aplikace třetích stran pro aplikační Proxy a to je jeden z důvodů, proč vznikla tato práce. Zde uvedu pouze Squint, aplikaci určenou pro kešovací Proxy Squid (více o Squid v kapitole 2.2 Uvažované Proxy servery). Squint 9 Squint periodicky analyzuje záznamy Squid proxy a generuje záznam o uživatelých komunikujících prostřednictvím proxy. Vygenerovaná zpráva obsahuje detailní historii návštěv webových stránek každého uživatele spolu s přibližným časem, který uživatel trávil na zmíněných stránkách. Squint předpokládá, že uživatel aktivně prohlíží webový obsah maximálně 2 minuty po načtení stránky a že uživatel ukončil relaci, pokud se o něm v proxy záznamu nenachází žádná zpráva po dobu 5 minut. 1.3 Měřící skript V motivaci jsem zmínil, že měření času stráveného na webových stránkách musím provádět na stroji každého uživatele v rámci lokální sítě. Proto musí být měřící skript spustitelný nejlépe v každém webovém prohlížeči. Všechny majoritní webové prohlížeče mají implementovaný interpreter javascriptového kódu, ale složitější konstrukce v různých interpreterech mohou končit s odlišnými výsledky. Zároveň se v různých prohlížečích liší práce s událostmi a objektovým modelem dokumentu (anglicky Document Object Model 10, dále jen DOM). 9. http://www.ledge.co.za/software/squint/index.php 10. http://www.w3.org/dom/ 9

Kapitola 2 Návrh Celý systém na měření času stráveného uživatelem na webových stránkách se skládá ze čtyř komponent: 1. Měřící skript implementovaný v jazyce Javascript. 2. Proxy server který vkládá tento skript do html dokumentu. 3. Databáze na ukládání naměřených dat. 4. Webový server který přijímá a ukládá data poslaná skriptem do databáze a zprostředkovává data uživateli. 2.1 Architektura řešení Komunikaci všech komponent od uživatelova poslaného požadavku jsem zobrazil v následujícím sekvenčním diagramu (obrázek 2.1). Proxy přepošle uživatelův požadavek cílovému serveru a až proxy obdrží odpověd, vloží měřící skript do přijatého html dokumentu. Javascript se do html dokumentu vkládá dvěma způsoby. Přímo vložením javascriptu mezi otvírající a zavírající script tag nebo URL adresou v atributu src vloženého script elementu. Zvolil jsem druhý způsob, abych oddělil správu měřícího skriptu od proxy a nezatěžoval proxy vkládáním celého kódu. Samotný skript se stáhne a spustí až po načtení patřičného script elementu. 2.1.1 Návrh Měřícího algoritmu Nejdříve skript po načtení zjistí, zdali je stránka aktivní a viditelná. Potom už jen využívám událostí DOM, abych detekoval akti- 10

2. NÁVRH Obrázek 2.1: Komunikace všech komponent. vitu uživatele a posílal data v pravidelném časovém intervalu. Algoritmus detekce aktivity a posílání naměřených dat webovému serveru jsem vyjádřil následujícím diagramem (obrázek 2.2). Naměřená data webový server načte z query řetězce dotazu a vloží do databáze. Obrázek 2.2: Diagram aktivit měřícího skriptu. 2.2 Uvažované Proxy servery Existuje několik proxy serverů s otevřenými zdrojovými kódy, sám jsem ale uvažoval pouze nad třemi z nich. Prioritou pro mě byla 11

2. NÁVRH snadná modifikovatelnost, aby proxy server nebyl příliš velký a systémově náročný. Node.js 1 Platforma postavená na javascript engine V8 2 společnosti Google. Stejný engine používá Google ve svém prohlížeči Chrome 3. Tato platforma slouží pro jednoduché a rychlé vytváření škálujících webových aplikací. NodeJS používá událostmi řízený, neblokující I/O model, který z něj dělá systémově nenáročnou a efektivní platformu. Tento model je kontrastem k současným modelům založených na vláknech. Uživatelé se nemusí obávat uváznutí (anglicky deadlock), protože rozhraní, které Node poskytuje, nemá žádné zámky a téměř žádné funkce nepracují přímo se vstupy ani s výstupy. Proto nejsou procesy nikdy blokovány a i nezkušení vývojáři jsou schopni vytvářet vysoce škálovatelné webové aplikace. Node byl ovlivněn a podobně designován jako EventMachine 4 pro Ruby nebo Twisted 5 pro Python. Node je licencován pod MIT 6. Samotný Node.js není webový proxy server, k tomuto účelu bych musel použít jeden z modulů implementovaných pro tuto platformu. Na výběr existuje několik variant, které by pro jednotlivce nebo malou sít byly ideální, ale nebyl jsem přesvědčen, že by byl proxy server na runtime platformě ideální pro větší sít. Squid 7 Squid je plně funkční kešovací webproxy podporující HTTP, HTTPS, FTP a jiné protokoly. Proxy šetří šířku pásma a vylepšuje reakční dobu ukládáním lokálních kopií často dotazovaných webových stránek a jejich znovupoužíváním. Squid spíše kopíruje často používaný obsah než neefektivně vše. Zároveň může směrovat obsah dotazů na servery mnoha různými způsoby a tím vytvořit hierarchii kešovacího serveru, který optimalizuje průtok, značně redukuje zátěž serveru a zlepšuje čas doručení ke klientu. Squid nabízí bohaté řízení přístupu, autorizace, logovací prostředí pro vývoj 1. https://nodejs.org/about/ 2. https://code.google.com/p/v8/ 3. https://www.google.com/chrome/browser/desktop/index.html 4. http://rubyeventmachine.com/ 5. https://pypi.python.org/pypi/twisted 6. http://opensource.org/licenses/mit 7. http://www.squid-cache.org/intro/ 12

2. NÁVRH webové proxy i bohatou nabídku možností optimalizace provozu. Většina optimalizace je v základním nastavení pro jednodušší instalaci a vyšší výkon. Squid je multiplatformní proxy server a je licencován pod GNU GPLv2 8. Rozhodl jsem se neimplementovat svoji práci do tohoto proxy serveru, protože má velké množství zdrojových kódů a funkcí, kterých bych nevyužil. Tinyproxy 9 Tinyproxy je systémově nenáročný HTTP a HTTPS proxy démon pro POSIX 10 kompatibilní operační systémy. Navržený od základu aby byl rychlý a přesto malý. Je to ideální řešení pro vestavěné systémy, kde je požadována plně funkční proxy, ale systémové zdroje pro větší proxy nejsou dostupné. Tinyproxy je licencována pod GNU GPLv2. Tinyproxy vyžaduje velmi málo systémových zdrojů. S použitím knihovny glibc 11 zabírá pouze 2MB v operační paměti. Zátěž CPU roste lineárně s počtem souběžných spojení, proto může Tinyproxy běžet i na starších strojích, nebo na sít ových zařízeních s vestavěným UNIXovým systémem. Tinyproxy podporuje pomocí connect metody dopředné HTTPS spojení bez modifikace provozu, transparentní proxy i reverse proxy. Pro svoji práci jsem zvolil Tinyproxy, protože má malé systémové nároky, je snadno modifikovatelný a je implementován v jazyce C. 2.3 Uvažované Web servery Už při hledání proxy serveru mě zaujal javascriptový interpreter a framework v jednom NodeJS. Zároveň mě zaujalo, s jakou jednoduchostí v něm jde vytvořit webový server a jeden takový prezentuji v následující ukázce. Zde jsem příliš neuvažoval nad jinými alternativami. Našel jsem modul Express 12, který nad platformou generuje základní kostru webového serveru s jednou jednoduchou stránkou. Součástí Express je i html preprocesor Jade 13. 8. https://www.gnu.org/licenses/license-list.html 9. https://banu.com/tinyproxy/ 10. https://www.ietf.org/timezones/data/theory 11. http://www.gnu.org/software/libc/ 12. http://expressjs.com/ 13. http://jade-lang.com/ 13

var http = require( http ); http.createserver(function (req, res) { res.writehead(200, { Content-Type : text/plain }); res.end( Simple site\n ); }).listen(80, 127.0.0.1 ); 2. NÁVRH Express Malý a flexibilní framework pro platformu NodeJS. Middleware s mnoha užitečnými metodami poskytuje robustní základ pro webové i mobilní aplikace a zároveň nijak neomezuje funkce platformy. Jade Zjednodušující jazyk pro psaní html šablon. Produkuje html kód, podporuje dynamické kódování a znovu používání kódu. 2.4 Uvažované databáze Mongodb 14 Dokumentově orientovaná NoSQL 15 databáze, která ukládá data do dokumentů ve formátu binární JSON 16. Oproti relačním databázím používá dynamické schéma, které nemusí být vůbec definováno. Proto přidání atributu do jednoho dokumentu nevyžaduje změnu ostatních dokumentů ani samotného schématu. Mongodb podporuje šifrovanou komunikaci, logování, autentizaci, autorizaci a na úrovni dokumentů ACID 17 vlastnosti. Mongodb může globálně škálovat mezi několika distribuovanými datovými centry a na rozdíl od jiných NoSQL databází, není limitován pouze na dotazy typu klíč-hodnota, ale podporuje i rozsahové a prostorové dotazy, regulární výrazy a funkce v jazyce javascript. Původně jsem ve své práci použil Mongodb, ale nevyhovoval mi zápis dotazů a velikost databáze. Mongodb při instalaci vygeneruje 3 soubory pro bod obnovy, aby se v případě chyby neztratily žádné informace. Velikost každého z těchto souborů je 1.1GB a velikost programového vybavení Mongodb asi 200MB. 14. http://www.mongodb.com/mongodb-architecture 15. http://martinfowler.com/bliki/nosqldefinition.html 16. http://json.org/ 17. http://lightwolftech.com/index.php?page=backgrounders 14

2. NÁVRH PostgreSQL 18 Silný objektově relační databázový systém s otevřenými zdrojovými kódy. Tato databáze je 15 let pod aktivním vývojem a za tu dobu si získala silnou reputaci pro spolehlivost, integritu a správnost. Databáze je licencována pod PostgreSQL licencí 19 a pustitelná na většině operačních systémů, včetně Linux, UNIX (BSD, Mac) i Windows. Rozhodl jsem se pro tuto databázi, protože jsem lépe obeznámen s dotazovacím jazykem SQL 20 a protože čistá instalace databáze PostgreSQL zabírá na disku pouze 62MB, z toho 20.6MB je samotný software. 18. http://www.postgresql.org/about/ 19. PostgreSQL licence je podobná BSD nebo MIT http://opensource.org/ licenses/postgresql 20. http://en.wikipedia.org/wiki/sql 15

Kapitola 3 Řešení Jak jsem zmínil v návrhu, tato práce se skládá ze tří částí a v této kapitole se budu postupně věnovat všem. Nejdříve popíši měřící skript, který bude spouštěn v prohlížeči uživatele a bude posílat naměřená data webovému serveru. V další části se budu věnovat všem důležitým modifikacím v Tinyproxy, konfiguraci i instalaci. Poté provedu instalaci databáze PostgreSQL, webového serveru Express, nastavím spojení s touto databází a objasním funkce obsluhující databázi ze sítě prostřednictvím protokolu HTTP [2]. Ke konci zmíním ještě možné úpravy a dodatečné konfigurace. 3.1 Popis navrženého měřícího scriptu Vzhledem k existenci vícero prohlížečů jsem uvažoval měřící skript co nejuniverzálnější. Každý prohlížeč může mít odlišně implementovaný javascriptový interpreter, což při použití složitějších konstrukcí nebo frameworků může vést k odlišným výpočetním výsledkům. Navíc mohou poskytovat nad základním javascriptem další konstrukce nebo události DOM, které by v jiných prohlížečích nefungovali. 3.1.1 Měření aktivity uživatele na stránce Nejdříve jsem řešil, jakým způsobem bude skript detekovat aktivní stránku nebo aktivitu uživatele a kdy bude posílat naměřená data serveru. DOM umožňuje skriptovacím jazykům reagovat na události vyvolané prohlížečem nebo uživatelem. 16

3. ŘEŠENÍ Událostmi onmousemove, onscroll a onkeypress lze detekovat přímou aktivitu uživatele. Čas bych mohl měřit nastavením časového intervalu, který by určoval maximální vzdálenost dvou událostí jednoho časového úseku. To znamená, jakmile měřící skript detekuje jednu ze zmíněných událostí, čeká maximálně po dobu intervalu na další z událostí. Pokud další z událostí detekuje, čeká znovu od poslední události, dokud nedetekuje žádnou a tím označí tento časový úsek jako uzavřený a posílá data webovému serveru. Pro detekci aktivní stránky použít události onfocus a onblur. Událost onfocus je spuštěna ve chvíli kdy se stránka stává aktivní v rámci operačního systému. Naopak událost onblur je spuštěna bud když záložka se stránkou přestává být aktivní nebo když celý prohlížeč přestává být aktivní. V ideálním případě by se čas měřil od události onfocus do onblur nebo onbeforeunload, která se spouští těsně před opuštěním nebo uzavřením stránky. Ale protože na tuto událost není možné v některých prohlížečích reagovat jinak, než potvrzujícím dialogem, je potřeba čas měřit od události onfocus v nastaveném intervalu do události onblur nebo uzavření stránky. Dalším způsobem je událost visibilitychange popsaná v dokumentu doporučovaném organizací World Wide Web Consortium 1 (dále jen W3C). Událost indikuje změnu vlastnosti hidden v dokumentu. Rozdíl oproti předchozímu řešení je, že pokud je stránka v aktivní záložce a není minimalizovaná, tak přestože je jiná aplikace aktivní a zcela zakrývá prohlížeč, má vlastnost hidden stále hodnotu false. To znamená, že měření by pokračovalo, i kdyby se uživatel věnoval jiné aplikaci. Událost visibilitychange i vlastnost hidden se v prohlížečích vyskytují pod jinými názvy. Pro svoji práci jsem zvolil druhou variantu s použitím událostí onfocus a onblur, která ale neřeší, zda je stránka aktivní v momentě načtení, proto ihned po načtení resp. v reakci na událost onload 1. http://www.w3.org/ 17

3. ŘEŠENÍ zkontroluji vlastnost hidden. Navíc pokud je stránka načtena v neaktivní záložce, může první aktivace v některých prohlížečích spustit událost onfocus dvakrát. Tuto skutečnost je potřeba ošetřit například proměnnou uchovávající aktuální stav viditelnosti a při spuštění události kontrolovat zda k ní již nedošlo. Kód, který detekuje aktivní stránku a spouští měření, vypadá následovně: var hasfocus = false; window.onload = function(){ if(!document["hidden"] &&!hasfocus && windowtop === 1){ hasfocus = true; start(); } }; window.onblur = function(){ if(hasfocus){ hasfocus = false; clearinterval(sendinterval); stop(); } }; window.onfocus = function(){ if(!hasfocus){ hasfocus = true; start(); } }; 3.1.2 Struktura html a iframe Internetová stránka je tvořena kořenovým html elementem, který má dva volitelné elementy head (hlavička dokumentu) a body (tělo dokumentu). Hlavička obsahuje metadata spjatá s celým dokumentem například název dokumentu, jméno autora, kaskádové styly nebo kódování. V těle dokumentu se pak nachází elementy, které formátují vzhled stránky a poskytují informace uživateli. Html element říká prohlížeči, kde začíná internetový dokument, ale tento element 18

3. ŘEŠENÍ nemusí být na stránce jedinný. Pomocí elementů object, iframe k a embed je možné vložit do jednoho dokumentu jiný i z odlišného URL. Dokumenty se pak chovají jako samostatné stránky v jedné záložce prohlížeče. Když je jeden dokument aktivní, je druhý neaktivní a naopak. To vede k implementačním otázkám: Zajímají mě v analýze vložené dokumenty? Pokud nezahrnu do analýzy tyto dokumenty, může mě uživatel obejít? Uživatel by mohl vytvořit html dokument s elementem iframe a zdrojovou adresou požadované stránky. A dokud by po načtení stránky nezacílil myší ani klávesnicí dokument uvnitř iframe, o stránce by nebyl v analýze žádný záznam, protože by zmíněný dokument uvnitř iframe nespustil událost focus. Nejideálnější by bylo, kdyby měřící skript zahrnoval URL všech zobrazených dokumentů na stránce. Problém je, že dokumenty spolu mohou komunikovat nebo si vzájemně číst obsah pouze pokud neporušují politiku stejného původu (anglicky Same-Origin Policy). Same-Origin Policy 2 (dále jen SOP) Dva dokumenty mají stejný původ, pokud jsou na webu dostupné stejným protokolem na stejném hostu i portu. SOP určuje jak dokumenty nebo skripty načtené z jednoho původu mohou ovlivňovat zdroje načtené z jiného původu a tím zabránit případným útokům Cross-Site Request Forgery 3. SOP rozlišuje mezi posílanými a přijímanými informacemi. Jeden původ může data posílat, ale nemůže je přijímat. Smysl zákazu je zabránit škodlivým webovým stránkám číst důvěrné informace jiných stránek. Z html dokumentu mohu získat elementy bezprostředních potomků vkládající html dokumenty. Ale kvůli SOP nemohu tyto dokumenty číst a v případě vícenásobného vnoření takto nezískám všechna URL. Z potomka html dokumentu získám URL bezprostředního 2. https://www.w3.org/security/wiki/same_origin_policy 3. https://www.owasp.org/index.php/cross-site_request_ Forgery_(CSRF) 19

3. ŘEŠENÍ rodiče pomocí vlastnosti dokumentu referrer, ale v případě vícenásobného zanoření nezískám nejvyššího rodiče a nezískám sourozence. Uvažujme html dokument A: <html> <head> <script> // skript dokumentu A </script> </head> <body> <iframe src= B > <html> <head> <script> // skript dokumentu B </script> </head> <body> <iframe src= D > <html> <head> <script> // skript dokumentu D </script> </head> </html> </iframe> </body> </html> </iframe> <iframe src= C > <html> <head> <script> // skript dokumentu C </script> </head> <body> </body> </html> </iframe> </body> </html> 20

3. ŘEŠENÍ Skript dokumentu A zná zdrojové adresy dokumentů B a C, ale nezná D. Skript dokumentu B zná zdrojové adresy dokumentů A a D, ale nezná C. Skript dokumentu C zná zdrojovou adresu dokumentu A, ale nezná B a D. Skript dokumentu D zná zdrojovou adresu dokumentu B, ale nezná A a C. Ve své práci jsem se toto rozhodl řešit tak, že ihned po načtení dokumentu posílá skript webovému serveru echo zprávu (oznámení že stránka byla načtena), jež součástí je i informace zda se jedná o nejvyšší html dokument. Po načtení dokumentu A v prohlížeči by databáze obdržela 4 echo zprávy, ale pouze u zprávy z dokumentu A by byla informace, že se jedná o nejvyšší html dokument. Pokud by analytiky zajímala hierarchie potomků je potřeba upravit měřící skript, aby posílal i informaci o rodiči a upravit webový server s databází aby tuto informaci byli schopni přijmout. Během analýzy by pak bylo možné zrekonstruovat, které dokumenty spolu byly na jedné stránce a dobu strávenou v dokumentech potomků případně zahrnout pod nejvyšší rodičovský dokument. 3.1.3 Posílání dat webovému serveru Posílání nebo příjímání dat ze serveru spadá do problematiky SOP s několika výjimkami: <script> element na skripty <link> element na kaskádové styly <img> element na obrázky <audio> a <video> na zvuková a video média <object>, <embed> a <applet> na plug-iny vše co přijde s <frame> a <iframe> 21

3. ŘEŠENÍ Každý z těchto elementů vytvoří zprávu GET protokolu HTTP s URL obsaženou v atributu src. Součástí URL může být tzv. query řetězec, který nespadá do hierarchické struktury unikátních cest URL. Query řetězec začíná znakem? a obsahuje páry: jméno=hodnota oddělené znakem &. Webový server na základě hodnot takového řetězce posílá odlišné odpovědi. Tento způsob byl původně určen pro specifikaci uživatelova požadavku, nicméně na straně serveru mohu například tyto specifické údaje vkládat do databáze. Naměřená data měřícím skriptem posílám webovému serveru právě tak, že do aktuálního html dokumentu vkládám script element s adresou webového serveru v atributu src a naměřenými informacemi v query řetězci. Ze dvou důvodů posílám zprávy webovému serveru dvojího typu echo a data. Pokud bych posílal pouze zprávy s naměřenými daty, unikala by mi informace o kratší návštěvě stránky, než je délka přednastaveného intervalu. Proto ihned po načtení webové stránky posílám webovému serveru echo zprávu oznamující návštěvu stránky. Vzhledem k struktuře databáze bych musel před vložením každé informace zkontrolovat, zdali existuje záznam o vkládaném uživateli i navštívené stránce a pokud ne, vložit nejdříve do databáze tyto informace. Tímto způsobem kontrolu provádím na straně serveru pouze po přijetí echo zprávy. Zároveň se vnitřní čas každého stroje v lokální síti může lišit, a abych naměřená data sjednotil, nechávám si v reakci na echo zprávu od serveru na klienta posílat rozdíl serverového času a času odeslání echo zprávy. Následně měřící skript přičítá tento rozdíl k hodnotě start každé data zprávy. Informace v query řetězci jsou v následujícím tvaru. 22

3. ŘEŠENÍ jméno typ popis type řetězec "echo"nebo "data" start celé číslo Počátek tohoto intervalu v milisekundách od epochy span celé číslo Délka tohoto intervalu v milisekundách domain řetězec Hostname upravený funkcí: encodeuri() url řetězec Pathname upravený funkcí: encodeuri() top 0 nebo 1 Bool hodnota zda jsou naměřená data asociována s nejvyšším html dokumentem Příklad script elementu: <script type= text/javascript src= http://192.168.0.1:3000/adddata?type=data& start=1430333805276&span=10000&domain=www.example.com&top=1 > 3.2 Modifikace Tinyproxy Dalším významným krokem v této práci bylo vložit měřící skript do každého html dokumentu, který směřuje z internetu do lokální sítě. Kvůli snížení objemu posílaných dat po síti mohou být html dokumenty po internetu posílány v komprimované podobě. V této kapitole se proto věnuji kompresi resp. dekompresi a vložení měřícího skriptu na vhodné místo v html dokumentu. K Tinyproxy neexistuje žádná dokumentace pouze komentované zdrojové kódy. Zdrojové kódy Tinyproxy jsou rozděleny do několika souborů podle obsluhovaných modulů. Hlavní změny jsem prováděl v souboru req.c, ve kterém se nachází funkce obsluhující spojení mezi klientem a serverem. Rozsah změn se týká souborů: req.c, conn.c, conn.h, buff.h, conf.c a conf.h. Nejdříve jsem pomocí kontrolních výpisů analyzoval komunikaci mezi klientem a serverem v Tinyproxy, která vypadá následovně: 1. proxy detekuje spojení s klientem a jeho požadavek. 2. alokuje strukturu conn_s, která uchovává informace o spojení jako filedescriptory, buffery apod. A vytvoří spojení se serverem. 3. (ve funkci process_client_headers) přečte hlavičky klientova požadavku, zapíše na server a hlavičku smaže. 23

3. ŘEŠENÍ 4. (ve funkci relay_connection) přečte data, zapíše na server a data smaže. 5. (ve funkci process_server_headers) přečte hlavičky odpovědi na požadavek, zapíše na klienta a hlavičku smaže. 6. proxy detekuje spojení se serverem a jeho odpověd. 7. (ve funkci relay_connection) Dokud proxy nedetekuje uzavřené spojení ze strany serveru nebo konec čtení, zvolí připravený filedescriptor bud pro čtení ze serveru, zápis na klienta, nebo oba a podle zvoleného filedescriptoru provede: (a) Přečte až 2048 znaků ze serveru a uloží do bufferu. (b) Odstraní až 2048 znaků z bufferu a zapíše je na klienta. 8. uzavře s klientem spojení a dealokuje conn_s. Obrázek 3.1: Komunikace klienta se serverem prostřednictvím proxy. 24

3. ŘEŠENÍ 3.2.1 Komprese/Decomprese html dokumentu Servery mohou posílat data komprimovaná, aby spojení bylo rychlejší. Komprimace může v ideálním případě zmenšit velikost posílaných dat až 10x avšak běžněji se setkáme až s čtyřnásobným zmenšením. Všechny dostupné prohlížeče akceptují kompresi html dokumentu v deflate anebo gzip. Pro oba typy komprese resp. dekomprese mi posloužila knihovna zlib [3] od Mark Adler a Jean-loup Gailly a stejně jako Tinyproxy ani zlib nemá žádnou dokumentaci, ale pouze okomentované deklarace funkcí v hlavičkovém souboru zlib.h. Základní komprese resp. dekomprese, kterou bývají html dokumenty kódovány má zcela jednoduché použití: 1. Inicializace struktury z_stream_s funkcí inflateinit resp. deflateinit. 2. inflate resp. deflate. 3. Dokud není zpracováno vše: (a) Aktualizace struktury z_stream_s. (b) inflate resp. deflate. 4. Ukončení komprese resp. dekomprese a dealokace struktury z_stream_s funkcí inflateend resp. deflateend. Dekompresi, vložení script elementu a případnou zpětnou kompresi provádím ve funkci relay_connection (viz. Bod 7 komunikace mezi klientem a serverem v Tinyproxy), kde dochází k přečtení dat ze serveru a zápis na klienta. Ale v tomto bodě jsou již ztraceny obě hlavičky jak požadavku, tak odpovědi na požadavek. Bez informace, jestli je obsah komprimován či nikoli a pokud komprimován je, tak jakým způsobem, nemohu provést dekompresi. Stejně nemohu provést kompresi, když nevím jaké kódování klient akceptuje. Proto jsem do struktury conn_s přidal 3 ukazatele na řetězce. Jeden na hlavičku Accept-Encoding posílanou v požadavku a další na Content-Encoding a Content-Type posílané v odpovědi. Hlavičky kopíruji před jejich smazáním ve funkcích process_server_headers a process_client_headers (viz. 25

3. ŘEŠENÍ Bod 3 a 5). (Zároveň nepotřebuji provést dekompresi, pokud se nejedná o html dokument) Na základě těchto informací pokud je Content-Type roven text/html mohu ve funkci relay_connection inicializovat struktury komprese i dekomprese. A hledat v otevřeném textovém html dokumentu správné místo vložení script elementu. static int process_client_headers (struct conn_s *connptr, hashmap_t hashofheaders) {... int ret = 0; char *data, *header;... /* * If there is a "Accept-Encoding" header, * retrieve the information for later use. * And swap the information for encoding * that proxy accepts. * - Kamil specific - */ connptr->accept_encoding = get_header_value (hashofheaders,"accept-encoding"); hashmap_remove (hashofheaders, "accept-encoding"); add_header_to_connection (hashofheaders, acceptencoding,strlen(acceptencoding));... } return ret; static int process_server_headers (struct conn_s *connptr) {... hashmap_t hashofheaders; 26

3. ŘEŠENÍ... /* * If there is a "Content-Encoding" and/or * "Content-Type" header, * retrieve the information for later use. * - Kamil specific - */ connptr->content_encoding = get_header_value (hashofheaders,"content-encoding"); connptr->content_type = get_header_value (hashofheaders,"content-type"); processencodingheaders(connptr,&hashofheaders);... return 0; ERROR_EXIT: hashmap_delete (hashofheaders); return -1; } 3.2.2 Místo vložení měřícího skriptu Element script se může v dokumentu nacházet bud v elementu head nebo kdekoli v elementu body. Zvolil jsem vkládání do elementu head a protože i element head může mít atributy jako každý element, bylo by ideální vkládat skript těsně před koncový tag head resp. </head>. Ale jak jsem zmínil v popisu komunikace mezi klientem a serverem v Tinyproxy, proxy přečte až 2048 znaků a tím by mohlo dojít k rozdělení koncového head tagu. Ve chvíli kdy bych jej detekoval, nemusel bych mít přistup k předchozímu řetězci, protože by mohl být již odeslán. Příklad: 1. Tinyproxy přečte řetězec končící znaky </he, pošle jej klientovi a smaže. 2. Tinyproxy přečte řetězec začínající znaky ad>, detekuje koncový head tag, ale řetězec s místem vložení je už na cestě ke klientovi. 27

3. ŘEŠENÍ Element script tedy vkládám těsně za koncový znak > otvírajícího head tagu. Přestože nevěřím, že by mi server Tinyproxy mohl na 2048. znaku rozdělit otvírající head tag, implementoval jsem algoritmus na vyhledání koncového znaku tohoto tagu pomocí stavového automatu (obrázek 3.2). int getinsertionpointer(char* buffer, int size, int* state){ char* ptr = buffer; char* last = ptr; char* endofstring = ptr + size; int tmp = 0 - *state; if(*state < 0){ return 0; }else if(*state > 0 && *state < (int)strlen(head)){ while( *(ptr + *state + tmp) == head[*state] && (ptr + (*state)++ + tmp < endofstring)); if(ptr + *state + tmp < endofstring){ if( *(ptr + *state + tmp) == *(ptr + *state + tmp) == > ) (*state)++; else (*state) = 0; }else return 0; last = ptr++; } if(*state == (int)strlen(head) && ptr + *state < endofstring){ if( *(ptr + *state) == *(ptr + *state) == > ) (*state)++; else (*state) = 0; } while( (ptr = strchr(ptr, < ))!= NULL && *state!= (int)strlen(head) +1 ){ while( *(ptr + (++(*state))) == head[*state] && (ptr + *state < endofstring)); if(ptr + *state < endofstring){ if(*state == (int)strlen(head)){ if(*(ptr + *state) == *(ptr + *state) == > ) (*state)++; } else (*state) = 0; } last = ptr++; 28

3. ŘEŠENÍ } } if(*state == (int)strlen(head) +1 && (ptr = strchr(last, > ))){ *state = -1; return ++ptr - buffer; } return 0; Obrázek 3.2: Automat. Javascriptový kód se do html dokumentu vkládá dvěma způsoby. Přímo vložením javascriptu mezi otvírající a zavírající script tag. Nebo URL adresou v atributu src vloženého script elementu. Druhý způsob mi umožní oddělit javascript od proxy serveru a spravovat jej jinde. Vhodné rozšíření k této funkcionalitě je možnost měnit src atribut bez nutnosti znovu kompilovat zdrojové kódy Tinyproxy. K tomuto účelu slouží soubor tinyproxy.conf, jehož parsování a aplikaci konfiguračních hodnot mají na starosti funkce souborů conf.c a conf.h. Rozhodl jsem se je pozměnit, abych mohl snadno měnit nastavení mnou provedených změn v Tinyproxy. Do souboru Tinyproxy jsem přidal dva odstavce. # # This allows you to insert script element into HTML # document with specific attributes. # Format: Script "src" "dst" "interval" # src - mandatory attribute, source address of the Tracing # script. # dst - mandatory attribute, destination address where the # data will be sent. # interval - optional attribute, sets the value of interval # in seconds. Default is 10. 29

3. ŘEŠENÍ # # - Kamil # Script "http://localhost:3000/.../script.js" "http://localhost:3000" "10" # # If it s set to Yes, then data will be compressed again # after decompression. # This can reduce bandwidth of intranet. # If it s set to No, then data won t be compressed after # decompression. # This can speed up proxy processing. # # - Kamil # Compress Yes První odstavec nastavuje atributy vkládaného script elementu. Řádek začínající slovem Script má dva povinné parametry a jeden volitelný. Oba povinné parametry mají formát URL i s komunikačním protokolem. První určuje hodnotu atributu src (adresa, kde se nachází měřící javascript) a druhý atributu dst (adresa, kam budou posílána naměřená data). Třetí a zároveň volitelný určuje hodnotu atributu interval, je typu celé číslo a definuje, v jakých intervalech bude měřící javascript posílat naměřená data webovému serveru. V druhém odstavci je řádek začínající slovem Compress, který má pouze jeden povinný parametr, je typu boolean a určuje, jestli budou data po dekompresi znovu kompresována. Po všech důležitých úpravách zbývá jen instalace sekvencí následujících příkazů: env LIBS= -lz./configure -prefix=/usr -localstatedir=/var -sysconfdir=/etc -enable-xtinyproxy -enable-upstream - enable-transparent -program-prefix="" -program-suffix="" make make install 30

3. ŘEŠENÍ 3.3 Webový server Express nad platformou Node.js a databáze PostgreSQL Instalace platformy NodeJS nainstaluje zároveň balíčkového správce (anglicky Node Package Manager 4, dále jen NPM) pro snadnější instalaci balíčků do systému. Tohoto správce použiji pro instalaci balíčku express a pomocného balíčku express-generator 5, který nainstaluje a prováže všechny závislosti potřebné pro správný chod balíčku express. npm install express -g npm install express-generator -g Samotný webový server nainstaluji příkazy: express /home/user/this_webserver/ cd /home/user/this_webserver/ npm install V tuto chvíli zde stále chybí logika přijímání dat i vizualizace. Tu přidáme aplikací patche: patch -p0 < webserver.patch Instalace vygeneruje pět hlavních adresářů s důležitými soubory pro běh základní webové stránky. 1. bin - uvnitř se nachází spouštěcí skript www.js. 2. node_module složka pro moduly, na kterých je Express závislý. 3. public složka určená pro dokumenty posílané klientu obrázky, css, javascriptové kódy. 4. route - složka pro javascriptové směrovací kódy jádro webové stránky. 5. view složka pro pohledové soubory psané pro modul Jade html pre-procesor umožňuje vytvářet bohaté hierarchie html dokumentů a tak snížit opakování kódu. 4. https://www.npmjs.com/ 5. http://expressjs.com/starter/generator.html 31

3. ŘEŠENÍ 3.3.1 Použití Node.js Vedle vygenerovaných adresářů vygeneruje instalace i soubor app.js, který bych přirovnal k funkci main imperativních programovacích jazyků. Nachází se v něm obsluha klientů, připojení k databázi nebo zpracování a posílání chybového stavu při nedosažení požadované stránky. Pro vytváření webových stránek mi stačí přidávat nové pohledy do složky view a vše pak provázat ve směrovacích javascriptech. Po spuštění stránky následujícím příkazem se na localhostu s portem 3000 spustí základní stránka s jedním pohledem. node /home/user/this_webserver/bin/www.js Logiku URL, které přijímá a zpracovává naměřená data, jsem umístil do cesty /adddata a slouží jak pro příjem echo zpráv tak data zpráv. V této práci jsem již zmínil některé informace, které jsem označil za důležité pro analýzu. Nyní je zopakuji i s těmi, které jsem nezmiňoval. Za základní čtyři považuji: 1. ip adresa uživatele 2. url navštívené stránky 3. čas zobrazení stránky 4. čas strávený na stránce Jako identifikace uživatele na stránce mi v této práci postačí ip adresa příchozího dotazu na stránku obsluhující databázi. Pokud je ale požadavek vyslán na webový server s databází z jiné sítě než se nachází tento server, pak je ip adresa uživatele schována za ip adresu směrovače a mé řešení je potřeba nahradit vhodnějším. Například v případě autentizací proxy by bylo vhodnější asociovat dotaz přímo s účtem uživatele. K rozšiřujícím informacím patří booleovská hodnota, zda se jedná o nejvyšší html dokument či nikoli a URL adresa z které uživatel přešel na aktuální html dokument. Tato informace mi poslouží k analýze hierarchického členění vnořených stránek (více v kapitole 3.1.2 Struktura html a iframe). 32

3. ŘEŠENÍ 3.3.2 PostgreSQL a Tabulky databáze PostgreSQL po instalaci vytvoří uživatele postgres k jehož účtu se z bezpečnostních důvodů nelze přihlásit pomocí hesla, ale pouze přes účet superuživatele. Následující sekvence příkazů vytvoří databázi. su su postgres createdb dbname V účtu postgres se přihlásíme k databázi příkazem: psql dbname Heslo databáze nastaví příkaz: alter user postgres with password dbpassword Zakládací skript spustí příkaz: \i /some_path/psql.sql Nakonec je potřeba ještě upravit heslo a název databáze v souboru webového serveru /home/user/this_webserver/app.js. pg.defaults.database= dbname ; pg.defaults.password= dbpassword ; Měřené informace jsem rozdělil do 4 tabulek následovně: Server, Path, Client, Chunk (obrázek 3.3). 3.3.3 Vizualizace naměřených dat Na rozdíl od měřícího skriptu jsem neváhal použít různých knihoven. Například jquery a Widget Factory pro snadnější práci s DOM a Ajax a k vizualizaci využívám grafů společnosti Google Google Charts 6. Grafy jsou vykreslovány s použitím technologie HTML5/SVG (a VML v případě starších prohlížečů Internet Explorer), aby byla zajištěna kompatibilita mezi prohlížeči i mobilními zařízeními. Naměřené informace zobrazuji na stránce /data a veškeré zpracování dat provádím v javascriptu na straně klienta. Funkce javascriptu jsem rozdělil do tří souborů. 6. https://developers.google.com/chart/interactive/docs/ index 33

3. ŘEŠENÍ Obrázek 3.3: Diagram Entit. Plug widget k obsluze tlačítek clients a domains a k nim přidružených seznamů s klienty a domény. Data funkce určeny k obsluze požadavků klienta a získání dat z databáze. Charts - funkce, které formátují a vykreslují data z databáze. Vytvořil jsem jednoduchou strukturu pohledů s přímočarou navigací. Existují pouze dvě cesty a obě končí pohledem na stejný graf. První cesta začíná koláčovým grafem, který zobrazuje všechny uživatele ve zvoleném časovém období a v procentech čas, který strávili uživatelé na internetu (obrázek 3.4). Tato cesta je výchozí (zobrazí se ihned po načtení stránky /data). Volbou uživatele se zúží výběr na další koláčový graf, který zobrazí všechny domény navštívené uživatelem a v procentech čas, který na nich strávil (obrázek 3.5). 34

3. ŘEŠENÍ Obrázek 3.4: Klienti. Obrázek 3.5: Klient 127.0.0.1. 35

3. ŘEŠENÍ Volba domény zúží výběr na pár uživatel-doména a zobrazí poslední graf histogram. Tento graf zobrazuje, v kterých hodinách uživatel trávil na stránce nejvíc času (obrázek 3.6). Obrázek 3.6: Histogram. Druhá cesta je analogická k první. První graf zobrazí navštívené domény všemi uživateli a v procentech čas, který na nich strávili. Druhý graf zobrazí všechny uživatele a v procentech čas, který na zvolené doméně strávili. Třetí graf je stejný jako v první cestě (obrázek 3.6). 3.4 Úprava dat v databázi Měřící skript posílá zprávy webovému serveru v pravidelném intervalu. Pokud je interval příliš krátký a v síti mnoho uživatelů, mohly by zprávy posílané skriptem zaplavit sít. Na druhou stranu, čím delší je interval, tím delší může být doba mezi poslední odeslanou zprávou a uzavřením stránky. Tato doba nebude, vzhledem k návrhu měřícího skriptu, odeslána a proto o ní nebude záznam v databázi. Při pořízení následujícího výpisu z databáze byl interval nastaven na 10 vteřin. Z ukázky (obrázek 3.7) je patrné, že mezi echo zprávy 15:25:36, 15:25:43 a 15:25:43, 15:25:49 není doba strávená na tomto webu zaznamenána. Vhodným doplňkem této práce by byl skript, který by v pravidelných časových intervalech dopočítával chybějící záznam o stráveném čase a databázi upravoval. Spouštět skript v pravidelných in- 36

3. ŘEŠENÍ Obrázek 3.7: Výpis z databáze. tervalech lze například pomocí programu Cron [1]. Zároveň by Cron mohl upravovat záznamy, které vznikly, když uživatel dlouho prohlížel jednu webovou stránku. Touto úpravou je možné výrazně snížit objem databáze. Například záznamy z obrázku 3.8 by mohly být redukovány na jeden řádek. Obrázek 3.8: Výpis z databáze. 37