Na tomto míst bude ociální zadání va²í práce

Na tomto míst¥ bude ociální zadání va²í práce •

Toto zadání je podepsané d¥kanem a vedoucím katedry,

•

musíte si ho vyzvednout na studiijním odd¥lení Katedry po£íta£· na Karlov¥ nám¥stí,

•

v jedné odevzdané práci bude originál tohoto zadání (originál z·stává po obhajob¥ na kated°e),

•

ve druhé bude na stejném míst¥ neov¥°ená kopie tohoto dokumentu (tato se vám vrátí po obhajob¥).

i

ii

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·

Bakalá°ská práce

Mapa Internetu

Viktor Bohuslav Bohdal

Vedoucí práce:

Ing. Michal Medvecký

Studijní program: Softwarové technologie a management, Bakalá°ský

Obor: Softwarové inºenýrství

24. kv¥tna 2011

iv

v

Pod¥kování D¥kuji panu Ing. Michalovi Medveckému za jeho p°ipomínky, ochotu a trp¥livost p°i vedení mé bakalá°ské práce. Dále d¥kuji kolegovi Lubomíru Ji°i²tovi za jeho podporu a v¥cné p°ipomínky.

vi

vii

Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

V eském Krumlov¥ dne 22. 5. 2011

.............................................................

viii

Abstract This bachelor thesis explores the sources of physical location of IP addresses and investigate the logical topology of IP networks. A web-based application with implementation of these sources is a part of the thesis that displays the locations on maps and graphicaly shows the logical topology. In thesis is evaluated the solution and the performance. Translation of Czech abstract into English.

Abstrakt Tato práce se zabývá zkoumáním zdroj· fyzického umíst¥ní ve°ejných IP adres a zji²óváním logické topologie IP sítí. Sou£ástí práce je implementace t¥chto zdroj· do webové aplikace, která zobrazuje umíst¥ní IP adres na mapových podkladech a gracky znázor¬uje logickou topologii £ásti sít¥. V práci je zhodnocena vhodnost °e²ení a výkonnost aplikace.

ix

x

Obsah 1 Úvod

1

2 Popis problému, specikace cíle

3

2.1

Struktura práce ve vztahu k vyty£eným cíl·m . . . . . . . . . . . . . . . . . .

3

2.2

IP adresace

3

2.2.1

IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2.1.1

. . . . . . . . . . . . . . . . . . . . . . . .

4

IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2.2.1

. . . . . . . . . . . . . . . . . . . . . . . .

5

Zdroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.3.1

2.2.2

2.3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.2

Vyhrazené adresy

Vyhrazené adresy

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.3.1.1

Fyzické umíst¥ní

WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3.1.2

Maxmind GeoLite City

. . . . . . . . . . . . . . . . . . . . .

8

2.3.1.3

IPInfoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3.1.4

Reverzní DNS záznamy

Logické umíst¥ní

. . . . . . . . . . . . . . . . . . . . .

9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

. . . . . . . . . . . . . . . . . . . . . . . . .

9

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.4

Mapové podklady - Google Maps . . . . . . . . . . . . . . . . . . . . . . . . .

11

. . . . . . . . . . . . . . . . . . . . . . . . .

11

2.5

Relevance výsledk· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.4.1

2.3.2.1

Databáze IANA

2.3.2.2

Traceroute

Pouºití Google Maps API

3 Analýza 3.1

3.2

13

Poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.1.1

Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.1.2

Mimofunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . .

14

P°ípady uºití

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.2.1

Zobrazení fyzického umíst¥ní

. . . . . . . . . . . . . . . . . . . . . . .

16

3.2.2

Zobrazení logické topologie

. . . . . . . . . . . . . . . . . . . . . . . .

16

3.2.3

Kontrola fronty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2.4

Zji²óvání fyzického umíst¥ní

. . . . . . . . . . . . . . . . . . . . . . .

18

3.2.5

Zji²óvání logického umíst¥ní

. . . . . . . . . . . . . . . . . . . . . . .

19

xi

xii

OBSAH

4 Návrh °e²ení 4.1

4.2

4.3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.1.2

MySQL

21

4.1.3

JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.1.4

AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.1.5

XHTML a CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Knihovny

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nette Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.2.2

jQuery knihovna

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.2.3

NotORM

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

Architektura aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.3.1

23

Styl MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.1

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.3.1.2

View

24

4.3.1.3

Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Model aplikace

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.2.1

Cachování dat

4.3.2.2

Rozhraní

4.3.2.3

Sluºby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Prezenta£ní vrstva

. . . . . . . . . . . . . . . . . . . . . . . . . .

25 26 26

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

Démon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

29

Pouºité nástroje 5.1.1 5.1.2

5.3

24 24

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Implementace

5.2

22 23

4.2.1

4.3.3

5.1

21

4.1.1

4.3.2

4.4

21

Technologie

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Opera£ní systém

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Modelovací nástroje

29 29

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

5.1.2.1

Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . .

29

5.1.2.2

MySQL Workbench 5.2 CE . . . . . . . . . . . . . . . . . . .

5.1.3

Vývojové prost°edí NetBeans

5.1.4

Verzovací systém Git . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Problémy b¥hem implementace

. . . . . . . . . . . . . . . . . . . . . . .

29 30 30

. . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.2.1

Pam¥óvá náro£nost

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.2.2

asová náro£nost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.2.3

Výpo£etní náro£nost . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

Nasazení aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

6 Záv¥r

33

6.1

Statistika

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2

Moºnosti pokra£ování

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 34

A Seznam pouºitých zkratek

37

B Poºadavky aplikace

39

B.1

PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

OBSAH

xiii

C Obrázky aplikace

41

D Obsah p°iloºeného CD

45

xiv

OBSAH

Seznam obrázk· 2.1

Hierarchie správc· IPv4 adresního prostoru, zdroj: APNIC . . . . . . . . . . .

3.1

Diagram p°ípad· uºití

3.2

Diagram aktivit - znázorn¥ní scéná°e uºití - zobrazení fyzického umíst¥ní a logické topologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.3

Diagram aktivit - znázorn¥ní scéná°e uºití - kontrola fronty.

18

3.4

Diagram aktivit - znázorn¥ní scéná°e uºití - zji²óvání fyzického umíst¥ní a

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

6 15

logické topologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

4.1

Vztahy mezi komponentami MVC, zdroj: Jan Tichý . . . . . . . . . . . . . . .

24

4.2

E-R model databáze

25

5.1

Aplikace: Informování uºivatele o zbývajícím £ase pro na£tení

. . . . . . . . .

31

5.2

Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

6.1

Aplikace: Zobrazení logické topologie IP sít¥ . . . . . . . . . . . . . . . . . . .

33

C.1

Aplikace: Zobrazení fyzického umíst¥ní - sít¥ t°ídy A v Evrop¥ . . . . . . . . .

41

C.2

Aplikace: Zobrazení fyzického umíst¥ní - sít¥ t°ídy A v Severní Americe . . . .

42

C.3

Aplikace: Zobrazení logické topologie - £ást rozsahu rozsahu klubu Silicon Hill

43

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xv

xvi

SEZNAM OBRÁZK

Seznam tabulek 2.1

Rozd¥lení IPv4 adres do t°íd . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

RFC 3330 - Special-Use IPv4 Addresses

. . . . . . . . . . . . . . . . . . . .

5

2.3

RFC 3330 - Special-Use IPv6 Addresses

. . . . . . . . . . . . . . . . . . . .

5

6.1

Statistika £asové náro£nosti - jednovláknový p°ístup

6.2

Statistika velikosti datového úloºi²t¥

. . . . . . . . . . . . . .

34

. . . . . . . . . . . . . . . . . . . . . . .

35

xvii

xviii

SEZNAM TABULEK

Kapitola 1

Úvod Tématem této bakalá°ské práce je fyzické umíst¥ní ve°ejných IP adres a logické topologie IP sít¥. Prozkoumává r·zné ve°ejn¥ dostupné zdroje s pot°ebnými informacemi. Lokalizace je hojn¥ vyuºívána zejména ve webovém prost°edí, kde díky zji²t¥ní fyzického umíst¥ní uºivatele lze cílen¥ sm¥°ovat reklamu pro daný region nebo zobrazit jazykovou mutaci odpovídající jazyku v daném prost°edí. Dal²ím vyuºitím je nap°. zji²t¥ní p°ibliºné umíst¥ní úto£ník· na systému apod. Téma bakalá°ské práce jsem vybral zám¥rn¥ z n¥kolika d·vod·. V minulosti jsem se n¥kolikrát snaºil zjistit fyzické umíst¥ní IP adres, zejména v p°ípad¥ statistik webových prezentací, kde jsem cht¥l zjistit p·vod náv²t¥vník·. Tyto informace jsem získával z r·zných zdroj·, proto mne téma zaujalo agregací t¥chto zdroj· a pro její vyuºitelnost. Dal²ím d·vodem byly obory mého zájmu - konkrétn¥ softwarové inºenýrství a síóvé technologie. Ve vývoji aplikace vyuºiji znalosti ze softwarového inºenýrství a doménou aplikace je IP adresace a získávání dat pomocí standardních síóvých protokol·.

1

2

KAPITOLA 1.

ÚVOD

Kapitola 2

Popis problému, specikace cíle Cílem práce je prozkoumat r·zné ve°ejn¥ dostupné zdroje s informacemi o fyzickém umíst¥ní IP adres a zdroje pro rekonstrukci topologie síóvého rozsahu. Výstupem je návrh a vytvo°ení webové aplikace, která tyto zdroje implementuje, lokalizuje zadaný rozsah IP adres a výsledky zobrazí v map¥. Aplikace se také pokusí o rekonstrukci topologie zadaného rozsahu IP adres. D·leºitou vlastností navrhované aplikace je její roz²i°itelnost. Pro aplikaci je d·leºité, aby se dala snadno roz²í°it o dal²í zdroje s informacemi.

2.1

Struktura práce ve vztahu k vyty£eným cíl·m

V této kapitole jsou prozkoumány zdroje, které práce vyuºívá k získávání pot°ebných informací. Zde zmín¥né zdroje jsou poté implementovány v aplikaci. Zdroje jsou rozd¥leny do dvou £ástí - zdroje s informacemi o fyzickém umíst¥ní adresy a zdroje k získání dat pot°ebných pro zji²t¥ní topologie síóvého rozsahu. Dále jsou zde p°edstaveny pouºité mapové podklady a princip adresování v IP sítích. Kapitola

Analýza

(kap. 3) se podrobn¥ji v¥nuje zadání aplikace. Zkoumá poºadavky a

jednotlivé p°ípady uºití.

Návrh °e²ení

(kap. 4) p°ibliºuje základní architekturu aplikace. Je

zde uveden p°ehled pouºitých t°íd a knihoven t°etích stran s jejich krátkým popisem. V kapitole

Implementace

(kap. 5) je popsán vývoj aplikace a infrastruktura. Jsou zde

také zdokumentovány problémy, které se b¥hem vývoje aplikace vyskytly. Kapitola

Záv¥r

(kap. 6) shrnuje diskutované zdroje a dále obsahuje zhodnocení této

práce. Ukazuje statistické informace o aplikaci a navrhuje moºná pokra£ování v této práci.

2.2

IP adresace

IP adresa je identikátor pouºívaný v po£íta£ových sítích, které komunikují pomocí IP protokolu. Kaºdé rozhraní p°ipojené do sít¥ by m¥lo mít svojí IP adresu, která je jedine£ná

1

v rámci dané sít¥. V sou£asnosti existují dv¥ verze IP protokolu IPv4 a IPv6 . Pod pojmem IP subnet se myslí £ást IP rozsahu reprezentující ur£itou sí´. 1

Pokud není uvedeno jinak, pod pojmem IP adresa se v této práci myslí IP adresa protokolu verze 4.

3

4

KAPITOLA 2.

2.2.1

POPIS PROBLÉMU, SPECIFIKACE CÍLE

IPv4

IP protokol verze 4 pouºívá k adresaci 32bitový identikátor, který se zapisuje do skupin po osmi bitech (oktet·) odd¥lených te£kou. Pro snaº²í £itelnost a zapamatovatelnost se oktety zapisují také dekadicky. S IP adresou souvisí také pojem maska sít¥. Maska sít¥ je d·leºitá pro ur£ení, do které sít¥ dané IP adresa pat°í. Maska sít¥ je také 32bitové £íslo, které se zapisuje po oktetech odd¥lených te£kami, nebo v tzv. slash formátu. Jedná se o formu zápisu, ozna£ovanou CIDR. P°íklad masky sít¥ (stejná maska v r·zných formátech): 11111111.11111111.11110000.00000000 - 255.255.240.0 - /20 Maska sít¥ udává, kolik bit· z IP adresy identikuje sí´ a kolik bit· zbývá pro identikaci za°ízení v síti. IP adresu sít¥ lze z IP adresy za°ízení a masky sít¥ získat pomocí operace logický sou£in na jednotlivých bitech identikátoru. IP adresy se rozd¥lují do n¥kolika t°íd v závislosti na po£áte£ních bitech prvního oktetu.

T°ída První bity

Rozsah

Maska

A

0

0.0.0.0 - 127.255.255.255

/8

B

10

128.0.0.0 - 191.255.255.255

/16

C

110

192.0.0.0 - 223.255.255.255

/24

D

1110

224.0.0.0 - 239.255.255.255

/32

E

1111

240.0.0.0 - 255.255.255.255

Tabulka 2.1: Rozd¥lení IPv4 adres do t°íd

2.2.1.1 Vyhrazené adresy IP adresy, u kterých je zbyte£né zji²óvat fyzické, £i logické umíst¥ní. Tyto IP adresy se v¥t²inou pouºívají ke speciálním ú£el·m (nap°. experimentální, privátní adresy, broadcast) a neobjevují se v internetu.

2.2.2

IPv6

IP protokol verze 6 pouºívá k adresaci za°ízení v síti 128bitový identikátor. Pro snaº²í £itelnost se zapisuje do osmi skupin po £ty°ech hexadecimálních £íslicích. Pro snaº²í zápis se adresy mohou zkracovat, pokud se v adrese za sebou nachází více skupin s nulami apod. Toto zkrácení se m·ºe v rámci jedné IP adresy uplatnit pouze jednou. P°íklad r·zného zápisu stejné IPv6 adresy:

•

2001:0db8:0000:0000:0000:0000:1428:57ab

•

2001:0db8:0000:0000:0000::1428:57ab

•

2001:0db8:0:0:0:0:1428:57ab

2.2.

5

IP ADRESACE

Blok

První IP

Poslední IP

Popis

Reference

0.0.0.0/8

0.0.0.0

0.255.255.255

"Tato"sí´

RFC 1700

10.0.0.0/8

10.0.0.0

10.255.255.255

Privátní rozsah

RFC 1918

127.0.0.0/8

127.0.0.0

127.255.255.255

Loopback, místní smy£ky

RFC 1700

169.254.0.0/16

169.254.0.0

169.254.255.255

"Místní spoje",

172.16.0.0/12

172.16.0.0

172.31.255.255

Privátní rozsah

192.0.2.0/24

192.0.2.0

192.0.2.255

"TEST-NET",

192.18.0.0/15

192.18.0.0

192.19.255.255

Výkonnostní testování

RFC 2544

192.88.99.0/24

192.88.99.0

192.88.99.255

Mapování IPv6to4 adres

RFC 3068

192.168.0.0/16

192.168.0.0

192.168.255.255

Privátní rozsah

RFC 1918

224.0.0.0/4

224.0.0.0

239.255.255.255

Multicastové adresy

RFC 3171

240.0.0.0/4

240.0.0.0

255.255.255.255

Broadcast

RFC 1700

autokongurace RFC 1918

dokumentace

Tabulka 2.2: RFC 3330 - Special-Use IPv4 Addresses

•

2001:0db8:0:0::1428:57ab

•

2001:0db8::1428:57ab

•

2001:db8::1428:57ab

Stejn¥ jako u p°edchozí verze IP protokolu se u IPv6 pouºívá maska sít¥.

2.2.2.1 Vyhrazené adresy IP adresy, u kterých je zbyte£né zji²óvat fyzické, £i logické umíst¥ní. Tyto IP adresy se v¥t²inou pouºívají ke speciálním ú£el·m (nap°. experimentální, privátní adresy, broadcast) a neobjevují se v internetu.

Blok

Popis

Reference

::1/128

Loopback, místní smy£ky

RFC 4291

::/128

Nespecikovaná adresa

RFC 4291

::FFFF:0:0/96

IPv4 mapování

RFC 4291

::/96

Adresy pro zp¥tnou kompatibilitu s IPv4

RFC 4291

fe80::/10

Místní unicast

RFC 4291

2001:db8::/32

Dokumentace

RFC 3849

5f00::/8

6bone experimentální

RFC 1897

3e::/16

6bone experimentální

RFC 2471

2001:10::/28

ORCHID, neroutovatelné

RFC 4843

::/0

Defaultní routa

00::/8

Multicast

Tabulka 2.3: RFC 3330 - Special-Use IPv6 Addresses

RFC 4291

6

KAPITOLA 2.

2.3


Zdroje

Tato podkapitola se zabývá jednotlivými zdroji dat pro tuto práci. Zdroje jsou rozd¥leny do dvou £ástí - zdroje pro fyzické umíst¥ní a zdroje pro zji²óvání logické topologie.

2.3.1

Fyzické umíst¥ní

Problémem s ur£ováním fyzického umíst¥ní stroje se zadanou IP adresou je to, ºe nejsme schopni zjistit, zda organizace, které byla daná IP adresa p°id¥lena, ji pouºila na adrese uvedené v registru nebo zda IP adresu pouºila v jiném m¥st¥ £i dokonce stát¥. Toto zt¥ºují r·zné síóvé principy jako tunelování, routování £i virtuální privátní sít¥ (VPN). Nelze ur£it p°esn¥ fyzické umíst¥ní stroje s danou IP adresou. Rozsahy IP adres nejsou systematicky rozd¥lovány podle oblastí, ve kterých se p°id¥lují. Proto je moºné, ºe jeden rozsah je p°id¥lený organizaci v Evrop¥ a následující rozsah je p°id¥len organizaci v Asii. Je moºné pouze ur£it nejpravd¥podobn¥j²í umíst¥ní pouºitím r·zných zdroj· a pomocných nástroj·. Kaºdé IP adrese bude ur£ena míra pravd¥podobnosti, ºe se stroj s danou IP adresou nachází na zji²t¥ném umíst¥ní. Tato pravd¥podobnost bude ur£ena na základ¥ výstup· z jednotlivých zdroj·, které budou poptávány. Kaºdý zdroj je ohodnocen ur£itou relevancí, která by m¥la reektovat d·v¥ryhodnost a správnost údaj· v databázi. ím více zdroj· ur£í jednu lokalitu, tím vy²²í bude relevance.

Obrázek 2.1: Hierarchie správc· IPv4 adresního prostoru, zdroj: APNIC

Ze zdroj· lze s vysokou pravd¥podobností ur£it stát, ve kterém se stroj s danou IP adresou nachází, protoºe jméno zem¥ je povinný údaj p°i p°id¥lování IP rozsahu organizaci.

2.3.

7

ZDROJE

Tyto údaje jsou ukládány u správce IANA. S kaºdým rozd¥lením na men²í územní celky pravd¥podobnost rapidn¥ klesá, protoºe neexistuje ºádný ociální zdroj s t¥mito daty. IANA

(Internet Assigned Numbers Authority)

[7] je organizace, která má na starost ce-

losv¥tovou správu IP adresního prostoru, ko°enových zón DNS a dal²ích zdroj· d·leºitých pro internet. Pro správu IP adres je IANA ko°enovým prvkem. Správci jsou rozd¥leni do stromové hierarchie, kde kaºdý správce má na starost ur£itou oblast a jsou mu p°id¥leny rozsahy IP adresy v¥t²ím správcem. Pod IANA spadá p¥t organizací, mezi které jsou rozd¥leny jednotlivé kontinenty (nap°. pro Evropu je správce komunita RIPE). Tito správci se

2

3 a LIR 4 . Lokální registry dále p°i°azují IP 5 adresy jednotlivým poskytovatel·m internetových sluºeb (ISP ) £i koncovým uºivatel·m.

ozna£ují jako RIR , kte°í se dále d¥lí na NIR

2.3.1.1 WHOIS Z výpisu získaného pomocí protokolu WHOIS z databáze IANA m·ºeme o zadané IP adrese zjistit organizaci, které byl p°id¥len rozsah, do kterého daná adresa pat°í. Z WHOIS m·ºeme o dané organizaci zjistit její název a adresu. Registr IANA je ociální zdroj, proto jsou tato data povaºována za d·v¥ryhodná a pravdivá. Data získaná z WHOIS m·ºeme brát jako výchozí bod pro dal²í zji²óvání umíst¥ní. Výpis pro IP 147.32.30.1:

inetnum: netname: descr: descr: country: admin-c: tech-c: status: mnt-by: mnt-lower: remarks: source:

147.32.0.0 - 147.32.255.255 CVUT-TCZ Czech Technical University Prague CZ MN718-RIPE MN718-RIPE ASSIGNED PI TENCZ-MNT TENCZ-MNT Please report ... RIPE

Ve výpisu je uveden administra£ní (admin-c) a technický kontakt (tech-c) pro daný subjekt (IP adresu). Pro pot°eby aplikace budou pouºity informace o administra£ním kontaktu, jakoºto o správci daného subjektu. Informace o administra£ním kontaktu MN718-RIPE:

person: address: address: address: address: address: 2 3 4 5

Regional Internet registry National Internet registry Local Internet registry Internet Service Provider

Michal Neuman CVUT - Vypocetni centrum Zikova 4 Praha 6 166 36 The Czech Republic

8

KAPITOLA 2.


V tomto p°ípad¥ se poda°ilo získat adresu organizace, která má danou IP adresu p°id¥-

Zikova 4, Praha 6. Ov²em stroj s IP adresou Vaní£kova, Praha 5. Specikace protokolu WHOIS je popsána v RFC 3912 [18].

lenu. Konkrétn¥ pro IP 147.32.30.1 je to adresa 147.32.30.1 je fyzicky umíst¥n na adrese

2.3.1.2 Maxmind GeoLite City Voln¥ dostupná databáze obsahující údaje o fyzickém umíst¥ní stroje s danou IP adresou. Poskytovatel uvádí p°esnost 99.5% na úrovni státu a 79% na úrovni m¥sta (v USA). Databázi je moºné stáhnout £i vyuºívat jako web service.

6

Z této databáze vychází velké mnoºství dal²ích zdroj·, které lze nalézt na Internetu.

Databáze Maxmind má také svoji komer£ní verzi. Tato fakta sv¥d£í o kvalit¥ databáze m·ºe být povaºována za d·v¥ryhodnou. Databáze je distribuována ve form¥ souboru £i ji lze vyuºít online [10].

2.3.1.3 IPInfoDB IPInfoDB [8] nabízí databázi lokací ve dvou verzích - lokace na úrovní státu, £i lokace na úrovni m¥sta. Poskytovatel databáze uvádí p°esnost údaj· 99.5% na úrovní státu a p°ibliºn¥ 80% na úrovni m¥sta (pouze pro USA a v okruhu 25 mil). IPInfoDB nabízí databázi k vyuºití pomocí programového rozhraní. API je p°ístupné p°es HTTP protokol a vrací data ve formátu XML. Pro vyuºití API je nutné provést registraci a tím získat API klí£. Registrace je zdarma. Po£et dotaz· je omezen limitem dvou dotaz· za sekundu, p°i£emº pokud dojde k p°ekro£ení limitu, zpomalí se zpracování dotaz· na 1 dotaz za 1 sekundu. Data pochází z voln¥ dostupné databáze MaxMind. K jejich úprav¥ jsou vyuºívány Geonames, informace o £asových pásmech a data z registru IANA. Databáze je m¥sí£n¥ aktualizována. Výstup pro IP 147.32.30.1:

<Status>OK CZ Czech Republic 52 Hlavni mesto Praha Prague 50.0833 14.4667 <Timezone>0 0 6

Nap°.: Modul do webového serveru Apache 2 - GeoIP

2.3.

ZDROJE

9

0 <TimezoneName> 147.32.30.1

2.3.1.4 Reverzní DNS záznamy Systém DNS neposkytuje pouze p°eklad doménových názv· na IP adresy, ale také naopak p°eklad IP adres na doménová jména. Reverzní záznam (DNS PTR) hraje v p°ekladu z IP adresy na doménové jméno d·leºitou roli práv¥ tento záznam obsahuje data pot°ebná pro p°eklad. Dá se p°edpokládat, ºe IP adresa, jejíº reverzní záznam existuje a doménové jméno po p°ekladu obsahuje národní doménu nejvy²²ího °ádu (TLD), je umíst¥na práv¥ v té zemi, které doména nejvy²²ího °ádu náleºí. Nap°.: P°eloºení IP adresy 147.32.3.39 na doménové jméno vrátí výstup www.cvut.cz. TLD je .cz, coº odpovídá eské republice. Reverzní DNS záznam m·ºe v tomto p°ípad¥ poskytnout orienta£ní informaci o fyzickém umíst¥ní dané IP adresy. To vychází z p°edpokladu, ºe DNS záznamy národních domén sm¥°ují na za°ízení umíst¥né v daném stát¥. Princip tohoto p°edpokladu je jednoduchý. Domácí doménová jména nej£ast¥ji pouºívají domácí uºivatelé. Provozovatel sluºby by se m¥l snaºit zp°ístupnit sluºbu uºivatel·m co nejlep²í cestou nejd·leºit¥j²í roli hraje konektivita. Domácí konektivita je zpravidla rychlej²í a levn¥j²í a bývá mén¥ omezena na objem p°enesených dat. Tento princip není nijak ociální, proto lze reverzní DNS záznamy brát pouze jako orienta£ní data. Systém doménových jmen je denován v RFC 1035 [16].

2.3.2

Logické umíst¥ní

2.3.2.1 Databáze IANA IANA (Internet Assigned Numbers Authority) je organizace, která má na starost správu IP adres. Kaºdá IP adresa pat°í do autonomního systému (AS). AS je mnoºina IP sítí a router·, které jsou spravovány spole£nou organizací. Autonomní systémy jsou ozna£ované celým £íslem (d°íve 16bit, dnes 32bitovým). Pomocí WHOIS dotazu lze zjistit, do kterého AS daná IP pat°í a na základ¥ t¥chto informací je moºné zadané IP adresy seskupit do logických celk·. Výpis z WHOIS o IP 147.32.30.1 (zkrácený):

10

KAPITOLA 2.

NetRange: CIDR: OriginAS: NetName: NetHandle: Parent: route: descr: origin: mnt-by: source:


147.32.0.0 - 147.33.255.255 147.32.0.0/15 RIPE-ERX-147-32-0-0 NET-147-32-0-0-1 NET-147-0-0-0-0 147.32.0.0/15 CVUT-TCZ + VSCHT-TCZ AS2852 AS2852-MNT RIPE

Výpis z WHOIS o IP 147.34.0.1 (zkrácený):

NetRange: CIDR: OriginAS: NetName: NetHandle: Parent: NetType: NameServer: NameServer: RegDate: Updated:

147.34.0.0 - 147.34.255.255 147.34.0.0/16 MENTORG10 NET-147-34-0-0-1 NET-147-0-0-0-0 Direct Assignment NS2.MENTORG.COM NS1.MENTORG.COM 1991-06-18 2005-04-25

Z výpisu lze zjistit, ºe IP adresa 147.32.30.1 pat°í do AS2852. Do tohoto AS pat°í celá sí´ 147.32.0.0/15. IP adresa 147.34.0.1 pat°í do rozsahu 147.34.0.0/16, který spravuje jiná organizace. Dá se p°edpokládat, ºe sít¥ 147.32.0.0/15 a 147.34.0.0/16 jsou dva r·zné logické celky. Takto m·ºeme zjistit rozd¥lení do základních logických celk· rozd¥lených dle t°íd IP adres.

2.3.2.2 Traceroute Hlavním zdrojem bude aplikace traceroute [17]. Aplikace slouºí k analýze sít¥. Zaznamenává uzly (routery) na cest¥ datagram· od zdroje k cíli. Její princip je zaloºen na hlavi£ce IP paketu, konkrétn¥ poloºky Time-to-live (TTL). Poloºka TTL pomáhá zabra¬ovat v zahlcení sít¥ v p°ípad¥, ºe by paket krouºil mezi sm¥rova£i. Pokud by se v síti objevilo více t¥chto ztracených paket·, docházelo by ke zbyte£nému zatíºení sít¥, které by mohlo vést aº k její nedostupnosti. TTL je hodnota, která je sniºována o jedna na kaºdém sm¥rova£i, kterým paket prochází na své cest¥ k cíli. Pokud dosáhne nulové hodnoty sm¥rova£ paket zahodí a vy²le odesílateli paketu zprávu ICMP Time Exceeded pomocí ICMP. Z výstupu aplikace traceroute lze zjistit, zda je síóvý rozsah rozd¥len do podsítí. Nap°.: Traceroute na 147.32.30.134:

2.4.

11

MAPOVÉ PODKLADY - GOOGLE MAPS

6

(194.50.100.191)

15.218 ms

11.047 ms

7

(195.113.144.174)

11.843 ms

11.010 ms

11.025 ms

8

(147.32.252.58)

11.164 ms

11.739 ms

11.795 ms

9

(147.32.252.237)

12.028 ms

11.672 ms

11.143 ms

(147.32.30.134)

11.242 ms

11.415 ms

11.299 ms

10

11.595 ms

Z výpisu se dá vy£íst, ºe IP rozsah 147.32.0.0/16 je pravd¥podobn¥ subnetován. Na skoku £. 9 je sm¥rova£, který pat°í do podsít¥, která má v rozsahu IP 147.32.252.237 a zárove¬ pat°í do sít¥, která má v rozsahu IP 147.32.30.134, tedy cílová stanice. Obdobn¥ lze soudit ze sm¥rova£e na skoku £. 8. P°i traceroute ov²em m·ºe nastat n¥kolik nep°íjemných situací.

•

Sm¥rova£ vrací IP adresu, kterou p°i sm¥rování na²eho paketu v·bec nepouºíváme.

•

Sm¥rova£ neodesílá ICMP zprávy.

•

Sm¥rova£ sice ICMP zprávy odesílá, ale s nízkým TTL, takºe se nevrátí.

T¥mto situacím nelze p°edcházet a proto s nimi musí být po£ítáno. Z aplikace traceroute lze zárove¬ zjistit £as odezvy (poslední t°i sloupce).

2.4

Mapové podklady - Google Maps

Google Maps je internetová mapová aplikace poskytovaná zdarma spole£ností Google. Krom¥ klasického mapového zobrazení poskytuje Google Maps satelitní zobrazení map, dopravní informace a dal²í. Aplikace nabízí ve°ejné programové rozhraní pro pouºití v aplikacích t°etích stran. V sou£asnosti je doporu£ené pouºívat t°etí verzi API. P·vodní, druhá verze je ozna£ena jako zastaralá (deprecated).

2.4.1

7

Pouºití Google Maps API

Google Maps API se pouºívá vloºeným JavaScriptového souboru do kódu aplikace. Na tento soubor se odkazuje p°ímo na server poskytovatele.

8

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=true/false"> V URL je povinný parameter

sensor,

který ur£uje, zda má aplikace Google Maps zji²óvat

fyzickou polohu uºivatele. Dále je zapot°ebí vytvo°it objekt typu

google.maps.Map, kterému

jsou p°edány dva parametry - prvek, do kterého se mapa vykreslí a moºnosti, které nastavují úvodní vlastnosti map (centrování, p°iblíºení, typ mapy a dal²í). 7 8

Více informací viz http://code.google.com/intl/cs-CZ/apis/maps/documentation/javascript/v2/ Soubor s JavaScriptem lze na£íst také p°es HTTPS

http://code.google.com/intl/cs-CZ/apis/maps/documentation/javascript/basics.html#HTTPS

12

KAPITOLA 2.


Pomocí JavaScripového API lze do map vkládat ukazatele, ikony, informa£ní okna £i sloºit¥j²í geometrické útvary. API umoº¬uje ovládat události, upravovat ovládání mapy, pracovat s vrstvami £i druhy mapových podklad·. Více o programovém rozhraní je na [5]. Pouºití tohoto rozhraní není limitováno po£tem spojení, £i po£tem dotaz·. P°edcházející verze API vyºadovali získání klí£e po vypln¥ní formulá°e na stránce poskytovatele. Od t°etí verze jiº klí£ není vyºadován.

2.5

Relevance výsledk·

Kaºdý zdroj je ohodnocen £íslem. Toto £íslo vyjad°uje d·v¥ryhodnost a p°esnost daného zdroje. P°i zobrazování výsledku je zobrazena také relevance daných hodnot. Pokud poskytne více zdroj· stejný výsledek relevance se s£ítá. Vy²²í relevance znamená vy²²í d·v¥ryhodnost a p°esnost výsledku. V ideálním p°ípad¥ by m¥l sou£et relevancí jednotlivých zdroj· roven 100. V takovém p°ípad¥ by relevance výsledk· byla v procentech.

Kapitola 3

Analýza Webová aplikace ur£ená pro zji²óvání a vizualizaci fyzického a logického rozmíst¥ní za°ízení v £ástech ve°ejné sít¥. Z r·zných ve°ejn¥ dostupných zdroj· bude získávat informace o poºadovaném rozsahu IP adres. Získaná data bude ukládat do vlastní databáze pro moºnost op¥tovného rychlého zobrazení výsledk·. Uºivatel si bude moci vyºádat aktualizaci údaj· v databázi aplikace. Uºivatel bude moci data opakovan¥ zobrazovat ve fyzickém a logickém pohledu. V rámci fyzického pohledu se zobrazí mapové podklady z on-line mapové aplikace, do kterých budou zakreslena získaná data. Logický pohled bude nabízet náhled na zji²t¥nou topologii sít¥ seskupení prvk· do logických celk·, zji²t¥né propojení jednotlivých prvk·.

3.1

Poºadavky

Poºadavky denují vlastnosti, které má aplikace mít, £i funk£nost, kterou má aplikace poskytovat. Analýza poºadavk· je první fáze p°i vývoji software. Na základ¥ této analýzy jsou vytvo°eny jednotlivé p°ípady uºití.

3.1.1 1.

Funk£ní poºadavky

Rekonstrukce topologie sít¥. Aplikace zjistí z dostupných zdroj· informace o jednotlivých adresách dané sít¥ a pokusí se je rozd¥lit na základ¥ zji²t¥ných informací do jednotlivých logických celk·.

2.

Zji²t¥ní fyzické lokalizace IP adresy £i rozsahu IP adres. Aplikace zjistí z r·zných zdroj· informace o fyzickém umíst¥ní jednotlivých IP adres.

3.

Vykreslení fyzického umíst¥ní do on-line mapové aplikace. Aplikace vyuºívá API rozhraní ve°ejné on-line mapové aplikace, do jejíchº podklad· zakreslí zji²t¥né výsledky o fyzickém umíst¥ní.

4.

Ukládání výsledk· do cache aplikace. Aplikace ukládá zji²t¥né výsledky do vlastní cache, aby se p°i novém poºadavku na informace o zadané síti zbyte£n¥ znovu nezískávala data a zbyte£n¥ nezat¥ºovaly zdroje.

13

14

KAPITOLA 3.

3.1.2 1.

ANALÝZA

Mimofunk£ní poºadavky

Podpora IPv4 protokolu. Aplikace podporuje aktuáln¥ nejpouºívan¥j²í verzi protokolu IP a její adresaci.

2.

Roz²i°itelnost o dal²í verze IP protokolu. Návrh aplikace je zvolen tak, aby bylo snadné aplikaci roz²í°it o podporu dal²ích verzí IP protokolu.

3.

Mapové podklady Google Maps. Jako mapové podklady pro zobrazení fyzického umíst¥ní IP adres pouºívá aplikace online statické mapové podklady Google Maps.

4.

Vyuºití standardních protokol·. Aplikace získává data ze zdroj· pomocí ve°ejn¥ dostupných standardních protokol·.

5.

Webové uºivatelské rozhraní. Aplikace nabízí jednoduché a pouºitelné webové uºivatelské rozhraní, pouºitelné i pro uºivatele se základní znalostí práce s PC.

6.

P°ístup k internetu. Aplikace pot°ebuje pro dotazování zdroj· internetovou konektivitu. Pro zobrazení mapových podklad· z on-line mapové aplikace je také pot°eba internetová konektivita.

7.

Jazyk PHP. Pro vývoj aplikace bude pouºit skriptovací programovací jazyk PHP.

8.

Rozsah v CIDR formátu Uºivatel bude zadávat IP sí´ ve formátu CIDR (A.B.C.D/xx).

3.2.

3.2

15

PÍPADY UITÍ

P°ípady uºití

V aplikaci se nachází pouze dv¥ uºivatelské role - samotný uºivatel a démon, který se stará o získávání dat ze zdroj·. Kaºdá z t¥chto rolí pouºívá n¥které p°ípady uºití - specikace posloupnosti £inností, které systém vykonává.

Obrázek 3.1: Diagram p°ípad· uºití

16

KAPITOLA 3.

3.2.1

ANALÝZA

Zobrazení fyzického umíst¥ní

Akté°i: uºivatel Vstupní podmínky: Uºivatel zadal platný rozsah. Hlavní scéná°: 1. Uºivatel zadá platný rozsah. 2. Pokud se jedná o vynucenou aktualizaci, uloºí se subnet do fronty a vymaºou se stará data. 3. Prohledá se cache. 4. Pokud nejsou data v cache, opakuje se prohledávání cache. Prohledávání se p°eru²í, pokud se poda°í nalézt data v cache, £i je vy£erpán maximální po£et pokus·. 5. Systém na£te data z cache. 6. Systém zpracuje data a p°ipraví je k odeslání uºivateli. 7. Systém ode²le data uºivateli. 8. Data jsou zobrazena uºivateli.

3.2.2

Zobrazení logické topologie

Akté°i: uºivatel Vstupní podmínky: Uºivatel zadal platný rozsah. Scéná°: 1. Uºivatel zadá platný rozsah. 2. Pokud se jedná o vynucenou aktualizaci, uloºí se subnet do fronty a vymaºou se stará data. 3. Prohledá se cache. 4. Pokud nejsou data v cache, opakuje se prohledávání cache. Prohledávání se p°eru²í, pokud se poda°í nalézt data v cache, £i je vy£erpán maximální po£et pokus·. 5. Systém na£te data z cache. 6. Systém zpracuje data a p°ipraví je k odeslání uºivateli. 7. Systém ode²le data uºivateli. 8. Data jsou zobrazena uºivateli.

3.2.

PÍPADY UITÍ

17

Obrázek 3.2: Diagram aktivit - znázorn¥ní scéná°e uºití - zobrazení fyzického umíst¥ní a logické topologie.

3.2.3

Kontrola fronty

Akté°i: démon Vstupní podmínky: ádné. Scéná°: 1. Démon prohledá frontu. 2. Pokud je fronta prázdná, po£ká démon ur£ený £asový interval a spustí znovu prohledávání fronty. 3. Pokud se ve front¥ nachází IP adresy, démon si jednu vybere. 4.

extend Démon zjistí data pro fyzické umíst¥ní.

5.

extend Démon zjistí data pro logickou topologii.

18

KAPITOLA 3.

ANALÝZA

6. Démon uloºí výsledek do cache. 7. Systém vymaºe IP adresu z fronty. 8.

extend Systém uloºí získaná data.

Obrázek 3.3: Diagram aktivit - znázorn¥ní scéná°e uºití - kontrola fronty.

3.2.4

Zji²óvání fyzického umíst¥ní

Akté°i: démon Vstupní podmínky: Poºadavek na platnou IP adresu. Scéná°: 1. Démon po²le poºadavek. 2. Systém vybere nepouºitý zdroj informací, pokud n¥jaký má. 3. Systém se dotáºe vybraného zdroje. 4. Systém opakuje výb¥r. 5. Pokud systém nemá ºádný nepouºití zdroj, vrátí výsledek.

3.2.

PÍPADY UITÍ

19

Obrázek 3.4: Diagram aktivit - znázorn¥ní scéná°e uºití - zji²óvání fyzického umíst¥ní a logické topologie.

3.2.5

Zji²óvání logického umíst¥ní

Akté°i: démon Vstupní podmínky: Poºadavek na platnou IP adresu. Scéná°: 1. Démon po²le poºadavek. 2. Systém vybere nepouºitý zdroj informací, pokud n¥jaký má. 3. Systém se dotáºe vybraného zdroje. 4. Systém opakuje výb¥r. 5. Pokud systém nemá ºádný nepouºití zdroj, vrátí výsledek.

20

KAPITOLA 3.

ANALÝZA

Kapitola 4

Návrh °e²ení Navrhovaným °e²ením je webová aplikace napsaná v jazyce PHP [15] vyuºívající databázový systém MySQL [11] jako vlastní cache pro ukládání zji²t¥ných výsledk·. Aplikace vyuºívá PHP framework Nette [14] a JavaScript knihovnu jQuery [9]. Prezenta£ní vrstvu aplikace tvo°í XHTML, CSS [6] a JavaScript. Pro komunikaci se serverovou £ástí vyuºívá prezenta£ní vrstva také technologie AJAX.

4.1

Technologie

4.1.1

PHP

PHP (PHP: Hypertext Preprocessor)[15] je ²iroce pouºívaný open-source skriptovací jazyk ur£ený zejména pro vývoj dynamických webových aplikací. Oblíbený je zejména pro svoji jednoduchost, multiplatformost, roz²i°itelnost a ²irokou komunitu vývojá°·. Nej£ast¥ji se za£le¬uje p°ímo do struktury jazyka (X)HTML. PHP lze také pouºít k tvorb¥ konzolových a desktopových aplikací. P°i pouºití PHP jsou skripty provád¥ny na stran¥ serveru. Následný výstup t¥chto skript· je p°ená²en uºivateli. Syntaxe jazyka je velice podobná programovacímu jazyku C. Obecn¥ je PHP nezávislé na opera£ním systému, pouze n¥které funkce jsou závislé na zvolené platform¥. D·leºitou sou£ástí PHP jsou roz²í°ení, z nichº velká £ást je obsaºena p°ímo v distribuci

1

2 a PEAR3 .

PHP . Dal²í roz²í°ení lze získat p°es repozitá°e PECL

Nejnov¥j²í verze, která je i pouºita v práci, je ozna£ena

4.1.2

PHP 5.3.

MySQL

MySQL je multiplatformní databázový systém, který pro komunikaci pouºívá dialekt jazyka SQL. Tento dialekt má oproti standardnímu SQL n¥která specická roz²í°ení. MySQL je 1

<

Seznam standardních roz²í°ení jazyka PHP

http://php.net/manual/en/extensions.alphabetical.php> 2 3

21

22

KAPITOLA 4.

NÁVRH EENÍ

velice oblíbený díky snadné implementovatelnosti a své cen¥ - je k dispozici pod bezplatnou licencí GPL (komunitní edice) i pod komer£ní placenou licencí. MySQL bylo zpo£átku optimalizováno pro rychlost, proto nenabízí funk£nost jako jiné

4

databázové systémy . N¥které funkce p°i²ly aº s verzí MySQL 5 - nap°. procedury, funkce, triggery a pohledy.

5

MySQL podporuje n¥kolik metod ukládání dat . Rozdíly mezi jednotlivými zp·soby jsou nap°.: typy klí£·, podpora transak£ního zpracování. Krom¥ t¥chto rozdíl· jsou r·zné výkonnosti jednotlivých metod.

4.1.3

JavaScript

JavaScript je objektov¥ orientovaný skriptovací jazyk, který se zpravidla pouºívá jako interpretovaný programovací jazyk pro webové aplikace. asto se vkládá p°ímo do HTML kódu stránky. Pomocí JavaScriptu se vytvá°í dynami£nost prezenta£ní vrstvy p°ímo u klienta. Syntakticky je podobný jazyku Java, ale jinak s tímto jazykem má spole£ný pouze název. Výhodou jazyka je jeho multiplatformost. Jeho interpretace záleºí na JavaScriptovém jád°e integrovaném p°ímo ve webovém prohlíºe£i. To zp·sobuje drobné rozdíly ve funk£nosti mezi jednotlivými prohlíºe£i.

4.1.4 AJAX

AJAX

6 není programovací jazyk, ale pouze zp·sob jak vyuºít existující prost°edky. AJAX

umoº¬uje komunikaci klienta se serverem bez nutnosti na£ítání celé webové stránky. Tato komunikace probíhá na pozadí, coº umoº¬uje uºivateli nadále pracovat s p·vodní stránkou. Pro komunikaci je nej£ast¥ji vyuºit protokol HTTP a data jsou p°ená²ena ve formátu XML, (X)HTML nebo JSON.

4.1.5

XHTML a CSS

7 a CSS8 jsou dv¥ základní technologie pro vytvá°ení webových stránek. HTML de-

HTML

nuje strukturu, zatímco CSS poskytuje pravidla pro zobrazení na r·zných za°ízeních. XHTML

9 je jazyk pro vytvá°ení webových dokument·. Jazyk XHTML je upravená verze

HTML tak, aby vyhovoval podmínkám tvorby XML dokument· se zachováním zp¥tné kompatibility. XHTML se snaºí striktn¥ odd¥lit strukturu dokumentu od denice jeho vzhledu. P·vodní jazyk HTML umoº¬oval m¥nit vzhled dokumentu p°ímo ve struktu°e. 4

<

Porovnání databázových systém· MySQL a Oracle

http://blogs.oracle.com/GeorgeTrujillo/entry/mysql_versus_oracle_features_functionality> 5 Storage engines - 6 7 8 9

Asynchronous JavaScript and XML the Hypertext Markup Language Cascading Style Sheets Extensible Hypertext Markup Language

4.2.

23

KNIHOVNY

4.2

Knihovny

4.2.1

Nette Framework

Nette Framework je výkonný framework pro vytvá°ení webových aplikací v PHP 5. Je po-

10 , KISS11 , MVC12 a znovupouºitelnosti. Nette Framework je dílo 13 £eského autora a je dostupný zdarma pod BSD licencí .

staven na principech DRY

Framework rozd¥luje aplikaci dle MVC na komponenty model, °adi£ ( hled(

view ). Pro tvorbu komponenty pohled

controller )

a po-

je vyuºíván ²ablonovací systém integrovaný p°ímo

v Nette Frameworku.

4.2.2

jQuery knihovna

Knihovna jQuery (ozna£ovaná také jako framework) zjednodu²uje práci se skriptovacím jazykem JavaScript a nabízí moºnost roz²i°ování r·znými dopl¬ky. jQuery je bezplatn¥ dostupný pod duálními licencemi GPL

14 a MIT15 .

Knihovna se snaºí také °e²it rozdíly mezi jednotlivými JavaScriptovými jádry v prohlíºe£ích.

4.2.3

NotORM

NotORM[2] je knihovna, která vytvá°í p°ístupovou vrstvu k databázovému systému v PHP aplikacích. Jak samotný název napovídá, nejedná se o

objektov¥ rela£ní mapování. NotORM

16 ). Knihovna

je dílo £eského autora s bezplatným licencováním (GPL nebo Apache Licence

podporuje nej£ast¥ji vyuºívané databázové systémy (MySQL, PostgreSQL, Oracle). NotORM se m·ºe chlubit velice dobrými výkonnostními výsledky [3].

4.3

Architektura aplikace

Aplikace reektuje architektonický styl MVC, který je p°ímo podporován pouºitým Nette frameworkem.

4.3.1

Styl MVC

Architektonický styl MVC [1] (Model-View-Conroller) je velmi oblíbený zp·sob návrhu aplikace. MVC rozd¥luje aplikaci do t°í komponent - Model, View (pohled) a Controller (°adi£). Kaºdá komponent má p°esn¥ denováno, za co je v aplikaci odpov¥dná. Komponenty jsou vzájemn¥ nezávislé a vým¥na jedné komponenty by nem¥la ohrozit funk£nost aplikace. 10 11 12

DRY - Don't Repeat Yourself Keep It Simple, Stupid! Model-View-Controller

http://nette.org/cs/licence> http://github.com/jquery/jquery/blob/master/GPL-LICENSE.txt> 15 16

13 14

< <

24

KAPITOLA 4.

NÁVRH EENÍ

Obrázek 4.1: Vztahy mezi komponentami MVC, zdroj: Jan Tichý

4.3.1.1 Model Model

reprezentuje jednotlivé entity reálného sv¥ta (který je

modelován ). Tato komponenta

tvo°í funk£ní a datový základ aplikace. Stará se o p°ístup k dat·m a manipulaci s nimi. Komponenta by m¥la mít p°esn¥ denované rozhraní pro ostatní komponenty. Nejniº²í vrstvu modelu tvo°í datové úloºi²t¥. Model bývá nej£ast¥ji implementován objektovými t°ídami (OOP).

4.3.1.2 View View

zobrazuje obsah Modelu. P°i zm¥n¥ v Modelu aktualizuje zobrazení. Události od uºi-

vatele p°edává Controlleru.

4.3.1.3 Controller Controller

denuje chování aplikace. Zpracovává vstupy a události p°icházející od uºivatele

(View) a následn¥ volá procesy Modelu. V závislosti na poºadavcích od uºivatele vybírá vhodn¥ View pro dal²í zobrazení.

4.3.2

Model aplikace

Model aplikace je rozd¥len do n¥kolika logických celk· za pomoci

jmenných prostor·.

krétn¥ takto:

• MapaInternetu • MapaInternetu\Entities

- jednotlivé entity v systému

• MapaInternetu\Entities\Address • MapaInternetu\Entities\Location

- reprezentace IP adres - reprezentace fyzického umíst¥ní

Kon-

4.3.

25

ARCHITEKTURA APLIKACE

• MapaInternetu\Exceptions • MapaInternetu\Services • MapaInternetu\Sources

- výjimky pro komunikaci v rámci aplikace

- sluºby pro aplikaci - zdroje dat

• MapaInternetu\Sources\Physical • MapaInternetu\Sources\Logical

- zdroje dat pro fyzickou lokalizaci

- zdroje dat pro logické umíst¥ní

4.3.2.1 Cachování dat Nejniº²í vrstvu modelu tvo°í úloºi²t¥ dat. Jako úloºi²t¥ dat je pouºit databázový systém MySQL. Pro p°ístup k databázi je vyuºita knihovna NotORM. Vzhledem k tomu, ºe se nejedná o systém ORM, stará se o mapování dat z databáze na objekty samotná aplikace. O cachování dat se stará sluºba

CacheService.

Obrázek 4.2: E-R model databáze

CacheService má na starosti také údrºbu databáze a snaºí se minimalizovat velikost databáze. K tomu vyuºívá sumarizaci. Sumarizace funguje tak, ºe men²í rozsahy IP adres (jednotlivé IP adresy mohou být povaºovány jako rozsah) seskupí a vytvo°í rozsah v¥t²í, který tyto rozsahy obsahuje. Viz kapitola 2.2. Sumarizace ke své funkci vyuºívá operace logické násobení, kdy bitový formát IP adres je vzájemn¥ logicky vynásoben. Vynásobením se získá spole£ná £ást, která reprezentuje adresu sít¥ spole£nou pro dané rozsahy. Sumarizovány do v¥t²ího celku jsou ty adresy, které mají stejné výsledky fyzického umíst¥ní. Do databáze se uloºí jen v¥t²í celek. Tímto zp·sobem se redukuje po£et záznam· v databázi - nap°. místo 256 záznam· je uloºen pouze 1.

26

KAPITOLA 4.

NÁVRH EENÍ

P°íkladem jsou sít¥ 10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16 a 10.3.0.0/16. V²echny tyto sít¥ mohou být reprezentovány jedinou adresou sít¥ 10.0.0.0/14. Sumarizace ov²em nepom·ºe v p°ípad¥, kdy má n¥jaký v¥t²í rozsah stejné výsledky týkající se umíst¥ní, ale n¥kolik IP adres uvnit° tohoto rozsahu má výsledky odli²né, takºe by p·vodní rozsah rozd¥lil na n¥kolik rozsah· men²ích. Pro optimalizaci tohoto zp·sobu ukládání výsledk· lze vyuºít procházení databáze podobn¥ jako routovacích tabulek od nejkonkrétn¥j²ího záznamu k obecn¥j²ímu (od nejdel²í masky sít¥ k nejkrat²í). Nap°íklad rozsah IP adres 10.0.0.0 10.255.255.255 lze sumarizovat do sít¥ 10.0.0.0/8, ale rozsah 10.2.3.0/24 má jiné fyzické umíst¥ní. Tento rozsah by p·vodní rozsah rozd¥lil do n¥kolika rozsah· a tím by do²lo k nár·stu záznam· v databázi. Sluºba nejd°íve na£te data pro rozsah 10.2.3.0/24 a aº poté zbytek rozsahu. V databázi jsou uloºeny pouze dva záznamy.

4.3.2.2 Rozhraní Pro t°ídy reprezentující IP adresu je rozhraní

IIPAddress,

které musí být implementováno.

V tomto rozhraní jsou denovány metody pot°ebné pro komunikaci s objektem reprezentující IP adresu. Díky tomuto rozhraní lze jednodu²e p°idat implementaci jiné verze IP protokolu a jeho adresaci. Rozhraní

IService

denuje metody, které musí kaºdá sluºba implementovat, aby s nimi

mohla aplikace komunikovat. Pro zdroje dat s informacemi o fyzickém umíst¥ní je p°ipraveno rozhraní

IPhysicalSource.

Aplikace dokáºe komunikovat se zdroji, které toto rozhraní implementují. Obdobné rozhraní existuje pro zdroje s daty o logické topologii. Toto rozhraní se jmenuje

ILogicalSource.

4.3.2.3 Sluºby O jednotlivé funkce systému se starají sluºby. Kaºdá sluºba implementuje rozhraní

IService.

Kaºdá sluºba má zodpov¥dnost za ur£itou funk£nost. Jakákoliv sluºba m·ºe být kdykoliv nahrazena jinou implementací. Tato zm¥na by nem¥la ohrozit funk£nost aplikace. V aplikaci se nachází tyto sluºby:

• CacheService

- Sluºba poskytující funkce cache. Ve²kerý p°ístup do databáze je veden

p°es tuto t°ídu. V této sluºb¥ je pouºita knihovna NotORM a mapují se zde databázová data na objekty.

• ILocationService

- Rozhraní pro sluºby, které se starají o získávání dat pro lokalizaci.

LogicalLocationService

- Sluºba pro získávání dat o logické topologii. Ve sluºb¥

jsou zaregistrované jednotlivé zdroje s daty o logické topologii IP adresy. S t¥mito zdroji sluºba pracuje.

PhysicalLocationService

- Sluºba pro získávání dat o fyzickém umíst¥ní. Ve sluºb¥

jsou zaregistrované jednotlivé zdroje s daty o fyzickém umíst¥ní IP adresy. S t¥mito zdroji sluºba pracuje.

4.4.

27

DÉMON

4.3.3

Prezenta£ní vrstva

Aplikace zobrazuje výsledky pomocí XHTML kódu jako webovou stránku. Aplikace p·jde p°epínat mezi zobrazováním fyzického umíst¥ní a logické topologie. Pomocí AJAX se na£ítají data pro kompletní zobrazení informací o poºadovaném rozsahu IP adres. Tato data server

17 a jsou p°edána JavaScriptu pro zpracování a zobrazení.

vrací ve formátu JSON

Uºivatel je informován o odhadovaném £asu, který je pot°eba pro na£tení v²ech pot°ebných informací (ETA). Informace ke kaºdému IP subnetu jsou na£ítány na pozadí. Aplikace se n¥kolikrát pokusí na£íst data ke kaºdému IP subnetu. Pokud p°ekro£í maximální po£et pokus·, za£ne na£ítat dal²í IP subnet. Maximální po£et pokus· je 30. Mapové podklady jsou zobrazovány pomocí JavaScriptu podle dokumentace [5]. Pomocí tohoto rozhraní jsou také do mapy zakreslovány jednotlivé body a vytvá°ena informa£ní okna. Zobrazení logické topologie je ve form¥ stromu. Cesta od stroje s aplikací k cílové IP je zobrazena pomocí obrázku generovaného aplikací ze zji²t¥ných dat.

4.4

Démon

Démon pro získávání dat pracuje ve vícevláknovém p°ístupu. V jeden okamºik je schopný spustit aº 20 vláken. Po£et vláken reguluje podle zatíºení serveru, které zjistí z

/proc/loadavg.

V p°ípad¥ p°íli² vysoké zát¥ºe démon v²echna vlákna ukon£í a £eká dokud zatíºení neklesne. Démon vyuºívá linuxového programu

wget

pro p°ístup k PHP skript·m na zji²óvání

pot°ebný dat.

17

http://www.json.org/>

JavaScript Object Notation - <

28

KAPITOLA 4.

NÁVRH EENÍ

Kapitola 5

Implementace Implementace aplikace prob¥hla podle analýzy (kap. 3) a návrhu aplikace (kap. 4). B¥hem implementace se objevily n¥které problémy a aplikace musela být upravena pro dosáhnutí optimální funk£nosti.

5.1

Pouºité nástroje

Aplikace byla implementována za pouºití standardních vývojá°ských nástroj·.

5.1.1

Opera£ní systém

P°i vývoji byl pouºit opera£ní systém Linux, distribuce Debian. OS Linux byl pouºit zejména pro jeho cenu - jedná se o voln¥ ²i°itelný opera£ní systém. V aplikaci jsou z OS Linux vyuºívány zejména programy

1 °ádek - shell bash . 5.1.2

wget, traceroute

a

whois. Dále je vyuºit interpret pro p°íkazový

Modelovací nástro je

Pro vytvo°ení diagram· do kapitol

Analýza a Návrh

byl pouºit program Enterprise Architect

a MySQL Workbench 5.2 CE. Pro modelování byl pouºit jazyk UML [19].

5.1.2.1 Enterprise Architect Enterprise Architect je kompletní nástroj pro systémovou analýzu a návrh. Tento nástroj pokrývá celý cyklus vývoje aplikací - od poºadavk·, p°es návrh model· aº po testování a údrºbu.

5.1.2.2 MySQL Workbench 5.2 CE MySQL Workbench [12] je nástroj pro návrh databázové struktury. Tento nástroj je k dispozici p°ímo od poskytovatele MySQL. 1

Bourne Again SHell

29

30

KAPITOLA 5.

5.1.3

IMPLEMENTACE

Vývojové prost°edí NetBeans

NetBeans [13] je open source vývojové prost°edí. Primárn¥ je ur£eno pro vývoj aplikací v jazyce Java, ale podporuje i dal²í programovací jazyky (nap°. PHP).

5.1.4

Verzovací systém Git

Git [4] je distribuovaný systém správy verzí, který byl p·vodn¥ vytvo°en pro vývoj linuxového jádra.

5.2

Problémy b¥hem implementace

5.2.1

Pam¥óvá náro£nost

P·vodní návrh aplikace, který umoº¬oval zji²óvání informací o velkém po£tu IP adres v rámci velkých rozsah·. Bohuºel pot°ebná pam¥´ se odvíjela od velikosti IP sít¥ (délky masky). Spot°eba pam¥ti exponenciáln¥ rostla v závislosti na délce masky. Z toho d·vodu bylo v systému zavedeno omezení po£tu sou£asn¥ zobrazovaných IP adres - maximum je

28

adres. P°i zadání IP subnetu jsou zji²óvány informace o odpovídajících

2

subnetech "men²í t°ídy" , neº zadaný IP subnet.

/9, aplikace zji²úje informace o 128 odpovída/16. V p°ípad¥ zadání subnetu s maskou /4, zji²újí se informace o 16 odpovídajících subnetech s maskou /8. Nap°.: P°i zadání IP subnetu s maskou

jících subnetech s maskou

5.2.2

asová náro£nost

asová náro£nost se projevovala u získávání údaj· o jednotlivých IP adresách. Rozdíly v dob¥ trvání získávání informací o IP adresách se r·znily v °ádech desítek sekund. V nejhor²ích p°ípadech zji²t¥ní informací trvalo více neº 5 minut. V rámci prezenta£ní vrstvy je uºivatel informován o nejhor²í odhadované délce £asu pot°ebného pro získání v²ech pot°ebných informací. Tento £as je pomocí jednoduchého vzorce

t = n ∗ t0 .

• t

2

- celkový £as

• n

- po£et zbývajících IP adres k na£tení

• t0

- pr·m¥rný £as na£tení 1 IP adresy

Rozd¥lení do t°íd je zobrazeno v tabulce 6.2

5.3.

31

NASAZENÍ APLIKACE

Obrázek 5.1: Aplikace: Informování uºivatele o zbývajícím £ase pro na£tení

5.2.3

Výpo£etní náro£nost

Z d·vod· velké výpo£etní náro£nosti aplikace nepouºívá v cachování výsledk· metodu

marizace

IP adres do v¥t²ích celk·. Jeden IP subnet se nachází aº v

32 sítích.

su-

Nár·st vý-

po£etního zatíºení databázového serveru je b¥hem vyhledávání IP subnetu p°íli² vysoký. Sumarizací by se u²et°il úloºný prostor o n¥kolik desítek kB na 100 IP adres, coº nep°iná²í velkou výhodu.

5.3

Nasazení aplikace

Následující diagram znázor¬uje výslednou strukturu aplikace spolu se znázorn¥ním komunikace, která probíhá mezi jednotlivými £ástmi systému.

Obrázek 5.2: Diagram nasazení

32

KAPITOLA 5.

IMPLEMENTACE

Kapitola 6

Záv¥r Prvním cílem této práce bylo prozkoumat r·zné ve°ejn¥ dostupné zdroje dat pro fyzickou lokalizaci IP adres a pokusit se rekonstruovat logickou topologii £ásti sít¥. V rámci práce bylo prozkoumáno n¥kolik zdroj·, konkrétn¥ databáze WHOIS, MaxMind GeoLite City, IPInfoDB a výstup programu traceroute. Jako dal²í zdroj byl prozkoumán systém doménových jmen DNS. Tento zdroj se ov²em neosv¥d£il jako relevantní. Zdroje celkov¥ nejsou p°esné, ale celkem správn¥ umísóvaly IP adresy na úrovni stát·, pop°. kraj·. Výstup programu traceroute poskytl relevantní data pro rekonstrukci topologie zadaného subnetu. Bohuºel není moºné zjistit ve²keré propoje v rámci sít¥, ale pouze cestu k jednotlivým prvk·m v síti z pohledu externího pozorovatele. Sí´ se jeví jako £erná sk°í¬ka, pokud není pozorovatel p°ímo uvnit°.

Obrázek 6.1: Aplikace: Zobrazení logické topologie IP sít¥

33

34

KAPITOLA 6.

ZÁVR

Dal²ím cílem práce bylo vytvo°ení aplikace, která implementuje prozkoumané zdroje a poskytne webové rozhraní pro její vyuºití. Aplikaci se poda°ilo vytvo°it, ale s n¥kterými nedostatky. Volba jazyka PHP, ve kterém byla aplikace implementováno, nebyla nejvhodn¥j²í. Jazyk PHP se hodí pro dynamické webové stránky, ale není p°íli² vhodný na psaní aplikací, které pot°ebují pracovat více s opera£ním systémem. Nevýhoda byla v interpretaci soubor· aplikace p°es webový server. Bohuºel jazyk PHP nemá velkou podporu IP protokol·. Velká výzva byla napsání démona v jazyce PHP. Z d·vod· interpretace jazyka PHP ve webovém serveru byla zvolena kombinace PHP + linuxový interpret bash. Tyto problémy by ²ly vy°e²it pouºitím jiného programovacího jazyka, bliº²ího opera£nímu systému - nap°. C++. Na druhou stranu se poda°ilo vytvo°it aplikaci modulární. Celkem jednodu²e lze p°idávat dal²í zdroje s daty pro lokalizaci IP adres. O n¥co sloºit¥ji lze p°idávat zdroje pro logickou topologii. Díky modularit¥, které bylo dosaºeno díky architektu°e MVC, m·ºe být snadno vym¥n¥na prezenta£ní vrstva aplikace. Implementace jiné verze IP protokolu (nap°. IPv6) a jeho adresace je také moºná díky objektovému návrhu aplikace. Díky knihovn¥ NotORM je moºné snadno zm¥nit datové úloºi²t¥.

6.1

Statistika

B¥hem zji²óvání informací o jednotlivých IP adresách byla vytvá°ena statistika o délce trvání tohoto zji²óvání. V následujících tabulkách jsou nam¥°ené hodnoty týkající se £as· a velikosti databáze. Hodnoty jsou odhadované z aktuálních minimálních/maximálních/pr·m¥rných hodnot uloºených v databázi.

1 IP V²echny IP Pouºitelné IP

Pouºitelné IP

Minimum

0.772 s

105 let

90,8 let

2 861 382 105 s

Maximum

324.853 s

44 242,5 let

38 180,3 let

1 204 052 540 135 s

19.342 s

2 634,2 let

2 273,3 let

71 690 223 675 s

Pr·m¥r

Tabulka 6.1: Statistika £asové náro£nosti - jednovláknový p°ístup Tabulka ukazuje, jak dlouho by trval sb¥r dat pro ve²keré IP adresy a pro ve²keré ne-

1 IP adresy. Tabulka uvaºuje jednovláknový p°ístup. V optimálním p°ípad¥ - p°i

vyhrazené

vyuºití v²ech vláken - by hodnoty mohly být n¥kolikanásobn¥ niº²í. Tabulka uvaºuje pr·m¥rnou velikost dat na 1 IP adresu. Pr·m¥r je vypo£ítaný z celkové velikosti databázových tabulek a vyd¥lením po£tem IP adres uloºených v databázi. S rostoucím po£tem IP adres v databázi se tento pr·m¥r m·ºe li²it v závislosti na uloºených fyzických lokalitách v databázi £i sloºitosti logické topologie

6.2

Moºnosti pokra£ování

Práce nabízí n¥kolik moºností, jak na práci navázat. Do aplikace lze implementovat dal²í zdroje pro zji²óvání fyzického umíst¥ní, £i logické topologie. Dal²í moºností je implementace 1

Nevyhrazených IP adres je celkem 3 706 453 504. Celkem je 4 294 967 296 IP adres.

6.2.

35

MONOSTI POKRAOVÁNÍ

Po£et IP Velikost tabulek v B Velikost tabulek v MB Komentá° 1

195 B

0,19 kB

1 000

194 409 B

189,85 kB

5 117

994 789 B

0,95 MB

1 000 000

194 408 638 B

185,40 MB

3 706 453 504

720 566 577 055 B

687 185,84 MB

pouºitelné IP

4 294 967 296

834 978 741 727 B

796 297,78 MB

v²echny IP

Tabulka 6.2: Statistika velikosti datového úloºi²t¥

protokolu IPv6, na který je aplikace p°ipravena. Nejv¥t²í moºností pokra£ování je ov²em optimalizace aplikace. Démon na zji²óvání dat by mohl být p°epsán do jiného jazyka s lep²ím vyuºitím vícevláknového p°ístupu. V aplikaci by mohlo být vytvo°eno ve°ejné programové rozhraní a aplikace by mohla být zp°ístupn¥na ve°ejnost.

36

KAPITOLA 6.

ZÁVR

P°íloha A

Seznam pouºitých zkratek AJAX API AS

Asynchronous JavaScript and XML

Application Programming Interface, programové rozhraní aplikace

Autonomous Systém, autonomní systém

CIDR CSS

Classless Inter-Domain Routing, mechanizmus adresování sítí

Cascading Style Sheets

DNS

Domain Name System, systém doménových jmen

DRY

Don't Repeat Yourself

IANA

Internet Assigned Numbers Authority, http://www.iana.org/

ICMP

Internet Control Message Protocol

IP

Internet Protocol

ISP

Internet Service Provider

KISS LIR

Keep It Simple, Stupid

Local Internet Registry

HTTP MVC NIR

RIR TLD

Model View - Controller

National Internet Registry

ORM RFC

Hypertext Transfer Protocol, protokol pro vým¥nu hypertextových dokument·

Object-Relational Mapping, objektov¥-rela£ní mapování Request for Comments, ozna£ení standard· popisující internetové protokoly

Regional Internet Registry Top Level Domain, doména nejvy²²ího °ádu

37

38

TTL VPN

PÍLOHA A.

Time-to-live Virtual Private Network

WHOIS XHTML XML

SEZNAM POUITÝCH ZKRATEK

Who is?, TCP protokol eXtensible HyperText Markup Language

Extensible Markup Language, roz²i°itelný zna£kovací jazyk

P°íloha B

Poºadavky aplikace Opera£ní systém: Webový server:

Linux, interpret

bash

Apache 2, PHP

Databázový server:

MySQL 5

Ostatní aplikace: whois, traceroute, wget B.1

PHP

Verze:

5.3

Roz²í°ení:

mod_gd, mod_curl, mod_mysql

Limit b¥hu:

300 s

Limit pam¥ti: Ostatní:

alespo¬ 500 MB

povolení funkce

exec

39

40

PÍLOHA B.

POADAVKY APLIKACE

P°íloha C

Obrázky aplikace

Obrázek C.1: Aplikace: Zobrazení fyzického umíst¥ní - sít¥ t°ídy A v Evrop¥

41

42

PÍLOHA C.

OBRÁZKY APLIKACE

Obrázek C.2: Aplikace: Zobrazení fyzického umíst¥ní - sít¥ t°ídy A v Severní Americe

43

Obrázek C.3: Aplikace: Zobrazení logické topologie - £ást rozsahu rozsahu klubu Silicon Hill

44

PÍLOHA C.

OBRÁZKY APLIKACE

P°íloha D

Obsah p°iloºeného CD . |-| | | | | | | |-| |-| | | |--

application |-- app |-- document_root |-- libs |-- log |-- temp |-- var models |-- MapaInternetu.eap text |-- src | |-- figures |-- text.pdf readme.txt

-

aplikace vlastní aplikace adresá° p°ístupný z web pro p°ístup k aplikaci knihovny log soubory do£asné soubory, cache zdrojových soubor· dal²í soubory pot°ebné pro b¥h aplikace (nap°. externí zdroje)

- Enterprise Architect projekt - modely -

zdrojové TeX soubory s textem bakalá°ské práce obrázky k bakalá°ské práci text bakalá°ské práce popis obsahu CD

45

46

PÍLOHA D.

OBSAH PILOENÉHO CD

Literatura [1] TICHý, J.

Programová podpora tvorby webových aplikací - architektura aplikace.

http://www.jantichy.cz/diplomka/pozadavky/architektura,

25. 8. 2004.

[2] VRáNA, J. NotORM - PHP library for simple working with data in the database, .

http://www.notorm.com/,

stav z 1. 5. 2011.

[3] VRáNA, J. NotORM je rychlej²í neº Doctrine 2 i dibi, .

http://php.vrana.cz/notorm-je-rychlejsi-nez-doctrine-2-i-dibi.php, 27. 7. 2010. [4] web:git. Git - fast version control system.

http://git-scm.com/,

stav z 18. 5. 2011.

[5] web:googlemaps. Google Maps.

http://code.google.com/intl/cs-CZ/apis/maps/,

stav z 1. 5. 2011.

[6] web:html. HTML & CSS.

http://www.w3.org/standards/webdesign/htmlcss,

stav z 1. 5. 2011.

[7] web:iana. Internet Assigned Numbers Authority.

http://www.iana.org/numbers/,

stav z 1. 5. 2011.

[8] web:ipinfodb. IP InfoDB.

http://www.ipinfodb.com/,

stav z 1. 5. 2011.

[9] web:jquery. jQuery - JavaScript Library.

http://jquery.com/,

stav z 1. 5. 2011.

[10] web:maxmind. MaxMind GeoLite City.

http://www.maxmind.com/app/geolitecity, [11] web:mysql. MySQL.

http://www.mysql.com/,

stav z 1. 5. 2011.

[12] web:mysql:workbench. MySQL Workbench.

http://wb.mysql.com/,

stav z 18. 5. 2011.

[13] web:netbeans. NetBeans.

http://netbeans.org/,

stav z 18. 5. 2011.

47

stav z 1. 5. 2011.

48

LITERATURA

[14] web:nette. Nette Framework.

http://nette.org/,

stav z 1. 5. 2011.

[15] web:php. PHP: Hypertext Preprocessor.

http://www.php.net/,

stav z 1. 5. 2011.

[16] web:rfc1035. RFC 1035.

http://www.faqs.org/rfcs/rfc1035.html/,

listopad 1987.

[17] web:rfc1393. RFC 1393.

http://www.faqs.org/rfcs/rfc1393.html/,

leden 1993.

[18] web:rfc3912. RFC 3912.

http://www.faqs.org/rfcs/rfc3912.html/, [19] web:uml. Object Management Group - UML.

http://www.uml.org/,

stav z 18. 5. 2011.

zá°í 2004.

Na tomto míst bude ociální zadání va²í práce

Recommend Documents