W OPARCIU O RUCH HTTPusers.pja.edu.pl/~s2294/Mapa.pdf · 2007. 10. 28. · Mapa polskiej sieci...

Warszawa 2002

MAPA POLSKIEJ SIECI ROZLEGŁEJ

W OPARCIU O RUCH HTTP

A D A M S U J K A N R A L B U M U 1 3 4 6

P I O T R D Y N I A N R A L B U M U 1 4 8 6

P R A C A I N Ż Y N I E R S K A N A P I S A N A P O D K I E R U N K I E M

M G R A D A M A W I E R Z B I C K I E G O

Mapa polskiej sieci rozległej w oparciu o ruch HTTP

2

S P I S T R E Ś C I

1 . W S TĘP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 . M I A R Y W Y D A J N OŚC I I J A K OŚC I S I E C I W A N . . . 5

2 . 1 . N A T Ę Ż E N I E R U C H U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 . 2 . O P Ó Ź N I E N I E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 . 3 . N I E Z A W O D N O ŚĆ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 . 4 . P R Z E P U S T O W O ŚĆ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 . 5 . S Z E R O K O Ś Ć P A S M A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 . 6 . S T O P I EŃ W Y K O R Z Y S T A N I A P A S M A . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 . P R Z E G LĄD D O S TĘP N Y C H N A R ZĘD Z I . . . . . . . . . . . . . . 8

4 . C H A R A K T E R Y S T Y K A N A R ZĘD Z I

W Y K O R Z Y S T A N Y C H P R Z Y P O M I A R A C H . . . . . . . . 1 3

4 . 1 . P I N G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 4 . 1 . 1 . O P I S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 4 . 1 . 2 . S Z C Z E G Ó Ł Y P A K I E T U I C M P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 4 . 1 . 3 . Z D U P L I K O W A N E I U S Z K O D Z O N E P A K I E T Y . . . . . . . . . . . . . . . . . . . . . . . 1 4 4 . 1 . 4 . S Z C Z E G Ó Ł Y T T L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 4 . 1 . 5 . B Ł Ę D Y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4

4 . 2 . T R A C E R O U T E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 5 4 . 2 . 1 . O P I S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 5 4 . 2 . 2 . S K Ł A D N I A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 5 4 . 2 . 3 . P R Z Y K Ł A D O W E Z A S T O S O W A N I E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 6

4 . 3 . P L A N K T O N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8 4 . 3 . 1 . O P I S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8 4 . 3 . 2 . W Y K A Z F U N K C J I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8

5 . U Z A S A D N I E N I E ( P L U S Y I M I N U S Y ) W Y B R A N Y C H T E C H N I K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1

5 . 1 . O G R A N I C Z E N I A B E Z P I E C Z E Ń S T W A S E R W E R Ó W . . . . . . . . . 2 1

5 . 2 . O G R A N I C Z E N I A W Y N I K A JĄC E Z B R A K U

W Y S T A R C Z A JĄC Y C H D A N Y C H U Z Y S K A N Y C H Z P O M I A R Ó W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1


3

5 . 3 . Z A L E T Y I W A D Y W Y N I K A JĄC E Z C E N Y B ĄD Ź S P O S O B U

D Y S T R Y B U C J I N A R Z ĘD Z I P O M I A R O W Y C H . . . . . . . . . . . . . . . . . 2 2

6 . O B J AŚN I E N I E M E T O D P O M I A R Ó W . . . . . . . . . . . . . . . . 2 3

6 . 1 . L O G I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3

6 . 2 . A D R E S Y I P 5 0 N A J C Z Ę ŚC I E J W Y S T Ę P U J ĄC Y C H

K L I E N T Ó W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3

6 . 3 . S K R Y P T Y C G I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4

6 . 4 . O P I S D Z I A ŁA N I A I W Y K O R Z Y S T A N I E . . . . . . . . . . . . . . . . . . . . . . 2 5

7 . O M Ó W I E N I E O T R Z Y M A N Y C H W Y N I K Ó W . . . . . . . . 2 6

7 . 1 . " S U R O W E " W Y N I K I T R A C E R O U T E . . . . . . . . . . . . . . . . . . . . . . . . . . 2 6

7 . 2 . D A L S Z E P R Z E T W A R Z A N I E W Y N I K Ó W . . . . . . . . . . . . . . . . . . . . . . 2 6

7 . 3 . P O Ł Ą C Z E N I E W S Z Y S T K I C H ŚC I E Ż E K W J E D E N G R A F . . 2 7

7 . 4 . G E N E R A C J A P L I K U D O P L A N K T O N A . . . . . . . . . . . . . . . . . . . . . . 2 8

7 . 5 . S T A T Y S T Y K I : I L O Ś Ć P O M I A R Ó W Z G W I A Z D K A M I ,

D ŁU G O ŚC I ŚC I E Ż E K , I L O Ś Ć SĄ S I A D Ó W . . . . . . . . . . . . . . . . . . . 3 1

7 . 6 . M A P A I J E J O P I S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6

8 . P R Z Y KŁA D O W E Z A S T O S O W A N I A . . . . . . . . . . . . . . . . . . 3 9

8 . 1 . B U F O R O W A N I E S T R O N W W W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 9

8 . 2 . O B R A Z O W A N I E R U T I N G U W S I E C I A C H . . . . . . . . . . . . . . . . . . . . 3 9

8 . 3 . I N Ż Y N I E R I A R U C H U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 9

8 . 4 . S Y M U L A T O R Y S I E C I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 0

9 . P O D S U M O W A N I E / Z A K OŃC Z E N I E . . . . . . . . . . . . . . . . 4 1

1 0 . Z AŁĄC Z N I K I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2

1 0 . 1 . S P I S S E R W E R Ó W W W W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2

1 0 . 2 . P R Z Y K Ł A D L I S T U , K T Ó R Y Z O S T A Ł R O Z E S Ł A N Y D O

A D M I N I S T R A T O R Ó W S E R W E R Ó W . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3

1 0 . 3 . P L A K A T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4

1 0 . 4 . A D R E S P R O J E K T O W E J S T R O N Y W W W . . . . . . . . . . . . . . . . . . . . . 4 5

1 1 . B I B L I O G R A F I A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6


4

1 . W S TĘP

Światowa sieć komunikacyjna Internet działa w oparciu o tzw. Zasadę best-effort.

Oznacza to, że wędrujące w sieci pakiety mogą napotkać na swojej drodze szereg

nieprzewidywalnych i często niedających się kontrolować przeszkód. Warunki te

opisywane są przez szereg miar, takich jak częstość strat pakietów, opóźnienia

w przesłaniu pakietu, przepustowość dostępną i maksymalną dla protokołu TCP i wiele

innych. Rozwój narzędzi służących do dokładnego i szybkiego a zarazem taniego

badania tych zmiennych ma duże znaczenie dla rozwoju aplikacji działających

w Internecie. Rozwój ten ma i będzie miał wpływ na szybkość oraz kierunek rozwoju

samego Internetu, sposobów projektowania sieci oraz budowy symulatorów.

Praca nasza podzielona została na dwie części. W pierwszej części opisujemy narzędzia

pomiarowe wykorzystywane obecnie, niejednokrotnie będące jeszcze we wczesnym

stadium rozwoju, oraz narzędzia wykorzystane przez nas podczas przeprowadzonych

pomiarów. W drugiej części zawarliśmy opis i prezentację eksperymentu pomiarowego,

który miał na celu stworzenie przykładowej mapy polskiego Internetu,

a przynajmniej jego części. Zamieszczone tutaj również zostały wyniki, jakie

uzyskaliśmy podczas analizy danych zgromadzonych w czasie trwania eksperymentu.


5

2 . M I A R Y W Y D A J N OŚC I I J A K OŚC I S I E C I W A N Jakość sieci WAN można ocenić, stosując wiele różnych miar (metryk). Wiele z nich

można uznać za obiektywne, inne metryki należy uznać za mniej obiektywne lub niemal

niemożliwe do wcześniejszego oszacowania. Niektóre z bardziej rozpowszechnionych

metryk to:

natężenie ruchu

opóźnienie i czas oczekiwania

niezawodność

straty

przepustowość

szerokość pasma

stopień wykorzystania pasma

Każda z tych metryk jest szczegółowo omówiona w dalszej części rozdziału.

2.1. Natężenie ruchu

Jedną z ważniejszych metryk sieci WAN jest natężenie obsługiwanego ruchu. Natężenie

to zmienia się w czasie zależnie od cyklu pracy przedsiębiorstw, pór roku i innych

czynników. Jak każdą zmieniającą się wielkość mierzyć je można wieloma miarami

statystycznymi, z których najważniejszymi są wartość średnia i wartość maksymalna.

Maksymalne natężenie, jakie występuje w sieci, nazywane jest również natężeniem

szczytowym. Jak wskazuje nazwa jest to największe zaobserwowane nasilenie ruchu.

Średnie natężenie jest natężeniem przeciętnie występującym w sieci.

2.2. Opóźnienie

Jest jedną z częściej stosowanych metryk odzwierciedlających wydajność sieci.

Odpowiada ona odcinkowi czasu oddzielającemu dwa zdarzenia. W przypadku

wymiany informacji zdarzenia te z reguły oznaczają wysłanie i odebranie danych.

Dlatego opóźnienie jest czasem potrzebnym na przesłanie w sieci pakietu z punktu

źródłowego do docelowego. Przy takiej definicji opóźnienie jest zjawiskiem

sumarycznym, uzależnionym od wielu czynników, miedzy innymi zależy od:

Czasu propagacji: termin ten odnosi się do łącznego czasu wymaganego na przesłanie

(propagację) danych przez wszystkie urządzenia transmisyjne sieci znajdujące się na


6

ścieżce transportu. Wydajność i ilość tych urządzeń transmisyjnych ma bezpośredni

wpływ na sumaryczne opóźnienie każdej transmisji. Dodatkowym czynnikiem

wpływającym na czas propagacji jest natężenie ruchu. Im bardziej obciążone jest dane

urządzenie transmisyjne, tym mniejsza szerokość pasma dostępna dla nowej transmisji.

Opóźnienia w przesyłaniu: opóźnienie w przesyłaniu przez sieć jest łącznym czasem

potrzebnym na odebranie, buforowanie, przetwarzanie i przesłanie danych przez każde

fizyczne urządzenie. Rzeczywiste opóźnienie w przesyłaniu każdego urządzenia może

zmieniać się w czasie. Urządzenia, które pracują przy niemal maksymalnym obciążeniu,

mają zwykle większe opóźnienia w przesyłaniu niż porównywalne urządzenia o małym

obciążeniu. Ponadto wartości opóźnień mogą dodatkowo wzrastać z powodu zbyt

dużego obciążenia lub błędów pracy sieci. Opóźnienia w przesyłaniu często nazywane

są czasem oczekiwania poszczególnych składników.

Opóźnienia mierzymy:

w jedną stronę – ile czasu dane potrzebują na przebycie drogi od jednego hosta

do drugiego

w dwie strony – czas potrzebny na przebycie trasy od hosta A do B i na powrót.

Czas transmisji danych od hosta A do B może być inny od czasu transmisji od

hosta B do A i zależy np.: od konfiguracji rutingu w sieci.

średnie – uśredniony wynik z wielu pomiarów

maksymalne – maksymalna wartość zbadana podczas pomiarów

minimalne – minimalna wartość otrzymana podczas pomiarów

2.3. Niezawodność

Odnosi się do skuteczności każdego łącza (określanego liczbą przekłamanych bitów).

Niektóre łącza mogą ulegać uszkodzeniom częściej od innych. Po uszkodzeniu sieci

niektóre łącza można naprawić szybciej i łatwiej niż inne.

2.4. Przepustowość

Przepustowość jest to ilość danych jaką łącze może przesłać w określonej jednostce

czasu. Im większa przepustowość, tym szybsza transmisja danych. Wyróżniamy

przepustowość dostępną – zależną od ilości ruchu oraz ilości połączeń na ścieżce.


7

2.5. Szerokość pasma

Odnosi się do dostępnej pojemności ruchu w określonym łączu. Zazwyczaj maksymalna

liczba bitów, które mogą być przesyłane siecią w jednostce czasu, mierzona jest w bps.

Termin pochodzi z elektroniki gdzie szerokość pasma reprezentuje całkowity dystans

miedzy najwyższym i najniższym sygnale w kanale komunikacyjnym. Szerokość pasma

reprezentuje pojemność łącza. Im większa szerokość, tym większa wydajność łącz.

Szerokość zależy od wielu czynników miedzy innymi opóźnienia i natężenia ruchu.

2.6. Stopień wykorzystania pasma

Możliwe jest również monitorowanie wykorzystania pasma.

Wykorzystanie to zwykle jest wyrażane procentowym zużyciem szerokości pasma. Na

przykład, jeśli stosowane jest łącze T-1, wykorzystanie jego 30% oznacza, że aktualnie

jest wykorzystywana taka właśnie część dostępnego pasma o szerokości 1,544 Mbps.

Wskaźniki te mogą być trudne do przeanalizowania a czasami mogą być wręcz mylące.

Na przykład: często zdarza się, że oprogramowanie zarządzające siecią pobiera

informacje na temat wykorzystania zasobów co pewien okres czasu. Może to być

godzina, pięć minut lub dowolny inny czas. Jeśli częstotliwość próbkowania jest zbyt

mała (w stosunku do dynamiki zmian), krótkotrwałe wahania wykorzystania pasma

mogą być gubione. Z kolei zbyt częste próbkowanie może doprowadzić do powstania

ogromnej ilości nieistotnych informacji. Sztuka polega na dobraniu odpowiedniej

częstotliwości, pozwalającej na zebranie istotnych danych na temat działania sieci w

stosunku do oczekiwań użytkownika.


8

3 . P R Z E G LĄD D O S TĘP N Y C H N A R ZĘD Z I W poniższej tabelce zebrane zostały dostępne narzędzia pomiarowe służące do celów

omówionych w poprzednim rozdziale. Zestawienie opiera się na opracowaniu [1].

Kolorem pomarańczowym wyróżnione zostały narzędzia komercyjne.

Tabela I: Narzędzia pomiarowe Nazwa Dane

wejściowe Pomiar Wyjście

Metoda Funkcje Zakres czasowy

Topologia sieci (BGP)

Jaspvi BGP4(ipv4) i BGP4+ (ipv6) tablica rutingu

Pasywna Wyświetlą topologie BGP

Różne, bazujące na dziennych logach

Graf połączeń BGP

Pomiar w skali makro Clevertools GeoBoy

Dane z pomiarów ruchu Pasywna Geograficzne śledzenie ścieżek Brak

Ścieżka do hosta na grafie 2D lub 3D

skitter Monitorowane ścieżki Aktywna Geograficzne śledzenie ścieżek Różne

Różne w zależności od konfiguracji

Pomiar w skali mikro otter Zestaw wezlow lub

scieżek Pasywna Różne Różne Różne

Analiza pakietów (Sprzętowa)

HP/Agilent Advisor LAN lub WAN Obie Aktualne wykorzystywane pasmo; rtt,

straty pakietów, generowany ruch

Pomiar jednokrotny bądź stale próbkowanie

Dane dla HP/Agilent software

InMon sFlow Probe 1000Base-SX Obie Pomiar przepływu Czas

rzeczywisty Cisco NetFlow v5/ InMon sFlow

LinkView 10BaseT, 100BaseTx Obie

Dystrybucja pasma, ramek, błędy pakietów, generator ruchu, topologia graficzna

Czas rzeczywisty Raport

Shomiti Explorer

10/100/Giga Ethernet Pasywna Przechwytywanie pakietów Czas

rzeczywisty Dane do dalszej obróbki

Sniffer Pro 10/100 Ether LAN; GigaEther; ATM; Obie

Przechwytywanie pakietów, wykorzystanie pasma, wykorzystanie protokołów, błędy pakietów i ramek, generator ruchu

Czas rzeczywisty, analiza logów w przedziałach od 1 sekundy do 1 dnia

GUI

Analiza pakietów (Programowa) Clevertools PacketBoy

TCP/IP, IPX, Appletalk, Banyan, DECNET

Pasywna Przechwytywanie pakietów Czas rzeczywisty, analiza logów

Windows lub Unix GUI

Ethereal

Ethernet, FDDI, PPP, token-ring, X.25, IP over ATM, tcpdump (libpcap), różne analizatory pakietów

Pasywna Dystrybucja protokołu

Czas rzeczywisty lub analiza logów

Unix GUI

EtherPeek

Ethernet, Fast Ethernet, or Gigabit Ethernet NIC (Windows 95/98/NT)

Obie

Przechwytywanie pakietów, wykorzystanie pasma przez węzły lub protokoły, filtracja pakietów, generator pakietów, różne “wtyczki”

Analiza logów GUI, statystyki w HTML

ettercap Switched LAN

Pasywna + kilka aktywnych komend

Analiza ruchu na ścieżkach, przechwytywanie haseł, fingerprint OS, zamknięcie połączenia

Czas rzeczywisty Tekst

HP/Agilent Reporter LAN/WAN/ATM Pasywna Obciążenie, przepustowość, protokół Różne Tabele, wykresy,

raport


9

hping ICMP echo, TCP, UDP, ICMP and RAW-IP protocols

Aktywna

Analiza pakietów TCP/IP, analiza firewall, skaner portów; testy sieci, obsługa wielu protokołów TOS, fragmentacja, wyznaczanie MTU


LanExplorer

Ethernet, Fast Ethernet, or Gigabit Ethernet NIC (Windows 95/98/NT)

Pasywna

Przechwytywanie pakietów, wykorzystanie przepustowości, wykorzystanie protokołów, rozmiar pakietów

Logi GUI

LANQuest Net/WRx

IP, Ethernet, GigaEther, Token ring, FDDI

Obie Przepustowość, opóźnienie, straty Czas rzeczywisty GUI

Shomiti Surveyor

10/100/1000 Ethernet; 4/16 Token Ring

Obie Analiza siedmiu warstw Różne GUI

Sniffer Basic 10/100 Ether LAN, 4/16 token ring Obie

Przechwytywanie pakietów, przepustowość, wykorzystane protokoły, kontrola błędów, generowanie ruchu

Czas rzeczywisty, analiza logów w przedziałach od 1 sekundy do 1 dnia

GUI

Analiza ruchu argus Pliki z danymi lub

analiza rzeczywista Pasywna połączenia, pojemność , straty, opóźnienie, wahania, wydajność


ASPath

Tablica adresów IP (adres nadawcy i odbiorcy), numer portu, protokół, przedział czasowy

Pasywna Wykorzystanie zasobów W zależności od konfiguracji

Tekst – w postaci tabeli

cflowd Dane eksportowane z ruterów CISCO

Pasywna Analiza przepływu, wydajność

Testy w stałych odstępach czasu

Tabela sumaryczna

Clevertools EtherBoy LAN Pasywna Przepustowość, wykorzystanie

protokołów Czas rzeczywisty

Windows lub Unix GUI

CoralReef ATM (OC3/12) live feed Pasywna Wydajność, analiza przepływu

Przedziały czasowe w regularnych odstępach

Strony http

Cricket Przedziały czasowe Pasywna Analiza ruchu

Przedział pięcio minutowy

http GUI

InMon Traffic Server

Dane importowane z ruterów CISCO, dane z innych urządzeń (ruterów, przełączników)

Pasywna Wydajność, analiza przepływu

Czas rzeczywisty (przedziały minutowe), logi (przedziały godzinne)

http

NetFlow Dane importowane

z ruterów CISCO Pasywna Wydajność, analiza przepływu W zależności od konfiguracji Dane do obróbki

Orca Plik tekstowy Pasywna Czasowe wykresy i dystrybucja cron job collects data HTML, pliki PNG

TAAD

Dane zbierane

przez OC3mon

Pasywny monitor

sieci

Pasywna Identyfikuje problem na podstawie pomiarów przepływu

W zależności od konfiguracji

Tabela sumaryczna

Analiza SNMP Compaq TeMIP

SNMP, Q3/CMIP, CORBA, ATM, Sonet/SDH

Pasywna Monitor ruchu, pomiar wydajności Czas rzeczywisty

GUI or web pages

NeTraMet SNMP Pasywna Zmiany ruchu, rozmiary pakietów, wykorzystanie protokółów, czas „turnaround”

Rożne – oparte na regułach

GUI

NetSCARF/Scion SNMP MIBs Pasywna Wszelkiego rodzaju statystyki Różne Web pages

Pomiar wydajności aplikacji OPNET IT Guru / ACE

RMON probes, ślady pakietów, próbki RMON,

Obie Opóźnienie, wahania , straty, czas odpowiedzi, retransmisje Różne

Windows / UNIX GUI, grafy, rapotr WWW


10

dane bezpośrednio z sieci, pliki konfiguracyjne ruterów

CompuWare EcoScope

LAN, WAN, GigaEther Obie

Rozkład zużycia pasma, czas odpowiedzi, wielkość ruchu, transfer klient - serwer

Dzienny, tygodniowy, miesięczny

Windows GUI

Optimal Application Expert

Bezpośrednio sieci, analizatory protokołów RMON lub RMON2

Obie Czas odpowiedzi, obciążenie, analiza czasowa Różne Windows GUI

Clevertools WebBoy LAN, strony www Pasywna

Statystyki ruchu www, ilość odpytanych adresów URL, ilość zapytań, protokoły internetowe

Czas rzeczywisty GUI

Pomiar pasma i przepustowości

bing

Porównanie RTTs z ICMP/ECHO z pakietami innego rozmiaru

Aktywna Pasmo Czas rzeczywisty

Przepustowość (bps)

{b|c}probe ICMP/ECHO Aktywna Pasmo, przeciążenie Czas rzeczywisty Tekst

clink

Pakiet UDP z limitem TTL, ICMP błąd odpowiedzi, ICMP/ECHO odpowiedź

Aktywna Pasmo Czas rzeczywisty Tekst

iperf TCP i UDP Aktywna Pasmo, opóźnienie, wahania strat Czas rzeczywisty Tekst lub GUI

netperf Generator obciążenia Aktywna Przepustowość, opóźnienia end-to-

end Czas rzeczywisty Tekst

nettimer Zestaw pakietów Obie Przechwytywanie pakietów Czas rzeczywisty

Surowe dane, dane w formacie ns trace

pathchar UDP, ICMP Obie Pasmo, przepustowość, opóźnienie, straty


pathrate Dane bazujące na UDP Aktywna Pojemność absolutna pasma

(wykrywanie „wąskich gardeł”) Czas rzeczywisty

Pojemność całkowita (zakres między max a min zbadanym)

pchar UD, ICMP Obie Pasmo, przepustowość, opóźnienie, straty


SProbe Adres IP drugiego końca ścieżki Aktywna Wykrywanie „wąskiego gardła” w obu

kierunkach Logi Tekst

TReno

Pakiet UDP z limitem TTL, ICMP błąd odpowiedzi, ICMP/ECHO odpowiedź

Obie Pasmo Czas rzeczywisty

Grafy gnuplot oraz ppmtogif

ttcp and nttcp Generator Aktywna Przepustowość Czas

rzeczywisty Tekst

Viznet Rzeczywiste dane z sieci bądź logi wygenerowane przez Netlog

Pasywna Wizualizacja pasma

Czas rzeczywisty Animacja czasu

rzeczywistego

Forward Path Probes

GTrace UDP z limitem TTL, ICMP z limitem czasowym

Obie Opóźnienie, osiągalność

Czas rzeczywisty

Mapa, nazwa, adres IP, RTT każdego skoku na ścieżce

mtr ICMP ECHO Aktywna Jakość łącza, osiągalność Czas rzeczywisty Graficzne, tekst

Nikhef traceroute

UDP z limitem TTL; ICMP z limitem czasowym

Aktywna Opóźnienie, osiągalność, straty pakietów

Czas rzeczywisty

Statystyka, adres, nazwa każdego skoku

pingplotter ICMP Echo/Reply Aktywna Osiągalność, procent straty pakietów Czas rzeczywisty Graf

traceroute UDP z limitem TTL, ICMP z limitem czasowym

Aktywna Opóźnienie, osiągalność, straty pakietów

Czas rzeczywisty

Nazwa i adres każdego hosta na ścieżce

WhatRoute UDP z limitem TTL, ICMP z limitem czasowym

Obie Opóźnienie, osiągalność Czas rzeczywisty

Mapa, adres hopów, Mac adres

Xtraceroute UDP z limitem TTL, ICMP z limitem Aktywna Osiągalność Czas

rzeczywisty Wykres na mapie świata


11

czasowym Monitorowanie “chmury internetowej” Narus Intelligence SNMP Pasywna Monitorowanie serwisów IP oraz ich

wykorzystania Różne Informacje o ruchu

NIKSUN NetVCR, NetReporter, NetDetector

SNMP Pasywna

Pomiar ruchu, czas odpowiedzi aplikacji, wielkość retransmisji, straty na ścieżce, przepustowość, szerokość pasma

Różne Informacje o ruchu

“Pogoda internetu”

for News hosts Ping Aktywna

Straty pakietów z U Oregon exchange point do ponad stu serwerów news

30 minut

Status, procentowe straty pakietów, min/śred/max

Andover Internet Traffic Report

Ping Aktywna Globalny ruch w internecie, RTT, straty pakietow 15 minut

Graf indeksowany (0-100)

Serwisy internetowe prowadzące testy wydajności KeyLabs Strona http Aktywna Testy porównawcze serwerow www Różne GUI

Keynote Perspective

Dane zgromadzone z około ~50 lokalizacji na świecie

Aktywna

Czas dostepu, opóźnienia, testy dla: całego serwisu, pojedynczej strony, kilku różnych stron, również serwisy zabezpieczone hasłem

15 minut, godzina, dzień, miesiąc

Interfejs http MyKeynote

ServiceMetrics SM-WEB

Dane ze światowych i lokalnych agentów pomiarowych

Aktywna Czas odpowiedzi, osiągalność, wydajność

1-15 godzin, 24 godziny GUI

KeyLabs Strona http Aktywna Testy porównawcze serwerów www Różne GUI Monitorowanie dostawców internetowych BrixWorx software

Pomiary Brix100 lub Brix1000 Verifiers

Obie Testy end-to-end pomiędzy hostami weryfikującymi

Czas rzeczywisty

GUI http lub programy kontrolujące

Brix 1000 Verifier

Testy aktywne ruchu w sieci Aktywna

Pomiary wydajności od ISP, opóźnienia w jedną i obie strony, wahania, aktualna przepustowość dla poszczególnych aplikacji (np.: POP, SMTP, DNS, NNTP, RTP, H.323, HTTP, HTTPS)

Czas rzeczywisty, synchronizacja do milisekund

BrixWorx GUI http, interfejs lini polecen, SNMP agent v1, SNMP MIB II, Ethernet MIB, EtherStats

Brix 100 Verifier

Aktywne i pasywne testy ruchu w sieci Obie

Pomiary wydajności od ISP, opóźnienia w jedną i obie strony, wahania, aktualna przepustowość dla poszczególnych aplikacji (np.: POP, SMTP, DNS, NNTP, RTP, H.323, HTTP, HTTPS)

Czas rzeczywisty

BrixWorx GUI http, interfejs linii poleceń, SNMP agent v1, SNMP MIB II, Ethernet MIB, EtherStats

Brixnet Managed Service

Pomiary Brix100 lub Brix1000 Verifiers

Obie

Testy end-to-end, testy ruchu pomiędzy macierzą agentów monitorujących, testy w sieci bazującej na IP

Czas rzeczywisty

BrixWorx GUI http

Nettest TCP/UDP Aktywna Wykorzystuje Iperf bądź testy dostarcza użytkownik

Zależny od testów NetLogger

Wykorzystanie odnośników internetowych

IPTraf Linux net stats Pasywna

Połączenia TCP, licznik pakietów / bitów, statystyka aktywności interfejsów, procentowy rozkład ruchu TCP/UDP

Różne Konsola

libpcap Dane z monitora sprzętowego Pasywna Przechwytywanie pakietów Rożne Plik

tcpdump Bazujące na libpcap Pasywna Przechwytywanie pakietów Rożne Plik

tcpdpriv Bazujące na libpcap Pasywna Przechwytywanie pakietów Rożne Plik

Symulatory sieci (Planowanie) dummynet Interpretacja

pakietów Aktywna Zarządzanie pasmem Czas rzeczywisty Symulacja ruchu

OPNET Modeler

Próbki RMON, śledzenie pakietów, dane z sieci, pliki konfiguracyjne ruterów

Obie Opóźnienie, wahania, straty, czas dopowiedzi, czas retransmisji, prognozowanie, analizy wydajności

Rożne Windows / UNIX GUI, grafy, raport www

OPNET IT Guru / ACE

Próbki RMON, śledzenie pakietów, dane z sieci, pliki konfiguracyjne

Obie Opóźnienie, wahania, straty, czas odpowiedzi, czas retransmisji, prognozowanie, analizy wydajności



12

ruterów

ServiceProvider Guru

Próbki RMON, śledzenie pakietów, dane z sieci, pliki konfiguracyjne ruterów

Obie

Opóźnienie, wahania, straty, czas odpowiedzi, czas retransmisji, prognozowanie, analizy wydajności, zautomatyzowane projektowanie sieci


Testy dostępności w jedna stronę echoping ICMP Echo/Reply Aktywna Osiągalność, opóźnienie, straty

pakietów Czas rzeczywisty Tekstowe

fping ICMP Echo/Reply Aktywna Osiągalność wielu hostów, opóźnienie, straty pakietów


gnuplotping ICMP Echo/Reply Aktywna Osiągalność wielu hostów, opóźnienie, straty pakietów

Czas rzeczywisty

Gnuplot graf zawierający rozkład opóźnienia

Imeter ICMP Echo/Reply Aktywna Ping z długim czas oczekiwania Rożne Graf na stronie www

Nikhef ping ICMP Echo/Reply Aktywna

Osiągalność, opóźnienie, straty pakietów


ping ICMP Echo/Reply Aktywna

Osiągalność, opóźnienie, straty pakietów


sting TCP Pasywna Straty pakietów w jedna stronę Czas rzeczywisty Tekst

Traceping Dane z ping i traceroute Aktywna Straty pakietów



13

4 . C H A R A K T E R Y S T Y K A N A R ZĘD Z I

W Y K O R Z Y S T A N Y C H P R Z Y P O M I A R A C H .

4.1. Ping

4.1.1. Opis

Narzędzie ping używa obowiązkowego datagramu ICMP o nazwie ECHO_REQUEST,

wywołującego ICMP ECHO_RESPONSE od hosta lub bramki. Datagramy

ECHO_REQUEST (``pingi'') składają się z nagłówka IP oraz ICMP, oraz czasu

wysłania pakietu i wypełnienia do określonego rozmiaru pakietu. Program ten jest

przeznaczony do testowania sieci, pomiarów i zarządzania nią. Z powodu obciążenia,

jakie może wywołać w sieci, używanie pinga w skryptach może być niebezpieczne.

Należy uniemożliwić dostęp do skryptu niepowołanym osobom.

Ping oblicza czasy podróży i statystyki utraty pakietów. Jeśli odbierane są pakiety

zduplikowane to nie są one włączane do obliczeń strat pakietów, choć ich czas podróży

jest używany do obliczania minimalnego/średniego/maksymalnego czasu podróży.

Po nadaniu (i odebraniu) określonej liczby pakietów, lub po zakończeniu programu,

wyświetlane jest krótkie podsumowanie. Jeśli ping nie odbierze żadnych pakietów

odpowiedzi, to zakończy działanie z kodem wyjścia 1. W przypadku błędu kod ten

wynosi 2. W przeciwnym razie zwracane jest 0. Umożliwia to używanie kodu wyjścia

do sprawdzania czy hosty „żyją”.

4.1.2. Szczegóły pakietu ICMP

Nagłówek IP bez opcji ma 20 bajtów. Pakiet ICMP ECHO_REQUEST zawiera

dodatkowych 8 bajtów nagłówka ICMP, za którymi następuje określona ilość danych.

Gdy podany jest rozmiar pakietu, to określa on rozmiar dodatkowego bloku danych

(domyślnie 56). Tak więc ilość danych znajdujących się wewnątrz pakietu IP typu

ICMP ECHO_REPLY jest zawsze 8 bajtów większa niż żądana ilość danych (nagłówek

ICMP). Jeśli rozmiar danych ma wielkość przynajmniej 8 bajtów, to ping używa

pierwszych 8 bajtów do włączania pieczątki czasowej, której używa do obliczeń czasów

podróży. Jeśli podano mniej niż 8 bajtów wypełnienia to nie są podawane czasy

podróży.


14

4.1.3. Zduplikowane i uszkodzone pakiety

Ping zgłasza pakiety uszkodzone i zduplikowane. Pakiety zduplikowane nigdy nie

powinny się pojawiać i prawdopodobnie są powodowane przez nieprawidłowe

retransmisje poziomu połączenia (link-level). Mogą się one pojawiać w wielu

sytuacjach i rzadko są dobrym znakiem, choć obecność niewielkiej liczby duplikatów

nie zawsze musi być powodem do alarmu.

Pakiety uszkodzone często wskazują na uszkodzenie sprzętu na drodze pakietu pinga.

4.1.4. Szczegóły TTL

Wartość TTL pakietu IP reprezentuje maksymalną liczbę ruterów IP, którą pakiet może

minąć nim zostanie wyrzucony. W obecnej sytuacji można oczekiwać, że każdy ruter

internetowy zmniejsza wartość TTL o jeden. Specyfikacja TCP/IP określa, że pole TTL

pakietu TCP powinno być ustawione na 60, lecz wiele systemów używa mniejszych

wartości (4.3 BSD używa 30, 4.2 używało 15). Maksymalna możliwa wartość tego pola

to 255 i większość systemów Unixowych ustawia wartość TTL pakietów ICMP

ECHO_REQUEST na 255. W normalnym działaniu ping drukuje wartości TTL

odbieranych pakietów.

4.1.5. Błędy

Wiele hostów i bram ignoruje opcję RECORD_ROUTE.

Maksymalna długość nagłówka IP jest zbyt mała dla całkowitej użyteczności opcji w

rodzaju RECORD_ROUTE. Jednak praktycznie nie można z tym nic zrobić.

Szybkie pingowanie (flood pinging) nie jest ogólnie zalecanie a w szczególności

pingowanie adresu rozgłoszeniowego.

Listing I: Przykładowe wykorzystanie narzędzia ping #!/bin/sh # Skrypt pingujący zadany adres echo "Content-type: text/html"; echo ""; # w razie potrzeb prosze podac odpowiednia sciezke nice /bin/ping -i 2 -c 100 $1

Opis na podstawie [12].


15

4.2. Traceroute

4.2.1. Opis

Traceroute jest narzędziem śledzącym trasy, którymi podążają pakiety w sieci.

Traceroute wykorzystuje pole TIME TO LIVE protokołu IP i próbuje wydobyć

odpowiedź ICMP TIME_EXCEEDED od każdej bramki na drodze do określonego

hosta. Jedynym wymaganym parametrem jest nazwa hosta docelowego lub jego adres

IP. Domyślny próbny datagram ma długość 38 bajtów, lecz może to być zwiększone

przez podanie rozmiaru pakietu za nazwą hosta docelowego.

Program ten próbuje śledzić trasę pakietów IP, którą pakiet przebyłby do danego hosta

internetowego. Czyni to wysyłając próbki UDP z mała wartością TTL (time to live) a

następnie nasłuchując od bramki odpowiedzi ICMP "time exceeded". Próbkowanie

rozpoczyna się z TTL o wartości jeden i zwiększane jest aż program otrzyma

odpowiedź ICMP "port unreachable" oznaczającą maksimum TTL, bądź osiągnięciu

hosta (domyślne maksimum odpowiada 30 skokom i może być zmienione flagą -m ).

Dla każdego TTL wysyłane są trzy próbki (zmieniane flagą -q ), czego efektem jest

zwrócenie przez program linijki pokazującej TTL, adres bramki i zaokrąglony czas

podróży każdej z próbek. Jeśli odpowiedzi próbek przyszły z różnych bramek to zostaną

wydrukowane adresy wszystkich odpowiadających systemów. Jeśli nie było odpowiedzi

podczas 3 sekundowego interwału (określanego jako `timeout' i zmienianego flagą -w )

to dla danej próbki drukowane jest "*".

Nie chcemy by docelowy host przetwarzał próbki pakietów UDP, więc docelowy port

jest ustawiany na wartość niespotykaną (jeśli jednak na hoście docelowym port ten jest

wykorzystywany wartość tą można zmienić flagą -p).

4.2.2. Składnia

traceroute [-m max_TTL] [-n] [-p port] [-q nqueries] [-r] [-s src_addr] [-t tos] [-w

waittime] host [packetsize]


16

4.2.3. Przykładowe zastosowanie

Listing II: Przykładowy skrypt wykorzystujący traceroute #!/bin/sh # Skrypt trauceroutujacy zadany adres echo "Content-type: text/html"; echo ""; # w razie potrzeb prosze podac odpowiednia sciezke nice /usr/sbin/traceroute "$1" Listing III: Dane zwrócone podczas pomiaru serwera www.onet.pl 1 host49-121.datastar.pl (62.89.121.49) 1.397ms 1.412ms 1.642ms 2 host209-117.datastar.pl (62.89.117.209)7.817ms 6.205ms 8.024ms 3 cs-to-cs2.waw.cdp.pl (213.134.142.33) 6.964ms 6.374ms 6.632ms 4 waw-to-atman.cdp.pl (213.134.128.62) 6.857ms 7.141ms 9.421ms 5 pozman-do-atman.oc3.p.pol34.pl(193.111.36.38) 41.403ms 11.980ms 13.021ms 6 z-poznan-gw.wroc.krakow.622.pol34.pl 212.191.224.122) 20.985ms 33.849ms 26.436ms 7 gwk.cyfronet.krakow.pl (195.150.1.179) 130.118ms 200.828ms 198.920ms 8 muzrtr.cyfronet.krakow.pl (195.150.1.237) 69.600ms 24.108ms 23.615ms 9 z-cyfronetu.onet.pl (195.150.96.2) 67.241ms 29.723ms 26.700ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *


17

Począwszy od bramki 10 kolejne albo nie przesyłają komunikatów ICMP

TIME_EXCEEDED lub przesyłają je z TTL zbyt małym by osiągnąć nasz serwer.

Bardzo powszechnym powodem występowania „gwiazdek” jest również błąd w

implementacji kodu sieciowego występujący w systemach BSD (i pochodnych) systemy

te wysyłają komunikaty używając TTL pozostałego w oryginalnych datagramach.

Odpowiedź nie dojdzie z powrotem, ponieważ przekroczy zadany czas (timeout) na

drodze powrotnej (bez wysyłania ostrzeżeń do kogokolwiek, bo dla ICMP nie są

wysyłane komunikaty ICMP). Istnieje możliwość ominięcia tego błędu, jeśli użyjemy

TTL długości co najmniej dwa razy większej niż długość ścieżki. Jednak ze względu na

bardzo duże obciążenie sieci, jakie generuje tracerout, w naszych pomiarach nie

mogliśmy sobie pozwolić na każdorazowe korekty wartości TTL oraz częste

powtórzenia.

Opis na podstawie [13].


18

4.3. Plankton

4.3.1. Opis

Plankton został zaprojektowany do wizualizacji hierarchii schowków www. Ale jest to

również uniwersalny algorytm wizualizacji złożonych sieci, co przy odpowiednim

zmodyfikowaniu danych wejściowych pozwala wykorzystać go do zobrazowania

węzłów oraz ścieżek naszej mapy. Używamy pewnych specyficznych cech: root są

wyznaczane na podstawie badań ilości sąsiadów, jeśli liczba ta przekroczy 7 to węzeł

jest oznaczany jako root. W zależności od ilości węzłów algorytm wizualizacyjny

oblicza ich rozmieszczenie, począwszy od miejsca centralnego mapy.

Opis składni pliku wejściowego znajduje się rozdziale: 7.4. „Generacja pliku do

Planktona”.

4.3.2. Wykaz funkcji

W tabeli poniżej zawarte zostały funkcje apletu Plankton, które dostępne są dla

użytkowników. Funkcje te wprowadzają element interakcji, umożliwiają np.:

powiększanie, przesuwanie oraz całkowite przetwarzanie otrzymanego wykresu

względem wybranych elementów. Ponadto możliwe jest wyrysowanie mapy w

połączeniu z mapą geograficzną świata. Jednak, aby element ten był aktywny w danych

dostarczonych do przetworzenia, powinny być zawarte długość i szerokość

geograficzna. Dane takie są dostarczane np. przez narzędzie VisualRoute ™ firmy

Visualware INC. Aktualnie zakres informacji o terytorium Polski ogranicza się

praktycznie do Warszawy a pozostałe miasta są pominięte. Z tego względu funkcja ta

nie jest aktywna.

Tabela II: Dostępne funkcje API Plantkona Lista funkcji

Komenda Opis File

Clear Network Czyści wszystkie węzły oraz ścieżki aktualnie wyświetlane Clear World Map Czyści mapę świata aktualnie wyświetlaną Redraw Network Generuje nową mapę z pliku z danymi Center Network Środkuje wyświetlane węzły i ścieżki


19

Load Network Wyszukuje w katalogu wszystkie pliki z danymi, następnie wyświetla listę, z której użytkownik może wybrać plik do wczytania

Load World Map Wczytanie mapy. Animation Wczytanie wielu plików z danymi Exit Zamknięcie Planktona

Interaction

Select Object Pozwala użytkownikowi wybrać jeden węzeł, następnie można trzymając wciśnięty przycisk myszy przesuwa węzeł w obrębie wyświetlacza

Select Tree Zaznaczanie całego drzewa węzłów wraz z potomkami Deselect All Objects Deselekcja wszystkich zaznaczonych obiektów

Select Root Zamienia węzeł w węzeł główny (root) bądź węzeł główny w zwykły węzeł

Select Root by Name

Wybiera wszystkie węzły zawierające tekst w swojej nazwie i zamienia je w węzły

Move Pozwala na przemieszczanie całej mapy Auto Arrange Automatyczne rozmieszczenie węzłów Step by Step Pozwala zaobserwować jak jest hierarchicznie budowana mapa

View Topological Arrange Ustawia węzły w zależności od położenia topologicznego

Geographical Arrange

Ustawia węzły w zależności od położenia geograficznego, jeśli jest dostarczona długość i szerokości geograficzna w pliku z danymi

Topological / Geographical Wyświetla oba rozkłady w jednym oknie

Low resolution Przedstawia ścieżki jako linie proste High resolution Przedstawia ścieżki jako linie trójkątne Show All names Wyświetla nazwy wszystkich węzłów Show Root names Wyświetla nazwy węzłów głównych Show No names Wyłącza wyświetlanie nazw

Tool Zoom Przeskalowanie mapy Rotate Obrót mapy Line Size Zmiana grubości ścieżek Node Size Zmiana wielkości węzłów

Color by Top Level Domain Name

Tworzy przypisania odpowiednich kolorów do domen, następnie koloruje mapę w zależności od domeny


20

Mask/Color by HTTP Request Koloruje węzły i ścieżki w zależności od ilości odpytań HTTP

Default Colors Zamiana kolorów węzłów i ścieżek na standardowe Help

Commands Opis dostępnych komend About Informacje o Planktonie Overview Informacje o aktualnej mapie Opis na podstawie [2]


21

5 . U Z A S A D N I E N I E ( P L U S Y I M I N U S Y ) W Y B R A N Y C H

T E C H N I K

5.1. Ograniczenia bezpieczeństwa serwerów

Eksperyment pomiarowy polegał na zbadaniu szeregu logów z serwerów WWW, a

następnie zbadaniu tras między tymi serwerami a klientami łączącymi się z nimi.

Powodzenie eksperymentu zależało w dużej mierze od życzliwości osób

administrujących serwerami WWW. Narzędzia musiały być dostosowane do wymogów

bezpieczeństwa komercyjnych serwerów oraz pomiary nie mogły naruszać polityki

bezpieczeństwa poszczególnych firm. Te uwarunkowani ograniczyły rodzaj narzędzi,

jakie mogły być wykorzystywane w eksperymencie, jak również rodzaj wykonywanych

pomiarów. Ograniczenia te spowodowane są faktem, iż większość narzędzi

wymienionych w punkcie 3, wymaga praw użytkownika uprzywilejowanego, a na tak

daleko idąca przychylność ze strony osób uczestniczących w pomiarach nie mogliśmy

liczyć. Na badanych serwerach musiały być zainstalowane i uruchomione skrypty

wybierające dane z logów serwera jak również skrypty wykonujące pomiary. Do

przeprowadzenia pomiarów wybraliśmy narzędzia, które nie wymagały do poprawnego

działania konta uprzywilejowanego użytkownika, były to: ping, traceroute oraz skrypt

wybierający interesujące nas dane z logów serwera. Skrypty dostarczone przez nas

administratorom musiały być chronione przed niepowołanym dostępem ze względu na

możliwość przeprowadzenia dzięki nim ataków typu DoS.

5.2. Ograniczenia wynikające z braku wystarczających danych

uzyskanych z pomiarów

Kolejnym ograniczeniem, jaki wynikało ze specyfikacji naszych pomiarów oraz

serwerów, na których pomiary były dokonywane była ilość pomiarów, jakie mogliśmy

wykonać. Serwery te w większości są komercyjnie wykorzystywane przez

użytkowników sieci i ich administratorzy nie mogli pozwolić sobie na zbyt intensywne

wykorzystanie swojego pasma przez skrypty dostarczone przez nas. Z tego powodu

przyjęliśmy ograniczenie w liczbie hostów, jakie były odpytywane przez skrypty do 50

oraz ilości pomiarów do 100.


22

Ze względu na przyjęte ograniczenia w ilości zarówno pomiarów i badanych hostów

często podczas przeprowadzania testów otrzymywaliśmy niekompletne ścieżki.

Spowodowane jest to konfiguracją ruterów występujących na ścieżce częstym

występowaniem serwerów proxy, bądź konfiguracją skryptów pomiarowych. Brak

możliwości przeprowadzenia większej ilości testów nie pozwolił na wyeliminowanie

błędnych odpytań.

Bardzo ważnym zagadnieniem ze względu na kompletność danych, na których

operowaliśmy był czas. Aby eksperyment był miarodajny należało przeprowadzić testy

w jednym czasie na wielu serwerach. Jak wcześniej okazało się, profil działalności

naszych testowych hostów nie pozwolił na jednoczesne wykonanie prób ze wszystkich

zaplanowanych przez nas serwerach. Dane, jakie uzyskaliśmy nie pokrywały się i

należało kilkakrotnie powtarzać testy.

5.3. Zalety i wady wynikające z ceny bądź sposobu dystrybucji narzędzi

pomiarowych

Bezpieczeństwo oraz zasoby nie były jedynymi czynnikami ograniczającymi zasób

naszych narzędzi. Problemem, którego nie udało nam się ominąć były względy

finansowe. Wiele narzędzi jest dystrybuowanych na zasadzie płatnych licencji bądź

składek członkowskich, płaconych na rzecz różnych projektów. Niejednokrotnie opłaty,

jakie należy wnieść na rzecz producenta sięgają 50 000 USD. Z tego oraz innych

względów postanowiliśmy skorzystać z oprogramowania darmowego, dostępnego w

sieci, między innymi na serwerach CAIDA.


23

6 . O B J AŚN I E N I E M E T O D P O M I A R Ó W

6.1. Logi

Dane do badania postanowiliśmy pobrać z logów dostępu (access_log) serwerów

WWW, z których administratorami udało nam się nawiązać współpracę. Aby dane były

jak najbardziej jednorodne, pochodzą z tego samego okresu. Datą, którą wybraliśmy do

przeprowadzenia doświadczenia był 13 maja 2002. Aby zachować anonimowość

użytkowników, niezbędne było zastosowanie dodatkowych skryptów, które usuwały z

logów nieistotne dane. Skrypty pozostawiały tylko adresy IP klientów, usuwały

natomiast adresy URL żądane przez klientów. Zabieg ten miał również na celu znaczne

zmniejszenie rozmiarów plików, jakie otrzymaliśmy od administratorów (w przypadku

niektórych serwerów logi z jednego dnia zajmowały kilka gigabajtów).

6.2. Adresy IP 50 najczęściej występujących klientów

Jako zadowalającą ilość danych uznaliśmy 50 adresów IP najczęściej pojawiających się

w logach w zadanym okresie czasu. Do obróbki użyliśmy bardzo prostego i wydajnego

programu wykorzystującego język skryptowy bash oraz awk.

Listing IV: Kod skryptu "top50": #!/bin/bash if [ -z $1 ] then echo "top50: brak parametru wejsciowego" echo "Sposob uzycia skryptu: ./top50 access_log plik_wyjsciowy"else if [ -z $2 ] then echo "top50: brak parametru wyjsciowego" echo "Sposob uzycia skryptu: ./top50 access_log plik_wyjsciowy" else cat $1 | awk '{print$1}' | sort | uniq -c | sort -rn | head -50 | awk '{print $2}' >> $2 fi fi

Skrypt pobiera dwa parametry. Pierwszy to wejściowy plik logu (access_log) a drugi

jest wyjściowym plikiem, w którym znaleźć się mają przetworzone dane.


24

6.3. Skrypty CGI.

Kolejnym etapem doświadczenia było zdobycie informacji na temat ścieżek rutingu

pomiędzy serwerami a klientami WWW, którzy zostali wybrani z logów w poprzednim

etapie. Dane te postanowiliśmy pobrać za pomocą ogólnie znanych narzędzi ping i

traceroute. Ponieważ interesowały nas ścieżki od serwerów do klientów biorących

udział w projekcie, programy te musiały być uruchomione zdalnie. Aby nie angażować

w to administratorów napisaliśmy dwa skrypty CGI, za pomocą których sami mogliśmy

zebrać dane. Ze względu na ich przeznaczenie skrypty są bardzo przejrzyste a ich

instalacja polega jedynie na zapisaniu w odpowiednim katalogu oraz nadaniu praw

wykonywania. Przejrzystość skryptów znacznie podniosła ich wiarygodność,

upewniając administratorów, że skrypty nie naruszają bezpieczeństwa serwerów. Oto

kod wymienionych skryptów.

Listing V: traceroute.cgi #!/bin/sh # Skrypt trauceroutujacy zadany adres echo "Content-type: text/html"; echo ""; # w razie potrzeb prosze podac odpowiednia sciezke nice /usr/sbin/traceroute "$1"

Listing VI: ping.cgi #!/bin/sh # Skrypt trauceroutujacy zadany adres echo "Content-type: text/html"; echo ""; # w razie potrzeb prosze podac odpowiednia ścieżkę nice /bin/ping -i 2 -c 100 $1


25

6.4. Opis działania i wykorzystanie.

Skrypt traceroute.cgi wykonuje pojedynczy traceroute do hosta o zadanym adresie.

Skrypt ping.cgi wykonuje 100 pingów w odstępach co 3 sekundy do hosta o zadanym

adresie.

Dane ze skryptu traceroute.cgi pobieraliśmy poprzez program wget.

Przykładowo, aby zbadać ścieżkę z http://noname.ueuro.net do hosta o adresie IP

212.76.40.94 wystarczyło podać :

Listing VII: WGET komenda pobrania

wget http://noname.ueuro.net/cgi-bin/traceroute.cgi?212.76.40.94

Niestety z powodów technicznych nie mogliśmy pobrać danych (ping i traceroute) ze

wszystkich serwerów jednocześnie. Fakt ten sprawia, że dane z ping.cgi nie

umożliwiają porównania warunków panujących na wszystkich ścieżkach.


26

7 . O M Ó W I E N I E O T R Z Y M A N Y C H W Y N I K Ó W .

7.1. "Surowe" wyniki traceroute.

Z powodu prostoty skryptów dane wyjściowe nie są w żaden sposób formatowane.

Utrudnia to ich analizę w przeglądarce internetowej, lecz znacznie ułatwia dalszą

obróbkę otrzymanych plików. (Nie trzeba usuwać zbędnych znaczników HTML)

Listing VIII: Przykład uzyskanego wyniku: 1 host49-121.datastar.pl (62.89.121.49) 3.414 ms 1.561 ms 1.463 ms 2 host209-117.datastar.pl (62.89.117.209) 257.179 ms 285.133 ms 240.024 ms 3 cs-to-cs2.waw.cdp.pl (213.134.142.33) 296.508 ms 249.728 ms 217.549 ms 4 cdp.wix.waw.cdp.pl (213.134.128.10) 262.123 ms 235.131 ms 271.587 ms 5 astercity.gix.net.pl (157.25.1.148) 311.905 ms 290.365 ms 293.388 ms 6 * * * 7 moc-gw.astercity.net (212.76.32.154) 205.746 ms 363.994 ms 172.321 ms 8 94-moc1.acn.waw.pl (212.76.40.94) 264.714 ms 290.832 ms 177.108 ms

7.2. Dalsze przetwarzanie wyników

Ponieważ dane otrzymane z traceroute.cgi zawierają szereg informacji nie potrzebnych

nam w badaniu, należało je zmodyfikować. W tym przypadku również posłużyliśmy się

prostym skryptem bash i awk.

Listing IX: Kod "ip" #/bin/bash awk '{print $3}' $1 > ip_$2

Po powyższej obróbce każdego pliku otrzymaliśmy zbiór plików następującej postaci:

ip_*.


27

Listing X: Zawartość przykładowego pliku ip_* (10.1.0.23) (193.42.228.33) (213.248.76.1) (213.248.69.93) (213.248.64.137) (213.248.64.29) (213.248.64.34) (213.248.74.6) (195.66.225.14) (154.32.101.2) (146.101.0.2) (146.101.0.18) * * * * * *

7.3. Połączenie wszystkich ścieżek w jeden graf.

Do łączenia wszystkich węzłów ścieżkami w celu uzyskania jednolitego grafu

wykorzystujemy programu należącego do http://www.caida.org Plankton. Wymusza to

przygotowanie danych wejściowych o ściśle określonym formacie.

Listing XI: Przykład pliku wejściowego: d 2002 08 30 t 839 T 1285 n 0 146.188.9.146 n 3 213.248.64.57 n 4 202.0.170.45 r n 5 193.59.202.82 n 6 212.191.0.18 n 8 158.43.111.42 n 9 213.158.195.25 n 28 144.232.9.110 r N 29 chgen0101-tc-p3-0.kpnqwest.net n 605 203.97.7.69 n 33 129.250.2.168 n 42 213.186.73.58 n 43 212.2.102.173 N 44 atm2-2-305-kat-cr1-kat-pb1.devs.futuro.pl n 46 195.205.0.130 r n 47 194.42.48.12 n 48 213.248.66.58 . .


28

.

. l 330 234 240 l 331 234 701 l 332 234 728 l 333 235 836 l 334 236 267 l 335 236 474 l 336 238 745 l 337 240 808 l 338 241 801

Opis zawartości:

Plik składa się z trzech części

Pierwsza zawiera:

d - data wygenerowania pliku

t - liczba wszystkich węzłów grafu

T - Liczba wszystkich krawędzi grafu

Druga część ma postać:

n lub N id węzła IP lub nazwa węzła opcjonalnie r

n - kiedy podajemy IP węzła

N - kiedy podajemy nazwę węzła

r - kiedy węzeł jest tzw. root'em (większym węzłem

w grafie oznaczanym na czerwono).

Trzeci człon wygląda następująco:

l id połączenia id węzła1 id węzła2

7.4. Generacja pliku do Planktona

W celu scalenia wszystkich danych w jeden plik formatu Planktona napisaliśmy

program. Posłużyliśmy się językiem programowania Python (http://www.python.org).

Program jako argument pobiera listę plików ip_*, następnie tworzy dwa zbiory

elementów. Pierwszy to lista wszystkich węzłów grafu wraz z wyszczególnieniem ich

sąsiadów. Drugi to lista połączeń między węzłami. Na obu tych listach przeprowadzane

są operacje mające na celu uzyskanie pliku o formacie opisanym w poprzednim

podrozdziale.


29

Listing XII: Kod programu "plankton_data": #pokazuje liste wezlow z iloscia sasiadow print "Przygotowuje dane do Planktona:" import sys import string D={} dl=len(sys.argv) for a in range(1, dl): fin = open(sys.argv[a]) s = fin.read() l = string.split(s, "\n") l = l[:-1] j=0 for i in range(len(l)): x = l[i] if(x <> "*"): r=x r=r[-1:] if(r == ")"): x=x[1:-1] if(r == "\015"): x=x[1:-2] l[j]=x j=j+1 for i in range(len(l)-1): ip1=l[i] ip2=l[i+1] if (ip1 <> "*"): if(ip1 in D.keys() and ip2 not in D[ip1] and ip2 <> "*"): D[ip1].append(ip2) if(ip1 not in D.keys() and ip2 <> "*"): D[ip1]=[] D[ip1].append(ip2) if(ip2 in D.keys() and ip1 not in D[ip2]): D[ip2].append(ip1) if(ip2 not in D.keys() and ip2 <> "*"): D[ip2]=[] lista={} licz=0 sasiedzi=[] ile=0 for i in D.keys(): lista[i]=[] lista[i].append(licz) lista[i].append(len(D[i])) licz=licz+1 if(len(D[i])>0):


30

ile=ile+1 for i in D.keys(): while j < len(D[i]): z=[i, D[i][j]] if(z not in sasiedzi): sasiedzi.append(z) j=j+1 j=0 fout=open("/home/dziobak/projekt/Data/plankton.fvl","w") x="#plik z danymi do planktona\n" fout.write(x) x="d 2002 08 30\n" fout.write(x) x="t "+`len(lista)-1`+"\n" fout.write(x) x="T "+`len(sasiedzi)`+"\n" fout.write(x) ile=0 for i in lista.keys(): ilosc=lista[i][1] if (ilosc > 0): r=i r=r[-1:] if(len(r)>0): if(r in string.digits): if(ilosc > 6): x="n "+`lista[i][0]`+" "+i+" r\n" else: x="n "+`lista[i][0]`+" "+i+"\n" else: if(ilosc > 6): x="N "+`lista[i][0]`+" "+i+" r\n" else: x="N "+`lista[i][0]`+" "+i+"\n" fout.write(x) j=0 while j < len(sasiedzi): e=sasiedzi[j] e1=e[0] e2=e[1] x="l "+`j`+" "+`lista[e1][0]`+" "+`lista[e2][0]`+"\n" fout.write(x) j=j+1 fout.close() print "Done."

Map

a po

lski

ej si

eci r

ozle

głej

w o

parc

iu o

ruch

HTT

P

31

7.5.

Stat

ysty

ki: i

lość

pom

iaró

w z

gw

iazd

kam

i, dł

ugoś

ci śc

ieże

k, il

ość

sąsi

adów

W

ykre

s I: I

lość

gw

iazd

ek

130 4

20

01

0 1

0 2

0 3

34

22

41

23

27

97

31

30

11

00

0 0

0 0

00

00

00

01

00

00

00

02

12

11

61

00

1 0

0

13

0 20

40

60

80

100

120

140

02

46

8 10

12

1416

1820

2224

2628

3032

34

3638

4042

4446

4850

5254

5658

60

62

liczb

a gw

iazd

ek

Ilość

Map

a po

lski

ej si

eci r

ozle

głej

w o

parc

iu o

ruch

HTT

P

32

W

ykre

s II:

Dłu

gośc

i ści

eżek

0 0

01

36

2 6 17

15 20

15 16

36

42

21

22

02

10

10

03

0

68

00

00

0 0

00

00

00

00

00

00

00

00

00

00

00

00

0 0

0 18

0 10

20

30

40

50

60

70

80

0 2

46

8 10

12

14

1618

2022

2426

2830

3234

36

38

4042

4446

4850

5254

5658

6062

64

dł

ugość

ilość

Map

a po

lski

ej si

eci r

ozle

głej

w o

parc

iu o

ruch

HTT

P

33

10

34

28

822

3263

454

83

050100

150

200

250

300

350

400

450

500

12

34

56

78

910

1112

sąsi

edzi

ilość

W

ykre

s III

: Lic

zba

sąsi

adów

Tabe

la II

I:

Licz

ba są

siad

ów

Ilość

są

siad

ów

1 2

3 4

5 6

7 8

9 10

11

12

w

szys

tkic

h ho

stów

Ilość

ho

stów

45

4 63

83

32

22

8

8 2

4 3

0 1

680


34

W powyższych wykresach występuje kilka anomalii. Na Wykresie I zaznaczone jest, że

kilkanaście (18) ścieżek zawiera dużą liczbę „gwiazdek”. Taka sama ilość ścieżek na

Wykresie II ma nienaturalną długość. Te dziwne pomiary wynikają z występowania

pętli rutingu na niektórych ścieżkach i świadczą o błędach w konfiguracji

poszczególnych hostów (ruterów) na ścieżce komunikacyjnej. Zaobserwowane błędy

dotyczyły jednego serwera WWW. Bardzo wyraźnie perlę rutingu można

zaobserwować na poniższym przykładzie:

Listing XIII: Przykład pętli rutingu rutingu w pomiarach 195.116.229.130 194.204.140.49 195.205.0.245 194.204.175.139 194.204.175.171 194.204.175.158 213.25.5.210 213.76.0.98 212.191.225.66 212.109.135.18 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 WSP-CORE-ATM-3-101.man.zgora.pl 212.109.135.5 212.109.135.6 212.109.135.5 WSP-CORE-ATM-3-101.man.zgora.pl 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6


35

212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5 212.109.135.6 212.109.135.5

Jeśli weźmiemy pod uwagę fakt, iż niektóre urządzenia nie przekazują pakietów ICMP

można łatwo wyjaśnić występowanie tak dużej liczby gwiazdek. Przykładowo, w w/w

przykładzie, jeżeli urządzenie występujące na dziesiątym miejscu (hopie) wycinałoby

pakiety ICMP to otrzymalibyśmy wyniki bardzo przypominający te, które

spowodowały anomalie w naszych statystykach.

Listing XIV: Przykład pętli rutingu z gwiazdkami 195.116.229.130 194.204.140.49 195.205.0.245 194.204.175.139 194.204.175.171 194.204.175.158 213.25.5.210 213.76.0.98 212.191.225.66 212.109.135.18 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


36

7.6. Mapa i jej opis

Wykres IV: Wizualizacja wyników

Na mapie kolorem czerwonym zaznaczone zostały główne węzły polskiej sieci WAN,

które zostały wytypowane na podstawie naszych pomiarów i badań. Wszystkie węzły

opisane zostały w tabeli poniżej. Tabel zawiera adres IP, nazwę oraz informacje

wygenerowane narzędziem SmartWhois firmy TamoSoft, Inc., które jest udostępnione

pod adresem www.all-nettools.com .


37

Tabela IV: Informacje o węzłach głównych Nr Adres IP Nazwa Dane o serwerze 1 134.222.230.38 hmb-s1-rou-1001.DE.eurorings.net

134.222.0.0 - 134.222.255.255

European Unix Users Group Kruislaan 413

NL-1098 SJ AmsterdamNL

KPNQwest N.V.

2 213.25.5.26 do.war-ar7.z.war-r2.tpnet.pl

213.25.5.0 - 213.25.5.255

polaczenia miedzy routerami TP S.A.-"POLPAK"

Warszawa

3 193.42.228.33 war7000.gazeta.pl

193.42.228.0 - 193.42.231.255

Agora SAPublisher of Gazeta

Wyborcza

4 193.219.28.1 c7-icm-atm2-0-6.icm.edu.pl

193.219.28.0 - 193.219.28.255

Public Internet services network at ICM, Warsaw, Poland

5 194.204.175.154 z.lub-r1.do.war-r2.tpnet.pl

194.204.175.0 - 194.204.175.255

Commercial IP network of Polish Telecom Piotrkow Tryb.


195.205.0.0 - 195.205.0.255

TP S.A.-"POLPAK" WARSZAWA

7 213.134.128.10 cdp.wix.waw.cdp.pl

213.134.128.0 - 213.134.128.255

CROWLEY DATA POLAND's network

Warsaw, POLAND

8 195.205.0.178 do.lodz-ar2.z.lodz-r1.tpnet.pl

195.205.0.0 - 195.205.0.255


9 194.204.175.202 Serwer TPSA – Piotrków Trybunalski.

194.204.175.0 - 194.204.175.255

Commercial IP network of Polish Telecom

Piotrków Trybunalski

10 195.205.0.130 do.wro-ar2.z.wro-r1.tpnet.pl

195.205.0.0 - 195.205.0.255


38


11 194.204.175.101 z.war-r2.do.war-r1.tpnet.pl

194.204.175.0 - 194.204.175.255

Commercial IP network of Polish Telecom

Piotrków Trybunalski

12 62.12.32.73 pos8-0-2488M.cr1.CPH1.gblx.net

62.12.32.0 - 62.12.32.159

The Copenhagen hub of the PEC

Global Crossing Telecommunications, Inc.

The Netherlands

13 194.204.175.170 z.kra-r1.do.war-r1.tpnet.pl

194.204.175.0 - 194.204.175.255


14 213.25.5.138 do.wro-ar1.z.wro-r1.tpnet.pl

213.25.5.0 - 213.25.5.255

polaczenia miedzy routerami TP S.A.-"POLPAK"

Warszawa


195.205.0.0 - 195.205.0.255

TP S.A.-"POLPAK"Warszawa

16 195.205.0.13 z.war-ar3.do.war-r1.tpnet.pl

195.205.0.0 - 195.205.0.255

TP S.A.-"POLPAK" Warszawa

17 62.89.117.209 host209-117.datastar.pl

62.89.117.0 - 62.89.117.255

CROWLEY DATA POLAND's networkPOLAND

Internal connection in Core Network

Customers Standard Link Warszawa

18 194.204.175.147 z.war-r2.do.ols-r1.tpnet.pl

194.204.175.0 - 194.204.175.255


Opis na podstawie[16]


39

8 . P R Z Y KŁA D O W E Z A S T O S O W A N I A

8.1. Buforowanie stron WWW

Bufor webowy, szczególnie gdy jest zainstalowany w odpowiednim miejscu sieci,

przynosi wiele korzyści. Strony WWW są wtedy dostarczane bardzo szybko,

obciążenie łącza WAN spada nawet dwukrotnie. Technologia ta rozwija się w ostatnim

czasie bardzo dynamicznie. Projektanci buforów webowych wprowadzają do nich nowe

rozwiązania (np. różnego rodzaju algorytmy przetwarzające w wyrafinowany sposób

odwołania do obiektów webowych), dzięki którym użytkownicy nie muszą już czekać

tak długo na pojawienie się na ekranie kolejnej strony WWW. Cała idea jest bardzo

prosta: należy umieścić obiekty webowe tak blisko użytkowników końcowych, jak to

tylko możliwe. Użytkownik pobiera wtedy strony WWW z bufora zainstalowanego na

obrzeżach sieci LAN, zamiast ściągać je z odległego serwera, pracującego gdzieś

daleko w sieci Internet. Pomiary prowadzone przez nas mogą pomóc w wyborze

miejsca w sieci, w którym taki bufor WWW powinien być umieszczony aby najlepiej

spełniał swoje funkcje.

Opis na podstawie[10]

8.2. Obrazowanie rutingu w sieciach

Ma charakter nie tylko informacyjny, ale również pomaga w projektowaniu

i późniejszym testowaniu sieci. Pomiary wykonywane podczas testów

przeprowadzonych w naszym projekcie pozwalają na wykrycie wielu błędów w

konfiguracji sieci. Jak pokazaliśmy w rozdziale 7 wykrycie anomalii podczas analizy

zgromadzonych danych ukazało błędy konfiguracyjne na trasie z jednego z serwerów.

8.3. Inżynieria ruchu

Inżynieria ruchu to w najprostszym ujęciu metodyka zapewniania równomiernego

obciążenie łączy, gwarantowania pasma dla różnych rodzajów ruchu, ograniczania

ruchu na pewnych łączach lub kierowania go na łącza wybrane. W sieciach

przesyłających dane i głos można dzięki tej inżynierii skierować ruch w stronę

dostępnych zasobów. Przebiega ona czteroetapowo: pomiary, znakowanie,

modelowanie i dostarczanie ruchu do właściwego miejsca. Pomiary ruchu są procesem

zbierania różnych metryk sieciowych, takich jak: liczba pakietów, ich rozmiar,


40

przesyłanie pakietów w godzinach szczytu, tendencje ruchu, najczęściej używane

aplikacje itp. Znakowanie ruchu polega na przypisywaniu zebranych danych do różnych

kategorii. Dzięki temu można potem statystycznie je modelować. Modelowanie ruchu

jest procesem, w którym zarówno wszystkie charakterystyki ruchu jak i statystyczne

analizowany ruch wykorzystuje się do utworzenia powtarzających się formuł i

algorytmów. Kiedy ruch zostanie matematycznie wymodelowany można wtedy tworzyć

rożne scenariusze funkcjonujące na podstawie ruchu. Co się np. stanie, jeśli nasilenie

ruchu będzie wzrastało o 2 % miesięcznie przez cztery kolejne miesiące? Po

prawidłowym wymodelowaniu ruchu można korzystać z osiągnięć symulacji

programowych, ustawiając różne parametry. Opisany schemat stosowany jest w nowej

technologii MPLS (Mulili-Protocol Label Switching), która może być lekarstwem na

coraz większe wykorzystanie zasobów sieci. MPLS pozwala odciążyć urządzenia oraz

efektywniej wykorzystać trasowanie na obrzeżach sieci oraz połączeniach

szkieletowych WAN. Przeprowadzenie naszych badań w dłuższym przedziale czasu

pozwala na zgromadzenie danych wykorzystywanych podczas wyznaczania etykiet

MPLS.

Opis na podstawie [10]

8.4. Symulatory sieci

Dane zebrane podczas eksperymentu mogą posłużyć jako dane wejściowe dla

symulatorów sieci WAN. Symulatory te odzwierciedlają działanie sieci o wiele

dokładniej, jeśli dane wejściowe pochodzą z rzeczywistych pomiarów.


41

9 . P O D S U M O W A N I E / Z A K OŃC Z E N I E

Głównym celem pracy było opracowanie mapy polskiej sieci rozległej w oparciu

o wyniki zgromadzone podczas analizy ruchu HTTP. Cel pracy został osiągnięty,

jednak ze względu na ograniczenia wynikające z braku wystarczających danych mapa,

którą uzyskaliśmy obrazuje tylko część polskiej sieci WAN.

Ponadto poznaliśmy i sklasyfikowaliśmy dostępne narzędzia pomiarowe, służące do

pomiarów procesów występujących w sieciach transmisji danych.

Praca pokazuje również studium przypadku wykorzystania tych narzędzi do analizy

mapy rutingu w sieci WAN. Badania tego typu mają zastosowanie przy symulacji sieci,

analizie ruchu i struktury sieci w celu zarządzania i planowania sieci.

Istniejące projekty dostarczają tego typu informacji przez dłuższy czas, jednak projekty

te rozwijane są poza granicami polski, i swoim zasięgiem nie obejmują naszej części

sieci. Rozwinięciem projektu pracy mogłoby być zaprojektowanie i instalacja stacji

monitorujących sieć, co pozwoliłoby na zgromadzenie oraz analizę pomiarów z

dłuższego okresu czasu. Wymagałoby to jednak uzyskania zgody na współpracę tego

typu, zgromadzenia środków i większych nakładów czasowych.


42

1 0 . Z AŁĄC Z N I K I

10.1. Spis serwerów WWW

Lista serwerów, do których skierowana została prośba o pomoc w pomiarach.

Niestety, część z nich bądź odmówiła nam pomocy, bądź wcale nie odpowiedziała na

nasze zapytania. Serwery te oznaczone zostały znakiem (-).

Pozostałym serdecznie dziękujemy za okazaną nam pomoc, gdyby nie Oni projekt nasz

stałby się czysto teoretycznymi analizami.

Gazeta.pl - zbieranie logów i prowadzenie pomiarów

Gratka.pl –zbieranie logów i prowadzenie pomiarów

Sunsite

Hoga.pl (-)

Home.pl (-)

Interia.pl (-)

O2.pl (-)

Wirtualna Polska (-)

PJWSTK (-)

Noname.ueuro.net - zbieranie logów i prowadzenie

pomiarów

Storm.com.pl - zbieranie logów i prowadzenie pomiarów


43

10.2. Przykład listu, który został rozesłany do administratorów

serwerów

Szanowna Pani/ Szanowny Panie

Zwracamy się do Pani/Pana z prośbą o pomoc w realizacji projektu pt. ”Mapa Polskiej

sieci WAN łączącej klientów z głównymi serwerami WWW”.

Jako administrator popularnego serwera WWW, ma Pan/i dostęp do potrzebnych nam

informacji, czyli adresów IP klientów Pana/Pani serwera. Nie zagraża to prywatności

Pana/Pani klientów, bowiem nie udostępni Pan/i nam informacji o treści żądanej przez

nich.

Załączamy do tego listu skrypt bash tworzący listę adresów IP. Jeżeli zgodzi się Pan/i

wziąć udział w projekcie prosimy o potwierdzenie, tak żebyśmy mogli skoordynować w

czasie gromadzenie informacji. Dodatkową pomocą w realizacji projektu byłaby

instalacja na Pan/i serwerze skryptu CGI pozwalającego na zbadanie tras rutingu do

klientów Pana/Pani serwera. Może on również mierzyć dostępną przepustowość dla

protokołu TCP.

Załączony przez nas skrypt jest bezpieczny i nie zużywa dużej ilości zasobów

obliczeniowych.

Pomiary zostaną wykonane dla ograniczonej ilości klientów (najwyżej 100).

Wyniki projektu będą udostępnione wszystkim uczestnikom, ale nie będą bez ich zgody

publikowane w mediach.

Z poważaniem


44

10.3. Plakat


45

10.4. Adres projektowej strony www

http://www.dziobak.org/projekt

Kontakt:

Adam Sujka: [email protected]

Piotr Dynia: [email protected]


46

1 1 . B I B L I O G R A F I A [1] http://www.caida.org/tools/ – przegląd dostępnych narzędzi pomiarowych

[2] http://www.caida.org/tools/visualization/plankton/help.xml

[3] http://www.caida.org/outreach/papers/1998/plankton/plankton.html

[4] http://www.nmt.edu/tcc/help/lang/awk.html - AWK

[5] http://www.cs.hmc.edu/tech_docs/qref/awk.html

[6] http://www.python.org/ - Python

[7] „Sieci komputerowe. Księga eksperta”, Mark Sportach,

Tłumaczenie: Zbigniew Gała, Helion, 04/1999

[8] Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup

Operations - RFC2925

[9] A Primer On Internet and TCP/IP Tools – RFC1739

[10] „MPLS czyli etykiety w sieci”, A.Janikowski, NetWorld, maj 2002,

nr 5/2002 (79)

[11] „Buforowanie Weba”, NetWorld,

http://www.networld.pl/artykuly/7031.html

[12] Tłumaczenie maunala do ping

[13] Tłumaczenie manuala do traceroute

[14] Vren. Paxson, Measurements and Analysis of End-to-End Internet Dynamics

Ph.D. dissertation, 1997 - ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz

[15] S.Floyd, V. Paxson, The failure of poisson modeling. IEEE.ACM Trans. On

Networking, strona 236, 1995

[16] “Network measurement tools tests”, Michal Przybylski, Szymon Trocha,

Poznań Supercomputing and Networking Center, June 2001

[17] SmartWhois TamoSoft, Inc www.tamasoft.com, skrypt na stronie

www.all-nettools.com

W OPARCIU O RUCH HTTPusers.pja.edu.pl/~s2294/Mapa.pdf · 2007. 10. 28. · Mapa polskiej sieci...

Documents

Transcript of W OPARCIU O RUCH HTTPusers.pja.edu.pl/~s2294/Mapa.pdf · 2007. 10. 28. · Mapa polskiej sieci...