Srovnávací analýza technologií vývoje webových aplikací

Univerzita Karlova v Praze Matematicko-fyzikální fakulta

DIPLOMOVÁ PRÁCE

Milan Kryl

Srovnávací analýza technologií vývoje webových aplikací

Katedra softwarového inženýrství Vedoucí diplomové práce: Mgr. Pavel Míka Studijní program: Informatika, datové inženýrství

Chtěl bych poděkovat firmě NetCentrum, provozující internetový portál Centrum.cz, za zapůjčení hardware pro testování. Jmenovitě Pavlu Doskočilovi. Mým pracovním kolegům Arne Ruskovi a Ing. Michalu Novotnému za konzultace při instalačních problémech a Mgr. Janu Hučínovi, se kterým jsem konzultoval statistické zpracování dat.

Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce. V Praze dne 10. 12. 2005

Milan Kryl

2

Obsah Obsah .................................................................................................................................... 3 1 Úvod.............................................................................................................................. 5 2 Webová aplikace............................................................................................................ 5 2.1 Základní definice.................................................................................................... 5 2.2 Architektura ........................................................................................................... 5 3 Výběr jednotlivých technologií .................................................................................... 22 4 Představení jednotlivých testovaných technologií......................................................... 22 4.1 CGI ...................................................................................................................... 22 4.2 FastCGI................................................................................................................ 23 4.3 PHP - Hypertext preprocessor .............................................................................. 24 4.4 Perl ...................................................................................................................... 25 4.5 Python.................................................................................................................. 26 4.6 Java ...................................................................................................................... 26 4.7 ASP...................................................................................................................... 29 4.8 ASP.NET ............................................................................................................. 30 4.9 Cocoon................................................................................................................. 32 4.10 Caché ................................................................................................................... 33 4.11 Oracle WEBDB/Portal ......................................................................................... 34 5 Bezpečnost................................................................................................................... 34 5.1 Dva různé pohledy ............................................................................................... 34 5.2 Bezpečnostní rizika .............................................................................................. 35 5.3 Podpora zajištění vzdálené bezpečnosti ................................................................ 36 5.4 CGI ...................................................................................................................... 36 5.5 FastCGI................................................................................................................ 37 5.6 PHP...................................................................................................................... 37 5.7 Perl ...................................................................................................................... 38 5.8 Python.................................................................................................................. 39 5.9 Java ...................................................................................................................... 39 5.10 ASP.NET ............................................................................................................. 41 5.11 Cocoon................................................................................................................. 42 5.12 Analýza známých bezpečnostních incidentů ......................................................... 42 6 Měření výkonu............................................................................................................. 50 6.1 Prostředí testování ................................................................................................ 50 6.2 Porovnání výkonu jednotlivých technologií .......................................................... 51 6.3 Výsledky měření .................................................................................................. 55 6.4 Závěr a vyhodnocení ............................................................................................ 74 7 Zvyšování výkonu........................................................................................................ 74 7.1 Rysy systému s vysokou dostupností .................................................................... 75 7.2 Zvyšování spolehlivosti DNS ............................................................................... 75 7.3 Rozkládání zátěže................................................................................................. 76 8 Závěr ........................................................................................................................... 79 9 Seznam literatury ......................................................................................................... 81 Příloha A – obsah CD .......................................................................................................... 84

3

Název práce: Srovnávací analýza technologií vývoje webových aplikací Autor: Milan Kryl Katedra (ústav): Katedra softwarového inženýrství Vedoucí diplomové práce: Mgr. Pavel Míka e-mail vedoucího: [email protected] Abstrakt: Diplomová práce podrobně seznamuje s fungováním technologií pro tvorbu internetových aplikací. Jednotlivé technologie CGI, FastCGI, Perl, Python, ASP, ASP.NET, Java servlet, JSP, Cocoon a PHP jsou rozebírány z bezpečnostního hlediska. Zmiňovány jsou funkce podporující zabezpečení každé technologie při instalaci technologie na server a také během vývoje. Důraz je kladen i na množství zveřejňovaných bezpečnostních incidentů, jejich četnost a vývoj od vzniku technologie a jejich typ. Práce rozebírá také výkonnostní srovnání jednotlivých aplikací za pomoci tří testovacích programů (Apache Benchmark, httperf, test_client). Vzorek testovacích souborů je zátěžově testován jedním až několika desítkami simulovaných klientů. Testování je prováděno lokálně přímo na serveru i vzdáleně za pomoci dalšího počítače připojeného přes síť. Nakonec jsou nastíněny možnosti dalšího výkonnostního rozšíření a zmíněno několik doporučení pro lepší dostupnost celé internetové aplikace. Přiblíženy jsou systémy s vysokou dostupností a také fungování internetových aplikací pro celosvětové použití. Klíčová slova: webové technologie, zabezpečení, srovnání výkonnosti, CGI, FastCGI, Perl, Python, Cocoon, PHP, ASP, ASP.NET, Java, JSP

Title: Web development technology comparison analysis Author: Milan Kryl Department: Department of Software Engineering Supervisor: Mgr. Pavel Míka Supervisor’s email address: [email protected] Abstract: This paper informs about most technologies for developing web applications. Application security is one of important criterion for comparison of CGI, FastCGI, Perl, Python, ASP, ASP.NET, Java servlet, JSP, Cocoon and PHP. There are mentioned all functions supporting security after server installation and during developing process. All comparison is made with emphasis on published security accidents, their frequency and type. Second main part of this paper is performance comparison. All tests are made with three benchmark programs (Apache Benchmark, httpref and test_client). Testing samples are requested from one to tens simulated clients. One test is done on server localhost, two others are made remotely from second computer. At the end there are mentioned some tips to better application performance and internet application accessibility. And finally there is information about high availability clusters and internet applications for world wide use. Keywords: web technology, security, peformance comparison, CGI, FastCGI, Perl, Python, Cocoon, PHP, ASP, ASP.NET, Java, JSP

4

1 Úvod Pro tvorbu většiny internetových aplikací si nevystačíme se statickým stránkami, které jen umístíme na internet. Aplikace, které jsou na internetu používány, jsou převážně databázové. Ať se již jedná o freemail, zpravodajský server, firemní stránky, elektronický obchod, diskusní fórum a nebo fulltextový vyhledávač. Internet se začíná rozšiřovat do všeobecného používání. Není již výsadou několika akademických pracovišť, ale přístupnější více lidem. Využívají jej každý den, ať už pro pracovní účely, pro vyhledávání informací a nebo ve volném čase pro zábavu a hry, zjišťování dopravních spojení a nebo relaxaci. Následkem většího používání je taktéž nárůst služeb, které jsou na internetu nabízeny. Jejich tvorba se vyplácí, a proto vznikají stále další. Internet se stává platformou, pod kterou vyvíjí čím dál víc programátorů, vývojářů a designérů. Nehledě na programovací jazyky, internet se stal prostředím, které nemůže být přehlíženo a které se možná stane jednou z několika aplikačních platforem, pro níž se budou nové aplikace vyvíjet. Je mnoho možností, jak vyvíjet webové aplikace. Účelem této práce je bližší pohled na některé z nich. Podívat se podrobněji a prozkoumat jejich možnosti, slabiny a limity. Protože by nebylo možné prozkoumat všechny používané technologie, zaměříme se pouze na několik reprezentantů z různých kategorií. V celá práce bude zaměřena hlavně na bezpečnostní a výkonové hledisko každé testované technologie.

2 Webová aplikace 2.1 Základní definice Webová aplikace Webová aplikace nebo internetová služba je softwarová aplikace přístupná přes internetový prohlížeč nebo program komunikující HTTP protokolem. Typicky se skládá z tenkého klienta (internetový prohlížeč), prezentační vrstvy (webový server), aplikační vrstvy (aplikační server) a databázové vrstvy. Aplikace může být rozložena na několika webových serverech, používat několik aplikačních serverů nebo databázových zdrojů.

2.2 Architektura Při prohlížení stránek na internetu se používá internetový prohlížeč k zasílání požadavků na server. Webový server tyto požadavky zpracuje a vrátí patřičnou odpověď. Tyto požadavky jsou zasílány při vyplnění a odeslání nějakého formuláře, kliknutím na odkaz nebo vyplněním odkazu do adresového řádku prohlížeče.

Dvouvrstvá architektura Často jsou zobrazovanými stránkami pouze statické HTML soubory. Ty jsou uloženy na serveru a čekají až na uživatelský požadavek, kdy jsou zaslány do prohlížeče. Tento případ nazveme jako dvouvrstvou architekturu.

5

Obrázek 2-1 - Dvouvrstvá architektura

Třívrstvá architektura Web server není sofistikovaný software pro ukládání dat a neumožňuje náročnější datové operace. Proto se ve většině případů přidává ještě datová vrstva. Prohlížeč stále reprezentuje klientskou vrstvu. Server se stal vrstvou prostřední a databáze je ve vrstvě třetí. Data jsou uložena v databázi a generována dynamicky, až po zaslání požadavku klientem.

Obrázek 2-2 - Třívrstvá architektura

Podstatnou částí třívrstvové aplikace je databázová vrstva, obsahující systém řízení báze dat (SŘDB). Umožňuje perzistentní uložení dat na serveru a zprostředkovává je aplikační vrstvě, se kterou obousměrně komunikuje za pomoci SQL dotazů. Aplikační vrstva data zprostředkovává připojeným klientským prohlížečům a naopak zasílaná data zpracovává a ukládá zpět na databázový server.

6

Obrázek 2-3 - Třívrstvá architektura - detail

Obrázek 2-3 ilustruje spíše logický pohled. V praxi se setkáme s mnoha různými implementacemi, které budou tomuto modelu odpovídat. Nejčastěji jsou webový server a databázový server nainstalované na jednom počítači. Je to jednodušší jak na finanční požadavky, tak i pro správu celého prostředí. Tato implementace na moderním hardware zvládne desetitisíce požadavků za hodinu. Poslední možností publikace na webu je zobrazování dat přímo z databáze. V prostřední vrstvě je pouze jednoduchý transformátor překládající požadavky z klienta pro databázi a naopak. Veškeré operace provádí databázový stroj. Pro populární a vysoce zatěžované webové aplikace se většinou instaluje webový server a databázový server odděleně na dva stroje. Tím se získá lépe škálovatelné řešení a také rychlejší aplikace. Pokud mají být webové servery velmi zatěžovány, použije se celý soubor

7

počítačů (tzv. cluster). Databáze a webserver jsou replikovány na více počítačů a požadavky jsou rozdělovány na jednotlivé počítače ve skupině podle aktuálního zatížení.

HTTP (HyperText Transfer Protocol) Třívrstvová architektura je koncept pro vytváření webových aplikací. Internet sám o sobě nabízí komunikační protokoly a síťové spojení klientů s prostřední vrstvou aplikace. Umožňuje spojení prohlížeče a webového serveru. Aplikační protokol HTTP realizuje ve webových aplikacích přenos dat mezi klientem (prohlížečem) a serverem. Většina serverů a prohlížečů používá nejnovější verzi HTTP/1.1 [5].

Příklad použití HTTP Koncept HTTP je jednoduchý: prohlížeč zašle požadavek na web server a ten pošle zpátky odpověď. Pro každý požadavek je zaslána jedna odpověď. Hlavička je v textové formě a následují požadovaná data - HTML dokument, obrázek nebo datový soubor. Požadavek je textový popis dat, která jsou po serveru požadována, případně i s dodatečnými parametry. Má dánu pevnou strukturu, kdy na prvním řádku je typ požadavku, adresa požadované stránky a verze protokolu. Následují řádky ve tvaru Atribut: hodnota a celý požadavek končí prázdným řádkem. Prohlížeč pošle na server požadavek (například): GET /index.html HTTP/1.1 Host: www.mff.cuni.cz User-agent: Mozilla/5.0 (Windows) Gecko/20041107 Firefox/1.0 Accept: text/xml,application/xhtml+xml,text/plain,text/html

Příklad požaduje po serveru www.mff.cuni.cz stránku index.html za pomocí HTTP/1.1 Další dva řádky identifikují uživatele, prohlížeč a informují o typu dat, které je schopen prohlížeč přijmout. Při běžném prohlížení stránek jsou zasílány podobné požadavky, ale většinou obsahují ještě další informace zasílané prohlížečem. Odpověď vypadá podobně. Na prvním řádku vrátí verzi protokolu a stavový kód v číselné a textové variantě. Stavový kód se dělí na pět kategorií podle počáteční cifry: • 1xx - informační - požadavek byl přijat, zpracovávání pokračuje • 2xx - úspěch - požadavek úspěšně přijat a zpracován • 3xx - přesměrování - pro dokončení požadavku je třeba vykonat ještě nějakou další akci • 4xx - chyba klienta - požadavek má špatnou syntaxi nebo nemůže být proveden • 5xx - chyba serveru - server nedokázal vykonat platný požadavek Následují řádky atribut dvojtečka hodnota. Hlavička končí prázdným řádkem a následně je zaslán obsah požadovaného souboru. HTTP/1.1 200 OK Date: Sun, 10 Oct 2004 09:02:52 GMT Server: Apache/1.3.31 (Unix) Content-Type: text/html; charset=utf-8

8

<META name="Author" content="[email protected]"> ...

První řádek informuje, že se jedná o HTTP/1.1 a o bezproblémové vyřízeném požadavku návratový kód 200 a zpráva OK. Další řádky obsahují aktuální datum a čas, jméno web serveru a kódování zaslané stránky. Hlavička je od dat oddělena prázdným řádkem a následně je zaslán celá obsah souboru index.html.

Stavy Tradiční databázové aplikace jsou stavové. Uživatel se přihlásí, spustí nějaké úlohy, a po jejich provedení se odhlásí. Například v bankovní aplikaci se uživatel přihlásí vyplněním přihlašovacího formuláře, přes nějaká menu se dostane až k požadované operaci a provede elektronickou platbu a následně se odhlásí. Bankovní aplikace má stavy: poté co se uživatel přihlásí a může se pohybovat v nějaké struktuře nabídek. Nakonec, když se odhlásí (přesune aplikaci je jiného stavu), tak nemůže provádět žádné operace, kromě opětovného přihlášení. HTTP je obecně použitelný protokol, který je čistě bezestavový. Jakákoliv výměna informací mezi prohlížečem a serverem je nezávislá na předchozích požadavcích. Každý HTTP požadavek obsahuje totožnou hlavičku (uživatelské pověření, typ stránek, které prohlížeč akceptuje a instrukce, jak formátovat odpověď). Jakmile server požadavek vyřídí, tak zašle odpověď a na celý proces zapomene. Bezestavový protokol má své výhody. Server neuchovává žádné další údaje o uživatelských relacích, šetří se tím zatížení celého serveru. Uživatelé mohou libovolně přecházet jedním kliknutím ze serveru na server. Přidání stavů do protokolu HTTP není možné. Je třeba stavy nasimulovat předáváním unikátního klíče nebo tokenu. Uživatel a jeho spojení se serverem je tímto jednoznačně identifikováno. Tento token je použit v prostřední vrstvě třívrstvové architektury (na webserveru). Mohou na něj být navázána další potřebná data (realizující stav). Ta se ke klientovi neposílají, ale jsou uložena na webserveru nebo v databázi. Většina webových technologií tuto možnost simulace stavů podporuje a nabízí programátorům. Výměna tokenu nám umožní použít stavové struktury, jako jsou uživatelské nabídky, více kroků při nějaké akci a řízení procesů. Lze uživatelům zakázat několikanásobné přihlášení, vypršení přihlášení po nějaké době a kontrolovat přístup do celé aplikace. Použití HTTP není omezeno pouze na přenos HTML stránek. Rozšířením datových položek v hlavičkách, nadefinováním dalších návratových kódů jej lze použít i pro libovolné další přenosy dat. Přesto se nejčastěji používá právě pro výměnu internetových stránek.

9

HTTPS Když jsou data přenášena přes internet z jednoho bodu na druhý, tak prochází přes switche, routery, gatewaye a proxy servery. Po cestě přes jednotlivé uzly sítě až k cílovému počítači existuje mnoho míst, kde může jít k zachycení zasílaných dat. Bylo třeba najít řešení, jak přenášet bezpečně data mezi klientem a serverem. Některé informace jsou příliš citlivé na přenos, aby je bylo možné přenášet nešifrované. Z toho důvodu firma Netscape Communications přidala bezpečnostní protokol, který celou komunikaci mezi serverem a klientem šifruje. Netscape pojmenoval tuto vrstvu Secure Socket Layer (SSL) a díky podpoře i ze strany prohlížeče si brzy našla cestu mezi lidi. Netscape vyvinul za použití asymetrického a symetrického šifrování neproprietární protokol, který poskytuje šifrování, autentizaci serveru, integritu dat a klientskou autentizaci pro komunikaci založenou na TCP/IP.

Obrázek 2-4 - Schéma HTTPS protokolu

SSL protokol běží nad TCP/IP vrstvou a pod vrstvou aplikační. Používá TCP/IP vrstvu jménem aplikačního protokolu a v případě klientů, kteří ovládají SSL, provede autentizaci u serverů používajících SSL a oběma stranám umožní navázat šifrované spojení. symetrické šifrování - toto schéma používá stejného klíče pro šifrování dat, stejně jako pro dešifrování. Obrázek ilustruje příklad použití symetrického šifrování.

10

Obrázek 2-5 - Schéma symetrického šifrování

V tomto schématu je použit pouze jediný klíč. Proto je třeba, aby jej pro komunikaci měly obě strany. asymetrické šifrování - jak lze odvodit z názvu, tak asymetrické šifrování funguje jinak než symetrické. V tomto schématu jsou již dva klíče: veřejný a soukromý. Následující obrázek ilustruje celé fungování.

Obrázek 2-6 - Schéma asymetrického šifrování

Pokud jsou data šifrovaná veřejným klíčem, tak je může dešifrovat pouze vlastník soukromého klíče. Na rozdíl od symetrického šifrování odesílatel nemusí znát soukromý klíč, který příjemce potřebuje k dešifrování. Veřejný klíč je volně distribuován a kdokoliv může iniciovat zabezpečené spojení. Soukromý klíč není nikdy distribuován a je vždy utajen. Certifikát je šifrovaná informace, která spojuje veřejný klíč s identitou jednotlivce, serveru a nebo nějaké jiné entity. Zahrnuje identifikaci a signaturu vydavatele certifikátu. Vydavatel certifikátu je označován jako Certifikační Autorita (CA). Certifikát může obsahovat ještě další

11

údaje (sériové číslo, platnost certifikátu), které slouží certifikační autoritě k lepší správě vydávaných certifikátů. V libovolném internetovém prohlížeči, který ovládá SSL komunikaci, si můžete obsah certifikátu jednoduše prohlédnout sami.

Obrázek 2-7 - Informace uložené v certifikátu

Identifikace je ukládána podle standardu X509. A používá několik základních polí pro identifikaci. • • • • • •

Common Name (CN) - jméno certifikované entity Organization nebo Company (O) - entita spojená s touto organizací Organizational Unit (OU) - entita spojená s organizační jednotkou City/Locality (L) - entita je umístěna v tomto městě State/Province (ST) - entita je umístěna v tomto státě nebo oblasti Country (C) - země (dvoumístný ISO kód)

Certifikát je obvykle přenášen v binárním a nebo kódovaném textovém formátu. Při navazování komunikace proběhne třífázové navázání komunikace: 1. vyjednání parametrů: server a klient si mezi sebou vymění několik základních informací. Šifrování, které může klient použít pro komunikaci, metodu výměny klíčů (RSA, Diffie-Hellman, ...), autentizační algoritmus (MD5 nebo SHA1) a několik dalších parametrů.

12

2. vzájemná autentizace: server zašle klientovi svůj certifikát, který obsahuje mimo jiné i informace o veřejném klíči serveru. Volitelně může server požadovat certifikát od klienta. 3. výměna tajného klíče: Klient vybere tajný klíč pro výměnu dat, zašifruje jej veřejným klíčem serveru a pošle na server. Pro ověření posílá i identifikační číslo spojení zašifrované tímto klíčem. Obratem odpovídá server zašifrovanými daty, následované šifrovaným session-id. Identifikátor spojení se pravidelně mění, aby se minimalizovalo riziko útoku.

Obrázek 2-8 - Schéma navázání komunikace

K navázání komunikace bylo použito asymetrické šifrování a také došlo k výměně klíče. Pro následnou komunikaci je používáno symetrického šifrování, neboť je mnohem rychlejší. Pro maximální bezpečnost se doporučuje délka klíče aspoň 128 bitů. Zasílaná data jsou rozdělována po 64 bitových blocích a ke každému bloku se přidává MAC (Message Authentication Code) - aby nedošlo k modifikaci zasílaných dat. Pro zajištění důvěryhodnosti je potřeba také ověřit platnost serverového certifikátu. Ověřují se tyto věci: • • • •

nevypršela platnost certifikátu - ta je uvedena uvnitř, porovnává se s aktuálním časem certifikát je důvěryhodný - podepsala jej důvěryhodná certifikační autorita souhlasí podpis certifikátu s uváděnou CA - ověření podpisu pomocí veřejného klíče CA z jejího certifikátu souhlasí doménové jméno serveru s uváděným v certifikátu - připojujeme se opravdu k tomu, jehož klíč ověřujeme?

13

Posílení tenkého klienta v třívrstvové architektuře Prohlížeče jsou tenkými klienty. Nemají žádnou aplikační logiku a jediné o co se starají je zaslání požadavku na server, získání odpovědi a její zobrazení. Není třeba do prohlížeče nic doinstalovat, konfigurovat či jinak měnit. Naopak to znamená, že veškerá aplikační logika musí sídlit až ve střední vrstvě architektury. Bylo by sice možné vytvořit aplikaci, která by s databází na serveru komunikovala přímo z počítače klientů. Nabízela by mnohem komfortnější ovládání a programátor by nemusel pracně obcházet omezení dané protokolem HTTP. Na druhou stranu by se celá webová, nebo spíše už databázová, aplikace stala závislou pouze pro jeden operační systém nebo jedno prostředí. Při použití jednoduchého internetového prohlížeče, který je implementován na všech dostupných operačních systémech, není uživatel limitován a může k webové aplikaci přistupovat odkudkoliv, kde lze prohlížeč spustit. Prohlížeč není nijak náročný na zdroje, takže jej lze nalézt i v mobilních zařízeních, plánovačích a mobilních telefonech. Ale internetový prohlížeč není zcela uzavřeným programem. Systémem různých rozšíření lze funkce internetového prohlížeče dále rozvíjet. Je možné přidat aplikační logiku i do klientské vrstvy prohlížeče. Při použití technologií jako je Java, Macromedia Flash nebo JavaScript je možné vyvíjet komponenty aplikace zcela nezávislé na serveru. Tyto komponenty mohou zpracovat data dřív, než jsou odeslána na server a nabízet větší uživatelský komfort. Malým nedostatkem je nutnost instalace těchto rozšíření, pokud nejsou v prohlížeči k dispozici. Prohlížeče z rodiny Mozilla podporují jazyk XUL pro pohodlnou tvorbu uživatelského rozhraní. Snadným způsobem za pomoci XML a JavaScriptu lze vytvořit aplikaci používající klasických prvků prohlížeče. Hlavní výhodou tohoto jazyka je přenositelnost mezi platformami. Mezi vytvořenými aplikacemi přímo pro prohlížeč již najdeme programy jako IRC klient, FTP klient a podobně. Podobná snaha je vidět u společnosti Macromedia. Ta se usiluje o vybudování a rozšíření internetové aplikační vrstvy (Rich Internet Applications - RIA).

Rozmanité Internetové Aplikace (Rich Internet Application - RIA) Problémy dnešních webových technologií Internet reprezentuje velký potenciál týkající se neočekávané flexibility při vývoji aplikací a také má velký vliv na nové chápání tvorby aplikací. Během postupného vývoje základních webových aplikací se začalo narážet na některá omezení, která tvorba internetových aplikací přináší: • • •

nutnost tvorby aplikace tak, aby byla zachována filosofie dokumentově orientovaných standardů HTML a HTTP. Vytvoření příjemného uživatelského rozhraní je nákladné jak finančně, tak i časově. přetrvávají síťová omezení: nestálé připojení s proměnlivou rychlostí. časové a finanční náklady na vývoj a údržbu internetové aplikace mohou být znepokojující. To je zapříčiněno nejen limitujícími technologickými prostředky, ale

14

také různými požadavky a procesy při vývoji mezi týmy vytvařejícími desktopové a nebo internetové aplikace.

Řešení Při vývoji rozšířených webových aplikací je třeba takové řešení, které vyřeší většinu problému s infrastrukturou internetu a také rozšíří dnešní internetové standardy. Na druhé straně nesmí přidat na komplikovanosti vývojového procesu nebo náročnosti na síťovou komunikaci. Ideální platforma pro pokročilé webové aplikace by měla nabízet tyto možnosti: • rozšířené uživatelské rozhraní, které bude nabízet velké funkční možnosti klient/server aplikace, ale stále bude operovat v běžném internetovém prostředí • aplikace vytvořená za pomoci tohoto řešení musí odrážet aktuální stav klientské části v reálném čase i na serveru. • nabídnout univerzální vývojové prostředí, které bude zastírat nesrovnalosti jednotlivých platforem, stejně tak potřeby konkrétního prostředí pro běh aplikace. Stejně tak bez nutnosti na klienta instalovat nebo udržovat nějaké další programy. • vývojové prostředí by mělo podporovat jednoduchý vývoj nových aplikací, nabídnout známé vývojové modely a šanci rozvíjet existující technické nadání i v budoucnosti.

Technologické možnosti Během posledních let vzniklo několik technologií, které se snaží o řešení výše zmiňovaných nedostatků. • • •

vlastní řešení založené na DHTML/JavaScript apod. nástroje RIA jako je například Macromedia Flash tlustý klient (.NET, Java, ...)

Vlastní řešení DHTML/JavaScript řešení může být použito pro poskytnutí některých potřebných funkcí, které vyžadují aplikace na straně klienta. Tato technologie založená převážně na skriptovacím jazyku nemůže vylepšit škálovatelnost, zajistit spolehlivost nebo poskytnout prostředí pro zpracování událostí náročných na rychlost odezvy (time-critical) v distribuovaném internetovém prostředí. Tvorba aplikace pomocí tohoto vývojového modelu je náročná na čas, DHTML/JavaScript kód je často závislý na platformě a typu prohlížeče. To vede k vyšší nákladům při vývoji a také složitější údržbě vytvořené aplikace. Nástroje RIA Nejdřív se myslelo, že nástroje pro tvorbu Rozmanitých Internetových Aplikací jsou odpovědí na většinu vývojářských požadavků. Nabízí nejlepší, částečné řešení na problémy internetu. Nástroje RIA nabízí rozmanitý vizuální vzhled aplikace. Díky tomu lze obejít nutnost kliknutí a načtení stránky. Veškerý obsah lze zobrazovat kontinuálně, je možné vytvářen efekty přesunu, animace a další multimediální obsah. Bohužel zatímco nástroje RIA, jako například Macromedia Flash, pomáhají vytvořit lepší uživatelské rozhraní, tak si příliš nerozumí v záležitostech týkajících se škálovatelnosti, spolehlivosti a bezpečnosti. Tvorba RIA přináší další vývojové komplikace a nutnost instalace a údržby programového rozhraní na straně klienta. RIA sice nabízí rozšířené možnosti tvorby uživatelského rozhraní, ale neposílí výkonnostní sílu aplikace.

15

Tlustý klient Nedostatky internetu se snaží řešit i několik technologií běžících pouze na straně klienta. Obecně jsou tyto technologie, jako například Java Swing/WebStart nebo Microsoft .NET, podobné tím, že nedostatky řeší přesunem větší části na klienta. Internetová aplikace se tak mění v desktopovou, běžící jako tlustý klient. V obou případech řešení (tlustého klienta a nebo desktopové aplikace) je klíčovou výhodou, že se starají hlavně o zobrazování dat. To znamená méně vzájemné komunikace přes síť, vedoucí k větší dostupnosti bez připojení, lepšímu výkonu a vylepšené podpoře práce s objemnými daty. Navíc umožňuje větší průchodnost serveru a tím navýšení kapacity pro zpracování více uživatelů. Hlavní nevýhodou, společnou pro všechny tlusté internetové klienty a desktopové aplikace, je závislost konfigurace klientské platformy. Tlustý webový klient může mít za následek mnoho způsobených problémů instalovaným software a jeho údržbou. Například pro aplikace vytvořené v Microsoft .NET je třeba mít nainstalované prostředí .NET Common Language Runtime (CLR), zatímco Java WebStart zase potřebuje Java Virtual Machine (JVM). Závislost na klientu může omezovat uživatele ve standardizované instalaci klientského počítače a vývojáři budou nuceni vyvíjet několik verzí aplikace za použití různorodých technologií. Nutnost konkrétního provozního prostředí může mít za následek drahé investice do modernizace počítačů. Kromě vysokých nároků na vývoj a správu mohou tlustí klienti nabídnout řešení některých problémů: spolehlivost a také podporu pro transakce s velkými nároky na rychlost odezvy.

Technologie klienta Java V roce 1990 byl pod označením Oak vyvinut objektově orientovaný programovací jazyk. Vývojová skupina firmy Sun Microsystems, označovaná jako Green, měla za úkol vyvinout nový produkt pro rozšíření porfolia firmy Sun. Původně byl Oak vytvořen pro osobní digitální zařízení s názvem *7, které chtěl Sun na trhu nabídnout. Odnož zabývající se zařízením *7 ustrnula na mrtvém bodě. Projekt Oak využil popularity internetu, která se rozšířila díky prohlížeči firmy Netscape, a byl uvolněn pro internetové použití s novým označením - Java. Napsaný program v Javě je překládán do nezávislého bytekódu. Ten neběží na platformě konkrétního počítače, ale je spouštěn na Java Virtual Machine (JVM). JVM je software, který se stará o běh překompilované aplikace. Umožňuje běh na libovolném počítači, na kterém je JVM nainstalována. Pro přenos z platformy na platformu stačí pouze převést JVM a díky tomu budou funkční veškeré aplikace napsané v Javě i na nové platformě.

16

Obrázek 2-9 - Kompilace Java apletu

Bytekód, který je vytvořen po kompilaci, neobsahuje žádné instrukce závislé na platformě. To sice přináší pohodlnou přenositelnost. Na druhou stranu také nutnost běhu na virtuálním stroji přidává počítači další práci navíc. Spouštění nezávislého kódu je výkonostně náročnější, než pokud by byl program překompilován přímo pro danou aplikaci bez mezivrstvy JVM.

JavaScript Brendan Eich zaměstnanec firmy Netscape dostal za úkol vyvinout jazyk, který bude integrován do internetového prohlížeče a bude umožňovat větší interaktivitu internetových stránek. To si lze představit například jako práci s formuláři, možnost změny barvy, vytvoření nových oken a práci s nimi. Ve stejné době přišla firma Sun s první verzí Javy a Netscape dostal první licenci na její využívání. Brendan Eich stál před rozhodnutím, zda použít Javu a nebo jít vlastní cestou a vytvořit něco zcela nového. Nakonec byly vlastnosti Javy příliš robustní a tým se pustil do vývoje skriptovacího jazyka interpretovaného v prohlížeči. První implementace jazyka byla obsažena v roce 1995 v prohlížeči Netscape Navigator 2.0 a jmenovala se LiveScript. Za několik měsíců byl jazyk přejmenován na JavaScript a v internetových prohlížečích přežil až dodnes. Během vývoje verzí jednotlivých prohlížečů ještě nastala malá roztržka s prohlížečem Internet Explorer, který si udělal JavaScript po svém a nazval jej JScript. Protože se obě větve postupně odchylovaly, byl ustanovena mezinárodní standardizační průmyslovou asociací se zaměřením na informační a komunikační systémy ECMA specifikace ECMA Script. Ta standardizuje jednotlivé prvky JavaScriptu 1.1 a vzníká ECMA Script verze 1.0. Nynější specifikace ECMA Scriptu je již ve verzi 3.0 (kompatibilními implementacemi jsou JavaScript 1.5 a JScript 5.5).

17

Macromedia Flash Autorem, který stojí za zrodem nástroje Macromedia Flash je Jonathan Gay. Vytvořil nejprve grafický editor, který se později začal specializovat na tvorbu animací a v té době se nazýval SmartSketch. Během vývoje změnil jméno na FutureSplash Animator a úspěchy začal slavit, když si jej firma Microsoft vybrala jako nástroj pro tvorbu internetového portálu MSN. Dalším zákazníkem se stala společnost Disney a od roku 1996 následovala spolupráce se společností Macromedia. Nakonec společnost Macromedia program zakoupila a vydala jej pod názvem Macromedia Flash 1.0. Postupně se program vyvinul v plnohodnotný vývojový nástroj, který má kromě animací velmi široký záběr. Nyní se již uživatelé těší ze sedmé verze - Macromedia Flash MX 2004. Macromedia Flash je kombinací několika zcela rozdílných nástrojů. Vypadá jako vektorový grafický program, schopný zpracovávat bitmapové obrázky a s možností animací. Obsahuje také programovací jazyk ActionScript, který je založen na standardech JavaScriptu - ECMA Script. Samozřejmostí je zpracování obsahu v HTML formátu, stejně tak jako XML data. Bez potíží je schopen komunikovat přes síťové připojení a nebo být integrován s dynamicky generovanými stránkami založenými buď na CFML (ColdFusion Markup Language) nebo JSP (JavaServer Pages). Od verze 5 ve spojední s Flash Generator 2 jej lze použít i jako frontend k databázovému serveru. Lze tak vytvořit například internetový obchod nebo libovolnou aplikaci spolupracující s databází. Flashové animace .FLA lze exportovat s nižšími datovými nároky do souboru s příponou .SWF. Ty slouží hlavně k zobrazování a přenosu přes internet. Přehrávány jsou pomocí nainstalovaných pluginů v internetových prohlížečích.

ActiveX Component Object Model (COM), také známý pod názvem ActiveX je technologie firmy Microsoft pro tvorbu softwarových komponent. Umožňuje komunikaci mezi programy. Ačkoliv byla tato technologie implementována na několika platformách, tak je používána hlavně na systému Microsoft Windows. Jeho předchůdcem bylo OLE (Object lining and embedding) a nyní je ve fázi nahrazování technologií Microsoft .NET framework. V letech 1991 až 1993 se postupně objevilo OLE 1.0 a OLE 2.0. COM bylo rozhraní na pozadí objektového modelu OLE. Počátkem roku 1996 Microsoft přejmenoval některé části OLE na Internet ActiveX, až na konec pod tímto názvem začal označovat celé jako ActiveX technologii. Pro programování ActiveX komponent slouží jazyky C, C++, Visual Basic a několik dalších skriptovacích jazyků implementovaných pro Windows. Integrací podpory ActiveX do prohlížeče Internet Explorer bylo umožněno vývojářům doplňovat do internetových stránek rozmanité části kódu. Bohužel ve většině případů toho bylo zneužíváno i k šíření virů, trojanů nebo spyware. Navíc kromě Internet Exploreru komponenty ActiveX nepodporuje žádný další internetový prohlížeč.

18

AJAX Nástroj, který je spíše kombinací několika známých technologií, než novým počinem na poli webových technologií. Tyto technologie se vzájemně doplňují a dohromady působí velmi zajímavě. AJAX se skládá z těchto komponent: • standardní prezentační vrstva založená na XHTML a CSS • dynamické zobrazování a interakce za použití Document Object Model (DOM) • výměna a manipulace s daty za použití XML a XSLT • asynchronní výměna dat díky XMLHttpRequest • a JavaScript, který všechny tyto komponenty spojuje v jeden fungující celek Klasické webové aplikace pracují ve stylu požadavek na server, zpracování požadavku a zobrazení výsledku. Zatímco AJAX se snaží tento způsob práce se stránkou překonat. Po prvním načtení jsou data se serverem vyměňována kontinuálně a na pozadí. Uživatel vidí stále načtenou a zobrazenou stránku. Během zpracování stažených dat a přípravě jejich zobrazení již může probíhat další získávání nových dat. JavaScript přes XMLHttpRequest požaduje po serveru nějaká data (obvykle XML), následně je za pomocí XSLT zpracuje a zobrazí v okně prohlížeče. Obrovskou výhodou je vyšší interaktivnost takto vyrobených aplikací. V praxi si je lze Flicker vyzkoušet na službách Google Maps (http://maps.google.com/), (http://www.flicker.com/) nebo A9 (http://a9.com).

S přenosem internetových aplikací na klienta úzce souvisí i technologie pro tvorbu jednotného uživatelského rozhraní. Většinou jsou koncipovány tak, aby byla tvorba rozhraní jednoduchá a pokud možno i nezávislá na platformě.

XUL Jako nadstava pro tvorbu uživatelského rozhraní vlastních aplikací byl vytvořen tvůrci prohlížeče Mozilla programovací jazyk na podobném základu jako HTML. Slouží k jednoduchému vytváření aplikačního rozhraní, které doplňuje kódem napsaným v JavaScriptu a nebo C/C++. Vzhled lze jednoduše měnit kaskádovými styly. XUL zatím není žádným definovaným standardem, pouze jich několik používá a je postaven na jejich základech (CSS, JavaScript, XML, DTD a RDF). Díky tomu se jej lze velmi rychle naučit a začít tvořit vlastní aplikace a nebo rozšíření internetového prohlížeče Mozilla Firefox, a případně také Mozilla Thunderbird. Velkou výhodou je jeho přenositelnost mezi všemi platformami, pro které je překompilován Mozilla Firefox.

XAML Firma Microsoft vytvořila pro další verzi operačního systému Windows Longhorn jazyk XAML (eXtensible Application Markup Language). Slouží k definici uživatelského rozhraní a je založená na XML.

19

Tyto XAML soubory budou produktem vývojových nástrojů (např. Visual Studio .NET) a při kompilaci se budou připojovat k výsledným aplikacím. Možné je přikompilování přímo do kódu aplikace nebo interpretace XAML souboru až při samotném běhu aplikace. Elementy nadefinované v souboru se mapují na objekty vytvářené za běhu (Common Language Runtime objects) a atributy jsou mapovány na proměnné nebo události těchto objektů. Někteří pozorovatelé vidí tuto technologii jako přímou odpověď na aktivity týmu Mozilla a produkt XUL.

Konverze aplikace ze serverové na klientskou Během vývoje projektu možná nastane situace, kdy vývojový tým narazí na limity při umístění aplikace na serveru. Zváží celou situaci a rozhodne se pro změnu umístění aplikace ze serveru na klienta. Nicméně tento přechod nepřinese pouze výhodné podmínky pro další rozvoj, ale donutí vývojový tým řešit problémy, které by v serverovém řešení nenastávaly. Před nasazením tlustého klienta je třeba vyřešit, zda si většina uživatelů bude moci novou aplikaci nainstalovat. Nebude totiž možné vytvořit všechny varianty aplikace pro libovolnou platformu. K tomu by bylo třeba najmout do vývojového týmu mnohem více lidí a stejně by nebylo možné odladit všechny možné kombinace uživatelských prostředí. Většinou se celý vývoj omezí na jednu nebo dvě platformy a na ně se začne celá aplikace transformovat. Je velmi pravděpodobné, že bude pro vývoj tlustého klienta použit rozdílný programovací jazyk. Další překážkou bude vyškolení celého vývojového týmu na nové aplikační prostředí nebo výměna lidí v týmu. Po vytvoření první verze nové aplikace běžící jako tlustý klient následuje distribuce uživatelům. Na uživatelské počítače jsou kladeny vyšší nároky na přenos dat než v případě přístupu přes tenkého klienta. Uživatel si místo spuštění internetového prohlížeče musí stáhnout instalační balík a nainstalovat novou aplikaci. Až poté může novou aplikaci začít používat. Další obtíže nastanou při vyvolání chyby aplikace. Vše běží na uživatelském počítači a je třeba poslat podrobnou zprávu o vyvolané chybě zpět autorům aplikace. Ladění tímto způsobem je mnohem komplikovanější než v případě umístění aplikace na serveru. Je třeba doplnit detailní hlášení o chybách nebo v některých případech přímo telefonicky komunikovat s uživatelem, případně jej navštívit osobně a chybu programu řešit na místě. Jakmile bude chyba odhalena a v nové verzi aplikace opravena, je třeba mít nějaký mechanismus kontroly nových verzí a jejich automatickou distribuci. Případně informovat uživatele a nechat aktualizaci aplikačního vybavení na něm. Přechod na tlustého klienta samozřejmě není pouze plný negativ, která byla do teď zmiňována. Zahrnuje také pozitiva, která převáží všechny nevýhody a vedou k řešení tímto způsobem. Při instalaci programu na klientský počítač má aplikace větší kontrolu prostředí, na kterém běží a pokud nejsou splněny všechny podmínky, může na to nějak operativně reagovat a

20

informovat uživatele. Po stažení instalačního balíku a prvním spuštění aplikace nemusí být nutné připojení k internetu (záleží na charakteru aplikace). Tlustému klientu může stačit připojení pouze v pravidelném časovém intervalu, kdy jsou data synchronizována a pak zase může dál běžet bez komunikace po internetu. Minimalizuje se tak množství přenášených dat přes internetové spojení (veškerá činnost je nad daty provedena u klienta a po síti je odeslán pouze výsledek). Vývojový tým má větší kontrolu nad grafickým uživatelským rozhraním. Může využívat lepších možností ovládání celé aplikace (například drag&drop). Navíc je ovládání aplikace nezávislé na rychlosti internetového spojení, a proto se neprojeví špatná kvalita linky na rychlosti ovládání aplikace. V případě velkých výpočetních nároků při zpracování dat může také většinu práce přesunout na klientský počítač a odlehčit tak procesorovému času serveru. Dohromady tlustý klient nabízí mnohem více nástrojů pro tvorbu aplikací, než se kterými se musí spokojit serverová aplikace. Na druhou stranu je třeba dalších instalací a nestačí jen spustit internetový prohlížeč a začít aplikaci používat ze serveru. Typ klienta Uživatelská základna Kontrola prostředí Složitost aplikace Grafické uživ. rozhraní Síťové připojení

Tenký klient velká nekontrolované jednoduché (polo)statické stálé

Tlustý klient středně velká více kontrolované komplexnější aktivní žádné nebo občasné

Tabulka 2-1 - porovnání tenkého a tlustého klienta

Prostřední vrstva Prostřední vrstva je podstatnou částí celé webové aplikace. Propojuje mezi sebou obě okolní vrstvy, řídí strukturu a obsah dat, které se zobrazují klientovi, poskytuje zabezpečení a ověřování přístupových práv a také přidává do aplikace stavy. Je to vrstva, která spojuje internet s databázovým serverem.

Databázová vrstva Do celého systému lze doplnit téměř libovolný databázový server, pokud jej nainstalovaná technologie podporuje. Pro nasazení lze vybrat technologie od open source projektů: MySQL nebo PostreSQL, až po drahá komerční řešení firem Oracle nebo Sybase.

Technologie výrobce Některé aplikační platformy jsou dodávány s velmi rozsáhlými nástroji, které ulehčují tvorbu aplikací na minimum. Po spuštění stačí pouze vybrat typ aplikace, který je třeba vytvořit a jednoduchý průvodce instrukcemi a otázkami dovede uživatele až do zdárného konce. Jedním z představitelů, který se chová tímto způsobem je firma Oracle u svého produktu Oracle Portal. Uživatelé bez znalosti programování v PL/SQL, tvorby stránek v HTML, CSS a nějakém skriptovacím jazyce mají možnost za pomoci průvodců nastavit vzhled firemního portálu. Zmodifikovat barevná schémata, změnit informace, které se na úvodní stránce zobrazují a dalšími způsoby ovlivňovat chod jejich vlastního portálu.

21

Všechny tyto úkony jsou schopni dělat po jednoduchém základním školení, případně po pročtení manuálu a průvodce, který je dostupný na stránkách Oracle Portal. S malými znalostmi jsou schopni zprovoznit běh celého portálu a zpřístupnit jej do internetu. Po nějaké době mohou uživatelé začít narážet na různá omezení. Naleznou činnosti a změny, které nebude možné za pomoci průvodců uskutečnit. Uživatel, který se nebude chtít dále vzdělávat, se s těmito omezeními smíří a zůstane dál ve vytyčených hranicích. Pokud bude změna doopravdy požadována, tak si možná na provedení změn najme nějakého externího programátora. Případně se nechá proškolit v dalších částech systému, naučí se více ovládat celé pozadí portálů a změny si provede sám. Velmi nepříjemné pro všechny aplikace, které jsou tvořeny za pomoci průvodců je jednotné rozhraní. I když je možné změnit barevná schémata, přeuspořádat umístění informací na stránce, tak nelze vložit webu vlastní firemní identitu. Je nabízeno hotové řešení, které ukáže během několika chvil hotové výsledky. V případě dalšího zájmu a nebo požadavků umožňuje jednoduché modifikace. Pokud si chce firma provádět větší změny a celé řešení si přizpůsobit pro vlastní podmínky, tak musí využít některého z externích programátorů nebo dalších školení a změny si zpracovávat sama.

3 Výběr jednotlivých technologií Podle statistik serveru Security Space [1] je aktuálně nejpoužívanější webový server Apache. Aktuálně má 75% podíl a z hlediska dalšího vývoje se dá usuzovat na další růst. Z toho důvodu je práce zaměřena hlavně na technologie, které lze nasadit na webový server Apache. Podle četnosti používání jednotlivých modulů v serveru Apache [2], lze nalézt i potencionální kandidáty pro testování. První místo vede s více než 50 % modul PHP. V žebříčku ještě objevíme technologie Perl, FastCGI a Python. Pro srovnání s FastCGI ještě přidáme technologii CGI, která byla předchůdce FastCGI a funguje trochu na odlišném principu. Mezi další často využívané technologie patří i platforma Java a ASP.NET od firmy Microsoft. [54] Stále oblíbenějším datovým formátem se stává XML. Univerzální typ dat, který slouží pro výměnu informací mezi různými systémy. Lze jej využít i jako zdroj dat pro generování internetových stránek. Publikování XML reprezentuje aplikační rozhraní Cocoon, které je velmi zajímavé a časem se možná stane nástupcem některých stávajících technologií. Okrajově práce zmiňuje i technologie vycházející z jiného principu. Jedná se o komerční databázové systémy. Namísto vzniku programovacího jazyka pro internet se snaží s existujících databázových systémů vytvořit různá exportní rozšíření. Ta potom mají umožnit pohodlnější publikování uložených dat v databázových systémech. Budeme se zajímat o rozšíření WebDB databázového systému Oracle a také postrelační Caché.

4 Představení jednotlivých testovaných technologií 4.1 CGI CGI neboli Common Gateway Interface [17]. Předchůdce technologií, které umožnily dynamický obsah na internetu. Je tím nejjednodušším rozhraním, které podporuje snad každý webserver.

22

CGI programy byly nejdříve psány v programovacím jazyku C nebo ve skriptovacím jazyku Bourne shell. Jazyk C je nízkoúrovňový a má velmi nepohodlnou manipulaci se znakovými řetězci. Většina vývojářů proto hledala jednodušší nástroje. Řešením se stal Perl. Dnes můžeme říct, že se Perl stal nejvíce používaným programovacím jazykem pro CGI. Různá rozšíření ale nebrání zvolit cokoliv jiné. CGI totiž, díky existenci různých knihoven, podporuje téměř libovolný programovací jazyk.

Obrázek 4-1 - Schéma běhu CGI skriptu

Při každém požadavku na server je spuštěna nová kopie CGI skriptu. Jsou načtena data z hlavičky HTTP požadavku a jeho parametry a následně předána nově vytvořené kopii. Tento skript je poté spuštěn a má ke všem zaslaným parametrům přístup jako k proměnným prostředí. Hlavní nedostatky CGI jsou zřejmé: • každý požadavek nutí systém vytvořit nový proces. Představte si zátěž, kterou zapříčiní start interpretu Perlu a poté například připojení do databáze. Nyní tuto hodnotu vynásobte stem nebo tisícem požadavků, které mohou přicházet každou vteřinu, na zatíženém serveru. Stránky používající CGI trpí často malou rychlostí, i když používají předkompilované programy napsané v jazyku C. • protokol nebyl navržen tak, aby počítal se zpracováváním sessions (možnost uchování stavů aplikace). Data každé session jsou vymazána, protože po vykonání programu se proces ukončí. Je třeba psát speciální kód, který bude sessions zpracovávat a ukládat. Tyto nevýhody vedly vývojáře k různému obcházení - komunikaci s již běžícím procesem za pomoci API webového serveru a nebo za použití obecného IPC mechanismu. Na základě toho se v roce 1995 vynořilo FastCGI, které je založeno na zcela jiném principu než jeho předchůdce.

4.2 FastCGI Hlavním rozdílem od CGI je to, že skripty jsou překompilovány a spuštěny pouze jednou. Globálně inicializované objekty, jako například persistentní připojení k databázi, jsou také

23

persistentně udržované [18]. Skripty jsou spouštěny miniaplikačním serverem, jedním procesem, který je zodpovědný za opakovaný běh skriptu a zasílání odpovědí na požadavky webserveru. FastCGI skripty běží mimo webový server a komunikace je realizována za pomocí unixového socketu. Všechny požadavky jsou řešeny v pořadí FIFO. Je zde také možnost rozprostřít zátěž serveru na několik nezávislých počítačů s běžícím FastCGI skriptem. Místo spojení přes unix socket se použije TCP/IP spojení.

Obrázek 4-2 - Schéma běhu FastCGI skriptu

FastCGI přímo podporuje sessions na straně serveru. Tato podpora se nazývá session affinity a spočívá v tom, že opakované požadavky od jednoho klienta jsou směřovány stejnému aplikačnímu serveru FastCGI. Za pomoci speciálních knihoven může programátor manipulovat s daty uloženými pro session.

4.3 PHP - Hypertext preprocessor PHP je následníkem úspěšného projektu PHP/FI (Personal Home Page/Forms Interpreter), který vytvořil v roce 1995 Rasmus Lerdorf. Nejprve PHP/FI bylo několik skriptů v Perlu, ale později bylo kompletně implementováno v jazyku C. Díky tomu bylo možno komunikovat s databází a vytvářet jednoduché dynamické internetové aplikace.

24

Kolem roku 1997 vyšla další verze PHP/FI 2.0, kterou již používalo několik tisíc uživatelů na přibližně 50 000 doménách. Během roku 1997 začali vytvářet Andi Gutmans a Zeev Suraski kompletním přepisem a několika vylepšeními první verzi PHP [20]. Objevili v PHP/FI několik nedostatečně výkonných částí, na základě jejich univerzitního projektu. Kompletně PHP/FI přepsali a po devíti měsících testování koncem roku 1998 uvedli PHP 3.0 jako oficiálního následníka projektu PHP/FI. Na rozdíl ostatních skriptovacích jazyků, včetně Perlu nebo Pythonu, má PHP trošku opačnou filosofii. Místo vkládání kompletního HTML kódu do skriptu v některém z jazyků a obalením aplikační logikou je kód PHP vkládán do HTML stránky. Nápad vkládat programový kód přímo do HTML vedl nakonec ke vzniku šablon (například Smarty) a jejich dalšímu použití. V dnešní době jsou šablony využívány od jednoduchých stránek s přístupem do databáze až po komplexní komerční aplikace založené na XML. Největší využití nalézají šablony na serverech s velkým množstvím obsahu. Ať se jedná o zpravodajský server a nebo publikační systém administrující stránky obce. Kromě PHP najdeme ještě další skriptovací jazyky s podobným přístupem ColdFusion, JSP a ASP. Nejvíce používaným je PHP [2]. Cílem PHP bylo poskytnout možnosti rychlého vývoje aplikací pro internet. PHP používá syntaxi podobnou Perlu s cykly a podmínkovými bloky z programovacího jazyka C. Nabízí lehce použitelné příkazy téměř pro libovolnou operaci v prostředí webu. Lze se postarat o uložení souboru, persistentní databázové spojení, práci se sessions a mnoho dalšího včetně dynamického generování PDF souborů. Jednoduché použití a velké spektrum modulů zapříčinilo rozšíření PHP do obecného povědomí a stále častější použití. PHP může pracovat buď jako rozšíření Apache (modul) a nebo jako CGI skript. Více efektivní je použití modulu. Pokud se nainstaluje PHP do Apache jako modul znamená to následující: PHP parser se nahraje pouze při startu serveru a každý nový proces Apache jej již obsahuje. PHP skripty jsou interpretovány při každém požadavku na daný soubor. Některé objekty deklarované jako persistentní, jako například připojení do databáze, zůstanou otevřené i po skončení skriptu. Na rozdíl od FastCGI zde nejsou žádné sdílené objekty. Například připojení do databáze patří jednotlivým procesům Apache, provádějícím nějaký skript. V paměti je nahrané skriptovací jádro Zend, to nahraje požadovaný skript, nahraje moduly potřebné pro provedení skriptu a celý kód provede. V případě potřeby také zajišťuje komunikaci s externími zdroji dat.

4.4 Perl Perl (Practical Extraction and Report Language) umí samozřejmě víc než jen extrahovat nebo reportovat. Je to obecně použitelný skriptovací jazyk, který vytvořil v roce 1987 Larry Wall [21]. Primárně byl určen pro operační systém UNIX, ale během vývoje byl portován i na další operační systémy. Po programovacím jazyku C je to pravděpodobně nejportovanější programovací jazyk. Larry Wall vyvinul Perl pro jeden konkrétní problém s tím, že ho udělá univerzálně, aby jej příště mohl použít znovu na řešení dalších problémů. Nakonec se Perl stal nejužitečnějším nástrojem pro zpracování dat.

25

Perl nebyl navržen pro použití na internetu, ale jeho funkčnost byla o tuto možnost rozšířena. V dřívějším použití byl Perl pomalý, protože se interpret spouštěl při každém požadavku na server (propojení přes CGI). Aby se předešlo přebytečné režii, byl vytvořen v roce 1996 modul mod_perl. Vytvořil jej Gisle Aas. Stejně jako v případě použití modulu PHP, ani tady v tomto případě nevzniká další režie způsobená opakovaným spouštěním interpretu. Užitečnou výhodou je kompilace skriptu při prvním spuštění. Pro další použití je uložen ve vyrovnávací paměti a spouštěn bez opakovaných kompilací.

4.5 Python Python vytvořil okolo roku 1990 Guido van Rossum [22]. Je to interpretovaný, interaktivní a objektově orientovaný skriptovací jazyk. Jazyk se stal stejně populární jako Perl, proto byla vytvořena i modulová varianta (vznikl mod_python) místo spouštění přes CGI rozhraní. Programátorům nabízí zajímavý přístup k programovým blokům kódu. Ty řeší za pomoci odsazení na každém řádku. Řádky se stejným odsazením totiž patří do stejného bloku. Tímto nepřímo nutí tvůrce k větší přehlednosti. Modul přistupuje k interpretu Python za pomocí knihovny libpython a umožňuje jej spouštět přímo v procesu serveru Apache. Dřívější verze knihovny mod_python poskytovaly pouze málo nástrojů pro vytváření stránek. I když mod_python obsahoval mapování internetových adres na funkce nebo objekty Pythonu nazývané Publisher (inspirované aplikací Zpublisher od autora jménem Zope). Nyní již poskytuje další funkce pro plné využití v prostředí na internetu. Od verze 3.1 je k dispozici nativní podpora cookies, včetně kryptografického podpisu dat. Existují také podpůrné funkce k serializaci proměnných na hodnoty, aby je bylo možné uložit do cookies. Práce se session, včetně náhodného generování unikátního čísla. Session může být uložena buď v databázi, nebo přímo v paměti (podle toho, jestli Apache běží v několika procesech a nebo v několika vláknech). Objekt Session je rozšiřitelný, tak je možné libovolně modifikovat úložiště jednotlivých session. Na konec představuje verze 3.1 vlastní implementaci PSP (Python Server Pages). Tento framework umožňuje vkládání kódu do HTML podobně jako je tomu u PHP, JSP nebo ASP. PSP parser je vytvořen za pomoci nástroje flex [24]. Flex je nástroj pro rychlé generování lexikálních analyzátorů a podléhá GNU licenci.

4.6 Java J2EE není produkt. Jedná se hlavně o specifikaci, která definuje komunikační rozhraní mezi aplikací a kontejnerem. Pro vývoj webových aplikací v prostředí Java se používají dvě možné architektury. První možnost využívá JSP stránek nebo servletů v prostřední vrstvě k tomu, aby obsloužila připojované klienty a starala se o celou logiku aplikace.

26

Obrázek 4-3 - JSP/Servlet architektura

Malé a střední aplikace využívají tento způsob tvorby aplikací. Druhý typ architektury zahrnuje použití serveru J2EE a Enterprise JavaBeans (EJB). Tato varianta je vhodná hlavně pro rozsáhlé podnikové aplikace, kde bude potřeba nasadit škálovatelné řešení.

Obrázek 4-4 - Enterprise JavaBeans

Architektura servletu Servlet je Javová třída, která může být načtena a spuštěna webovým serverem. Takový webový server se nazývá kontejner (v počátcích byl nazýván servletovým motorem – servlet engine). Servlet komunikuje s klientem podle modelu požadavek-odpověď protokolem HTTP.

27

Obrázek 4-5 - Architektura servletu

V aplikaci JSP je servletový kontejner nahrazen kontejnerem JSP. Na oba kontejnery je odkazováno jako na webové kontejnery nebo jako JSP/servlet kontejnery. Servletová aplikace může taktéž obsahovat statický obsah – HTML stránky nebo obrázky. Protože by nebylo příliš vhodné, aby byl statický obsah přeposílán zprostředkovaně přes servlet řeší se předřazením serveru mezi servlet a klienta. Pro vyřizování požadavků na statický obsah vyřizuje vše webový server. Pokud jsou požadavky pro servlet, tak jsou přeposílány servletu.

Obrázek 4-6 - Servlet v kombinaci s HTTP serverem

Fungování servletu Servlet je nahrán do kontejneru při prvním požadavku. Zpracuje přeposlaný požadavek uživatele, zpracuje jej a předá zpět servletovému kontejneru. Ten odpověď posílá zpátky klientovi. Po zpracování požadavku zůstává servlet v paměti a čeká na zpracovávání dalších požadavků. Není z paměti odstraněn, dokud kontejner nezjistí nedostatek paměti. Pokaždé, když je nějaký servlet požadován, tak je překontrolováno stáří nahraného servletu a souboru na disku. Pokud je nahraný servlet starší než ten na disku, je opětovně nahrán do paměti. Není třeba restartovat servlety v případě nějaké změny, vše se děje automaticky po přepsání původního souboru.

Kontejnerový servlet Tomcat Dnes je k dispozici mnoho servletových kontejnerů, které lze pro programování použít. Jeden z nejpopulárnějších je Tomcat. Původně navržen firmou Sun Microsystems.V říjnu 1999 byl předán do rukou nadace Apache Software, kde se stal součástí projektu Jakarta. Dva měsíce po převzetí nadací Apache Software byla zveřejněna verze Tomcat 3.0. Následovalo několik zveřejněných verzí, než se dospělo k 3.3 podporující specifikaci servlet 2.2 a JSP 1.1.

28

Dalším následníkem byla verze 4.0 (Catalina), která byla kompletně přeprogramována. Podporuje specifikaci servlet 2.3 a JSP 1.2 a stejně tak je zpětně kompatibilní se servlety 2.2 a JSP 1.1. Následující verze 5.0.x vylepšuje Tomcat v mnoha ohledech: • výkonové optimalizace a omezuje garbage collection • přepsaný vývojový nástroj (deployer) umožňuje validaci a kompilaci celé aplikace před nasazením do produkčního prostředí • kompletní monitorování serveru za pomocí Java Management Extensions (JMX) • rozšířená dokumentace • vylepšené zpracování taglibs • zlepšená integrace na jednotlivé platformy (nativní Windows a Unix wrappery) Momentálně vyvíjená verze je Tomcat 5.5.x, která upravuje objevené nedostatky, optimalizuje rychlost zpracovávání a celkový výkon kontejneru. Je podporována specifikace servletů 2.4 a JSP 2.0. Na rozdíl od konkurenčního konejneru JRun obsahuje Tomcat i vlastní webový server. Tomcat je proto možné použít nejen pro zpracování servletů nebo JSP stránek, ale také statického obsahu (HTML stránky, obrázky, ...).

JRun Alternativou k Tomcatu je prostředí JRun, které bylo vyvíjeno během rozvoje používání Javy na internetu. V roce 1997 se jednalo o první dostupnou servlet engine. A hned rok poté v roce 1998 se stalo JRun Pro první komerční aplikací podporující JavaServer Pages (JSP). Tvůrce JRunu firma Live Software byla odkoupena společností Allaire Corporation. A následně byl celý produkt prodán firmě Macromedia. Nynější JRun verze 4 je nedílnou součástí iniciativy MX. ColdFusioin MX je založeno na technologii JRun. A Rich Internet Aplikace využívají navíc Flash jako uživatelské rozhraní komunikující se serverovou aplikací v Javě. Macromedia se aktivně účastní Java Comunity Process (JCP), který určuje, jak jsou standardy v Javě nastolovány. A dále se firma Macromedia snaží aktivně podílet na iniciativách souvisejících s open source komunitou. Konkrétně hlavně se systémem Axis – Java Web Service.

4.7 ASP Active Server Pages (ASP) je technologie pro tvorbu internetových aplikací firmy Microsoft. Využívá se hlavně na jejich vlastním webserveru Internet Information Services (IIS). Tvorba stránek v ASP je podporována existencí vestavěných objektů. Objekty jako Request, Response, Server, Session nebo ASPError by měly vývojářům usnadňovat programování. Většina stránek je psaná za pomocí Visual Basic Scriptu, ale je možné použít i jiné skriptovací jazyky: JScript nebo Perlscript. ASP technologie se dočkala i portu pro web server Apache, kde je k dispozici modul Apache::ASP pro tvorbu perlových ASP stránek pro server Apache. Nyní již je postupně nahrazována novější technologií ASP.NET.

29

4.8 ASP.NET S technologií ASP.NET firma Microsoft přepracovala kompletně skriptovací jazyk ASP a ačkoliv se nové jméno podobá tomu původnímu, tak snad nic jiného nezůstalo. Technologie je založená na virtuálním stroji a běhových knihovnách Common Language Runtime (CLR). Umožňuje použití více než 40 programovacích jazyků. Kromě původního VBScriptu, JScript .NET nebo standardizovaného C# je možné programovat v open source jazycích jako je Perl nebo Python. I když je prostředí používáno hlavně pro běh aplikací na systému Windows, existuje také implementace knihovny pro systém Unix. ASP.NET se snaží o usnadnění přesunu od vývoje Windows aplikací k programování pro internet. Snaží se vývojářům nabídnout stejné možnosti jako v uživatelském prostředí Windows. Na rozdíl od klasického skriptovacího programování pro internet se .NET technologie snaží nabídnout programování řízené událostmi. Kombinováním různých technologií umožňuje do internetového bezestavového prostředí vnést persistentní (mezi požadavky) stavy. Tyto stavy je dokonce možné ukládat do SQL databáze, do odděleného procesu běžícího na stejném stroji jako webserver nebo úplně na jiný stroj. Takové stavy odolají i restartu IIS nebo pádu běžícího procesu ASP.NET. Vytvořené aplikace běží nativně na IIS od verze 5.0 výše a web serveru Cassini (server naprogramovaný v technologii .NET a používaný hlavně s WebMatrix a prostředím free asp.net 1.1). Navíc lze aplikace spustit i na libovolném linuxovém frameworku kompatibilním se standardem ECMA [49]. Generovaný kód HTML 4.0/JavaScript je částečně nestandardní a lépe funguje hlavně v prohlížeči Microsoft Internet Explorer. V ASP.NET 2.0 je již situace o něco lepší, ale některé komponenty (TreeView) by ještě potřebovaly několik úprav. Navíc je kód generován podle typu prohlížeče přistupujícího k aplikaci.

.NET Framework Microsoft oznámil iniciativu týkající se technologie .NET v červenci 2000. Platforma .NET je nové programátorské rozhraní pro služby MS Windows a API technologií, které Microsoft vytvořil během devadesátých let. Začleněné jsou komponenty COM+, nástroj pro tvorbu webu ASP, plně podporující XML a objektově-orientovaný návrh aplikací. Podporuje také nově vznikající protokoly webových služeb SOAP, WSDL a UDDI. Směr vývoje se zaměřuje na internet. .NET Framework verze 1.0 byl zveřejněn v roce 2002. K dispozici byla samostatně distribuovatelná verze a také se framework stal součástí vývojového nástroje Visual Studio .NET (známé také pod označením Visual Studio .NET 2002). V dalším roce byla vydána verze 1.1 a jako první se stala součástí operačního systému Microsoft Windows – je obsažena v Microsoft Windows Server 2003. Byla přidána podpora ASP.NET pro mobilní zařízení. Ta byla v minulosti distribuována zvlášť. Bylo nutné provést několik změn týkajících se bezpečnosti. Je možné spouštět aplikace z internetu částečně důvěryhodným způsobem. A aplikacím napsaným v ASP.NET lze povolit zabezpečení přístupu k zdrojovým kódům. Součástí frameworku se také stala podpora ODBC a databází Oracle. K dispozici byla dána také verze pro malá zařízení - .NET Compact Framework. Od října 2005 je k dispozici i verze 2.0. Přináší několik užitečných vlastností. Pro snažší tvorbu uživatelského rozhraní moduly pro šablony vytvářených stránek, různé typy navigace 30

(menu, drobečková navigace nebo stromové zobrazení). Bezpečnost podporují hotové moduly pro kompletní správu uživatelů. Vytváření a správa uživatelů, jejich přihlašování a s tím spojený personalizovaný obsah, kde je možné propojení na ovládací prvky bez psaní kódu. Pro přístup k datovým zdrojům je definována mezivrstva datových zdrojů, které propojují zdroj dat s komponentou zobrazující data v aplikaci.

Architektura .NET Framework Dvěma hlavními komponentami jsou Common Language Infrastructure (CLI) a Common Language Runtime (CLR). CLI je specifikace pro prostředí, ve kterém běží aplikace. Zahrnuje společnou definici typů, základní knihovny tříd a na platformě nezávislý mezikód označovaný jako Common Intermediate Language (CIL). CLR poskytuje prostředí pro běh aplikací napsaných v CIL. Předtím, než může být CIL kód spuštěn pod CLR, musí být přeložen (typicky za pomocí Just In Time kompilace) do strojového kódu.

Obrázek 4-7 - Architektura .NET framework

Každé CIL obsahuje popisné informace (.NET metadata). CLR metadata ověřuje pro spuštění správných metod. Metadata jsou obvykle generována kompilátorem, při překládání aplikace do CIL. Ale programátor může vytvářet vlastní metadata za pomocí vlastních atributů. Pokud je z libovolného jazyka vygenerována CIL, je možné jej spouštět na libovolném CRL nebo spolupracovat s moduly napsanými v libovolném dalším .NET jazyce.

31

Obrázek 4-8 - Zpracování libovolného podporovaného programovacího jazyka

Kód je umístěn v .NET Assembly, což v případě Windows znamená Portable Exacutable (PE) DLL nebo EXE soubory. Assembly slouží k ukládání kódu, jeho verzování a zabezpečení. Skládá se z několika souborů a musí být připojen manifest, který obsahuje metadata pro celou assembly. Jednoznačná identifikace je možná jménem PE souboru, číslo verze a token veřejného klíče (64bitový hash veřejného a soukromého páru klíčů). Schéma označování umožňuje CLR identifikovat jednoznačně každou aplikaci a také je možné všechny aplikace sloučit do globální Assembly Cache, kombinovat stejné knihovny v několika verzích bez nebezpečí, že by byla nahrána špatná verze.

ASP.NET Postback V HTML existují dva prvky, které odesílají požadavky zpět na server. Jde o vstupní prvek input typu submit a typu image. Nicméně ASP.NET umožňuje zajistit i ostatním prvkům ve stránce volání zpětných požadavků podobným způsobem. Pro kontaktování serveru se používá objekt XmlHttp a tento způsob se nazývá postback. [55] Tento mechanismus není nutné používat přímo. V ASP.NET existují metody, které tvorbu takových prvků ulehčují. Pro vygenerování prvku, který bude vyvolávat post-back, a následné zpracování odeslaných dat je třeba implementovat rozhraní ICallbackEventHandler. Toto rozhraní obsahuje jedinou metodu, která slouží ke zpracování post-backu. Programátorům tato funkce umožňuje jednodušší tvorbu aplikací, není třeba se zabývat skriptováním na straně klienta, ale stačí jen nadefinovat prvky se zpětným voláním. Pohodlnost tvorby takových prvků na druhou stranu vyvažují větší požadavky na kvalitu linky. Z klienta je odesíláno větší množství požadavků a celkově i větší objem dat. O tuto možnost nejsou nicméně ochuzeni ani programátoři jiných programovacích jazyků, jen si musí potřebnou funkčnost dodělat do své aplikace za pomoci JavaScriptu.

4.9 Cocoon Projekt Apache Cocoon odstartoval v roce 1998 italský student Stefano Mazzocchi [25]. Byl nespokojený s omezeními klasického HTML, když měnil design domácí stránky Apache. Rozhodl se použít XML a XSL jako základ nového programu, protože mu to umožnilo 32

oddělit různé části návrhu webu (obsah, vzhled, architekturu a logiku) mezi několik lidí bez vzájemného zasahování do práce. Namísto psaní všech důležitých komponent se Mazzocchi rozhodl použít již existující programy, které již existovaly a nebo byly vyvíjeny. Cocoon používá mnoho dalších komponent z různých projektů Apache (například Xalan nebo Xerces), byl jimi ovlivněn a zpětně je ovlivňuje. Během roku 2001 se přihlásilo do emailové konference přes 2000 lidí. K vývoji se připojilo i několik velkých firem, což je pro vznikající projekt dobrým znamením. Na vývoj dohlíží osm hlavních vývojářů jádra systému Cocoon, kteří kontrolují správnost nového programového kódu a také základní kód mění. Mnoho dalších vývojářů se podílí na tvorbě nových komponent a pomáhá při hledání a opravě chyb. Celý projekt Cocoon byl vytvořen tak, aby mohl existovat vedle již stávajícího J2EE řešení a nebo s ním i spolupracovat. Může čerpat z mnoha různých zdrojů dat jako je například databáze, LDAP, nativní XML databáze, systém SAP nebo přes síťové připojení k libovolným datům uloženým v XML formátu. Kromě HTML umožňuje výstup i ve formátech jako jsou WML, PDF, SVG nebo RTF. Když přijme Cocoon HTTP požadavek webového klienta, rozhodne, která roura jej zpracuje. První komponenta v rouře musí vygenerovat počáteční XML data (přesněji řečeno události SAX), která jsou předána na vstup další komponentě, ta data nějak transformuje, předá další komponentě, až poslední komponenta data (resp. události SAX) serializuje do výstupního proudu, který je zaslán zpět webovému klientovi. Spouštět Cocoon je možné buď jako servlet a nebo přímo z příkazové řádky. Dále je nabízen skriptovací jazyk spouštěný na serveru a známý pod označením XSP (Extensible Server Pages).

4.10 Caché Vývoj post-relační databáze Caché začal v roce 1995 [26]. Produkt vznikl jako následník rodiny databázových produktů společnosti InterSystems založených na M technologie definované ANSI standardem. V roce 1997 byla vydána verze Caché 2.0 a během následujících let se každý rok podařilo přijít s verzí další. V prosinci roku 2000 byla vydána Caché verze 4.0, která klade hlavní důraz na vývoj webových aplikací a umožňuje přímou tvorbu internetových stránek generovaných přímo z databázového zdroje - Caché Server Pages. Následující verze produktu - Caché 5.0 - vydané v prosinci 2002 dále rozvíjí podporu internetu. Zavádí se podpora XML a také podpora SOAP a web services. Vytvořený webový výstup z databáze Caché je při prvním zobrazení kompilován do jazyka databázové platformy - Caché ObjectScript. Při následných zobrazeních se již pouze zkompilovaný kód provádí. Vzájemnou komunikaci prohlížeče s databází Caché realizuje CSP brána. Ta směřuje požadavky zasílané na webserver na aplikační server Caché a také opačným směrem. CSP bránu lze na server nainstalovat jako ISAPI/NSAPI/CGI rozhraní nebo v případě serveru Apache také jako modul přímo zkompilovat do jádra Apache serveru.

33

CSP stránky jsou klasické internetové stránky, které obsahují speciální CSP tagy vykonávané na serveru. Tento kód se vykonává před odesláním stránky klientovi do prohlížeče, ten již obdrží čistý HTML kód bez speciálních značek.

4.11 Oracle WEBDB/Portal K podpoře webového publikování byl donucen i nejznámější tvůrce databázového systému Oracle. Modul umožňující generování stránek na datech uložených v databázi Oracle nazval WEBDB [27]. Od verze Oracle 7.3.4 jej již lze použít, ale pouze v případě, že není třeba pracovat s dokumenty kancelářských aplikací. Od verze Oracle 8 jej lze využívat přímo. Kromě modulu WEBDB je třeba ještě nějak spojit uživatele s databází. To je realizováno buď přes WEBDB listener, který směřuje HTTP požadavky na WEBDB modul. Nebo lze propojení realizovat za pomocí webového serveru (Apache nebo IIS). Toto připojení je realizováno pomocí CGI skriptů. WEBDB listener se k databázi připojuje pouze poprvé, na rozdíl od CGI odpadá část režie opětovného připojování a měl by být rychlejší. Poslední možností je připojení za pomoci cartridge do aplikačního serveru Oracle. Od verze Oracle 9 v roce 2001 bylo rozšíření WEBDB zcela nahrazeno technologií Oracle9iAS Portal - komponentou aplikačního serveru Oracle [28]. A stejně je tomu tak i ve verzi Oracle 10g, která byla uvolněna v prosinci 2004. Celé řešení slouží k publikování na internetu nebo intranetu. Administrace je možná díky mnoha přehledným a jednoduchým průvodcům. V nich lze vytvořit většinu potřebných věcí. V případě, že je potřeba vytvořit něco speciálního, lze použít přímo ručně psaný sqlplus kód. Veškerá aplikační logika internetových stránek je uložena v databázi.

5 Bezpečnost 5.1 Dva různé pohledy Pokud se na hodnocení jednotlivých technologií podíváme z bezpečnostního hlediska, můžeme jej rozdělit na bezpečnost lokální a vzdálenou.

Lokální bezpečnost Lokální bezpečnost znamená zajištění, aby nedošlo k průniku zevnitř. Ochranu před útočníkem, který má již k počítači přístup (fyzický a nebo vzdálený za pomoci např. ssh). Útočník mohl přístup získat neoprávněně nebo systém již využívá s omezenými právy k jiným účelům prováděným na stejném počítači. Neoprávněný přístup mohl být získán díky špatnému zabezpečení operačního systému nebo jiné běžící aplikaci. Vzdálené riziko představují programy, přístupné nějakým způsobem do internetu. Ať se jedná o FTP server, databázový server nebo SMTP server. Libovolná z těchto služeb, pokud nebude dostatečně aktualizovaná a záplatovaná, může být využita k získání lokálního přístupu a následně k bezpečnostnímu incidentu na serveru.

Vzdálená bezpečnost Vzdálenou bezpečností webové aplikace označíme zabezpečení všech uživatelských vstupů do aplikace. Pokud jsou na všech místech vstupující data korektně kontrolována a ověřována, je tato bezpečnost zaručena. Vstup dat musí propustit pouze znaky, které jsou povolené. V úvahu je třeba brát i možnost přetečení vyrovnávací paměti při vložení delšího vstupu, než

34

je očekáváno. Vstupní data musí být buď transformována do použitelné podoby a nebo je třeba vrátit chybové hlášení. Kontrola dat musí probíhat s ohledem na požadovaný typ dat. Zatímco lokální bezpečnost by měl mít na starost hlavně správce provozovaného serveru, o vzdálenou bezpečnost se již dělí s programátorem webové aplikace. Aplikace je již přístupná z webu a je možné jejím během poskytnout útočníkům snazší místo k útoku. Samozřejmě, že i na vzdálenou ochranu je třeba dbát z pohledu správce serveru a maximálně ji podporovat [14].

5.2 Bezpečnostní rizika Bezpečnostní zranitelnost může být často zavedena získáním, instalací, konfigurací, vývojem a používáním externích programů. Riziko představují i špatně napsané aplikace, které nikdy nebyly zamýšleny pro širší použití. Nebo vedlejší efekt použitím několika nezávislých programů, jež neměly být nikdy nainstalovány dohromady. Například několik úspěšných útoků bylo provedeno díky CGI skriptu instalovaném na mnoho serverů. Přesto může chtít vlastník serveru takové skripty nainstalovat. Administrátor by se měl vždy ujistit, že přístup, funkcionalita a potenciální riziko takových aplikací je co nejmenší. Správnou konfigurací limitovat rizika bezpečnostního narušení serveru.

Deset největších bezpečnostních rizik Organizace OWASP zveřejnila seznam deseti nejzávažnějších bezpečnostních problémů, které se vyskytují v internetových aplikacích [30]. Nekontrolovaný vstup dat - informace, které aplikace získá z HTTP požadavku nejsou kontrolovány před použitím v aplikaci. Útočník může využít této chyby k útoku na webovou aplikaci. Narušená kontrola přístupu – Není správně zajištěno omezení, co vše je povoleno autentizovanému uživateli. Útočník může této chyby využít k přístupu na účty ostatních uživatelů, zobrazovat citlivé soubory nebo použít nepovolené funkce. Narušená autentikace a správa session - Pověření k účtu a informace o přihlášení nejsou řádně chráněna. Útočník může kompromitovat hesla, klíče, session cookies nebo další tokeny. Může narušit bezpečnostní omezení a zjistit identity ostatních uživatelů. Cross Site Scripting (XSS) chyba - Webová aplikace může být použita jako mechanismus pro přenesení útoku přímo do internetového prohlížeče připojeného uživatele. Úspěšný útok může odhalit přihlašovací údaje uživatele, umožnit útok na uživatelův počítač nebo podvrhnout obsah stránky k oklamání uživatele. Přetečení vyrovnávací paměti (Buffer Overflow) - Komponenty webových aplikací v některých jazycích nekorektně kontrolují vstupní data. Může dojít k jejímu zhroucení a někdy i následné kontrole běžícího procesu. Tyto komponenty mohou zahrnovat CGI, knihovny, ovladače a komponenty webového serveru, na kterém běží aplikace. Chyba umožňující vkládání kódu - Webová aplikace používá zasílané parametry k přístupu na externí systémy nebo k operačnímu systému. Pokud útočník dokáže tyto parametry pozměnit a připojit vlastní kód, externí systém tyto příkazy spustí s oprávněními serveru. Nesprávné ošetřování chyb - Chybové podmínky, které nastanou za běhu aplikace, nejsou korektně ošetřeny. Pokud může útočník vyvolat nějaké chyby, které aplikace neošetřuje korektně, může se dostat k detailním informacím o celém systému, zakázat celou službu, obejít bezpečnostní mechanismus nebo způsobit pád serveru.

35

Nezabezpečené úložiště dat - Webové aplikace často používají kryptografické funkce k ochraně informací nebo přihlašovacích údajů. Správná implementace je poměrně složitá, proto většinou dochází k oslabení této ochrany díky nesprávnému použití. DOS útok - Útočník může spotřebovávat aplikační zdroje, aby další oprávnění uživatelé nemohli službu nadále používat nebo k ní přistupovat. Útočník může uživatelům dokonce zamezit přístup k jejich účtům a nebo zavinit selhání celé aplikace. Nezabezpečená konfigurační správa - Velké konfigurační nároky na server mohou mít špatný vliv na zabezpečení webové aplikace. Mnoho konfiguračních možností ovlivňuje i bezpečnost aplikace v případě špatného nastavení. Další text se bude věnovat hlavně zajištění vzdálené bezpečnosti webové aplikace. Budou porovnány možnosti zabezpečení poskytované vývojářům při vývoji webové aplikace v daném prostředí. A také budou brány v úvahu nástroje, které pomohou administrátorům při zabezpečování serveru. Na konci porovnáme jednotlivé technologie z hlediska známých a zveřejněných bezpečnostních chyb.

5.3 Podpora zajištění vzdálené bezpečnosti 5.4 CGI Při tvorbě každého CGI skriptu je třeba dbát zvýšené opatrnosti z bezpečnostního hlediska. Každý CGI skript může poskytnout úplný přístup do systému, pokud bude nevhodně napsán. Lze si jej představit jako malý server, který bude zpracovávat jeden typ požadavků. S tímto přístupem je třeba jej vyvíjet a před nasazením jej pořádně překontrolovat, jestli nenabízí nějakou neošetřenou cestu dovnitř systému. Kromě vytvoření zranitelnosti díky neošetřenému vstupu libovolného formulářového prvku může také poskytnout úmyslně nebo neúmyslně informace o celém počítači. Tyto informace může útočník použít k útoku při napadení serveru. CGI skripty jsou potencionálně nebezpečné, i když server běží pod uživatelem nobody [33, 34]. Podvržený CGI skript běžící jako nobody stále může odeslat systémový soubor passwd, zjistit podrobnosti o síťovém provozu nebo spustit login na některém z vyšších portů. Další problémy vznikají, pokud na stroji nezávisle na sobě pracuje několik uživatelů. Tato situace nastává například u webhostingových serverů. Spouštění CGI skriptů pod jedním uživatelem není ideální. Uživatelské skripty si mohou vzájemně škodit, přistupovat na uložené soubory a nebo dokonce zasláním kill signálu ostatní běžící skripty ukončit. Byly vytvořeny nástroje, které mají tato rizika limitovat a jednotlivé uživatele chránit mezi sebou a od útoku přes internet. Pro CGI se obecně nazývají jako wrappers. Starají se o běh skriptů pod vlastníkem souboru a limitují přístup k souborům na jeden adresář a podadresáře. Slouží jako podpora bezpečnostních opatření, ale ne jako efektivní a dokonalé řešení. Programátor není zbaven dodržování základních bezpečnostních pravidel. Jeho případné chyby mohou mít menší důsledky, než kdyby běžící skripty nebyly chráněny vůbec.

cgiwrap Program cgiwrap vytvořil Nathan Neulinger pro použití na akademické půdě, kde si každý ze studentů může vytvářet vlastní CGI skripty [36]. Vytvořené rutiny potom běží pod uživatelem, který skript vytvořil a v jeho domovském adresáři. Omezuje se tak přístup do cizí adresářové struktury. Stále zůstává riziko napadení domovského adresáře. Za pomoci 36

běžícího CGI skriptu může útočník do domovského adresáře nahrát nějaký trojský kůň. Například se může jednat o některý příkaz, běžně spouštěný z příkazové řádky, a tím od uživatele získat další zajímavá data.

sbox Sbox (Secure Box) patří k dalším podobným nástrojům a opět omezuje CGI skript na práva autora (případně skupiny) skriptu [37]. Nabízí ještě několik dalších možností ochrany navíc. Volitelně je možné volat chroot do konkrétního adresáře a odstínit tak i riziko napadení domovského adresáře autora skriptu. Omezit lze také množství prostředků, které může být CGI skriptu přiděleno. Zamezí se tak případnému neúmyslnému nebo záměrnému pokusu o DOS útoku. Při běhu v operačním systému UNIX je navíc nabízena uživatelská správa adresářů a virtualhostů.

suEXEC Webový server Apache přichází s vlastním řešením nazvaným suEXEC [38]. Neboť je velmi úzce svázán se serverem Apache, není možné jej použít pro některý jiný webový server. SuEXEC nabízí stejnou funkcionalitu jako cgiwrap. Navíc díky tomu, že přímo spolupracuje s Apachem, nabízí použití direktiv User a Group v sekcích VirtualHost. Díky těmto nástrojům je možné lépe udržovat přehled o celém provozu a lépe jej administrovat. Bez wrapperu by nebylo možné najít autora běžícího skriptu a jednoduše odhalit případné problémy.

5.5 FastCGI FastCGI lze použít stejně jako jeho předchůdce s wrapperem suEXEC. Jedná se pravděpodobně o jediné bezpečnostní rozšíření používané pro FastCGI, další možnosti se na internetu najít nepodařilo.

5.6 PHP PHP nabízí přímo ve svém nastavení tzv. bezpečný mód (safe mode), který omezí některé programátorské možnosti [19]. Na druhou stranu přináší větší ochranu celému serveru, kde je PHP nainstalováno, pokud server sdílí několik uživatelů. Na většině hostingových serverů je bezpečný mód aktivován a některé potencionálně nebezpečné funkce nefungují. Samozřejmě bezpečný mód neřeší celkové zabezpečení, ale je jeho součástí stejně jako ostatní zmiňované nástroje. Aktivací se nevyřeší starosti o další části systému - operační systém nebo internetový server samotný. Zapnutí bezpečného módu omezí ty funkce PHP, které manipulují s potencionálně nebezpečnými daty a odkud by bylo možno čekat větší pravděpodobnost chyby a nebo vyšší riziko průniku do systému. Toto nebezpečné chování se snaží omezovat s co nejmenším vlivem na další funkčnost. Pokud se jedná o velmi nebezpečné funkce, případně nějaké systémové volání, tak jsou zakázána úplně (například funkce dl() pro načítání rozšíření PHP za běhu skriptu). Funkce operující se soubory jsou omezeny, buď na konkrétní adresáře, případně kontrolují vlastníka skriptu a manipulovaného souboru (musí se shodovat). Podrobnosti jsou v dokumentaci PHP. Dále se od verze 4.2.0 změnilo výchozí nastavení toho, jak jsou zpracovávány parametry jdoucí do skriptu (register_globals). Data zasílaná metodou GET nebo POST se automaticky

37

registrovala jako proměnné ve skriptu. Pokud programátor zapomněl proměnnou před použitím inicializovat na výchozí hodnotu, tak ji bylo možné přidáním parametru do adresního řádku jednoduše předefinovat a změnit běh skriptu. Tomu se již PHP brání ve výchozí konfiguraci. Proměnné se ukládají do superglobálních polí $_GET a $_POST. Dalším pomocným nastavením je automatické přidávání zpětných lomítek před nebezpečné znaky pro proměnné vstupující do skriptu. Direktiva magic_quotes_gpc ovlivňuje předzpracování proměnných při operacích z požadavků GET a POST nebo práci s cookies. Direktiva magic_quotes_runtime ošetřuje práci s proměnnými, které vstupují z externích zdrojů. Zpracovány jsou jak data jdoucí z databáze, tak i načítané textové soubory. Pro paranoidní správce je možné explicitně za pomoci direktivy disable_functions nebo disable_classes zakázat používání dalších nevhodných funkcí nebo definovaných tříd. Programátor by měl na úrovni aplikace používat funkcí, pro ošetření vstupních proměnných: addslashes() - vrátí řetězec, který před nebezpečné znaky (apostrof, uvozovka, zpětné lomítko a nulový byte - NULL) přidá zpětné lomítko. htmlspecialchars() - znaky používané v HTML převede na entity (např. < na <), zabrání tak uživatelům vkládat HTML kód do aplikace. preg_match() - ověření, zda proměnná vyhovuje regulárnímu výrazu strip_tags() - odstraní HTML a PHP elementy z řetězce. trim() - odstraní bílé znaky (whitespaces) ze začátku a konce řetězce. Korektním ošetřením vstupů se zabrání dvěma nejčastějším chybám nazývaných SQL injection a Cross Site Scripting [11].

5.7 Perl Velmi zajímavý přístup k bezpečnosti nabízí Perl. Zapomnětlivost programátorů při zpracování vstupních proměnných řeší následovně: Je možné jej spustit s parametrem -T, který zapíná tzv. mód nakažlivosti (taint mode). Každá vstupní proměnná do skriptu je pokládána za nebezpečnou - nakažlivou (tainted). Nakažlivé proměnné nemohou být použity v nebezpečných funkcích system(), exec(), eval() nebo open(). Ani v operátoru zpětných uvozovek nebo v dalších funkcích ovlivňujících cokoliv mimo samotný skript. Pokud se přeci jen pokusíte o některou z výše zmíněných akcí, skript bude ukončen s varovnou zprávou. Podobně bude Perl ukončen, když zavoláte externí program bez explicitního nastavení proměnné PATH a ohlásí chybové hlášení - „Insecure $ENV(PATH)“ nebo „Insecure Dependency“. Silně se nedoporučuje přidávat do prohledávané cesty také aktuální adresář - “.”. Při spouštění skriptu může aktuální adresář obsahovat aplikaci útočníka. Ta bude zavolána namísto předpokládaného programu se stejným názvem. Nenakažlivou proměnnou můžeme získat z nakažlivých provedením operátoru ~, který kontroluje obsah za pomoci regulárního výrazu. if ($nakazena_emailova_adresa=~/(\S+)\@([\w.-]+)/) { # vybere nenakažené části zpracované regulárním výrazem $nenakazena_emailova_adresa = "$1\@$2"; }

38

Pokud je nakažená proměnná přidána do nějaké nenakažené, je nakažlivost propagována dále. Riziko, které představovala, se vložením do jiné proměnné nevynuluje. Nově vzniknutou je třeba také překontrolovat, zda obsahuje pouze povolené a očekávané znaky. Toto zpracování sice automaticky nezaručí, že výsledná nenakažlivá proměnná je zcela bezpečná. Donutí programátora explicitně vyjádřit všechny požadavky na proměnnou a zajišťuje vložení těchto požadavků do programového kódu. Programování skriptů je více odolné vůči opomenutým a neošetřeným vstupům.

5.8 Python RExec RExec (Restricted Execution Framework) obsahuje třídu RExec, která podporuje omezené metody funkcí r_eval(), r_execfile(), r_exec a r_import(). Ty mají nahrazovat klasické funkce eval(), execfile(), exec() a import() Pythonu a provádět je ve vyhrazeném prostředí, kde mají přístup pouze k vyhrazeným a důvěryhodným modulům a funkcím. Díky několika bezpečnostním incidentům byly tyto moduly od Pythonu verze 2.3 zakázány a odstraněny.

Bastion Bastion (Restricted access to objects) je modul ke zvýšené bezpečnosti objektů. Jak překlad názvu napovídá bastion - bašta, slouží modul k ochraně některých atributů objektu. Jeho použití je podmiňováno nasazením modulu RExec. Stejně jako předchozí modul je i tento od verze 2.3 zakázán a zmínku o něm lze nalézt pouze v dokumentaci. Jinak nejsou k dispozici žádné další podpůrné nástroje, které by měly podpořit bezpečnost webových aplikací. Vše nechává na zkušenostech programátora a tvůrce každé aplikace.

5.9 Java Bezpečnost se snažili podporvat tvůrci platformy již od samotných začátků při návrhu. Například velmi významným rozdílem mezi Javou a jazykem C/C++ je použití modelu ukazatelů, který zabraňuje přepsání paměti nebo narušení dat. Namísto pointerové aritmetiky Java podporuje pole s kontrolou hranic. Programátor pak nemůže chybně přepsat nějakou část dat nebo přistupovat k prvkům pole mimo nastavené hranice. Tím je znemožněno zavedením chyb, které se mohou objevovat například v jazyce C/C++. I kvůli síťovému a distribuovanému prostředí, ve kterém se aplikace v Javě nachází, byla do návrhu zahrnuta řada dalších ochran před zavedením potencionálních bezpečnostních rizik. Při kompilaci jsou odstraněny ukazatele a alokace paměti. Za běhu se tím zabrání očekáváním některých míst v paměti nebo paměťovým skokům při vykonávání programu. Interpretr kontroluje veškerý bytekód před jeho samotným spuštěním. I pokud applety projdou kontrolou interpretru, tak je jim znemožněn přístup k souborům na lokálním disku počítače, kde jsou spouštěny. Java Virtual Machine (JVM) má za úkol nahrávání, linkování, kontrolu a spouštění jednotlivých tříd (Java Classes) [53]. Třídy jsou nejdříve interpretovány, a pouze části kódu jsou následně optimalizovány a kompilovány. Tím se zachovává úroveň zabezpečené pro 39

interpretovaný kód. Ale stejně tak i pro kód optimalizovaný a kompilovaný do bytekódu. JVM udržuje dva zásobníky volání, aby zůstaly zachovány informace původního bytekódu. Zásobník bytekódu je použit pro kontrolu bezpečnosti za běhu, ověřování správného přiřazení proměnných, přetypování a kontrola hranic polí. Tato analýza by nebyla možná ze statického zkoumání bytekódu, ale je třeba ji provádět za běhu. Kontrola kódu je v JVM proces skládající se ze 4 kroků. Začíná zkoumáním jednotlivých formátů souborů tříd a kontroluje konkrétní značky. Končí kontrolou jednotlivých příkazů a jejich parametrů. Poslední část není dokončena, dokud se nezavolá každá metoda a nejsou překontrolována její přístupová práva. Ve výchozím nastavení je poslední krok kontroly prováděn pouze na třídy, které jsou volány vzdáleně. Kontrolu lze ovlivnit některým z následujících parametrů JVM: • -verifyremote – výchozí nastavení, kontroluje pouze třídy přístupné vzdáleně • -verify – kontroluje všechny třídy • -noverify – vypíná všechny kontroly Tyto přepínače již nejsou v dokumentaci Java 2 zmiňovány, aplikační kód prochází kompletní kontrolou.

Zabezpečení kódu Aby se zabránilo případné modifikaci distribuovaného kódu, je možné balíčky .JAR podepsat. Po podepsání souboru jsou přidány dva další soubory k projektu. Podpis tříd a podpis bloku. Podpisy se tvoří za pomocí jedné z hašovacích funkcí – SHA1 nebo MD5. Další typ ochrany se stará o nemožnost spuštění jako část jiné aplikace, případně je jejím cílem zabránit přístup ke zdrojovým kódum. Při spouštění jsou za kontrolu zodpovědné moduly nahrávající jednotlivé třídy. Zajišťují, aby nebyla použita třída, která je chráněná. Systém tříd uzavřených do jednoho balíku (package) může být zapečetěn (sealed). To zabrání ostatním třídám, aby se připojovaly na konkrétní balík do souboru JAR. Zapečetění se provede přidáním řádku Sealed: true před podepsáním celého balíku. Konfiguračním nastavením (java.security) je možné znemožnit připojení k balíku nebo jen pouhý přístup k němu. Ke chráněným zdrojům nebo pro nebezpečné aplikace je možné definovat přístupová práva (java.security.permission). Práva lze v Javě definovat ke všem důležitým systémovým službám: přístup k souborům, sokety, zobrazování, zrcadlení, bezpečnostní politika, a mnoho dalších. Pro každý skript je možné nadefinovat bezpečnostní politiku (policy). Může se brát důraz na umístění (codebase) nebo autora (signer), který kód vytvořil a podepsal. V JVM je možné používat několik politik definovaných najednou. Výsledná politika vzniká ze sjednocení všech použitých politik. Kvůli bezpečnosti není možné politiku měnit za běhu skriptu. Veškeré operace kontroluje SecurityManager použitím metody checkPermission. Je možné vytvořit privilegovaný kód, který na krátkou dobu získá větší práva přístupu, než jsou aktuálně platící. Například použití fontů, které chce aplikace použít, ale fonty v části chráněné systémem. Privilegovaný kód lze možné vytvořit implementací intarfaců java.security.PrivilegedAction nebo PrivilegedExceptionAction.

40

5.10 ASP.NET Zabezpečení ASP.NET Technologie ASP.NET nabízí několik způsobů, které mají podporovat zabezpečení aplikace. • autentikace – uživatel před přihlášením do systému musí být autentikován, nejlépe takovým způsobem, aby se nepřenášelo uživatelské jméno a heslo v čitelné podobě přes síť • autorizace – při každém uživatelském požadavku by měla být ověřována jeho pravomoc a rozsah přístupových práv. A pokud by byl rozsah nedostačující, tak přístup k operaci odmítnout. • šifrování – nastavení serveru umožňuje zvolit šifrovanou komunikaci přes SSL. Pro větší bezpečnost vytvářených aplikací je v .NET společný bezpečnostní mechanismus, který se stará, aby nedošlo k narušení celého systému některou špatně napsanou aplikací nebo záškodnickým kódem. Mechanismus Code access security[51] zajišťuje ochranu zdrojů a operací před přístupem nedůvěryhodného kódu. Stará se o následující funkce: • definuje práva a skupiny práv pro přístup k jednotlivým zdrojům • umožňuje administrátorům definovat bezpečnostní politiku, která spojí systém práv se skupinami zdrojových kódů • umožňuje pro každý program definovat přístupová práva, která má mít, o které si může zažádat a jaká práva nemá v žádném případě mít možnost získat. • uděluje povolení podle bezpečnostní politiky a definovaných přístupových práv • dovoluje kódu požadovat, aby jej mohla spustit pouze aplikace s určitými přístupovými právy • lze definovat spouštění chráněného kódu pouze aplikacemi, které jsou podepsané určitým digitálním podpisem • stará se o přístupová práva při běhu každé aplikace. Kontroluje, zda jsou získaná oprávnění dostatečná pro provádění operací.

Autentikace IIS a OS Windows IIS server nabízí několik možností autentizace uživatelů při přihlašování do aplikace na IIS serveru. Podporovány jsou základní HTTP autentizace, autentizace uživatelů systému Windows nebo digest autentizace. Je možné je také dohromady kombinovat. • •

• • •

Základní HTTP autentizace – uživatelské jméno a heslo je přenášeno v čitelné podobě od klienta k serveru Integrovaná Windows autentizace – kompatibilní pouze pro prohlížeče IE 2.0 a výše. Není podporován přenos přes HTTP proxy a autentizace je omezena na počítače se stejného doménového stromu. Je vhodné autentizaci používat pouze pro budování firemních intranetů. Digest autentizace – Kompatibilní s firewally a proxy servery, jméno a heslo není přenášeno v čitelné podobě. Je nutné mít uživatelská jména a hesla v čitelné podobě na doménovém serveru. Autentizace formulářem – uživatel vyplní přihlašovací jméno a heslo, které je následně kontrolováno s nějakou databází. Passport autentizace – možnost využít placené služby Microsoft Passport service, kde je registrováno přes 130 miliónů uživatelů. Používání této služby je zpoplatněno.

41

Pro nasazování intranetových řešení je velmi vhodné využít právě autentizace z operačního systému Windows. Uživatel se pro připojení k interní síti nemusí podruhé přihlašovat. Stačí, když se k serveru připojí a má definován přístup pro své uživatelské jméno používané u sebe v počítači. Na IIS serveru je modul WindowsAuthenticationModule[50], který na základě údajů získaných ze systému Windows u klienta vytvoří dva moduly. Modul WindowsIdentity mapuje identitu uživatele systému Windows přistupujícího na IIS server. Modul WindowsPrincipal slouží k určování rolí jednotlivých uživatelů a umožňuje zjišťovat příslušnost do uživatelských skupin. I když se jedná o velmi zajímavé řešení, jde o proprietární technologii firmy Microsoft. Není jej možné nasadit pouze ve spojení webového serveru IIS a připojovaných klientů s operačním systémem MS Windows a prohlížečem Internet Explorer. Pro tvorbu aplikací, kdy je očekáván přístup klientů s jiným typem prohlížečů nebo operačních systémů, je třeba volit jinou formu autentikace.

5.11 Cocoon Neboť je Cocoon servlet, neexistuje zatím žádná utilita, která by podpořila bezpečnost. Opatření by měla být provedena hlavně na straně aplikačního prostředí Javy a nebo internetového serveru samotného.

5.12 Analýza známých bezpečnostních incidentů Všechny informace ohledně bezpečnostních incidentů jednotlivých technologií byly čerpány ze služeb SecurityFocus, CERT/CC a Microsoft Security Bulletin Search.

Security Focus Pravděpodobně největší zdroj informací týkajících se bezpečnosti na internetu. Obsahuje databázi bezpečnostních zranitelností - SecurityFocus Vulnerability Database a známou emailovou konferenci BugTraq. Jedná se o neutrální subjekt, poskytující každý den aktuální bezpečnostní informace. Informace se pro platící zákazníky firmy Symantec objevují ihned a pro ostatní jsou informace vydávané zdarma se zpožděním 48 hodin [29].

CERT/CC CERT (Computer Emergency Response Team/Coordination Center) je institut provozovaný neakademickou částí Carnegie Mellon Univerzity. Je součástí Software Engineering Institute. Byl založen americkým oddělením obrany a oddělením národní bezpečnosti. CERT/CC je centrum, kde jsou vystavovány informace o bezpečnostních zranitelnostech a internetových bezpečnostních problémech. Jsou sledovány trendy v aktivitách útočníků a zveřejňovány řešení bezpečnostních problémů [41].

Microsoft Security Bulletin Search Databáze všech bezpečnostních incidentů pro produkty firmy Microsoft. Je součástí služby Microsoft TechNet a umožňuje prohledávání bezpečnostních produktů dotazem a omezením pouze na některé produkty. Ze všech databází byly ke každé technologii získány záznamy o bezpečnostních zranitelnostech. Za použití fulltextového vyhledávání a nebo vyhledávání podle kategorií.

42

Případné duplicitní informace o chybách byly započítány pouze jednou. Zpracovávány byly všechny informace jednotlivých databází až do poloviny roku 2005.

Rozdělení podle rizika Ke každé zranitelnosti bylo zaznamenáno, zda představuje lokální či vzdálené bezpečnostní riziko. U informací z databáze SecurityFocus byly pouze převzaty již existující označení, z CERT databáze byl typ hrozby zjištěn z popisu chyby. Navíc byla připojena informace, jakého maximálního přístupu může útočník dosáhnout. Zranitelnosti byly klasifikovány do následujících 11 kategorií. Kompletní přístup do systému - získání administrátorského účtu, možnost provádět na serveru libovolné operace. DOS útok (Denial of service) - vyřazení systému z provozu za pomoci nějaké operace Možnost měnit paměť serveru - tato zranitelnost poskytuje útočníkům možnost zasahovat do paměti serveru. Cross site scripting - vložení cizího kódu do stránky serveru, která nemá korektně ošetřenou kontrolu vstupních parametrů. Změna odesílaného emailu - možnost modifikovat odesílaný email, změnit obsah hlaviček a nebo těla zprávy. Rizika záleží na typu aplikace, která na serveru běží. Vkládání kódu do HTTP požadavku - možnost modifikace HTTP požadavku, v závislosti na typu aplikace možnost získání i plného přístupu k celému systému Spuštění s právy serveru - možnost spustit nějaký kód s oprávněním webového serveru Přístup pro čtení všeho - možnost číst libovolná data na disku serveru, může být zneužito k získání přístupových jmen, odhalení přístupových hesel a plnému přístupu Přístup pro čtení s právy serveru - možnost číst veškeré soubory, ke kterým má přístup webový server. Čtení zdrojových souborů jednotlivých skriptů a snazší odhalení dalších případných bezpečnostních slabin. Možný únik informací - ze systému lze zjistit další doplňkové informace, které mohou dopomoci při útoku. Další chyby - blíže nespecifikované a nebo další bezpečnostní zranitelnosti

43

Celkový počet zveřejněných chyb

Vyhodnocení jednotlivých chyb 50 45 40 35 30 25 20 15 10 5 0 CGI

PHP

Perl

Python

Cocoon

Java

Asp.NET Oracle

Caché

Technologie

Graf 5-1 - Počet celkově zveřejněných chyb

Počet chyb

Celkový souhrn všech bezpečnostních chyb nám ukazuje, že mezi nejzmiňovanější technologie patří PHP. Maximum zveřejněných chyb je v roce 2003, dále počet zveřejněných chyb poklesl. Naopak Perl má nejvíce chyb v roce 2004, zatímco v roce 2003 nebyly zveřejněny žádné bezpečnostní zranitelnosti. Technologie Java vykazuje chyby v posledních třech letech. 20 18 16 14 12 10 8 6 4 2 0

1996 1997 1998 1999 2000 2001 2002 2003 2004

CGI

PHP

Perl

Python

Cocoon

Java

Asp.NET Oracle

Caché

2005

Technologie

Graf 5-2 - Četnost chyb během let

Při pozorování četnosti zranitelností podle typu zjistíme, že nejnebezpečnější technologií je Perl. Pravděpodobně nejvážnější chybu, získání kompletního přístupu k serveru, totiž nabízí hned v 7 případech zranitelností. Následují s odstupem 3 zranitelností PHP a Python.

44

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

ASP.net

Oracle

Caché

Graf 5-3 - Kompletní přístup (root)

Java a PHP jsou díky svým zranitelnostem nejvíce ze všech porovnávaných technologií náchylní na DOS útok. Vyřadit z provozu nějakou běžící službu je umožněno v 5 případech. PHP technologie navíc nabízí riziko modifikace paměti na serveru, modifikace odesílaných emailových zpráv a změny HTTP hlaviček v požadavcích zasílaných připojeným klientům. 12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

ASP.net

Oracle

Caché

ASP.net

Oracle

Caché

Graf 5-4 - Denial of service

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

Graf 5-5 - Možnost měnit paměť serveru

45

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

ASP.net

Oracle

Caché

ASP.net

Oracle

Caché

Graf 5-6 - Změna odeslaného emailu

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

Graf 5-7 - Možnost vkládat kód do HTTP požadavku

Dále je PHP favoritem i v případě chyby Cross Site Scripting, která umožňuje útočníkům vkládat do výsledné stránky vlastní kód (většinou se používá JavaScript). Nabízí to 5 zranitelností. 12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

ASP.net

Oracle

Caché

Graf 5-8 - Cross site scripting

Když chce útočník na serveru něco spustit s právy serveru, má opět největší šanci použít některou ze zranitelností PHP (11 zranitelností) a stejně tak získání přístupu pro čtení s právy serveru (11 zranitelností). Získání přístupu pro čtení je u PHP možné ve 4 případech a u ASP.NET ve 3 případech.

46

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

ASP.net

Oracle

Caché

ASP.net

Oracle

Caché

ASP.net

Oracle

Caché

Graf 5-9 - Spouštění s právy serveru

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

Graf 5-10 - Přístup pro čtení pro vše

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

Graf 5-11 - Přístup pro čtení s právy serveru

Případný únik informací, které mohou být pro útočníka zajímavé při plánování útoku, je možný ve 4 případech u technologie Perl a v 1 případě u technologie Cocoon. Java nabízí 2 chyby dovolující získat větší práva běžícím skriptům.

47

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

ASP.net

Oracle

Caché

ASP.net

Oracle

Caché

Graf 5-12 - Možný únik informací

12 10 8 6 4 2 0 CGI

PHP

Perl

Python

Cocoon

Java

Graf 5-13 - Další chyby

Množství zveřejňovaných chyb je závislé nejen na zručnosti programátorů tvořících jednotlivá prostředí. Určitý vliv má i rozsáhlost celé technologie a množství kódu. Čím větší počet programových řádek, tím je větší riziko, že někde v kódu bude chyba. Závisí také na intenzitě používání jednotlivých technologií a jejich rozšířenosti po internetu. Je proto velmi dobré instalovat nástroje zmíněné v předchozí části, aby bylo celé aplikační prostředí před útoky co nejvíce chráněné. Samozřejmostí musí být také sledování aktuálního dění okolo nasazené technologie, objevených bezpečnostních chyb a také následná aplikace bezpečnostních záplat. Aktualizace systému všemi bezpečnostními záplatami a jejich pravidelná kontrola by měla být jednou z hlavních činností správce serveru.

Převážně zranitelnosti vzdálené Kromě technologie Caché se všechny zranitelnosti týkají hlavně vzdálené bezpečnosti. V případě Caché se jedná o špatné bezpečnostní nastavení ve výchozí instalaci. Po instalaci je dovolen přístup pro zápis do libovolného adresáře. Útočník tak může získat oprávnění administrátora. U ostatních zranitelností je možné vzdálené narušení bezpečnosti nebo případně narušení kombinované oběma způsoby.

48

100% 90% 80% 70% 60%

neznámo

50%

ne

40%

ano

30% 20% 10% 0% CGI

PHP

Perl

Python

Cocoon

Java

ASP.net

Oracle

Caché

Graf 5-14 - Chyby dostupné vzdáleně

S nárůstem použití webových aplikací je přímo spojeno i množství bezpečnostních útoků na jednotlivé aplikace. Zabezpečení webových aplikací se dostává mnohem více pozornosti, než tomu bylo v minulosti. Nástroje pro testování se budou ještě více automatizovat, jejich zaměření se bude rozšiřovat. Ruční testování průniku a automatické bezpečnostní testy budou sjednocovány do automatických nástrojů. Základní testování bývalo realizováno detekcí možnosti útoku a jeho následném úspěchu. Například hledáním chyb v přetečení zásobníku a nebo testování přítomnosti nějakých vzorků kódu. Kvůli rostoucí hrozbě Cross Site Scripting útokům se rozšiřuje o další metody detekce víceúrovňových útoků a s tím spojené ukládání stavů aplikace [13,32]. Například několik bankovních institucí mělo nedávno problémy s cross-frame scripting (XFS) útokem. Jedná se o speciální typ útoku nazývaného jako rhybaření (phishing attack), kdy je podvržena pouze část stránky v jednom rámci. Krátce potom uvolnil výrobce testovací nástroje pro simulaci XFS útoku a možnosti zjistit, zda byl útok úspěšný [31]. Z důvodu pomalého vývoje aktualizací jednotlivých testovacích nástrojů, umožňují někteří výrobci testovacích nástrojů přidávat i vlastní testovací skripty. Snižuje se tak reakční doba na vznikající bezpečnostní problémy. Prozatím je nevýhodou nejednotnost skriptovacího prostředí jednotlivých nástrojů. Zvýšený zájem o bezpečnost webových aplikací ilustruje i vznik dvou organizací, které se zaměřují speciálně na technické řešení bezpečnostních zranitelností webových aplikací.

Open Web Application Security Project (OWASP) OWASP je skupinou dobrovolníků, která vydává technickou dokumentaci, nástroje a standardy týkající se webové bezpečnosti obecně. Na jejich stránkách najdeme deset největších nedostatků webových aplikací.

OASIS Web Application Security Technical Committee Technický výbor bezpečnosti webových aplikací vydává klasifikační schémata internetových bezpečnostních chyb, modeluje jednotlivé chyby a vytváří XML schéma popisující podmínky webové bezpečnosti. Navazuje na práci OWASP VulnXML, kterou převzal od skupiny OWASP do své kompetence.

49

6 Měření výkonu 6.1 Prostředí testování Hardwarová konfigurace Pro testování byly použity dva počítače. Jeden počítač sloužil v našem testování jako server a druhý byl použit jako přistupující klient. Podle toho byla také uzpůsobena jejich hardwarová konfigurace.

Klient Klientský počítač s jedním procesorem Intel Pentium Celeron 2,4 GHz se 128KB L2 cache. Operační paměť DDR o velikosti 512 MB. A pevným diskem Seagate 80GB a 7200 otáček. K serveru byl počítač připojen 100Mbit síťovou kartou přes 100Mbit switch.

Server Server byl počítač se dvěma procesory Intel Pentium Xeon 2,66 GHz s 512KB L2 cache. Operační paměť o velikosti 2 GB. Diskem Seagate 18GB, 10 000 otáček/min., 4MB cache na rozhraní Ultra160 SCSI. Počítač používal síťovou kartu integrovanou na základní desce dvouportovou Fast-Ethernet 10/100/1000BaseTX-RJ45.

Softwarová konfigurace

Klient Linuxová distribuce Debian testing, jádro 2.6.7-1-686

Server Linuxové technologie Linuxová distribuce Debian stable, jádro 2.6.10 #3 SMP Apache 1.3.33 Zatím nejpoužívanějším serverem je Apache ve své jedničkové verzi, ačkoliv se dvojková varianta začíná také nasazovat. Proto byl zvolen jako testovací prostředí pro všechny realizované testy kromě prostředí Cocoon. Pro Cocoon byl použit server Jetty, který je obsažen v instalaci projektu Cocoon. Všechny následující moduly byly na server Apache nainstalovány jako dynamicky sdílený objekt (DSO). Pro vzájemné porovnání nemá použití dynamicky sdílených objektů vliv na výkonnost. V případě nasazení některé z technologií do praxe je lepší kompilace modulu přímo do statického tvaru (SO) pro server Apache. • • • •

mod_fastcgi 2.4.2 mod_perl 1.29 mod_python 2.7.11 (Python 2.2.1) PHP 4.3.10 - pro podporu PHP byla nainstalována poslední verze čtyřkového prostředí PHP.

j2sdk 1.4.2_07 Toto prostředí bylo použito pro instalaci a běh frameworku Cocoon. 50

Cocoon 2.1.6 Aplikační prostředí bylo spuštěno na webovém serveru Jetty, který je dodáván spolu s instalačním balíkem programu Cocoon. Server byl spuštěn na portu 8888, na kterém běží ve výchozí instalaci. mysql 4.1.9 Databázový server byl nainstalován pro testování spolupráce jednotlivých technologií s databází. Bohužel se ani po konzultaci nepodařilo nainstalovat podporu mysql databáze pro Python. Proto není mysql testování u této technologie zmiňováno.

Technologie Windows Pro testování technologií ASP a ASP.NET byl na server nainstalován operační systém Windows Server 2003 včetně IIS 6.0 a .NET framework 2.0. K databázi MySQL připojen přes mysql connector net 1.0.6.

6.2 Porovnání výkonu jednotlivých technologií Realizované testy Testování bylo prováděno několika nezávislými testovacími nástroji. Dva z nich byly použity vzdáleně z druhého testovacího počítače a jeden byl použit přímo na serveru. Pro lokální testování bylo využito nástroje testování výkonnosti serveru Apache - Apache Benchmark, který je dodáván přímo v instalaci serveru Apache. Pro vzdálené testování byl použit nástroj httperf, který slouží k měření výkonnosti HTTP protokolu. Vzdáleně byl ještě použit testovací klient naprogramovaný v jazyce C. Lokální měření bylo prováděno pro porovnání se vzdálenými testy. Vzdálené testování se nejlépe přibližuje běžnému provozu celé technologie. Při každém testování byl na server zasílán pevný počet požadavků. Tento pevný počet požadavků byl postupně rozdělován mezi jednoho až několik stovek najednou běžících procesů (klientů). Jednotlivá měření byla prováděna nezávisle na sobě. U jednotlivých měření byl sledován vliv technologie a dalších faktorů na rychlost vyřízení zasílaných požadavků. Tato hodnota je velmi důležitá. Server nesmí uživatele nechat čekat příliš dlouho. Je třeba udržovat průměrnou dobu odezvy na co nejnižších hodnotách. Podle psychologických studií by neměla celková doba odezvy, ani při vysoké zátěži serveru, přesáhnout 8 až 10 vteřin [4].

Vzorky dat pro měření Pro testování bylo vytvořeno pět typů souborů: hello, small, medium, big, mysql a myslq-rand. Každý z nich má cílem otestovat některou z vlastností jednotlivých technologií.

hello Velmi známý a často programovaný skript, který na výstup vypíše frázi Hello World! Tento soubor byl použit pro testování režie, kterou má každá technologie při zpracovávání dat a generování výstupu.

51

small Soubor small má testovat generování malých souborů, konkrétně o velikosti 1kB. Ve většině technologií byl tento skript vytvořen konstrukcí cyklu for s výpisem osmi znaků a 128násobným opakováním. Jeho přítomnost v našem testování měla reprezentovat generování souborů s malou velikostí.

medium Testovací soubor nazvaný jako medium reprezentoval při testování střední velikost stránky. Do velikosti stránky nebyly započítány případné kaskádové styly, související obrázky nebo javascripty. Navíc byla snaha o simulaci vkládání dynamických prvků do statického obsahu. Výstup byl rozdělen na dvě statické části, které se vypisovaly vcelku. V polovině byl vložen krátký výstup a následovala druhá polovina statického výstupu.

big Soubor big reprezentoval v našem testování stránky s datovou velikostí 64kB a byl v našem testování největší. Generování probíhalo ve většině případů za pomoci for cyklu. Pouze v případě technologie Cocoon se cyklus simuloval průchodem a zpracováním XML souboru.

mysql Mysql skript sloužil k testování databázového připojení. Ve skriptu je připojení k databázi, výběr několika položek jednoduchým SQL dotazem z jedné tabulky a odpojení od databáze. Jeho proměřením získáme režii, kterou jednotlivé technologie mají při připojení k databázovému serveru.

mysql-rand Neboť se při měření skriptu mysql projevilo ukládání dotazů do cache databázového serveru, bylo nutné provést ještě jedno měření, kde byly zasílány požadavky s náhodnými dotazy, a vyrovnávací paměť se neprojevila.

Nastavení testovaných technologií Nastavení serveru Apache a jednotlivých technologií ilustruje výpis relevantních částí konfiguračního souboru httpd.conf # minimalizace použití DNS, aby nedocházelo k opakovanému převádění číselných IP adres na jmennou, při každém zaslaném požadavku HostnameLookups Off # konfigurace procesů web serveru Apache Timeout 30 KeepAlive Off MaxKeepAliveRequests 5 KeepAliveTimeout 5 MinSpareServers 20 MaxSpareServers 50

52

StartServers 50 MaxClients 700 MaxRequestsPerChild 1000 # vypnuti kontroly souboru .htaccess, aby při hledání požadované stránky nebyla kontrolována cesta až do kořenového adresáře webserveru a v každé úrovni zjišťována existence souboru .htaccess AllowOverride None # Povolit FollowSymLinks se nedoporučuje z bezpečnostních důvodů, aby se při nepozorném vytvoření symbolického odkazu do adresářové struktury webserveru nevystavila část souborů na internet. Zákaz vede k dalším systémovým voláním funkce lstat() a má tak neblahý vliv na výkonnost serveru. Proto byla tato možnost při testování povolena. Options FollowSymLinks

# nastavení pro testování technologie CGI Options None Order allow,deny Allow from all

# nastavení pro testování technologie FastCGI Options None Order allow,deny Allow from all SetHandler fastcgi-script AddHandler fastcgi-script fcg fcgi fpl # nastavení pro testování technologie Python AddHandler python-program .py PythonHandler hello

53

PythonDebug Off AddHandler python-program .py PythonHandler small PythonDebug Off AddHandler python-program .py PythonHandler medium PythonDebug Off AddHandler python-program .py PythonHandler big PythonDebug Off SetHandler python-program PythonHandler mod_python.publisher # nastavení pro testování technologie Perl Alias /perl/ /diplomka/WWW/perl/ SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI SetHandler perl-script PerlHandler Db

Parametry nastavení MySQL databáze byly následující: key_buffer=128M max_allowed_packet=1M thread_stack=512K thread_cache=200 table_cache=256 max_connections=700

Výchozí nastavení IIS 6.0 bylo změněno takto: 54

Connection Timeout 5 seconds Enable HTTP Keep-Alives bylo vypnuto Request queue limit (number of requests) 4000 Maximum number of worker processes 4

Výpis jednotlivých testovacích skriptů Všechny testované skripty jsou obsaženy na přiloženém CD v adresáři testovane_skripty a jednotlivých podadresářích podle technologie. Static - statické stránky Obsahovaly pouze statický soubor, který byl výstupem ostatních technologií. Byly tu pro referenční porovnání, jaký rozdíl je ve statickém obsahu vůči dynamicky generovaným stránkám. CGI Pro získání maximální rychlosti této technologie byl použit programovací jazyk C. FastCGI Opět z důvodu dosažení maximální možné rychlosti byl zvolen programovací jazyk C. Následující skripty jsou vytvořeny rozšířením skriptů technologie CGI o zpracovávací nekonečný cyklus a přidání hlavičkového souboru FastCGI [35]. Cocoon hello.html Generování probíhalo z jednoho xml souboru za pomocí xsl transformace do výsledné stránky. Následuje výpis všech potřebných souborů pro vygenerování. small.html Co největší podobnosti k for cyklům bylo dosáhnuto vytvořením xml souboru, který obsahoval na každém řádku totéž, co bylo vypisováno jako výstup v jednom kroku for cyklu v předchozích technologiích. Průchod přes jednotlivé položky a jejich transformace do výsledku si lze představit jako for cyklus. medium.html Z xml souboru byla transformována pouze část rozdělující statický výstup na dvě poloviny. Konstantní výstup zde byl předvyplněn již v XSL šabloně popisující transformaci. big.html Poslední testovací soubor byl řešen úplně stejným způsobem jako small.html, jen na rozsáhlejším vzorku dat v souboru big.xml.

6.3 Výsledky měření Použitá metodika Při analýze byla použita metoda analýzy rozptylu, náležící do rodiny obecných lineárních modelů. Analýza rozptylu poskytuje odpověď na otázku, zda určitá vysvětlovaná proměnná závisí na hodnotách jiných, tzv. vysvětlujících proměnných. Obecný model analýzy rozptylu je: 55

Y = m + a + b + … + e,

kde Y jsou hodnoty vysvětlované proměnné, m je konstanta, a, b, … jsou vlivy jednotlivých vysvětlujících proměnných (faktorů), e je náhodná odchylka s nulovou střední hodnotou. Výpočtem se stanovují hodnoty parametrů m, a, b, …, a to tak, aby součet druhých mocnin odchylek Y od součtu m + a + b + … byl co nejmenší (metoda nejmenších čtverců). Přitom u parametrů a, b, … se stanoví pro každou hodnotu vysvětlující proměnné jeden parametr. Jeli tedy v některém případě jedna z vysvětlujících proměnných např. pohlaví nabývající dvou možných hodnot, stanoví se hodnota parametru zvlášť pro muže a zvlášť pro ženy apod. Po výpočtu hodnot parametrů se, zjednodušeně řečeno, testuje, zda jsou hodnoty některé skupiny parametrů natolik blízké nule, že je lze zanedbat. V tom případě se učiní závěr, že vysvětlovaná proměnná nezávisí na příslušné vysvětlující proměnné. Pokud se naopak ukáže, že hodnoty vypočtených parametrů zanedbat nelze, má se za to, že vysvětlovaná proměnná na příslušné vysvětlující proměnné závisí. Často se testují ještě výskyty tzv. interakcí, tedy jevu, kdy určitá kombinace několika vysvětlujících proměnných má na vysvětlovanou proměnnou speciální vliv.

Postup Na server bylo při každém měření zasláno 10 tisíc požadavků. K tomu účelu bylo postupně použito 11 různých technologií (Static, CGI, FastCGI, Perl, Python, Cocoon, PHP, Java servlet, JSP, ASP a ASP.NET) a 4 soubory o různé velikosti od desítek bytů (soubor hello) až po desítky kB (soubor big). U každé kombinace souboru a technologie proběhlo měření celkem čtyřicetkrát, a to s různými počty klientů, kteří se podělili o zmíněných 10 tisíc požadavků. Počty klientů se měnily od 1 do 391 klientů. Výsledkem každého měření byla střední doba vyřízení jednoho požadavku v ms. Data byla následně statisticky zpracována pomocí obecných lineárních modelů a metody analýzy rozptylu. Úkolem analýzy bylo odpovědět na tyto otázky: 1. Liší se od sebe významně použité technologie co do rychlosti (času) vyřízení požadavku? 2. Liší se od sebe významně použité soubory co do rychlosti (času) vyřízení požadavku? 3. Závisí rychlost vyřízení na velikosti souboru lineárně? 4. Existuje mezi technologií a velikostí souboru nějaká interakce, pokud jde o rychlost vyřizování požadavků? 5. Má na vyřizování požadavků vliv počet klientů, a to jak v rychlosti, tak v počtu selhavších požadavků? Je případná závislost lineární? 6. Existuje mezi technologií a počtem klientů nějaká interakce, pokud jde o rychlost vyřizování požadavků?

Vliv technologie Faktor použité technologie je statisticky významný. Nejnižší střední doba byla pozorována u Perlu, nejvyšší u PHP, které se od ostatních technologií v době vyřízení požadavku liší o celý jeden řád. Skupina šesti technologií Static, FastCGI, Java servlet, JSP, ASP a Python nemá mezi sebou statisticky významné rozdíly, jinak se všechny ostatní dvojice technologií mezi sebou významně liší.

56

30 25 20 15 10 5 0

PHP

Cocoon

CGI

ASP.NET

Python

ASP

FastCGI

Static

JSP

-10

Java servlet

-5 Perl

odchylka od společného průměru v ms

Měření AB - vliv technologie na střední čas vyřízení požadavku

Techonologie

Graf 6-1 - Měření AB - vliv technologie na střední čas vyřízení požadavku

Vliv velikosti souboru Velikost souboru má na střední dobu vyřízení požadavku významný vliv. Podle očekávání jsou rychleji vyřizovány požadavky s malými soubory. Vliv velikosti je však poměrně slabý, odpovídá přibližně 1 ms na stovky kB. U každé technologie je navíc tento vliv jiný (mezi velikostí souborů a technologií je tudíž interakce), největší je u Perlu a PHP, kde se pohybuje kolem 1 ms na desítky kB. U měřených souborů odpovídal růst doby vyřízení požadavku velikosti souboru lineárně. Jelikož však byly k dispozici pouze čtyři soubory, nelze jednoznačně říci, zda je doba vyřízení požadavku obecně lineární funkcí velikosti souboru. K tomu by bylo potřeba měřit více souborů různé velikosti za použití menšího počtu technologií.

Vliv počtu klientů Rostoucí počet klientů se z hlediska střední doby vyřízení požadavku projevuje u různých technologií různě. Statisticky významné odchylky od průměru byly pozorovány u technologií CGI, Cocoon, PHP a Java servlet, u prvních tří se však mohl projevit výskyt nevyřízených požadavků (viz níže). U technologií ASP, ASP.NET, Static, Python a Perl střední doba vyřízení požadavku na počtu klientů nezávisí. U FastCGI a JSP se závislost projevuje až u největšího souboru, ovšem pro každou technologii jinak: zatímco u FastCGI začíná u největšího souboru s rostoucím počtem klientů střední doba také růst, u JSP se větší počet klientů u největšího souboru projevuje značným nárůstem rozptylu (rozkolísáním) střední doby vyřízení. Křivka závislosti doby vyřízení na počtu klientů u technologií CGI, Cocoon, PHP a Java servlet není lineární, jak ukazují následující grafy. V grafech jsou pro každý počet klientů uvedena měření na všech souborech, proto může jedné hodnotě na x-ové ose odpovídat víc bodů.

57

Měření AB, Static - závislost střední doby vyřízení požadavku na počtu klientů 0,6

střední doba v ms

0,5 0,4 0,3 0,2 0,1 0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-2 - Měření AB - statické stránky

Měření AB, CGI - závislost střední doby vyřízení požadavku na počtu klientů 5 4,5 střední doba v ms

4 3,5 3 2,5 2 1,5 1 0,5 0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-3 - Měření AB - CGI

58

Měření AB, FastCGI - závislost střední doby vyřízení požadavku na počtu klientů 3

střední doba v ms

2,5 2 1,5 1 0,5 0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-4 - Měření AB – FastCGI

Měření AB, PHP - závislost střední doby vyřízení požadavku na počtu klientů 50 45 střední doba v ms

40 35 30 25 20 15 10 5 0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-5 - Měření AB - PHP

59

Měření AB, Perl - závislost střední doby vyřízení požadavku na počtu klientů 25

střední doba v ms

20

15

10

5

0 0

50

100

150

200

250

300

350

400

350

400

Počet klientů

Graf 6-6 - Měření AB - Perl

Měření AB, Python - závislost střední doby vyřízení požadavku na počtu klientů 6

střední doba v ms

5 4 3 2 1 0 0

50

100

150

200

250

300

Počet klientů

Graf 6-7 - Měření AB - Python

60

Měření AB, JSP - závislost střední doby vyřízení požadavku na počtu klientů 2,5

střední doba v ms

2

1,5

1

0,5

0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-8 - Měření AB - JSP

Měření AB, Java servlet - závislost střední doby vyřízení požadavku na počtu klientů 1 0,9 střední doba v ms

0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-9 - Měření AB - Java servlet

61

Měření AB, ASP - závislost střední doby vyřízení požadavku na počtu klientů 12

střední doba v ms

10 8 6 4 2 0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-10 - Měření AB – ASP

Měření AB, ASP.NET - závislost střední doby vyřízení požadavku na počtu klientů 16

střední doba v ms

14 12 10 8 6 4 2 0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-11 - Měření AB - ASP.NET

62

Měření AB, Cocoon - závislost střední doby vyřízení požadavku na počtu klientů 6

střední doba v ms

5 4 3 2 1 0 0

50

100

150

200

250

300

350

400

Počet klientů

Graf 6-12 - Měření AB - Cocoon

Selhané (nevyřízené) požadavky se objevovaly pouze u technologií CGI, Cocoon a PHP, a to od určitého počtu klientů bez ohledu na velikost souboru: u CGI od 111 klientů, u Cocoonu od 231 a u PHP od 131 klientů.

Tabulky

Celkem – – 1759 171029 – Velikost souboru 1 4934 1758 166094 10241,81 Technologie 10 162051 1748 4044 33635,15 Počet klientů 1 0,3 1747 4044 0,53 Velikost souboru : Technologie (interakce) 10 3161 1737 883 656,12 Počet klientů : Technologie (interakce) 10 51 1727 832 10,49 Tabulka 6-1 - Měření AB - tabulka analýzy rozptylu

Významnost

P-hodnota

F statistika

Residuální součet čtverců

Reziduální počet stupňů volnosti

Součet čtverců

Stupně volnosti

Souhrnné výsledky lineárního modelu popisuje jednak tabulka analýzy rozptylu (ANOVA), jednak tabulka vypočtených koeficientů modelu. V tabulkách dvojtečka označuje interakci mezi různými faktory, tj. vliv společného působení těchto faktorů.

– – <2e-16 ano <2e-16 ano 0,4668 ne <2e-16

ano

<2e-16

ano

Bez uvažování interakce s konkrétní technologií byl vliv počtu klientů nevýznamný, významnost se však objevila v okamžiku, kdy byl počet klientů uvažován ve vztahu ke konkrétní technologii. To znamená, že se vliv klientů projevuje pro každou konkrétní technologii jinak. Tyto různé projevy se při pohledu bez rozlišení technologie vzájemně kompenzují.

63

Střední chyba Koeficient koef. (Střední hodnota) 1,832 0,1269 Velikost souboru 6,98E-10 3,26E-10 Cocoon 2,197 0,1722 FastCGI -1,571 0,1722 Perl -1,977 0,1722 PHP 30,21 0,1724 Python -1,383 0,1721 Static -1,622 0,1722 ASP -1,418 0,1721 ASP.NET -0,9465 0,1721 JSP -1,626 0,1718 Java servlet -1,501 15,6 Počet klientů -0,00251 0,000493 Velikost souboru:Cocoon -5,2E-10 3,85E-10 Velikost souboru:FastCGI 2,65E-09 3,85E-10 Velikost souboru:Perl 1,6E-08 3,85E-10 Velikost souboru:PHP 1,11E-08 3,86E-10 Velikost souboru:Python 2,29E-09 3,85E-10 Velikost souboru:Static -3,1E-10 3,85E-10 Velikost souboru:ASP 7,54E-09 3,85E-10 Velikost souboru:ASP.NET 7,05E-09 3,85E-10 Velikost souboru:JSP 3,91E-10 3,73E-10 Velikost souboru:Java servlet -2,7E-09 1,26E-06 Cocoon:Počet klientů 0,005437 0,000685 FastCGI:Počet klientů 0,002531 0,000685 Perl:Počet klientů 0,001616 0,000685 PHP:Počet klientů 0,004626 0,000685 Python:Počet klientů 0,002065 0,000685 Static:Počet klientů 0,002451 0,000685 ASP:Počet klientů 0,001847 0,000685 ASP.NET:Počet klientů 0,000739 0,000685 JSP:Počet klientů 0,002993 0,000685 Java servlet:Počet klientů 0,002632 0,000685 Tabulka 6-2 - Měření AB - tabulka vypočtených koeficientů modelu

Z povahy lineárního modelu vyplývá, že některé koeficienty jsou nulové a v tabulce proto nejsou uvedeny. Faktor velikosti souboru a počtu klientů má lineární vliv, uvedené koeficienty u nich tedy odpovídají koeficientům u lineárního členu (tj. jde o směrnice přímek proložených pozorováními ve smyslu lineární regrese). Faktor technologie je kategoriální, koeficienty jsou proto uvedené pro každou technologii (s výjimkou CGI, kterou lineární model bere jako referenční). Jednotlivé koeficienty se sčítají.

Měření test-client

Postup Na server byl při každém měření zaslán jeden požadavek z jednoho vzdáleného klienta. K tomu účelu bylo postupně použito 11 různých technologií (Static, CGI, FastCGI, Perl, Python, Cocoon, PHP, Java servlet, JSP, ASP a ASP.NET) a 4 soubory o různé velikosti od desítek bytů (soubor hello) až po desítky kB (soubor big).

64

Výsledkem každého měření byla doba vyřízení požadavku v ms. Data byla následně statisticky zpracována pomocí obecných lineárních modelů a metody analýzy rozptylu. Úkolem analýzy bylo odpovědět na tyto otázky: 1. Liší se od sebe významně použité technologie co do rychlosti (času) vyřízení požadavku? 2. Liší se od sebe významně použité soubory co do rychlosti (času) vyřízení požadavku? 3. Závisí rychlost vyřízení na velikosti souboru lineárně? 4. Existuje mezi technologií a velikostí souboru nějaká interakce, pokud jde o rychlost vyřizování požadavků?

Vliv technologie a velikosti souboru Faktor použité technologie je statisticky významný. Rychlost zpracování požadavku však závisí významně i na velikosti souboru, mezi faktorem technologie a faktorem velikosti souboru existuje interakce. U tří ze čtyř souborů (hello, small, medium) dosáhly největší doby zpracování požadavku technologie CGI a Coccon, rozdíl oproti ostatním činil jednotky ms. Ostatní technologie měly mezi sebou jen minimální rozdíly, díky velkému počtu pozorování však i tyto rozdíly byly statisticky významné. Nejnižší dobu vyřízení požadavku u nejmenších dvou souborů (hello, small) vykázaly techologie ASP, Java servlet a Static, u souboru medium pak ASP a ASP.NET. U souboru big dochází ke značné změně: technologie ASP, PHP, Python a Perl vyřizují požadavky významně pomaleji, než by odpovídalo lineární závislosti na velikosti souboru. Interakce mezi velikostí souboru a technologií je tak nejzřetelnější právě na těchto kombinacích souboru a technologie. U ostatních technologií odpovídá nárůst doby velikosti souboru přibližně lineárně, nicméně podle tvaru křivek lze předpokládat, že přesněji by nárůst doby vystihoval exponenciální či kvadratický trend. Jelikož však měření probíhalo pouze na čtyřech souborech, není možné jednoznačně určit, zda a od jaké velikosti souboru se u uvedených technologií mění lineární závislost doby na velikosti na závislost jiného typu.

65

Průměrnou dobu vyřízení požadavku v závislosti na použité technologii a velikosti souboru uvádí následující grafy. Technologie byly pro přehlednost rozděleny do dvou skupin podle střední doby vyřízení požadavku pro soubor big.

doba v ms

Měření TC - průměrná doba vyřízení požadavku podle souboru pro vybrané technologie 25

ASP.NET

20

Static

15

FastCGI

10

JSP

5

Java servlet

0 hello

small

medium

big

Soubor Graf 6-13 - Měření test-client - srovnání technologií část 1.

Měření TC - průměrná doba vyřízení požadavku podle souboru pro vybrané technologie 25

ASP CGI Cocoon Python PHP Perl

doba v ms

20 15 10 5 0 hello

small

medium

big

Soubor Graf 6-14 - Měření test-client - srovnání technologií část 2.

Tabulky Souhrnné výsledky lineárního modelu popisuje tabulka analýzy rozptylu (ANOVA). Vzhledem k tomu, že v modelu byly přítomny pouze dva faktory a třídění bylo tzv. vyvážené (pro každou kombinaci faktorů byl k dispozici stejný počet pozorování), je vhodnější místo tabulky koeficientů modelu použít tabulku průměrných hodnot.

66

Technologie hello small medium ASP 1,24 2,13 3,40 ASP.NET 2,38 2,82 3,82 CGI 3,34 4,12 6,26 Cocoon 4,17 4,74 6,77 FastCGI 1,64 2,21 4,40 Java servlet 1,29 2,07 4,79 JSP 1,61 2,76 4,58 Perl 1,91 2,56 4,48 PHP 1,71 2,52 4,75 Python 2,02 2,18 4,88 Static 1,39 1,92 4,01 Tabulka 6-4 - Měření test-client - tabulka průměrných hodnot

Významnost

P-hodnota

F statistika

Residuální součet čtverců

Reziduální počet stupňů volnosti

Součet čtverců

Stupně volnosti

Celkem – – 8799 201787 – – Soubor 3 133388 8796 68399 17758,47 <2e-16 Technologie 10 13959 8786 54441 557,51 <2e-16 Soubor : Technologie (interakce) 30 32518 8756 21923 432,92 <2e-16 Tabulka 6-3 - Měření test-client - tabulka analýzy rozptylu

– ano ano ano

big 10,47 6,90 10,58 11,00 9,07 10,37 9,90 21,15 19,73 13,25 8,23

Měření httperf

Postup Na server bylo při každém měření opakovaně zasláno 100 požadavků ze 100 různých vzdálených klientů, a to vždy ve stejný okamžik. Měření se opakovalo desetkrát. K tomu účelu bylo postupně použito 11 různých technologií (Static, CGI, FastCGI, Perl, Python, Cocoon, PHP, Java servlet, JSP, ASP a ASP.NET) a 4 soubory o různé velikosti od desítek bytů (soubor hello) až po desítky kB (soubor big). Výsledkem každého měření byly dva údaje – celková doba trvání spojení a doba čekání na odezvu serveru v ms. Data byla následně statisticky zpracována pomocí obecných lineárních modelů a metody analýzy rozptylu. Úkolem analýzy bylo odpovědět na tyto otázky: 1. Liší se od sebe významně použité technologie co do doby trvání spojení, resp. co do doby odezvy serveru? 2. Liší se od sebe významně použité soubory co do doby trvání spojení, resp. co do doby odezvy serveru? 3. Závisí rychlost vyřízení na velikosti souboru lineárně? 4. Existuje mezi technologií a velikostí souboru nějaká interakce, pokud jde o dobu trvání spojení, resp. dobu odezvy serveru?

Doba trvání spojení – vliv technologie a velikosti souboru Výsledky jsou prakticky totožné s měřením test-client. Faktor použité technologie je statisticky významný. Rychlost zpracování požadavku však závisí významně i na velikosti souboru, mezi faktorem technologie a faktorem velikosti souboru existuje interakce. U tří ze čtyř souborů (hello, small, medium) dosáhly největší doby zpracování požadavku technologie CGI a Coccon, rozdíl oproti ostatním činil jednotky ms. Ostatní technologie měly mezi sebou jen minimální rozdíly, díky velkému počtu pozorování však i tyto rozdíly byly statisticky 67

významné. Nejnižší dobu vyřízení požadavku tak vykázaly techologie ASP, ASP.NET a Static. U souboru big dochází ke značné změně: technologie JSP, PHP, Python a Perl vyřizují požadavky významně pomaleji, než by odpovídalo lineární závislosti na velikosti souboru. Perl dokonce u souboru big o několik řádů prodloužil celkovou dobu trvání spojení. Interakce mezi velikostí souboru a technologií je tak nejzřetelnější právě na těchto kombinacích souboru a technologie. U ostatních technologií odpovídá nárůst doby velikosti souboru přibližně lineárně, nicméně podle tvaru křivek lze předpokládat, že přesněji by nárůst doby vystihoval exponenciální či kvadratický trend. Jelikož však měření probíhalo pouze na čtyřech souborech, není možné jednoznačně určit, zda a od jaké velikosti souboru se u uvedených technologií mění lineární závislost doby na velikosti na závislost jiného typu. Průměrnou dobu vyřízení požadavku v závislosti na použité technologii a velikosti souboru uvádí následující grafy. Technologie byly pro přehlednost opět rozděleny do dvou skupin. M ěření HT - průměrná doba trvání spojení podle souboru, vybrané technologie

doba v ms

30 25

ASP

20

Static

15 10

ASP.NET FastCGI

5

Java servlet

0 hello

small

medium

big

Soubor Graf 6-15 - Měření httperf - doba trvání spojení část 1.

Měření HT - průměrná doba trvání spojení podle souboru, vybrané technologie

doba v ms

30 25

Cocoon

20

Python CGI

15

JSP

10

PHP

5

Perl

0 hello

small

medium

big

Soubor Graf 6-16 - Měření httperf - doba trvání spojení část 2.

68

Doba čekání na odpověď – vliv technologie a velikosti souboru Výsledky analýzy doby čekání na odpověď jsou u tří menších souborů (hello, small, medium) zcela totožné s výsledky analýzy doby trvání spojení. U souboru big se objevují tyto odlišnosti: 1. Lineární trend, a to dokonce s malým koeficientem růstu (tj. s malým sklonem křivky) zachovává podstatně více technologií než u doby spojení – FastCGI, Static, Java servlet, CGI a Cocoon. Naopak technologie ASP a ASP.NET, na rozdíl od celkové doby spojení, u souboru big výrazně prodloužily dobu čekání na odpověď. 2. Pro soubor big je nárůst doby čekání na odpověď u technologie PHP relativně mnohem menší než nárůst celkové doby trvání spojení. To tedy znamená, že hlavním důvodem, proč se u PHP prodlužuje u velkých souborů doba trvání spojení, není čekání na odezvu serveru. Měření HT - průměrná doba čekání na odpověď podle souboru, vybrané technologie

doba v ms

10 8

ASP

6

Static ASP.NET

4

FastCGI

2

Java servlet

0 hello

small

medium

big

Soubor

Graf 6-17 - Měření httperf - srovnání technologií část 1.

Měření HT - průměrná doba čekání na odpověď podle souboru, vybrané technologie 10 Cocoon

doba v ms

8

Python

6

CGI JSP

4

PHP Perl

2 0 hello

small

medium Soubor

big

Graf 6-18 - Měření httperf - srovnání technologií část 2.

69

Tabulky Souhrnné výsledky lineárního modelu popisuje tabulka analýzy rozptylu (ANOVA). Vzhledem k tomu, že v každém ze dvou modelů (pro dobu spojení i dobu odezvy) byly přítomny pouze dva faktory a třídění bylo tzv. vyvážené (pro každou kombinaci faktorů byl k dispozici stejný počet pozorování), je vhodnější místo tabulky koeficientů modelu použít tabulku průměrných hodnot.

Celkem – – 431 444675896 – Soubor 3 32496421 428 412179476 106671 Technologie 10 103029636 418 309149840 101459 Soubor : Technologie (interakce) 30 309110439 388 39400 101466 Tabulka 6-5 - Měření httperf - tabulka analýzy rozptylu - doba trvání spojení

Významnost

P-hodnota

F statistika

Residuální součet čtverců

Reziduální počet stupňů volnosti

Součet čtverců

Stupně volnosti

Doba trvání spojení

– <2e-16 <2e-16 <2e-16

– ano ano ano

Spojení hello small medium big ASP 0,7 0,9 2,3 9,4 Static 1,2 1,5 3,5 7,7 ASP.NET 1,6 1,3 2,6 9,2 FastCGI 1,5 1,9 4,0 8,6 Java servlet 1,0 1,6 4,0 9,8 Cocoon 3,1 3,3 5,4 10,0 Python 1,5 1,8 4,4 14,2 CGI 3,4 3,7 5,7 10,1 JSP 1,9 1,9 4,6 15,8 PHP 1,6 2,1 4,2 25,1 Perl 1,6 2,1 3,9 6751,4 Tabulka 6-6 - Měření httperf - tabulka průměrných hodnot - doba trvání spojení

Významnost

P-hodnota

F statistika

Residuální součet čtverců

Reziduální počet stupňů volnosti

Součet čtverců

Stupně volnosti

Doba čekání na odpověď

Celkem – – 431 444675896 – – Soubor 3 1588661 428 20302652 37363 <2e-16 Technologie 10 5070720 418 15231932 35777 <2e-16 Soubor : Technologie (interakce) 30 15226433 388 5499 35810 <2e-16 Tabulka 6-7 - Měření httperf - tabulka analýzy rozptylu - doba čekání na odpověď

– ano ano ano

70

Odezva hello small medium big ASP 0,6 0,8 0,8 3,7 Static 0,8 1,2 1,2 1,2 ASP.NET 1,5 1,2 1,0 3,4 FastCGI 1,1 1,6 1,6 2,1 Java servlet 0,6 1,3 1,4 1,5 Cocoon 2,7 3,0 3,0 3,1 Python 1,1 1,5 2,0 6,1 CGI 3,0 3,4 3,4 3,4 JSP 1,5 1,6 1,8 4,0 PHP 1,2 1,8 1,9 3,6 Perl 1,1 1,8 1,5 1498,8 Tabulka 6-8 - Měření httperf - tabulka průměrných hodnot - doba čekání na odpověď

Měření MySQL

Postup Na databázový server MySQL byly při každém měření opakovaně zaslány požadavky, a to různým počtem klientů (1 až 16). Měření se opakovalo stokrát. K tomu účelu byly postupně použity 4 různé technologie (CGI, FastCGI, Perl, PHP). Pro technologii Python měření nebylo možno provést, kvůli nemožnosti instalace. Výsledkem každého měření byla doba zpracování požadavku. Data byla následně statisticky zpracována pomocí obecných lineárních modelů a metody analýzy rozptylu. Úkolem analýzy bylo odpovědět na tyto otázky: 1. Liší se od sebe významně použité technologie co do rychlosti (času) vyřízení požadavku? 2. Závisí rychlost vyřízení na počtu klientů lineárně? 3. Existuje mezi technologií a počtem klientů nějaká interakce, pokud jde o rychlost vyřizování požadavků?

Doba trvání spojení – vliv technologie a počtu klientů Analýza prokázala statisticky významné rozdíly mezi všemi čtyřmi použitými technologiemi. Nejdelší doba byla zaznamenána u technologie CGI, nejkratší pak u FastCGI a PHP. Doba vyřízení požadavku významně též závisí na počtu klientů. U technologie FastCGI byla většina měření s 11 klienty a všechna měření s 16 klienty poznamenána nevyřízením žádného z požadavků, proto tato měření nebyla vzata v úvahu. Jak je vidět z následujícího grafu, nejvyšší průměrná doba vyřízení požadavku nastává při měření s jediným klientem. Vyšší počet klientů vede k poklesu průměrné doby vyřízení požadavku, tento pokles je však lineární jen od 6 do 16 klientů. Jelikož měření neprobíhalo pro všechny možné počty klientů od 1 do 16, nelze jednoznačně určit, ve kterém bodě se trend poklesu mění na lineární.

71

Měření MySQL - vliv technologie a počtu klientů 14 12

doba v ms

10 cgi

8

fastcgi perl

6

php 4 2 0 1

6

11

16

Počet klientů

Graf 6-19 - Měření mysl - srovnání jednotlivých technologií

Měření MySQL-rand

Postup Na databázový server byly při každém měření opakovaně zaslány požadavky testovacím nástrojem httperf, a to v různém počtu současně. V jednom měření bylo odesláno 1000 požadavků. Požadavky byly odesílány současně 100 až 700 připojeními (navyšováno po 10 současných připojeních). Každé měření bylo zopakováno desetkrát. K tomu účelu bylo postupně použito 6 různých technologií (CGI, FastCGI, Perl, PHP, ASP.NET a Java servlet). Pro technologii Python měření nebylo možno provést, kvůli nemožnosti instalace. Výsledkem každého měření byla průměrná doba zpracování požadavku. Data byla nejprve statisticky zpracována pomocí obecných lineárních modelů a metody analýzy rozptylu. Úkolem analýzy bylo odpovědět na tyto otázky: 1. Liší se od sebe významně použité technologie co do doby zpracování požadavku? 2. Závisí doba zpracování na počtu současných požadavků lineárně? Vzhledem k tomu, že pro žádnou technologii není průběh doby zpracování v závislosti na počtu současných požadavků lineární pro všechny sledované počty, ale jen v určitých rozmezích, posloužil lineární model pouze jako pomocný nástroj ke zjištění, že všechny použité technologie se mezi sebou liší. Z těchto důvodů není uvedena tabulka analýzy rozptylu. Další analýza byla založena na zkoumání křivek pro jednotlivé technologie.

Vliv technologie a počtu současných požadavků Analýza prokázala statisticky významné rozdíly mezi všemi šesti použitými technologiemi. Obecně nejdelší doba byla zaznamenána u technologie CGI, nejkratší pak u Java servletu. Technologie FastCGI a Perl vykazovaly obdobné chování, přičemž o něco nižší časy vykazovalo FastCGI. Uvedené závěry platí ovšem pouze pro počty současných požadavků pohybující se ve zkoumaném rozmezí (100 až 700). Při dalším růstu počtu současných požadavků se mohou trendy doby zpracování změnit – takové změny byly zaznamenány u všech technologií již nyní v uvedeném rozmezí. 72

U každého z počtů současně zaslaných požadavků byl spočten medián doby zpracování za všech 10 měření (medián je robustnější, tj. statisticky odolnější charakteristika v případě odlehlých pozorování a značných náhodných výkyvů). Z grafu je patrné, že u čtyř technologií (CGI, FastCGI, Perl a PHP) se křivka zjištěné střední doby zpracování (mediánu) skládá z několika částí: 1. Do určitého počtu požadavků je křivka lineární s malým koeficientem sklonu, případně s nulovým růstem (rovnoběžná s osou x). 2. Po překročení určitého počtu současných požadavků doba vyřízení začne růst rychleji a s dalším nárůstem počtu požadavků se postupně stabilizuje kolem nové trendové křivky. Ta je opět lineární, avšak již s daleko větším koeficientem sklonu. To neplatí pro PHP, kde se skokově změní úroveň, nicméně sklon je opět velmi malý. Měření MySQL-rand - vliv technologie a počtu současných požadavků 4000 3500 3000 ASP.NET čas (ms)

2500

CGI FastCGI

2000

Java servlet Perl

1500

PHP 1000 500 0 100 140 180 220 260 300 340 380 420 460 500 540 580 620 660 700 Počet současných požadavků

Graf 6-20 - Měření MySQL-rand - srovnání jednotlivých technologií

Z analýzy vyplývají tři závěry: 1. Hlavní rozdíl mezi technologiemi spočívá v různých polohách bodu, v němž se změní trend doby zpracování. Nejdříve nastává tento okamžik u CGI, nejpozději u PHP a FastCGI. Je-li počet současných požadavků menší než 400, jsou rozdíly mezi technologiemi Perl, FastCGI a PHP zanedbatelné. 2. U technologií ASP.NET a Java servlet byl maximální počet 700 současných požadavků příliš malý na to, aby bylo možné jednoznačně zjistit a popsat změnu chování po dosažení kritického bodu – pro ASP.NET by bylo potřeba zvyšovat počet nejméně na 800–900 současných požadavků, u Java servletu není možné odhadnout ani polohu kritického bodu.

73

3. Po překročení bodu změny trendu nejrychleji narůstá doba u CGI. Sklon křivek u FastCGI a Perl je přibližně stejný, obě technologie se tedy liší jen úrovní. Je však možné, že pro větší počty současných požadavků než 700 může začít křivka FastCGI růst rychleji, jak to naznačují měření na 690 a 700 požadavcích. Nejpomalejší, prakticky nulový růst vykazuje PHP. O povaze růstu po překročení kritického bodu pro ASP.NET a Java servlet není dostatek informací.

6.4 Závěr a vyhodnocení Testování odhalilo několik nejrychlejších kandidátů. Kromě statických stránek, jejichž prvenství bylo logické předpokládat, najdeme na nejrychlejších místech technologie Perl, FastCGI, JSP, Java servlet, ASP a Python. V případě lokálního testování dokonce Perl a JSP předstihli statické stránky. Příčina bude pravděpodobně v absenci rychlostní optimalizace statických stránek. V případě použití modulu mod_mmap_static mohlo dojít k očekávanému prvenství statických stránek. Při vzdáleném testování (bližším normálnímu provozu) se na přední místa dostává technologie ASP a Java servlet pro objemově menší soubory. V případě většího souboru medium se do popředí dostaly technologie ASP a ASP.NET. Při větším nárůstu velikosti zpracovávaného souboru vyřizují technologie ASP, PHP, Python a Perl požadavky výrazně pomaleji. Databázové měření odhalilo vítěze při práci s databází. Na prvním místě stojí technologie PHP, která jako jediná vykazuje při rostoucím počtu požadavků téměř nulový růst doby odezvy. Ke zlomu dochází, ale až jako u poslední testované technologie a ani potom není růst příliš strmý. Pro ASP.NET a Java servlet nebylo dosaženo kritického bodu, proto nebylo možné odhadnout chování po jeho překročení. Mezi vítěze, z pohledu výkonu, je možné zařadit technologie ASP.NET, Java servlet a přihlédnutím na zpracovávání databázových požadavků ještě i PHP. Pokračováním výkonnostních testů by mohlo být měření většího množství vzorků s různými velikostmi výstupních stránek. Prokázala by se tak případná závislost velikosti výstupu na rychlosti odezvy serveru. Další možností by bylo i vytvoření jednoho většího projektu ve všech testovaných technologiích a proměření jeho výkonnosti pro různé počty klientů. Dále by bylo vhodné opakovat instalaci databázového spojení pro technologii Python a zjistit její možnosti při práci s databází.

7 Zvyšování výkonu Při úspěšném provozu webových aplikací se zvyšuje počet uživatelů, a tím roste i hardwarová náročnost. Postupně je možné zvyšovat výkon počítače, kde celá aplikace běží. Vyladěním konfigurace souborového systému, operačního systému, serveru a sítě pro nejvyšší možný výkon. Výměna procesoru za rychlejší, přidání dalšího procesoru, rozšíření operační paměti a výměna disků za vysokootáčkové nebo dokonce za diskové pole. Nakonec se dosáhne maxima, které je nám jeden počítač schopen poskytnout a musíme zvolit jiné řešení než byla softwarová nebo hardwarová optimalizace. Důvodem pro nasazení několika serverů místo jednoho může mít i další hodnotu než jen vyšší zvládaný výkon celé aplikace. Celé řešení se stane také více odolné proti selhání některé z komponent. Pokud se vyskytne hardwarová chyba (například porucha disku nebo vyhoření

74

síťového zdroje), tak uživatel nic nepozná. Tato řešení nazývána jako systémy s vysokou dostupností (High-Availability Clusters).

7.1 Rysy systému s vysokou dostupností Systém poskytuje během jednoho dne tisíce až milióny stránek každý den. Pro obsloužení takového množství internetových požadavků musí mít následující vlastnosti: Spolehlivé DNS servery - V případě pádu všech DNS serverů se na stránky nikdo nedostane. Proto jsou DNS záznamy velice důležité při návrhu celého systému. Přístup s rozložením zátěže - Uživatelé se mohou připojit na jeden nebo více serverů, které jsou vybírány automaticky, na základě jejich momentální zátěže a dostupnosti. Zvládnutelná architektura pro úložiště - Většina systémů také obsahuje velké množství údajů, které musí být dostupné na všech serverech systému. Uložení dat musí být spolehlivé a také jednoduše zvládnutelné. Bez náležitého plánování a solidní architektury celého úložiště se může vlastnictví mnoha serverů a starosti se všemi jejich disky stát noční můrou. Inspiraci můžeme hledat u systému souborů firmy Google. Jejich Google file system (GFS) je vytvořen s důrazem na bezpečnost dat provozovaných na potencionálně chybujícím levném hardware [8]. Efektivní back-end - Velké internetové servery obsahují mnoho aplikací. Provádí se milióny databázových dotazů, stejně tak jako mnoho dalších úkolů pro zajištění vysoké dostupnosti nebo personalizace jednotlivým uživatelům. Proto je třeba kvalitního back-endu. Není to část přístupná přes internet, ale slouží k synchronizaci a aktualizaci každého serveru v systému. Také administrátorům umožňuje spravovat různé části systému, provádět zálohování, aktualizace nainstalovaného software a podobně. Vysoký stupeň zabezpečení - Designéři systému musí dávat velký důraz na bezpečnost celé architektury. Sítě mnoha počítačů jsou totiž častým cílem hackerů, kteří je používají pro útoky na další servery. Větší počet počítačů znamená také větší počet potencionálních problémů.

7.2 Zvyšování spolehlivosti DNS Když je DNS server nedostupný, tak je nedostupný celý systém. Uživatel sice může znát IP adresu a potom se pravděpodobně k systému dostanete, ale většina uživatel ani netuší, kde lze IP adresu zjistit. Očekávat proto nějaké uživatele, zatímco nefunguje DNS, je nereálné. Proto jsou pro registraci nové domény potřeba dva DNS servery. Nicméně pro cluster by měly být dva jako absolutní minimum a raději použít více než dva DNS servery. Zvýší se tím spolehlivost celého DNS systému. Inspiraci může přinést následující strategie [9,15]: •

Rozestavit nejméně dva DNS servery, jak požadují registrátoři doménových jmen, lépe však více než dva.

•

Zařídit jeden DNS server zcela mimo systém. Pokud nastane výpadek obou lokálních DNS serverů, tak celá síť bude stále dostupná díky vnějšímu DNS serveru.

•

Použít nejméně jeden vyhrazený DNS server, pokud je to možné. Systém s několika nainstalovanými aplikacemi je méně spolehlivý, než systém, který má nainstalovanou pouze jedinou aplikaci (DNS). 75

•

Používat lokální vyrovnávací paměť pro DNS, pokud některá z aplikací požaduje možnost převodu IP adresy na jmenný tvar. Například systém, který sleduje demografické údaje (odkud lidé na server přistupují) může velmi dobře těžit z prohledávání dočasně uložených DNS záznamů.

•

Běžně používat monitorovací systémy pro kontrolu, že jsou data DNS správná a dostupná.

7.3 Rozkládání zátěže Hlavním důvodem instalace několika uzlů do serverového systému je rozkládání zátěže, jistota vyššího stupně výkonnosti a stability. Při nasazování je možno vybírat ze dvou základních možností: DNS round-robin a hardwarové rozkládání zátěže. Obě metody jsou probrány v následujícím textu:

Distribuce požadavků za pomoci DNS round-robin DNS round-robin je doporučováno pouze v případě, když není dostupné hardwarové řešení. Round-robin DNS je mechanismus rotování jednoho doménového jména přes seznam IP adres jednotlivých webových serverů [7]. Předpokládejme vlastnictví dvou serverů img1.centrum.cz (213.29.7.237) a img2.centrum.cz (213.29.7.238) přes které chceme rozkládat zátěž domény img.centrum.cz. Využijeme DNS round-robin a uděláme následující: Pro jednu doménu přiřadíme více než 1 IP adresu. Do zóny pro doménu centrum.cz přidáme následující řádky: img1 IN A 213.29.7.237 img2 IN A 213.29.7.238 img img

IN CNAME img1 IN CNAME img2

Restartujeme DNS server. Pokud na adresu img.centrum.cz zavoláme příkaz ping, při prvním spuštění je vidět IP adresu prvního obrázkového serveru 213.29.7.237 a zatímco při druhém příkazu ping se bude objevovat druhá IP adresa 213.29.7.238. Doménové záznamy lze kontrolovat příkazem host: [local]# host img.centrum.cz img.centrum.cz. has address 213.29.7.238 img.centrum.cz. has address 213.29.7.237

Při požadavku na doménové jméno img.centrum.cz je vrácena nejdříve první IP adresa. Podruhé je vrácena další IP adresa v pořadí. A další požadavky jsou postupně rozdělovány na obě připojené adresy.

76

U novějších DNS serverů je možné definovat pořadí položek, jakým způsobem budou při dotazování rotovány. • fixed – vrací záznamy vždy ve stejném pořadí, jaké je dáno v zónovém souboru • random – je použito náhodné pořadí • cyclic – vrací záznamy cyklicky (round-robin) Tento mechanismus rozkládání zátěže má bohužel velkou nevýhodu. DNS server neví nic o aktuální zátěži jednotlivých serverů. Pokud je některý z nich vysoce zatížen, tak jej slepě opět cyklicky vybírá a posílá na něj požadavky. Pokud bude mít některý ze serverů výpadek nebo se stane z nějakého důvodu nedostupný, DNS server bude požadavky dál směřovat i na nedostupný server. Některé požadavky se k serveru dostanou a některé ne. Server se bude občas jevit jako nedostupný.

Distribuce požadavků pomocí hardwarového rozkládání zátěže Hardwarové rozkládání zátěže se v dnešní době používá velmi často. Toto řešení je typicky mnohem inteligentnější než DNS round-robin zmiňované v předchozí části. Hardwarové řešení může implementovat rozmanité monitorování každého serveru. Sledovat lze aktuální zátěž, výkon, dostupnost podle doby odezvy, podle počtu zaslaných požadavků a nebo generováním vlastních testovacích požadavků. Díky tomu tato zařízení nabízí velké možnosti kontroly celého rozkládacího mechanismu. Některá zařízení nabízí vytvoření prioritní fronty požadavků, kde některé servery mají větší prioritu než ostatní. Například, když budete mít Pentium 4 3,8 GHz se 2GB paměti a druhý počítač Pentium III 1GHz s 512MB paměti, můžete zvýšit prioritu systému s procesorem Pentium 4, protože díky lepšímu hardware zvládne víc požadavků než druhý stroj.

Obrázek 7-1 - Schéma jednoduchého rozkládání zátěže

Systém rozložení zátěže se rozhodne na který uzel má požadavek směřovat, vybere vhodný server a požadavek na něj přesměruje. Vybraný server požadavek zpracuje a odpoví klientovi. Výběrová kritéria pro server záleží na prioritě, dostupnosti a spolehlivosti.

77

Toto řešení má ale pouze jeden vstupní bod do celého systému. Požadavky na doménu img.centrum.cz musí jít všechny přes systém rozkládání, který požadavky na službu překládá na požadavky pro konkrétní servery v systému. Požadavek na doménu je zaslán počítači rozkládajícímu zátěž, protože DNS server zjistí jeho IP adresu. Ten se potom rozhodne, který ze serverů img[1-N].centrum.cz požadavek zodpoví.

Obrázek 7-2 - Schéma redundantního rozkládání zátěže

Na druhém obrázku si můžete všimnout druhého počítače, rozkládajícího zátěž. Ten je spojen jak s prvním počítačem, tak i do systému webových serverů přes přepínač (switch). Přímé spojení obou počítačů je realizováno buď síťovým kabelem a nebo sériovým rozhraním RS232. Toto spojení slouží ke vzájemnému sledování stavu. Druhý počítač sleduje všechny operace prováděné prvním počítačem. Pokud přestane být první počítač dostupný díky hardwarovému selhání, druhý systém rozkládání zátěže převezme jeho IP adresu a převezme jeho funkci. Křížové připojení přes přepínač umožňuje druhému počítači přístup do celého systému a je schopen obnovit během několika okamžiků funkčnost celé webové služby. Navíc pokud systémy rozkládání zátěže umožňuje použít NAT (Network Address Translation), není třeba mít jednotlivé servery přístupné z internetu a snížit případné riziko narušení bezpečnosti.

Clustering Snaží se řešit stejný problém jako rozkládání zátěže, pouze rozdílným způsobem. Celé řešení totiž není na sobě nezávislé. Jedná se o komplikovaný protokol, kterým spolu všechny servery v clusteru komunikují. Starají se o rozložení zátěže mezi sebe. To vyžaduje kromě hardwarové integrace i úzkou spolupráci s programovým řešením. Jako ilustrace poslouží již výše zmiňovaný GoogleFS [8].

78

Rozložení zátěže webové aplikace mezi několik počítačů nemusí být vždy triviální jako v případě statického obsahu. Každý klient může mít unikátní session s vlastními daty, kterou je třeba udržovat. Buď je třeba každého klienta směřovat stále na stejný server, a nebo údaje o session mezi servery sdílet. Při směrování na stejný server je třeba vyřešit i jeho případný výpadek. Když jde o sdílení dat mezi servery, je třeba počítat se zpomalením provozované aplikace.

Rozkládání zátěže firewallů Při provozu nejsou zatěžovány pouze servery s běžící internetovou aplikací. Vyšším provozem jsou ovlivňovány i další síťové prvky routery, switche nebo firewally [16]. Většina firewallů v sobě obsahuje nějaký procesor až už je na architektuře SPARC a nebo x86. Díky tomu je jeho průchodnost limitována. Pro zvýšení propustnosti se implementuje rozložení zátěže stejným způsobem i na firewally. Jeden prvek se stará o rovnoměrné rozložení procházejícího síťového provozu mezi několik firewallů. Díky tomu není propustnost limitována konfigurací jednoho firewallu, ale v případě potřeby se jen zakoupí další.

Globální rozkládání zátěže Stejně jako distribuce zátěže na firewally, vychází i globální rozkládání zátěže ze stejného principu. Pouze se zátěž distribuuje ne mezi jednotlivé počítače, ale mezi jednotlivá umístění po státu nebo kontinentu. Zatímco rozkládání zátěže pracuje na lokálních sítích (LAN), globální rozkládání pracuje se sítí WAN. Existuje několik možností jak celý systém implementovat. Buď je založen na DNS a nebo na protokolu BGP (Border Gateway Protokol). K implementaci jsou hlavně následující dva důvody: 1. Globální rozkládání zátěže umožní bližší přístup k datům nebo službě. Namísto přístupu přes webový server v Americe se při přihlášení z České republiky nasměruje provoz na server do Německa. 2. V případě nefunkčnosti německého serveru je tu ale vždy záložní možnost a přesměrování na americký server. Uživatel získá sice pomalejší přístup k datům, ale data budou stále dostupná. Celá technologie je stále ve vývoji a obě z variant (DNS i BGP) mají své nedostatky, které je třeba brát v úvahu při jejich implementaci.

8 Závěr Celá práce se zaměřovala hlavně na výkonnostní testování jednotlivých technologií. V úvahu byly brány i bezpečnostní rizika, která jsou podstupována při nasazení technologie na server a následném vývoji aplikací. Přiblíženo bylo také fungování jednotlivých technologií a možnosti dalšího rozšiřování, v případě zvýšení nároků na server díky rostoucímu počtu uživatelů. Velmi zajímavým projektem je framework Apache Cocoon. Velmi efektivním způsobem umožňuje rozdělení práce několika členům týmu. Pro vývoj aplikace používá moderních technologií XML a XSL, případně vlastního programování v jazyce Java. Při použití výchozího provozního prostředí bohužel nedosahuje velmi výrazných rychlostí a řadí se spíše k těm pomalejším technologiím. V případě požadavku na XML zpracování je třeba zvážit použití komerčního systému Caché. To nabízí kromě XML databáze také klasické SQL rozhraní a napojení na mnoho dalších zajímavých datových zdrojů.

79

Svým výkonem zaujaly technologie výkonostně náročné aplikace včetně bezpečnostních incidentů, které byly objeveny. V případě ASP.NET může překážkou pro jejich objevování.

ASP.NET a Java servlet, které jsou vhodné pro připojení k databázi. Výhodou je také nižší počet u obou technologií za celou dobu jejich existence být důvodem uzavřenost technologie, což může být

PHP je, i přes velkou oblíbenost, na posledních místech, pokud se porovnává doba odezvy. V případě práce s databází se dostává do popředí a nezanedbatelná je i jednoduchost vytváření aplikací díky existenci rozmanitých funkcí ve výchozí instalaci. Nevýhodou naopak velké množství zveřejňovaných bezpečnostních incidentů a to včetně roku 2004. Python byl výkonově o něco málo pomalejší než FastCGI pro generování stránek. Pro databázové srovnání jej bohužel nebylo možné nainstalovat. Vzhledem na počet zveřejněných zranitelností je na tom velmi dobře vzhledem k ostatním technologiím. Pro případ náročných datových operací je vhodné zvážit a otestovat komerční řešení firem Oracle nebo InterSystems. Tato řešení počítají s rozšiřováním systému přidáváním dalších počítačů. Pro budoucí zkoumání by bylo vhodné se zaměřit na testování nějaké konkrétní aplikace vytvořené ve všech testovaných technologiích. Zaměřit se na generování požadavků co nejbližším klasickému provozu. Simulací rozmanitého nastavení klientských počítačů a generováním reálné zátěže [44]. Dále by bylo vhodné přidat do otestování i novější verze webserveru Apache 2 a jednotlivých technologií [42, 43]. Další možností je porovnání výkonnosti internetových technologií s databázovými systémy, které umožňují výstup dat na internet [45-48].

80

9 Seznam literatury [1] Security Space: Internet Research Reports. http://www.securityspace.com/s_survey/data/index.html [2] Security Space: Web Server Survey. http://www.securityspace.com/s_survey/data/200502/index.html http://www.securityspace.com/s_survey/data/200502/servers.html [3] Lane D., Williams H. E. (2004): Web Database Application with PHP and MySQL, 2nd Edition. O'Reilly [4] King A. B. (2004): Zrychlete své WWW stránky!, Zoner Press, Brno [5] RFC 2616 Hypertext Transfer Protocol - HTTP/1.1 http://www.w3.org/Protocols/rfc2616/rfc2616.txt [6] Shiflett C. (2003): HTTP Developer's Handbook. Sams Publishing [7] Dostálek L., Kabelová A. (2000): Velký průvodce protokoly TCP/IP a systémem DNS. Computer Press, Praha [8] Ghemawat S., Gobioff H., Shun-Tak Leung (2003): The Google File System. 19th ACM Symposium on Operating Systems Principles, http://labs.google.com/papers/gfs.html [9] Kabir M. J. (2002): Apache Server 2 Bible, Hungry Minds. 637-673. [10] Tracy M., Jansen W., McLarnon M.(2002): Guidelines on Securing Public Web Servers, National Institute of Standards and Technology, http://csrc.nist.gov/publications/nistpubs/800-44/sp800-44.pdf [11] Dialo M. (2004): Web assessment methodology and Secure PHP applications, Eindhoven University of Technology, http://www.win.tue.nl/~ecss/stageverslagen/MDiallo2004.pdf [12] Cross D. (2001): Data Munging with Perl. Manning Publications Co, Greenwich [13] Cook S. (2003): A Web Developer’s Guide to Cross-Site Scripting, http://www.giac.org/practical/GSEC/Steve_Cook_GSEC.pdf [14] CERT (2001): Securing Public Web Servers, http://www.cert.org/securityimprovement/modules/m11.html [15] Bourke T. (2001): Server Load Balancing. O’Reilly & Associates, Inc. [16] Kopparapu Ch. (2002): Load Balancing Servers, Firewalls, and Caches. Wiley Computer Publishing, John Wiley & Sons, Inc. [17] Domácí stránka CGI http://www.w3.org/CGI/ [18] Rozcestník FastCGI http://www.fastcgi.com/ 81

[19] PHP http://www.php.net/ [20] PHP history http://www.php.net/history [21] Perl http://www.perl.com/ [22] Python http://www.python.org/ [23] mod_python http://www.onlamp.com/pub/a/python/2003/10/02/mod_python.html [24] flex http://www.gnu.org/software/flex/ [25] Cocoon http://cocoon.apache.org/ [26] Caché http://www.intersystems.com/cache/ [27] Oracle WEBDB http://www.oracle.com/technology/products/webdb/ [28] Oracle Portal http://www.oracle.com/technology/products/ias/portal/ [29] Bugtraq, SecurityFocus - http://www.securityfocus.com [30] OWASP Top Ten - http://www.owasp.org/documentation/topten.html [31] Raina K. (2004): Trends in Web Application Security, SecurityFocus, http://www.securityfocus.com/infocus/1809 [32] Cross Site Scripting Info - http://httpd.apache.org/info/css-security/ [33] CGI security http://www.w3.org/Security/Faq/wwwsf4.html [34] Kamthan P. (1999): CGI Security: Better Save Than Sorry. http://tech.irt.org/articles/js184/ [35] Simons P., Babel R. (2002): FastCGI - The Forgotten Treasure http://cryp.to/publications/fastcgi/ [36] cgiwrap - http://cgiwrap.unixtools.org/ [37] sbox - http://stein.cshl.org/software/sbox/ [38] suEXEC - http://httpd.apache.org/docs-2.0/suexec.html [39] Crow O. (2004): Efficient String Concatenation in Python. http://www.skymind.com/~ocrow/python_string/ [40] XSLT tutorial. http://www.w3schools.com/xsl/ [41] CERT Software Engineering Institute. http://www.cert.org/

82

[42] Banga G., Druschel P. (1997): Measuring the Capacity of a Web Server. Department of Computer Science, Rice University. [43] Courage M., Manley S. (1999): An Evaluation of CGI Traffic and its Effect on WWW Latency, Harvard University. [44] Nahum E. M. (2002): Deconstructing SPECweb99. 7th International Workshop on Web Content Caching and Distribution, August 2002. [45] Gousios G., Spinellis D. (2002): Comparison of Portable Dynamic Web Content Technologies for the Apache Server, 3rd International System Administration and Networking Conference SANE 2002, pages 103–119, Maastricht, The Netherlands. [46] Titchkosky L., Arlitt M., Williamson C. (2003): A Performance Comparison of Dynamic Web Technologies. [47] Kotsis G., Taferner L. (2002): Performance Comparison of Web-based Database Access. [48] Labrinidis A., Roussopoulos N. (2000): Generating dynamic content at database-backed web servers: cgi-bin vs mod_perl. Department of Computer Science and Institute for Systems Research, University of Maryland [49] http://www.ecma-international.org/ [50] http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/152257 77-8b91-4e7a-a49d-f4b4ad0f1b3a.mspx [51] Young M., Young C. W. (2003): Deploying Solution with .NET Enterprise Servers [52] Kurniawan B. (2002): Java for the Web with Servlets, JSP and EJB: A Developer’s Guide To J2EE Solutions [53] Piliptchouk D. (2003): Java vs. .NET Security, Part 1 http://www.onjava.com/pub/a/onjava/2003/11/26/javavsdotnet.html [54] Port80 Surveys the Top 1000 Corporations' Application Servers and Scripting Platforms (2005): http://port80software.com/surveys/top1000appservers/ [55] Patel J., Acker B., McGovern R. (2005): Creating Custom Web Controls with ASP.NET 2.0, http://msdn.microsoft.com/library/en-us/dnvs05/html/custwebcon.asp

83

Příloha A – obsah CD Výpis jednotlivých adresářů obsažených na CD. • • •

• •

analyza_mereni o analyza-jednotlivych-mereni.xls – zdrojová data a výsledky zpracování naměřených dat nastaveni_serveru o my.cnf – část konfiguračního souboru pro MySQL server o httpd.conf – část konfiguračního souboru testovane_skripty o asp – testovací soubory pro technologii ASP o asp.net – testovací soubory pro technologii ASP.NET o cgi – testovací soubory pro technologii CGI o cocoon – testovací soubory pro technologii Cocoon o fastCGI – testovací soubory pro technologii fastCGI o java jsp – testovací soubory pro Java Server Pages o java servlet – testovací soubory Java Servlet o perl – testovací soubory pro technologii Perl o php – testovací soubory pro technologii PHP o python – testovací soubory pro technologii Python o static – pro srovnání testovaných technologií ještě statické stránky zverejnene-chyby.xls – přehled všech zveřejněných chyb, které byly v práci srovnávany diplomova prace.pdf – elektronická verze této diplomové práce

84