w oparciu o ruch httpusers.pja.edu.pl/~s2294/mapa.pdf · 2007. 10. 28. · mapa polskiej sieci...
TRANSCRIPT
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Czas rzeczywisty Tekst
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ść
Czas rzeczywisty Tekst
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Czas rzeczywisty GUI
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
Czas rzeczywisty GUI
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Rożne Windows / UNIX GUI, grafy, raport www
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Rożne Windows / UNIX GUI, grafy, raport www
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
Czas rzeczywisty Tekst
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
Czas rzeczywisty Tekst
ping ICMP Echo/Reply Aktywna
Osiągalność, opóźnienie, straty pakietów
Czas rzeczywisty Tekst
sting TCP Pasywna Straty pakietów w jedna stronę Czas rzeczywisty Tekst
Traceping Dane z ping i traceroute Aktywna Straty pakietów
Czas rzeczywisty Tekst
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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].
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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]
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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 * * *
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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].
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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]
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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_*.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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 . .
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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):
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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 .
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
6 195.205.0.2 do.war-ar4.z.war-r2.tpnet.pl
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
TP S.A.-"POLPAK" WARSZAWA
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
38
TP S.A.-"POLPAK" WARSZAWA
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
Commercial IP network of Polish Telecom Piotrkow Tryb.
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
15 195.205.0.14 do.war-ar3.z.war-r1.tpnet.pl
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
Commercial IP network of Polish Telecom Piotrkow Tryb.
Opis na podstawie[16]
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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,
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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.
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
44
10.3. Plakat
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
45
10.4. Adres projektowej strony www
http://www.dziobak.org/projekt
Kontakt:
Adam Sujka: [email protected]
Piotr Dynia: [email protected]
Mapa polskiej sieci rozległej w oparciu o ruch HTTP
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