Pod Recznik

Ośrodek Kształcenia na Odległość
Politechniki Warszawskiej
Piotr Jankowski, Dominik Łoniewski,

Grzegorz Wójcik
Sieci komputerowe
podrecznik
˛ multimedialny pod redakcja˛
prof. dr hab. inż. Andrzeja P. Wierzbickiego
Warszawa, 2007
Ilustracje:
Anita Sterna
Opracowanie HTML:
Mariusz Pajer
Wydanie II, Warszawa 2007

Niniejszy podr˛ecznik i płyta CD-ROM sa˛ przeznaczone wyłacznie
˛ do użytku studentów studiów
„na odległość” Politechniki Warszawskiej.
Ośrodek Kształcenia na Odległość

Politechniki Warszawskiej
ul. Nowowiejska 15/19
00-665 Warszawa
http://www.okno.pw.edu.pl
Seria: Akademickie Podr˛eczniki Multimedialne

Spis treści
Wprowadzenie 1
1 Podstawowe poj˛ecia 3
1.1. Historia sieci komputerowych . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Topologie sieciowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Rodzaje sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Model ISO/OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1. Transmisja danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.2. Urzadzenia
˛ sieciowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.3. Internetowy model sieciowy . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5. Media transmisyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.1. Kable miedziane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.2. Kable światłowodowe . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Rozwój standardu Ethernet 17

2.1. Podstawy standardu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1. Topologia sieci Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2. Transmisja danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3. Model sieci LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.4. Budowa ramki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.5. Adresacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2. Ethernet w kolejnych wcieleniach . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1. Ethernet 10 Mb/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2. Fast Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.3. Gigabit Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.4. 10 Gigabit Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3. Urzadzenia
˛ sieci Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4. Nowe właściwości sieci Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.1. Sieci wirtualne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.2. Priorytety ruchu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.3. Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.4. Agregacja łaczy
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
iii
iv
3 Sieci Frame Relay 35

3.1. Budowa sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2. Protokół transmisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3. Sterowanie przeciażeniami
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1. Protokół LMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Sieci ATM 45
4.1. Standard ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2. ATM Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3. Urzadzenia
˛ ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4. Adresacja w sieci ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5. Rodzaje połaczeń
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6. Wirtualne ścieżki i kanały . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7. Budowa komórki ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7.1. Typy komórek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.8. Model sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8.1. Warstwa fizyczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8.2. Warstwa ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8.3. Warstwa AAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.9. Klasy ruchu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.10. Interfejsy ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.10.1. Protokół ILMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.10.2. Protokół PNNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.11. ATM a sieci komputerowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.11.1. Standard LANE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.11.2. LANE 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.11.3. MPOA - Multiprotocol Over ATM . . . . . . . . . . . . . . . . . . . . . 69
4.11.4. IP over ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.12. ATM a telefonia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.13. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Protokoły z rodziny TCP/IP 77

5.1. Protokół ARP/RARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2. Protokół IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.1. Adresacja w sieciach IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.2. Działanie protokołu IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3. Protokół UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.4. Protokół TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5. Protokół ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.6. Protokół DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.7. Protokół DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.8. Protokół IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
v
5.9. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6 Routing pakietów IP 101

6.1. Urzadzenia
˛ w sieci IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.2. Tablica routingu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.3. Routing statyczny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.3.1. Metryka trasy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.3.2. Trasy domyślne i interfejsy . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4. Routing dynamiczy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4.1. Klasyfikacja protokołów routingu dynamicznego . . . . . . . . . . . . . 103
6.5. Protokół RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.5.1. Format pakietu RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.5.2. Tablica routingu RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.5.3. Działanie protokołu RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.5.4. Trasy w protokole RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.5.5. Przykłady działania RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.5.6. Metryki RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.5.7. Problemy RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.5.8. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.6. Protokół RIP wersja 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.6.1. Format pakietu RIP 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.6.2. Autoryzacja w protokole RIP 2 . . . . . . . . . . . . . . . . . . . . . . . 115
6.6.3. Rozsyłanie uaktualnień . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.6.4. Wyznaczanie trasy i problemy . . . . . . . . . . . . . . . . . . . . . . . 116
6.7. Protokół OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.7.1. Działanie OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.7.2. Komunikacja pomi˛edzy routerami w OSPF . . . . . . . . . . . . . . . . 117
6.7.3. Metryka OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.7.4. Wyznaczanie trasy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.7.5. Obszary OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.7.6. Agregacja tablic routingu . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.7.7. Redystrybucja tras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.8. Protokół BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.8.1. Systemy Autonomiczne . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.8.2. Działanie protokołu BGP . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.8.3. Wyznaczanie trasy w protokole BGP . . . . . . . . . . . . . . . . . . . . 124
6.9. Wymiana informacji pomi˛edzy protokołami . . . . . . . . . . . . . . . . . . . . 125
6.10. Wybór protokołu dla sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
7 Podstawowe usługi sieciowe 127

7.1. Poczta elektroniczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.1.1. Protokół SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.1.2. Protokół POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
vi
7.1.3. Protokół IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

7.2. Przesyłanie plików . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.2.1. Protokół FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.2.2. Protokół NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.2.3. Usługa SCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.3. Usługi terminalowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.3.1. Protokół TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.3.2. Protokół SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.3.3. Usługi terminalowe systemów MS Windows . . . . . . . . . . . . . . . 144
7.4. Serwisy informacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
7.4.1. Protokół HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.4.2. Usługa Usenet news . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.5. Synchronizacja czasu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
7.5.1. NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
7.5.2. Usługa DayTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.6. Informacje o użytkownikach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.6.1. NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.6.2. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
7.7. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8 Ochrona danych w sieci 165

8.1. Wirusy komputerowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
8.1.1. Ochrona antywirusowa . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
8.2. Ochrona danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
8.2.1. Model centralny gromadzenia danych . . . . . . . . . . . . . . . . . . . 170
8.2.2. Bezpieczeństwo plików . . . . . . . . . . . . . . . . . . . . . . . . . . 174
8.2.3. Ochrona danych na pojedynczym komputerze . . . . . . . . . . . . . . . 174
8.2.4. Model rozproszony przechowywania danych . . . . . . . . . . . . . . . 175
8.3. Sieci bezpieczne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
8.3.1. VLAN-y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
8.4. Łacza
˛ WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
8.5. Bezpieczne połaczenia
˛ sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.5.1. Protokoły sieciowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.5.2. Routery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
8.5.3. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
8.5.4. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.5.5. Systemy IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
8.5.6. Firewalle personalne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.5.7. UTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.6. Kryptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.6.1. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.7. Autoryzacja i potwierdzanie tożsamości . . . . . . . . . . . . . . . . . . . . . . 192
8.7.1. Konto i hasło . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
8.7.2. Biometria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
vii
8.7.3. SSL i potwierdzanie tożsamości klienta . . . . . . . . . . . . . . . . . . 194

8.7.4. Certyfikaty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.8. Podpis cyfrowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.8.1. Definicja podpisu cyfrowego . . . . . . . . . . . . . . . . . . . . . . . . 194
8.8.2. Wymagania dla podpisu cyfrowego . . . . . . . . . . . . . . . . . . . . 194
8.8.3. Infrastruktura podpisu cyfrowego . . . . . . . . . . . . . . . . . . . . . 195
8.8.4. Działanie podpisu cyfrowego . . . . . . . . . . . . . . . . . . . . . . . . 195
8.8.5. Wdrożenie podpisu cyfrowego . . . . . . . . . . . . . . . . . . . . . . . 195
8.9. Przelewy bankowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Skorowidz 199
viii
Wprowadzenie
Podr˛ecznik niniejszy jest wynikiem doświadczeń zespołu autorskiego w nauczaniu i przekazy-

waniu wiedzy dotyczacej ˛ podstaw sieci komputerowych (inaczej teleinformatycznych, popular-
nie identyfikowanych z Internetem) — niezwykle ważnego elementu zarówno współczesnego
biznesu jak i przyszłej cywilizacji informacyjnej i opartej na wiedzy.
Podr˛ecznik ma charakter elementarny, ale jednak specjalistyczny. Jego adresatem sa˛ studen-
ci, którzy b˛eda˛ chcieli zajmować si˛e w przyszłości projektowaniem, eksploatacja˛ i zarzadzaniem
˛
sieci komputerowych. Podr˛ecznik nie wyczerpuje tej tak bogatej i szybko rozwijajacej ˛ si˛e dzie-
dziny, stanowi tylko pewien wybór wiadomości elementarnych, celowo ograniczonych co do
obj˛etości. Na przykład, podr˛ecznik nie omawia zagadnienia mobilnego, radiowego dost˛epu do
danych i sieci komputerowych, choć sa˛ to zagadnienia bardzo ważne i szybko dziś rozwijane.
Autorom chodziło tu raczej o przekazanie podstaw wiedzy o sieciach komputerowych; jej prak-
tyczne wykorzystanie wymagało b˛edzie i tak uzupełniajacych ˛ studiów podr˛eczników i informacji
internetowych.
1
2
R OZDZIAŁ 1
Podstawowe pojecia
˛
W rozdziale przedstawiono zasadnicze poj˛ecia zwiazane˛ ze współczesnymi sieciami komputero-

wymi: najpopularniejsze topologie sieci, modele odniesienia, typy urzadze˛ ń sieciowych, rodzaje
okablowania. Dobra znajomość tych poj˛eć b˛edzie niezb˛edna do zrozumienia treści dalszych roz-
działów.
W tym rozdziale, a także w reszcie podr˛ecznika, stosowane sa˛ najpopularniejsze, w środo-
wisku technicznym zwiazanym
˛ z tematyka˛ sieci komputerowych, nazwy urzadze ˛ ń, protokołów
i usług. Niestety dziedzina ta rozwija si˛e tak szybko, że nie zawsze zdażyły
˛ powsta ć odpowied-
nie terminy w j˛ezyku polskim, dlatego też cz˛esto używane sa˛ oryginalne nazwy angielskie. Tam
gdzie to tylko było możliwe zamieszczono ich polskie odpowiedniki.
1.1. Historia sieci komputerowych

Historia komunikacji (od łac. communicare — dzielić, brać udział) jest równie stara jak ludzkość.
Przyjmuje si˛e, że mowa wykształciła si˛e wśród ludzi około 50 tys. lat temu. Pierwsze, zachowane
do dzisiaj, rysunki naskalne maja˛ ok. 20 tys. lat, a pierwsze odnalezione dokumenty pisane licza˛
5 tysi˛ecy lat. Różne systemy sygnalizacji wykorzystywane były już przez ludy pierwotne, ale
pierwsza sygnalizacja optyczna, przypominajaca ˛ późniejszy telegraf (stosowany w nowożytnej
Europie dopiero na przełomie XVII i XVIII w.), używana była już przez starożytnych Greków.
Poczatków
˛ współczesnej telekomunikacji należy doszukiwać si˛e w XIX w. W 1846 r. Samuel
Morse wynalazł telegraf, w 1876 r. Aleksander Graham Bell opatentował telefon, a w 1897 r.
powstało radio Guglielmo Marconiego.
Jednak historia sieci komputerowych to lata nieomal współczesne. Do ich powstania praw-
dopodobnie najbardziej przyczyniła si˛e zimna wojna. W 1957 r. ówczesny Zwiazek ˛ Radziecki
wystrzelił Sputnika — pierwszego ze sztucznych satelitów Ziemi. Poczucie atomowego zagro-
żenia oraz świadomość tego, że w wyścigu w kosmos dali si˛e wyprzedzić, skłoniła Amerykanów
do powołania, przy departamencie obrony, w 1962 r. ARPA (Advanced Research Projects Agen-
cy). Zadaniem tej agencji było prowadzenie zaawansowanych prac badawczych na potrzeby sys-
temu obronnego Stanów Zjednoczonych. Jedna˛ z takich prac była pierwsza sie ć komputerowa
ARPANET (1969) — sieć połaczeń ˛ mi˛edzy komputerami, w której nie było jednego centrum za-
rzadzania
˛ i przetwarzania danych, a każdy z w˛ezłów był niezależny i mógł funkcjonowa ć nawet
w przypadku awarii pozostałych w˛ezłów. Sieć ta, w zamyśle jej twórców, miała być odporna na
atak atomowy. Wymyślone wtedy mechanizmy funkcjonowania sieci stały si˛e podstawa˛ działa-
nia współczesnych pakietowych, protokołów sieciowych, na których m.in. bazuje Internet.
Sieć ARPANET łaczyła
˛ zarówno laboratoria wojskowe, jak i wielkie ośrodki uniwersytec-
3
4 1.1. Historia sieci komputerowych
kie, które również uczestniczyły w badaniach ARPA. Dosyć szybko wykorzystano możliwości
komunikacji, które stwarzała i w 1972 r. powstała pierwsza usługa sieciowa — poczta elek-
troniczna. Dalszy rozwój protokołów sieciowych post˛epował bardzo szybko. W 1974 r. powstał
standard TCP (Transport Control Protocol), w 1976 — pierwszy router, a w 1978 standard trans-
feru plików.
Pierwszy raz termin Internet został użyty ok. 1974 r., ale do szerszego użycia wszedł do-
piero w latach osiemdziesiatych.˛ Stopniowo rozpocz˛eto rozdzielanie sieci o charakterze militar-
nym od sieci naukowej, do której później właczono ˛ również zastosowania komercyjne. Na wzór
ARPANET-u powstawały inne sieci, o cywilnym charakterze: BITNET, EARN i CSNET. Kształ-
towały si˛e „klasyczne” protokoły internetowe. W 1983 r. opublikowany został zestaw standar-
dów TCP/IP w znanej nam, współczesnej postaci. W 1984 r. opracowano DNS (Domain Name
System).
Przełom w rozwoju Internetu nastapił ˛ w 1991 r. kiedy to Tim Berners-Lee z CERN-u opra-
cował protokół HTTP (Hypertext Transfer Protocol) i zaproponował nowy system udost˛epniania
informacji: WWW (World Wide Web). Prawdziwa˛ popularność ten nowy system zdobył wraz
z pojawieniem si˛e pierwszej graficznej przegladarki ˛ WWW — Mosaica (1993). Od tego mo-
mentu rozwój ogólnoświatowej sieci stał si˛e nieomal wykładniczy, zasadniczo zmieniajac ˛ do-
tychczasowe sposoby dost˛epu do informacji i tworzac ˛ jedna˛ z podstaw budowy społecze ństwa
informacyjnego.
Wspominajac ˛ histori˛e sieci komputerowych warto też powiedzieć o dwóch nieodległych od
siebie datach. W 1994 r. powstał pierwszy katalog stron internetowych, zorganizowany przez
firm˛e Yahoo! Był to przodek wszystkich dzisiejszych portali (czyli serwerów WWW groma-
dzacych
˛ wiedz˛e z określonej dziedziny zarówno w postaci własnych artykułów, jak i dobrze
skatalogowanych odnośników do innych serwerów) i wyszukiwarek internetowych.
W 1995 r. rozpocz˛eły działanie NetPhone i RealAudio — dajac ˛ poczatek
˛ usługom przesyła-
nia głosu w sieci Internet.
Polska z przyczyn politycznych nie mogła brać udziału w powstawaniu Internetu i zwiaza- ˛
nych z nim usług. Nasz udział mógł si˛e rozpoczać ˛ po 1989 r. W 1990 r. po zniesieniu przez
COCOM wi˛ekszości restrykcji Polska uzyskała dost˛ep do sieci EARN, zaś w 1991 r. NASK
(Naukowa i Akademicka Sieć komputerowa) zrealizowała pierwsze podłaczenie ˛ do Internetu.
Dalszy rozwój usług post˛epował bardzo szybko i niewiele ust˛epował ich rozwojowi na świecie:
w 1995 r. powstał pierwszy polski portal internetowy: Wirtualna Polska, w 1999 r. pierwszy pol-
ski komunikator: Gadu-Gadu, w 2001 r. praktycznie równolegle z powstaniem angloj˛ezycznej
Wikipedi powstała również jej polska edycja.
Obecnie, właśnie ze wzgl˛edu na ogromny rozwój i wielka˛ popularność Internetu, rodzina
protokołów TCP/IP (stanowiaca ˛ jego podstaw˛e) stała si˛e wiodac ˛ a˛ technologia˛ sieciowa˛ wypie-
rajac
˛ wszystkie inne, konkurencyjne rozwiazania. ˛ Na bazie tych protokołów tworzone sa˛ nowe
usługi zwiazane
˛ m.in. z transmisja˛ dźwi˛eku i obrazu.
Przewiduje si˛e, że w niedalekiej przyszłości przesyłanie zarówno danych, jak i zapisanych
cyfrowo: dźwi˛eku (rozmów telefonicznych, audycji radiowych, muzyki) i obrazu (zdj˛e ć, filmów)
b˛edzie możliwe za pomoca˛ wspólnej infrastruktury sieci pakietowych. To zjawisko stopniowego
scalania si˛e różnych dotad ˛ technologii nosi nazw˛e konwergencji (od łac. convergere — zbiega ć
si˛e). Zakłada si˛e, że ta sama rodzina protokołów sieciowych b˛edzie używana zarówno w sieciach
lokalnych, czy domowych, jak i w sieciach wielkich operatorów telekomunikacyjnych.
Podstawowe poj˛ecia 5
1.2. Topologie sieciowe

Sposób łaczenia
˛ urzadzeń
˛ w sieciach komputerowych zmieniał si˛e wraz z rozwojem technologii
sieciowych. Wielu producentów lansowało własne rozwiazania,
˛ ale w praktyce mamy do czy-
nienia przede wszystkim z czterema typami topologii sieciowych: szyna,˛ pierścieniem, gwiazda˛
i krata.˛
Rysunek 1.1: Schemat sieci komputerowej zbudowanej w topologii szyny.
Szyna (ang. bus) jest jedna˛ z najstarszych topologii sieciowych. W tej topologii wszystkie
komputery podłaczone˛ sa˛ bezpośrednio do wspólnego medium transmisyjnego. Cokolwiek je-
den komputer wyśle do takiej sieci może być odebrane przez wszystkie inne, a co za tym idzie
dost˛epne pasmo jest dzielone przez wszystkie połaczone
˛ do szyny komputery. Rodzi to sze-
reg problemów. Najważniejszym z nich sa˛ kolizje, czyli sytuacje, gdy dwa komputery rozpoczna˛
nadawanie w mniej wi˛ecej tym samym momencie. Powoduje to, że wzajemnie si˛e zakłócaja˛ i ża-
den z nadanych przez nich komunikatów nie nadaje si˛e do odczytu. Drugim istotnym problemem
jest to, że każdy komputer może odebrać to, co wysyła do sieci dowolny inny komputer. Bardzo
łatwo jest podsłuchać transmisj˛e, która zachodzi pomi˛edzy dwoma komputerami połaczonymi ˛
do wspólnej szyny. Do zalet tej topologii należy zaliczyć bardzo prosta˛ i tania˛ konstrukcj˛e sieci.
Sieci wykorzystujace˛ topologi˛e szyny to m.in.: Ethernet oraz Token Bus.
Pierścień (ang. ring) — jest topologia˛ obecnie rzadko stosowana, ˛ ale uznawana˛ za jedna˛ z bar-
dziej niezawodnych. Jak sama nazwa wskazuje, wszystkie komputery lub urzadzenia ˛ sieciowe,
podłaczone
˛ do tego typu sieci, sa˛ połaczone
˛ w pierścień. Inaczej jednak niż w przypadku szyny,
wszystkie one aktywnie uczestnicza˛ w przekazywaniu danych. Sieć o budowie pierścieniowej
może składać si˛e z jednej badź
˛ dwóch ścieżek transmisji danych (jednego, badź ˛ dwóch pierście-
ni). Jedna ze ścieżek nosi nazw˛e podstawowej, a druga zapasowej. W przypadku awarii ścieżki
podstawowej (np. uszkodzenia łacza ˛ transmisyjnego), stacje b˛edace ˛ najbliżej miejsca awarii do-
konuja˛ obejścia, czyli połaczenia
˛ pierścienia podstawowego i zapasowego. W ten sposób trans-
misja może nadal być kontynuowana. Wyróżniamy dwa rodzaje urzadze ˛ ń podłaczonych
˛ do sieci
pierścieniowych: SAS (Single Attached Station) oraz DAS (Dual Attached Station) — w zależ-
ności od tego czy sa˛ podłaczone
˛ do jednego, czy do dwóch pierścieni. Urzadzenie ˛ połaczone
˛
tylko do jednego pierścienia może, w przypadku awarii, zostać wyłaczone ˛ z sieci.
6 1.2. Topologie sieciowe
Rysunek 1.2: Schemat sieci komputerowej zbudowanej w topologii pierścienia.
Sieci pierścieniowe cechuja˛ si˛e zazwyczaj przewidywalnymi charakterystykami czasowymi

tj. można z pewnościa˛ określić, kiedy wysłane dane, w danej sieci, dotra˛ do odbiorcy. Dlatego
też, tego typu sieci były ch˛etnie wykorzystywane w przemyśle np. do sterowania obrabiarkami
lub liniami produkcyjnymi. Bardzo duże zastosowanie znalazły również w wielkich systemach
finansowych.
Przykładami sieci wykorzystujacych ˛ topologi˛e pierścieniowa˛ sa:
˛ FDDI (Fiber Distributed
Data Interface), Token Ring, SDH (Synchronous Digital Hierarchy). Z wyjatkiem ˛ tej ostatniej,
sieci te maja˛ już obecnie znaczenie jedynie historyczne.
Rysunek 1.3: Schemat sieci komputerowej zbudowanej w topologii gwiazdy.
Gwiazda (ang. star) — jest topologia,˛ która dominuje obecnie w lokalnych sieciach kompute-
rowych. W tej topologii wszystkie komputery sa˛ podłaczone,
˛ osobnymi łaczami,
˛ do centralnego
urzadzenia
˛ odpowiedzialnego za transmisj˛e danych mi˛edzy nimi. Ponieważ w tym rozwiazaniu ˛
każdy komputer dysponuje własnym łaczem,
˛ może on — przynajmniej teoretycznie — wykorzy-
stywać pełna˛ przepustowość sieci. Awaria jego łacza
˛ nie powoduje awarii całej sieci, a jedynie
unieruchomienie jednego komputera. Zdecydowanie utrudnione jest też podsłuchiwanie transmi-

sji — sasiednie
˛ komputery nie maja˛ zazwyczaj możliwości odbierania pakietów danych, które
nie sa˛ do nich skierowane. Z drugiej jednak strony, ze wzgl˛edu na liczb˛e połacze
˛ ń, ich długość
oraz konieczność prowadzenia dużej ilości okablowania w uporzadkowany
˛ sposób, sieci budo-
wane w tej technologii sa˛ stosunkowo drogie w budowie.
Najpopularniejszym przykładem tego typu sieci sa˛ nowoczesne sieci Ethernet.
Rysunek 1.4: Schemat sieci komputerowej zbudowanej w topologii kraty.
Krata (ang. mesh) — jest przede wszystkim wykorzystywana w sieciach rozległych. Jest to to-
pologia sieciowa złożona w budowie i późniejszym zarzadzaniu,
˛ pozwala ona bowiem na łacze- ˛
nie każdego urzadzenia
˛ w sieci z każdym innym. Oczywiście nie wszystkie połaczenia
˛ sa˛ reali-
zowane, ze wzgl˛edów finansowych, badź ˛ technicznych, ale typowo pomi˛edzy dwoma punktami
takiej sieci istnieje wi˛ecej niż jedno połaczenie.
˛ Dzi˛eki temu, tego typu sieci sa˛ bardzo odporne
na awarie i umożliwiaja˛ uzyskanie dużych przepustowości, ale wymagaja˛ bardziej skompliko-
wanych mechanizmów rozpływu ruchu i sa˛ raczej kosztowne w budowie i eksploatacji.
Do typowych sieci budowanych w tej topologii zaliczyć należy: ATM (Asynchronous Trans-
fer Mode) oraz Frame Relay.
1.3. Rodzaje sieci

Istnieje wiele definicji różnych rodzajów sieci komputerowych. Jednak wraz z rozwojem tech-
nologii staja˛ si˛e one coraz mniej adekwatne. Podstawowe rodzaje sieci można scharakteryzowa ć
w nast˛epujacy
˛ sposób:
Sieć LAN (Local Area Network) to sieć łacz˛ aca

˛ zazwyczaj niewielka˛ liczb˛e komputerów (od
kilku — w przypadku grupy roboczej — do kilkuset, a nawet kilku tysi˛ecy w przypadku dużego
przedsi˛ebiorstwa). Najistotniejszym wyróżnikiem tego typu sieci jest jednak jej lokalny charak-
ter — ograniczenie terytorium sieci do bardzo niewielkiego obszaru — typowo rz˛edu kilkuset
8 1.3. Rodzaje sieci
metrów, do kilku kilometrów. Komputery, podłaczone

˛ do sieci, znajduja˛ si˛e przeważnie w posia-
daniu jednej firmy lub organizacji i sa˛ rozmieszczone w należacym
˛ do niej budynku. Jeśli sieć
danej instytucji obejmuje kilka budynków mówimy wtedy o sieci kampusowej.
Ze wzgl˛edu na niewielkie odległości pomi˛edzy komputerami i łatwość prowadzenia wszel-
kich instalacji możliwe (i ekonomicznie uzasadnione) jest stosowanie technologii zapewniaja- ˛
cych duże szybkości transmisji. Obecnie typowymi szybkościami transmisji w sieciach lokal-
nych jest 100 Mb/s – 1 Gb/s. W niektórych cz˛eściach sieci moga˛ być stosowane połaczenia ˛
o szybkości 10 Gb/s. Dla sieci lokalnych charakterystyczne sa˛ również działajace˛ tam aplikacje
bezpośrednio zwiazane
˛ z działaniem danej instytucji np.: programy biurowe, finansowe, bazy
danych itp.
Sieć WAN (Wide Area Network) czyli inaczej sieć rozległa jest całkowitym przeciwie ństwem
sieci lokalnych — jej obszar działania obejmuje setki lub tysiace˛ kilometrów. Może ona łaczy
˛ ć
zarówno oddziały tego samego przedsi˛ebiorstwa, jak i w˛ezły sieciowe należace˛ do różnych firm.
W sieciach tego typu przeważaja˛ połaczenia
˛ punkt-punkt, choć zazwyczaj zapewniane sa˛ także
połaczenia
˛ zapasowe. Oczywiście najbardziej znanym przykładem sieci rozległej jest Internet.
Sieci rozległe charakteryzuja˛ si˛e z bardzo zróżnicowanymi szybkościami transmisji. W centrum
(szkielecie) sieci, zapewnianym przez dużych operatorów telekomunikacyjnych, możliwe jest
uzyskiwanie pr˛edkości transmisji dochodzacych˛ do terabitów na sekund˛e. Jednak użytkowni-
cy indywidualni badź
˛ instytucjonalni, ze wzgl˛edu na wysokie opłaty, uzyskuja˛ dost˛ep do sieci
z pr˛edkościami znacznie niższymi niż w sieciach lokalnych. Typowe pr˛edkości to: 128 kb/s,
512 kb/s, 2 Mb/s.
Sieć MAN (Metropolitan Area Network). Sieci metropolitalne były przede wszystkim pomy-
ślane jako miejsca koncentracji usług sieciowych w obszarach zurbanizowanych, o przewidy-
wanej dużej liczbie użytkowników. Powstawały przede wszystkim w momencie, gdy łacza ˛ do
sieci rozległych np. Internetu miały niezbyt wielkie przepustowości. Stad ˛ pomysł scentralizo-
wania najcz˛eściej wykorzystywanych zasobów (uruchomienia serwerów: plików, Usnet news,
w3cache) tam gdzie jest dużo osób chcacych ˛ z nich skorzystać. Dzi˛eki temu informacje były
pobierane jednokrotnie i gromadzone w sieci MAN, zamiast wielokrotnie transmitowa ć to samo,
dla różnych użytkowników, przez mało wydolne łacza ˛ do sieci rozległej. Ponieważ sieci miejskie
obejmowały zazwyczaj niezbyt wielkie obszary (do 100 km) i mogły wykorzystywa ć istniejac ˛ a˛
infrastruktur˛e teletechniczna,˛ możliwe było budowanie sieci o stosunkowo dużych przepustowo-
ściach (typowo od 100 Mb/s do kilku Gb/s). Do tej sieci były podłaczane˛ sieci lokalne poszcze-
gólnych instytucji, a sama sieć dysponowała jednym lub kilkoma połaczeniami
˛ do sieci rozległej.
Kilka lat temu, dzi˛eki finansowaniu Komitetu Badań Naukowych, w głównych ośrodkach aka-
demickich w Polsce powstały sieci miejskie łacz ˛ ace
˛ instytucje edukacyjne i naukowo-badawcze.
Obecnie coraz rzadziej mamy do czynienia z koncentracja˛ usług w sieciach miejskich. Ze
wzgl˛edu na rozwój sieci rozległych, m.in. przez istotne zwi˛ekszenie szybkości transmisji do-
st˛epnych dla poszczególnych użytkowników, sieci MAN stały si˛e przede wszystkim sieciami
o charakterze dost˛epowym (ułatwiajacymi˛ dost˛ep do sieci rozległej).
1.4. Model ISO/OSI
Model ISO/OSI powstał w 1984 r. w momencie, gdy rynek sieci komputerowych był zdominowa-
ny przez rozwiazania
˛ poszczególnych dużych producentów (DEC, IBM). Był próba˛ stworzenia
pewnego modelu koncepcyjnego, który pozwalałby na tworzenie poszczególnych komponentów
sieci — zarówno urzadzeń
˛ jak i oprogramowania — przez niezależnych wytwórców oraz za-
pewnienie wzajemnej zgodności wszystkich rozwiazań.
˛ Przez wszystkie lata rozwoju sieci był
on podstawowym modelem odniesienia używanym przy przedstawianiu zasad działania sieci.
Model ISO/OSI składa si˛e z siedmiu warstw (liczac
˛ od dołu):
1. warstwa fizyczna — opisuje sprz˛etowe możliwości przesyłania danych; umożliwia prze-
syłanie pojedynczych bitów informacji pomi˛edzy dwom (lub wi˛ecej) komputerami poła- ˛
czonymi tym samym łaczem;˛ opisuje parametry elektryczne i mechaniczne łacza ˛ (poziomy
sygnałów elektrycznych, kształt złacz),
˛ szybkość transmisji, opóźnienia transmisyjne, sto-
p˛e bł˛edów.
2. warstwa łacza˛ — umożliwia przesyłanie ramek (tj. sekwencji bitów) pomi˛edzy dwoma
lub wi˛ecej stacjami połaczonymi
˛ tym samym łaczem;
˛ zapewnia wykrywanie i ewentualne
korygowanie bł˛edów transmisji; przy wi˛ekszej liczbie stacji zapewnia bezkolizyjny dost˛ep
do łacza.
˛
3. warstwa sieciowa — zapewnia wybór optymalnej drogi pakietów (tj. danych wraz z odpo-
wiednimi informacjami sterujacymi)˛ pomi˛edzy dwoma stacjami ko ńcowymi przy wyko-
rzystaniu w˛ezłów pośredniczacych;
˛ zapewnia również jednoznaczna˛ adresacj˛e wszystkich
urzadzeń
˛ w całej sieci.
4. warstwa transportowa — oddziela oprogramowanie warstw wyższych od problemów
zwiazanych
˛ z przesyłaniem danych; zapewnia bezbł˛edna˛ transmisj˛e o zadanej charaktery-
styce (przepustowość, stopa bł˛edów, opóźnienia) oraz ekonomiczne wykorzystanie łacza. ˛
5. warstwa sesji — umożliwia wzajemna˛ synchronizacj˛e urzadze ˛ ń bioracych
˛ udział w wy-
mianie informacji oraz zarzadzanie
˛ wymiana˛ danych.
6. warstwa prezentacji — odpowiada za przekształcenie przesyłanych informacji do formy
odpowiedniej dla oprogramowania wykorzystywanego przez użytkownika (zmiana spo-
sobu kodowania znaków, zmiana formatu, szyfrowanie lub deszyfrowanie, kompresja lub
dekompresja).
7. warstwa aplikacji — umożliwia bezpośrednia˛ komunikacj˛e z użytkownikiem przez od-
powiednie programy aplikacyjne.
Model ISO/OSI stał si˛e podstawa˛ rozwoju wielu protokołów sieciowych, jednak nie do ko ńca
zadania poszczególnych protokołów pokrywaja˛ si˛e z funkcjami odpowiednich warstw. Stosun-
kowo najlepsza˛ odpowiedniość widać w tzw. protokołach warstwy fizycznej oraz w warstwie
sieciowej. W ramach rodziny protokołów TCP/IP cz˛esto jednak poszczególne protokoły realizu-
ja˛ zadania, które zostały przypisane wi˛ecej niż jednej warstwie modelu ISO/OSI np. TCP, czy
telnet. Relacje poszczególnych protokołów z rodziny TCP/IP do modelu ISO/OSI przedstawiono
na rys. 1.5.
Zestaw protokołów internetowych bazujacych
˛ na IP, TCP i UDP, obejmujacych
˛ wszystkie
warstwy modelu ISO/OSI przyj˛eło si˛e nazywać stosem TCP/IP. Jest on w tej chwili implemen-
towany praktycznie w każdym systemie operacyjnym.
10 1.4. Model ISO/OSI
aplikacji NFS
Telnet SMTP FTP
prezentacji DNS XDR
sesji RPC
transportowa TCP UDP
sieciowa IP
³¹cza
Ethernet Token Ring Slip PPP
fizyczna
Rysunek 1.5: Układ protokołów warstwy fizycznej i protokołów z rodziny TCP/IP w stosunku
do warstwowego modelu ISO/OSI.
1.4.1. Transmisja danych

Faktyczna transmisja danych w modelu ISO/OSI odbywa si˛e tylko na poziomie warstwy fizycz-
nej. Jednak dane wysyłane z programów nie trafiaja˛ zazwyczaj bezpośrednio do warstwy fi-
zycznej, a przechodza˛ przez wszystkie warstwy modelu poczawszy
˛ od warstwy aplikacji. Każda
z warstw, aby móc realizować swoje zadania, rozszerza te dane o charakterystyczne dla siebie
informacje sterujace
˛ oraz ewentualnie sumy kontrone. W ten sposób, zanim surowe dane dotra˛
do medium transmisyjnego, ich obj˛etość znaczaco
˛ wzrasta (rys 1.6).
aplikacji dane
prezentacji
sesji
transportowa
sieciowa
³¹cza
fizyczna
Rysunek 1.6: Transmisja danych przez poszczególne warstwy modelu ISO/OSI.
W przypadku rzeczywistej transmisji przesyłane dane sa˛ uzupełniane o nagłówki poszcze-

gólnych protokołów sieciowych np. do danych przesyłanych przez telnet dodawany jest nagłó-
wek TCP, nast˛epnie IP, a na końcu np. nagłówek i suma kontrolna Ethernet. Dopiero taki pakiet
jest fizycznie przesyłany pomi˛edzy komputerami. Oczywiście, u odbiorcy odbywa si˛e proces
odwrotny — poszczególne protokoły (poczawszy ˛ od Ethernetu) odczytuja˛ informacje sterujace
˛
z nagłówków, a dane przekazuja˛ do protokołów warstw wyższych.
Do funkcjonowania niektórych protokołów (np. IP w warstwie sieciowej) konieczne sa˛ proto-
koły pomocnicze (np. ARP Address Resolution Protocol). Nie służa˛ one wymianie danych przez
poszczególne aplikacje, a sa˛ wykorzystywane do wymiany informacji kontrolnych i sterujacych
˛
pomi˛edzy poszczególnymi stosami protokołów na komputerach użytkowników.
1.4.2. Urzadzenia
˛ sieciowe
Wprowadzenie modelu ISO/OSI pozwoliło również na dokonanie pewnej klasyfikacji urzadze ˛ ń
sieciowych w zależności od tego, w której warstwie modelu pracuja.˛ Wyróżniono nast˛epujace
˛
zasadnicze typy urzadzeń:
˛
repeater jest urzadzeniem

˛ działajacym
˛ jedynie w warstwie fizycznej — jego podstawowym zda-
niem jest wzmocnienie i regeneracja sygnału, a przez to przedłużenie zasi˛egu działania sie-
ci. W pierwszych latach sieci komputerowych był to po prostu odpowiedni wzmacniacz,
w tej chwili jest to zazwyczaj urzadzenie
˛ komputerowe, które odczytuje ramki nadcho-
dzace
˛ jednym interfejsem, a nast˛epnie przepisuje je na drugi interfejs. Repeatery zostały
praktycznie wyeliminowane z sieci lokalnych (ich miejsce zaj˛eły bardziej rozbudowane
urzadzenia
˛ opisane poniżej), natomiast wciaż
˛ sa˛ z powodzeniem używane w sieciach roz-
ległych.
bridge (mostek) jest urzadzeniem

˛ działajacym
˛ w warstwie łacza.
˛ Podobnie jak repeater, ła-
˛
czy ono poszczególne segmenty sieci w jedna˛ całość. Jednak w odróżnieniu od repeatera
„uczy” si˛e ono topologii sieci, w której pracuje, na podstawie adresów zawartych w ram-
kach, które przesyła. Np. w przypadku sieci Ethernet, każda ramka zawiera sześciobajtowe
adresy nadawcy i odbiorcy danych. Tuż po właczeniu
˛ bridge nic nie wie o topologii sieci,
do której jest podłaczony.
˛ W momencie otrzymania pierwszej ramki musi ja˛ wi˛ec rozesła ć
przez wszystkie swoje interfejsy, majac ˛ nadziej˛e, że gdzieś tam jest jej odbiorca. Jedno-
cześnie jednak zapami˛etuje adres jej nadawcy i interfejs, którym nadeszła. W momencie,
gdy odbiorca zechce odpowiedzieć, jego ramka nie trafi już do wszystkich komputerów
w całej sieci. Bridge b˛edzie już wiedział, przez który interfejs ja˛ wysłać, aby dostarczyć
bezpośrednio do adresata. Przy okazji znów nauczy si˛e — gdzie jest kolejny komputer
w sieci. W ten sposób, w miar˛e przenoszenia coraz wi˛ekszego ruchu, bridge dowiaduje
si˛e o położeniu wszystkich komputerów w sieci i buduje sobie tablic˛e ich adresów oraz
odpowiadajacych
˛ im interfejsów. Proces ten ilustruje rysunek 1.7.
Oczywiście dane w tej tablicy nie sa˛ pami˛etane raz na zawsze, bowiem w ten sposób ni-
gdy nie moglibyśmy przenieść komputera z jednego segmentu do drugiego. Ich tzw. czas
życia wynosi ok. 5 min. — jeśli w tym czasie komputer nie potwierdzi swojego działa-
nia, informacja o nim jest usuwana z tablicy. Bridge dopisze go znów gdy rozpocznie on
nadawanie.
router jest również urzadzeniem

˛ służacym
˛ do łaczenia
˛ sieci mi˛edzy soba.˛ Działa w warstwie
sieciowej. Dlatego może on dysponować informacjami o adresacji całej sieci. Dane te mo-
ga˛ zostać wprowadzone przez administratora (tzw. routing statyczny) lub pobrane z innych
routerów w sieci (tzw. routing dynamiczny). Dzi˛eki tym informacjom router może od razu
przekazywać nadchodzace˛ pakiety do właściwych segmentów sieci (rys. 1.8).
12 1.4. Model ISO/OSI
3
2
1 1
3 1
2
Rysunek 1.7: Droga ramek w sieci, której poszczególne segmenty podłaczone

˛ sa˛ do bridge’a.
2
1
1
172.16.10.0 2 172.16.20.0
172.16.30.0
Rysunek 1.8: Droga pakietów w sieci, której poszczególne segmenty podłaczone

˛ sa˛ do routera.
gateway (brama) jest urzadzeniem

˛ działajacym
˛ w warstwie aplikacji. Ma ono wszystkie cechy
routera, ale pozwala również wszystkim wyższym warstwom sieciowym na modyfikacj˛e
przesyłanych przezeń danych. Gateway jest używany zazwyczaj tam, gdzie konieczne jest
przeniesienie danych z jednego rodzaju sieci (np. TCP/IP) do innego (np. SNA IBM).
Gateway może też funkcjonować w ramach jednej aplikacji — np. poczty elektronicznej,
pozwalajac˛ np. na połaczenie
˛ ze soba˛ systemu poczty internetowej opartej na protokole
SMTP (Simple Mail Transfer Protocol) z systemem poczty charakterystycznym dla sieci
Novell.
Przedstawione tu modele urzadzeń˛ sieciowych maja,˛ podobnie jak sam model ISO/OSI, cha-
rakter koncepcyjny. Dost˛epne w sprzedaży urzadzenie
˛ nie zawsze daja˛ si˛e łatwo zaklasyfikowa ć
do jednej z przedstawionych tu grup. Cz˛esto w zależności od obsługiwanych protokołów moga˛
pełnić różne role np. dla protokołów z rodziny TCP/IP moga˛ działać jak router, dla protokołów
novellowskich zachowywać si˛e jak bridge, a dla wybranych systemów pocztowych mieć funkcj˛e
gatewaya.
Rola każdego z tych urzadzeń,
˛ stosowanych w rzeczywistych sieciach komputerowych, zo-
stanie bardziej szczegółowo omówiona w późniejszych rozdziałach.
1.4.3. Internetowy model sieciowy

Ponieważ faktyczny rozwój protokołów sieciowych nieco odbiegał od pierwotnych założe ń mo-
delu ISO/OSI, powstał nowy model o uproszczonej strukturze (rys. 1.9). Nosi on nazw˛e mode-
lu internetowego. W tym modelu warstwy łacza ˛ i fizyczna zostały połaczone
˛ w jedna˛ wspólna˛
warstw˛e fizyczna.˛ Stało si˛e tak dlatego, że standardy protokołów wymiany danych na poziomie
sprz˛etowym (np. standard Ethernet II) zawsze te dwie warstwy traktowały łacznie.
˛ Również wyż-
sze warstwy modelu ISO/OSI zostały scalone. Tutaj rozbieżności pomi˛edzy modelem ISO/OSI,
a rzeczywistymi protokołami sieciowymi były najwi˛eksze, a uznano, że tak dokładny podział na
warstwy nie jest konieczny do opisu działania sieci. Najcz˛eściej to właśnie nawiazania
˛ do warstw
tego uproszczonego modelu można znaleźć w publikacjach na temat funkcjonowania protokołów
sieciowych.
aplikacji
prezentacji aplikacji
sesji
transportowa transportowa
sieciowa sieciowa
³¹cza
fizyczna
fizyczna
Rysunek 1.9: Model internetowy i model ISO/OSI.
1.5. Media transmisyjne

We współczesnych sieciach komputerowych stosowane sa˛ rozmaite media transmisyjne. W ni-
niejszym punkcie przedstawione zostana˛ ich najważniejsze rodzaje. Skupimy si˛e na różnych ro-
dzajach okablowania, choć oczywiście możliwa jest również bezprzewodowa transmisja danych
— nie b˛edzie ona jednak omawiana w tym podr˛eczniku.
1.5.1. Kable miedziane

Jest to najpopularniejszy rodzaj okablowania, z którym mamy do czynienia przede wszystkim
w lokalnych sieciach komputerowych.
Jeszcze kilka lat temu do budowy takich sieci najcz˛eściej był wykorzystywany kabel koncen-
tryczny. Sa˛ to dwa przewody miedziane — jeden umieszczony wewnatrz ˛ drugiego, rozdzielone
14 1.5. Media transmisyjne
warstwa˛ dielektryka. Zewn˛etrzny kabel ma zazwyczaj form˛e plecionki. Obecnie wykorzysty-

wane sa˛ dwa rodzaje kabli koncentrycznych: o oporności falowej: 50Ω i 75Ω. Kable 50Ω były
wykorzystywane do budowy sieci komputerowych, kable 75Ω używane sa˛ do budowy instalacji
antenowych telewizyjnych i radiowych.
Obecnie jednak do budowy lokalnych sieci komputerowych używa si˛e przede wszystkim
czteroparowej skr˛etki komputerowej. Sa˛ to cztery pary wzajemnie skr˛econych przewodów. W za-
leżności od technologii sieciowej, do transmisji wykorzystywana jest jedna, dwie lub wszystkie
cztery pary. Dost˛epne sa˛ trzy rodzaje skr˛etki komputerowej:
UTP (Unshielded Twisted Pair) — skr˛etka nieekranowa;
FTP (Foiled Twisted Pair) — skr˛etka z ekranowaniem wykonanym z folii metalizowanej;
STP (Shielded Twisted Pair) — skr˛etka z oplotem (ekranowaniem) miedzianym.
Różnia˛ si˛e one przede wszystkim odpornościa˛ na zakłócenia elektromagnetyczne oraz granicz-
nymi (maksymalnymi) cz˛estotliwościami transmisji.
W zależności od wykonania, parametrów transmisyjnych i odporności na zakłócenia okablo-
wanie komputerowe zaliczamy do jednej z kategorii:
Rodzaj Liczba par Maks. cz˛est. Zastosowanie

kat. 1 1 – kabel telefoniczny
kat. 2 2 4 MHz
kat. 3 4 10 MHz Token Ring (4 Mb/s), Ethernet (10 Mb/s)
kat. 4 4 16 MHz Token Ring (16 Mb/s)
kat. 5 4 100 MHz Ethernet (10-100 Mb/s)
kat. 6 4 250 MHz Ethernet (10 Mb/s – 1 Gb/s)
kat. 6a 4 500 MHz Ethernet (10 Mb/s – 10 Gb/s)
Tabela 1.1: Kategorie okablowania komputerowego według specyfikacji EIA/TIA.
Obecnie instalowane okablowanie miedziane wykonywane jest zazwyczaj w kategorii 5e lub

5+ (o nieco lepszych parametrach transmisyjnych od kategorii 5). Umożliwia ono budow˛e sieci
Gigabit Ethernet (o przepustowości do 1 Gb/s). Jeśli w przyszłości planowane jest wykorzystanie
w sieci przepustowości do 10 Gb/s, a trzeba pami˛etać, że okablowanie strukturalne instalowane
jest na co najmniej 10-15 lat, to do jego budowy należy użyć komponentów kat. 6 (przy niewiel-
kich długościach kabli — do 37 m) lub kat. 6a (dł. kabli do 100 m).
1.5.2. Kable światłowodowe

Wsz˛edzie tam, gdzie konieczna jest transmisja danych z wielkimi szybkościami i na dalekie
odległości stosowane jest okablowanie światłowodowe. Światłowód to cienkie włókno szkla-

ne (wykonane z dwutlenku krzemu) o przekroju kołowym, niewielkiej średnicy (4 125 µm),
otoczone nieprzepuszczalnym dla światła pancerzem. Dzi˛eki wykorzystaniu efektu całkowitego
wewn˛etrznego odbicia promień światła wprowadzony do światłowodu biegnie wzdłuż osi włók-
na. Jako źródła światła używane sa˛ diody elektroluminescencyjne (LED) lub nadajniki laserowe.
Nadawanie odbywa si˛e na określonych długościach fal świetlnych, w tzw. oknach transmisji
(czyli na takich długościach fal, które podlegaja˛ najmniejszemu tłumieniu). Typowe okna trans-
misji to: 850 nm, 1300 nm, 1550 nm.
Ze wzgl˛edu na budow˛e i sposób działania kable światłowodowe dzielimy na jedno- i wielo-

modowe. Kable wielomodowe maja˛ zazwyczaj wi˛eksze średnice włókna (50 100 µm) i umożli-
wiaja˛ przesyłanie wzdłuż osi włókna wielu promieni świetlnych (modów). Kable te charaktery-

zuja˛ si˛e jednak dosyć dużym tłumieniem. W kablu jednomodowym (4 10 µm średnicy włókna)
przesyłany jest tylko jeden promień światła, którego źródłem jest zazwyczaj nadajnik laserowy.
Kable światłowodowe przy wykorzystaniu technik zwielokrotnienia falowego umożliwia-
ja˛ uzyskanie terabitowych przepustowości oraz pozwalaja˛ na przesyłanie danych na odległości
dziesiatek,
˛ a nawet setek kilometrów.
1.6. Podsumowanie
Przedstawione w tym rozdziale poj˛ecia stanowia˛ elementarz administratora sieci komputerowej
— ich biegła znajomość b˛edzie niezb˛edna do zrozumienia kolejnych zagadnie ń omawianych
w podr˛eczniku. Wiele z przedstawionych tu poj˛eć i wspomnianych jedynie protokołów siecio-
wych zostanie szczegółowo omówiona w dalszych rozdziałach.
Bibliografia
[1] Adam Urbanek. Leksykon teleinformatyka. IDG Poland S.A., wydanie I, Warszawa, 2001.
[2] Praca zbiorowa. Vademecum teleinformatyka I. Sieci komputerowe, telekomunikacja, insta-

latorstwo. IDG Poland S.A., wydanie I, Warszawa, 1999.
[3] Praca zbiorowa. Vademecum teleinformatyka II. Sieci nowej generacji, technologie interne-
towe, metrologia sieciowa. IDG Poland S.A., wydanie I, Warszawa, 2002.
16
R OZDZIAŁ 2
Rozwój standardu Ethernet
W rozdziale przedstawiono podstawowe poj˛ecia zwiazane

˛ ze współczesnymi sieciami Ethernet.
Omówiono rozwój tego standardu od sieci 10 Mb/s do 10 Gb/s, przedstawiono zasady działania
urzadzeń
˛ sieci Ethernet oraz nowe standardy w znaczacy
˛ sposób zwi˛ekszajace
˛ możliwości tej
sieci.
2.1. Podstawy standardu

Standard Ethernet jest jednym z najstarszych, a jednocześnie jednym z wciaż ˛ najbardziej po-
pularnych standardów techniki komputerowej. Ide˛e tej sieci zaprezentowano ponad 30 lat temu
w laboratorium PARC (Palo Alto Research Center) firmy Xerox. Pierwsza działajaca ˛ sieć proto-
typowa, wykorzystujaca ˛ okablowanie koncentryczne i pracujaca ˛ z szybkościa˛ 2,94 Mb/s, została
przedstawiona przez autorów standardu: Roberta Metcalfe’a i Davida Boggsa w 1974 r. Od te-
go czasu standard ten ulegał ogromnym zmianom. Zmieniały si˛e: szybkości działania, media
i sposoby transmisji, czy nawet formaty ramki Ethernet. Wszystkie te zmiany jednak były wyko-
nywane stopniowo i w taki sposób, aby zachować wsteczna˛ zgodność z wcześniejszymi wersjami
protokołu.
Praktycznie od swojego powstania Ethernet był standardem otwartym, nad którego rozwojem
czuwały organizacje niezależne od poszczególnych producentów: IEEE (Institute of Electrical
and Electronics Engineers) oraz IETF (Internet Engineering Task Force).
Ten sposób rozwoju sieci oraz jej mocne oparcie na powszechnie akceptowanych normach
sprawiły, że Ethernet stał si˛e de facto standardem wszystkich sieci lokalnych (w ostatnich latach
sieci Ethernet stanowiły od 80 do 90% wszystkich tworzonych sieci lokalnych).
2.1.1. Topologia sieci Ethernet

Pierwotny standard Ethernet wykorzystywał topologi˛e szyny. Każdy z komputerów był bezpo-
średnio podłaczony
˛ do kabla koncentrycznego za pomoca˛ trójnika 1 lub zewn˛etrznego transce-
ivera2 . Taka sieć była niezwykle tania i łatwa w budowie — wystarczyło wyposażyć wszystkie
komputery w karty sieciowe, a nast˛epnie połaczyć
˛ je kablem koncentrycznym. Na obu końcach
1 Trójnik (ang. T-connector)— złacze
˛ o trzech końcówkach: jednej podłaczanej
˛ do karty sieciowej komputera,
dwóch do podłaczenia
˛ kabla koncentrycznego.
2 Transceiver (skrót od transmitter-receiver) — niewielkie urzadzenie
˛ umożliwiajace
˛ nadawanie i odbiór danych,
w przypadku sieci Ethernet połaczone
˛ z komputerem za pomoca˛ interfejsu AUI (Attachment Unit Interface).
17
18 2.1. Podstawy standardu
kabla należało umieścić terminatory — oporniki, które zapobiegały powstawaniu odbić falo-
wych.
Wszystkie dane, jakie komputer wysyłał do sieci, trafiały do wspólnej szyny i mogły by ć
odebrane przez każdy z podłaczonych
˛ do niej komputerów. W przypadku gdy konieczne było
stworzenie sieci składajacej
˛ si˛e z wielu cz˛eści (tzw. segmentów), do ich wzajemnego łaczenia ˛
używano repeaterów. Miały one za zadanie regeneracj˛e sygnału i jego przesłanie do drugiego
segmentu.
Ta prosta technologia budowy sieci komputerowych miała jednak swoje wady. Przede wszyst-
kim, z punktu widzenia użytkownika, dost˛epne pasmo było dzielone przez wszystkie komputery
podłaczone
˛ do wspólnego medium. Jeśli wi˛ec mieliśmy do czynienia z siecia˛ Ethernet 10 Mb/s,
do której podłaczonych
˛ było np. 20 komputerów, to średnie pasmo dost˛epne teoretycznie dla
pojedynczego użytkownika wynosiło ok. 512 kb/s. Poza tym, ze wzgl˛edu na to, że każdy z kom-
puterów może odebrać dane wysłane do wspólnej szyny, możliwy był podsłuch przesyłanych
informacji.
Z punktu widzenia administratora, technologia ta była przede wszystkim bardzo podatna na
awarie. Wystarczyło bowiem, że ktoś niechcacy ˛ rozłaczył
˛ kabel koncentryczny przy którymkol-
wiek z komputerów (wystarczy obluzować wtyczk˛e) — od razu przestawał działać cały segment.
Bardzo trudne było zlokalizowanie, w którym punkcie sieci doszło do awarii.
Obecnie, podstawowa˛ topologia˛ sieci Ethernet jest topologia gwiazdy. W tej topologii po-
szczególne komputery podłaczone
˛ sa˛ osobnymi przewodami (skr˛etka˛ czteroparowa˛ badź˛ kablem
światłowodowym) do centralnego urzadzenia ˛ w sieci. Dzi˛eki temu każde z urzadze
˛ ń może wy-
korzystywać całe dost˛epne pasmo transmisji, a awaria pojedynczego łacza ˛ eliminuje z sieci tylko
jeden komputer. Zdecydowanie też utrudniony jest bierny podsłuch danych.
Wada˛ tej topologii jest konieczność stosowania aktywnych urzadzeń ˛ sieciowych w jej cen-
trum. W zależności od zastosowanych rozwiazań ˛ technicznych, urzadzenia
˛ te moga˛ jedynie prze-
syłać dane otrzymane przez jeden ze swych portów na wszystkie pozostałe (koncentrator) lub
przesyłać nadchodzace˛ dane wyłacznie
˛ do ich bezpośrednich odbiorców, rozpoznajac ˛ topologi˛e
sieci zgodnie z zasadami działania bridge’a (przełacznik).
˛
W przypadku awarii urzadzenia
˛ centralnego z sieci eliminowanych jest kilkanaście, kilka-
dziesiat,
˛ a nawet kilkaset komputerów. Dlatego też w dużych sieciach komputerowych, bazuja- ˛
cych na protokole Ethernet, stosowane sa˛ rozwiazania˛ nadmiarowe (redundantne) w odniesieniu
zarówno do sprz˛etu: nadmiarowe zasilacze, karty interfejsów, matryce przełaczaj ˛ ace,
˛ jak i pew-
ne rozszerzenia protokołu, pozwalajace ˛ na uruchomienie połacze ˛ ń zapasowych. Niektóre z tych
rozszerzeń zostana˛ omówione w dalszej cz˛eści tego rozdziału.
2.1.2. Transmisja danych

Podstawowy sposób transmisji danych w sieciach Ethernet wywodzi si˛e z pierwszych ich re-
alizacji bazujacych
˛ na topologii szyny. Tego typu transmisj˛e oznacza si˛e: CSMA/CD (Carrier
Sense Multiple Access with Collision Detection). Polega ona na tym, że każda ze stacji stale „na-
słuchuje” — analizuje stan łacza.
˛ Jeśli chce wysłać dane i słyszy, że właśnie nikt nie nadaje —
rozpoczyna transmisj˛e. Oczywiście może si˛e zdarzyć, że dwie lub wi˛ecej stacji naraz dojdzie do
wniosku, że łacze
˛ jest wolne i rozpoczna˛ nadawanie w mniej wi˛ecej w tym samym momencie.
Taka˛ sytuacj˛e nazywamy kolizja˛ — wtedy wzajemnie nałożone transmisje staja˛ si˛e nieczytelne
Rozwój standardu Ethernet 19
dla odbiorców. Jednak podczas wysyłania danych stacja nadajaca ˛ ma również obowiazek˛ spraw-
dzania stanu łacza.
˛ Jeśli stwierdzi, że doszło do kolizji, natychmiast przerywa wysyłanie danych,
czeka niewielki, losowej długości, okres czasu, upewnia si˛e, czy łacze ˛ jest znów wolne i pona-
wia transmisj˛e. Ten losowy odst˛ep pomi˛edzy stwierdzeniem kolizji, a ewentualnym ponownym
rozpocz˛eciem transmisji wprowadzono po to, aby dwie stacje, które spowodowały kolizj˛e nie
zacz˛eły znów nadawać w tym samym momencie.
W odróżnieniu od wielu innych protokołów sieciowych, w Ethernecie, jeśli stacja ma do
nadania duża˛ porcj˛e danych, to po nadaniu pierwszej ramki i stwierdzeniu, że łacze ˛ wciaż
˛ jest
wolne, może rozpoczać ˛ nadawanie kolejnej i tak dalej, aż do wyczerpania danych.
Nie powinna zdarzyć si˛e taka sytuacja, że zanim stacja nadajaca˛ odbierze sygnał kolizji (która
może nastapić
˛ w znacznej odległości od miejsca nadawania), zakończy już nadawanie swojej
ramki3 . Aby tego uniknać ˛ wprowadzane sa˛ dwa ograniczenia: na minimalna˛ wielkość ramki
(wynosi ona 64 bajty) oraz na długość segmentu sieci (różna w zależności od medium transmisji).
Dla porzadku
˛ dodajmy tylko, że maksymalna wielkość ramki Ethernet to 1518 bajtów.
Jak widać sposób realizacji transmisji jest bardzo prosty. Warto jednak zwrócić uwag˛e na
dwie jego cechy. Po pierwsze — w klasycznych sieciach Ethernet, ze wzgl˛edu na istnienie zjawi-
ska kolizji, nie jesteśmy w stanie stwierdzić jak szybko dotrze ramka wysłana z jednego kompu-
tera do drugiego. Po drugie, im wi˛ekszy ruch w sieci, tym wi˛eksze prawdopodobie ństwo zajścia
kolizji, im wi˛ecej kolizji tym wi˛ecej trzeba wykonać retransmisji, to z kolei powoduje jeszcze
zwi˛ekszenie ruchu w sieci, a wi˛ec jeszcze wi˛ecej kolizji itd. Może to doprowadzić do całko-
witego zablokowania sieci — wszystkie komputery b˛eda˛ próbowały nadawać, praktycznie całe
pasmo b˛edzie zaj˛ete, a jednak odbiorcy nie b˛eda˛ niczego otrzymywać. Aby uniknać ˛ takiej sytu-
acji, w dobrej praktyce projektowej zakłada si˛e, że obciażenie
˛ pojedynczego segmentu sieci przy
transmisji CSMA/CD nie powinno przekraczać 60%. Jeśli jest wi˛eksze, może to doprowadzić
do zablokowania sieci (trzeba wtedy po prostu podzielić segment na dwa mniejsze, wstawiajac ˛
mi˛edzy nie bridge).
Stad
˛ jeśli wrócimy do poprzedniego przykładu, przy sieci Ethernet 10 Mb/s i 20 podłaczo- ˛
nych do niej komputerach b˛edziemy dysponowali ok. 300 kb/s średniego pasma dla każdego
z nich.
W takiej sieci Ethernet stacja odbiera i wysyła dane korzystajac ˛ z tego samego kanału trans-
misyjnego. Ten typ transmisji nazywa si˛e półdupleks (ang. half dupleks).
Wykorzystanie w sieciach Ethernet światłowodów zmieniło typ transmisji. W przypadku ła- ˛
czy światłowodowych mamy zawsze do czynienia z dwoma światłowodami — jeden służy do
przesyłania danych od stacji do urzadzenia
˛ odbiorczego, a drugi do transmisji w przeciwnym kie-
runku. Ten typ transmisji — jednoczesnej transmisji dwukierunkowej — nosi nazw˛e dupleksu
(ang. full duplex). Warto zauważyć, że przy takiej transmisji mi˛edzy dwoma komputerami nigdy
nie dochodzi do kolizji — można wi˛ec bez obaw wykorzystać pełne dost˛epne pasmo. Ten typ
3 Pr˛
edkość sygnału elektrycznego w kablu miedzianym to ok. 200 000 000 m/s. Wyobraźmy sobie dwa komputery
(A i B) podłaczone
˛ do sieci Ethernet 10 Mb/s oddalone od siebie o 500 m. Zanim pierwszy bit ramki wysłanej przez
komputer A dotrze do komputera B, komputer A b˛edzie już wysyłał 25 bit. Zanim dotrze do niego informacja
o ewentualnej kolizji — b˛edzie już przy 50 bicie. Jak widać nie jest to dużo. Twórcy standardu Ethernet narzucili
jednak bardzo ostre wymagania na wielkość ramki i wielkość segmentu uwzgl˛edniajac ˛ również konieczny czas
reakcji układów elektronicznych, możliwe bł˛edy, zakłócenia i dodajac ˛ jeszcze spory zapas. Dlatego też możliwe
jest uruchomienie segmentów sieci Ethernet znacznie przewyższajacych ˛ przyj˛ete w standardzie ograniczenie na
długość.
przesyłania danych został również wykorzystany przy budowie sieci Ethernet wykorzystujacych
˛
skr˛etk˛e komputerowa˛ i przełaczniki
˛ jako urzadzenia
˛ centralne.
2.1.3. Model sieci LAN

Przy omawianiu działania sieci Ethernet poruszamy si˛e praktycznie jedynie w obr˛ebie pierw-
szych dwóch warstw modelu ISO/OSI. W celu dokładniejszego opisu tego typu sieci stworzony
został model LAN (rys. 2.1). W modelu tym zarówno warstwa fizyczna, jak i warstwa łacza
˛ mo-
delu ISO/OSI zostały podzielone na dwie podwarstwy. Dodatkowo dodana została podwarstwa
współpracy mi˛edzysieciowej — odpowiedzialna za wymian˛e komunikatów sterujacych
˛ pomi˛e-
dzy poszczególnymi urzadzeniami
˛ sieci LAN.
Model ISO/OSI
Model LAN Standardy IEEE, ANSI
sieciowa Podwarstwa
wspó³pracy IEEE 802.1
miêdzysieciowej
LLC IEEE 802.2

³¹cza
Ethernet II
IEEE 802.15
IEEE 802.3
MAC IEEE 802.5

Token Ring
Bluetooth
Ethernet
FDDI
PHY
fizyczna
PMD
Rysunek 2.1: Wzajemne relacje pomi˛edzy warstwami modelu ISO/OSI, modelu LAN oraz stan-
dardami opisujacymi
˛ funkcjonowanie lokalnych sieci komputerowych.
Warstwa łacza
˛ została podzielona na podwarstwy:
LLC (ang. Logical Link Control) — kanału logicznego: zapewnia bezbł˛edna˛ transmisj˛e ramek
pomi˛edzy dwoma komputerami podłaczonymi
˛ do jednego segmentu sieci, zarzadza
˛ na-
wiazaniem
˛ i zakończeniem połaczenia
˛ logicznego pomi˛edzy dwoma komputerami, prze-
syłaniem ramek, ich właściwym uporzadkowaniem,
˛ retransmisja.˛
MAC (ang. Medium Access Control) — dost˛epu do medium: umożliwia adresacj˛e w warstwie
łacza
˛ (uzupełnia przesyłana˛ ramk˛e o adres nadawcy i odbiorcy), sprawdza sum˛e kontrolna˛
ramki.
Zazwyczaj funkcjonalność podwarstwy MAC jest zapewniana (sprz˛etowo) przez kart˛e sieciowa,˛
natomiast funkcje LLC sa˛ realizowane (programowo) przez odpowiedni sterownik sieciowy.
Warstwa fizyczna została natomiast podzielona na podwarstwy:
PMI (ang. Physical Medium Independent) — niezależna˛ od medium: dzi˛eki której przetwarza-
nie ramek odbywa si˛e zawsze tak samo, niezależnie od wykorzystywanego medium trans-
misyjnego; podwarstwa ta jest odpowiedzialna za realizacj˛e kodowania nadmiarowego 4
i scramblingu5 powodujacych,
˛ że przesyłany ciag
˛ bitów ma zbliżona˛ liczb˛e zer i jedynek
oraz jest nieokresowy — umożliwia to synchronizacj˛e nadajnika i odbiornika, a także ogra-
nicza zakłócenia; podwarstwa ta dodaje również do ramki tzw. preambuł˛e 6 oraz znaczniki
poczatku
˛ i końca ramki.
PMD (ang. Physical Medium Dependent) — zależna˛ od medium: realizujac˛ a˛ samo przesyła-
nie danych przy użyciu konkretnego medium fizycznego; w sieciach Ethernet odpowiada
ona za odpowiednie kodowanie transmisyjne, ewentualna˛ multipleksacj˛e 7 kanałów oraz
badanie stanu medium.
Opisany tu model sieci LAN został zaproponowany przez IEEE — i jak widać — poszcze-
gólne warstwy tego modelu dobrze odpowiadaja˛ odpowiednim standardom IEEE.
2.1.4. Budowa ramki

W trakcie 30-letniej historii Ethernetu format ramki wiele razy ulegał zmianie. Pierwszy rodzaj
ramki (tzw. Ethernet I) zaproponowany został w 1972 w PERC. Nast˛epnie w 1982 r. konsorcjum
firm DEC, Intel i Xerox zaproponowało nowy format: Ethernet II. Ten typ ramki był powszech-
nie stosowany w systemach uniksowych. W tym samym czasie nad nowym standardem ramki
pracowało również IEEE opracowujac ˛ standard IEEE 802.3. Aby pogł˛ebić jeszcze ten chaos —
niektóre firmy (np. Novell) zaproponowały własne formaty ramki bazujace ˛ na niezatwierdzonych
specyfikacjach IEEE.
Jednak i tym razem pomógł rozwój Internetu. Ponieważ w pierwszym okresie wi˛ekszość
z serwisów internetowych była tworzona na systemach uniksowych, wi˛ec dla zapewnienia od-
powiedniej wymiany danych w sieciach lokalnych, ujednolicono format ramki i w innych syste-
mach operacyjnych. Obecnie wi˛ekszość sieci Ethernet bazuje na ramce Ethernet II. W niektórych
zastosowaniach (np. starych sieciach Novell) spotyka si˛e jeszcze ramki IEEE 802.3.
W skład każdej ramki Ethernet wchodza: ˛ sześciobajtowe adresy odbiorcy (DA — Destination
Address) oraz nadawcy (SA — Source Address) oraz czterobajtowa suma kontrolna (FCS —
Frame Check Sequence). Ramki Ethernet II i IEEE różnia˛ si˛e znaczeniem tylko jednego pola.
W ramce Ethernet II, po adresach, wyst˛epuje dwubajtowe pole określajace ˛ typ przesyłanych
informacji (identyfikator protokołu wyższej warstwy modelu ISO/OSI). W ramce IEEE 802.3
to samo pole określa długość ramki. Na szcz˛eście identyfikatory poszczególnych protokołów
zostały tak dobrane, by były wi˛eksze od 1518. Stad ˛ w jednej fizycznej sieci moga˛ koegzystowa ć
4 Kodowanie nadmiarowe polega na tym, że mniej liczny ciag
˛ bitów (np. 4 bity) jest kodowany za pomoca˛ ciagu
˛
o wi˛ekszej liczbie bitów (np. 5 bitów). Pozwala to na podniesienie niezawodności transmisji oraz weliminowanie
niektórych uciażliwych
˛ w przesyłaniu sekwencji bitowych. W sieciach Fast Ethernet stosuje si˛e kodowanie 4B/5B,
natomiast w sieciach Gigabit Ethernet oraz 10 Gigabit Ethernet 8B/10B.
5 Scrambling lub inaczej randomizacja struktur danych polega na takim kodowaniu przesyłanych danych, aby
eliminować długie, powtarzajace

˛ si˛e, jednakowe symbole (np. długie ciagi
˛ samych zer lub samych jedynek).
6 Preambuła to pewien ustalony wzór zer i jedynek poprzedzajacy˛ poczatek
˛ ramki Ethernet, umożliwiajacy
˛ syn-
chronizacj˛e nadajnika i odbiornika.
7
Multipleksacja to łaczenie
˛ wielu strumieni danych w jeden.
Ethernet II
DA SA typ dane FCS
IEEE 802.3
DA SA d³. dane FCS
IEEE 802.3 + IEEE 802.2
DSAP
SSAP
CTL
DA SA d³. dane FCS
6 bajtów 6 bajtów 2 1 1 1 4 bajty
Rysunek 2.2: Formaty ramki Ethernet: Ethernet II, IEEE 802.3 i IEEE 802.3 wraz z nagłówkiem
IEEE 802.2.
dwa rodzaje Ethernetu. Jeśli stacja skonfigurowana do pracy w sieci Ethernet II odbierze ramk˛e
z typem poniżej 1518, to uzna ja˛ za bł˛edna˛ i odrzuci. To samo zrobi stacja skonfigurowana do
korzystania z IEEE 802.3 z ramka˛ o podanej długości powyżej 1518. Tak wi˛ec te dwie grupy
stacji b˛eda˛ wzajemnie ignorować swoja˛ obecność. Oczywiście tego typu konfiguracje nie sa˛
zalecane.
Te same funkcje, które w ramce Ethernet II sa˛ realizowane przez pole typu, w ramce IEEE
802.3 realizuje nagłówek IEEE 802.2. Określa on rodzaj protokołu odbiorcy i nadawcy (DSAP
i SSAP — Destination/Source Service Access Point). Jest to istotne, gdy na danym komputerze
wykorzystywane sa˛ dwa stosy protokołów np. internetowy TCP/IP oraz IPX/SPX firmy Novell.
Dodatkowo nagłówek IEEE 802.2 zawiera pole CTL (Control) pomocne w realizacji funkcji
podwarstwy LLC.
2.1.5. Adresacja
Każdy komputer w sieci Ethernet (lub dokładniej: każda karta sieciowa) jest identyfikowany
przez swój adres fizyczny (nazywany również adresem MAC). Adres ten składa si˛e z sześciu
bajtów i jest zazwyczaj zapisywany w postaci heksadecymalnej (szesnastkowej) np.:
08:00:20:B1:8D:B5
Aby adres karty sieciowej nie powtórzył si˛e nigdzie w sieci, każdemu z wytwórców została
przez IEEE przydzielona własna pula adresów. Pierwsze trzy bajty adresu MAC identyfikuja˛ pul˛e
danego producenta, kolejne trzy to numer karty w ramach tej puli. Wykaz adresów przypisanych
poszczególnym producentom można znaleźć w RFC 1700 Assigned Numbers.
Warto zwrócić uwag˛e na dwa adresy specjalne:
jeśli w ramce Ethernet został umieszczony adres odbiorcy: ff:ff:ff:ff:ff:ff oznacza
to, że ramka ta jest skierowana do wszystkich komputerów w danym segmencie sieci. Taki
adres nazywamy adresem rozgłoszeniowym lub broadcastowym. Sama zaś ramka nosi
nazw˛e broadcastu.
adres: 00:00:00:00:00:00 jest wpisywany wsz˛edzie tam, gdzie konieczne jest podanie
adresu fizycznego, a nie jest on w tym momencie znany. Ramka wysłana na ten adres
zachowuje si˛e jak broadcast.
2.2. Ethernet w kolejnych wcieleniach

Rozwój standardu Ethernet jest postrzegany przez użytkowników sieci przede wszystkim przez
pryzmat stale rosnacych
˛ szybkości przesyłania danych oraz zmieniajacych
˛ si˛e mediów transmi-
sji. Spróbujmy prześledzić te zasadnicze cechy standardu i uświadomić sobie, jak wiele rodzajów
sieci Ethernet jest obecnie w użyciu.
2.2.1. Ethernet 10 Mb/s

Pierwszym standardem sieci Ethernet, który zdobył znaczac ˛ a˛ popularność był standard 10 Base-58 .
Jako medium transmisyjne wykorzystywany był tzw. „gruby” kabel koncentryczny (thick Ether-
net). Pojedynczy segment mógł mieć do 500 m długości. Można było połaczyć ˛ do 5 segmentów
w jedna˛ sieć za pomoca˛ repeaterów.
Kolejnym standardem był 10 Base-2, wykorzystujacy ˛ powszechnie znany, znacznie ta ńszy,
„cienki” kabel koncentryczny (thin Ethernet). W tym standardzie maksymalna długość segmen-
tu ustalona została na 185 m i również możliwe było połaczenie
˛ do 5 segmentów za pomoca˛
repeaterów.
Standard 10 Base-FL pozwalał na tworzenie sieci Ethernet z wykorzystaniem okablowania
światłowodowego. Możliwe było przedłużenie zasi˛egu sieci na wi˛eksze niż dotad ˛ odległości,
a transmisja odbywała si˛e w trybie dupleksowym. Dzieku urzadzeniom
˛ obsługujacym
˛ 10 Base-
FL możliwe było tworzenie pierwszych sieci kampusowych bazujacych ˛ wyłacznie
˛ na Ethernecie.
W 1990 r. powstał standard (IEEE 802.3i) umożliwiajacy
˛ wykorzystanie skr˛etki komputero-
wej w sieciach Ethernet (10 Base-T). Ten typ okablowania stał si˛e wkrótce ogromnie popularny,
bowiem umożliwiał stworzenie uniwersalnej infrastruktury pozwalajacej ˛ na łaczenie:
˛ kompu-
terów, urzadzeń
˛ telekomunikacyjnych, instalacji przeciwpożarowych, telewizji przemysłowych
itp. Wszystkie nast˛epne standardy Ethernetu były tak projektowane, aby umożliwi ć wykorzysta-
nie istniejacego
˛ w przedsi˛ebiorstwach okablowania strukturalnego bazujacego
˛ na skr˛etce.
Podstawowe właściwości tych standardów zostały przedstawione w tabeli 2.1.
2.2.2. Fast Ethernet

W 1995 r. została przez IEEE zaakceptowana kolejna norma: IEEE 802.3u, czyli standard Fast
Ethernet zapewniajacy
˛ przepustowość do 100 Mb/s. Podstawowym standardem był 100 Base-
TX umożliwiajacy
˛ transmisj˛e po dwóch parach czteroparowej skr˛etki komputerowej kategorii
5. Jedna z par służy do nadawania, druga do odbierania, sygnały sa˛ zaś przesyłane w sposób
różnicowy. Ten sposób przesyłania danych pozwala na realizacj˛e transmisji dupleksowej.
8 Jaknależy rozumieć oznaczenia np. 10 Base-5? 10 oznacza szybkość transmisji liczona˛ w Mb/s, Base jest skró-
tem od Baseband i oznacza rodzaj transmisji (z punktu widzenia użytkownika Baseband to taka transmisja, w której
jedno urzadzenie
˛ nadajace
˛ wykorzystuje cała dost˛epna˛ przepustowość, w odróżnieniu od Broadband, w której wiele
urzadzeń
˛ nadaje w tym samym paśmie i dziela˛ dost˛epna˛ przepustowość), cyfra 5 (lub inne oznaczenia) określaja˛
medium transmisji — w tym przypadku „gruby” kabel koncentryczny.
24 2.2. Ethernet w kolejnych wcieleniach
Oznaczenie Medium transmisyjne Zasi˛eg

10 Base-5 „gruby” kabel koncentryczny 500 m
10 Base-2 „cienki” kable koncentryczny 185 m
10 Base-T skr˛etka (2 pary) 100 m
10 Base-FL światłowód wielomodowy 2 km
Tabela 2.1: Standardy sieci Ethernet.
W przypadku okablowania kategorii 3 (powszechnie wykorzystywanego w pierwszych sie-

ciach 10 Base-T) możliwe jest zastosowanie standardu 100 Base-T4, pozwalajacego ˛ na równo-
legła˛ transmisj˛e danych przy wykorzystaniu wszystkich czterech par.
Zwi˛ekszenie szybkości transmisji spowodowało konieczność skrócenia segmentu sieci (w ce-
lu zapewnienia wykrywania kolizji). Wprawdzie długość pojedynczego segmentu wynosi wciaż ˛
100 m, to jednak, za pomoca˛ repeaterów, nie można łaczyć
˛ ze soba˛ wi˛ecej niż dwóch segmentów
sieci.
Aby zapewnić zgodność z poprzednimi rozwiazaniami
˛ sieci Ethernet zaproponowano auto-
negocjacj˛e pr˛edkości transmisji. Urzadzanie
˛ Fast Ethernet moga˛ wykrywać rodzaj podłaczonej
˛
do niego karty sieciowej: jeśli jest to karta standardu 10 Base-T działaja˛ z pr˛edkościa˛ 10 Mb/s,
a jeśli 100 Base-TX — 100 Mb/s. Autonegocjacja działa wyłacznie ˛ przy wykorzystaniu kabli
miedzianych.
Pewnym ułatwieniem w tworzeniu sieci o wi˛ekszych rozmiarach jest standard transmisji
światłowodowej 100 Base-FX. Podobnie jak w standardzie 10 Base-FL, pozwala on na two-
rzenie łaczy
˛ o długości do 2 km.
Stosowane obecnie standardy sieci Fast Ethernet przedstawiono w tabeli 2.2.

100 Base-TX skr˛etka (2 pary) 100 m
100 Base-T4 skr˛etka (4 pary) 100 m
100 Base-FX światłowód wielomodowy 2 km
Tabela 2.2: Standardy sieci Fast Ethernet.
2.2.3. Gigabit Ethernet

Kolejny skok w pr˛edkości sieci Ethernet miał miejsce stosunkowo szybko. Już w 1998 r. zaakcep-
towany został standard IEEE 802.3z definujacy ˛ sieci Gigabit Ethernet wykorzystujace
˛ medium
światłowodowe. Zdefiniowano trzy rodzaje sieci, które pozwalały na transmisj˛e z pr˛edkościa˛
1 Gb/s przy wykorzystaniu zarówno światłowodów jedno-, jak i wielomodowych. W zależności
od wybranego medium transmisji (i wykorzystywanego nadajnika) można było uzyska ć różne
zasi˛egi działania sieci (tabela 2.3). Standard 1000 Base-LX, przy wykorzystaniu światłowodów
jednomodowych, pozwala już na tworzenie niewielkich sieci miejskich.

1000 Base-TX skr˛etka (4 pary) 100 m
1000 Base-SX światłowód wielomodowy 260 m
1000 Base-LX światłowód wielomodowy 550 m
światłowód jednomodowy 5 km
Tabela 2.3: Standardy sieci Gigabit Ethernet.
Stworzenie standardu Gigabit Ethernet wykorzystujacego˛ istniejace

˛ okablowanie miedzia-
ne okazało si˛e znacznie trudniejsze. Dopiero rok później opublikowano standard IEEE 802.3ab
definiujacy
˛ sieci 1000 Base-TX. Podstawowym problemem w opracowaniu tego standardu była
ch˛eć zapewnienia możliwości wykorzystania w nowej sieci istniejacego
˛ okablowania kategorii 5.
Aby to osiagn
˛ ać,
˛ transmisja danych odbywa si˛e wszystkimi 4 parami (w trybie dupleksowym)
równolegle po 250 Mb/s w każdej parze. Dodatkowo, aby obniżyć górna˛ cz˛estotliwość transmisji
zastosowano kodowanie wielowartościowe, co pozwala na wykorzystanie okablowania o mak-
symalnej cz˛estotliwości transmisji do 100 MHz.
Aby umożliwić wykrywanie kolizji przy niezmienionej długości segmentu (100 m) należa-
łoby w sieci Gigabit Ethernet zwi˛ekszyć minimalna˛ długość ramki do 512 bajtów. To z kolei
spowodowałoby niezgodność z poprzednimi standardami Ethernetu. Zaproponowano rozwiaza- ˛
nie kompromisowe — minimalna długość ramki, z punktu widzenia podwarstwy MAC, nadal
wynosi 64 bajty, jednak w przypadku przesyłania ramek krótszych niż 512 bajtów, na ich ko ńcu
(za polem FCS) dodawane sa˛ tzw. bajty rozszerzenia (carrier extension) uzupełniajace
˛ ramk˛e do
512 bajtów. Oczywiście stosowanie bajtów rozszerzenia nie jest konieczne przy wykorzystaniu
transmisji dupleksowej.
Podobnie jak w przypadku Fast Ethernetu możliwa jest autonegocjacja 10/100/1000 Mb/s
w sieciach Gigabit Ethernet opartych na okablowaniu miedzianym.
2.2.4. 10 Gigabit Ethernet

Najnowszy standard: 10 Gigabit Ethernet jest definiowany przez trzy normy IEEE:
802.3ae (2002) — dla okablowania światłowodowego,
802.3ak (2003) — dla dedykowanego okablowania miedzianego,
802.3an (2006) — dla skr˛etki komputerowej kat. 6 i 6a.
Ze wzgl˛edu na ogromna˛ pr˛edkość transmisji, tego typu łacza
˛ moga˛ być obecnie praktycznie
wykorzystywane jedynie w sieciach szkieletowych ogromnych instytucji i do łaczenia ˛ dużych
farm serwerów.
W normie IEEE 802.3ae (dotyczacej
˛ okablowania światłowodowego) przełomowe jest przede
wszystkim zaproponowanie dwóch warstw fizycznych — jednej dla sieci LAN (w tabeli 2.4
wszystkie standardy majace
˛ liter˛e R w nazwie), pracujacej ˛ z pr˛edkościa˛ 10 Gb/s i drugiej dla
sieci WAN (litera W w nazwie) działajacych˛ z pr˛edkościa˛ 9,58464 Gb/s. Ta druga pr˛edkość to
wynik zapewnienia zgodności wersji WAN standardu ze standardami SONET (OC-192) i SDH
(STM-64) — standardowa,˛ wykorzystywana˛ obecnie, infrastruktura˛ sieci WAN dużych opera-
torów telekomunikacyjnych. Dzi˛eki tej zgodności architektura 10 Gigabit Ethernet może zostać
wykorzystana do budowy sieci miejskich, a nawet rozległych.
26 2.3. Urzadzenia
˛ sieci Ethernet
Oznaczenie Dł. fali Typ światłowodu Transmisja Zasi˛eg

10G Base-SR/SW 850 nm wielomodowy szeregowa 26-65 m
10G Base-LR/LW 1310 nm jednomodowy szeregowa 10 km
10G Base-ER/EW 1550 nm jednomodowy szeregowa 40 km
10G Base-LX4 1310 nm wielomodowy WWDM 240-300 m
1310 nm jednomodowy WWDM 10 km
Tabela 2.4: Standardy sieci światłowodowych 10 Gigabit Ethernet.
Wprowadzono również dwa typy transmisji: szeregowa,˛ w której transmisja odbywa si˛e bit
po bicie oraz równoległa˛ wykorzystujac ˛ a˛ transmisj˛e WWDM (Wide Wavelength Division Mul-
tiplexing) — tzw. multipleksowanie zgrubne, które polega na tym, że transmisja odbywa si˛e
jednocześnie na 4 długościach fal (dzi˛eki temu można było uzyskać dosyć duże zasi˛egi sieci,
przy wykorzystaniu istniejacych
˛ światłowodów wielo- i jednomodowych, bez korzystania z na-
dajników laserowych dużej mocy).
Norma IEEE 802.3ak zdefiniowała sieci oznaczane jako 10G Base-CX4. Maksymalna dłu-
gość łacza
˛ w tym standardzie to 15 m. Został on pomyślany przede wszystkim do łaczenia˛ mi˛e-
dzy soba˛ urzadzeń
˛ znajdujacych
˛ si˛e w jednym centrum danych. Nie zdobył dużej popularno-
ści, a w najbliższej przyszłości zostanie prawdopodobnie całkowicie wyparty przez rozwiazania
˛
zgodne z IEEE 802.3an.
Ten ostatni standard (oznaczany 10G Base-T) pozwala na transmisj˛e z pr˛edkościa˛ 10 Gb/s
w sieci Ethernet przy wykorzystaniu skr˛etki komputerowej. Warto jednak zwrócić uwag˛e, że mu-
si to być okablowanie spełniajace ˛ najwyższe obecnie ratyfikowane normy. Dla okablowania kat.
6 przewidziany norma˛ zasi˛eg sieci 10G Base-T to 37 m (przy dobrych parametrach okablowania
może działać do ok. 50 m). Dla okablowania kat. 6a norma przewiduje zasi˛eg do 100 m.
W standardzie 10 Gigabit Ethernet ostatecznie zrezygnowano z wspierania transmisji półdu-
pleksowej (CSMA/CD), dzi˛eki temu nie trzeba si˛e martwić o wykrywanie kolizji i dostosowywać
do tego długość ramki i segmentu sieci.
Obecnie opracowywane sa˛ standardy, które maja˛ umożliwić w przyszłości budowanie sieci
Ethernet o przepustowości 40 i 100 Gb/s.
2.3. Urzadzenia
˛ sieci Ethernet
We współczesnych sieciach Ethernet mamy do czynienia z dwoma typami urzadze ˛ ń sieciowych:
koncentratorem i przełacznikiem.
˛ Zewn˛etrznie niczym si˛e od siebie nie różnia˛ i tylko pasjonat
sieci komputerowych potrafi na pierwszy rzut oka rozróżnić modele poszczególnych producen-
tów (podobnie jak pasjonat motoryzacji potrafi na pierwszy rzut oka określić mark˛e i podać para-
metry techniczne wskazanego pojazdu). Mimo, że urzadzenia
˛ te sa˛ tak podobne, ich właściwości
i funkcjonalność sa˛ zdecydowanie różne:
Koncentrator (ang. hub) jest prostym rozwini˛eciem idei repeatera. Mimo, że jest to obecnie
zazwyczaj urzadzenie
˛ wyposażone w wiele portów skr˛etki komputerowej lub portów światło-
wodowych, wewn˛etrznie wszystkie te porty podłaczone
˛ sa˛ do wspólnej szyny. Każda z ramek
odebrana przez jeden z portów trafia do wspólnej szyny i jest przesyłana przez wszystkie pozo-
stałe porty; tak wi˛ec mimo, że fizycznie sieć ma topologi˛e gwiazdy, to logicznie zachowuje si˛e
jakby była szyna.˛ Ma to wszystkie, omawiane wcześniej, wynikajace ˛ z takiej topologii, konse-
kwencje.
Koncentrator zawsze pracuje w trybie póldupleksu i wykorzystuje transmisj˛e CSMA/CD.
Współczesne koncentratory daja˛ możliwość łaczenia
˛ kilku urzadzeń
˛ w stos (stackowania).
Polega to na połaczeniu
˛ wewn˛etrznych szyn wszystkich urzadze ˛ ń w jedna˛ całość. Powoduje to,
że pasmo dost˛epne dla komputerów podłaczonych
˛ do wszystkich urzadze
˛ ń połaczonych
˛ w stos
jest takie samo, jakby wszystkie one były podłaczone
˛ tylko do jednego koncentratora.
Koncentratory były powszechnie używane w sieciach Ethernet 10 Mb/s i bywaja˛ używane
w sieciach Fast Ethernet. Praktycznie nie spotyka si˛e już ich w szybszych wersjach sieci Ethernet.
Przełacznik
˛ (ang. switch) jest z kolei pewnym rozwini˛eciem idei bridge’a. Można go sobie
wyobrazić jako bridge z duża˛ liczba˛ portów. Po rozpoznaniu topologii sieci, ramka odbierana
przez jeden port przełacznika
˛ jest przesyłana tylko na ten port, do którego jest podłaczony
˛ jej
odbiorca. Co wi˛ecej — dzi˛eki zastosowaniu odpowiednich matryc przełaczaj ˛ acych
˛ — możliwe
jest wykonywanie wielu takich operacji (na różnych portach) równolegle, w sposób niezależny
od siebie.
Wyróżnia si˛e dwa tryby pracy przełacznika:
˛
cut through — w tym trybie pracy decyzja o tym, do którego portu docelowego wysła ć nadcho-
dzac
˛ a˛ ramk˛e, jest podejmowana po odczytaniu adresu odbiorcy (DA). Dzi˛eki temu wpro-
wadzane jest minimalne opóźnienie przy przejściu ramki przez urzadzenie.
˛ Ma to jednak
pewne wady: wysyłanie rozpoczyna si˛e po odebraniu pierwszych 6 bajtów, jeśli ramka
jest uszkodzona, to przełacznik
˛ dowie si˛e o tym dopiero po sprawdzeniu sumy kontrolnej
(FCS) znajdujacej˛ si˛e na jej końcu — a wtedy już b˛edzie za późno, bo pakiet już prak-
tycznie trafił do sieci. Warto zapami˛etać, że w tym trybie pracy wszelkie bł˛edne ramki sa˛
przesyłane do sieci.
store & forward — ten tryb polega na tym, że najpierw cała ramka jest pobierana do bufora,
nast˛epuje jej sprawdzenie, a nast˛epnie jeśli jest nieuszkodzona jest przesyłana na port od-
biorcy. Ten tryb pracy jest wolniejszy, ale dokładniejszy. Musi być stosowany wsz˛edzie
tam, gdzie poszczególne porty pracuja˛ z różnymi pr˛edkościami.
Współczesne przełaczniki
˛ moga˛ działać w obu trybach. Jeśli stopa bł˛edów jest mała uruchamiany
jest tryb pracy cut through, a jeśli stopa bł˛edów rośnie, urzadzenie
˛ przełacza
˛ si˛e w tryb pracy
store & forward.
Przełaczniki
˛ moga˛ pracować zarówno w trybie dupleksu jak i półdupleksu, moga˛ być wypo-
sażone w porty o różnych szybkościach transmisji. Podobnie jak w przypadku koncentratorów,
niektóre modele przełaczników
˛ można łaczyć
˛ w stos, ale w takim przypadku nie mamy do czy-
nienia z łaczeniem
˛ szyn urzadzeń.
˛ Interfejsy do łaczenia
˛ w stos sa˛ logicznie traktowane jako do-
datkowe, bardzo szybkie porty (np. w przypadku przełaczników
˛ Fast Ethernet umożliwiaja˛ one
transmisj˛e z pr˛edkościami 1-2,5 Gb/s, zaś w przypadku przełaczników
˛ Gigabit Ethernet 30-40,
a nawet 80 Gb/s). Dzi˛eki temu połaczenie
˛ niewielkiej liczby przełaczników
˛ w stos nie powoduje
znaczacego
˛ spadku przepustowości.
28 2.4. Nowe właściwości sieci Ethernet
W szybkich sieciach Ethernet (np. Gigabit Ethernet) wykorzystywane sa˛ wyłacznie

˛ przełacz-
˛
niki.
2.4. Nowe właściwości sieci Ethernet

Pojawienie si˛e przełaczników
˛ — urzadzeń
˛ umożliwiajacych
˛ przetwarzanie informacji steruja-
˛
cych — pozwoliło na rozszerzenie właściwości dotad ˛ budowanych sieci o nowe interesujace
˛
funkcje. Poniżej omówione zostana˛ najważniejsze z nich.
2.4.1. Sieci wirtualne

Sieć wirtualna (VLAN) to logiczny segment, do którego w pewien sposób zostały przypisane
wybrane komputery z naszej sieci. W ramach jednej fizycznej sieci może istnieć wiele, nie ko-
munikujacych
˛ si˛e ze soba,˛ sieci wirtualnych (rys. 2.3).
Rysunek 2.3: Podział sieci komputerowej przedsi˛ebiorstwa na sieci wirtualne. Poszczególne sie-
ci VLAN oznaczono kolorami. Moga˛ one obejmować komputery podłaczone ˛ do różnych fizycz-
nych urzadzeń
˛ sieciowych.
Podział na sieci wirtualne odbywa si˛e przede wszystkim w celu lepszej ochrony pewnych
fragmentów sieci. Można sobie wyobrazić podział sieci komputerowej w taki sposób, że wy-
dzielone były by sieci wirtualne: serwisów internetowych, pracowników biurowych, badawcza,
finansowa itp. Każda z tych sieci może cechować si˛e własnymi zasadami bezpieczeństwa i moga˛
być dla siebie wzajemnie niewidoczne (chyba, że zdecydujemy si˛e je ze soba˛ połaczy
˛ ć korzysta-
jac
˛ z routera lub firewalla).
Przydział do sieci wirtualnej może odbywać si˛e na podstawie jednej z cech:
numeru portu urzadzenia,
˛ do którego podłaczony
˛ jest komputer,
adresu MAC komputera,
wykorzystywanego protokołu warstwy sieciowej,
adresu IP komputera.
Ponieważ zarówno adres IP, jak i wykorzystywany na komputerze stos protokołów może zo-
stać przez użytkownika łatwo zmieniony, przydział do sieci wirtualnej na podstawie tych dwóch
kryteriów wydaje si˛e mało bezpieczny.
Historycznie pierwszym sposobem przydziału do sieci wirtualnej był przydział na podstawie
numeru portu (rys. 2.4).
Rysunek 2.4: Przykład konfiguracja sieci VLAN — przydział na podstawie numerów portów
(numery portów podane sa˛ w lewej kolumnie, sieci wirtualne oznaczono V1-V8).
Ten sposób przydziału można było łatwo zaimplementować w przełaczniku.˛ Jak jednak wy-
mieniać mi˛edzy urzadzeniami
˛ sieciowymi informacje o zdefiniowanych sieciach VLAN? W tym
celu opracowano standard IEEE 802.1Q rozszerzajacy ˛ ramk˛e Ethernet o dodatkowe pole (znacz-
nik) przechowujace˛ m.in. identyfikator sieci VLAN (rys. 2.5).
Dzi˛eki zastosowaniu tego rozwiazania,
˛ każda ramka Ethernet, przesyłana w naszej sieci kom-
puterowej, może zawierać identyfikator sieci VLAN, do której należy. Jednak ten format ramki
nie jest dobrze obsługiwany przez wszystkie sterowniki sieciowe komputerów osobistych. Dla-
tego też powinien być używany tylko na tych łaczach,
˛ które służa˛ do komunikacji urzadze
˛ ń
sieciowych mi˛edzy soba.˛ Poszczególne komputery zazwyczaj należa˛ tylko do jednej sieci wirtu-
alnej9 i nie musza˛ stale otrzymywać tej informacji. Również ze wzgl˛edów bezpieczeństwa sieci
wskazane jest, aby ramki z informacjami o numerze sieci wirtualnej były przesyłane tylko w tych
miejscach, gdzie jest to absolutnie niezb˛edne (najlepiej wyłacznie
˛ w szkielecie sieci).
Standard IEEE 802.1Q umożliwia zdefiniowanie do 4094 sieci wirtualnych (rys. 2.6). Nume-
racja sieci VLAN musi być spójna na wszystkich urzadzeniach
˛ sieciowych. Przykład konfigura-
cji VLAN 802.1Q dla dwóch przełaczników
˛ połaczonych
˛ w stos przedstawiono na rysunku 2.7.
9 Może si˛
e zdarzyć, że serwer może obsługiwać wiele sieci wirtualnych, musi być wtedy wyposażony w specjalna˛
kart˛e sieciowa˛ i sterowniki umożliwiajace
˛ obsług˛e standardu IEEE 802.1Q.
Ramka Ethernet II Ramka 802.1Q

DA DA
SA SA
typ typ 802.1Q = 0x8100
VLAN ID
dane typ
FCS dane
FCS
Rysunek 2.5: Sposób rozszerzenia ramki Ethernet zdefiniowany w standardzie IEEE 802.1Q.
15 12 0
CFI
Pri VLAN ID
Priorytet VLAN ID 12 bitów
802.1p do 4094 sieci
wirtualnych
Rysunek 2.6: Budowa dodatkowego pola ramki Ethernet standardu IEEE 802.1Q zawierajacego
˛
informacje o identyfikatorze VLAN i priorytecie.
2.4.2. Priorytety ruchu

W znaczniku dodanym przez standard IEEE 802.1Q przewidziano również pole (Pri) służace ˛ do
określania priorytetu ramki w sieci Ethernet (rys. 2.6). Znaczenie tego pola opisuje standard IE-
EE 802.1p, który ostatnio został właczony
˛ do nowej wersji standardu IEEE 802.1D. To trzybito-
we pole pozwala na ustawienie 8 poziomów priorytetów. Jednak w rzeczywistych urzadzeniach ˛
sieciowych zapewnianych jest od dwóch do 4 poziomów priorytetów, dlatego też urzadzenia ˛
takie daja˛ możliwość zdefiniowania, które priorytety 802.1p odpowiadaja˛ którym priorytetom
sprz˛etowym (np. priorytety 0-3 to „niski” priorytet sprz˛etowy, a priorytety 4-7 to priorytet „wy-
soki”).
Jak realizowane jest zapewnienie priorytetów? W przełaczniku
˛ na portach wyjściowych znaj-
duja˛ si˛e dwa lub wi˛ecej buforów. W zależności od przyznanego priorytetu, ramka trafia albo do
jednego, albo do drugiego bufora. Przy wysyłaniu ramek do sieci, przełacznik˛ najpierw opróż-
nia bufor o wi˛ekszym priorytecie, a nast˛epnie bufor o priorytecie niższym. W ten sposób ramki
o wyższym priorytecie zawsze b˛eda˛ miały pierwszeństwo w dost˛epie do sieci. Ten mechanizm
jest mi˛edzy innymi podstawa˛ budowy sieci transmisji głosu (np. w technologii VoIP — Voice
over IP). Sieci Ethernet zapewniaja˛ obecnie dostatecznie duże pasmo do takich transmisji, ale
konieczne jest zapewnienie odpowiednich parametrów czasowych — i to właśnie jest osiagane ˛
za pomoca˛ priorytetów.
Rysunek 2.7: Konfiguracja sieci VLAN 802.1Q. Literami T i U oznaczono przynależność po-
szczególnych portów do wskazanej sieci wirtualnej. U oznacza port wysyłajacy
˛ standardowe
ramki Ethernet, T — port wysyłajacy
˛ ramki rozszerzone o znacznik 802.1Q.
Warto jednak pami˛etać, że jest to sposób jedynie na zapewnienie pewnego priorytetu transmi-
sji, a nie gwarancja odpowiedniej jakości tej transmisji (jak to ma miejsce np. w sieciach ATM).
W przypadku natłoku, czyli sytuacji, w której liczba nadchodzacych˛ ramek przekroczy pojemość
buforów, b˛eda˛ odrzucane również i te ramki, które sa˛ oznaczone wysokim priorytetem.
2.4.3. Spanning Tree Protocol

Kolejnym protokołem, który znaczaco ˛ rozszerza funkcjonalność sieci Ethernet jest STP (Span-
ning Tree Protocol) — został on zdefiniowany w ramach standardu IEEE 802.1D. Umożliwia on
zarzadzanie
˛ łaczami
˛ zapasowymi w sieci Ethernet. W zwykłej sieci Ethernet istnienie połacze ˛ ń
zapasowych może spowodować p˛etl˛e . Pakiet, który trafiłby do takiej p˛etli, krażyłby
˛ w niej stale,
a kolejne wysyłane do takiej sieci pakiety spowodowałyby całkowite zablokowanie łacza. ˛
Protokół STP umożliwia przełaczenie
˛ nadmiarowych łaczy ˛ w stan nieaktywny i ich aktywo-
wanie tylko w przypadku awarii odpowiedniego łacza ˛ podstawowego (tak jak to wida ć na rysun-
ku 2.8) . Działa w ten sposób, że przy rozpoznawaniu topologii sieci, tworzony jest acykliczny
graf rozpinajacy
˛ — taki podzbiór wszystkich połacze ˛ ń, który zapewnia doście do każdego ele-
mentu sieci, a jednocześnie nie zawiera p˛etli. W przypadku awarii któregoś z połaczeń, ˛ graf
rozpinajacy
˛ jest tworzony ponownie itd.
O tym, które łacza
˛ zostana˛ w pierwszej kolejności właczone
˛ do grafu, decyduja˛ dwa czynni-
10
ki: tzw. koszt ścieżki (path cost) oraz priorytet łacza
˛ nadany przez administratora. Koszt ścieżki
10
Jest to poj˛ecie umowne, na ogół nie majace
˛ nic wspólnego z rzeczywistym kosztem ekonomicznym łacza.
˛
Rysunek 2.8: Protokół STP przełacza

˛ nadmiarowe łacza
˛ w stan nieaktywny. W przypadku awarii
jednego z łaczy,
˛ uruchamia łacze
˛ zapasowe.
jest obliczany jako suma kosztów wszystkich łaczy ˛ bioracych

˛ udział w połaczeniu
˛ mi˛edzy dwo-
ma urzadzeniami.
˛ Koszt zaś pojedynczego łacza
˛ jest definiowany np. jako:
1000
przepustowość łacza
˛ w Mb/s
Do grafu wybierane sa˛ ścieżki o najniższym koszcie, czyli w warunkach normalnej pracy zawsze
zostanie wybrane połaczenie
˛ o wyższej przepustowości.
W przypadku dwóch połaczeń
˛ o tej samej przepustowości, administrator ma możliwość okre-
ślenie priorytetu dla każdego z łaczy.
˛ Do grafu jest wybierane łacze
˛ o wyższym priorytecie
(rys. 2.9).
Rysunek 2.9: Przykładowa konfiguracja STP.
Czas potrzebny na przełaczenie

˛ na łacze
˛ zapasowe w momencie awarii podstawowego (nie-
zb˛edny do uzgodnienia mi˛edzy urzadzeniami
˛ nowego grafu rozpinajacego)
˛ jest dosy ć długi.
W zależności od wielkości sieci może trwać nawet kilkadziesiat

˛ sekund. Dlatego też wprowadzo-
ny został standard IEEE 802.1w: Rapid Spanning Tree znacznie zmniejszajacy ˛ czasy oczekiwa-
nia na odpowiedzi poszczególnych urzadze ˛ ń sieciowych i przez to skracajacy
˛ czas przełaczenia.
˛
2.4.4. Agregacja łaczy

˛
Ostatnim ze nowym standardów znaczaco ˛ podnoszacych
˛ funkcjonalność sieci Ethernet jest IE-
EE 802.3ad. Umożliwia on scalenie do czterech łaczy
˛ fizycznych w jedno łacze
˛ logiczne o odpo-
wiednio wi˛ekszej przepustowości (400 Mb/s w przypadku Fast Ethernetu, 4 Gb/s w przypadku
Gigabit Ethernetu). Ruch jest równomiernie dzielony pomi˛edzy wszystkie łacza ˛ fizyczne. W
przypadku awarii któregoś z łaczy,
˛ które tworza˛ połaczenie
˛ logiczne, pozostałe przejmuja˛ nad-
chodzacy
˛ ruch i o ile ta zmniejszona przepustowość b˛edzie wystarczajaca, ˛ użytkownicy sieci
moga˛ nawet nie odczuć tego, że jedno łacze
˛ zostało wyłaczone.
˛
Konfiguracja tego typu pracy jest bardzo prosta i polega na wskazaniu numerów portów, które
maja˛ brać udział w połaczeniu
˛ logicznym (rys. 2.10).
Rysunek 2.10: Przykładowa konfiguracja agregacji łaczy.

˛
Wi˛ekszość nowoczesnych urzadzeń

˛ sieciowych umożliwia stosowanie agregacji łaczy.
˛ Gdy-
byśmy jednak chcieli wykorzystać t˛e technik˛e do podłaczenia
˛ serwerów, konieczny jest zakup
odpowiedniej karty wieloportowej wraz ze sterownikami wspierajacymi˛ IEEE 802.3ad.
2.5. Podsumowanie
Mimo swojego wieku (bardzo już s˛edziwego jak na technologie sieciowe), Ethernet okazuje si˛e
zaskakujaco
˛ żywotny. Jest to obecnie jeden z najszybciej rozwijajacych
˛ si˛e standardów IT. Ether-
34 2.5. Bibliografia
net pojawia si˛e w obszarach, które dotad

˛ były zarezerwowane wyłacznie˛ dla wyspecjalizowanych
protokołów sieciowych. Trafia do sieci miejskich, rozległych i bezprzewodowych. Trwaja˛ prace
nad standardem Ethernet dla sieci dost˛epowych (EFM — Ethernet in the First Mile). Prowadzo-
ne sa˛ prace badawcze zmierzajace˛ do opracowania nowych standardów: Ethernetu 40 Gb/s i 100
Gb/s.
Jak si˛e wydaje, można z duża doza˛ pewności założyć, że sieci tego typu b˛eda˛ nam towa-
rzyszyły jeszcze długie lata. Wprawdzie coraz mniej b˛eda˛ przypominały pierwotna˛ koncepcj˛e
sieci panów Roberta Metcalfe’a i Davida Boggsa, ale za to b˛eda˛ umożliwiały transmisj˛e ruchu
multimedialnego z wielkimi przepustowościami na duże odległości.
Bibliografia
[1] Krzysztof Nowicki, Józef Woźniak. Przewodowe i bezprzewodowe sieci LAN. Oficyna
Wydawnicza Politechniki Warszawskiej, wydanie I, Warszawa, 2002.
[2] Adam Wolisz. Podstawy lokalnych sieci komputerowych. Sprz˛et sieciowy. Wydawnictwo
Naukowo-Techniczne, wydanie II, Warszawa, 1992.
R OZDZIAŁ 3
Sieci Frame Relay
Technologia Frame Relay powstała w zwiazku ˛ z zapotrzebowaniem użytkowników sieci Internet

na szybka˛ i wydajna˛ technologi˛e do transmisji danych. Wynikało to z:
rosnacej
˛ popularności środowisk graficznych wśród użytkowników,
rosnacego
˛ zapotrzebowania na pasmo przez aplikacje,
rosnacej
˛ możliwości obliczeniowych komputerów PC, które wymagały szybszego dostar-
czania danych,
stale powi˛ekszajacej
˛ si˛e liczby użytkowników sieci Internet,
rosnacej
˛ popularności sieci LAN i konieczności podłaczania
˛ ich do sieci operatorów.
Technologia FR była stosunkowo niedroga i pozwalała nawet na podłaczanie ˛ bezpośrednio do
sieci FR komputerów użytkowników.
Poczatkowo
˛ FR była rozwijana w laboratoriach Bell Labs jako fragment specyfikacji techno-
logii ISDN. Jednak sukces jaki odniosła spowodował, że wkrótce stała si˛e odr˛ebna˛ technologia˛
sieciowa.˛ Można powiedzieć, że FR była właściwym rozwiazaniem
˛ w odpowiednim czasie, czy-
li poczatku
˛ lat Mogła współpracować z ATM, była skalowalna, elastyczna, z niskim narzutem
nagłówków w pakietach i wysoka˛ dost˛epnościa.˛ Dopiero ostatnie lata z rosnac
˛ a˛ popularnościa˛ na
rozwijanie usług zwiazanych
˛ z przesyłaniem strumieni audio i video w sieciach komputerowych
spowodowało, że zacz˛eto szukać innych rozwiazań.
˛ Zwłaszcza, że konkurencyjny Ethernet, roz-
wijany od ponad 30 lat, przekroczył barier˛e stosowania go tylko w sieciach LAN i zaczał ˛ by ć
stosowany w sieciach rozległych.
3.1. Budowa sieci

Sieć FR jest siecia˛ pakietowa˛ z komunikacja˛ połaczeniow
˛ a.˛ Pracuje na poziomie drugiej warstwy
modelu ISO/OSI (patrz rys. 3.1)
Podstawowe zadanie sieci FR jest bardzo proste: dostarczyć dane w bezpieczny sposób mi˛e-
dzy dwoma maszynami. Rodzaj danych nie ma żadnego znaczenia. Dane, po otrzymaniu ich od
warstw wyższych, sa˛ enkapsułowane w nagłówki FR oraz pole pozwalajace ˛ na wykrycie bł˛e-
dów w ramce. Pole to jest sprawdzane w pierwszej kolejności przez maszyn˛e odbierajac ˛ a˛ ramk˛e.
Jeżeli bład
˛ nie zostanie wykryty sprawdzane sa˛ dalsze pola z nagłówka.
Operacje wykonywane przez FR na poziomie warstwy łacza ˛ danych sa˛ dużo prostsze niż
w innych protokołach. Jest to jedna z przyczyn szybkiego przesyłania danych przez sieci FR.
W szczególności operacje te sprowadzaja˛ si˛e do: użycia flagi do sprawdzenia pojawienia si˛e
ramki w łaczu
˛ oraz sprawdzenia, czy ramka nie zawiera bł˛edów. Jeśli jest uszkodzona zostaje
usuni˛eta i warstwa łacza
˛ danych nie wykonuje żadnych operacji zwiazanych
˛ z retransmisja. ˛
35
36 3.1. Budowa sieci
Warstwy OSI Sieci FR
sieciowa X-25
³¹cza Frame Relay
fizyczna SDH
Rysunek 3.1: Frame Relay w modelu OSI.
Zazwyczaj protokoły transmisji danych używaja˛ mechanizmu potwierdzania otrzymania pa-

kietu z danymi. Po otrzymaniu potwierdzenia, komputer wysyłajacy ˛ dane, może wykasowa ć
kopi˛e ramki ze swoich buforów. W przypadku nie otrzymania potwierdzenia ramka zostanie
wysłana jeszcze raz. W operacje te nie jest angażowana aplikacja wysyłajaca/odbieraj
˛ aca
˛ dane.
Program użytkownika „ufa” warstwom niższym, że prześla˛ przez sieć potrzebne mu dane.
Sieć FR wszystkie operacje zwiazane
˛ z wykrywaniem bł˛edów przenosi na maszyn˛e odbie-
rajac
˛ a˛ lub wysyłajac˛ a˛ dane – UNI (ang. User-to-Network Interface). Konwencjonalna operacja
CRC (ang. Cyclic Redundancy Check) jest wykonywana przy użyciu pola FCS (ang. Frame
Check Sequence). Jednak jeżeli zostanie wykryty bład, ˛ powstały podczas transmisji, ramka jest
usuwana a do nadawcy wysyłane jest negatywne potwierdzenie odebrania ramki.
Dzi˛eki temu, że potwierdzaniem odbioru ramek w sieci FR zajmuja˛ si˛e stacje ko ńcowe, prze-
syłanie danych w w˛ezłach może odbywać si˛e znacznie szybciej. Szybkość ta jest funkcja˛ szyb-
kości działania danego w˛ezła oraz wielkości ruchu, który obsługuje. Maksymalna przepustowość
jaka˛ może zapewnić to 34 Mb/s. Ponieważ swoje działanie opiera na łaczach
˛ cyfrowych sieć FR
charakteryzuje niska stopa bł˛edów. Ponadto urzadzenia˛ obsługujace
˛ sieci FR potrafia˛ wykry ć
bł˛edy nagłówka, formatu, cyklicznego kodu nadmiarowego FCS pakietu. Ramki z wykrytym
bł˛edem sa˛ usuwane z sieci przez urzadzenie,
˛ które stwierdziło wystapienie
˛ bł˛edu. Do urzadzenia
˛
które wysłało uszkodzona˛ ramk˛e wysyłane jest negatywne potwierdzenie jej odbioru i nast˛epu-
je retransmisja. Przyczyn˛e, dla której sieć FR „spycha” obowiazki˛ zwiazane˛ z potwierdzaniem
odbioru rami, przedstawia rys. 3.2
Jak widać w konwencjonalnym rozwiazaniu
˛ pole z danymi jest przechowywane w buforze do
czasu zakończenia wykonywania operacji wykrywania bł˛edu. W tym czasie dane nie moga˛ by ć
wysłane dalej. Przy takim podejściu maszyna, urzadzenie
˛ przesyłajace
˛ musi czekać na otrzyma-
nie całej ramki z polem danych żeby móc zaczać ˛ procedur˛e CRC. Po jej zakończeniu wysyłane
jest potwierdzenie lub negatywne potwierdzenie otrzymania ramki.
Ponieważ jednak w sieci FR urzadzenia
˛ pośredniczace
˛ w przesyłaniu nie wysyłaja˛ potwier-
Sieci Frame Relay 37
Rysunek 3.2: Sprawdzanie bł˛edów w ramkach.
dzeń, nie musza˛ one czekać na otrzymanie całej ramki z danymi. Moga˛ ja˛ zaczać ˛ transmitować
dalej już po otrzymaniu nagłówka. Dzi˛eki temu sieć FR nie musi stosować techniki „zapami˛etaj
i wyślij” (ang. store-and-forward) i w skuteczny sposób zmniejszyć opóźnienia w transmisji ra-
mek. Takie podejście do przełaczania
˛ ramek jest nazywane „przekaż dalej” (ang. cut-through).
Wada˛ takiego podejścia jest niemożność sprawdzenia czy ramka nie uległa uszkodzeniu aż do
momentu kiedy dotrze do odbiorcy.
Oczywiście takie podejście ma swoje dobre i złe strony. W sieciach z niska˛ stopa˛ bł˛edów
można sobie pozwolić na wykrywanie uszkodzeń ramek przez stacje końcowe. Jest to znacznie
bardziej efektywne niż wymiana dodatkowych komunikatów przez urzadzenia ˛ pracujace
˛ w sieci.
Typowa˛ infrastruktur˛e sieci FR przedstawia Rys. 3.3
Urzadzenia
˛ pracujace
˛ w szkielecie cz˛esto sa˛ nazywane siecia˛ FR. Nazwa bierze si˛e z faktu,
że nie stanowia˛ one prostego połaczenia
˛ punktów na brzegach sieci. Sa˛ one połaczone
˛ logicznymi
ścieżkami zdefiniowanymi w sieci. Szkielet sieci tworzy topologi˛e gwiazdy. Choć niekoniecznie.
Sieć FR pozwala elastycznie dostosowywać topologi˛e do aktualnych potrzeb. Urzadzenia ˛ moga˛
być cz˛eściowo połaczone
˛ każde z każdym (ang. full mesh) a dalej tworzyć struktur˛e gwiazdy.
Sieć FR WAN używa dwukierunkowej komunikacji połaczeniowej
˛ mi˛edzy każda˛ para˛ urza-
˛
dzeń dost˛epowych DTE (ang. Data Terminal Equipment) takich jak: FRAD-y (ang. Frame Relay
Access Devices), terminale, komputery, rutery, mosty (ang. bridge) czy multipleksery. Ścieżka
38 3.1. Budowa sieci
Sieæ
Frame Relay HOST
PAD HOST
FRAD
LAN
Urz¹dzenia
koñcowe
u¿ytkowników
LAN
Rysunek 3.3: Sieć Frame Relay.
łacz
˛ aca
˛ dwa takie urzadzenia
˛ może przebiegać przez kilka w˛ezłów DCE (ang. Data Circut – ter-
minating Equipment), połaczonych
˛ ze soba˛ kanałami fizycznymi. Tak jak przedstawia to rys. 3.4.
DLCI 1
Sieæ
Frame Relay
B
LAN LAN
A C
DLCI 3
DLCI 2
LAN
LAN
Rysunek 3.4: Sieć Frame Relay – kanały DLCI.
Jednym mi˛edzyw˛ezłowym połaczeniem

˛ może przebiegać wiele takich ścieżek nazywanych
obwodami logicznymi lub wirtualnymi. Każdy taki obwód ma przypisany mu przez administra-
torów sieci numer identyfikacyjny DLCI (ang. Data–Link Connection Identifier). Każdy pakiet
przesyłany w sieci FR ma w nagłówku numer DLCI obwodu logicznego, do którego należy.
Sieć FR idealnie nadaje si˛e do obsługi ruchu jaki typowo generuja˛ użytkownicy, czyli spo-
radycznego, rzadko wykorzystujacego˛ całkowite dost˛epne pasmo. Z tego powodu jest ta techno-
logia jest ch˛etnie wykorzystywana przez operatorów telekomunikacyjnych do podłaczania ˛ sieci
LAN klientów do sieci Internet. Najcz˛eściej do takiego podłaczenia
˛ wykorzystywane sa˛ rutery
lub komputery PC z odpowiednimi kartami. Do ruterów, kart przyłaczone ˛ sa˛ modemy lub kon-
wertery (najcz˛eściej działajace
˛ w którejś z odmian technologii DSL (ang. Digital Subscriber Li-
ne), np. HDSL, ADSL. Urzadzenia˛ te sa˛ podłaczone
˛ bezpośrednio do jednoparowego przewodu
miedzianego (niektóre modemy, np. firmy RAD pozwalaja˛ na podłaczenie ˛ dwóch par przewo-
dów), do którego na drugim końcu jest przyłaczone˛ analogiczne urzadzenie.
˛ Użycie wi˛ekszej
liczby par pozwala podnieść maksymalna˛ szybkość transmisji modemów lub konwerterów. In-
nym możliwym sposobem jest użycie podobnego zestawu urzadze ˛ ń (rutery, konwertery) do ła-˛
czenia sieci LAN z Internetem przy wykorzystaniu światłowodu. Wówczas potrzebne sa˛ jeszcze
mulipleksery, które pozwalaja˛ na wydzielanie kanałów cyfrowych w traktach światłowodowych.
Zaleta˛ drugiego rozwiazania
˛ jest jego zasi˛eg. Dobrej klasy multipleksery pozwalaja˛ na transmisj˛e
sygnału na dziesiatki

˛ kilometrów. W przypadku kabli miedzianych najcz˛estszym problemem jest
ich duża stopa bł˛edów. Dla sieci FR musi ona być poniżej 10 8 . Jeśli kabel spełnia ten warunek
można uzyskać przepustowości ok. 1 Mb/s na odcinkach ok. 10 km. Przy krótszych połaczeniach
˛
i dobrej jakości kablach nowoczesne modemy pozwalaja˛ na transmisj˛e danych z szybkościa˛ na-
wet 4 Mb/s. Przepustowości jakie operatorzy najcz˛eściej oferuja˛ w swoich cennikach to 64 – 256

kb/s, 512 – 1 Mb/s, 1536 – 2 Mb/s. Oczywiście można z operatorem negocjować zestawienie
˛ o przepustowości n 2Mb s n 1. Oprócz tego, dla kanałów o takich przepustowościach,
łacza
cenniki zawieraja˛ minimalna˛ wartość CIR, którego wartość domyślnie wynosi 0 kb/s.
W Polsce z reguły wystarczaja˛ oferowane przez operatorów szybkości kanałów, gdyż jakość
łaczy
˛ nie pozwala na dużo wi˛ecej. Rozwiazaniem
˛ wówczas staje si˛e możliwość skorzystania
z łaczy
˛ radiowych.
3.2. Protokół transmisji

Format pakietu FR przedstawia rys. 3.5.
bajty
1 2 0-8188 2 1
FLAGA NAG£ÓWEK DANE FCS FLAGA
DLCI CIR EA DLCI FECN BECN OE EA

8 2 1 8 4 3 2 1
bity
Rysunek 3.5: Nagłówek ramki FR.
Do danych użytkownika dodawany jest dwubajtowy nagłówek. Domyślnie wielkość ramki

to 4096 bajtów. Maksymalnie może ona wynosić 8188 bajtów.
W zależności od tego, na jak długo obwody sa˛ zestawione w sieci dzieli si˛e je na dwie grupy:
1. stałe PVC (ang. Permanent Virtual Circuits) – bardzo popularne i jedynie dost˛epne na
poczatku
˛ istnienia sieci FR. Zestawiane na stałe (aż do nast˛epnej zmiany),
2. przełaczane
˛ SVC (ang. Switched Virtual Circuits) zestawiane na żadanie.
˛ Używane sa˛ nie-
co rzadziej niż PVC, choć ich popularność na pewno jest wyższa niż w latach poprzednich.
Każde z takich połaczeń
˛ logicznych jest charakteryzowane dwoma parametrami transmisyj-
nymi:
40 3.2. Protokół transmisji
CIR (ang. Committed Information Rate),

EIR (ang. Excess Information Rate).
W przypadku kanałów PVC sa˛ one ustalane raz, przy zestawieniu łacza ˛ i nie sa˛ potem renego-
cjowane. Kanały SVC ustalaja˛ te parametry każdorazowo przy zestawianiu połaczeniu.
˛
CIR określa gwarantowana˛ przepływność minimalna. ˛ Pozwala on sieci dostosować si˛e do
aplikacji generujacych
˛ tzw. ruch wybuchowy (w którym niekiedy pojawia si˛e duża liczba danych
w krótkim czasie). Miara˛ tej wybuchowości jest parametr Bc (ang. Committed Burst). Jest to ilość
danych w bitach, która˛ sieć zgadza si˛e przenieść w normalnych warunkach w przedziale czasu
Tc . Dane moga˛ być przenoszone w formie jednej lub wielu ramek. Jeśli szybkość transmisji
przekracza wartość CIR, to ramki maja˛ ustawiany bit DE (ang. Discard Eligibility).
Z kolei EIR określa nie gwarantowana˛ przepływność maksymalna.˛ Z EIR zwiazany˛ jest pa-
rametr Be oznaczajacy
˛ ilość nadmiarowych danych w bitach, które sieć zgadza si˛e przesłać, jeśli
istnieja˛ wolne zasoby.
Całkowita przepustowość dost˛epna dla użytkownika równa jest CIR + EIR. Ramki powodu-
jace
˛ przekroczenie tej wartości sa˛ definitywnie odrzucane. Przykładowo, jeśli u operatora mamy
wykupiony kanał wirtualny o parametrach CIR = 64 kb/s i EIR = 512 kb/s, to sieć podejmie pró-
b˛e przeniesienia chwilowego ruchu z maksymalna˛ przepustowościa˛ 576 kb/s. Przykład ilustruje
rysunek 3.6.
bity
Ramki odrzucone w wêŸle wejœciowym o

jneg
Bc+Be is y
m
ns
Ramki oznaczone bitem DE tra
m
e diu
Bc m
u do
têp
do
s CIR
œ æ
bko
y
Sz
czas
T0 T0+Tc
ramka 1 ramka 2 ramka 3 ramka 4
Rysunek 3.6: Zależność szybkości transmisji danych w kanałach od wartości CIR i EIR.
Ramki transmitowane z szybkościa˛ przekraczajac˛ a˛ wartość CIR + EIR maja˛ ustawiany bit DE
i moga˛ być usuwane z sieci FR przez urzadzenia,
˛ które sa˛ przeciażone.
˛ Jeżeli szybkość wybu-
chowego ruchu przekracza możliwości sieci do przeniesienia go (parametry Be Bc ), wówczas
urzadzenie
˛ w w˛eźle wejściowych zajmuje si˛e usuwaniem ramek nadchodzacych ˛ z szybkościa˛
przekraczajac˛ a˛ ten limit.
3.3. Sterowanie przeciażeniami

˛
Najpowszechniejszym mechanizmem sterowania przeciażeniami ˛ w sieci jest adaptacja okna emi-
syjnego do warunków panujacych ˛ w sieci. Podobnie jak w przypadku protokołu TCP lub pro-
tokołu X.25. Jednakże w sieci FR nie można w pełni wykorzystać tego mechanizmu, jak np.
w protokole TCP. Nie ma bowiem zaimplementowanych odpowiednich mechanizmów kontroli.
Zachowanie si˛e sieci FR w przypadku przeciażenia ˛ zależy do zaimplementowanych w niej pro-
tokołów. Jeśli w sieci FR dojdzie do przeciażenia
˛ to wówczas przeciażony
˛ w˛ezeł DCE wysyła
komunikaty do nadajacych
˛ urzadze
˛ ń DTE, a te przekazuja˛ je dalej do stacji końcowych. W koń-
cu docieraja˛ one do protokołów warstw wyższych na tych stacjach. Dopiero one moga˛ wpływa ć
na emisj˛e ramek przez odpowiednio ograniczajac ˛ lub zwi˛ekszajac
˛ ich rozmiar i szybkość prze-
syłania. Widać wi˛ec, że reakcje na przeciażenia
˛ w sieci FR nie sa˛ tak szybkie jak w sieciach
TCP/IP. Dlatego też chcac˛ wykorzystywać FR w warstwie łacza ˛ danych przy obsłudze transmisji
danych audio lub video należy używać jeszcze innych protokołów, np. RSVP (ang. Resource
Reservation Protocol). FR jako takie umożliwia implementowanie nast˛epujacych ˛ mechanizmów
sterowania przeciażeniami:
˛
FECN (ang. Forward Explicit Congestion Notification),
BECN (ang. Backward Explicit Congestion Notification),
CLLM (ang. Consolidated Link Layer Manager),
prosta kontrola przepływu (ang. Simple flow control).
Ponieważ komunikaty o przeciażeniu,
˛ wysyłane przez DCE i przekazywane dalej przez DTE,
musza˛ być obsłużone najpierw przez te typy urzadze ˛ ń, informuja˛ si˛e one nawzajem w jawny
sposób o wystapieniu
˛ przeciażenia.
˛ Robia˛ to za pomoca˛ jednobitowych informacji zaszytych
w nagłówku ramki. Odbiorca otrzymuje bit FECN, nadawca BECN. Urzadzenie ˛ DTE musi od-
powiedzieć na sygnał BECN zmniejszeniem szybkości transmisji. W przeciwnym razie DCE
zacznie kasować ramki, którym nadawca nadał niższy priorytet. Może również arbitralnie nada-
wać niższy priorytet wszystkim ramkom z przepływnościa˛ przekraczajac ˛ a˛ CIR. BECN/FECN
jest najpopularniejszym sposobem informowania o przeciażeniach.˛
Dane audio oraz video w sieciach FR można przesyłać na dwa sposoby. Pierwszy polega na
wykorzystaniu FR jako takiej bez żadnych „modyfikacji”. Urzadzenia ˛ obsługujace˛ FR wspieraja˛
tego typu transmisje poprzez stosowanie:
kodowania i kompresji głosu,
wykrywania sygnałów mowy,
kasowania echa,
używania buforów niwelujacych
˛ zmiany opóźnień w czasie (ang. jitter),
kształtowania ruchu,
fragmentacji pakietów ze zwykłymi danymi,
zmniejszania wielkości ramek,
dynamicznej kontroli przeciażeń,
˛ wykorzystujacej˛ mechanizmy kolejek i odrzucania pa-
kietów z danymi,
przesyłania danych głosowych przez kolejki o wyższych priorytetach obsługi, niż te ze
zwykłymi danymi.
W rzeczywistości, urzadzenia
˛ obsługujace
˛ FR używaja˛ kombinacji tych mechanizmów. W ten
sposób zmniejszaja˛ one zapotrzebowanie na pasmo oraz przeciwdziałaja˛ opóźnieniom i stratom
pakietów z danymi głosowymi. Mimo wszystko, brak zapewnienia mechanizmów sterowania
42 3.4. Podsumowanie
przeciażeniami
˛ na poziomie protokołu FR jest wada,˛ która została zniwelowana tylko w ogra-
niczonym stopniu. Dlatego też najcz˛eściej, przy przesyłaniu danych głosowych, stosowane jest
przesyłanie ich w pakietach protokołu IP przy wykorzystaniu FR (ang. Voice over IP over Fra-
me Relay). Dzi˛eki protokołowi IP możliwe jest już stosowanie protokołu RSVP, RTP (ang. Real
Time Protocol) oraz kompresj˛e nagłówków RTP.
3.3.1. Protokół LMI

Protokół interfejsu zarzadzania
˛ LMI (ang. Local Management Protocol) powstał w 1990r. z ini-
cjatywy Frame Relay Forum. Ma on duże znaczenie dla FR gdyż wnosi:
adresowanie globalne,
połaczenia
˛ grupowe,
obwód wirtualny LMI dla komunikatów.
Adresowanie globalne nadaje numerom DLCI status unikatowych adresów w urzadzeniach ˛
DTE sieci FR. Wówczas cała sieć FR przeobraża si˛e w typowa˛ sieć LAN aż do ruterów, FRAD-
ów z jej obrzeża. Indywidualne interfejsy i komunikujace˛ si˛e z nimi w˛ezły moga˛ by ć rozpozna-
wane przez typowe w sieciach LAN mechanizmy, np. protokoły odwzorowujace ˛ adresy mi˛edzy-
sieciowe na adresy fizyczne.
Połaczenia
˛ grupowe1 wpływaja˛ na szerokość pasma. Dzi˛eki nim nie jest obciażana
˛ cała sieć.
Modyfikacje tras rutingu zostaja˛ zaw˛eżone do grupy ruterów lub FRAD-ów. Każdy z użytkowni-
ków w grupie otrzymuje również kopie komunikatów z raportami o stanie grupy i modyfikacjach.
Połaczenia
˛ grupowe sa˛ zazwyczaj ustawiane na dłuższy okres. Do adresowania multicast zostały
zastrzeżone numery DLCI 1019-1022.
Obwód wirtualny LMI został przeznaczony do sygnalizacji dostarczajacej ˛ informacji o sta-
tusie i konfiguracji łacz.
˛ Usługi protokołu LMI sa˛ dost˛epne na poziomie interfejsu abonenta.
Mi˛edzy przełacznikiem
˛ a urzadzeniem
˛ dost˛epowym tworzony jest specjalny kanał wirtualny.
Przesyłane sa˛ nim cyklicznie listy ważnych DLCI, komunikaty określajace ˛ stan każdego obwo-
du, stan sieci. Zapewnia też synchronizacj˛e mi˛edzy DTE a DCE.
3.4. Podsumowanie
Sieci i urzadzenia
˛ FR umożliwiaja˛ ich wykorzystanie w różnego rodzaju zastosowaniach. Moż-
liwość szybkiego przenoszenia przez FR ramek protokołów warstw wyższych, np. IP, na dużych
odległościach czyni z tej technologii rozwiazanie
˛ np. tzw. problemu ostatniej mili szybkiego lo-
kalnego dost˛epu do sieci. Dodatkowo, użytkownicy dbajacy ˛ o bezpiecze ństwo swoich danych
otrzymuja˛ niemalże gotowe rozwiazanie
˛ stosujac
˛ kanały PVC lub SVC. Nie wyklucza ono sto-
sowania szyfrowanych kanałów VPN (ang. Virtual Private Network). FR może stanowi ć również
dobra˛ baz˛e dla aplikacji przesyłajacych
˛ dane typu audio lub video.
1W połaczeniach
˛ tego typu dane sa˛ transmitowane do wybranej grupy urzadze
˛ ń w sieci. I tylko tej grupy w prze-
ciwieństwie do broadcastu gdzie komunikaty odbiera każdy komputer w danej podsieci.
Bibliografia
[1] Uyless Black. Frame Relay Networks: Specifications and Implementations. McGraw–Hill,
NewYork, 2nd edition, 1995.
[2] Darren L. Spohn. Data Network Design. McGraw–Hill, NewYork, 2nd edition, 1997.

44
R OZDZIAŁ 4
Sieci ATM
Przez wiele lat istniał podział na sieci przeznaczone do transmisji danych oraz głosu. Sieci te
istniały równolegle do siebie oraz budowano dedykowane infrastruktury dla ich potrzeb. Podno-
siło to koszty budowania sieci oraz ich utrzymania. Ze wzgl˛edu na swoja˛ charakterystyk˛e, sieci
te trudno było z integrować. Wynika to z charakterystyki działania tych sieci. Sieci transmisji
danych sa˛ sieciami typu PTM (ang. Packet Transfer Mode) a sieci transmisji głosu sieciami STM
(ang. Synchronous Transfer Mode). W klasyczych sieciach PTM podstawowa˛ jednostka˛ "nośna" ˛
jest pakiet. Pakiet może mieć różna˛ długość, a co za tym idzie czas transferu pakietu nie jest stały.
Pakiety pochodzace ˛ z różnych źródeł i majace ˛ różne miejsce przeznaczenia moga˛ by ć transmito-
wane w różnej kolejności bez szczególnych zależności czasowych. W przypadku sieci STM, dla
celu transmisji, przyznawana jest szczelina czasowa. Dzi˛eki temu pomi˛edzy dwoma komuniku-
jacymi
˛ si˛e punktami zapewniona jest stała przepływność i opóźnienie. Pozwala to na realizacj˛e
usług zwiazanych
˛ z transmisja˛ głosu i obrazu w czasie rzeczywistym. Efektem ubocznym jest
niewykorzystane pasmo w przypadku, gdy nie odbywa si˛e żadna transmisja. ATM (ang. Asyn-
chronous Transfer Mode) powstał jako próba połaczenia ˛ tych dwóch nieco niekontatybilnych
technologii. Choć standard ATM ma obecnie charakter przejściowy (patrz wnioski końcowe), to
jednak jest dość powszechnie stosowany.
4.1. Standard ATM

Standard ATM został opracowany jako element specyfikacji B-ISDN (ang. Broadband Integra-
ted Services Digital Network) przez CCITT (ang. Consultative Committee for International Te-
legraph and Telephone) w 1988 roku. W zamierzeniu standard miał pozwolić na zintegrowanie
technologii sieci LAN (ang. Local Area Network), WAN (ang. Wide Area Network) i PSTN (Pu-
blic Switched Telephone Network) w jedna.˛ Za pomoca˛ technologii ATM miało być możliwe
świadczenie usług w:
sieciach LAN – poprzez interfejsy ATM w urzadzeniach
˛ typu komputery, przełaczniki
˛ itp.,
emulacje sieci LAN w tradycyjnych technologiach LAN takich jak Ethernet i Token Ring
oraz poprzez emulacje ATM w sieciach LAN;
sieciach WAN – poprzez interfejsy ATM oraz poprzez przenoszenie innych technologii
WAN poprzez sieć ATM (np. Frame Relay over ATM);
sieciach PTSN – poprzez interfejsy ATM w centralach telefonicznych oraz emulowanie
łaczny
˛ np. łaczy
˛ E1.
W przypadku gdyby ATM udało si˛e wdrożyć na szeroka˛ skal˛e, powstałaby jednolita sieć
świadczaca
˛ usługi transmisji danych oraz usługi zwiazane
˛ z telefonia.˛ Nie stało si˛e tak, gdyż po-
45
46 4.2. ATM Forum
wstały spore opóźnienia podczas definiowania kolejnych standardów. W sieciach LAN pojawił
si˛e Fast Ethernet, a nast˛epnie Gigabit Ethernet. Technologie te oferowały znaczny przyrost pr˛ed-
kości pracy sieci bez konieczności zapoznawania si˛e z nowa˛ technologia.˛ Koszty przełaczników
˛
oraz kart sieciowych ethernet zacz˛eły spadać, podczas gdy koszty przełaczników
˛ ATM oraz kart
już nie. Koszty wdrożenia ATM w LAN-ie stały si˛e na tyle duże, że obecnie nie buduje si˛e sieci
LAN w oparciu o ATM. Taniej jest budować sieci LAN z wykorzystaniem technologii ethernet.
4.2. ATM Forum

Problemy ze standaryzacja˛ różnorodnych usług w ATM-ie miało rozwiazać ˛ powstałe we wrze-
śniu 1999 roku ATM Forum. Organizacja ta powstała z inicjatywy dużych firm produkujacych
˛
sprz˛et sieciowy oraz operatorów telekomunikacyjnych i skupia obecnie około 600 członków. Pu-
blikuje ona standardy zwiazane
˛ z technologia˛ ATM. Informacje o prowadzonych pracach oraz
standardy dost˛epne sa˛ na stronie internetowej organizacji pod adresem www.atmforum.org.
4.3. Urzadzenia
˛ ATM
W sieciach ATM mamy do czynienia z połaczonymi
˛ przełacznikami
˛ realizujacymi
˛ operacje prze-
łaczania
˛ komórek ATM oraz urzadzaniami
˛ końcowymi, które sa˛ przyłaczone
˛ do przełaczników
˛ i
przesyłaja˛ poprzez sieć ATM dane. Urzadzeniem
˛ ATM może być komputer z karta˛ ATM, prze-
łacznik
˛ ethernet z karta˛ ATM lub szereg innych urzadze
˛ ń.
4.4. Adresacja w sieci ATM

Sieć ATM jak każda sieć posiada system adresowania urzadze˛ ń w sieci. Urzadzenia
˛ w sieci ATM
sa˛ identyfikowane poprzez dwudziestobajtowe pole adresowe. Adresy moga˛ należe ć do jednej
z trzech konwencji:
DDC (ang. Designated Country Code) – jest formatem wykorzystujacym ˛ specyfikacje ISO
3166, dzi˛eki czemu można określić kraj, w którym adres jest zarejestrowany;
ICD (ang. International Code Desigantor – podobnie jak DDC pozwala określić kraj,
z tym że wykorzystywana jest norma British Standards Institute;
E.164 – jest formatem adresu zdefiniowanym zgodnie z numeracja˛ przyj˛eta˛ w sieci ISDN.
Budow˛e adresu przedstawia rysunek 4.1. Znaczenie poszczególnych pól adresowych jest na-
st˛epujace:
˛
AFI (ang. Authority and Format Identifier) – określa stosowana˛ konwencj˛e adresowania.
Przyjmuje nast˛epujace˛ wartości:
39 – jeśli adres jest w formacie DDC;
46 – jeśli adres jest w formacie ICD;
45 – jeśli adres jest w formacie E.164.
DCC, ICD lub E.164 – prefiksy określajace ˛ sieć, do której klient jest dołaczony,
˛ zawieraja-
˛
ce dane o kodzie kraju wedle jednej z przyj˛etych konwencji. Pole to ma długość 2 bajtów
dla DCC i ICD oraz 8 dla E.164;
Sieci ATM 47
0 3 9 13 19
AFI DCC HO-DSP ESI SEL
Adres ATM w formacie DCC

AFI ICD HO-DSP ESI SEL
Adres ATM w formacie ICD

AFI E.164 HO-DSP ESI SEL
Adres ATM w formacie E.164
Rysunek 4.1: Budowa adresu ATM.
HO-DSP (ang. High Order Domain Specific Part) – pole określajace ˛ adres organizacji
zarzadzaj
˛ acej
˛ siecia.˛ Pole ma długość 10 bajtów dla formatów DCC i ICD oraz 4 dla
E.164;
ESI (ang. End System Identifier) – idendyfikator stacji wewnatrz ˛ sieci prywatnej. Roz-
miar jego wynosi 6 bajtów dla wszystkich konwencji adresowych. ESI powinien by ć nie-
powtarzalny i najcz˛eściej jest adresem nadanym przez producenta urzadzenia ˛ (np. MAC
Address);
SEL (ang selector) – jednobajtowe pole, które nie jest używane do identyfikacji urzadze ˛ ń
i najcz˛eściej jego wartość wynosi zero. Gdy urzadzenie
˛ spełnia jakaś
˛ dodatkowa˛ funkcje
w sieci to identyfikator ma inna˛ wartość.
Adresy ATM, choć identyfikuja˛ urzadzenia
˛ w sieci, nie identyfikuja˛ przesyłanych komórek.
Wynika to z faktu braku w komórce ATM pól adresowych nadawcy i odbiorcy. Adresy ATM sa˛
wykorzystywane wyłacznie˛ do zestawiania połacze
˛ ń pomi˛edzy poszczególnymi urzadzeniami.
˛
4.5. Rodzaje połacze

˛ ń
W sieci ATM dwa komunikujace ˛ si˛e urzadzenia
˛ dla celów transmisji musza˛ zestawić lub mieć
zestawione połaczenie.
˛ Standard ATM definiuje dwa typy połacze ˛ ń:
stały obwód wirtualny PVC (ang. Permanent Virtual Circuit) – tego typu obwód jest ze-
stawiany przez administratora. Administrator w zależności od sprz˛etu konfiguruje porty
urzadzeń,
˛ tras˛e poprzez przełaczniki,
˛ adresy oraz, jeśli trzeba, parametry określajace˛ ja-
kość transmisji;
przełaczany
˛ obwód wirtualny SVC (ang. Switched Virtual Circuit) – tego typu obwód jest
zestawiany na żadanie
˛ za pomoca˛ protokołów sygnalizacyjnych. Protokoły zapewniaja˛ ze-
stawienie połaczenia
˛ poprzez przełaczniki
˛ z żadan
˛ a˛ jakościa˛ transmisji. Podczas zestawia-
nia trasy, każdy przełacznik
˛ ATM sprawdza możliwość spełnienia wymaganych warunków
transmisji. W wypadku posiadania odpowiednich zasobów przełacznik ˛ przesyła żadanie
˛ do
nast˛epnego przełacznika.
˛ Po zestawieniu połaczenia
˛ nadawany jest 24-bitowy identyfika-
tor określajacy
˛ wirtualny kanał i ścieżk˛e.
48 4.6. Wirtualne ścieżki i kanały
4.6. Wirtualne ścieżki i kanały

W koncepcji ATM, w ramach pojedynczego łacza ˛ fizycznego, sa˛ transmitowane komórki należa- ˛
ce do różnych połaczeń.
˛ Nie sa˛ one identyfikowane adresami nadawcy i odbiorcy, jak np. w sieci
IP, ale sa˛ rozróżniane na podstawie zawartości pół VPI (ang. Virtual Path Identifier) oraz VCI
(ang. Virtual Channel Identifier). Komórki majace ˛ te same identyfikatory VPI i VCI tworza˛ wir-
tualny kanał, który realizuje jednokierunkowy transport komórek. W celu realizacji połaczenia ˛
dwukierunkowego należy zestawić par˛e połaczeń.
˛
W sieci ATM realizuje si˛e połaczenia
˛ typu VCC (ang. Virtual Channel Connection), które jest
połaczeniem
˛ pomi˛edzy dwoma punktami dost˛epu do sieci ATM. Połaczenie ˛ składa si˛e z wielu lo-
gicznych łaczy
˛ VCL (ang. Virtual Channel Link). Łacza ˛ VCL maja˛ znaczenie lokalne i sa˛ identy-
fikowane poprzez zawartość pola VCI w nagłówku komórki należacej ˛ do połaczenia.
˛ Zawartość
VCI może si˛e zmieniać po przejściu przez kolejne w˛ezły sieci powodujac ˛ zmiany VCL. Poła- ˛
czenia VCC moga˛ mieć struktur˛e wielopunktowa, ˛ która może być wykorzystana w przypadku
transmisji rozgłoszeniowych. Wirtulany kanał składajacy ˛ si˛e z wyznaczonej poprzez VCL trasy
gwarantuje integralność i sekwencyjność komórek ATM. Kanał może si˛e cechować określonym
pasmem przenoszenia. Parametry kanału sa˛ negocjowane w trakcie nawiazywania ˛ połaczenia.
˛
Grupa kanałów tworzy wirtualna˛ ścieżk˛e VP (ang. Virtual Path), która również może mieć przy-
pisane pasmo. Sieć ATM może realizować połaczenia
˛ typu VPC (ang. Virtual Path Connection),
które może być zainicjowane w punkcie dost˛epu do sieci lub w w˛ezłach o odpowiednich upraw-
nieniach. Połaczenia
˛ VPC, podobnie jak VCC, składaja˛ si˛e z wirtualnych łaczy ˛ VPL (ang. Virtu-
al Path Link), które sa˛ identyfikowane poprzez pole VPI. Pole to może ulegać zmianie podczas
transmisji, podobnie jak pole VCI. Połaczenie
˛ typu VPC jest połaczeniem
˛ jednokierunkowym
i dla transmisji dwukierunkowej należy zestawić dwa połaczenia.˛ Połaczenia
˛ VPC pozwalaja˛
operatorom na zestawienie połaczenia
˛ dla klienta, który potrzebuje posiadać wiele wirtualnych
kanałów. Wzajemne relacje pomi˛edzy kanałami i ścieżkami ilustruje rysunek 4.2.
wirtualny
kana³ (VC) VP
VC
VC
wirtualna VP
MEDIUM TRANSMISYJNE
œcie¿ka (VP)
Rysunek 4.2: Relacje pomi˛edzy kanałami a ścieżkami w sieci ATM.
4.7. Budowa komórki ATM

W technologii ATM dane przenoszone sa˛ za pomoca˛ komórek. Komórki charakteryzuja˛ si˛e sta-
łym rozmiarem 53 bajtów z czego 5 jest przeznaczonych na nagłówek a 48 na transmisje danych.
Sieci ATM 49
Struktura nagłówka różni si˛e w zależności od typu końcówki sieci. Zakończenie może być typu
NNI (ang. Network to Network Interface lub Node to Node Interface) lub UNI (ang. User to
Network Interface). Format komórki przedstawiony jest na rysunku 4.3.
bajty
0 5 53
NAG£ÓWEK DANE
UNI
CLP
GFC VPI VCI PT HEC
NNI
CLP
VPI VCI PT HEC
0 4 12 28 31 32 40
bity
Rysunek 4.3: Budowa komórki ATM.
Znaczenie poszczególnych pól jest nast˛epujace:

˛
GFC (ang. Generic Flow Control) – czerobitowe pole w nagłówku UNI. Jego wartość jest
ustawiana przez przełacznik
˛ ATM. Użytkownik może wykorzystać to pole do wydzielenia
wielu klas usług, w ramach jego sieci, które b˛eda˛ świadczone z różna˛ jakościa;
˛
VPI (ang. Virtual Path Identifier) – jest polem o rozmiarze 8 bitów na styku UNI lub 12
bitów na styku NNI, które określa przynależność komórki do wirtualnej ścieżki. Ścieżek
może być 256 na styku UNI lub 4096 na styku NNI;
VCI (ang. Virtual Channel Identifier) – jest polem o rozmiarze 16 bitów określajacym ˛
przynależność komórki do wirtualnego kanału.
PT (ang. Payload Type) – jest trzybitowym polem, określajacym
˛ czy komórka jest komórka˛
sygnalizacyjna˛ czy użytkownika;
CLP (ang. Cell Loss Priority) – jest jednobitowym polem określajacym ˛ priorytet komór-
ki. Wartość CLP=1 oznacza, że komórka może być utracona w sytuacji natłoku. Wartość
CLP=0 oznacza, że komórka nie powinna być utracona, ale nie oznacza to 100% gwarancji
na dostarczenie komórki;
HEC – jest ośmiobitowym polem sumy kontrolnej. Suma ta jest wyznaczana wyłacznie ˛
z nagłówka komórki. Mechanizm sumy pozwala na korekcj˛e pojedy ńczych bł˛edów i wy-
krycie wi˛ekszej ich liczby.
4.7.1. Typy komórek

Identyfikatory wirtualnych ścieżek, kanałów i pozostałe cz˛eści nagłówka moga˛ być kodowa-
ne w różnych formatach, w celu identyfikacji komórek nie b˛edacych
˛ komórkami użytkownika.
Przykładem moga˛ być komórki metasygnalizacji używane do zestawienia połacze˛ ń lub komór-
ki puste (ang. idle cells) służace
˛ jako wypełniacz przy wyrównywaniu pr˛edkości. Generalnie
w ATM-ie rozróżnia si˛e nast˛epujace
˛ typy komórek:
50 4.8. Model sieci
Idle – nie przenoszace

˛ żadnej informacji, generowane sa˛ w celu dostosowania szybkości
przepływu;
Valid – przesłane prawidłowo bez bł˛edów w nagłówku lub takie, w których bład
˛ ten udało
si˛e skorygować za pomoca˛ sumy kontrolnej;
Invalid – przesłane z bł˛edami, których nie udało si˛e skorygować;
Assigned – w warstwie ATM dostarczajace ˛ usługi aplikacjom;
Unassigned – wszystkie komórki, które nie sa˛ przydzielone.
4.8. Model sieci

W modelu sieci ATM można wyróżnić trzy warstwy: fizyczna,˛ ATM i warstw˛e adaptacyjna.˛
Każda z warstw realizuje określone funkcje.
4.8.1. Warstwa fizyczna

Warstwa fizyczna realizuje funkcje zwiazane ˛ z dost˛epem do medium transmisyjnego. W war-
stwie tej można wyróżnić dwie podwarstwy:
PM (ang. Physical Media Dependent Sublayer – realizujac ˛ a˛ funkcje zwiazane
˛ z dost˛epem
do medium transmisyjnego. W ramach tych funkcji określone sa˛ parametry nadajnika,
odbiornika, kodowania bitów, generowania i odtwarzania informacji synchronizujacych. ˛
TC (ang. Transmission Convergence Sublayer) – realizujac ˛ a˛ funkcje adaptacji strumienia
komórek ATM do przepływu przez fizyczny nośnik. Warstwa ta generuje oraz sprawdza
sum˛e kontrolna˛ w polu HEC nagłówka komórki. Podwarstwa TC generuje także puste
komórki, gdy sa˛ one potrzebne do dostosowania strumienia ATM do strumienia medium
transmisyjnego.
Warstwa fizyczna może wykorzystywać różne nośniki (media transmisyjne), choć dla potrzeb
ATM zaleca si˛e stosowanie łaczy˛ światłowodowych. Najcz˛eściej w ATM wykorzystuje si˛e in-
terfejsy takie jak SONET (ang. Synchronous Optical NETwork), SDH (ang. Synchronous Digital
Hierarchy), PDH (ang. Plesiochronous Digital Hierarchy). Oferuja˛ one różne pr˛edkości transmi-
sji. Tabela 4.1 pokazuje zestawienie pr˛edkości transmisji dla interfejsów SONET kontatybilnych
z SDH.
Najcz˛eściej spotykanymi interfejsami sa˛ interfejsy STM-1 (ang. Synchronous Transfer Mode
i STM-4. W przypadku ich użytkowania efektywna pr˛edkość dla użytkownika wynosi odpowied-
nio 146,76 Mb/s dla STM-1 i 599,04 Mb/s dla STM-4. Wynika to z faktu, iż co 27 komórka jest
przeznaczona dla transmisji sterujacych
˛ warstwa˛ fizyczna.˛ Oprócz interfejsów na stykach STM
sa˛ również zdefiniowane interfejsy ATM-TAXI o przepływności 100 Mb/s oraz ATM 25 Mb/s.
Ponadto sa˛ implementowane wolniejsze rozwiazania ˛ przeznaczone np. do obsługi modemów
xDSL (ang. Digital Subscriber Line).
4.8.2. Warstwa ATM

Warstwa ta odpowiada za ustanowienie połaczenia,
˛ ustalenie parametrów przepływu oraz za kon-
trol˛e. Warstwa ta realizuje swoje funkcje niezależnie od typu użytego nośnika. Użytkownik za
pomoca˛ tej warstwy otrzymuje szereg funkcji, które pozwalaja˛ mu na przeźroczysta˛ realizacje
Sieci ATM 51
SONET SDH Mb/s

STS-1/OC-1 - 51,84
STS-3/0C-3 STM-1 155,52
STS-9/OC-9 STM-3 466,5
STS-12/OC-12 STM-4 622,08
STS-18/OC-18 STM-6 933,12
STS-24/OC-24 STM-8 1244,16
STS-36/OC-36 STM-12 1866,24
STS-48/OC-48 STM-16 2488,32
STS-96/OC-96 STM-32 4976,64
STS-192/OC-192 STM-64 9953,28
Tabela 4.1: Zestawienie pr˛edkości transmisji interfejsów SONET.
transferu swoich danych poprzez sieć. W przypadku urzadzeń

˛ końcowych do tej warstwy z war-
stwy adaptacyjnej przesyłane sa˛ 48-bajtowe pola danych. Warstwa ATM opatruje je 5-bajtowym
nagłówkiem, który w połaczeniu
˛ z danymi stanowi komórk˛e ATM. Warstwa ta nie tworzy pola
sumy kontrolnej HEC. W przypadku odbioru danych nast˛epuje w warstwie oddzielenie nagłów-
ka od danych, które sa˛ wysyłane do warstwy adaptacyjnej. W przypadku realizacji tej warstwy
na przełacznikach,
˛ jest ona odpowiedzialna za połaczenia
˛ ATM o różnych wartościach parametru
QoS, a także za translacje identyfikatorów VCI/VPI.
4.8.3. Warstwa AAL

Warstwa adaptacyjna AAL (ang. ATM Adaptation Layer) jest warstwa˛ pośredniczac ˛ a˛ pomi˛edzy
warstwami wyższymi, w których działaja˛ aplikacje użytkowe a warstwa˛ ATM. Warstwa ta jest
implementowana wyłacznie˛ w urzadzeniach
˛ końcowych. W skład warstwy wchodza˛ dwie pod-
warstwy:
podwarstwa SAR (ang. Segmentation and Reasebly) – segmentacji i składania, która odpo-
wiada za zamian˛e jednostek PDU (ang. Protocol Data Unit) warstwy adaptacyjnej na pola
danych komórek ATM. Dla stacji odbiorczej jednostka ta odpowiada za składanie jedno-
stek PDU z poprawnie odebranych komórek. Podwarstwa ta jest usytuowana bezpośrednio
nad warstwa˛ ATM;
podwarstwa CS (ang. Convergence Sublayer) – podwarstwa zbieżności odpowiedzialna za
realizacj˛e usług ALL i współprac˛e z warstwami wyższymi.
Warstwa AAL jest przeznaczona do współpracy z różnego rodzajami aplikacji przesyłajacy- ˛
mi dane, dźwi˛ek, lub obraz w postaci cyfrowej. Różne typy danych wymagaja˛ przydziału róż-
nych zasobów sieci. Przy przydziale zasobów sieci, warstwa AAL musi uwzgl˛ednia ć nast˛epujace
˛
cechy żadań:
˛
rodzaj powiazań
˛ czasowych pomi˛edzy źródłem transmitowanej informacji a jej przezna-
czeniem;
charakter przepływności bitowej (może być stały lub zmienny);
tryb wymiany danych (połaczeniowy
˛ lub bezpołaczeniowy).
˛
52 4.9. Klasy ruchu
Warstwa AAL stanowi swego rodzaju filtr przydzielajacy ˛ zasoby sieci. Ze wzgl˛edu na róż-
norodność charakterystyk transmisji danych, w obr˛ebie warstwy AAL wydzielono kilka typów
warstw adaptacji AAL:
AAL typ 1 – jest wykorzystywany przy usługach klasy A (patrz niżej), które wymagaja˛
stałej, gwarantowanej pr˛edkości transmisji w trybie połaczeniowym.
˛ Jest przeznaczony do
realizacji transmisji głosu, dźwi˛eku, video i innych usług multimedialnych, w tak zwanym
czasie rzeczywistym.
AAL typ 2 – jest wykorzystywany przy usługach klasy B, które nie wymagaja˛ stałej,
gwarantowanej pr˛edkości transmisji ale wymagaja˛ nie przekraczania limitu maksymalne-
go opóźnienia. Przykładem tego typu transmisji jest transmisja kompresowanego obrazu
wideo, gdzie zamiast przesyłania klatki po klatce przesyłane sa˛ różnice pomi˛edzy nimi;
AAL typ 3/4 – jest wykorzystywana przy usługach klasy C/D, które nie wymagaja˛ transmi-
sji danych ze ścisłymi zależnościami czasowymi. Dane moga˛ być transmitowane w trybie
połaczeniowym
˛ jak i bezpołaczeniowym;
˛
AAL typ 5 – jest podobny do typu 3/4, lecz umożliwia transmisj˛e danych, które nie wy-
magaja˛ ścisłych zależności czasowych ale pracuja˛ w trybie połaczeniowym.
˛
Poszczególnym warstwom AAL przypisane sa˛ różne klasy ruchu.
4.9. Klasy ruchu

W standardzie ATM wyróżnia si˛e cztery klasy usług oznaczonych literami:
A – klasa usług wymagajaca ˛ synchronizacji, stałej przepływności bitowej pracujacych˛
w trybie połaczeniowym,
˛ przeznaczona do zastosowań multimedialnych w czasie rzeczy-
wistym;
B – klasa usług wymagajacych ˛ synchronizacji, pracujacych
˛ ze zmienna˛ przepływnościa˛
bitowa˛ oraz w trybie połaczeniowym;
˛
C –klasa nie wymagajaca ˛ synchronizacji, stałej przepływności bitowej, ale pracujaca˛ w try-
bie połaczeniowym;
˛
D –klasa nie wymagajaca ˛ synchronizacji, stałej przepływności bitowej, pracujaca˛ w trybie
bezpołaczeniowym.
˛
Aby oferować poszczególne klasy usług w standardzie ATM zdefiniowano nast˛epujace ˛ klasy
ruchu:
CBR (ang. Constant Bit Rate) – usługa zapewniajaca ˛ stała˛ przepływność bitowa.
˛ Komórki
należace
˛ do tej klasy maja˛ najwyższy priorytet. Klasa ta jest realizowana poprzez warstw˛e
AAL typ 1;
VBR (ang. Variable Bit Rate) – usługa oferujaca ˛ zmienna˛ przepływność bitowa˛ dla danych,
które maja˛ narzucone pewne wymagania co do jakości transmisji. VBR można podzielić
na dwie kategorie:
rt-VBR (ang. Real-Time Variable Bit Rate) – w tej klasie ważne sa˛ zależności cza-
sowe, np. maksymalne opóźnienie. Klasa ta jest realizowana poprzez warstw˛e AAL
typ 2;
nrt-VBR (ang. Non-Real-Time Variable Bit Rate) – w tej klasie zależności czasowe
nie sa˛ ważne. Klasa ta jest realizowana poprzez warstw˛e AAL 5;
Sieci ATM 53
ABR (ang. Available Bit Rate) – w tej klasie oferowany jest transfer danych z maksymal-
na˛ pr˛edkościa,˛ która jest aktualnie dost˛epna na łaczu.
˛ Pasmo, które jest dost˛epne, to całe
pasmo niezaj˛ete przez komórki transmitujace ˛ ruch w klasach CBR i VBR. Klasa ta jest
realizowana poprzez warstw˛e AAL 5;
UBR (ang. Unspecified Bit Rate) – w tej klasie oferowane jest pasmo na podobnej zasadzie
jak w klasie ABR. Klasa ta różni si˛e tylko tym, że w sytuacji natłoku jako pierwsze sa˛ usu-
wane komórki tej klasy. Klasa ta nadaje si˛e do transmisji dużych zbiorów danych, w któ-
rych kontrola przepływu jest realizowana poprzez aplikacj˛e transmitujac ˛ a˛ dane. W ABR
istnieje mechanizm kontroli przeciażeń,
˛ który zapobiega utracie danych w momencie prze-
ciażenia.
˛ Mechanizm kontroli zmusza systemy komunikujace ˛ si˛e poprzez sieć ATM do
ograniczenia lub wstrzymania transmisji. W UBR takiego mechanizmu nie ma i aplikacje
same musza˛ sobie radzić z utrata˛ danych. Klasa jest realizowana poprzez warstw˛e AAL3/4.
Zależności pomi˛edzy klasami ruchu ilustruje rysunek 4.4.
Pasmo
ABR lub UBR
VBR
CBR
Czas
Rysunek 4.4: Klasy ruchu w ATM.
Można przyjać,
˛ że w przypadku ruchu CBR nast˛epuje rezerwacja pasma. Pasmo to jest przy-
pisane dla tego ruchu niezależnie od faktu, czy w danym momencie realizowana jest transmisja
danych. W przypadku ruchu VBR zajmowane jest w danej chwili pasmo potrzebne do realizacji
danej transmisji. Jeśli transmisja zajmuje mniej pasma, to jest ono automatycznie zwalniane dla
potrzeb ABR lub UBR. Usługi ABR i UBR wykorzystuja˛ dla potrzeb transmisji danych całe
niezaj˛ete pasmo przez inne usługi.
4.10. Interfejsy ATM

W standardzie ATM zdefiniowane sa˛ dwa rodzaje styków, które ponadto istnieja˛ w dwóch od-
mianach:
styk UNI ( ang. User-to-User Interface) – ten styk określa zasady połaczenia
˛ użytkownika
z siecia˛ i ma nast˛epujace
˛ odmiany:
54 4.10. Interfejsy ATM
prywatny UNI (ang. private UNI) – przeznaczony do połacze ˛ ń pomi˛edzy przełacz-˛

nikiem ATM a urzadzeniem
˛ końcowym pracujacym ˛ w obr˛ebie tej samej prywatnej
sieci ATM;
publiczny UNI (ang. public UNI) – przeznaczony do przyłaczenia˛ urzadzenia
˛ ko ńco-
wego lub prywatnej sieci ATM do publicznej sieci ATM.
styk NNI ( ang. Network to Network Interface) – przeznaczony jest do łaczenia ˛ przełacz-
˛
ników ATM lub sieci ATM i posiada dwie podwersje:
prywatny NNI (ang. private NNI) – przeznaczony dla przełaczników ˛ pracujacych
˛
w sieciach prywatnych;
publiczny NNI (ang. public NNI) – przeznaczony dla przełaczników ˛ pracujacych
˛
w sieciach publicznych;
Z interfejsami ATM zwiazana ˛ jest sygnalizacja. Najcz˛eściej styku UNI używa si˛e jednej
z trzech wersji sygnalizacji: UNI 3.0, UNI 3.1, UNI 4.0. Wersja 4.0 jest najbardziej rozbudowa-
na, gdyż obejmuje elementy zwiazane˛ z transmisja˛ głosu. Z sygnalizacja˛ na styku UNI zwiazany
˛
jest też protokół ILMI (patrz niżej), zaś z sygnalizacja˛ na styku NNI protokół PNNI (patrz niżej).
4.10.1. Protokół ILMI

Protokół ILMI (ang. Integrated Local Managment Interface ) jest odpowiedzialny za autokonfi-
guracj˛e wielu parametrów protokołu ATM. Pozwala na wyznaczanie adresów serwerów inicjuja- ˛
cych różne usługi i protokoły sieciowe, a także na automatyczne nadanie urzadzeniu
˛ ko ńcowemu
adresu ATM.
4.10.2. Protokół PNNI

Protokół PNNI (ang. Private Network to Network Interface) ma realizować określanie tras czy-
li routing w sieci ATM. Niestety z różnych przyczyn powstanie protokołu zostało opóźnione.
Ustandaryzowane sa˛ dwie wersje tego protokołu PNNI-0 i PNNI-1. Protokół PNNI-0, którego
nast˛epnie przemianowano na IISP (ang. Interim Inter-switch Signaling Protocol) jest prostym
protokołem routingu dla sieci ATM. Wyznaczanie trasy dla komórki odbywa si˛e na podstawie
statycznych tras wpisanych do przełacznika.
˛ Wyznaczanie tras komórek w ramach protokolu
IISP oparty jest na statycznej tablicy tworzonej przez administratora sieci. Tablica ta składa si˛e
z elementów o nast˛epujacej˛ strukturze:
(adres ATM, długość adresu, indeks interfejsu)
Długość adresu lub prefiks oznacza ilość bitów adresu ATM używanych przy porównywaniu.
Można powiedzieć, że jest to "maska podsieci" podobna do maski podsieci w sieciach IP. Me-
chanizm ten pozwala na tworzenie wpisów określajacych ˛ tras˛e zarówno do pojedyńczych stacji
końcowych, jak i do całych grup stacji identyfikowanych prefiksem adresu. Indeks interfejsu ma
znaczenie lokalne i określa fizyczny port, lub kanał PVP. Stosowanie prefiksów może doprowa-
dzić do sytuacji, w której dwie pozycje w tablicy wskazuja˛ na dwie różne drogi. W takiej sytuacji
wybierana jest ta, która ma dłuższy prefiks. Na przykład w tablicy sa˛ dwa nast˛epujace
˛ wpisy:
1. Adres ATM 4700:1234:5678:9000:0000, prefiks 48, indeks 7
2. Adres ATM 4700:1234:5678:9000:0000, prefiks 56, indeks 8
Jeśli zajdzie konieczność wysłania pakietu do stacji o adresie ATM 4700:1234:5678:9012:2345
to pakiet zostanie przesłany zgodnie z druga˛ reguła,˛ gdyż jest w niej dłuższy prefiks. ILMI ze-
Sieci ATM 55
stawia połaczenia
˛ w oparciu o kanały UBR lub ABR. Nie jest możliwe ustawianie za pomoca˛
protokołu ILMI parametrów zwiazanych
˛ z jakościa˛ transmisji.
Protokół ILMI pozwalał na budow˛e sieci ATM, ale sieć zbudowana w oparciu o ten proto-
kół nie pozwalała na pełne wykorzystanie możliwości sieci, szczególnie zwiazanych
˛ z jakościa˛
oferowanych usług. Protokół PPNI-1 realizuje dynamiczny routing w sieci ATM. Komórka po-
dróżuje zgodnie z trasami, których charakterystyki sa˛ umieszczone w przełacznikach
˛ – z tym, że
trasy te sa˛ dynamicznie umieszczane przez protokół PNNI-1. Trasa, która jest wyznaczana przez
ten protokół może posiadać parametry zwiazane
˛ z wymaganiami QoS (ang. Quality of Service).
Może wi˛ec być realizowana w zależności od potrzeb w technikach ABR, VBR czy też CBR.
Protokół PNNI-1 umożliwia tworzenie zarówno małych sieci jak i dużych sieci operatorskich.
4.11. ATM a sieci komputerowe

Technologia ATM miała pozwolić na integracj˛e sieci transmisji danych z sieciami przeznaczo-
nymi do transmisji głosu. Aby można było zastosować ATM w sieciach transmisji danych, czyli
generalnie w sieciach komputerowych, opracowano szereg standardów, które przeznaczone były
dla sieci LAN i WAN.
4.11.1. Standard LANE

Sieci LAN, w momencie tworzenia standardów ATM, były tworzone w oparciu o technologi˛e
Ethernet i Token Ring. Konieczne stało si˛e zintegrowanie tych technologii w sieciach ATM. Ze
wzgl˛edu na koszty, nie można było, dokonać wymiany już istniejacych
˛ interfejsów w urzadze-
˛
niach. Postanowiono, wi˛ec połaczyć
˛ istniejace
˛ technologi˛e. Nie jest to łatwe, gdyż pomi˛edzy
tymi technologiami sa˛ spore różnice w działaniu. Przesłanie danych w sieci ATM wymaga zesta-
wienia połaczenia,
˛ co nie jest wymagane w sieci Ethernet. W Ethernecie adresy maja˛ długość 6
bajtów a w sieciach ATM 20 i do tego adresacja ma struktur˛e hierarchiczna.˛ Informacje o adre-
sach ATM nie sa˛ przesyłane w komórkach, natomiast informacje o adresach Ethernet sa˛ zawarte
w pakietach. W komórkach ATM sa˛ wyłacznie ˛ informacje o numerach kanału i ścieżki a i te
informacje moga˛ być zmieniane poprzez poszczególne w˛ezły sieci. Aby uporać si˛e z tymi pro-
blemami opracowano standard LAN Emulation (LANE) w wersji 1. Podstawowym założeniem
LANE było umożliwienie współpracy pomi˛edzy komputerami pracujacymi ˛ w sieciach lokalnych
oraz w sieciach ATM w ramach wspólnego segmentu sieci LAN. Z punktu widzenia sieci LAN
sieć ATM wyglada ˛ i zachowuje si˛e jak segment klasycznej, bezpołaczeniowej
˛ sieci LAN działa-
jacej
˛ w technologii Ethernet lub Token Ring. LANE maskuje istnienie sieci ATM dla programów
korzystajacych
˛ z warstwy MAC (ang. Media Access Control) i warstw wyższych, dzi˛eki czemu
nie jest konieczna wymiana lub modernizacja istniejacego
˛ oprogramowania.
LANE samo w sobie określa mechanizmy współpracy pomi˛edzy obiektami logicznymi re-
alizujacymi
˛ funkcje klientów oraz serwerów. W przypadku pojedynczej, emulowanej sieci LAN
można wyróżnić nast˛epujace
˛ obiekty:
LEC (ang. LAN Emulation Client) – obiekt klienta, powinien być co najmniej jeden;
LES (ang. LAN Emulation Server) – obiekt serwera emulujacego˛ sieć LAN;
BUS (ang. Broadcast and Unknown Server) – obiekt serwera dla ruchu broadcastowego;
LECS (ang. LAN Emulation Configuration Server) – obiekt serwera konfiguracyjnego.
56 4.11. ATM a sieci komputerowe
Obiekty serwerów odpowiedzialne sa˛ za:

odwzorowanie adresów MAC na adresy ATM;
transmisje danych pomi˛edzy klientami LEC oraz dystrybucj˛e ruchu typu broadcast i mul-
ticast;
konfiguracj˛e i współprac˛e pomi˛edzy elementami sieci ELAN (ang. Emulated LAN).
Obiekty serwerów sa˛ opogramowaniem, które może być zainstalowane zarówno na urzadze- ˛
niach końcowych, jak i na przełacznikach
˛ ATM. Poszczególne serwery moga˛ być umieszczone
na różnych urzadzeniach,
˛ choć najcz˛eściej ulokowane sa˛ na jednym. Upraszcza to konfiguracj˛e
tych serwisów.
Klienci LEC umieszczani sa˛ na urzadzeniach
˛ brzegowych sieci ATM. Moga˛ być to hosty
ATM (np. komputer z karta˛ ATM) lub przełaczniki ˛ brzegowe (np przełacznik
˛ Ethernet z karta˛
ATM).
Obiekt LEC
Jednym z podstawowych elementów sieci LANE jest LEC. Do jego zada ń należy:
przesyłanie danych do innego klienta LEC lub do serwera BUS w sytuacji realizacji ruchu
multicast lub broadcast;
rejestracja swoich danych w serwerze LES;
przechowywanie adresów w sytuacji, gdy LEC pełni funkcje Proxy LEC. LEC nie reje-
struje wtedy wszystkich adresów MAC w serwerze LES. LES w poszukiwaniu powiazania ˛
adresu MAC–ATM przesyła zapytania do wszystkich klientów Proxy LEC.
pełnienie roli interfejsu dla pozostałych składników sieci ELAN (BUS, LES, LECS). Klient
LEC zestawia z serwerem LECS połaczenie ˛ w celu uzyskania danych konfiguracyjnych
takich, jak adresy serwerów LES i BUS. Nast˛epnie zestawia połaczenie
˛ z serwerem LES,
w którym dokonuje rejestracji powiazanych
˛ ze soba˛ adresów. Rejestracja w serwerze LES
oznacza przyłaczenie
˛ klienta do ELAN-u, który ten serwer obsługuje. Aby ELAN był
w pełni funkcjonalny, klient LEC zestawia jeszcze połaczenie
˛ do serwera BUS, za pomoca˛
którego b˛edzie wysyłał ruch multicastowy i broadcastowy;
enkapuslacja ramek LAN w komórki ATM i przesyłanie ich poprzez sieć ATM. LANE
w transmisji danych wykorzystuje warstw˛e AAL5.
Funkcjonalność LEC implementowana jest w kartach ATM, przełacznikach
˛ oraz routerach. Z re-
guły możliwe jest uruchomienie wi˛ecej niż jednego klienta na pojedynczym urzadzeniu.
˛ Pozwala
to tworzyć wirtualne sieci LAN na bazie ATM.
Obiekt LES – serwer LANE
Serwer LES jest centralna˛ cz˛eścia˛ usługi LANE. Zapewnia on klientom LEC niezb˛edne infor-
macje potrzebne do zestawienia połacze ˛ ń z innymi klientami LEC. Do podstawowych zadań
serwera LES należa:
˛
przyłaczenie
˛ do sieci ELAN klientów LEC. LES na podstawie danych zawartych w żada-˛
niu klienta LEC może klienta przyłaczyć
˛ do ELAN-u lub odrzucić żadanie;
˛
rejestracja adresu klienta LEC oraz stworzenie na podstawie zarejestrowanych adresów
LEC bazy odwzorowań adresów MAC na adresy ATM;
Sieci ATM 57
W sieci ATM może być uruchomionych wiele serwerów LES ale, zgodnie ze specyfikacja˛
LANE 1.0, jeden serwer LES obsługuje jedna˛ sieć ELAN. Ten fakt ograniczył wdrożenia tech-
nologii LANE w sieciach LAN. Mało kto chciał uzależniać działanie sieci od jednego elementu.
Powstały firmowe implementacje, które pozwalały na tworzenie serwerów zapasowych. Nie by-
ły to rozwiazania
˛ kompatybilne ze soba,˛ co zmuszało użytkowników do zakupu urzadze ˛ ń od
jednego producenta.
Obiekt BUS – serwer rozgłoszeniowy
Serwer BUS jest usługa,˛ która˛ zazwyczaj uruchamia si˛e na tym samym urzadzeniu,
˛ na którym
działa serwer LES. Serwer realizuje funkcje rozsyłania pakietów typu broadcast i multicast do
klientów zlokalizowanych w obr˛ebie pojedynczej emulowanej sieci LAN. Serwer BUS jest iden-
tyfikowany poprzez specjalny adres ATM skojarzony z adresem broadcastowym MAC. Do ser-
wera BUS przyłaczeni
˛ sa˛ klienci LEC.
Obiekt LECS – serwer konfiguracyjny
Serwer LECS jest baza˛ danych zawierajac ˛ a˛ informacje konfiguracyjne na temat poszczegól-
nych podsieci ELAN. Działa on najcz˛eściej na adresie ATM 47007900000000000000000000–
00A03E000001-00 oraz używa stałych kanałów VPI=0 i VCI=17. Użycie domyślnych adresów
pozwala klientom LEC na szybkie odszukanie serwera LECS. W bazie danych serwera LECS
znajduja˛ si˛e adresy ATM serwerów LES i BUS. Poszczególne serwery sa˛ przypisane do ELAN-
ów a ELAN-y sa˛ identyfikowane poprzez nazwy. Z każdy ELAN-em zwiazane ˛ sa˛ także infor-
macje określajace
˛ typ emulowanej sieci (Ethernet lub Token Ring) oraz rozmiary ramek w danej
sieci. Klient LEC chcac˛ dołaczyć
˛ si˛e do ELAN-u w swoim zgłoszeniu podaje nazw˛e sieci ELAN,
do której chce uzyskać połaczenie,
˛ a w odpowiedzi otrzymuje adresy serwerów LES i BUS dla tej
sieci. Konfiguracja serwera LECS sprowadza si˛e do podania adresów ATM serwerów LES/BUS,
określenia typu sieci oraz nadania jej nazwy. W dużej cz˛eści urzadzeń
˛ konfiguracja jest jesz-
cze bardziej uproszczona i sprowadza si˛e do podania nazwy ELAN-u i typu sieci zaś serwisy
LES/BUS sa˛ automatycznie tworzone, a ich adresy umieszczane w bazie danych LECS.
Połaczenia
˛ ATM w LANE 1.0
W standardzie LANE 1.0 istnieja˛ dwa typy połacze

˛ ń: połaczenia
˛ sterujace
˛ oraz połaczenia
˛ do
transportu danych. Każdy z klientów LEC zestawia połaczenia
˛ VCC dla potrzeb sterowania
transmisja˛ danych z serwerami LES, LECS, BUS. Dodatkowe połaczenia˛ sterujace
˛ ustanawia
także serwer LES. W sumie w standardzie LANE 1.0 istnieja˛ nast˛epujace
˛ połaczenia
˛ kontrolne:
Configuration Direct VCC – dwukierunkowy kanał typu punkt-punkt zestawiany przez
serwer LES do serwera LECS;
Control Direct VCC – dwukierunkowy kanał typu punkt-punkt zestawiany przez klienta
LEC do serwera LES;
Control Distribute VCC – jednokierunkowe połaczenie
˛ typu punkt-wielopunkt zestawiane
przez serwer LES do wszystkich klientów LEC.
Wykaz połaczeń
˛ sterujacych
˛ pokazuje rysunek 4.5
Serwer sieci emulowanej LES
Control Control
Direct Direct
VCC VCC
Control
Distribute
VCC
Klient sieci emulowanej LEC Klient sieci emulowanej LEC
Configuration Configuration
Direct Direct
VCC VCC
Serwer konfiguracyjny LECS
Rysunek 4.5: Kanały sterujace

˛ w LANE 1.0.
W przypadku połaczeń
˛ zwiazanych
˛ z transportem danych mamy do czynienia z połaczenia-
˛
mi:
Data Direct VCC – dwukierunkowy kanał pomi˛edzy dwoma klientami LEC;
Multicast Send VCC – dwukierunkowy kanał zestawiany przez klienta LEC do serwera
BUS;
Mutlicast Forward VCC – jednokierunkowe połaczenie
˛ typu punkt – wiele punktów, które
zestawia serwer BUD do klientów LEC.
Połaczenia
˛ te znajduja˛ si˛e na rysunku 4.6.
Serwer ruchu broadcast BUS
Multicast Multicast
Send Send
VCC VCC
Multicast
Forward
VCC
Klient sieci emulowanej LEC Klient sieci emulowanej LEC
Data Direct VCC
Rysunek 4.6: Kanały transmisji danych w LANE 1.0.
Serwer BUS może przesyłać dane do klientów LEC przez dwa typy łaczy
˛ Multicat Send VCC
jak i Multicast Forward VCC. Niezależnie do rodzaju wybranego łacza
˛ dane, które ma otrzyma ć
klient LEC, musza˛ być nadesłane w odpowiedniej kolejności i nie moga˛ si˛e duplikować.
Sieci ATM 59
LANE 1.0 a model ISO/OSI

Architektur˛e sieci LANE można opisać za pomoca˛ modelu odniesienia ISO/OSI. W tym modelu
LANE 1.0 mieści si˛e w warstwie łacza
˛ danych (patrz rysunek 4.7). Z punktu widzenia ATM,
LANE jest usytuowana nad warstwa˛ AAL5. Takie usytuowanie LANE czyni ja˛ niewidoczna˛ dla
aplikacji działajacych
˛ w sieciach LAN.
Protoko³y Protoko³y
warstw warstw
wy¿szych wy¿szych
IP/IPX ATM - LAN Bridge IP/IPX

LANE LANE
AAL5 AAL5 MAC MAC
ATM ATM ATM
Warstwa Warstwa Warstwa Warstwa Warstwa
fizyczna fizyczna fizyczna fizyczna fizyczna
Komputer Prze³¹cznik Urz¹dzenie brzegowe Komputer

z kart¹ ATM ATM z kart¹
Ethernet
lub Token Ring
- warstwy odpowiedzialne za realizacje funkcji klienta LEC
Rysunek 4.7: LANE 1.0 a ISO/OSI.
Usytuowanie LANE nad warstwa˛ AAL5 oznacza, że nie można w tej technologii wykorzy-
stać możliwości ATM-u w zakresie wymagań QoS. Dane w LANE transmitowane sa˛ za pomoca˛
kanałów UBR.
Funkcjonowanie LANE
Aby uruchomić LANE 1.0, w pierwszej kolejności należy uruchomić serwery LES, LECS, BUS.
Konfiguracja polega na nadaniu nazwy ELAN-owi oraz na uruchomieniu serwerów LES i BUS,
które ten ELAN b˛eda˛ obsługiwać. Nast˛epnie należy skonfigurować serwer LECS. Do jego bazy
należy wprowadzić adresy serwerów LES i BUS oraz nazw˛e skojarzonego z nimi ELAN-u.
W kliencie LEC konfiguracja sprowadza si˛e do podania nazwy ELAN-u, w którym klient
ma pracować. Po właczeniu,
˛ klient za pomoca˛ procedur zwiazanych
˛ z ILMI pobiera prefiks sie-
ci ATM, w której b˛edzie pracował. Nast˛epnie, łacz˛ ac
˛ si˛e z serwerem LECS (który pracuje na
domyślnym adresie) za pomoca˛ kanału o identyfikatorach VPI=0 i VCI=17, pobiera adresy ser-
werów LES i BUS obsługujacych˛ ELAN, do którego LEC ma si˛e przyłaczyć.
˛ Potem klient LEC
rejestruje si˛e w serwerze LES i zestawiane sa˛ połaczenia
˛ kontrolne.
Odwzorowanie adresów
Obiekt klienta LEC jest przeznaczony do transmisji danych. W klasycznej sieci LAN urzadzenie
˛
wysyła pakiet pod adres MAC. W sieci LANE jest podobnie z tym, że przed wysłaniem transmi-
sji musi być zestawiony kanał. Aby było to możliwe, adresy MAC sa˛ odwzorowywane na adresy
ATM. Z sieci ATM klient LEC otrzymuje 13-bajtowy prefiks, który jest dopełniany 6 bajtami
adresu MAC. Pozostały 20-ty bajt ma znaczenie lokalne. W przypadku, gdy klient LEC chce
wysłać dane pod jakiś adres, MAC wysyła zapytanie do serwera LES, który (jeśli jest w stanie
udzielić odpowiedzi) wysyła ja˛ do LEC. Jeśli serwer LES nie potrafi udzielić odpowiedzi, to
wysyła zapytanie do wszystkich klientów LEC o dany adres MAC. Jeśli któryś z klientów LEC
posiada informacje o danym adresie MAC, to odsyła ja˛ do serwera LES a ten do klienta, który
pytał.
LANE a VLAN
Koncepcja sieci wirtualnej (ang. Virtual LAN) zakłada wyodr˛ebnienie logicznych podsieci w ra-
mach sieci, niezależnie od ich fizycznego połaczenia.
˛ Pozwala to wyodr˛ebnia ć użytkowników
sieci, którzy maja˛ mieć dost˛ep do określonych zasobów. Można także tworzyć wyizolowane gru-
py robocze. LANE spełnia te wymogi. Dla każdej wyodr˛ebnionej sieci należy powoła ć oddzielny
ELAN. Każda sieć ELAN jest oddzielna˛ niezależna˛ siecia˛ LAN.
Podsumowanie
Mechanizmy LANE 1.0, choć bardzo dobrze naśladowały działanie sieci LAN, nie zyskały po-
wszechnego wdrożenia. Główna˛ przyczyna˛ było powierzenie centralnej funkcji serwerom LES
i BUS, których nie można było dublować. W przypadku ich awarii przestawała działać cała sieć.
Problemy te rozwiazuje
˛ specyfikacja LANE 2.0, ale zanim ona powstała przełaczniki
˛ Ethernet
staniały do takiego stopnia, że obecnie nie opłaca si˛e wdrażać sieci ATM w sieci LAN. Obecna
funkcjonalność przełaczników
˛ LAN przewyższa możliwości sieci LANE 1.0. Możliwe jest two-
rzenie VLAN-ów oraz ustawianie priorytetów dla pakietów. Sieci LANE pozostały wyłacznie ˛
jako rozwiazanie
˛ niszowe.
4.11.2. LANE 2.0

Majac˛ na uwadze problemy zwiazane
˛ ze specyfikacja˛ LANE 1.0, ATM Forum opracowało nowa˛
specyfikacj˛e LANE o wersji 2.0. LANE 2.0 jest kompatybilna wstecz z wersja˛ 1.0, a jednocześnie
jest specyfikacja˛ rozbudowujac
˛ a˛ możliwości sieci LANE.
Architektura sieci LANE 2.0

Zadaniem specyfikacji LANE jest emulowanie połaczenia
˛ pomi˛edzy różnymi segmentami sieci
LAN poprzez sieć ATM. Sieć LAN może być zbudowana w oparciu o protokół Ethernet/802.3
lub Token-Ring/802.5. Aplikacje pracujace
˛ na komputerach wykorzystujace
˛ te protokoły nie po-
winny zauważać istnienia sieci ATM. Każdy ELAN z punktu widzenia sieci ATM jest zbiorem
LEC-ów usytuowanych najcz˛eściej na tak zwanych przełacznikach
˛ brzegowych oraz LEC-ów
zlokalizowanych bezpośrednio na komputerach. Połaczenie
˛ pomi˛edzy innymi LAN-ami moga˛
Sieci ATM 61
zapewnić wyłacznie
˛ routery. Z punktu widzenia modelu ISO/OSI LANE 2.0 jest usytuowane
poniżej warstwy 2.
Elementy składowe Specyfikacja LANE v.2.0 definiuje 5 podstawowych obiektów odpowie-

dzialnych za realizacj˛e usług w emulowanej sieci LAN. Sa˛ to:
LEC (ang. LAN Emulation Client) – obiekt reprezentujacy˛ klienta;
LES (ang. LAN Emulation Server) – obiekt odpowiedzialny za rejestracj˛e klientów LEC;
BUS (ang. Broadcast and Unknown Service) – obiekt odpowiedzialny za obsług˛e ruchu
broadcastowego;
LECS (ang. LAN Emulation configuration Server) – obiekt przeznaczony do udost˛epniania
informacji konfiguracyjnych klientom LEC w czasie inicjalizacji;
SMS (ang. Selective Multicast Server) – obiekt odpowiedzialny za obsług˛e ruchu multica-
stowego.
Protokół LANE v.2.0 definuje także dwa protokoły:
LNNI (ang. LAN Emulation Network Network Interface) – odpowiedzialny za komunikacj˛e
pomi˛edzy obiektami LES, BUS, SMS, LECS;
LUNI (ang. LAN Emulation User Network Interface) – odpowiedzialny za komunikacj˛e
pomi˛edzy LEC a pozostałymi elementami sieci LANE.
LECS#1 LECS#2
LNNI
LES#1 LES#2
BUS#1 SMS#1 SMS#2 BUS#2
LUNI
LEC#1 LEC#2 LEC#3 LEC#4
Rysunek 4.8: Model sieci LANE 2.0 protokoły LNNI i LUNI.
Podstawowe różnice w stosunku do LANE 1.0

Z punktu widzenia modelu sieci komputerowej, LANE 2.0 pozostaje w tym samym miejscu
modelu ISO/OSI co LANE 1.0. oraz jest, w zamierzeniu twórców, zgodne wstecz z LANE 1.0.
Ma to pomóc w migracji już istniejacych
˛ instalacji z LANE 1.0 do LANE 2.0. LANE 2.0 nie
miałoby jednak racji bytu, jeśli nie wprowadzonoby w nim zmian w stosunku do wersji 1.0.
Zmiany te miały usunać ˛ braki wyst˛epujace

˛ w wersji 1.0. Zasadnicze różnice pomi˛edzy LANE
2.0 i LANE 1.0 to istnienie w LANE 2.0:
wielu obiektów typu LES, BUS, LECS - mogacych ˛ obsługiwać te same ELAN-y;
nowego obiektu SMS, który pozwala na rozdzielenie drzew broadcastowych i multicasto-
wych;
wsparcia dla różnych klas ruchu, w tym ABR;
ośmiu klas jakości ruchu.
Cechy te pozwalaja˛ na budow˛e sieci o wyższej niezawodności i jakości, niż w przypadku sieci
zbudowanych w oparciu o specyfikacj˛e LANE 1.0. Pozwola˛ także na zastapienie ˛ rozwiaza
˛ ń fir-
mowych, w których firmy oferowały własne rozwiazania ˛ podnoszace˛ niezawodność sieci. Stanie
si˛e wi˛ec możliwe budowanie sieci w oparciu o urzadzenia
˛ pochodzace ˛ od różnych producentów.
Zadania elementów składowych LANE 2.0
Serwer LECS - LAN Emulation Configuration Server. Podstawowym zadaniem LECS jest
uproszczenie zarzadzania.
˛ Pełni on role centralnego repozytorium danych konfiguracyjnych.
Udost˛epnia on informacje innym komponentom sieci LANE. Każdy z komponentów sieci LAN
ustanawia, dla celów komunikacji z LECS-em, połaczenie
˛ kanałem VCC zwane Configuration
Direct VCC. Ponieważ w sieci LANE 2.0 może być wiele LECS-ów, LES-ów, BUS-ów oraz
SMS-ów, to dopuszczalna jest sytuacja, w której np. dwa LES-y moga˛ być podłaczone
˛ do róż-
nych LECS-ów. LECS oferuje pozostałym komponentom sieci LANE specyficzne informacje,
potrzebne im do konfiguracji. LEC w czasie uruchamiania otrzymuje od LECS-a adres LES-a,
który obsługuje dany ELAN. Nieco inna˛ informacj˛e otrzymuja˛ od LECS-a komponenty LES
i SMS. LECS podaje im adresy sasiednich
˛ serwerów LES i SMS obsługujacych
˛ ten sam ELAN.
Jedynym elementem sieci LANE 2.0, który nie otrzymuje informacji konfiguracyjnych od ser-
wera LECS, jest BUS. Wynika to z faktu, że każdy BUS jest ściśle powiazany
˛ z serwerem LES
i może bezpośrednio od niego otrzymywać dane konfiguracyjne. Konfiguracja sieci może ulegać
zmianom w czasie pracy. Aby zachować w miar˛e możliwości spójna˛ konfiguracj˛e sieci, możliwe
jest by LECS dynamiczne odświeżał konfiguracje pozostałym komponentom sieci. Najprostsza˛
metoda˛ jest ponowne odpytanie LECS-a o konfiguracj˛e przez inny komponent sieci. Ponieważ
w sieci LANE może być wi˛ecej niż jeden LECS, konieczny jest mechanizm synchronizacji baz
danych zawartych w każdym LECS-ie. Synchronizacja ta jest dokonywana za pomoca˛ kanałów
synchronizacyjnych VCC. Niestety sam mechanizm synchronizacji danych, zawartych w LECS-
ach, nie jest do końca zdefiniowany w specyfikacji LANE.
Serwer LES - LAN Emulation Server. LES jest głównym komponentem odpowiedzialnym za
prace emulowanej sieci LAN. Najcz˛eściej realizowany jest w postaci oprogramowania na prze-
łaczniku
˛ ATM. Istnieja˛ implementacje pracujace˛ na brzegowych urzadzeniach
˛ sieci ATM np. na
routerach CISCO czy stacjach roboczych SUN. Każdy LES tworzy i utrzymuje baz˛e powiaza ˛ ń
adresów ATM i MAC wszystkich stacji pracujacych ˛ w danym LAN-ie. Adresy ATM najcz˛e-
ściej sa˛ tworzone w oparciu o prefiks sieci ATM i adres MAC stacji. Zadaniem serwera LES
jest przyłaczenie
˛ do sieci ELAN klienta LEC. Klient LEC może zostać przyłaczony ˛ wyłacznie
˛
wtedy do ELAN-u, gdy jego żadanie˛ przyłaczenia
˛ b˛edzie skierowane do LES-a, który ten ELAN
obsługuje. Wyjatkiem
˛ sa˛ rozwiazania
˛ firm, które w konfiguracji zawieraja˛ tzw. ELAN domyślny.
Sieci ATM 63
LES, który taki ELAN obsługuje, przyłacza ˛ do sieci każdego klienta LES zgłaszajacego
˛ żada-
˛
nie przyłaczenia
˛ do sieci. Ułatwia to tworzenie prostej, emulowanej sieci, bo wystarczy właczy ˛ ć
urzadzenia
˛ i sieć już działa. Niestety, istnienie takiego LES-a i ELAN-u prowadzi do wielu pro-
blemów. Wystarczy bowiem by LES obsługujacy ˛ dana˛ sieć ELAN w czasie startu urzadzeń,
˛
wystartował nieco później niż LES obsługujacy ˛ ELAN domyślny. Jest wtedy szansa, że żada- ˛
nia wysłane przez prawidłowo skonfigurowane LEC-e zostana˛ przechwycone przez domyślny
LES. Sieć ELAN nie funkcjonuje wtedy prawidłowo. Ponieważ w sieci ELAN w specyfikacji
LANE 2.0 dopuszczalne jest istnienie wielu serwerów LES, musza˛ one synchronizowa ć swo-
je bazy danych. Czynia˛ to ustanawiać pomi˛edzy soba˛ połaczenia ˛ VCC zwane Control Cache
VCC. Synchronizacja baz odbywa si˛e za pomoca˛ protokołu Server Cache Synchronization Pro-
tokol (SCSP). Aby sieć ELAN prawidłowo pracowała, wszystkie serwery LES, obsługujace ˛ dany
ELAN, musza˛ mieć pomi˛edzy soba˛ połaczenia,˛ gdyż jedynie wtedy możliwa jest synchroniza-
cja wszystkich serwerów LES. Konieczność ta wynika z modelu pracy sieci. Kiedy LEC zostaje
właczony
˛ do sieci, jest on podłaczany
˛ do najbliższego serwera LES wskazanego przez LECS-a.
Kiedy LEC musi przesłać dane pod adres, którego nie zna, wysyła zapytanie o adres ATM do
swojego serwera LES. Serwer LES może odpowiedzieć na zapytanie o adres ATM podajac ˛ adres
ATM klienta LEC lub przesłać zapytanie do innego serwera LES, który na te pytanie odpowie.
Serwer BUS. Serwer BUS jest komponentem odpowiedzialnym za obsług˛e pakietów broadca-
stowych (jeden do wszystkich) i pakietów, dla których nie udało si˛e znaleźć ATM-owego adresu
przeznaczenia. Serwer BUS bierze także udział w transmisji pakietów multicastowych (jeden
do wielu) jeśli klientem LEC jest klient działajacy
˛ zgodnie ze specyfikacja˛ LANE 1.0. Istnieja˛
dwa sposoby realizacji serwera BUS. Pierwsza oparta jest na technologii VCC-Mapped. W takim
wykonaniu serwer BUS przesyła pakiety broadcastowe do wszystkich klientów LEC niezależ-
nie od tego, czy dany LEC zarejestrował jakiś MAC adres czy nie. Druga technologia jest nieco
bardziej inteligentna. Pakiety broadcastowe sa˛ wysłane tylko tym klientom, którzy zarejestrowa-
li jakieś adresy MAC. Pozwala to na zaoszcz˛edzenie pasma, a także oszcz˛edza klientowi LEC
pracy zwiazanej
˛ z usuwaniem niechcianych ramek. Każdy serwer BUS jest sparowany z ser-
werem LES. W specyfikacji LANE 1.0 i 2.0 nie jest wyszczególniony protokół komunikacyjny
pomi˛edzy serwerem LES i BUS. Producenci implementuja˛ go sami. Najcz˛e ściej w czasie konfi-
gurowania urzadzenia
˛ wystarczy skonfigurować serwer LES, a serwer BUS b˛edzie uruchomiony
automatycznie z takim samym adresem ATM jak LES. W czasie inicjalizacji LEC, po wysłaniu
zapytania o adres broadcastowy, otrzymuje też za pośrednictwem serwera LES adres skojarzo-
nego serwera BUS. Klient ustanawia do serwera BUS połaczenie˛ iDefault Multicast Send VCC,
a w odpowiedzi serwer BUS ustanawia Multicast Forwarding VVC do klienta. Klient LEC po
zestawieniu takich połaczeń
˛ staje si˛e lokalnym klientem serwera BUS. Wszystkie pakiety broad-
castowe, wysłane przez klienta LEC, sa˛ rozsyłane przez serwer BUS do jego lokalnych klientów
LEC oraz do innych serwerów BUS obsługujacych ˛ ten sam ELAN. Aby było to możliwe, wszyst-
kie serwery BUS pracujace ˛ we wspólnym ELAN-ie musza˛ ustanowić pomi˛edzy soba˛ połaczenie
˛
Multicast Forward VCC. Każdy klient LEC może także wysyłać do serwera BUS pakiety z nie-
znanymi adresami docelowymi oraz pakiety multicast. Jeśli klient LEC znajdzie adres docelowy
dla danego pakietu multicastowego, to może go wysłać bezpośrednio do docelowych stacji. Jeśli
nie, to może go wysłać badź
˛ na adres serwer BUS, badź ˛ na adres serwera SMS. Specyfikacja
LANE 2.0 dopuszcza obie te możliwości. Wynika to z konieczności zachowania zgodności ze
specyfikacja˛ LANE 1.0, w której pakiety multicastowe mogły być wysyłane wyłacznie
˛ na ad-
res serwera BUS. W przypadku pakietów z nieznanymi adresami docelowymi BUS rozsyła je
do wszystkich klientów LEC. Jeśli któryś z klientów LEC zna adres, jego odpowiedź zostanie
dodana do bazy adresowej serwera LES.
Serwer SMS - Selective Multicast Servers. Serwer BUS nie dostarczał efektywnego mechani-
zmu transmisji pakietów multicastowych. W specyfikacji LANE 2.0 dodano wiec nowy obiekt,
którego zadaniem jest przej˛ecie od serwera BUS obsługi ruchu multicastowego. Serwer SMS
nie przejmuje jednak całości tego ruchu. Nie było to możliwe, ze wzgl˛edu na konieczność za-
chowania zgodności z poprzednia˛ specyfikacja˛ LANE 1.0. SMS w czasie inicjalizacji ustanawia
połaczenie
˛ z serwerem LES, którego adres otrzymał od serwera LECS. Do synchronizacji bazy
z serwerem LES, SMS używa protokołu SCSP. Klienci LEC działajacy ˛ w oparciu o specyfikacj˛e
LANE 1.0 nie zauważaja˛ istnienia serwera SMS i wysyłaja˛ wszystkie dane multicastowe do ser-
wera BUS. Klient LEC napisany w oparciu o specyfikacje LANE 2.0 może ustanowić połaczenie˛
z serwerem SMS i do niego wysyłać dane multicastowe. Klient LEC v.2.0 może stać si˛e człon-
kiem grupy multicastowej. Grup˛e multicastowa˛ tworzy lokalny serwer LES poprzez rejestracj˛e
w swojej bazie nast˛epujacych
˛ informacji: adres multicastowy, adres serwera SMS, adres klienta
LEC. Serwer LES po zarejestrowaniu grupy rozsyła t˛e informacj˛e za pomoca˛ protokołu SCSP do
pozostałych serwerów LES oraz do serwera SMS. Kiedy serwer SMS otrzyma informacj˛e o gru-
pie, tworzy drzewo Multicast Forward VCC, do którego jako liść dodaje klienta LEC. Odtad ˛ LEC
v.2.0 b˛edzie otrzymywał dane multicastowe. Należy jednak pami˛etać, że oprócz nowych klien-
tów w sieci moga˛ znajdować si˛e także klienci LEC v.1.0. Aby zapewnić poprawna˛ współprac˛e
obu typów klientów, serwer SMS pracuje przy transmisji multicastów prawie tak samo jak in-
teligentny serwer BUS. Nie może jednak przejać ˛ pełnej funkcjonalności serwera BUS, gdyż nie
ma możliwości obsługiwania zapytań o adres przy przesyłaniu strumieni danych jakie sa˛ gene-
rowanie w normalnym ruchu sieciwym (ang. unicast). Ponadto serwer BUS jest zawsze para˛ dla
konkretnego serwera LES. Natomiast serwer SMS, posiadajac ˛ pełna˛ baz˛e klientów serwera LES,
jest w swej funkcjonalności zbliżony do serwera LES, nie ma jednak możliwości bezpośredniej
rejestracji LEC w swojej bazie.
Klient LEC - LAN Emulation Client. Klient LEC pełni rol˛e interfejsu sprz˛egajacego˛ sieć
LAN z siecia˛ ATM. Jako usługa jest realizowany w dwóch zasadniczych odmianach:
w postaci oprogramowania (sterownika) do karty sieciowej w komputerze lub routerze.
W tym przypadku klient LEC rejestruje si˛e w bazie adresowej serwera LES jako normalny
klient z pełnym adresem;
jako dodatkowy moduł oprogramowania w tak zwanych przełacznikach
˛ brzegowych. W tym
przypadku klient LEC rejestruje si˛e w bazie adresowej serwera LES jako proxy LEC. Ser-
wer LES przesyła do tego typu klientów LEC wszystkie zapytania o powiazanie˛ adresów
MAC - ATM, których sam nie potrafi obsłużyć;
Niezależnie od sposobu implementacji klient LEC realizuje nast˛epujace
˛ zadania:
transmisji danych do innych klientów LEC dla normalnej transmisji danych mi˛edzy urza- ˛
dzeniami w sieci (unicast);
transmisji danych do serwera BUS dla ruchu broadcastowego;
transmisji danych do serwera SMS dla ruchu multicastowego;
Sieci ATM 65
rejestracji swoich adresów w serwerze LES;

enkapsulacji ramek danych z sieci LAN w ramki sieci ATM.
Standardowo, w czasie inicjalizacji, klient LEC odpytuje serwer LECS o adresy serwerów LES
i BUS. Nast˛epnie rejestruje swój adres ATM i adres MAC w bazie serwera LES. W niektó-
rych implementacjach klientów LEC możliwe jest r˛eczne podanie adresów LES i BUS, a także
nadanie adresu ATM klientowi LEC. Pozwala to uniknać ˛ kłopotów zwiazanych
˛ z bł˛edami w im-
plementacjach sygnalizacji UNI. Jednocześnie obniża to poziom bezpieczeństwa sieci, gdyż po-
zwala na podszycie si˛e pod istniejacego
˛ klienta LEC.
Architektura protokołów LANE 2.0

Sieć zbudowana w oparciu o specyfikacje LANE 2.0 pracuje w architekturze klient-serwer.
Klientem w tej sieci jest LEC. Za pomoca˛ interfejsu LUNI (ang. LANE User to Network Interfa-
ce) komunikuje si˛e z serwerami realizujacymi
˛ usług˛e LAN Emulation Service. Serwery LECS,
LES, BUS, SMS do komunikacji pomi˛edzy soba˛ używaja˛ zestawu interfejsów LNNI (ang. LAN
Emulation Network to Network Interface). Dla każdego typu połacze
˛ ń pomi˛edzy serwerami sieci
ATM zdefiniowano nast˛epujace˛ interfejsy LNNI:
LECS LNNI, który odpowiedzialny jest za zestawianie kanałów:
synchronizacyjnych do innych serwerów LECS (LECS synchronization VCC(s) to
other LECS);
konfiguracyjnych do serwerów LES i BUS (Configuration Direct VCC(s) from one
or more LES and BUS).
LES NNI, który odpowiedzialny jest za zestawianie kanałów VCC:
konfiguracyjnych do serwera LECS (Configuration Direct VCC to an LECS);
synchronizacyjnych do sasiednich
˛ serwerów LES lub BUS (Cache Synchronization
VCC to neighbour LES(s) or SMS(s));
kontrolnych do pozostałych serwerów LES (Controll Coordinate VCC to all other
VCC).
BUS LNNI, który odpowiedzialny jest za zestawianie multicastowych kanałów VCC do
komunikacji z innymi serwerami BUS2 (Multicast Forward VCC to all other BUS);
SMS LNNI, który odpowiedzialny jest za zestawianie kanałów:
konfiguracyjnych do serwera LECS (Configuration Direct VCC to an LECS);
synchronizacyjnych do sasiednich
˛ serwerów LES lub SMS (Cache Synchonization
VCC to neighbour LES(s) or SMS(s));
multicastowych do pozostałych serwerów SMS(s) i BUS(s) (Multicast Forward VCC
to other SMS(s) and BUS(s)).
Jak widać z powyższych specyfikacji, sieć kanałów VCC protokołu LNNI realizuje trzy podsta-
wowe zadania:
kontrolne;
synchronizacyjne;
transmisji danych.
Prawidłowa realizacja powyższych zadań pozwala różnym serwerom serwisu LANE pracować
z punktu widzenia klienta LEC tak jak jeden wspólny serwer. Aby ułatwić zarzadzanie
˛ kanała-
mi w sieci LANE przyjmuje si˛e, że podstawowa˛ jednostka˛ sieci jest zbiór sasiednich
˛ serwerów.
Tworza˛ one tzw. oko sieci (ang. mesh). Podstawowym zadaniem protokołu LNNI jest takie ze-
stawienie kombinacji połaczeń

˛ wewnatrz
˛ oka sieci, aby każdy serwer b˛edacy
˛ składnikiem takiej
grupy otrzymywał komunikaty bez pośrednictwa innego serwera. Ponieważ możliwe sa˛ dwa ty-
py połaczeń
˛ VCC ("point to point" i "point to multipoint") oraz połaczenia
˛ moga˛ inicjować różne
serwery wchodzace ˛ w skład grupy, to możliwe jest powstawanie p˛etli połacze ˛ ń. Aby zapobiec
p˛etlom a także brakowi połaczeń,
˛ w protokole LNNI przyj˛eto szereg założeń, które musza˛ speł-
nić połaczenia,
˛ aby sieć działała prawidłowo. Dwa pierwsze założenia to:
każda wiadomość wysłana od dowolnego serwera w grupie musi trafić do wszystkich ad-
resatów, do których jest adresowana;
każda wiadomość nie może być wysłana wi˛ecej niż jeden raz do pozostałych w˛ezłów sieci.
Pozostałe założenia definiuja˛ zasady wyboru połacze
˛ ń w wypadku, gdy połaczenia
˛ si˛e dubluja.˛
Kanały, które zostały uznane za niepotrzebne nie sa˛ o razu likwidowane. Usuwane sa˛ one dopiero
po czasie przeterminowania. Przed upływem tego czasu moga˛ być w każdej chwili wykorzystane
do celów transmisji. Zasady tworzenia i likwidowania kanałów ilustruja˛ rysunki 4.9 4.10 4.11 .
W fazie 1 serwer A inicjuje połaczenia
˛ VCC (ciagła
˛ niebieska linia) zarówno point to multipoint
jak i point to point do serwerów B,C,D.
Serwer D
Serwer A Serwer B
Serwer C
Rysunek 4.9: Tworzenie kanałów VCC faza 1 i 2.
W fazie drugiej serwer B tworzy połaczenia

˛ VCC (kreskowana czerwona linia) point to point
do serwerów A,C,D. Ponieważ istnieje już połaczenie
˛ point to point do serwera A to jedno z nich
musi zostać usuni˛ete. Zostaje wybrane połaczenie,
˛ które zainicjował serwer A.
Serwer C musi mieć połaczenie
˛ zarówno z serwerami sasiednimi
˛ jak i z innymi serwerami.
Aby zoptymalizować ruch, tworzy on dwa połaczenie
˛ typu VCC (kreskowane zielone linie) point
to multipoint, jedno wyłacznie
˛ do serwerów w obr˛ebie swojej grupy, a drugie łacz ˛ ace
˛ zarówno
z serwerami w obr˛ebie grupy jak i po za nia.˛ W fazie 3 serwer D, który ma już połaczenia
˛ point to
point z serwerami A,B tworzy kanał VCC (kropkowana pomara ńczowa linia) point to multipoint
Sieci ATM 67
Serwer D
Serwer A Serwer B
Serwer C
Rysunek 4.10: Tworzenie kanałów VCC faza 3.
do serwerów A,B,C.
Aby optymalizować ruch, serwer D przy wysyłaniu nie używa kanałów VCC point to point
zestawionych do serwerów B,A. Używa do tego wyłacznie
˛ kanału point to multipoint.
Protokół SCSP - Server Cache Synchronization Protokol.
W protokole SCSP zdefiniowano procedury i narz˛edzia niezb˛edne do synchronizacji baz danych

tworzonych i posiadanych przez różne serwery serwisu LANE v 2.0. Jest to potrzebne, gdyż
w serwisie LANE 2.0 moga˛ si˛e duplikować serwery usług. Zadania realizowane przez protokół
SCSP można podzielić na dwie grupy:
zadania sygnalizacyjne,
zadania synchronizacyjne.
Do zadań sygnalizacyjnych należy informowanie poszczególnych serwerów sieci LANE o tym,
że zaszły zmiany w bazach danych. Zmiany te zachodza˛ na skutek właczania ˛ si˛e nowych ser-
werów serwisu LANE do sieci, odłaczania ˛ tychże serwerów, a także na skutek rejestracji no-
wych klientów LEC w różnych miejscach sieci ATM. Klienci LEC korzystajacy ˛ z usług sieci
ATM nie powinni zauważać, gdzie sa˛ podłaczeni
˛ oraz ile serwerów serwisu LANE świadczy im
usługi. Rozważajac ˛ sposób budowy protokołu SCSP można wyróżnić w nim dwie podwarstwy.
W pierwszej warstwie określanej jako protocol independent sublayer zestawiane sa˛ połaczenia ˛
pomi˛edzy sasiednimi
˛ serwerami serwisu LANE. Dowolny serwer, który używa zestawu procedur
składajacych
˛ si˛e na t˛e podwarstw˛e, może zsynchronizować swoja˛ baz˛e ze wszystkimi pozostały-
mi serwerami. Natomiast przy użyciu procedur składajacych ˛ si˛e na podwarstw˛e określana˛ jako
protokol dependent sublayer, dwa serwery korzystajace ˛ z procedur składajacych
˛ si˛e na t˛e pod-
Serwer D
Serwer A Serwer B
Serwer C
Rysunek 4.11: Tworzenie kanałów VCC stan końcowy.
warstw˛e moga˛ zsynchronizować tylko swoje bazy.
Protokół LUNI wersja 2

Integralna˛ cz˛eść specyfikacji LANE 2.0 stanowi specyfikacja protokołu LUNI. Definiuje ona in-
terfejs komunikacyjny pomi˛edzy siecia˛ LAN a siecia˛ ATM. Protokół ten definiuje w jaki sposób
ramki sieci lokalnej typu 802.3 oraz 802.5 sa˛ pakowane w ramki ATM. Operowanie na ram-
kach Ethernet i Token Ring powoduje, że zostaje zachowana pełna przeźroczystość dla aplikacji
sieciowych, zbudowanych w oparciu o protokoły wyższych warstw, takich jak IP czy IPX. W ra-
mach specyfikacji LUNI wprowadza si˛e poj˛ecie klienta LEC (ang. LAN Emulation Client).
Zadania protokołu LUNI. Protokół LUNI definiuje zadania, które musza˛ być realizowane
przez klienta LEC. W wi˛ekszości zostały one opisane podczas omawiania zadań klienta LEC.
W protokole LUNI zdefiniowane sa˛ także procedury tworzenia i usuwania kanałów VCC do
realizacji poszczególnych zadań. Sa˛ to kanały inicjowane zarówno przez serwery serwisu LANE
jak i klienta LEC. Kanały można podzielić na dwie zasadnicze grupy:
kanały kontrolne VCC
dwukierunkowy point to point Configuration Direct VCC pomi˛edzy klientem LEC
a serwerem LECS (inicjowany przez klienta LEC);
dwukierunkowy point to point Control Direct VCC pomi˛edzy klientem LEC a ser-
werem LES (inicjowany przez klienta LEC);
jednokierunkowy point to multipoint Control Distribute pomi˛edzy serwerem LES
a klientami LEC (inicjowany przez serwer LES).
Sieci ATM 69
kanały transmisji danych:

dwukierunkowy point to point Data Direct VCC pomi˛edzy klientami LEC (inicjowa-
ny przez klienta LEC);
dwukierunkowy point to point Multicast Send VCC pomi˛edzy klientem LEC a ser-
werem BUS (inicjowany przez klienta LEC);
jednokierunkowy point to multipoint Multicast Forward VCC pomi˛edzy serwerem
BUS a klientami LEC (inicjowany przez serwer BUS).
Rozszerzenia protokołu LUNI. Protokół LUNI v.2 jest rozszerzeniem specyfikacji LUNI v.1
i jest zgodny wstecznie z ta˛ specyfikacja.˛ Rozszerzenia LUNI 2.0 obejmuja: ˛
wsparcie dla QoS (Quality of Service);
wsparcie dla Multicastów;
multipleksacji ruchu w jednym kanale VCC.
Wsparcie dla wymagań QoS obejmuje możliwość zestawiania kanałów VCC dla transmisji da-
nych w standardzie ABRi (ang. Availble Bit Rate). W LANE 1.0 możliwe jest zestawianie wy-
łacznie
˛ kanałów w standardzie UBR (ang. Unspecified Bit Rate). Pozwala to na transmisj˛e da-
nych, które wymagaja˛ wi˛ekszej gwarancji jakości pasma. LANE v.2 pozwala definiować parame-
try QoS lokalnie dla każdego klienta LEC. Najniższe parametry jakości transmisji QoS odpowia-
daja˛ transmisji w standardzie UBR. Dane wysyłane przez klienta LEC z ustawionymi parame-
trami QoS sa˛ otrzymywane przez odbierajacego ˛ klienta LEC z zachowaniem jakości nadawania.
Wsparcie dla multicastów obejmuje możliwość tworzenia takich grup multicastowych, w których
odbierajacymi
˛ b˛eda˛ tylko członkowie danej grupy. Możliwe si˛e to stało po utworzeniu nowego
obiektu w serwisach LANE serwera SMS. Pełne wykorzystanie jego właściwości jest możliwe
dopiero wtedy, gdy klient LEC jest oparty o specyfikacj˛e LUNI 2.0. W LANE 1.0 multicasty
były rozsyłane za pomoca˛ serwera BUS, który rozsyłał je tak jak zwykłe pakiety broadcastowe.
W LANE 2.0 klient LEC śle adresy multicastowe do serwera SMS. Nast˛epnie klient LEC reje-
struje si˛e w bazie serwera SMS jako klient, który chce odbierać pakiety multicastowe adresowane
na konkretny adres multicastowy. W przypadku, gdy pakiety nie sa˛ adresowane do niego, to do
niego w ogóle nie docieraja.˛ W przypadku sieci LANE 1.0 klient LEC musi odbierać i ignorować
pakiety multicastowe, które nie sa˛ adresowane do niego. Pozwala to na oszcz˛edność pasma i na
lepsze wykorzystanie sieci. W LANE 1.0 w jednym kanale VCC przy transmisji danych nie jest
możliwa multiplekasacja ruchu do wielu różnych źródeł danych i typu danych. W takim kanale
moga˛ być transmitowane zarówno dane kontrolne jak dane zawierajace ˛ enkapsulowane pakiety
sieci LAN.
4.11.3. MPOA - Multiprotocol Over ATM

Typowa sieć LAN pracuje w oparciu o druga˛ warstw˛e modelu ISO/OSI. Aby przesłać pakiet do
innej sieci LAN, musi przejść on przez urzadzenie
˛ realizujace
˛ usługi warstwy modelu ISO/OSI
czyli przez router. Router może być aplikacja˛ pracujac
˛ a˛ na komputerze (np. oprogramowanie
KA9Q pracujace˛ na komputerach PC), cz˛eścia˛ systemu operacyjnego (np. jadro
˛ systemów ope-
racyjnych Solaris i Linux potrafi routować pakiety) lub pracować jako specjalizowane urzadze-
˛
nie (np. routery firm CISCO, Nortel Networks, Alcatel). Routery sprz˛etowe sa˛ bardzo wydaj-
nymi urzadzeniami,
˛ ale jednocześnie dość drogimi. W klasycznych sieciach LAN pojawiły si˛e
wi˛ec urzadzenia
˛ łacz
˛ ace
˛ w sobie funkcjonalność routerów i przełaczników.
˛ Nazywane sa˛ one
przełacznikami
˛ warstwy trzeciej. Przełaczniki
˛ tego typu analizuja˛ pierwszy pakiet ze strumienia
danych, który ma być przesłany pomi˛edzy sieciami LAN, a nast˛epne pakiety traktuje jako kon-
tynuacj˛e tego strumienia. Ta funkcjonalność pozwala na budowanie wysokowydajnych połacze ˛ ń
sieci LAN za stosunkowo nieduże pieniadze.˛ Podobna˛ funkcjonalność dla sieci LAN zbudowa-
nych w oparciu o specyfikacje LANE 2.0 ma zapewnić standard MPOA.
MPOA v.1.1
Standard MPOA v.1.1 ukazał si˛e w maju 1999 roku. Jest on rozszerzeniem standardu MPOA
1.0, który ukazał si˛e w lipcu 1997 roku. Standard MPOA określa sposób zastosowania protokołu
NHRP (ang. Next Hop Resolution Protokol) w sieciach zbudowanych w oparciu o specyfikacje
LANE 2.0. MPOA jest nadbudowa˛ nad siecia˛ LANE (patrz rysunek 4.12 MPOA a sieć LANE).
MPOA pozwala różnym sieciom ELAN na przesyłanie pakietów z pomini˛eciem routera. Pozwala
to sieci ATM na:
znacznie bardziej efektywna˛ komunikacje pomi˛edzy ELAN-ami;
zmniejszenie liczby urzadzeń
˛ potrzebnych do przesłania pakietów pomi˛edzy ELAN-ami;
uproszczenie budowy sieci, gdyż zmniejsza si˛e liczba urzadze
˛ ń potrzebnych do zapewnie-
nia połaczeń
˛ mi˛edzysieciowych, a co za tym idzie upraszcza si˛e konfiguracja sieci;
obniżenie kosztów, bo mniejsza liczba routerów oznacza wi˛ecej wolnych portów dla in-
nych urzadzeń.
˛
Standard MPOA może być zaimplementowanych w sieciach ATM które:
wspieraja˛ sygnalizacje UNI (ang. User Network Interface) w wersjach 3.0, 3.1, 4.0.
pracuja˛ zgodnie ze specyfikacja˛ LANE 2.0.
Aby wdrożenie MPOA było możliwe, należy najpierw zaimplementować protokół NHRP, któ-
rego definicja znajduje si˛e w dokumentach RFC 2332.
Model MPOA
Model sieci MPOA składa si˛e z dwóch komponentów:

serwera MPOA (MPS - MPOA Server),
klienta MPOA (MPC - MPOA Client).
ATM
MPOA CLIENT
NETWORK MPOA SERVER
L3 Fwd
Function NHS
ELAN#1
Routing
LEC#1 LEC#1 Function
Rysunek 4.12: MPOA a sieć LANE.

Sieci ATM 71
Serwer MPOA (MPS) jest funkcjonalnym odpowiednikiem routera. W jego skład wchodzi
NHS (ang. Next Hop Server),który jest implementacja˛ standardu NHRP z pewnymi rozszerze-
niami. MPS współpracuje z klientami MPC. MPS jest najcz˛eściej implementowany jako rozsze-
rzenie na oprogramowania na routerach sprz˛etowych. Klient MPOA (MPC) jest lokowany na
przełacznikach
˛ brzegowych (MPOA Edge Device) lub na komputerach bezpośrednio przyłaczo- ˛
nych do sieci ATM (MPOA HOST). Zadaniem klienta MPOA jest wykrywanie strumienia pa-
kietów, które musza˛ być przesłane przez router i przesłanie informacji o nich do serwera MPOA.
Gdy okaże si˛e, że transmisja danych jest skierowana do ELAN-u, który jest w tej samej sieci
ATM i ma zaimplementowanego klienta MPC, to zestawiane jest połaczenie ˛ VCC łacz
˛ ace
˛ bez-
pośrednio dwóch klientów LEC i nim sa˛ transmitowane dane. Sytuacj˛e ilustruje rysunek 4.13:
Przykładowe drogi pakietów w sieci ze standardem MPOA.
MPOA CLIENT MPOA SERVER

L3 Fwd
Function NHS
Routing
ATM
NETWORK
MPOA CLIENT MPOA SERVER
L3 Fwd
Function NHS
Routing
- standardowa droga pakietu

- skrócona droga pakietu
Rysunek 4.13: Przykładowe drogi pakietów w sieci ze standardem MPOA.
Podsumowanie
Standard LANE 2.0 oraz jego uzupełnienie, czyli standard MPOA, pozwalaja˛ na budow˛e bardzo
wydajnych sieci LAN. Zastosowanie obu standardów eliminuje wiele ogranicze ń, które spoty-
kało si˛e w sieciach zbudowanych w oparciu o specyfikacj˛e LANE 1.0. Rozbudowane zostały
zarówno serwisy (wprowadzono serwer multicastów, dzi˛eki MPOA możliwy jest routing) oraz,
co szczególnie ważne, poprawiono niezawodność sieci poprzez wprowadzenie dublujacych ˛ si˛e
serwerów usług. Praktyczne zastosowanie tych standardów stoi jednak pod znakiem zapytania.
MPOA zapewnia bardzo efektywny routing, ale jednocześnie ma bardzo słabe możliwości kon-
troli i filtracji ruchu. Wymaga także rozbudowania istniejacych
˛ urzadze
˛ ń o wi˛eksza˛ ilość pami˛eci
i silniejsze procesory. Trzeba także pami˛etać, że w dzisiejszych czasach zbudowanie sieci ściśle
wiaże
˛ si˛e z koniecznościa˛ wdrożenia różnorodnych mechanizmów bezpiecze ństwa, które w stan-
dardzie LANE i MPOA nie sa˛ przewidziane. Główna˛ jednakże przeszkoda˛ w budowie sieci ATM
LANE sa˛ i b˛eda˛ koszty. Pojedyncza karta do przełacznika˛ ATM z czterema portami ATM 155
Mb/s kosztuje tyle ile 24-portowy przełacznik˛ 10/100Mb/s dla sieci LAN. Karta ATM do kom-
putera PC kosztuje średnio pi˛eć sześć razy wi˛ecej niż dobrej klasy karta Fast Ethernet. W ofercie
firm trudno jest znaleźć karty ATM szybsze niż 622 Mb/s. Jednocześnie w sieciach LAN mamy
do czynienia z ofensywa˛ Gigabit Ethernetu. Takiej pr˛edkości transmisji nie gwarantuje żaden
przełacznik
˛ ATM przeznaczony dla sieci LAN. Prawdopodobnie jedynym miejscem, gdzie znaj-
da˛ praktyczne zastosowania standardy LANE 2.0 i MPOA b˛eda˛ sieci zbudowane na standardzie
LANE 1.0. Sa˛ to jednak tylko przypuszczenia, gdyż koszty przejścia do LANE 2.0 moga˛ być
na tyle wysokie, że b˛edzie to także nieopłacalne. Wiele sieci ATM pracuje w oparciu o firmowe
standardy, które zapewniaja˛ zarówno routing pomi˛edzy sieciami jak i zwi˛ekszona˛ niezawodność
sieci. Sprawdzaja˛ si˛e one na tyle dobrze, że podj˛ecie si˛e ich wymiany spowodowałoby wyłacznie˛
niepotrzebne koszty.
4.11.4. IP over ATM

Standard LANE służy do transmisji danych przez sieci ATM w sieciach LAN. Dla sieci typu
WAN nie za bardzo si˛e nadaje. Do tego typu rozwiaza ˛ ń przeznaczonych jest szereg innych stan-
dardów. Jednym z szerzej stosowanych jest standard IP over ATM. W standardzie określony jest
sposób odwzorowania pakietów IP na komórki ATM (RFC 1483) oraz sposób odwzorowania
adresów ATM na adresy IP (RFC 2225). Standard IP over ATM pozwala na podział fizycznej
sieci ATM na segmenty IP określane mianem LIS (ang. Logical IP Subnetwork). W ramach tej
podsieci przyłaczane
˛ do niej urzadzenia
˛ moga˛ si˛e komunikować korzystajac
˛ bezpośrednio z pro-
tokołu IP. Komputery, które znajduja˛ si˛e w różnych podsieciach LIS, do komunikacji potrzebuja˛
routera.
Odwzorowanie pakietów IP na komórki ATM

Komórki ATM maja˛ stała˛ długość zaś pakiety IP zmienna.˛ Należy wi˛ec podzielić odpowiednio
pakiety IP na mniejsze i dodać do nich informacje kontrolne. Dokument RFC 2225 zeleca by
do enkapsulacji pakietów wykorzystywać multipleksacje pakietów LLC/SNAP opisana˛ w RFC
1453. Enkapsulacja LLC/SNAP umożliwia transmisj˛e różnych protokołów warstwy sieciowej
przy pomocy pojedynczego połaczenia
˛ wirtualnego. Typ danych przenoszonych przez dany pa-
kiet jest identyfikowany na podstawie nagłówka LLC/SNAP. Nagłówek ten składa si˛e z 3 bajtów
przeznaczonych do identyfikacji typu protokołu łacza ˛ danych (cz˛e ść LLC) i 5 bajtów przezna-
czonych do jednoznacznej identyfikacji protokołu (cz˛eść SNAP). Cz˛eść SNAP składa si˛e z pola
EtherType określajacego
˛ typ protokołu w ramach danej organizacji standaryzujacej ˛ natomiast
zawartość pola OUI identyfikuje t˛e organizacj˛e.
Dla pakietów IP zalecane wartości pól sa˛ nast˛epujace:
˛
0xAAAA03 dla pola LLC, co odpowiada ramce Ethernet;
0x000000 dla pola OUI, co oznacza organizacje odpowiedzialna˛ za standaryzacje Ether-
netu;
0x0800 dla pola EtherType, co odpowiada pakietowi IP w ramce Ethernet.
Sieci ATM 73
0xAA-AA-03 LLC
3B
0x00-00-00
3B OUI
Pakiet IP over ATM
0x-08-00
Ether Type
2B
do 9 kB IP PDU
0 - 47 B PAD
1B CPCS-UU
1B CPI
Dane generowane
przez AAL5
2B Length
4B CRC
Rysunek 4.14: Struktura danych dla warstwy AAL5 zawierajacej

˛ pakiet IP over ATM.
Właściwy pakiet IP zawarty jest w polu IP PDU. Dodatkowo warstwa ALL 5 dodaje do pakietu
własne, specyficzne dla niej dane, takie jak sumy kontrolne (CRC) czy też pola wypełnienia
(PAD).
Odwzorowanie adresów
Podobnie jak w LANE, także w IP over ATM zachodzi konieczność odwzorowania adresów IP
na adresy ATM. Adresy ATM sa˛ niezb˛edne do zestawienia połaczenia ˛ pomi˛edzy komunikujacy- ˛
mi si˛e urzadzeniami.
˛ Po zestawieniu połaczenia,
˛ połaczenie
˛ jest jednoznacznie identyfikowane
poprzez identyfikator wirtualnego połaczenia,
˛ który jest złożony z pary VPI/VCI. Oznacza to,
że po procesie zestawienia połaczenia
˛ adres IP jest mapowany na identyfikator wirtualnego po-
łaczenia.
˛ Do odwzorowania adresów IP na adresy ATM służy protokół ATMARP a InATMARP
do odwzorowań odwrotnych. Protokoły te sa˛ odpowiednikami protokołów ARP i InARP z tra-
dycyjnych sieci IP. Zasadnicza różnica w działaniu polega na tym, że w klasycznych sieciach
żadanie
˛ z protokołu ARP jest wysyłane do wszystkich stacji w podsieci, natomiast w sieci ATM
jest wysyłane do serwera ATMARP. Serwer ATMARP ma t˛e wad˛e, że w przypadku jego awarii
sieć przestaje działać. Działanie tych protokołów różni si˛e nieco w zależności od użytych technik
połaczeń
˛ (PVC,SVC).
74 4.12. ATM a telefonia
Adresacja dla połacze

˛ ń PVC. W technologii ATM administrator może zestawić kanał PVC.
Kanał tego typu nie wymaga użycia technik sygnalizacji. Jeśli korzystamy z tej technologii, to na
stałe można przypisać adresy IP do identyfikatorów wirtualny połacze˛ ń. Nie jest wi˛ec koniecz-
ne zastosowanie serwera ATMARP. Taka technika ma sens, gdy sieć jest nieduża. W przypad-
ku wi˛ekszej podsieci zbudowanej w oparciu o kanały PVC można wykorzystać protokół InAT-
MARP. Pozwoli on uzyskać adres IP urzadzenia
˛ znajdujacego
˛ si˛e na drugim końcu kanału PVC.
Pozwoli to administratorowi zmniejszyć liczb˛e wpisów w tablicy ARP.
Adresacja dla połacze

˛ ń SVC. W przypadku korzystania z kanałów SVC, urzadzenia ˛ w sie-
ci ATM musza˛ zestawić połaczenie.
˛ Zestawienie połaczenia
˛ wymaga znajomości adresu ATM
urzadzenia,
˛ do którego połaczenie
˛ ma być zestawione. Adres ten może być otrzymany z pliku
konfiguracyjnego w urzadzeniu
˛ badź
˛ otrzymany od serwera ATMARP. Aby było możliwe prze-
słanie zapytania do serwera ATMARP, w pliku konfiguracyjnym urzadzenia ˛ należy poda ć adres
serwera, który b˛edzie dana˛ podsieć obsługiwał. Serwer, na podstawie żada
˛ ń od klientów, buduje
własna˛ tablice odwzorowań, której używa nast˛epnie do udzielania odpowiedzi na zapytania AR-
MARP. Dane w serwerze sa˛ trzymane przez określony czas np. 20 minut po czym usuwane. Po
otrzymaniu odpowiedzi od serwera ARP,klient zestawia kanał SVC do docelowego urzadzenia ˛
za pomoca˛ procedur ATM. Połaczenia
˛ te sa˛ likwidowane po jakimś czasie nieużywania.
4.12. ATM a telefonia

Standard ATM miał także integrować dane multimedialne. W oparciu o mechanizmy QoS opra-
cowano szereg standardów, które wspieraja˛ transmisj˛e głosu ze szczególnym naciskiem na trans-
misje telefoniczne. W ATM-ie dost˛epne sa˛ standardy pozwalajace ˛ łaczyć
˛ centrale telefoniczne
jak i realizować rozmowy telefoniczne bezpośrednio w sieci ATM.
Standard CES
Jednym z pierwszych standardów przeznaczonych dla wsparcia telefonii był standard CES (ang.
Circuit Emulation Service). Opracowany został w styczniu 1997 roku i opisany w dokumencie
at-vtoa-0078.00. Służy on do emulacji kanału cyfrowego E1, T1, E3, T3. ATM zapewnia wyłacz- ˛
nie przeźroczysty kanał VCC oparty na warstwie AAL1 zestawiony z parametrami CBR. ATM
nie interpretuje sygnalizacji w tym kanale oraz nie koduje ani nie rozkodowuje przesyłanych
w nim danych. Za zakodowanie danych, ich multipleksacje oraz sygnalizacj˛e wewnatrz ˛ kanału,
odpowiedzialne sa˛ urzadzenia
˛ brzegowe korzystajace
˛ z tego kanału. CES jest zwykle wykorzy-
stywany do łaczenia
˛ central telefonicznych poprzez siec ATM. Połaczenia
˛ moga˛ by ć realizowane
w architekturze punkt-punkt. Zaleta˛ standardu jest możliwość wdrożenia w prawie każdej sie-
ci ATM, w której można zestawiać kanały z parametrami CBR. Wada˛ jest to, że w przypadku
nieużywania pasma dla transmisji telefonicznej, wolne pasmo nie może być wykorzystane dla
potrzeb innych usług.
Sieci ATM 75
Standard DBCES
DBCES – (ang. Dynamic Bandwidth Circuit Emulation Service) jest standardem podobnym do
standardu CES z tym, że sa˛ w nim mechanizmy pozwalajace
˛ na wykrycie ciszy i zwolnienie
pasma dla innych usług.
Technologia ATM Trunking using AAL2 for Narrowband Serwices

O ile poprzednie technologie służa˛ do łaczenia
˛ central w oparciu o stałe kanały, tak ta opiera si˛e
o kanały zestawiane dynamicznie. Standard ten pozwala sieci ATM na interpretacj˛e sygnalizacji.
Połaczenie
˛ jest zestawiane w oparciu np. o numer telefonu. Dane sa˛ transmitowane w oparciu
o warstw˛e AAL 2 i standard VBR. Oznacza to, że w przypadku gdy transmisja si˛e nie odbywa,
to pasmo jest zwalniane dla innych usług. Możliwa jest także multipleksacja wielu rozmów tele-
fonicznych w jednej celce ATM. Pozwala to na zmniejszenie czasów opóźnie ń. Ponieważ kanały
sa˛ tworzone dynamicznie w zależności od potrzeb, to maleje ich globalna liczba. Łatwiejsze jest
także zarzadzanie
˛ taka˛ infrastruktura.˛
4.13. Podsumowanie
Koncepcja sieci ATM jest obecnie dojrzała˛ technologia, ˛ ale wydaje si˛e, że dojrzała zbyt późno.
Zanim opracowano technologi˛e LANE 2.0, standardowe urzadzenia ˛ sieci LAN potaniały na tyle,
że jej wdrożenia stało si˛e nieopłacalne. Dziś, gdy ATM jest technologia˛ dopracowana,˛ w sieciach
stosowany jest zwykle protokół IP. IP dociera wsz˛edzie tam gdzie dociera ATM, a ATM nie
wsz˛edzie tam gdzie protokół IP. Na bazie IP realizowane sa˛ usługi transmisji głosu i obrazu
– czyli to, co miało być domena˛ ATM. Powstaja˛ standardy, które pozwalaja˛ na bazie sieci IP
realizować usługi z wymaganiami QoS. Wydaje si˛e wi˛ec, że dni ATM sa˛ policzone. Nie nastapi ˛
to wprawdzie zbyt szybko, gdyż wielcy operatorzy ponieśli bardzo duże koszty na zbudowanie
infrastruktury sieci ATM. Koszty te musza˛ si˛e zwrócić, zaś nowe technologi˛e oparte na IP musza˛
być dopracowane.
Bibliografia

76
R OZDZIAŁ 5
Protokoły z rodziny TCP/IP
W tym rozdziale zostana˛ przedstawione protokoły sieciowe, w oparciu o które działaja˛ współ-
czesne sieci transmisji danych, zwłaszcza sieci komputerowe. Protokoły te i zwiazane˛ z nimi
technologie sa˛ wykorzystywane coraz cz˛eściej do różnego rodzaju innych zastosowań, nie mniej
jednak były one projektowane głównie dla rozwiazywania
˛ problemów zwiazanych
˛ z transmisja˛
danych komputerowych.
W pierwszej cz˛eści omówiony zostanie bardzo ważny dla prawidłowego działania sieci pro-
tokół, a w zasadzie para protokołów — ARP/RARP (ang. Address Resolution Protocol/Reverse
ARP).
Nast˛epny z protokołów, przedstawiony w kolejnej cz˛eści to protokół IP w wersji 4 (IPv4 –
ang. Internet Protocol version 4). Stanowi on podstaw˛e działania pozostałych protokołów wyż-
szych warstw modelu IOS–OSI. Jest szeroko wykorzystywany do budowy sieci komputerowych
oraz we wszelkiego rodzaju sieciach budowanych w oparciu o komutacj˛e pakietów.
W kolejnej cz˛eści, powiazanej
˛ z poprzednia,˛ zostana˛ przedstawione sposoby adresowania
urzadzeń
˛ w sieciach opartych na protokole IPv4.
Nast˛epna cz˛eść zawiera omówienie protokołu TCP (ang. Transmission Control Protocol)
oraz UDP (ang. User Datagram Protocol).
Ostatnie cz˛eści zawieraja˛ omówienie protokołów warstw wyższych. W szczególności proto-
kołów zwiazanych
˛ z działaniem sieci komputerowych: DHCP (ang. Dynamic Host Configuration
Protocol) oraz DNS (ang. Domain Name Service).
W podsumowaniu rozdziału zostały zawarte rozważania dotyczace ˛ najnowszej wersji proto-
kołu IP – IPv6. Wprawdzie nie jest on obecnie szeroko używany i popularny w Europie, a nawet
standardy definiujace˛ nowa˛ wersj˛e IP ciagle
˛ sa˛ modyfikowane. Należy pami˛etać, że np. w Ja-
ponii protokół ten już jest używany produkcyjnie w sieciach. To „szybkie” wdrożenie wynikło
z bardzo małej liczby adresów IPv4 przydzielonych krajom azjatyckim w czasach powstawania
Internetu.
5.1. Protokół ARP/RARP

Protokół ARP Jak już wspomniano w poprzednich rozdziałach, komunikacja w sieci nie może
si˛e odbywać bez udziału warstwy fizycznej. Poza problemem zwiazanym
˛ z odpowiednia˛ trans-
misja˛ sygnałów elektrycznych w tej warstwie, producenci sprz˛etu sieciowego musieli rozwiaza
˛ ć
jeszcze jedno trudne zadanie: w jaki sposób odwzorować adresy lub identyfikatory sieciowe
z warstw wyższych w warstwie fizycznej?
Jak wiadomo, każdy interfejs Ethernet posiada własny, 48 bitowy adres, nadawany przez
77
78 5.1. Protokół ARP/RARP
producenta i unikalny w skali światowej. Czasem jest on również nazywany adresem fizycznym
interfejsu – adresem MAC (ang. Media Access Control). Ponieważ adres IP interfejsu ma 32 bity,
przeto nie da si˛e dokonać prostego odwzorowania jednego adresu w drugi.
Rozwiazaniem
˛ może być centralna baza danych z informacjami o powiazaniach
˛ adresów
Ethernetowych z IP (tablica ethers w systemach unixowych). Łatwo sobie jednak wyobrazi ć, że
takie podejście przysparza mnóstwo kłopotów, np. z wprowadzaniem uaktualnie ń do bazy oraz
przetrzymywaniem dużej tablicy takich przekształceń adresów.
Dlatego też został wymyślony protokół służacy
˛ do dynamicznego odwzorowywania jednych
adresów na drugie — ARP. Protokół ARP działa w nast˛epujacy ˛ sposób. Jeśli komputer A chce
ustalić fizyczny adres komputera B na podstawie jego adresu IP, to sprawdza swoja˛ tablic˛e od-
wzorowań ARP, czy aby adres fizyczny B nie jest już znany. Jeśli nie jest to rozgłasza w podsieci,
w której si˛e znajduje, zapytanie ARP o adres ethernetowy komputera B. To zapytanie otrzyma
również komputer B, który odeśle informacj˛e o swoim adresie MAC. Posiadajac ˛ już t˛e informa-
cj˛e, komputer A może wysyłać dane do komputera B.
Wydaje si˛e oczywiste, że wysyłanie takiego zapytania każdorazowo przed transmisja˛ danych
z komputera A do B lub odwrotnie jest bardzo nieefektywne. Chociażby ze wzgl˛edu na to, że
każda maszyna w podsieci komputera A musi przetworzyć takie rozgłoszeniowe zapytanie. Dla-
tego też komputer A b˛edzie przechowywał w swojej podr˛ecznej pami˛eci adres MAC komputera
B przez określony czas. Domyślne czasy zapami˛etywania adresów MAC w pami˛eci (tablicy
ARP) sa˛ różne dla różnych systemów operacyjnych.
Również komputer B zakładajac, ˛ że wkrótce b˛edzie musiał odpowiedzieć A np. potwier-
dzeniem otrzymania danych, po otrzymaniu zapytania o jego adres MAC do swojej pami˛eci
podr˛ecznej dopisuje adres MAC komputera A. Podobnie postapi ˛ a˛ inne maszyny pracujace ˛ w tej
samej podsieci co A. W ramach udoskonaleń protokołu ARP, przy każdym wysłaniu zapytania
ARP w podsieci maszyna dołacza ˛ swój adres MAC, który jest nast˛epnie uaktualniany w pami˛e-
ciach podr˛ecznych innych komputerów. Pierwsze zapytanie ARP jest wysyłane przez komputer
przy jego starcie.
Protokół ARP jest oczywście rozwiazaniem
˛ tylko dla sieci LAN. Zapytania ARP nie sa˛ prze-
syłane przez routery do innych podsieci. Komunikacja z innym sieciami odbywa si˛e na podsta-
wie tablicy routingu, która˛ każde urzadzenia
˛ sieciowe posiada. Tablica routingu określa sposób
komunikacji komputera z własna˛ podsiecia˛ – poprzez określenie adresu podsieci i interfejsu sie-
ciowego. Z innymi sieciami poprzez wskazanie adresu bramy (ang. default gateway), nazywa-
nego również routingiem domyślnym. Zawartość tablicy routingu można obejrzeć w wi˛ekszości
systemów przez wywołanie polecenia netstat z odpowiednimi opcjami.
Protokół ARP oraz opisany poniżej RARP używaja˛ tego samego formatu ramki, przedsta-
wionego na rysunku 5.1. Niestety, ramki moga˛ być zmiennej długości w zależności od adresów
fizycznych i adresacji stosowanej w protokołach. W przypadku Ethernetu i IP w polach sa˛ usta-
wiane nast˛epujace˛ wartości:
RODZAJ SPRZETU
˛ – określa typ interfejsu sprz˛etowego, dla Ethernetu ustawiana jest
wartość 1,
PROTOKÓŁ – rodzaj adresu dla protokołu wyższego poziomu.
Protokół RARP Protokół ARP został wymyślony w celu rozwiazania ˛ problemu powiazania
˛
adresu IP z adresem MAC, przy założeniu, że urzadzenie
˛ lub komputer wie jaki adres IP samo
Protokoły z rodziny TCP/IP 79
0 8 16 31
Rodzaj adresu sprzêtowego Rodzaj adresu protoko³u
D³. adr. sprzêt. D³. adr. protoko³u Operacja
Adres sprzêtowy nadawcy (n bajtów)
Adr. sprzêt. nadawcy (n bajtów) Adres IP nadawcy (n bajtów)
Adres IP nadawcy (n bajtów) Adr. sprzêt. odbiorcy (n bajtów)
Adres sprzêtowy odbiorcy (n bajtów)
Adres IP odbiorcy (n bajtów)
Rysunek 5.1: Format ramki ARP.
posiada. Co jednak robić w przypadku komputerów nie wyposażonych np. w dyski twarde?
Wiadomo, że w takim przypadku komputer po uruchomieniu dysponuje w zasadzie tylko
i wyłacznie
˛ adresem MAC swojego interfejsu sieciowego. Zatem cała komunikacja odbywa si˛e
przy wykorzystaniu tylko warstwy fizycznej, a ten adres okazuje si˛e wystarczajacy ˛ do komuni-
kacji z innymi maszynami w obr˛ebie tej samej podsieci.
Tak samo jak w przypadku protokołu ARP, komputer chcacy ˛ ustalić swój adres IP wysyła
do podsieci zapytanie o swoja˛ konfiguracj˛e do wszystkich urzadze ˛ ń w podsieci. Jako identy-
fikator przedstawia adres MAC swojego interfejsu. Jest też możliwe użycie innych informacji
z komputera jako identyfikatora. Jednak adres MAC ma zawsze ten sam format, niezależnie od
producenta, i jest łatwo dost˛epny dla oprogramowania. Serwer lub serwery po otrzymaniu zapy-
tania przetwarzaja˛ je, uzupełniaja˛ pole adresu IP odbiorcy i odsyłaja˛ odpowiedź bezpośrednio do
maszyny pytajacej.
˛ Maszyna pytajaca ˛ może oczywiście otrzymać odpowiedzi od kilku serwerów,
choć wystarczy odpowiedź od jednego.
Protokół RARP jest bardzo stary i już praktycznie nie jest używany. Nie pozwala on na
ustawienie żadnych dodatkowych parametrów sieci. Jego rozwini˛eciem były protokoły BOOTP
a nast˛epnie DHCP (opisane w dalszych cz˛eściach).
Należy pami˛etać, że do momentu otrzymania odpowiedzi od serwera komputer nie jest w sta-
nie użyć jakichkolwiek mechanizmów wykrywajacych ˛ utrat˛e pakietu – zarówno tego z zapyta-
niem jak i odpowiedzia˛ od serwera. Również serwer nie może używać tego typu mechanizmów.
Duża liczba krótkich zapytań RARP jest w stanie przeciażyć˛ serwer RARP. Niektóre systemy
wysyłaja˛ zapytania RARP do skutku, inne po upłyni˛eciu czasu oczekiwania na odpowiedź zgła-
szaja˛ bład.
˛ Rozwiazaniem
˛ tego problemu jest uruchomienie wi˛ecej niż jednego serwera RARP
w każdej podsieci. Każdy z nich po otrzymaniu zapytania odczekuje losowo wybrany czas przed
wysłaniem odpowiedzi. Zapobiega to generowaniu nadmiernego ruchu w sieci przez jednocze-
śnie odpowiadajace˛ serwery.
80 5.2. Protokół IPv4
0 8 16 24 31
A 0 adr. sieci adr. komputera
B 10 adr. sieci adr. komputera
C 110 adr. sieci adr. komputera
D 1110 adr. grupowy
E 1111 adr. zarezerwowane
Rysunek 5.2: Klasy adresowe.
5.2. Protokół IPv4

Protokół IP został opisany w dokumencie RFC791. Jego głównym zadaniem jest transmisja poje-
dynczych pakietów danych. Dodatkowo przenoszenie ma być dokonywane w optymalny sposób,
tj. pakiety powinny docierać od nadawcy do odbiorcy najlepsza˛ droga.˛
Żeby zrozumieć, w jaki sposób dokonuje tego protokół IP, należy zrozumieć, w jaki sposób
adresowane sa˛ urzadzenia
˛ w sieciach z protokołem IP.
5.2.1. Adresacja w sieciach IPv4

Do identyfikowania maszyn protokół IP używa 32 bitowej liczby całkowitej. Jest to tzw. adres IP
urzadzenia.
˛ Problem odwzorowywania tych liczb w łatwe do zapami˛etania nazwy jest omówiony
w punkcie dotyczacym˛ systemu DNS.
Każdy 32 bitowy adres zawiera informacj˛e o tym, gdzie w sieci znajduje si˛e urzadzenie,˛
które go używa. Pierwsza cz˛eść adresu określa sieć, do której jest ono przyłaczone.
˛ Druga na-
tomiast identyfikuje je w tej podsieci. W celu ustalenia ile z 32 bitów adresuje sieć, a ile jest
adresem urzadzenia
˛ w tej podsieci, projektanci dokonali podziału adresów na klasy. Podział ten
przedstawia rysunek 5.2.
Każda˛ z tych klas identyfikuja˛ najstarsze (pierwsze z lewej) bity w adresie. W klasie A pierw-
szy bit ma wartość 0, siedem bitów adresuje sieć, w której może być 224 (16777216) kompute-

rów. Pule adresów tej klasy sa˛ wykorzystywane przez bardzo duże sieci. W adresach klasy B dwa
najstarsze bity adresu maja˛ wartość 10, 14 bitów adresuje sieć (214 16384). Pozostałe 16 bitów
jest wykorzystane do adresowania urzadze ˛ ń w tych podsieciach. W ostatniej z szeroko używa-
nych klas adresów w sieciach C najstarsze bity maja˛ wartość 110, 21 bitów jest przeznaczone
na adres podsieci i tylko 8 na adres urzadze˛ ń w tych podsieciach. Oprócz wymienionych trzech
popularnych klas adresowych zostały wyróżnione jeszcze dwie, niemniej istotne. Klasa D służy
do adresowania grupowego (ang. multicast). Wartości najstarszych bitów tej klasy sa˛ ustawione
na 1110. Pozostałe sa˛ wykorzystane do określenia adresu grupy. Ostatnia ze zdefiniowanych klas
194.81.46.167 Adres IP
11 0 0 0 0 1 0 . 0 1 0 1 0 0 0 1 . 0 0 1 0 111 0 . 1 0 1 0 0 111
255.255.255.192 Maska podsieci
11111111 . 11111111 . 11111111 . 11 0 0 0 0 0 0
194.81.46.128 Adres sieci
11 0 0 0 0 1 0.0 1 0 1 0 0 0 1.0 0 1 0 111 0 . 1 00 0 0 0 0 0
0.0.0.39 Numer komputera
00000000.00000000.00000000.00 1 0 0 111
Rysunek 5.3: Maskowanie adresu.
— E została zarezerwowana na przyszłość i jest głównie używana dla celów testowych. W klasie
tej najstarsze bity maja˛ wartości 11110.
Jak widać, tak przyj˛ety sposób adresowania daje możliwość szybkiego określania do jakiej
sieci powinien zostać przesłany pakiet z danymi. Informacja o tym jest zaszyta bezpośrednio
w adresie. Widać również, że ten podział stwarza duże niedogodności przez marnowanie, skoń-
czonej przecież, liczby adresów. Sztywny podział na klasy ogranicza liczb˛e sieci klasy A do 2 7 ,
sieci klasy B do 214 i liczb˛e sieci klasy C do 221 . Również sztywno jest określona możliwa,
maksymalna liczba komputerów do zaadresowania w tych podsieciach. Liczby te – mimo, że
duże – okazuja˛ si˛e niewystarczajace
˛ lub nadmiarowe do przydzielenia adresów wszystkim zain-
teresowanym (stad ˛ szybkie wdrożenie IPv6 w krajach azjatyckich). Sztywny podział zmusza do
przeznaczenia 255 adresów nawet dla sieci składajacej ˛ si˛e z kilkunastu komputerów. Pozosta-
łe adresy pozostaja˛ niewykorzystane i sa˛ niedost˛epne dla innych użytkowników. Niedost˛epność
wynika przede wszystkim z właściwości adresu w IPv4. Router, czyli urzadzenie
˛ pośredniczace
˛
w wymianie danych pomi˛edzy sieciami komputerowymi, wybierajacy ˛ tras˛e dla pakietu, rozpatru-
jac
˛ docelowy adres IP, jest w stanie operować tylko i wyłacznie
˛ cała˛ klasa˛ adresów; minimalnie
jest to 255 adresów w przypadku stosowania klas C. Druga przyczyna to organizacja mechanizmu
przydziału adresów instytucjom (w Europie zajmuje si˛e tym RIPE (fr. Réseaux IP Européens)).
Pula adresów przydzielona jednej organizacji nie może być jednocześnie używane przez inna.˛
Z tego powodu został wprowadzony tzw. routing bezklasowy (ang. Classless Inter–Domain
Routing, CIDR). Nie oznacza to, że podział na klasy został zlikwidowany. Nadal obowiazuje.
˛ Zo-
stała natomiast dodana tzw. maska podsieci. Maska to nic innego jak również 32 bitowa liczba
całkowita. W masce bity, od najstarszego (tak samo jak w adresie najstarszy bit jest pierwszym
z lewej), o wartości 1 maskuja˛ odpowiadajace ˛ mu bity w adresie, tym samym wyznaczaja˛ ad-
res sieci. Pozostałe z 32 o wartości 0 wyznaczaja˛ adres komputera w podsieci z maskowanego
adresu. Dokładnie przedstawia t˛e operacj˛e rysunek 5.3.
Mask˛e, według której otrzymamy identyczna˛ struktur˛e pól jak w jednej z klas, nazywamy
maska˛ naturalna. ˛
Jak widać, maska pozwala na bardziej elastyczne regulowanie liczba˛ adresów w jednej pod-
sieci. Na przykład można ustawić minimalnie 4 adresy IP dla jednej podsieci, a nie 255 jak
w przypadku stosowania sztywnego podziału klasowego. Można również rozszerzy ć pul˛e adre-
sów w stosunku do otrzymanej dzi˛eki maskom naturalnym.
Umownie przyj˛eło si˛e, że adresu 0 nigdy nie przypisuje si˛e żadnemu urzadzeniu
˛ w sieci.
Adres 0 oznacza domyślna˛ ścieżk˛e (czasami jest też ona określana jako tzw. default routing).
Upraszcza ona informacj˛e o rutowaniu, którymi posługuja˛ si˛e routery w procesie rutowania pro-
tokołu IP. Dodatkowe ograniczenia zwiazane ˛ z adresowaniem hostów zabraniaja˛ używania do ich
adresacji adresów z pierwszym bajtem wi˛ekszym niż 223. Inny duży obszar zarezerwowany dla
specjalnych potrzeb to 127.0.0.0/8 (w przedstawionej notacji maska adresu jest ośmio bitowa).
Sieć 127 cz˛esto nazywa si˛e p˛etla˛ (ang. loopback address). Adresem z tej sieci przypisywanym
wirtualnym interfejsom hostów jest najcz˛eściej 127.0.0.1. Dzi˛eki temu aplikacje, rozpoznajace˛
maszyn˛e przez numer IP a nie np. nazw˛e w systemie DNS, moga˛ adresować lokalna˛ maszyn˛e
w identyczny sposób jak zdalna.˛
Również umownie przyj˛eto zasad˛e, że zarezerwowane sa˛ numery hostów 0 i 255 we wszyst-
kich klasach adresowych. Adres IP z „wyzerowanym” numerem hosta jest pierwszym numerem,
zawsze parzystym, z danej puli adresowej, np. 172.16.0.0 i określa cała˛ sieć – 172.16. Natomiast
adres w którym wszystkie bity adresu hosta maja˛ wartość 1 nazywa si˛e adresem rozgłoszenio-
wym (ang. broadcast address). Dla podanej sieci adresem rozgłoszeniowym jest 172.16.255.255.
Jest to również ostatni adres, zawsze nieparzysty, w puli adresów dla tej podsieci. Wysłanie in-
formacji na ten adres docelowy spowoduje, że odbierze go każde urzadzenie
˛ w podsieci 172.16.
5.2.2. Działanie protokołu IPv4

Protokół IP nie daje gwarancji na dostarczenie pakietu do miejsca przeznaczenia. Dopiero TCP
daje możliwość kontroli i sprawdzania kompletności przesyłanych danych. Mimo to protokół
IP jest podstawa˛ działania współczesnych sieci komputerowych. Jest to możliwe dzi˛eki prostym
i skutecznym mechanizmom, w które został wyposażony.
Przede wszystkim został dobrze zdefiniowany format ramki pakietu IP przedstawiony na
rys 5.4. Po drugie protokoły rutingu IP maja˛ dobrze określone procedury wyboru trasy przesyła-
nia pakietu oraz zbiory reguł, które mówia˛ w jaki sposób pakiety powinny być przesyłane.
Pola nagłówka pakietu IP

WERSJA — wersja protokołu IP, informacja ta jest potrzebna do ustalenia, czy wszystkie
urzadzenia
˛ pośredniczace,
˛ nadawca i odbiorca zgadzaja˛ si˛e na format pakietu,
DŁUGOŚĆ NAGŁÓWKA — długość nagłówka pakietu w bajtach,
TYP OBSŁUGI (ang. Type of Service, TOS) — pole określa w jaki sposób pakiet powinien
zostać potraktowany przez urzadzenie:
˛
0 4 8 16 19 31
Wersja D³. nag³. Typ obs³ugi D³ugoœæ ca³kowita
Identyfikacja Znacz. Przesuniêcie fragmentu
Czas ¿ycia (TTL) Protokó³ Suma kontrolna
Adres nadawcy
Adres odbiorcy
Opcje (jeœli konieczne) Uzupe³nienie
DANE
Rysunek 5.4: Format pakietu IP.
- pierwszeństwo (priorytet) – pierwsze 3 bity, wartość 0 stopień normalny, wartość 7

sterowanie siecia,˛
- O – czwarty bit, prośba o krótkie czasy oczekiwania,
- S – piaty
˛ bit, prośba o przesyłanie szybkimi łaczami,
˛
- P – szósty bit, prośba o duża˛ pewność przesyłanych danych a tym samym mała˛ liczb˛e
retransmisji,
- bity 6,7 – nieużywane.
Wartości TOS sa˛ podpowiedziami dla algorytmów rutowania, a nie żadaniami.
˛
PROTOKÓŁ – określa, który z protokołów warstw wyższych został użyty do utworzenia
treści pola DANE,
SUMA KONTROLNA NAGŁÓWKA – odnosi si˛e tylko do nagłówka, bez pola danych,
ZNACZNIKI – pole 3 bitowe, z czego pierwszy bit ma zawsze wartość 0, drugi dopuszcza
(0) lub nie (1) fragmentacj˛e pakietu, trzeci określa, czy pakiet zawiera fragment ze środka
(0) czy końca (1) pierwotnego pakietu,
TTL (ang. Time To Live) — jest to liczba urzadzeń,˛ przez które pakiet może przejść w sie-
ci zanim stanie si˛e nieważny. routery i inne urzadzenia
˛ przetwarzajace
˛ musza˛ zmniejsza ć
wartość tego pola aby nie doszło do sytuacji, w której datagramy sa˛ przesyłane w niesko ń-
czoność,
UZUPEŁNIENIE – zależy od wybranych opcji, służy do zapewnienia, że długość nagłów-
ka jest wielokrotnościa˛ 32 bitów,
OPCJE – nie wyst˛epuje w każdym pakiecie IP; każda opcja składa si˛e z jednego bajtu
kodu opcji, po którym może si˛e pojawić jeden bajt długości. Dalej sa˛ dane wskazanej
0 1 2 3 4 5 6 7
Kopiuj Klasa opcji Numer opcji
Rysunek 5.5: Bajt kodu w polu opcje.
Klasa opcji Numer opcji Długość Opis

0 0 – Koniec listy opcji – używane, gdy opcje nie kończa˛
si˛e wraz z końcem nagłówka
0 1 – brak przypisanej funkcji, służy do wyrównywania
bajtów w liście opcji
0 2 11 Ograniczenia zwiazane
˛ z bezpieczeństwem i ob-
sługa˛
0 3 zmienna Swobodne trasowanie według nadawcy – używane
do przesyłania pakietu określona˛ ścieżka˛
0 7 zmienna Zapisuj tras˛e – do śledzenia trasy
0 8 4 Identyfikator strumienia - przestarzałe
0 9 zmienna Rygorystyczne trasowanie według nadawcy
2 4 zmienna Używana do zapisywania czasów wzdłuż trasy pa-
kietu
Tabela 5.1: Opcje pakietów IP.
opcji. Format kodu przedstawia rysunek 5.5

- KOPIUJ – wartość 1 oznacza, że opcje odnosza˛ si˛e do wszystkich fragmentów po-
dzielonego, pierwotnego pakietu IP. Wartość 0 oznacza, że opcje odnosza˛ si˛e tylko
do pierwszego fragmentu,
- KLASA – może mieć nast˛epujace
˛ wartości,
* 0 – Kontrola pakietów lub sieci,
* 1 – Zarezerwowane do przyszłego użytku,
* 2 – Poprawianie bł˛edów i pomiary,
* 3 – Zarezerwowane do przyszłego użytku,
Przedstawiona poniżej tabela 5.1 zawiera opcje, które moga˛ być umieszczane w pakietach
IP.
Każdy pakiet IP jest przesyłany niezależnie od innych. Pakiety należace
˛ do jednego strumie-
nia danych moga˛ si˛e poruszać różnymi trasami w sieci. Pozwala również na korzystanie z róż-
nego rodzaju technologii sieciowych, np. Ethernet, FDDI, ATM. Jest to możliwe dzi˛eki dwóm
mechanizmom: fragmentacji i enkapsulacji. Pierwszy z nich pozwala na podział pakietu IP na
mniejsze fragmenty jeśli wymaga tego technologia używana przez łacze, ˛ przez które ma być
przesłany pakiet. Ponieważ pakiet składa si˛e z nagłówka – zwierajacego
˛ informacje potrzebne
do dotarcia do miejsca docelowego – oraz danych, podział pakietu na fragmenty nie może po-
legać jedynie na podziale pakietu na cz˛eści dopasowane tak, aby mogły być przeniesione przez
sieć. W ten sposób fragment z danymi, a bez nagłówka, nigdy by nie dotarł do celu. Dlatego też
urzadzenie
˛ dokonujace
˛ fragmentacji do każdego z fragmentów oryginalnego pakietu dołacza ˛ na-
główek. Oczywiście pakiety poddane fragmentacji musza˛ ponownie zostać połaczone ˛ w całość.
I tak si˛e dzieje, ale jest to niewidoczne dla użytkownika i aplikacji, która dane wysłała. Proces
łaczenia
˛ odbywa si˛e już u końcowego odbiorcy. Od momentu fragmentacji pakiety podróżuja˛ sa-
modzielnie. Routery pośredniczace ˛ moga˛ również dokonywać ponownej fragmentacji pakietów.
Za kontrol˛e fragmentacji odpowiedzialne sa˛ pola IDENTYFIKACJA, ZNACZNIKI oraz PRZE-
SUNIECIE.
˛ Pole IDENTYFIKACJA służy określeniu, do jakiego oryginalnego pakietu należy
fragment w danym datagramie. Pole ZNACZNIKI zawiera informacj˛e czy fragmentacja pakietu
jest dopuszczona (jeśli nie, a router musiałby jej dokonać aby przesłać pakiet dalej, to wysyła
on do nadawcy komunikat o bł˛edzie i nie przetwarza dalej tego pakietu), czy fragment pochodzi
ze środka czy z końca pakietu (informacja potrzebna odbiorcy końcowemu do złożenia pakie-
tu). PRZESUNIECIE ˛ oraz DŁUGOŚĆ CAŁKOWITA pozwalaja˛ odbiorcy końcowemu określić,
czy zebrał już wszystkie fragmenty do złożenia pierwotnego datagramu. Pole PRZESUNIECIE ˛
ma jeszcze jedno bardzo ważne znaczenie. Ponieważ pole OPCJE może, ale nie musi, by ć użyte,
długość nagłówka pakietu IP jest zmienna, a co za tym idzie położenie poczatku
˛ danych w pakie-
cie również. Zmienna długość nagłówka jest jedna˛ z najwi˛ekszych wad IP wersji 4. Ma bardzo
duży wpływ na szybkość przetwarzania nagłówków przez urzadzenia ˛ sieciowe. Nie moga˛ one
bowiem z góry zakładać, który bajt nagłówka przechowuje potrzebne im informacje. W każdym
pakiecie musza˛ w tym celu przetworzyć cały nagłówek, co zajmuje zasoby routerów i innych
urzadzeń
˛ sieciowych.
Drugi mechanizm – enkapsulacja – pozwala na opakowanie dowolnego datagramu protokołu
IP w ramk˛e protokołów niższych warstw. Urzadzenia˛ sieciowe nie rozpoznaja˛ adresów IP ani
formatu datagramu. Każdy pakiet IP jest przesyłany jako dane w ramce protokołu warstwy łacza ˛
danych. Mechanizm ten jest wykorzystywany nie tylko przy przesyłaniu pakietów protokołu IP
różnego rodzaju technologiami sieciowymi ale również przez inne protokoły wyższych warstw,
np. TCP przy „przechodzeniu” do warstw niższych. Procesem odwrotnym do enkapsulacji jest
dekapsulacja.
Procesowi wyznaczania tras czyli rutowania w sieciach z protokołem IP poświ˛econy jest
dalszy rozdział.
5.3. Protokół UDP

Protokół UDP dostarcza użytkownikowi mechanizmy do przesyłania datagramów mi˛edzy pro-
gramami użytkowymi. Robi to, podobnie jak IP, w sposób bezpołaczeniowy.
˛ Cała kontrola po-
prawności wysyłanych i odbieranych danych jest zawarta w aplikacjach, które wykorzystuja˛
UDP.
Rysunek 5.6 przedstawia format nagłówka protokołu UDP.
Znaczenie pól jest nast˛epujace:
˛
port nadawcy – numer portu nadawcy; pole opcjonalne (wówczas ma ustawiona˛ wartość
0), jeśli używane wskazuje port do którego należy odesłać odpowiedź,
port odbiorcy – numer portu odbiorcy,
długość – liczba bajtów nagłówka i danych,
suma kontrolna – opcjonalna i nie musi być obliczona (wówczas pole ma wartość 0), prak-
tycznie nie używana w aplikacjach pracujacych
˛ w sieciach LAN.
86 5.3. Protokół UDP
0 16 31
Port UDP nadawcy Port UDP odbiorcy
D³ugoœæ komunikatu UDP Suma kontrolna UDP
DANE
Rysunek 5.6: Nagłówek UDP.
Jak widać protokół ten wyróżnia w komunikatach port nadawcy i odbiorcy. Poj˛ecie portu
można interpretować jako kolejk˛e komunikatów identyfikowana˛ na podstawie numeru. Numer
kolejki (numer portu) jest przyznawany przez system operacyjny, który również tworzy kolejk˛e.
Może mieć ona zmienna˛ długość. Każdy program, zanim b˛edzie mógł wysłać komunikat UDP,
musi uzyskać od systemu odpowiadajacy ˛ mu numer portu. Każdy komunikat wysłany przez
program b˛edzie miał ustawiony ten numer jako port nadawcy. Otrzymujac ˛ komunikat, UDP jest
w stanie sprawdzić, czy numer portu odbiorcy odpowiada którejś z aktualnie używanych kolejek.
Jeśli tak, dopisuje go na końcu kolejki, skad˛ program może go pobrać. Dzi˛eki temu UDP jest
w stanie rozróżnić, dostarczyć i odesłać komunikat od lub do właściwej aplikacji.
Problem przydziału numerów portów jest rozwiazywany
˛ na dwa sposoby:
1. przyporzadkowanie
˛ powszechne (statyczne) – każdy zgadza si˛e na przydzielenie nume-
rów portów przez stron˛e trzecia˛ (przez wszystkich uznana).˛ Strona trzecia publikuje listy
przydzielonych portów i programy używaja˛ portów umieszczonych na liście,
2. przyporzadkowanie
˛ dynamiczne – program potrzebujacy ˛ użyć portu do komunikacji otrzy-
muje jego numer od systemu operacyjnego. Aby skomunikować si˛e z odległa˛ maszyna˛
wysyła zapytanie o numer portu, którego używa dana usługa. Po otrzymaniu odpowiedzi
komunikuje si˛e ze wskazanym portem zdalnego komputera.
Najpopularniejsze aplikacje i protokoły wykorzystujace ˛ UDP to: RPC (ang. Remote Proce-
dure Call), NFS (ang. Network File System), DNS (ang. Domain Name Service), komunikatory
sieciowe, aplikacje VoIP.
Protokół UDP używa mechanizmu wyliczania sum kontrolnych tego samego co IP. Dzieli
dane na 16 bitowe fragmenty i wylicza ich uzupełnienie do 1 a nast˛epnie wylicza sum˛e tych
uzupełnień do 1. Przed wyliczeniem sumy kontrolnej UDP uzupełnia dane oktetem zer do wie-
lokrotności 16 bitów oraz wstawia pseudonagłówek na poczatku ˛ pakietu. Nagłówek ten nie jest
przesyłany wraz z pakietem. Służy on tylko i wyłacznie
˛ do wyliczenia sumy kontrolnej. To wła-
śnie dzi˛eki niej odbiorca jest pewien, że odebrał właściwy pakiet, gdyż w pseudonagłówku jest
umieszczony adres IP nadawcy i odbiorcy. Nadawca liczac ˛ sum˛e kontrolna˛ uwzgl˛ednia oba nu-
mery IP oraz sam pakiet UDP. Odbiorca uzyskuje adres IP nadawcy z nagłówka protokołu IP.
Jeśli wyliczona przez niego suma zgadza si˛e z wartościa˛ umieszczona˛ w datagramie UDP, to
dane dotarły do właściwego komputera i właściwego portu.
5.4. Protokół TCP

Protokół TCP w odróżnieniu od IP posiada mechanizmy pozwalajace ˛ na niezawodne dostarcza-
nie danych przez sieci. Rozszerza on tym samym w istotny sposób możliwości transmisji danych
w porównaniu do wcześniej przedstawionych protokołów.
Potrzeba stosowania mechanizmów gwarantujacych ˛ poprawne dostarczenie danych jest dość
oczywista. Wystarczy sobie wyobrazić konieczność podejmowania kilku prób przesyłania du-
żych zbiorów z jednego komputera do drugiego (czasami może to zajać ˛ kilkadziesiat
˛ minut)
zanim dotra˛ one do miejsca docelowego bez uszkodzenia. Trzeba pami˛etać, że protokół IP może
dokonywać fragmentacji pakietów, pakiety moga˛ być przesyłane różnymi drogami przy wyko-
rzystaniu różnego rodzaju technologii sieciowych, urzadzenia
˛ przetwarzajace
˛ pakiety moga˛ by ć
przeciażone,
˛ itd. Jest prawie niemożliwe, aby dane dotarły bez uszkodzenia za pierwszym razem
przy ich przesyłaniu.
0 4 10 16 31
Numer portu Ÿród³owego Numer portu docelowego
Numer sekwencyjny pakietu
Numer sekwencyjny potwierdzenia

D³. nag³. Flagi Rozmiar okna
Suma kontrolna Wa¿noœæ
Opcje
DANE
Rysunek 5.7: Nagłówek TCP.
Widać, że obsługa zadań postawionych przed TCP powoduje jego znacznie bardziej skom-
plikowana˛ implementacj˛e niż np. protokołu IP. Można powiedzieć, że ta skomplikowana imple-
mentacja ma na celu dostarczenie mechanizmów potwierdzania i retransmisji. Do ich budowy
potrzebny jest nagłówek pakietu protokołu TCP, przedstawiony na rys. 5.7.
Znacznie poszczególnych pól nagłówka jest nast˛epujace:
˛
numer portu źródłowego — identyfikuje program użytkowy po stronie nadawcy,
numer portu docelowego — identyfikuje program użytkowy po stronie odbiorcy,
numer sekwencyjny pakietu — wyznacza pozycj˛e fragmentu danych przenoszonych przez
pakiet w strumieniu bajtów przesyłanych mi˛edzy nadawca˛ i odbiorca,˛
numer sekwencyjny potwierdzenia — numer bajtu, który odbiorca spodziewa si˛e otrzyma ć
w nast˛epnej kolejności,
88 5.4. Protokół TCP
Po³¹czenie Po³¹czenie
zamkniête zamkniête
SYN x (nas³uchiwanie)
Wys³anie SYN
Otrzymanie SYN
Wys³anie
SYN y + ACK
potwierdzenia
(nas³uchiwanie)
Otwarcie
po³¹czenia
Wys³anie ACK
potwierdzenia
Otwarcie
po³¹czenia
Rysunek 5.8: Otwarcie sesji TCP.
długość nagłówka — długość nagłówka, musi być wielokrotnościa˛ 4 bajtów,

flagi — zmienna długość w zależności od tego jakie opcje zostały wybrane; w razie po-
trzeby stosowane jest uzupełnienie do 32 bitów, możliwe flagi to:
- URG – pole "WAŻNOŚĆ" jest istotne,
- ACK – pole potwierdzenia jest istotne,
- PSH – pakiet jest prośba˛ o przekazanie danych do warstw wyższych bez czekania na
wypełnienie bufora lub kolejne pakiety,
- RST – skasuj połaczenie,
˛
- SYN – zsynchronizowanie numerów poczatkowych,
˛
- FIN – koniec strumienia bajtów u nadawcy.
rozmiar okna — propozycja odbiorcy, ile danych może przyjać ˛ w jednym pakiecie,
suma kontrolna — liczba całkowita służaca ˛ do sprawdzania, czy dane i nagłówek TCP nie
zostały naruszone,
ważność — jeśli jest ustawiona flaga URG pole wyznacza miejsce w pakiecie, gdzie ko ń-
cza˛ si˛e pilne dane.
opcje — dodatkowe opcje, najcz˛eściej nieużywane.
Sesja TCP Mechanizm potwierdzania wymaga od odbiorcy, aby komunikował si˛e z nadawca˛
i wysyłał mu informacj˛e potwierdzajac˛ a˛ otrzymanie danych. W tym celu przed przystapieniem
˛
do transmisji danych (podzielonej na bajty o konkretnych numerach) nadawca otwiera sesj˛e z od-
biorca˛ przy pomocy wymiany trzech pakietów. Ma to na celu zsynchronizowanie numerów pa-
kietów. Mechanizm ten przedstawia rys. 5.8
Nadawca wysyła do odbiorcy pakiet z ustawiona˛ flaga˛ SYN i losowym numerem x w polu
NUMER SEKWENCYJNY PAKIETU (NSPA). Odbiorca odbiera ten pakiet. Zapisuje sobie ten
numer i wysyła pakiet z poczatkowym
˛ numerem porzadkowym
˛ y w polu NSPA, polem NUMER
SEKWENCYJNY POTWIERDZENIA (NSPO) ustawionym na wartość x 1 co oznacza, że
spodziewa si˛e bajtu danych o takim numerze w nast˛epnym pakiecie. Pole FLAGI ma ustawio-
ne wartości SYN + ACK. Odbiorca odbiera ten pakiet i potwierdza go przez wysłanie pakietu
z ustawiona˛ flaga˛ ACK. Połaczenie
˛ zostało ustanowione. W kolejnym kroku nadawca wysyła pa-

kiet z wartościa˛ y 1 w NSPA i flaga˛ ACK. Odbiorca potwierdzi to. W jego potwierdzeniu pole

NSPO b˛edzie miało wartość x 2 zgodnie z zasada˛ używania nast˛epnego numeru spodziewanego
bajtu danych. W kolejnych pakietach nadawca b˛edzie wysyłał dane zapisujac ˛ sobie informacje
o każdym wysłanym pakiecie oraz oczekujac ˛ na potwierdzenie od odbiorcy przed wysłaniem
nast˛epnego pakietu. Oczywiście nie może to trwać w nieskończoność. Nadawca w momencie
wysłania pakietu uruchamia zegar. Gdy minie odpowiedni czas a potwierdzenie nie nadejdzie,
nadawca wyśle pakiet ponownie. Ponieważ każdy pakiet ma ustawiony swój numer, nie dochodzi
do sytuacji przesyłania zduplikowanych pakietów i ich potwierdze ń.
Sliding Window Łatwo zauważyć, że ten mechanizm jest mało efektywny. Strumień danych
w zasadzie jest przesyłany tylko w jednym kierunku mimo tego, że otwarta sesja TCP umożli-
wia transmisj˛e w obu kierunkach. Ponadto, dane sa˛ przesyłane bardzo wolno — nadawca czeka
przed wysłaniem kolejnego pojedynczego pakietu na potwierdzenie otrzymania poprzedniego.
Problem ten jest rozwiazywany
˛ przy pomocy mechanizmu przesuwnych okien (ang. sliding win-
dow). Używanie tego mechanizmu pozwala nadawcy na wysłanie takiej ilości danych na raz,
jaki jest rozmiar okna (w bajtach). Nadawca dzieli dane na pakiety i wysyła je. Liczba danych
w pakietach nie może przekroczyć rozmiaru okna. W momencie, gdy nadchodzi potwierdzenie
dla pierwszego pakietu z okna, jest ono „przesuwane” o jeden pakiet. Nowy pakiet umieszczony
w oknie jest od razu transmitowany. Jeśli w mi˛edzy czasie nadejda˛ potwierdzenia otrzymania in-
nych pakietów, okno jest znowu „przesuwane” o liczb˛e potwierdze ń. Należy zauważyć, że, jeśli
jakiś pakiet nie został potwierdzony, cały czas przebywa w oknie i sa˛ stosowane dla niego me-
chanizmy retransmisji opisane powyżej. Tym samym pakiet w oknie z najmniejszym numerem
to pakiet, dla którego nie przyszło potwierdzenie. Nadawca „przesuwa” okno ponad wszystkimi
potwierdzonymi pakietami.
Ponad to, TCP umożliwia zmian˛e rozmiaru okna w czasie. Każde z odebranych potwierdze ń
może zawierać propozycj˛e zmiany rozmiaru okna. Dzi˛eki temu, jeśli odbiorca jest w stanie od-
bierać wi˛eksza˛ liczb˛e danych (a zarazem pakietów) na raz, nadawca może to wykorzysta ć i prze-
syłać dane szybciej. W przypadku, gdy nadawca odbierze pakiet z ogłoszeniem o zmniejszeniu
okna przez odbiorc˛e, wstrzymuje on wysyłanie pakietów poza wyznaczony rozmiar okna. Aby
nie stracić wysłanych już pakietów (przy wi˛ekszym rozmiarze okna), nadawca nie zmniejsza od
razu rozmiaru okna, ale robi to w miar˛e upływu czasu otrzymywania potwierdze ń.
Problem jaki niesie ze soba˛ mechanizm przesuwnego okna to retransmisje. Odbiorca za-
wsze potwierdza najdłuższy ciag ˛ kolejnych, poprawnie otrzymanych danych (numery bajtów).
W przypadku gdy nadawca wyśle np. 6 pakietów, odbiorca po otrzymaniu ich b˛edzie potwierdzał
ich przybycie i jako wartość kolejnego oczekiwanego bajtu b˛edzie podawał wartość o jeden wi˛ek-
sza˛ od numeru ostatniego bajtu w szóstym pakiecie. Tym sposobem nadawca jest informowany
o post˛epie odczytu strumienia danych wysyłanych przez odbiorc˛e. Jest to tzw. skumulowane po-
90 5.5. Protokół ICMP
twierdzenie. Co si˛e jednak stanie, gdy pierwszy pakiet zaginie? Odbiorca b˛edzie potwierdzał
odebranie pozostałych pi˛eciu pakietów jednak każde z potwierdze ń b˛edzie wskazywało na nu-
mer nast˛epnego bajtu danych po ostatnim w zaginionym pakiecie. Odbiorca nie ma możliwości
powiadomienia nadawcy, że pozostałe pakiety dotarły. Nadawca po przekroczeniu czasu ocze-
kiwania na odpowiedź musi wybrać, czy przesyłać tylko pierwszy z 6 pakietów, czy też jeszcze
raz wszystkie 6? Wysłanie jeszcze raz 6 pakietów jest nieefektywne. Po otrzymaniu pierwszego
pakietu odbiorca potwierdzi, że ma już wszystkie dane z okna i „poprosi” o nast˛epne dane, za-
czynajac ˛ od pakietu 7. Czyli 5 pakietów niepotrzebnie zajmowało zasoby sieci. Z drugiej strony,
jeśli nadawca wyśle ponownie tylko pierwszy pakiet, musi on znowu oczekiwać na potwier-
dzenia, zanim b˛edzie wiedział, czy transmitować dane 7 pakietu, czy jeszcze raz pakietów 2–6.
Cz˛eściej używanym mechanizmem jest jednak retransmisja tylko zaginionego pakietu.
Identyfikacja połaczenia
˛ Przy wielu równolegle działajacych
˛ aplikacjach, jednocześnie trans-
mitujacych
˛ dane do/z sieci musi istnieć mechanizm, który jednoznacznie określa, jakie dane na-
leża˛ do jakiej aplikacji. Protokół TCP dostarcza odpowiedniego rozwiazania.
˛ Po otwarciu sesji
TCP mamy nadawc˛e i odbiorc˛e na przeciwległych jej końcach. Każdy z nich jest identyfikowa-
ny jako para <adres IP końca, numer portu TCP>. Łacznie
˛ <IP nadawcy, port TCP nadawcy, IP
odbiorcy, port TCP odbiorcy> stanowi jednoznaczny identyfikator połaczenia.
˛ Dzi˛eki temu jeśli
istnieje sesja <172.16.7.2, 62587, 172.16.7.1, 53> to nic nie stoi na przeszkodzie, aby jednocze-
śnie działała druga identyfikowana jako <172.16.7.4, 15677, 172.16.7.1, 53>.
5.5. Protokół ICMP

W każdej mniejszej lub wi˛ekszej sieci zdarzaja˛ si˛e sytuacje awaryjne. Z przedstawionych opisów
widać, że ani protokół IP ani TCP nie dostarczaja˛ mechanizmów pozwalajacych ˛ urzadzeniom
˛ na
przesyłanie mi˛edzy soba˛ informacji o awariach, a użytkownikowi na diagnozowanie sieci w ta-
kich sytuacjach. Dlatego też do protokołów TCP/IP został wprowadzony mechanizm komuni-
katów diagnozujacych˛ stan sieci. Komunikaty te sa˛ przesyłane przy pomocy protokołu ICMP.
Protokół ten jest wymagana˛ cz˛eścia˛ implementacji stosu TCP/IP.
Jeśli aplikacja użytkownika spowodowała bł˛edy, to komunikaty o nich urzadzenia
˛ odsyłaja˛
zawsze do nadawcy. Jeżeli sa˛ to informacje przesyłane mi˛edzy urzadzeniami
˛ w sieci dla użyt-
kownika, jest to niewidoczne bez użycia odpowiednich narz˛edzi. Wynika to z faktu, że zawarte
w pakiecie informacje pozwalaja˛ tylko na takie zachowanie. Nie ma w nim informacji na te-
mat przebytej trasy i adresu poprzedniego routera, który przysłał pakiet. Zreszta,˛ nawet gdyby
taka informacja była i tak byłaby bezużyteczna. Routery z dynamicznym protokołem rutingu
cz˛esto zmieniaja˛ swoje tablice trasowań i nie ma w zwiazku˛ z tym szansy na ustalenie któr˛edy
pakiet dotarł do routera. Nadawca po otrzymaniu informacji o bł˛edzie, którego nie spowodował,
oczywiście nie jest w stanie poprawić zachowania routera. Może jednak zgłosić problem admi-
nistratorom sieci. Dlatego też odsyłanie informacji do nadawcy jest lepszym rozwiazaniem˛ niż
usuwanie bł˛ednych pakietów bez informowania kogokolwiek.
W przypadku, gdy w sieci wyst˛epuja˛ bł˛edy zwiazane˛ z obsługa˛ pakietów ICMP, to urzadze-
˛
nia nie wysyłaja˛ już do nadawcy informacji o bł˛edzie. Powodowałoby to powstawanie odpowie-
dzi o bł˛edach komunikatów o bł˛edach.
0 8 16 31
TYP KOD Suma kontrolna
Identyfikator Numer kolejny a)
DANE (opcjonalnie) b)
Rysunek 5.9: Nagłówek ICMP; a) nie używane i równe 0 przy niektórych typach komunikatów;
b) nagłówek + 64 bity pakietu w typach komunikatów, które tego wymagaja.˛
Informacje, jakie niosa˛ komunikaty ICMP, sa˛ zawarte w dwóch polach pakietu TYP i KOD
oraz polu DANE, które zawiera pierwsze 64 bity pakietu, który spowodował wygenerowanie
wiadomości ICMP. Format pakietu przedstawia rys. 5.9
Znaczenie kodów pola TYP jest nast˛epujace: ˛
0 – odpowiedź z echem,
3 – odbiorca jest nieosiagalny,
˛
4 – zmniejszenie szybkości nadawania,
5 – zmień trasowanie,
8 – prośba o echo,
11 – przekroczenie TTL,
12 – kłopot z parametrami datagramu,
13 – prośba o czas,
14 – odpowiedź z czasem,
15 – prośba o informacj˛e,
16 – odpowiedź z informacja,˛
17 – prośba o mask˛e adresu,
18 – odpowiedź z maska˛ adresu.
TYP 8 i 0 jest wykorzystywany przez popularny program ping. Komunikat z polem TYP
ustawionym na wartość 11 jest wysyłany, gdy sieć lub sieć odbiorcy jest nieosiagalna.
˛ Wów-
czas wartości pola KOD dokładniej definiuja˛ przyczyn˛e wysłania komunikatu. Moga˛ one by ć
nast˛epujace:
˛
0 – sieć nieosiagalna,
˛
1 – w˛ezeł nieosiagalny,
˛
2 – protokół nieosiagalny,
˛
3 – port nieosiagalny,
˛
4 – konieczna fragmentacja (jeśli jest ona zabroniona),
5 – bład
˛ trasy nadawcy,
6 – nieznana sieć odbiorcy,
7 – nieznany w˛ezeł odbiorcy,
92 5.6. Protokół DHCP
8 – w˛ezeł nadawcy odizolowany,

9 – komunikacja z siecia˛ odbiorcy zabroniona administracyjnie,
10 – komunikacja z w˛ezłem odbiorcy zabroniona administracyjnie,
11 – sieć niedost˛epna dla takiego rodzaju usługi,
12 – w˛ezeł niedost˛epny dla takiego rodzaju usługi.
Komunikaty z polem TYP równym 4 sa˛ przesyłane mi˛edzy dwoma bezpośrednio komuniku-
jacymi
˛ si˛e komputerami, routerem (pierwszym w ścieżce sieciowej) a nadawca.˛ Dzieje si˛e tak
w przypadku, gdy odbiorca nie nadaża ˛ z odbiorem danych. Najcz˛e ściej w takim przypadku ulega
zmniejszeniu rozmiar okna TCP.
5.6. Protokół DHCP

Jak już wiadomo w celu komunikowania si˛e w sieci komputer potrzebuje pewnego zestawu da-
nych do swojej konfiguracji. Przy pomocy protokołu RARP może si˛e „dowiedzie ć” jaki jest jego
adres IP. W sieci Ethernet jest to jednak za mało. Potrzebna jest jeszcze maska, adres IP domyśl-
nego routera (tzw. bramy) w podsieci. Poza tym RARP staje si˛e bezużyteczny w przypadku, gdy
w sieci cz˛esto pojawiaja˛ si˛e nowe komputery, np. sieć hotelu, centrum konferencyjnego. Dopi-
sywanie informacji o każdym nowym komputerze w sieci byłoby m˛eczace ˛ zarówno dla admini-
stratora jak i użytkowników. W celu rozwiazania
˛ tych problemów został opracowany protokół
BOOTP (ang. BOOTstrap Protocol) a nast˛epnie jego nast˛epca — protokół DHCP (ang. Dynamic
Host Configuration Protocol).
DHCP stanowi jedynie pewne rozszerzenie protokołu BOOTP.
BOOTP używa protokołu UDP do przesyłania informacji o parametrach konfiguracyjnych
komputerów. Jeśli maszyna X chce poznać swoja˛ konfiguracj˛e wysyła w swojej podsieci prośb˛e
w komunikacie BOOTP na adres rozgłoszeniowy (255.255.255.255). Serwer, który odbierze ten
komunikat, odpowiada stosujac ˛ również adres rozgłoszeniowy. Gdyby chciał uży ć bezpośred-
niego adresu maszyny X musiałby założyć, że maszyna ta zna już swój adres IP i jest w stanie
odpowiedzieć na zapytanie ARP. Ponieważ go nie zna, serwer również stosuje rozgłaszanie. Nie-
które serwery po otrzymaniu prośby BOOTP dopisuja˛ do swojej tablicy ARP adres sprz˛etowy
nadawcy i przy wysyłaniu odpowiedzi stosuja˛ bezpośrednie adresowanie. Jednak wi˛ekszość uży-
wa adresów rozgłoszeniowych. Po otrzymaniu odpowiedzi X zna wszystkie parametry swojej
konfiguracji sieciowej. Informacje zawarte w odpowiedzi sa˛ przedstawione na rys. 5.10.
Pole NAZWA PLIKU STARTOWEGO nie zwiera obrazu jadra ˛ potrzebnego do startu kom-
putera. Jest to tylko informacja (w postaci nazwy) potrzebna do jego uzyskania przy pomocy
protokołu TFTP (ang. Trivial FTP). Daje to możliwość przygotowania tego samego obrazu dla
wielu maszyn oraz oddzielnie serwera BOOTP od serwera z obrazami. Z punktu widzenia admi-
nistrowania lokalna˛ siecia˛ i jej ustawieniami najważniejszym polem jest DANE SPECYFICZNE
DLA SIECI. W polu tym przesyłana jest maska podsieci, adresy serwerów DNS, nazwa maszy-
ny. Oprócz tego moga˛ być przesyłane adresy serwerów czasu, adresy routerów, serwerów druku.
Ponieważ BOOTP używa do transportu informacji UDP, a ten jak wiemy jest protokołem
zawodnym, ważne jest aby pakiety odpowiedzi nie były zfragmentowane. Wielu klientów może
dysponować za małym buforem, aby móc złożyć pakiet. Poza tym klient sam musi zapewnić so-
bie mechanizmy ochrony przed odebraniem uszkodzonego pakietu. Dlatego też BOOTP wymaga
używania sum kontrolnych.
0 8 16 24 31
Operacja Typ sprzêtu D³. adr. sprzêt. L. przeskoków

Identyfikator
Czas (s) od momentu startu klienta
Adres IP klienta (0 w przypadku pytania o adres)
Adres IP klienta (odpowiedŸ serwera z numerem IP klienta)
Adres IP serwera
Adres IP domyœlnej bramy
Adres sprzêtowy klienta (16 Bajtów)
Nazwa serwera (64 Bajty)
Nazwa pliku startowego z obrazem j¹dra (128 Bajtów)
Dane dodatkowe (64 Bajty)
Rysunek 5.10: Nagłówek BOOTP.
W przypadku gdy klient nie otrzyma odpowiedzi, po wyznaczonym, losowym czasie oczeki-
wania ponawia swoja˛ prośb˛e. Losowość ma w tym przypadku bardzo duże znaczenie. Po awarii
zasilania albo w momencie rozpoczynania zaj˛eć w laboratorium z kilkudziesi˛ecioma maszynami,
wszystkie komputery wysyłaja˛ zapytania BOOTP do serwera co może spowodowa ć jego przecia- ˛
żenie. Przy losowym czasie oczekiwania komputery b˛eda˛ stopniowo otrzymywały odpowiedzi.
Jeśli czas byłby jednakowy dla wszystkich, serwer znowu byłby przeciażany. ˛
Mimo tylu zalet protokół BOOTP nie rozwiazuje ˛ problemu dynamicznej konfiguracji w sie-
ciach, w których klienci zmieniaja˛ si˛e z duża˛ cz˛estotliwościa.˛ Zwłaszcza, że sieci te maja˛ ogra-
niczona˛ pul˛e adresów IP i nie można stworzyć w nich indywidualnych konfiguracji dla każdego.
Protokół DHCP rozwiazuje˛ ten problem.
Podobnie jak BOOTP, DHCP do rozpoznawania klienta używa identyfikatora. Najcz˛e ściej
jest nim jego adres MAC. Na jego podstawie serwer określa w jaki sposób przyzna adres: sta-
tycznie, dynamicznie, na stałe. Najbardziej interesujace ˛ jest dynamiczne przyznawanie adresów.
W tym przypadku serwer nic nie wie o kliencie. Ma do dyspozycji tylko pul˛e adresów „przyzna-
nych” mu przez administratora, reguły według których może adresy przyznawa ć oraz niezb˛edne
parametry sieci.
Klient chcac
˛ uzyskać adres rozgłasza w sieci komunikat DHCPDISCOVER. Wszystkie ser-
wery DHCP w sieci, które odebrały komunikat i sa˛ skonfigurowane tak, żeby na niego odpowie-
dzieć, wysyłaja˛ wiadomość DHCPOFFER. Klient najcz˛eściej wybiera pierwsza˛ z odpowiedzi
reszt˛e ignorujac.
˛ Nast˛epnie rozpoczyna z serwerem negocjacj˛e „wynaj˛ecia” adresu wysyłajac ˛
DHCPREQUEST. Serwer potwierdza odebranie komunikatu przez nadanie do klienta DHC-
PACK. W tym momencie klient dostaje informacje o konfiguracji sieci. Jednak otrzymany adres
94 5.7. Protokół DNS
jest wynaj˛ety tylko na określony czas. W tym czasie serwer nie b˛edzie oferował tego adresu in-
nym klientom. Jeśli pod koniec okresu wynajmu klient nie odnowi dzierżawy adresu serwer uzna,
że może go ponownie użyć w negocjacji wynajmu z innym klientem. W przypadku gdy klient
chce przedłużyć okres wynajmu wysyła do serwera DHCPREQUEST z zapytaniem o przedłuże-
nie czasu używania tego adresu. Jeśli serwer si˛e zgadza, to odpowiada DHCPACK (DHCPNACK
w przeciwnym przypadku). Gdy klient otrzyma DHCPNACK, natychmiast przestaje używa ć sta-
rego adresu i rozpoczyna negocjacje od poczatku. ˛ Podobnie dzieje si˛e gdy serwer, od którego
komputer otrzymał adres, staje si˛e niedost˛epny. Wówczas wysyłany jest komunikat DHCPRE-
QUEST w sieci. Jeśli któryś z serwerów odpowie, maszyna zachowuje si˛e zgodnie z przedsta-
wiona˛ procedura.˛ Jeśli nie otrzyma odpowiedzi w odpowiednim czasie zaprzestaje używania
starego adresu i rozpoczyna procedur˛e od poczatku. ˛
Oczywiście klient może zwolnić adres przed upływem czasu „wynajmu”. W tym celu klient
wysyła serwerowi komunikat DHCPRELEASE. Po wysłaniu tego komunikatu klient zaprzestaje
używania starego adresu.
5.7. Protokół DNS

Wiemy już, że do komunikowania si˛e w sieci maszyny wykorzystuja˛ adresy. Ich format oraz
wartości sa˛ jednak trudne do zapami˛etania przez człowieka. Znacznie lepiej zamiast adresu
193.59.201.40 pami˛etać www.dns.pl. Jest to tzw. nazwa kanoniczna. Jej format odzwierciedla
hierarchi˛e systemu nazw używanego w sieci Internet czyli DNS (ang. Domain Name Service).
Poczatkowo,
˛ gdy komputerów w sieci było niewiele, ich nazwy znajdowały si˛e w jednym
pliku tekstowym. W miar˛e upływu czasu, gdy komputerów w sieci zaczynało już by ć wi˛ecej,
zarzadzanie
˛ tym plikiem, jego przeszukiwanie stało si˛e bardzo trudne. Dlatego też zdecydowano
si˛e na przejście na hierarchiczny system nazw. Dodatkowo system ten jest rozproszony.
Przyj˛ety system nadawania nazw odzwierciedla struktur˛e sieci Internet. Podłaczone˛ sa˛ do
niej uczelnie, jednostki administracji rzadowej,
˛ firmy komercyjne, wojsko, itd. Każda z tych
grup ma pewna˛ doz˛e autonomii oraz jest odpowiedzialna z przydział nazw w jej obr˛ebie. Sce-
dowanie odpowiedzialności za porzadek ˛ panujacy
˛ w danej grupie ułatwia zarzadzanie
˛ nazwami
w Internecie.
Najwyższy poziom w hierarchii, czyli korzeń drzewa nazw, prezentuje znak ".". W syste-
mie DNS nie określono w ścisły sposób, jak maja˛ być nazywane kolejne poziomy, a jedynie
format nazw. W zasadzie wartość nazwy może być dowolna. Jednak, aby nie wprowadzać bała-
ganu przyj˛eto pewne zasady używania nazewnictwa i w nast˛epnym po "." poziomie zostały uj˛ete
nazwy:
1. com. – organizacje komercyjne,
2. edu. – instytucje edukacyjne,
3. gov. – administracja rzadowa,
˛
4. mil. – wojsko,
5. net. – centra kontroli pracy sieci,
6. org. – organizacje nie pasujace˛ do żadnej z powyższych grup,
7. arpa. – specjalna domena do wiazania˛ adresów IP z nazwami,
8. int. – organizacje mi˛edzynarodowe,
Ponieważ poczatkowo
˛ Internet istniał tylko w USA, system nadawania nazw nie odzwierciedlał
gov com edu pl mil org …
usa sun edu com gov nask …
pw uw pwn sejm …
Rysunek 5.11: Hierarchia nazw.
podziałów terytorialnych państw. Gdy pozostałe państwa zacz˛eły si˛e przyłaczać

˛ do sieci Internet
oprócz systemu organizacyjnego nazywania dodano nazewnictwo terytorialne w postaci dwuli-
terowych kodów krajów dodawanych do wymienionych nazw. Oprócz tego dodano kody krajów
bezpośrednio po znaku ".". Kody te nie sa˛ stosowane w USA jako „kolebce” Internetu.
W każdej z tych grup dodawane sa˛ nazwy nowych komputerów zgodne z ich „pochodze-
niem”. Jeśli rejestrujemy nazw˛e dla naszej firmy, świadczacej˛ komercyjne usługi, może ona zo-
stać dodana do systemu DNS jako:
nazwa_firmy.com – jeśli rejestrujemy domen˛e w USA i jest ona zwiazana ˛ z działalnościa˛
komercyjna,˛
nazwa_firmy.com.pl – jeśli rejestrujemy domen˛e w Polsce i również jest ona zwiazana ˛
z działalnościa˛ komercyjna,˛
nazwa_firmy.pl – bezpośrednio w domenie ".pl" w przypadku dużych organizacji w danym
kraju, serwisów informacyjnych o kraju, itd.
W ten sposób system nazw DNS ma struktur˛e drzewa, w którym liście to nazwy konkretnych
maszyn a w˛ezły to serwery obsługujace ˛ kolejne poziomy hierarchii.
Ważna˛ cecha˛ tego sytemu jest jego niezależność od geograficznego miejsca położenia maszy-
ny o danej nazwie. Co wi˛ecej, awaria serwera obsługujacego ˛ dany fragment drzewa powoduje,
że tylko ten fragment i przechowywane w nim nazwy przestaja˛ być dost˛epne a nie komputery
w całej sieci jak w przypadku płaskiego pliku. Choć w przypadku stosowania kilku serwerów
nazw dla danej domeny można uniknać ˛ sytuacji, w której nazwy obsługiwane przez dany serwer
przestaja˛ być „widoczne” w Internecie.
Przed nadaniem nazwy zaaprobowanej przez lokalna˛ organizacj˛e przyznajac ˛ a˛ nazwy (ISP,
96 5.7. Protokół DNS
administrator), organizacja ta musiała wcześniej uzyskać zgod˛e na zarzadzanie ˛ dana˛ domena,˛

np. pw.edu.pl od władz zarzadzaj˛ acych
˛ domena˛ edu w Polsce. W ten sposób domena pw.edu.pl
ma swojego administratora, który rozdziela nazwy w jej obr˛ebie a władze zarzadzaj ˛ ace
˛ domena˛
edu nie musza˛ już o to martwić. Fragment hierarchii nazw w Internecie jest przedstawiony na
rys. 5.11
Na podstawie danych zebranych w serwerach DNS oraz protokołu wymiany komunikatów
mi˛edzy klientami a serwerami, użytkownicy nie musza˛ pami˛etać adresów maszyn, z którymi
chca˛ si˛e komunikować. Przed połaczeniem
˛ si˛e ze zdalna˛ maszyna,˛ aplikacje staraja˛ si˛e ustalić
jaki jest jej adres przy pomocy lokalnego programu odwzorowujacego. ˛ Program ten w tym celu
sprawdza swoja˛ pami˛eć podr˛eczna.˛ Jeśli nie znajduje tam informacji o poszukiwanej maszynie to
buduje zapytanie, które nast˛epnie wysyła do serwera (w jednym komunikacie do serwera może
być wiele zapytań). W przeciwnym przypadku udziela nieautorytatywnej1 odpowiedzi klientowi.
Każde zapytanie zawiera nazw˛e, dla której poszukiwany jest adres IP oraz typ poszukiwanej in-
formacji, np. czy chodzi nam tylko o adres, czy o nazw˛e serwera pocztowego dla danej domeny.
Jeśli serwer zna odpowiedź na pytanie to odsyła ja˛ klientowi. W przeciwnym przypadku odsyła
list˛e serwerów, które moga˛ dostarczyć odpowiednich informacji. W nast˛epnym kroku klient b˛e-
dzie kierował zapytania do nich, aż dotrze do serwerów obsługujacych ˛ najwyższy poziom nazw,
jeśli żaden serwer wcześniej nie odpowie poszukiwanymi danymi. Jest to tzw. iteracyjny spo-
sób rozwiazywania
˛ nazw. Druga możliwa metoda to tzw. zapytania rekurencyjne. Jeśli serwer
otrzyma tego typu zapytanie i nie potrafi udzielić na nie odpowiedzi, wysyła zapytania do in-
nych serwerów i odsyła klientowi uzyskana˛ odpowiedź. Tym sposobem zawsze, o ile tylko taka
informacja jest zapisana w systemie DNS, klient otrzyma odpowiedź z poszukiwana˛ informacja.˛
Rys. 5.12 przedstawia format komunikatów protokołu DNS.
Pole IDENTYFIKATOR służy klientowi do powiazania ˛ odpowiedzi z zapytaniem. PARA-
METR określa, czy np. jest to pytanie czy odpowiedź, typ pytania: standardowe, odwrotne, ża- ˛
danie rekursji. Klient przede wszystkim wypełnia pole PYTANIE. Ma ono swój wewn˛etrzny
format przedstawiony na rys. 5.13
Pole NAZWA może mieć zmienna˛ długość. Jest prezentowane jako ciag ˛ nazw, każda poprze-
dzona bajtem określajacym
˛ jej długość. Pole KLASA umożliwia zapytanie o nazw˛e dowolnego
obiektu w systemie. Nazwy Internetowe sa˛ jedna˛ z możliwych opcji. Pole TYP pozwala określić
klientowi rodzaj zapytania a serwerowi rodzaj danych w odpowiedzi. Możliwości sa˛ nast˛epujace: ˛
A – adres maszyny,
CNAME – nazwa kanoniczna,
HINFO – nazwa procesora i systemu operacyjnego,
MINFO – informacja o skrzynce lub liście pocztowej,
MX – preferencja i nazwa maszyny obsługujacej ˛ wymian˛e poczty dla danej domeny,
NS – nazwa serwera nazw z autorytatywnymi informacjami dla danej domeny,
PTR – wskaźnik na nazw˛e maszyny,
SOA – pola określajace
˛ za które cz˛eści hierarchii DNS serwer jest odpowiedzialny,
TXT – dowolny tekst.
Typ PTR jest szczególnie użyteczny przy zapytaniach odwrotnych. Pytanie tego typu zawie-
ra adres IP maszyny, dla której chcemy znaleźć nazw˛e. Zapytanie to jest konstruowane przez
1 Odpowiedź serwera jest nieautorytatywna w przypadku gdy serwer udzielajacy
˛ odpowiedzi nie jest to głównym
serwerem DNS dla domeny komputera, o który nadeszło zapytanie.
0 16 31
Identyfikacja Parametr
Liczba pytañ Liczba odpowiedzi

Liczba serwerów autorytatywnych Liczba informacji dodatkowych
Pytania
Odpowiedzi
Serwery autorytatywne
Dodatkowe odpowiedzi
Rysunek 5.12: Format komunikatu protokołu DNS.
odwrócenie poszukiwanego adresu IP, np. 172.16.7.2 na 7.16.172, w specjalnej domenie nazw
IN-ADDR.ARPA (7.16.172.in-addr.arpa). Lokalny serwer DNS powinien zawiera ć informacj˛e
o nazwach maszyn w tej domenie.
5.8. Protokół IPv6

Protokół IPv4 działa bardzo dobrze do dnia dzisiejszego. Jednak zmiany takie, jak nowe tech-
niki komunikacyjne: sieci bezprzewodowe, GPRS (ang. General Packet Radio Service), nowe
programy użytkowe, zwi˛ekszenie si˛e liczby przyłaczonych
˛ do sieci Internet komputerów oraz
planowane umożliwienie komunikacji poprzez sieć nowym rodzajom urzadzeń˛ powoduja,˛ że ko-
nieczne sa˛ rozszerzenia tego protokołu – na jego nowsza˛ wersj˛e IPv6. Główne argumenty, które
za tym przemawiaja,˛ sa˛ nast˛epujace:
˛
wyczerpanie si˛e dost˛epnej przestrzeni adresowej,
popularność stosowania programów użytkowych przesyłajacych˛ dźwi˛ek i obraz (wymaga
zagwarantowania ustalonych parametrów transmisji),
brak możliwości uwierzytelniania nadawcy.
W momencie, gdy IPv4 był projektowany, problemów tych nie było – ponieważ nikt jeszcze
wtedy nie myślał o tak szerokim zastosowaniu Internetu.
0 16 31
NAZWA
TYP KLASA
Rysunek 5.13: Format pola PYTANIE z komunikatu protokołu DNS.
Proponowany przez IETF (ang. Internet Engineering Task Force) IPv6 jest tak na prawd˛e
nie nowym protokołem a ulepszona˛ wersja˛ IPv4. Wi˛ekszość mechanizmów działajacych ˛ w IPv4
została zachowana. Prace nad IPv6, mimo tego że jego uruchomienie ogłaszano już wielokrotnie,
sa˛ zwiazane
˛ z:
długościa˛ adresów,
formatem nagłówka,
informacjami opcjonalnymi,
wsparciem dla mechanizmów rezerwacji zasobów,
możliwościami rozszerzania protokołu w przyszłości.
Projektanci nowego protokołu, pami˛etajac ˛ o kłopotach z adresowaniem klasowym w IPv4,
postanowili problem rozwiazać
˛ przez zwi˛ekszenie długości adresu z 32 do 128 bitów. Daje to
możliwość zaadresowania 1012 stacji końcowych i 109 sieci. Z drugiej jednak strony, zwi˛ekszenie
nagłówka pakietu przyczynia si˛e do wolniejszego przetwarzania go przez routery. Tym samym
wyznaczanie tras dla pakietów stałoby si˛e wolniejsze i przeczyło by założeniom o wsparciu IPv6
dla przenoszenia strumieni audio/video. W zwiazku ˛ z tym cz˛e ść pól została usuni˛eta z nowego
formatu nagłówka. Dzi˛eki temu, mimo że zwi˛ekszono 4 krotnie wielkość adresu, nagłówek ma
zawsze 40 bajtów. Jest to zmiana w porównaniu do nagłówka IPv4, którego długość może być
zmienna – od 20 do 60 bajtów. Jak widać na rys. 5.14, nowy nagłówek (w wersji podstawowej)
zawiera tylko 7 pól stałej długości – zawsze 40 bajtów dla nagłówka podstawowego. Pole opcje
(zmiennej długości) zostało przesuni˛ete do nagłówków dodatkowych.
Dzi˛eki temu routery nie musza˛ pracowicie wyliczać sum kontrolnych nagłówka. Zostało to
przeniesione do innej warstwy stosu protokołów. Zreorganizowaniu uległo również fragmento-
wanie pakietów. Zlikwidowano pola dotyczace ˛ fragmentacji pakietów w nagłówku IPv4 i prze-
niesiono ich funkcj˛e do specjalnego nagłówka rozszerzajacego ˛ w IPv6 (jak również inne opcje
dodatkowe do podobnych nagłówków). Routery transmitujace ˛ pakiety IPv4 musza˛ każdorazo-
wo badać rozmiar pakietu i porównywać jego rozmiar z MTU (ang. Maximum Transfer Unit)
obowiazuj
˛ acym
˛ na danym łaczu
˛ i w razie konieczności dokonywać jego defragmentacji. Tego
typu podejście obniża wydajność urzadzeń,
˛ a co za tym idzie całej sieci. W protokole IPv6 przed
wysłaniem pakietu stacja nadawcza musi określić MTU dla całej trasy pakietu za pomoca˛ spe-
cjalnego protokołu – MTU Path Discovery.
0 4 12 16 24 31
Wersja Klasa ruchu Identyfikator potoku

D³ugoœæ pakietu Nastêpny nag³. Hop limit (TTL)
Adres Ÿród³owy
Adres docelowy
Rysunek 5.14: Nagłówek IPv6.
Pole TTL z IPv4 w nagłówku IPv6 ma nazw˛e HOP VALUE. Jego maksymalna wartość to
jak poprzednio 255. Również pełniona funkcja, zapobieganie powstawaniu p˛etli w sieciach, nie
uległa zmianie.
Zapewnienie dobrej jakości transmisji strumieni audio i video, powierzone polu TOS (ang. Ty-
pe of Service) w IPv4, w IPv6 zostało zawarte w polu TRAFFIC CLASS o tej samej długości .
Pozwala ono na definiowanie usług z gwarantowanym poziomem obsługi QoS (ang. Quality of
Service). Rozszerzenie możliwości świadczenia usług z określona˛ jakościa˛ daje w nim 20 bito-
we pole Flow Label, lecz na razie nie ma szczegółowych ustaleń co do wykorzystania tego pola
w praktyce. Pole to jest podzielone na dwa podpola. Pierwsze 4 bity wyznaczaja˛ klas˛e ruchu
(wartości 0
7 określaja˛ wrażliwości na zmiany czasów opóźnień, 8 15 wyznaczaja˛ prio-
rytet). Pozostałe identyfikuja˛ potok danych. Pole PAYLOAD LENGTH wyraża długość pakietu
w oktetach. Dopuszczalne sa˛ wartości z zakresu od 576 do 65535 bajów. W razie konieczności
możliwe jest ustawienie wartości 0 w tym polu i przesłanie dłuższego pakietu zwanego JUMBO-
GRAMEM.
Rozszerzenia nagłówka Najistotniejsza˛ zmiana˛ w porównaniu z dotychczasowym protokołem

sa˛ nagłówki rozszerzajace.
˛ Przy pomocy pola NEXT HEADER można określić, jaki nagłówek
rozszerzajacy
˛ znajduje si˛e za nagłówkiem podstawowym, a przed nagłówkiem transportowym.
Nagłówki te tworza˛ ściśle określone moduły, co pozwala na ich szybkie przetwarzanie. Nie ma
ograniczenia co do ich liczby – sa˛ za to ograniczenia co do kolejności ich wyst˛epowania. Na-
główki te zapewniaja˛ mi˛edzy innymi możliwość fragmentacji i autentykacji pakietów. Podobne
możliwości zapewniały opcjonalne pola w nagłówku IPv4, lecz nie były zbyt szeroko stoso-
wane, gdyż obniżały wydajność przetwarzania pakietów. Koncepcja rozszerzonych nagłówków
pozwala na łatwe rozbudowanie możliwości protokołu IPv6 o nowe możliwości bez konieczno-
ści zmian w głównym nagłówku. Dotychczas zdefiniowane nast˛epujace ˛ nagłówki:
Hob-by-Hop options header,
100 5.9. Podsumowanie
Destination options header-1,

Source Routing header,
Fragmentation header,
Authentication header,
IPv6 Encryption header,
Destination option header-2.
Obecność rozszerzonego nagłówka jest sygnalizowana poprzez odpowiednia˛ wartość pola NEXT
HEADER VALUE (NHV) nagłówku IPv6. Każdy z nagłówków rozszerzonych posiada własne
8 bitowe pole NHV wskazujace ˛ na ewentualny nast˛epny nagłówek rozszerzajacy.
˛ W tych polach
również powinny si˛e znaleźć wartości określajace
˛ typ nast˛epnego nagłówka. W ostatnim nagłów-
ku rozszerzonym znajduje si˛e wartość pola określajaca
˛ typ nagłówka warstwy transportowej, na
przykład nagłówek TCP.
5.9. Podsumowanie
W powyższych punktach zostały przedstawione podstawowe informacje dotyczace ˛ protokołów
pozwalajacych
˛ na wymian˛e informacji w sieciach transmisji danych, bazujacych
˛ na protokole
IPv4. Osoby pragnace ˛ dokładniej poznać szczegółowe mechanizmy ich działania b˛eda˛ oczywi-
ście musiały si˛egnać
˛ do dodatkowych źródeł wiedzy. Niemniej jednak przedstawiony tu zasób
informacji powinien pozwolić na zrozumienie podstaw działania sieci komputerowych i zwiaza-
˛
nych z nimi problemów.
Bibliografia
[1] Douglas E.Comer. Sieci komputerowe TCP/IP: Zasady, protokoły i architektura. Wydaw-
nictwa Naukowo–Techniczne, Warszawa, 1997.
[2] Information Sciences Institute. Internet Protocol, September 1981. RFC 791.
R OZDZIAŁ 6
Routing pakietów IP
Dwa komputery komunikujace ˛ si˛e poprzez sieć wysyłaja˛ do siebie pakiety. Aby pakiety trafiały
do miejsca przeznaczenia musza˛ przejść określona˛ tras˛e. Sposób określania trasy pakietów okre-
śla si˛e mianem routingu. Każdy pakiet może być przesyłany poprzez elementy pasywne sieci,
takie jak przewody telefoniczne, światłowody oraz poprzez urzadzenia
˛ aktywne takie jak route-
ry, przełaczniki,
˛ koncentratory. Sposób organizacji pakietu zależy od rodzaju protokołu użytego
do jego stworzenia. Dla routingu pakietów najwi˛eksze znaczenie maja˛ urzadzenia ˛ zwane Ro-
uterami. Routery realizuja˛ funkcje routingu pakietów dla protokołów routowalnych. Protokół
routowalny to dowolny protokół, który w swojej budowie zawiera informacje o adresowaniu
sieci, umożliwiajace
˛ przeniesienie pakietów pomi˛edzy dwoma urzadzeniami˛ sieciowymi, które
korzystaja˛ z tego protokołu. Protokołu routowalnego nie należy mylić z protokołem routingu.
Zadaniem protokołu routingu jest dostarczenie mechanizmów wymiany informacji o routingu
pomi˛edzy routerami, pracujacymi
˛ w danej sieci. Definicje routingu można znaleź ć np. w ency-
klopedii. Brzmieć ona może np. tak:
Routing – wytyczanie trasy, wyznaczanie trasy, trasowanie, wybieranie najlepszej drogi w ce-
lu przesłania komunikatu mi˛edzy komputerami pracujacymi ˛ w sieci, podstawowe zadanie war-
stwy sieciowej modelu wzorcowego ISO/OSI. Trasa może być raz ustalona i niezmienna, wy-
znaczana na zasadzie obwodu wirtualnego lub określana dynamicznie, dla każdego komunikatu
(a nawet pakietu) z osobna1 .
6.1. Urzadzenia
˛ w sieci IP
W sieci IP mamy do czynienia z dwoma zasadniczymi typami urzadze ˛ ń zwanymi hostem i ro-
uterem. Host można zdefiniować jako komputer lub inne urzadzenie,
˛ które jest podłaczone
˛ do
sieci IP, ale nie pełni w niej wyróżnionych zadań zwiazanych
˛ z wyznaczaniem trasy pakietów.
Korzysta on z sieci, by wymieniać dane z innym hostami. Host jest przyłaczony
˛ do jednej lub
wielu podsieci IP, ale nie transmituje pakietów pomi˛edzy tymi sieciami. Zadanie to realizuje ro-
uter. Transmituje on pakiety IP pomi˛edzy sieciami. Decyzje o wyborze trasy podejmuje on na
podstawie tablicy routingu. Sposób wpisywania tras do tablicy routingu definiuje, czy mamy do
czynienia z routingiem statycznym czy dynamicznym. Router IP z punktu widzenia technicznego
to rodzaj komputera, wyposażonego w wiele interfejsów prowadzacych ˛ do różnych sieci, wraz
z oprogramowaniem realizujacym ˛ funkcje routingu (wyboru trasy). Funkcje routera może pełni ć
zarówno specjalnie dedykowane urzadzenie
˛ jak i zwykły komputer z odpowiednim oprogramo-
waniem. Przykładem routerów sprz˛etowych sa˛ urzadzenia
˛ firm CISCO, Nortel Networks, Juniper
1
Powyższa definicja została zaczerpni˛eta z encyklopedii znajdujacej
˛ si˛e na stronie http://wiem.onet.pl
101
102 6.2. Tablica routingu
etc. Routerami programowymi moga˛ być komputery z systemami operacyjnymi Linux, Windows
2000, UNIX lub dedykowanym oprogramowaniem takim jak na przykład KA9Q. Wi˛ekszość sys-
temów operacyjnych ma zdolność routowania pakietów, ale ta możliwość jest cz˛esto domyślnie
wyłaczona.
˛
6.2. Tablica routingu

Tablica routingu to baza informacji o trasach. Z punktu widzenia administratora ma ona format
tabeli w postaci: adres-sieci/hosta, maska-podsieci, adres-nast˛epnego-routera, metryka. W zależ-
ności od implementacji, tablica może zawierać szereg dodatkowych informacji. Moga˛ to być:
interfejs, poprzez który pakiet ma być wysłany;
oznaczenie protokołu, który dana˛ tras˛e wpisał do tablicy;
czas ważności trasy.
W niektórych routerach możliwe jest zastapienie
˛ adresu nast˛epnego skoku nazwa˛ interfejsu, po-
przez który pakiet ma być nadany. Możliwe jest też zdefiniowanie wielu takich samych tras
statycznych poprzez różne interfejsy.
6.3. Routing statyczny

O routingu statycznym mówimy wtedy, gdy trasy sa˛ wpisane do tablicy routingu przez admi-
nistratora. Administrator sam określa wszystkie parametry trasy. Ma to niewatpliwe ˛ zalety – na
przykład taka,˛ że wszystkie trasy w routerach sa˛ dobrze znane i kontrolowane. Można wi˛ec po-
wiedzieć, że sieć oparta o routing statyczny zachowuje si˛e w sposób przewidywalny, gdyż bł˛edy
w routingu jeśli wyst˛epuja˛ to wyłacznie
˛ z powodu bł˛ednych wpisów. Routing statyczny nie ob-
ciaża
˛ łaczy
˛ dodatkowa˛ wymiana˛ informacji i jest wygodny do konfiguracji w małych sieciach.
Niestety przy użyciu routingu statycznego trudno jest tworzyć połaczenia
˛ redundatne oraz dy-
namicznie rozkładać obciażenie
˛ łaczy.
˛ Trudno jest też zbudować duża˛ sieć w oparciu routing
statyczny, gdyż jakakolwiek zmiana w sieci powoduje konieczność rekonfiguracji sporej cz˛eści
jej routerów.
6.3.1. Metryka trasy

Każda z tras znajdujaca ˛ si˛e w tablicy routingu ma przypisana˛ określona˛ metryk˛e. Pozwala ona
określić jakość danej trasy w tablicy. Im metryka jest mniejsza, tym trasa jest lepsza. Ma to
szczególne znaczenie w wypadku, gdy do jakiegoś miejsca prowadzi wi˛ecej tras. Metryka po-
zwala wybrać najlepsza.˛ Najniższa˛ metryk˛e maja˛ zwykle trasy zwiazane
˛ z interfejsami routera,
a nast˛epnie trasy wpisane statycznie. Protokoły routingu korzystaja˛ z różnych mechanizmów wy-
znaczania metryki trasy. Do wyznaczenia metryki może być branych pod uwag˛e wiele rożnych
czynników jak na przykład:
liczba przejść poprzez routery;
przepustowość łaczy;
˛
stopa bł˛edów na łaczach;
˛
opóźnienie na poszczególnych łaczach
˛ i routerach
Routing pakietów IP 103
wartość kosztu ustawiona przez administratora.

Co z tych danych zostanie użyte do wyznaczania metryki zależy od potrzeb i protokołów.
W protokołach routingu, które b˛eda˛ omawiane stosowane sa˛ pierwsze dwa czynniki.
6.3.2. Trasy domyślne i interfejsy

Do tablicy routingu automatycznie dopisywane sa˛ sieci, które sa˛ zdefiniowane na interfejsach
routera. Maja˛ one z definicji metryk˛e równa˛ zero, o ile nie zadeklaruje si˛e inaczej. Dodatkowo
w wielu routerach definiuje si˛e tzw. routing domyślny. W przypadku routerów dla pakietów IP
jako adres sieci podaje si˛e adres 0.0.0.0 i mask˛e 0.0.0.0. Wpis w tablicy routingu wyglada ˛ wi˛ec
nast˛epujaco:
˛ 0.0.0.0, 0.0.0.0 adres-nast˛epnego-routera, metryka. Każdy pakiet, któremu nie zna-
leziono innej drogi, jest wysyłany pod adres routera umieszczony w tym wpisie. Trasy domyślne
najcz˛eściej definiowane sa˛ statycznie przez administratora, ale moga˛ być również rozgłaszane za
pomoca˛ protokołów routingu.
6.4. Routing dynamiczy

O routingu dynamicznym mówimy wtedy, gdy zawartość tablic routingu jest wpisywana po-
przez protokół routingu dynamicznego. Routing dynamiczny pozwala na zbudowanie bardziej
skalowalnej sieci, gdyż zwalnia on administratora z konieczności konfigurowania wszystkich ro-
uterów. Dołaczenie
˛ kolejnego routera w sieci, w której wykorzystywany jest protokół routingu
dynamicznego, sprowadza si˛e w zasadzie do konfiguracji parametrów dołaczanego
˛ routera oraz
routerów z nim sasiaduj
˛ acych.
˛ Rounting dynamiczny pozwala sieci na elastyczne reagowanie na
zmiany jej struktury. W wypadku awarii jednego z w˛ezłów, routery sa˛ wtedy w stanie wytyczy ć
automatycznie nowa˛ drog˛e. Warunkiem koniecznym jest oczywiście istnienie alternatywnej dro-
gi. Czas wyznaczenia nowej drogi jest zależny od rodzaju używanego protokołu routingu oraz
konfiguracji routerów. Zastosowanie protokołu routingu dynamicznego wymaga od administra-
tora posiadania znacznie wi˛ekszej wiedzy, niż jest konieczna do ustawienia routingu statycznego.
Routing dynamiczny stawia wi˛eksze wymagania co do sprz˛etu, na którym b˛edzie wykorzysty-
wany. Wymagania te sa˛ tym wi˛eksze, im wi˛eksza jest sieć, bardziej złożona jej topologia oraz
bardziej skomplikowany jest protokół routingu dynamicznego.
6.4.1. Klasyfikacja protokołów routingu dynamicznego

Protokoły routingu klasyfikuje si˛e najcz˛eściej przyjmujac
˛ jedno z dwóch kryteriów: miejsce za-
stosowania lub sposób wyznaczanie trasy. W przypadku miejsca zastosowania protokoły dzieli-
my na:
zewn˛etrzne;
wewn˛etrzne.
Protokoły zewn˛etrzne sa˛ stosowane do wymiany informacji o routingu pomi˛edzy sieciami
zarzadzanymi
˛ przez różne podmioty np. przez różnych operatorów telekomunikacyjnych. Przy-
kładem takiego protokołu jest protokół BGP (ang. Border Gateway Protocol).
Protokoły wewn˛etrzne stosowane sa˛ wewnatrz ˛ domen administracyjnych zarzadzanych
˛ przez
jeden podmiot. Przykładem może być sieć wewn˛etrzna jakiejś firmy. Tego typu sieć określa si˛e
104 6.5. Protokół RIP
jako system autonomiczny. Przykładem takiego protokołu jest RIP (ang. Routing Information
Protocol).
Drugim kryterium klasyfikacji protokołów jest sposób wyznaczania trasy. W przypadku tego
kryterium wyróżniamy protokoły:
dystans-wektor;
stanu łacza.
˛
W protokołach typu dystans-wektor routery wymieniaja˛ pomi˛edzy soba˛ informacje o zna-
nych adresach przeznaczenia, kierunkach, w których należy przesłać pakiet i o odległościach li-
czonych w liczbie przeskoków pomi˛edzy routerami jakie należy wykonać, aby dotrzeć do miej-
sca przeznaczenia. W protokołach tego typu do wyliczenia najlepszej drogi nie jest brana pod
uwag˛e jakość łacza.
˛ Łatwo jest zrozumieć sposób działania tego typu protokołu, gdyż najlepsza
droga jest droga˛ wiodac ˛ a˛ przez najmniejsza˛ liczb˛e routerów. Jest to także zasadnicza wada tego
typu protokołów, gdyż na skutek wyliczeń trasy pakiety moga˛ być transmitowane przez wolne
łacze
˛ szeregowe wiodace ˛ poprzez dwa routery zamiast iść poprzez łacza˛ gigabitowe, ale poprzez
trzy routery. Dlatego też protokoły te maja˛ zastosowanie przede wszystkim w sieciach wewn˛etrz-
nych o jednolitej strukturze. Wada˛ tego typu protokołów jest też nie przekazywanie przez routery
informacji o źródle, z którego si˛e dowiedziały o trasie. Skutkuje to rozsyłaniem uaktualnie ń do
wszystkich swoich sasiadów
˛ niezależnie od tego czy to jest potrzebne czy nie, a to może spowo-
dować znaczny wzrost ruchu w sieci. Nieskomplikowany algorytm wyznaczania trasy powoduje
zmniejszenie wymagań na moc procesora w routerze. Przykładem takiego prostego protokołu
jest protokół RIP.
W protokołach stanu łacza ˛ routery przekazuja˛ pomi˛edzy soba˛ informacje o topologii sieci.
W tej topologii uwzgl˛edniane sa˛ segmenty sieci, do których przyłaczony ˛ jest router oraz stan
i jakość łaczy.
˛ Wi˛ekszość protokołów routingu rozsyła wyłacznie˛ informacje o zmianach, co
znacznie skraca czasy przebudowy tablic routingu. Znajomość topologii sieci pozwala protoko-
łom stanu łacza
˛ eliminować p˛etle w połaczeniach
˛ mi˛edzy routerami. Protokoły stanu łacza
˛ maja˛
też wady. Sa˛ bardziej złożone od protokołów dystans-wektor, co powoduje wi˛eksze wymagania
na moc obliczeniowa˛ i pami˛eć routerów. Protokoły tego typu sa˛ też trudniejsze w konfiguracji
i wymagaja˛ od administratora sporej wiedzy. Przykładem takiego protokołu jest OSPF.
6.5. Protokół RIP

Protokół RIP (ang. Routing Information Protocol) został zdefiniowany w dokumencie RFC 1058
w czerwcu 1988 roku. Opisuje on w pełni otwarta˛ postać protokołu routingu dystans-wektor.
Protokół ten został zaprojektowany do zastosowania w małych prostych sieciach. Obecnie ist-
nieja˛ dwie specyfikacje protokołu RIP. Wersje zawarta˛ w RFC 1058 nazywa si˛e RIP lub RIP
1.
6.5.1. Format pakietu RIP

Format pakietu protokołu RIP przenoszacego
˛ informacje o protokole IP przedstawiony jest na
rysunku 6.1. Znaczenie poszczególnych pól jest nast˛epujace:
˛
command – 1 bajtowe pole komendy określajace ˛ funkcje pakietu. Dopuszczalne sa˛ nast˛e-
pujace
˛ wartości:
0 8 16 31
command (1) version (1) must be zero (2)
address family indetifier (2) must be zero (2)
IP address (4)
must be zero (4)
must be zero (4)
metric (4)
Rysunek 6.1: Format pakietu RIP 1.
1 – request - żadanie
˛ przesłania tablicy routingu;
2 – response - odpowiedź na żadanie;
˛
3 – traceon - pakiety z tak ustawiona˛ wartościa˛ pola powinny być ignorowane;
4 – traceoff - pakiety z tak ustawiona˛ wartościa˛ pola powinny być ignorowane;
5 – reserved - wartość ta została zarezerwowana przez Sun Microsystem do ich wła-
snych celów – pakiety z tak ustawiona˛ wartościa˛ pola powinny być ignorowane;
version – 1 bajtowe pole numeru wersji protokołu RIP;
AFI (ang. Address Family Identifier) – 2 bajtowe pole określajace,
˛ który protokół jest ro-
utowany. Jeśli jest to protokół IP, to wartość pola wynosi 2;
IP address – 4 bajtowe pole adresu sieci;
must be zero – 2 lub 4 bajtowe pole wypełnione zerami;
metric – 4 bajtowe pole metryki.
Maksymalna długość pakietu RIP wynosi 512 bajtów. Pakiet jest transmitowany za pomoca˛
protokołu UDP na porcie 520. W pakiecie moga˛ być powtarzane sekwencje zawierajace ˛ od pola
2
AFI do pola metryki (czyli pole AFI, 2 bajty wypełnione zerami, adres IP , 8 bajtów wypełnio-
nych zerami oraz cztery bajty z metryka). ˛ Takie sekwencje moga˛ powtórzyć si˛e 25 razy, co daje
możliwość przeniesienia w pojedynczym pakiecie informacji o 25 pozycjach tablicy routingu.
Jeśli tablica routingu jest dłuższa, to wymagane jest jej podzielenie i wysłanie w kolejnych pakie-
tach. Format pakietu umożliwia przeniesienie informacji routingowych dla dowolnego protokołu
routingu. W przypadku, gdy przenoszone sa˛ dane dla protokołu IP, w polu AFI musi by ć ustawio-
na wartość 2. Ponieważ jest to pierwsza specyfikacja protokołu RIP, to w polu version musi by ć
ustawiona wartość 1. W polu command w praktyce moga˛ pojawić si˛e dwie wartości. Gdy wartość
pola ustawiona jest na 1 oznacza to, że pakiet jest pakietem-żadaniem
˛ przesłania tablicy routingu
routera. W polu adresu IP router umieszcza swój adres. Router odbierajacy ˛ takie żadanie
˛ wysy-
ła pakiet-odpowiedź z ustawiona˛ w polu command wartościa˛ 2. W pakiecie-odpowiedzi router
umieszcza adresy IP ze swojej tablicy routingu. Jeśli ma ich wi˛ecej, niż mieści si˛e w jednym
pakiecie, to wysyła szereg kolejnych pakietów-odpowiedzi. W polu metric zawarta jest metryka
trasy. Jest ona wartościa˛ pomi˛edzy 1 - 15. Jest ona każdorazowo zwi˛ekszana po przejściu przez
kolejny router. Metryka trasy w przypadku protokołu RIP opisuje liczb˛e routerów, które musi
2
Cztery bajty sa˛ adresem IP jeśli wartość pola AFI wynosi 2
pokonać pakiet, aby dotrzeć do miejsca docelowego.
6.5.2. Tablica routingu RIP

Routery z uruchomionym protokołem RIP przekazuja˛ za pomoca˛ pakietów RIP informacje o ru-
tingu. Informacje te sa˛ przechowywane w routerach w tablicach routingu RIP. Każdy wiersz
takiej tablicy zawiera nast˛epujace
˛ pola:
docelowy adres IP;
metryka;
adres nast˛epnego skoku;
flagi zmiany trasy;
zegary trasy.
Pole docelowego adresu IP zawiera adres hosta lub numer sieci. Docelowy adres IP z pa-
kietu z danymi, który ma być przesłany poprzez router z uruchomionym protokołem RIP, jest
porównywany z zawartościa˛ tego pola. Jeśli zostanie znaleziony wpis odpowiadajacy ˛ adresowi
docelowemu, to pakiet zostanie przesłany pod adres zawarty w polu adresu nast˛epnego skoku.
Pole metryki określa koszt trasy, jaka˛ musi pokonać pakiet, aby dotrzeć do miejsca docelowego.
W wi˛ekszości wypadków jest to liczba routerów po drodze. Metryka równa 1 oznacza, że jest
bezpośrednie łacze
˛ do celu. Pole flagi zmiany trasy wskazuje, czy wpis zwiazany˛ z tym polem nie
uległ zmianie, tzn. czy nie nastapiła
˛ modyfikacja adresu docelowego. Z każdym wpisem zwiaza- ˛
ne sa˛ dwa zegary trasy route-timeout i route-flush. Zegary te pozwalaja˛ na określenie ważności
poszczególnych wpisów.
6.5.3. Działanie protokołu RIP

Po uruchomieniu protokołu RIP na routerze nast˛epuje proces inicjalizacji. Pierwsze wpisy w ta-
blicy routingu protokołu RIP zwiazane˛ sa˛ z konfiguracja˛ routera, na którym protokół został uru-
chomiony. Dotycza˛ one interfejsów samego routera. Zawartość tablicy jest rozsyłana do sasied- ˛
nich routerów. Router rozsyła swoja˛ tablic˛e routingu co 30 sekund, które odmierzane sa˛ przez
zegar uaktualnień. Tablica routingu jest wysyłana w serii pakietów, której długość jest zależ-
na do rozmiarów tablicy. Pakiety nie sa˛ w żaden sposób numerowane, wi˛ec nie ma pewności,
że sasiedni
˛ router otrzyma je w komplecie. Router odbiera także pakiety od sasiednich
˛ route-
rów. W miar˛e ich napływu dokonuje aktualizacji swojej tablicy routingu. Ważność tras w tablicy
routingu określaja˛ dwa zegary trasy route-timeout i route-flush. Jeśli router nie otrzymuje uak-
tualnień o danej trasie, to traci ona swoja˛ ważność. Dba o to zegar route-timeout. Zegar ten jest
inicjowany (najcz˛eściej wartościa˛ 180 sekund) za każdym razem, gdy przychodzi uaktualnienie
o danej trasie. Jeśli przez 180 sekund takie uaktualnienie nie nadejdzie, to router zaznacza taka˛
tras˛e jako nieważna˛ poprzez ustawienie flagi zmiany trasy oraz metryki na wartość 16 oraz rozsy-
ła informacje o nieważności trasy do sasiednich
˛ routerów. Przy domyślnych ustawianiach (180 s)
wpis w routerze ważny jest przez czas potrzebny na sześć kolejnych uaktualnień. Ma to t˛e zalet˛e,
że zagubienie kilku pakietów nie powoduje przerwy w pracy sieci. Niestety ma to też t˛e wad˛e,
że w przypadku gdy trasa jest faktycznie nieważna trzeba czekać aż 3 minuty, aby router prze-
stał jej używać do wysyłania pakietów. W obecnych warunkach pracy sieci komputerowych jest
to troch˛e za długo. Trasa nie jest usuwana z tablicy routingu przez czas, który odmierza zegar
route-flush. Najcz˛eściej spotykana˛ wartościa˛ jest 90 sekund, choć dokument RFC 1058 zaleca
120 sekund. W sumie od momentu stwierdzenia nieważności trasy do momentu usuni˛ecia wpisu
z tablicy routingu upłynać
˛ może 270 sekund.
Pakiet RIP wysyłany jest na adres 255.255.255.255 czyli adres rozgłoszeniowy. Otrzymu-
ja˛ go wszystkie routery i hosty w danej podsieci. Gdyby wszystkie jednocześnie próbowały
wysyłać zawartość tablicy routingu co 30 sekund to nastapiłoby
˛ zapchanie sieci. Aby routery
nie próbowały rozsyłać informacji o routingu jednocześnie, do zegara uaktualnień dodawana
jest pewna losowa wartość powodujaca˛ przesuni˛ecie czasu aktualizacji o kilka milisekund. Je-
śli w podsieci, do której wysłany został pakiet znajduja˛ si˛e również hosty to i one go odbiora.˛
B˛eda˛ zmuszone go przetworzyć i odrzucić. Powoduje to pewne obciażenie,˛ ale taka jest spe-
cyfika tego protokołu. W przypadku łacz ˛ punkt-punkt z routerami na ko ńcach informacja do-
ciera tylko do zainteresowanych. Trzeba jednak uważać w przypadku wolnych łacz ˛ i dużych
tablic routingu. Dla przesłania tablicy routingu o rozmiarze 1000 pozycji potrzeba 40 pakietów
RIP. Całkowita długość pakietu jest suma˛ długości pakietu RIP, nagłówka IP oraz nagłówka
UDP. Wynosić wi˛ec b˛edzie: 512 [bajtów](RIP) + 20 [bajtów](IP) + 8 [bajtów](UDP)
= 540 [bajtów]. Daje wi˛ec to: 540 [bajtów] * 40 [pakietów] = 21600 [bajtów]. Jeśli
˛ ma przepustowość 64 [kb/s] czyli 8 [kilobajtów/s] wi˛ec 8196 [bajtów] na sekun-
łacze
d˛e. Aby wi˛ec przesłać 21600 [bajtów] danych z tablicami routingu potrzeba: 2160 [bajtów]
/ 8196 [bajtów/s] = 2.64 [s].
Oznacza to, że przez ponad 2.64 sekundy łacze
˛ jest zaj˛ete przez transmisje tablicy routingu.
Taka sytuacja powtarzać si˛e b˛edzie si˛e co 30 sekund czyli w ciagu˛ minuty przez ponad 5 se-
kund sieć jest niedost˛epna. W obecnym stanie rozwoju sieci komputerowych sytuacja taka jest
niedopuszczalna.
6.5.4. Trasy w protokole RIP

Pakiet RIP w wersji 1 nie przenosi informacji o podsieciach. Nie ma też tej informacji w tablicy
routingu RIP. W tablicy routingu RIP moga˛ znajdować si˛e :
adres hosta
numer podsieci
0 oznaczajace
˛ tzw. default routing.
Adres hosta jest jednoznacznie identyfikowany poprzez 32 bitowy adres IP a adres sieci przez
adres sieci i mask˛e. Protokół RIP nie przenosi informacji o masce podsieci. Podsieć określana
jest na podstawie przynależności klasowej adresu lub w przypadku podsieci przyłaczonej˛ bez-
pośrednio do routera na podstawie maski ustawionej na interfejsie. W przypadku podziału sieci
na mniejsze podsieci wszystkie podsieci przyłaczone
˛ do routera z protokołem RIP powinny by ć
sobie równe. Powoduje to niepotrzebne rezerwowanie znacznych ilości adresów IP szczególnie
dotkliwie na łaczach
˛ szeregowych, których obsłużenie wymaga czterech adresów IP. Komplikuje
to także projektowanie sieci, gdyż użycie adresów z tej samej klasy, ale o różnych niezachodza-
˛
cych na siebie maskach, może spowodować niedost˛epność jednej z tych podsieci.
Wpis 0.0.0.0 w tablicy routingu RIP oznacza domyślny routing. Jest on umieszczany na koń-
cu tablicy routingu. Pakiety, których adres docelowy nie zgadza si˛e z żadnym ze wcześniejszych
wpisów, sa˛ wysyłane na adres domyślnego routera. Tego typu podejście pozwala na ogranicze-
nie rozmiarów tablic routingu. Router musi znać wyłacznie
˛ drogi do najbliższych podsieci, zaś
inne moga˛ być dost˛epne poprzez domyślny routing. W ten sposób bardzo cz˛esto realizowany jest
dost˛ep do Internetu.
W-31 W-32
31 192.168.3.0/24 32
WARSZAWA
19
/ 24 2 2 2.
.0 16
2 8.
6 8. 5.
.1 0/
2 24
19
1 1
KIELCE LUBLIN
1 1
11 192.168.1.0/24 192.168.6.0/24 11
K-11 I£-61
Rysunek 6.2: RIP – przykład działania.
6.5.5. Przykłady działania RIP

Na rysunku 6.2 jest przedstawiona prosta sieć złożona z trzech routerów nazwanych Kielce, War-
szawa, Lublin, które łacz˛ a˛ trzy podsieci. Routerem głównym jest router Warszawa. Do routera
Kielce przyłaczone
˛ sa˛ dwie podsieci: podsieć 192.168.1.0/243, w której sa˛ komputery PC oraz
podsieć 192.168.2.0/24, która służy do realizacji połaczenia
˛ z ruterem Warszawa. Podobna sytu-
acja wyst˛epuje w przypadku routera Lublin z tym, że podsieci maja˛ tam adresy 192.168.6.0/24
(lokalna sieć komputerówa) oraz 192.168.5.0/24 (połaczenie
˛ do routera Warszawa). Do routera
Warszawa dołaczone˛ sa˛ obie podsieci łacz
˛ ace
˛ ten router z dwoma innymi oraz podsie ć o nume-
rze 192.168.3.0/24. Wszystkie sieci sa˛ sieciami klasy C, co ułatwiło zaprojektowanie całości.
Jak widać z rysunku, pakiet wysłany z komputera K-11 do komputera IŁ-61 musi przejść przez
wszystkie routery. Aby to było możliwe, routery musza˛ mieć skonfigurowane tablice routingu.
Jeśli użyjemy protokółu RIP, to cała konfiguracja sprowadzi si˛e do konfiguracji interfejsów i
uruchomienia RIP-a na kolejnych routerach. Zakładajac, ˛ że protokół jest uruchomiony, pomi˛e-
dzy routerami nastapi˛ wymiana tablic routingu. Może to przebiegać na przykład w nast˛epujacych
˛
cyklach:
1. Na wszystkich routerach do tablic routingu zostana˛ wpisane informacje o bezpośrednio
przyłaczonych
˛ podsieciach. Na routerze Warszawa b˛eda˛ to informacje o sieciach 192.168.2.0,
192.168.3.0, 192.168.5.0, na routerze Lublin informacje o sieciach 192.168.5.0 i 192.168.6.0,
a na routerze Kielce informacje o sieciach 192.168.1.0 i 192.168.2.0. Metryka dla tych
3
Zapis maski /24 odpowiada masce 255.255.2555.0
Lp. Sieć Nast˛epny Metryka

1 192.168.1.0 192.168.2.1 1
2 192.168.2.0 bezpośrednie połaczenie
˛ 0
˛ 0
˛ 0
5 192.168.6.0 192.168.5.1 1
Tabela 6.1: Tablica routingu routera Warszawa.

1 192.168.1.0 192.168.5.2 2
2 192.168.2.0 192.168.5.2 1
3 192.168.3.0 192.168.5.2 1
˛ 0
˛ 0
Tabela 6.2: Tablica routingu routera Lublin.
wpisów wynosić b˛edzie 0.

2. Router, któremu zegar jako pierwszy odmierzył 30 sekund wysyła swoja˛ tablic˛e routin-
gu do sasiadów.
˛ Może to być np. router Warszawa. Routery Lublin i Kielce odbieraja˛ t˛e
informacj˛e i dopisuja˛ ja˛ do swoich tablic routingu. W tym momencie router Lublin wie,
któr˛edy wysłać pakiety do podsieci 192.168.2.0 i 192.168.3.0 (tablica 6.2, wiersze 2 i 3),
ale jeszcze nie ma informacji o podsieci 192.168.1.0. Tej informacji nie ma też jeszcze
router Warszawa, gdyż nie otrzymał jej od routera Kielce.
3. Nast˛epnym routerem, który odmierzył swoje 30 s jest router Kielce. Wysyła wi˛ec on za-
wartość swojej tablicy routingu. Wysyła także informacje o sieciach, o których informacje
otrzymał od routera Warszawa4 . Router Warszawa aktualizuje swoja˛ tablic˛e routingu do-
dajac
˛ jeden wopis (wiersz 1, tablica 6.1).
4. Ostatni z routerów Lublin także odmierzył swoje 30 s i wysyła swoja˛ tablic˛e routingu
do routera Warszawa, który aktualizuje swoja˛ tablic˛e routingu o wpis dotyczacy ˛ podsieci
192.168.6.0 (tablica 6.1 powi˛eksza si˛e o wiersz 5).
5. Gdy routery Kielce i Lublin wyśla˛ informacje o swoich tablicach routingu, to router War-
szawa b˛edzie miał pełna˛ informacj˛e o wszystkich podsieciach. Tej informacji nie b˛eda˛
miały jeszcze routery Kielce i Lublin. Musza˛ one poczekać aż otrzymaja˛ t˛e informacj˛e od
routera Warszawa. Wysyła on swoja˛ tablice routingu do obu routerów w kolejnym cyklu.
6. Routery Kielce i Lublin po otrzymaniu tablicy routingu od routea Warszawa maja˛ już pełna˛
informacje o sieci.
7. Od tej pory informacje przesyłane przez RIP służa˛ już tylko potwierdzaniu ważności ist-
niejacych
˛ wpisów. Oczywiście kolejność rozsyłania informacji mogła by być inna ale osta-
teczny rezultat zawsze b˛edzie ten sam.
4
Zakładamy, że nie jest wyłaczona
˛ funkcja rozszczepionego horyzontu (ang. split-horizon)

˛ 0
˛ 0
3 192.168.3.0 192.168.2.2 1
4 192.168.5.0 192.168.2.2 1
5 192.168.6.0 192.168.2.2 2
Tabela 6.3: Tablica routingu routera Kielce.
6.5.6. Metryki RIP

Po uruchomieniu protokołu, routery umieszczaja˛ w swoich tablicach routingu informacje o sie-
ciach bezpośrednio do nich przyłaczonych.
˛ Sieciom tym nadaja˛ metryk˛e równa˛ 0. Gdy router
rozgłasza za pomoca˛ protokołu RIP informacje o swojej tablicy routingu, to zwi˛eksza o 1 metry-
ki w wysyłanych przez siebie tablicach routingu. Przykładowo router Kielce wysyła do routera
Warszawa informacje o sieci 192.168.1.0 z metryka˛ równa˛ 1. Router Warszawa dopisze t˛e in-
formacj˛e do swojej tablicy routingu. Router Warszawa wyśle informacje o sieci 192.168.1.0 do
routera Lublin nadajac
˛ tej informacji metryk˛e 2. Gdy tablice routingu zostana˛ już ustalone, to ro-
uter Lublin powinien posiadać w swojej tablicy routingu informacje o trasie do sieci 192.168.1.0
z metryka˛ równa˛ 2.
6.5.7. Problemy RIP

W sieciach komputerowych moga˛ zdarzać si˛e awarie, routery moga˛ być okresowo wyłaczane
˛ lub
moga˛ być dołaczane
˛ do obecnie istniejacych
˛ nowe routery lub podsieca. Powoduje to zmiany to-
pologii sieci, za którymi protokół routingu powinien nadażać.
˛ Poniżej przedstawionych zostało
kilka problemów, jakie moga˛ wystapić
˛ w sieciach z routingiem dynamicznym opartym na proto-
kole RIP.
Rozszczepiony horyzont
Jednym z problemów jest fakt, że router RIP wysyła informacje o swojej tablicy routingu do
wszystkich swoich sasiadów,
˛ nie biorac
˛ pod uwag˛e źródła informacji. Może to powodowa ć sze-
reg problemów. Na przykład jeśli ulegnie awarii sieć 192.168.1.0 (patrz rysunek 6.3), która jest
przyłaczona
˛ do routera Kielce, to router ten usunie informacje o tej sieci ze swojej tablicy ro-
utingu. Wyśle też informacj˛e do routera Warszawa, która b˛edzie zawierać informacj˛e, że trasa
do 192.168.1.0 ma obecnie metryk˛e równa˛ 16, czyli jest to trasa nieważna. Router Warszawa
zaznaczy t˛e tras˛e jako nieważna˛ w swojej tablicy routingu, ale nim t˛e informacj˛e wyśle do ro-
utera Lublin, może otrzymać informacje o aktualizacji od tego routera. Router Lublin w stanie
ustalonym ma w swojej tablicy tras˛e do sieci 192.168.1.0 z metryka˛ równa˛ 2 i w ramach aktuali-
zacji wyśle t˛e informacj˛e do routera Warszawa z metryka˛ równa˛ 3. Router Warszawa dopisze t˛e
informacj˛e do swojej tablicy routingu a w ramach rozsyłania swoich aktualizacji wyśl˛e t˛e infor-
macje do obu sasiednich
˛ routerówi z metryka˛ równa˛ 4. Router Lublin zignoruje informacj˛e o tej
sieci za to router Kielce ja˛ zaakceptuje. W tym momencie mamy sytuacj˛e, w której wszystkie
W-31 W-32
31 192.168.3.0/24 32
WARSZAWA
4 19
/2 2 2 2.
0 16
. 2. 8.
8 5.
16 0/
2. 24
19
1 1
KIELCE LUBLIN
1 1
11 192.168.1.0/24 192.168.6.0/24 11
K-11 I£-61
Rysunek 6.3: RIP – ilustracja rozszczepionego horyzontu.
routery maja˛ w swoich tablicach różne informacje o sieci 192.168.1.0, która nie działa. Pakiety
wysyłane z komputerów b˛eda˛ krażyć
˛ w kółko pomi˛edzy routerami. Np. jeśli pakiet do odłaczo-
˛
nej sieci wyśle komputer IŁ-61, to router Lublin wyśle go do routera Warszawa a ten odeśle go
z powrotem do routera Lublin, gdyż na ten router wskazuje trasa w tablicy routingu. Ten router
odeśle pakiet z powrotem do routera Warszawa a ten odeśle do routera Lublin. Ta zabawa trwać
by mogła bez końca, gdyby nie mechanizmy zabezpieczajace ˛ w protokole IP.
Aby nie dopuścić do powstania takiej sytuacji wystarczyłoby, aby routery nie wysyłały in-
formacji o trasach do routerów, od których te informacje otrzymały. Technika ta nosi nazw˛e
Rozszczepionego horyzontu (ang. split horizon). W naszym przykładzie, jeśli ta technika została
by zastosowana, to router Lublin nie wysłałby informacji o sieci 192.168.1.0 do routera Warsza-
wa, gdyż właśnie od niego ja˛ dostał. Metoda ta rozcina p˛etle pomi˛edzy sasiaduj
˛ acymi
˛ routerami
a niejako przy okazji zmniejsza ilość wysyłanych informacji. Niestety jest nieskuteczna w sieci
zawierajacej
˛ p˛etle.
Nieco innym podejściem jest technika zwana Poison Reverse. W metodzie tej, trasy otrzyma-
ne poprzez dany interfejs sa˛ odsyłane do routera, który je nadesłał z metryka˛ ustawiona˛ na 16.
Routery, do których dotrze taka informacja o trasach dokonaja˛ aktualizacji swoich tablic routin-
gu. Jeśli w tablicach maja˛ lepsze informacje o danej trasie (niższa metryka i trasa wiodaca
˛ przez
inny router) to informacja o trasie z metryka˛ 16 zostanie zignorowana. Jeśli zaś trasa wiedzie
przez router, który przysłał informacje z metryka˛ 16, to t˛e tras˛e musza˛ usunać
˛ ze swojej tablicy
i informacje o tym rozesłać dalej. Technika ta przyspiesza usuwanie nieaktualnych tras z tablic
routingu.
W-31 W-32
31 192.168.3.0/24 32
WARSZAWA
19
/ 24 2 2 2.
.0 16
2 8.
8. 5.
16 100 Mb/s 0/
2. 100 Mb/s 24
19
1 1
KIELCE 32 kb/s LUBLIN
1 1
11 192.168.1.0/24 192.168.6.0/24 11
K-11 I£-61
Rysunek 6.4: RIP – przykład sztucznej metryki.
P˛etla i liczenie do nieskończoności
W powyższym przykładzie może dojść do jeszcze jednej sytuacji, gdy wyłaczona ˛ jest opcja split
horizon, to routery b˛eda˛ wymieniać informacje o routingu bez końca. Po pewnym czasie wyga-
śnie czas ważności trasy do 192.168.1.0 na routerze Lublin, ale nie wygaśnie jednocześnie na
routerach Warszawa i Kielce. Otrzyma wi˛ec on aktualizacj˛e od routera Warszawa z metryka˛ 4.
Dopisze ja˛ do swojej tablicy routingu i b˛edzie t˛e tras˛e rozsyłał do swoich sasiadów
˛ z metryka˛
5. Po pewnym czasie wygaśnie ważność trasy na routerze Warszawa, ale w nast˛epnym cyklu
rozgłaszania, któregoś z sasiadów
˛ router ten może otrzymać aktualizacj˛e od routera np. Lublin
z metryka˛ 5, która˛ to tras˛e b˛edzie ogłaszał sasiadom
˛ z metryka˛ 6. Taka sytuacja mogłaby trwa ć
bez końca, gdyby nie ograniczenie na maksymalna˛ wartość metryki. Gdy osiagnie ˛ ona wartość
16, to trasa staje si˛e nieważna. Dzi˛eki temu po jakimś czasie z tablic routingu wszystkich route-
rów powinny zniknać ˛ wszystkie niepoprawne wpisy. Czas, po jakim to zostanie osiagni˛
˛ ete, może
być jednak dość długi i zależy od ustawień poszczególnych zegarów w routerach.
Sztuczna metryka
Metryka w protokole RIP uwzgl˛ednia wyłacznie

˛ liczb˛e przeskoków poprzez routery do doce-
lowej sieci. Nie zawsze jest to korzystne. Rozważmy sytuacj˛e jak na rysunku 6.4. Połaczenia
˛
pomi˛edzy routerami Lublin – Warszawa oraz Kielce – Warszawa sa˛ zrealizowane w technologii
Fast Ethernet i maja˛ przepływność 100 Mb/s a połaczenie
˛ pomi˛edzy routerami Kielce – Lublin
192.168.3.0/24
WARSZAWA
19
/ 24 2 2 2.
.0 16
2 8.
6 8. 5.
1 0/
2. 24
19
1 1
KIELCE LUBLIN
1 1
192.168.1.0/25 192.168.1.128/25
Rysunek 6.5: RIP – przykład routowania klasowego.
ma przepływność 32 kb/s. Z punktu widzenia protokołu RIP jakość tych łaczy

˛ nie ma najmniej-
szego znaczenia. Po ustaleniu si˛e tablic routingu w routerze Lublin sieć 192.168.1.0 dost˛epna
b˛edzie poprzez adres 192.168.4.1 czyli bezpośrednie łacze˛ 32kb/s. Podobna sytuacja wystapi ˛
w przypadku sieci 192.168.6.0 i routera Kielce. Przy nie zapchanych łaczach
˛ Fast Ethernet prze-
pychanie ruchu poprzez łacze ˛ 32k/b nie wydaje si˛e sensowne. Zaradzić można temu na kilka
sposobów. Jednym z nich jest sztuczne nadanie wi˛ekszej metryki łaczu ˛ 32 kb/s. W naszym pro-
stym wypadku wystarczy wartość 2. Protokół RIP ustali wtedy, że najlepsza droga prowadzi
pomi˛edzy routerami Kielce i Lublin prowadzi poprzez szybkie łacze ˛ fastethernet i router War-
szawa. W wypadku awarii, któregoś z tych łacz ˛ protokół routingu RIP przekieruje ruch poprzez
łacze
˛ pomi˛edzy routerami Lublin–Kielce. Jest jednak pewna wada tej sytuacji. W protokole RIP
metryka trasy jest liczba˛ routerów, przez które musi przejść pakiet aby dotrzeć do docelowego
miejsca. Maksymalna wartość metryki wynosi 15, a wi˛ec po drodze pakiet może przejść po-
przez 15 routerów. Jeśli sztucznie zwi˛ekszymy metryk˛e na wybranym łaczu, ˛ to zmniejszamy
liczb˛e routerów, porzez które może przejść pakiet. W przypadku małych sieci składajacych
˛ si˛e
z kilku routerów może być to niezauważalne, jednak dla wi˛ekszej sieci może to doprowadzić do
nieosiagalności
˛ cz˛eści podsieci.
Routowanie klasowe
W powyższych przykładach posługiwano si˛e sieciami klasy C 192.168.xx.xx. Wszystkie pod-
sieci w przykładach miały ten sam rozmiar. Jeśli zamienimy podsieć 192.168.1.0/24 na podsieć
192.168.1.0/25 oraz podsieć 192.168.6.0 na podsieć 192.168.1.128/25 to uzyskamy sieć, która
może zachowywać si˛e niestabilnie. Wynika to z faktu nieprzenoszenia przez protokół RIP infor-
macji o masce podsieci, a my postanowiliśmy użyć maski 255.255.255.128.W przypadku takim
jak na rysunku 6.5 router Kielce wyśle do routera Warszawa informacje o sieci 192.168.1.0.
Router Warszawa dokona aktualizacji wpisu w swojej tablicy routingu i dopisze tam lini˛e
wskazujac˛ a,˛ że sieć 192.168.1.0 jest dost˛epna poprzez router Kielce. Ponieważ RIP jest protoko-
114 6.6. Protokół RIP wersja 2
0 8 16 31
command (1) version (1)
address family indentifier (2) route Tag (2)
IP address (4)
subnet mask (4)
next hop (4)

metric (4)
Rysunek 6.6: Format pakietu RIP 2.
łem routingu klasowego, a sieć 192.168.1.0 jest siecia˛ klasy C, to cały routing zostanie skiero-
wany do routera Kielce. Oznacza to, że fragment sieci 192.168.1.128/25 przyłaczony
˛ do routera
Lublin stanie si˛e niedost˛epny z podsieci 192.168.3.0. Aktualizacja, która przyjdzie do routera
Warszawa od routera Lublin może ta˛ sytuacje odwrócić, gdyż router ten przyśle informacje, że
ma tras˛e również do sieci klasy C 192.168.1.0. Wtedy niedost˛epna stanie si˛e cześć sieci przyła-
˛
czona do routera Kielce. Każdorazowe aktualizacje moga˛ zmieniać dost˛epność tych fragmentów
sieci.
6.5.8. Podsumowanie
Protokół RIP był pierwszym protokołem routingu, dla którego ustalono standardy. Jest prosty
w konfiguracji, ale ma szereg wad, które w obecnych warunkach bardzo ograniczaja˛ sens jego
użycia. Niemniej jest on w dalszym ciagu
˛ implementowany na routerach i można go uży ć bez
wi˛ekszych obaw w małych sieciach o nieskompliowanej topologii.
6.6. Protokół RIP wersja 2

Na poczatku
˛ lat 90-tych postanowiono opracować modyfikacj˛e protokołu RIP, która pozwoliłaby
na zniesienie cz˛eści jego ograniczeń. Nowa specyfikacja została opublikowana w dokumencie
RFC 1723. Najważniejsze zmiany w stosunku do wersji RIP to:
możliwość przenoszenia informacji o masce podsieci;
możliwość autoryzacji wysyłanych informacji routingowych;
wysyłanie uaktualnień za pomoca˛ multicastów.
Sposób wyznaczania trasy pozostał taki sam jak w wersji 1.
6.6.1. Format pakietu RIP 2

Znaczenie poszczególnych pól jest podobne jak w wersji RIP-1. Zasadnicza˛ zmiana˛ jest zasta-
˛
pienie pól wypełnionych zerami nowymi polami. Znaczenia poszczególnych pól w pakiecie sa˛
nast˛epujace:
˛
0 8 16 31
command (1) version (1)
0xFFFF authentication type (2)

authentication (16)
Rysunek 6.7: Format pakietu autoryzacyjnego RIP2.
command – pole komendy;

version – dla wersji RIP 2 w polu tym jest wstawiona wartość 2;
AFI – określa jaki protokół b˛edzie routowany, jeśli IP to wartość pola ustawiona jest na
2. Jeśli pole AFI ma ustawiona˛ wartość 0xFFFF to oznacza, że pakiet niesie informacje
o autoryzacji;
route tag – pole określajace
˛ czy trasa jest trasa˛ wewn˛etrzna˛ (otrzymana˛ od protokołu RIP),
czy też trasa˛ zewn˛etrzna˛ (otrzymana˛ od innych protokołów);
IP address – adres IP (pod warunkiem AFI=2);
subnet mask – maska podsieci;
next hop – adres nast˛epnego skoku;
metric – metryka.
6.6.2. Autoryzacja w protokole RIP 2

W wypadku, gdy w polu AFI umieszczona jest wartość 0xFFFF, to pakiet przenosi informacje
o autoryzacji. Format pakietu autorazycyjnego ma postać jak na rysunku 6.7.
Nagłówek autoryzacji zast˛epuje pierwszy wpis informacji o routingu. Oznacza to, że w pa-
kiecie zamiast 25 informacji o trasach może być ich 24. Dokument RFC 1723 określa, że w polu
Authentication może znajdować si˛e hasło w formacie plain text. Nie jest to, jak widać, silne
zabezpieczenie. Routery, które maja˛ w konfiguracji protokołu RIP 2 właczon
˛ a˛ autoryzacj˛e, po-
winny odrzucać pakiety, które nie zawieraja˛ nagłówka autoryzacyjnego.
6.6.3. Rozsyłanie uaktualnień

RIP w wersji 2 rozsyła uaktualnienia za pomoca˛ multicastów. Używa do tego adresu 224.0.0.9.
Jednocześnie RIP 2 może współpracować z RIP 1. Zakres współpracy jest zależny od imple-
mentacji programowej protokołu na routerze. W zależności od implementacji protokołu RIP 2
na routerach możliwe jest wymuszenie na poszczególnych interfejsach jednej z sytuacji:
RIP 1 – poprzez interfejs wysyłane sa˛ komunikaty w formacie RIP 1 i tylko w tym forma-
cie;
RIP 1 compatibility – poprzez interfejs wysyłane sa˛ komunikaty w formacie RIP 2, ale za
pomoca˛ broadcastów;
RIP 2 – poprzez interfejs wysyłane sa˛ komunikaty w formacie RIP 2, ale za pomoca˛ mul-
ticastów;
none – nie sa˛ wysyłane żadne komunikaty RIP.
116 6.7. Protokół OSPF
W wypadku, gdy komunikaty RIP 2 sa˛ rozsyłane za pomoca˛ broadcastów, może dojść do sytu-
acji, że zostana˛ odebrane przez router, na którym pracuje wersja protokołu RIP 1. Nie stanowi
to wi˛ekszego problemu, gdyż prawidłowo funkcjonujacy ˛ router z protokołem RIP 1 powinien
zignorować pakiet, w którym, w polu wersji, znajduje si˛e wartość inna niż 1. Oznacza to, że taki
router b˛edzie głuchy na informacje od protokołu RIP 2, co może rodzić pewne problemy w dzia-
łaniu sieci. Wyjścia z tej sytuacji sa˛ co najmniej dwa. Można wymusić na routerze z protokołem
RIP 2 wysyłanie komunikatów w wersji RIP-1 lub dokonać uaktualnienia protokółu z RIP 1 do
RIP 2.
6.6.4. Wyznaczanie trasy i problemy

RIP-2 wyznacza tras˛e korzystajac˛ z tego samego algorytmu co RIP 1. Ma wi˛ec dokładnie te
same problemy z wyznaczaniem jakości trasy, co swój poprzednik. Możliwość przesłania ma-
ski podsieci znosi ograniczenia zwiazane
˛ z routingiem klasowym. Możliwość wykorzystania
multicastów do rozsyłania informacji o routingu pozwala w sieciach LAN ograniczyć liczb˛e
adresatów, do których sa˛ wysyłane uaktualnienia. Możliwość autoryzacji pozwala zaś na lepsze
zabezpieczenie sieci. Niemniej jednak zastosowanie protokołu RIP ma sens wyłacznie
˛ w sieciach
o nieskomplikowanej topologii i w miar˛e jednakowych łaczach.
˛
6.7. Protokół OSPF

Sieci komputerowe stale si˛e rozwijaja.˛ Obecnie zrezygnowano w nich z routingu opartego na
klasach adresowych A,B,C. Zacz˛eto wykorzystywać łacza ˛ o różnych przepustowościach oraz
pojawiły si˛e routery o silnych procesorach. Aby w pełni wykorzystać możliwości łaczy˛ oraz
optymalnie budować i wykorzystywać sieci, zaszła konieczność opracowania nowego protokołu.
Na przełomie lat osiemdziesiatych
˛ i dziewi˛ećdziesiatych
˛ opracowano protokół OSPF (ang. Open
Shortest Path First). Powstał on jako standard internetowy niezależny od producenta. Miało to
niebagatelne znaczenie dla klienta, gdyż nie musiał kupować sprz˛etu tylko od jednego dostawcy
aby wykorzystywać w pełni możliwości sieci. Specyfikacja OSPF jest cały czas modyfikowa-
na i rozwijana. Można przyjać,
˛ że najszerzej jest wykorzystywana specyfikacja zawarta w RFC
2178. W nowych routerach, które maja˛ wsparcie dla protokołu IPv6 implementowana jest spe-
cyfikacja rozszerzajaca
˛ możliwości OSPF na sieć IPv6.
6.7.1. Działanie OSPF

OSPF jest protokołem stanu łacza.
˛ Wyznacza on inaczej tras˛e niż czyni to protokół RIP, chociaż
podobnie jak on przeznaczony jest do pracy w obr˛ebie jednej domeny administracyjnej. OSPF
pozwala na podzielenie domeny na obszary. Pomimo tego, iż nie ma ograniczenia co do licz-
by routerów w poszczególnych obszarach, to wedle zalece ń praktycznych nie powinno ich być
wi˛ecej niż 50-70. Każdy router z uruchomionym protokołem OSPF utrzymuje w swojej pami˛eci
baz˛e danych z informacjami dotyczacymi˛ topologii połacze
˛ ń w obr˛ebie swojego obszaru. W ba-
zach tych zawarte sa˛ informacje o interfejsach routerów znajdujacych
˛ si˛e w danym obszarze. Na
podstawie tych informacji wyznaczana jest najkrótsza ścieżka do sieci, która wchodzi w skład
domeny administracyjnej. Najkrótsza ścieżka obliczana jest za pomoca˛ algorytmu Dijkstry. Przy
obliczaniu najlepszej drogi pod uwag˛e brane sa˛ takie czynniki, jak jakość łacza
˛ oraz stan interfej-
su. Wyliczone trasy w postaci adresu IP nast˛epnego skoku oraz interfejsu, przez który pakiet ma
być przesłany, sa˛ wprowadzane do tablicy routingu. Ponieważ wszystkie routery wyliczaja˛ trasy
na podstawie tych samych danych, to wszystkie ścieżki wiodace ˛ do danej podsieci powinny być
zgodne.
6.7.2. Komunikacja pomi˛edzy routerami w OSPF

Routery rozpoczynaja˛ komunikacj˛e pomi˛edzy soba˛ wymieniajac ˛ pakiety Hello. Ustanawiaja˛ za
pomoca˛ tych pakietów tzw. relacje sasiedzkie.˛ Cz˛estotliwość wysyłania pakietów Hello zależy
od rodzaju łacza. ˛ Jeśli łacze
˛ jest typu rozgłoszeniowego (np. ethernet), to pakiety wysyłane sa˛
co 10 s, a jeśli łacze
˛ nie ma tego charakteru (np. łacza
˛ typu punkt-punkt) to pakiety wysyłane
sa˛ co 30 sekund. Pakiety sa˛ wysyłane przez każdy aktywny interfejs. W pakiecie router wysyła
list˛e routerów, od których już dostał pakiet Hello w danym segmencie. Dzi˛eki temu możliwe
jest szybkie ustanowienie relacji dwustronnych pomi˛edzy routerami, a także zmniejszenie liczby
pakietów wymienianych pomi˛edzy routerami. Po ustanowieniu dwustronnej komunikacji route-
ry zaczynaja˛ przysyłać pomi˛edzy soba˛ informacje o topologii sieci za pomoca˛ pakietów LSA
(ang. Link State Advertisement). Ponieważ routerów w danym segmencie sieci może by ć dużo,
to potrzebny jest mechanizm ograniczajacy ˛ liczb˛e transmisji. Gdyby go nie było, to aby pozna ć
cała˛ topologi˛e routery musiałyby przesłać N x N komunikatów, gdzie N oznacza liczb˛e route-
rów w segmencie. Mechanizm ograniczajacy ˛ polega na wybraniu spośród routerów pracujacych ˛
w danym segmencie tzw. routera desygnowanego – DR (ang. Designated Router) oraz tzw. zapa-
sowego routera desygnowanego – BDR (ang. Backup Designated Router). Każdy router pracuja- ˛
cy w danym segmencie ustanawia łaczność ˛ z routerem DR i do niego wysyła informacje o stanie
swoich łaczy.
˛ Router DR gromadzi te informacje i rozsyła je do wszystkich routerów w seg-
mencie. Dzi˛eki temu liczba komunikatów potrzebnych do przesłania całej informacji o łaczach ˛
w segmencie spada z NxN do 2xN. Wybór routera DR i BDR odbywa si˛e podczas przesłania
pierwszych komunikatów Hello. Wybór routera DR zależy od czasu inicjalizacji routera oraz od
jego priorytetu. W wypadku gdy dwa routery zostana˛ zainicjalizowane jednocześnie, to route-
rem DR stanie si˛e router o wyższym priorytecie. Priorytet w przypadku wi˛ekszości routerów jest
wartościa˛ konfigurowalna˛ i dla każdego routera oraz interfejsu może być ustawiony oddzielnie.
Jeśli trafia˛ si˛e dwa routery o tym samym priorytecie, to na router DR wybrany zostanie ten, który
ma wyższy identyfikator. Identyfikatorem routerów jest najcz˛e ściej najwyższy numer IP na in-
terfejsie lub adres IP ustawiony na interfejsie loopback0. Raz wybrany router DR pozostaje nim
do chwili przerwy w jego pracy. Jeśli z jakiegoś powodu router DR zamilknie, to jego funkcje
przejmie router BDR, który stanie si˛e routerem DR, a spośród pozostałych routerów zostanie
wybrany nast˛epny router BDR. Jeśli zamilknie router BDR, to także zostanie wybrany jego na-
st˛epca. Istotnym jest to, że przy wyborze routera nie jest brana pod uwag˛e wolna moc i zdolności
obliczeniowe routerów. Może si˛e zdarzyć, że routerem DR zostanie jakiś starszy router o sła-
bym procesorze, co może powodować problemy w sieci. Aby uniknać ˛ tego typu sytuacji, trzeba
r˛ecznie obniżać priorytety routerom, które moga˛ nie sprostać funkcji routera DR. Każdy router
z protokołem OSPF ma pełna˛ kopi˛e danych na temat obszaru, w którym pracuje. Po procesie ini-
cjalizacji i wymianie danych, w ramach stałej aktualizacji rozsyłane sa˛ wyłacznie ˛ zmiany w bazie
danych. Oznacza to znaczne zmniejszenie rozmiaru transmitowanych danych. Jeśli na którymś
z routerów zmieni si˛e stan interfejsu, to ta informacja zostanie rozesłana do wszystkich routerów
w sieci, a one dokonaja˛ ponownego przeliczenia swoich tras. Trzeba o tym pami˛eta ć szczególnie,
gdy w sieci używane sa˛ łacza,
˛ na których cz˛esto dochodzi do zmiany stanu. Przykładem takim sa˛
łacza
˛ dial-up. Używanie ich bezpośrednio w sieci OSPF może spowodować cz˛este przeliczanie
tras, a co za tym idzie przeciażenie
˛ routerów i obniżenie jakości pracy sieci.
6.7.3. Metryka OSPF

Podobnie jak w protokole RIP w protokole OSPF wyst˛epuje metryka. Znaczenie ma takie sa-
mo jest jednak inaczej liczona. Metryka OSPF może być interpretowana jako swojego rodzaju
koszt przesłania pakietu poprzez dane łacze. ˛ Dla każdego łacza
˛ metryka jest wyznaczana jako
8
10 /(przepustowość łacza). ˛ Dla interfejsu Ethernet metryka wynosić b˛edzie 10, a dla ła- ˛
cza Fast Ethernet 1. Obecnie stosowane sa˛ jednak łacza ˛ ATM o przepływności 155 Mb/s i 622
Mb/s oraz łacza
˛ Gigabit Ethernet. Gdyby przyjać ˛ standardowy sposób liczenia wartości metry-
ki dla tych łacz,
˛ to metryka miałaby wartość ułamkowa, ˛ co nie jest dopuszczalne. Wyjściem
z tej sytuacji jest r˛eczne przedefiniowanie metryk dla szybszych łaczy. ˛ Aby to miało sens, na-
leży wszystkim łaczom
˛ tego samego typu nadać konsekwentnie te same metryki. Robienie tego
r˛ecznie w przypadku kilkudziesi˛eciu routerów może być czasochłonne. Na szcz˛eście niektóre ro-
utery, maja˛ możliwość przedefiniowania wartości bazowej dla wyliczania metryki. Można wtedy
zamiast 108 zdefiniować inna˛ wartość, ważne jest, by na wszystkich routerach w danym obszarze
była ona jednakowa. Należy także zadbać, aby w metrykach uwzgl˛edniana była faktyczna prze-
pustowość łacz.
˛ W Polsce popularne sa˛ łacza ˛ Frame Relay. Przepustowość tych łacz ˛ jest określa-
na przez dwa parametry. Jednym z nich jest teoretyczna przepustowość wynoszaca ˛ na przykład
2Mb/s a drugim parametr CIR (ang. Committed Information Rate), który określa gwarantowana˛
przepustowość łacza.
˛ Lepszym rozwiazaniem
˛ jest uwzgl˛ednianie w metryce OSPF przepustowo-

ści CIR, niż teoretycznej przepustowości łacza.˛ W przypadku łacza
˛ 2Mb/s koszt łacza
˛ wyniesie
8
8
48 (10 2 2 0
(10 512 1024
1

48), a jeśli jako koszt podamy CIR 512kb/s, to koszt b˛edzie wynosić 191
191), co jak widać jest bardzo duża˛ różnica.˛ Metryka danej trasy jest su-
ma˛ metryk wszystkich łaczy ˛ tworzacych
˛ ścieżk˛e pomi˛edzy punktem źródłowym a docelowym.
Pod uwag˛e brane sa˛ wyłacznie
˛ metryki zwiazane˛ z wysłaniem pakietu poprzez dane łacze.
˛ Jeśli
dwa routery podłaczone
˛ do tego samego segmentu sieci maja˛ inne wartości metryki na łaczach ˛
użytych do przyłaczenia,
˛ to zupełnie inaczej wylicza˛ sobie metryk˛e trasy. W przypadku bardziej
skomplikowanej struktury sieci pakiety z jednego miejsca do drugiego w˛edrowa ć b˛eda˛ jedna˛
trasa˛ a wracać zupełnie inna.˛
6.7.4. Wyznaczanie trasy

Każdy z routerów buduje sobie model sieci w postaci grafu skierowanego. Poszczególne wierz-
chołki grafu odpowiadaja˛ badź
˛ to bramom (routerom), badź ˛ sieciom. Poszczególne wierzchołki
sa˛ łaczone
˛ para˛ skierowanych kraw˛edzi. Każda z kraw˛edzi ma nadana˛ wag˛e, przy czym jeśli
kraw˛edź jest skierowana od wierzchołka routera do sieci lub od routera do routera, to waga jest
równa metryce na interfejsie routera, z którego kraw˛edź wychodzi. Jeśli zaś kraw˛edź jest skiero-
wana od wierzchołka oznaczajacego˛ sieć do routera, to wartość wagi wynosi 0. Ma to zapobiec
dwukrotnemu zliczeniu tej samej wagi. Na rysunku 6.8 przedstawiona jest przykładowa sieć. Dla
uproszczenia wszystkie routery pracuja˛ w jednym obszarze. Po przekazaniu wszystkich danych
routery zbuduja˛ graf taki jak na rysunku 6.9.
192.168.3.0/24
1 Ethernet
WARSZAWA
4 19
/2 2 2 2.
.0 16
2 Fa 8
.
6 8 e rn e
t stE .5.0
.1 the /
1 92 Eth rne 24
1 t 1
192.168.4.0/24
KIELCE 32 kb/s LUBLIN
1 FastEthernet FastEthernet 1
192.168.1.0/24 3 192.168.6.0/24 4
GNIEZNO OLSZTYN
2
1 FastEthernet Ethernet 1
192.168.7.0/24 192.168.8.0/24
Rysunek 6.8: OSPF – przykładowa sieć.
Wagi na poszczególnych kraw˛edziach grafu odźwierciedlaja˛ wartości metryki dla poszcze-

32
gólnych interfejsów. Dla interfejsu o przepustowości 32kb/s metryka wynosi 3052(108 1024
3052). Na podstawie takiego grafu routery wyliczaja˛ najlepsze trasy. Jeśli np. spojrzymy
na tras˛e z sieci 192.168.1.0/24 do sieci 192.168.7.0/24 to widać, że możliwych jest kilka dróg po-
przez, które pakiet może tam dotrzeć. Najkorzystniejsza˛ trasa˛ b˛edzie trasa wiodac
˛ a˛ poprze route-
ry Kielce, Warszawa, Lublin, Gniezno, gdyż jej metryka wynosić b˛edzie 10+1+1+1=13. Gdyby
brać pod uwag˛e tras˛e Kielce, Lublin, Gniezno, to jej metryka wyniesie 3052+1+1=3056, a wi˛ec
b˛edzie znacznie wi˛eksza. Trasa powrotna zależeć b˛edzie od ustawień domyślnego routingu na
komputerach w sieci 192.168.7.0. Jeśli domyślny routing b˛edzie b˛edzie wskazywał na Gniezno,
to trasa b˛edzie taka sama jak z sieci 192.168.1.0. Jeśli zaś wskazywać b˛edzie na router Olsz-
tyn, to pakiety z komputera w sieci 192.168.7.0/24 b˛eda˛ wracały do sieci 192.168.1.0/24 przez
ten router. Jest to typowa sytuacja asymetrii tras, po których w˛edruja˛ pakiety. Może sprawia ć to
czasami wiele problemów.
6.7.5. Obszary OSPF

Sieć zbudowana w oparciu o protokół OSPF może zostać podzielona na obszary. Niesie to ze
soba˛ sporo korzyści. Pozwala to przede wszystkim na uproszczenie zarzadzania
˛ siecia,˛ gdyż
podział na obszary pozwala na przekazanie zarzadzania
˛ fragmentem sieci wybranej jednostce
organizacyjnej, korzystajacej
˛ z tej sieci. Obszary oznaczane sa˛ za pomoca˛ cyfr przy czym za-
wsze powinien istnieć obszar oznaczony zerem, który zwany jest obszarem zerowym lub szkie-
letowym. Komunikacja pomi˛edzy dwoma obszarami w sieci OSPF musi si˛e odbywać poprzez
obszar zerowy. Routery, które łacz
˛ a˛ obszar zerowy z innymi obszarami nazywane sa˛ routerami
192.168.3.0/24
0 10
WARSZAWA
10 0
0
1
192.168.2.0/24 192.168.5.0/24
0 10 0 1
KIELCE LUBLIN
3052 0
192.168.4.0/24
0 3052
1 0 1 0
192.168.1.0/24 192.168.6.0/24
1
0
10
0
GNIEZNO OLSZTYN
1
1 0 10 0
0
192.168.7.0/24 192.168.8.0/24
Rysunek 6.9: OSPF – sieć w postaci grafu.

AREA 1 AREA 2
192.168.3.0/24 172.16.1.0/24
3 3
WARSZAWA SZCZECIN
19 1
30 2 2 2. /3
0
2 2 72
. 0/ 16 .4
.1
6.
.2 8. . 3 3.
68 2. 16 8/
2 .1 8/ 2 . 30
19 1
30 17
1 1 1
192.168.2.4/30 172.16.3.0/30
KIELCE LUBLIN GNIEZNO OPOLE
1 1 1 1
192.168.1.0/24 192.188.9.0/24 172.16.2.0/24
AREA 0
Rysunek 6.10: OSPF – agregacja tablic routingu.
brzegowymi lub routerami ABR (ang. Area Border Router). Jeśli dwa obszary łaczy ˛ router oraz
żaden z obszarów nie jest obszarem zerowym, to taki router nie pełni funkcji routera ABR. Nie
transmituje też on pakietów pomi˛edzy obszarami. Wynika to z faktu, że wszystkie pakiety, skie-
rowane do miejsca leżacego
˛ wewnatrz
˛ obszaru, nie powinny tego obszaru opuszcza ć, natomiast
pakiety, które maja˛ wyjść poza obszar, moga˛ wyjść wyłacznie
˛ poprzez router ABR, a ten musi
być dołaczony
˛ do obszaru zerowego.
Zadaniem routera brzegowego jest wi˛ec transmisja danych pomi˛edzy obszarami. Aby to było
możliwe, router brzegowy musi rozesłać trasy biegnace ˛ w jego obszarze do obszaru zerowego.
Aby zmniejszać rozmiar przesyłanych tras, routery brzegowe moga˛ agregować trasy. Aby sieć
mogła działać, to routery brzegowe musza˛ także rozsyłać trasy otrzymane w obszarze zerowym
do obszarów, które łacz
˛ a.˛ Routery ABR wyróżnia także fakt posiadania przez nie kompletnych
danych na temat obszarów, które łacz ˛ a.˛ W oparciu o te dane wyznaczaja˛ one trasy. Jeśli router
ABR łaczy
˛ wi˛ecej obszarów, to b˛edzie posiadał wi˛ecej danych zwiazanych
˛ z obszarami. Oznacza
to konieczność stosowania jako routerów ABR routerów, które maja˛ dużo pami˛eci operacyjnej
oraz silny procesor.
6.7.6. Agregacja tablic routingu

Routery brzegowe moga˛ dokonywać agregacji tablic routingu. Ma to duże znaczenie, gdy w ja-
kimś obszarze znajduje si˛e sporo podsieci. Dla każdej podsieci potrzebny jest wtedy oddzielny
wpis w tablicy routingu. Jeśli odpowiednio zaplanujemy sieć, to liczb˛e wpisów w poszczegól-
nych routerach można znaczaco ˛ ograniczyć. Ilustruje to przykład w rysunku 6.10. W obsza-
rze 1 znajduja˛ si˛e trzy routery i pi˛eć podsieci 192.168.1.0/24, 192.168.2.0/30, 192.168.2.4/30,
192.168.2.8/30, 192.168.3.0/24. Informacja o tych sieciach jest dystrybuowana do obszaru 2 po-
przez routery Lublin i Gniezno. Jeśli nie b˛edzie realizowana agregacja to w obszarze 2 informacja
122 6.8. Protokół BGP
o tych podsieciach pojawi si˛e jako pi˛eć oddzielnych wpisów w tablicy routingu. Bez żadnej stra-
ty można informacje o sieciach 192.168.2.0/30 i 192.168.2.4/30 wysyła ć do obszaru zero jako
informacje o sieci 192.168.2.0/29. Z punktu widzenia routerów, leżacych˛ poza obszarem 1, po-
dział tej podsieci na dwa mniejsze kawałki nie jest istotny. Jeśli uczyni si˛e dodatkowe założenie,
w którym zagwarantuje si˛e, że numery z sieci 192.168.2.0/24 b˛eda˛ wyłacznie ˛ nadawane urza-˛
dzeniom pracujacym˛ w obszarze 1, to dla routerów spoza tego obszaru istotna staje si˛e wyłacznie
˛
informacja o routerze, który zna drog˛e do całej tej podsieci. Agregacji można b˛edzie dokona ć
także wtedy, gdy sieć 192.168.0.0/24 b˛edzie również przypisana jako podsieć dla obszaru 1.
Wtedy w obszarze 1 użyte, badź
˛ zagwarantowane, b˛eda˛ cztery kolejne podsieci 192.168.0.0/24,
192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24. Ponieważ sa˛ to cztery kolejne podsieci, to da-
ja˛ si˛e one zaagregować do jednej podsieci 192.168.0.0/22. Dzi˛eki temu w routerach w innych
obszarach sieci OSPF b˛edzie wyłacznie
˛ jedna trasa zamiast poczatkowych
˛ 5. W przypadku bar-
dzo dużych sieci można w znacznym stopniu zmniejszyć rozmiary tablic routingu, dzi˛eki cze-
mu uzyskuje si˛e sprawniej działajac
˛ a˛ sieć. Dodatkowo, agregacja pozwala na cz˛eściowe ukrycie
struktury sieci w danym obszarze, co może podnieść bezpieczeństwo sieci.
6.7.7. Redystrybucja tras

Protokół OSPF buduje tablice routingu w oparciu o topologi˛e sieci. Może si˛e zdarzyć, że w sieci
sa˛ starsze routery, które nie obsłuża˛ protokołu OSPF oraz routery, które maja˛ ustawione wyłacz-
˛
nie trasy statyczne. Jest to ważna cz˛eść informacji o sieci, która powinna być uwzgl˛edniona. Do
przekazania tej informacji służy mechanizm redystrybucji. Redystrybuowane moga˛ by ć zarów-
no dane z protokołu OSPF do innych protokołów, jak i z innych protokołów do protokołu OSPF.
Każda z tras, która została uzyskana metoda˛ redystrybucji jest traktowana przez protokół OSPF
jako trasa zewn˛etrzna. Trasy zewn˛etrzne w protokole OSPF sa˛ jednego z dwóch typów: typu I
i typu II. Różnica pomi˛edzy typami tras sprowadza si˛e do sposobu wyznaczania metryki trasy.
W trasach typu I, metryka jest suma˛ metryk zewn˛etrznej oraz wewn˛etrznej, która jest uzyskania
dost˛epu do routera obliczana jako metryka trasy do granicznego systemu autonomicznego czyli
routera ASBR. Router ASBR (ang. Autonomous System Border Router) jest routerem łacz ˛ acym
˛
sieć OSPF z inna˛ siecia.˛ Metryka tras typu II jest zaś wyznaczana wyłacznie
˛ jako metryka uzy-
skania dost˛epu do routera ASBR. Protokół OSPF może także redystrybułować trasy domyślne,
dzi˛eki czemu możliwe jest rozgłoszenie w sieci routerów OSPF informacji, gdzie znajduja˛ si˛e
routery, które oferuja˛ np. połaczenia
˛ do Internetu.
6.8. Protokół BGP

Protokół BGP (Border Gateway Protocol) jest protokołem zewn˛etrznym służacym˛ do wymiany
informacji o routingu pomi˛edzy różnymi systemami autonomicznymi. Protokół jest standardem
internetowym i jego definicje znajduja˛ si˛e w nast˛epujacych
˛ dokumentach RFC:
RFC 1771 - Opis protokołu BGP4 (aktualna wersja protokołu BGP),
RFC 1772 - BGP Application,
RFC 1773 - BGP Experience,
RFC 1774 - BGP Protocol Analysis,
RFC 1655 - BGP MIB.
Protokół BGP jest obecnie podstawowym protokołem wymiany tablic routingu w Internecie.
W ramach protokołu BGP przekazywane sa˛ kompletne informacje o routingu z całego Internetu.
Wymaga wi˛ec on od routera sporych zasobów sprz˛etowych. W tej chwili zalecana wielkość
pami˛eci w routerze, który b˛edzie obsługiwał protokół BGP, wynosi 256 MB.
6.8.1. Systemy Autonomiczne

Z punktu widzenia protokołu BGP sieć Internet jest siecia˛ połaczonych
˛ ze soba˛ systemów au-
tonomicznych (ang. AS - Autonomous System). Na system składaja˛ si˛e routery, które sa˛ admi-
nistrowane przez dany podmiot. Na tych routerach wykorzystywany jest wewn˛etrzny protokół
routowania. Z punktu widzenia innych AS-ów dany AS może być traktowany jako monolit. Da-
ny AS posiada numery IP z tak zwanej puli PI (ang. PI – Provider Indepent). Pula charakteryzuje
si˛e tym, że te adresy przypisane sa˛ do danego AS i tylko do niego. Pozwala to AS, jako jedno-
stce, dowolnie kształtować swoje połaczenia
˛ z Internetem. Posiadanie własnego AS umożliwia
posiadanie wielu łacz ˛ do dowolnych dostawców Internetu i dowolne przełaczanie˛ si˛e pomi˛e-
dzy dostawcami, bez konieczności zmiany adresów IP. Własne systemy autonomiczne posiadaja˛
operatorzy internetowi oraz duże firmy, które maja˛ wiele przyłacze
˛ ń do Internetu. Każdy AS ma
unikalny numer, który jest liczba˛ z zakresu od 1 do 65535. W Internecie moga˛ by ć używane nu-
mery od 1 do 65411, a numery od 65412 do 65535 służa˛ do oznaczania sieci prywatnych. Numer
danemu systemowi autonomicznemu nadawany jest przez mi˛edzynarodowa˛ organizacje ICANN
(ang. Internet Corporation for Assigned Names and Numbers) lub jej regionalne przedstawiciel-
stwo. Organizacja ta zajmuje si˛e także rozdziałem adresów IP z klasy PI. Operatorzy internetowi
ze swojej puli adresów PI przydzielaja˛ swoim klientom adresy PA (PA ang. Provider Agregable).
Z punktu widzenia routingu BGP, klient z adresami PA jest cz˛eścia˛ sieci operatora, od którego
adresy otrzymał. Na operatorze spoczywa odpowiedzialność za poprawność funkcjonowania ro-
utingu. Dla klienta posiadajacego
˛ tego typu adresy zmiana operatora oznacza także zmian˛e tych
adresów.
6.8.2. Działanie protokołu BGP

Dwa routery z uruchomionym protokołem BGP ustanawiaja˛ pomi˛edzy soba˛ relacje sasiedzkie. ˛
Jeśli oba routery należa˛ do tego samego systemu autonomicznego, jest to relacja wewn˛etrzna (In-
ternal BGP), a jeśli dwa routery należa˛ do różnych systemów, jest to relacja zewn˛etrzna (External
BGP). Sasiednie
˛ routery wymieniaja˛ pomi˛edzy soba˛ informacje na temat tablic routingu za po-
moca˛ protokołu TCP na porcie 179. Po nawiazaniu ˛ sesji, routery wysyłaja˛ komunikaty OPEN,
za pomoca˛ których określaja˛ parametry sesji (np. wersje protokołu BGP). Po ustaleniu parame-
trów sesji za pomoca˛ komunikatów UPDATE wymieniane sa˛ listy hostów i sieci, które moga˛ by ć
osiagni˛
˛ ete poprzez dana˛ ścieżk˛e oraz parametry tych ścieżek. Jeśli połaczenie
˛ zostało nawiaza-
˛
ne po raz pierwszy, to dwa routery przesyłaja˛ pomi˛edzy soba˛ pełne tablice routingu, a potem
wysyłane sa˛ tylko zmiany. Gdy nie ma zmian to wysyłane sa˛ krótkie komunikaty (19-bajtowe)
KEEPALIVE. Dzi˛eki tym komunikatom dwa routery sygnalizuja˛ sobie, że pracuja˛ i że połacze- ˛
nie pomi˛edzy nimi funkcjonuje poprawnie. Ponieważ do komunikacji pomi˛edzy routerami BGP
wykorzystywany jest protokół TCP/IP, to dwa routery nie musza˛ być bezpośrednio połaczone, ˛
choć najcz˛eściej routery BGP maja˛ pomi˛edzy soba˛ bezpośrednio zestawione łacza˛ dedykowane.
124 6.8. Protokół BGP
AS 300 AS 100
AS 200 AS 150
AS 120
Rysunek 6.11: BGP – wyznaczanie trasy.
W przypadku braku bezpośredniego łacza

˛ pomi˛edzy dwoma routerami BGP zestawia si˛e sesje
typu multihop-ebgp.
6.8.3. Wyznaczanie trasy w protokole BGP

W bazach protokołu przechowywane sa˛ informacje o ścieżce, od źródła do adresu przeznacze-
nia, w postaci sekwencji numerów autonomicznych. Każda ścieżka to lista systemów, poprzez
które musza˛ być przesłane pakiety do adresu docelowego. Długość ścieżki jest jednym z podsta-
wowych kryteriów wyboru trasy. Sama długość ścieżki zależy zaś od polityki trasowania pakie-
tów, które wchodza˛ w skład ścieżki. O polityce decyduja˛ natomiast preferencje poszczególnych
administratorów oraz umowy mi˛edzyoperatorskie. Żaden z systemów autonomicznych nie ma
obowiazku
˛ przesyłania pakietów pomi˛edzy innymi systemami, a możliwości filtrowania takiego
ruchu w protokole BGP sa˛ zagwarantowane. Taka˛ sytuacj˛e ilustruje rysunek 6.11. Dla uproszcze-
nia przedstawia on tylko 5 systemów autonomicznych. Gdyby wszystkie systemy przepuszczały
cały ruch, to z AS 120 do AS 300 dopuszczalne byłyby nast˛epujace ˛ trasy:
200 300;
200 100 300;
200 150 100 300;
150 200 300;
150 100 300;
150 200 100 300;
Protokół BGP kierujac ˛ si˛e algorytmem najkrótszej ścieżki do wysyłania pakietów wybierze
ścieżk˛e poprzez AS 200. Może si˛e jednak zdarzyć, że operator AS 200 nie życzy sobie, aby
poprzez jego sieć były transmitowane pakiety z AS 120 do AS 300. Może ustawić wtedy filtr,
w którym ogłasza swoje istnienie do wszystkich sieci, a nie przekazuje informacji o ścieżkach,
które otrzymał od innych systemów autonomicznych. W tym momencie liczba ścieżek prowa-
dzacych
˛ z AS 120 do AS 300 zmaleje. Dost˛epna b˛edzie tylko ścieżka:
150 100 300;
Ruch może odbywać si˛e wyłacznie˛ jedna˛ droga,˛ choć teoretycznie dost˛epnych jest ich wi˛ecej.
Kryterium najkrótszej ścieżki ma t˛e wad˛e, że nie uwzgl˛ednia jakości poszczególnych łaczy ˛ oraz
nie rozstrzyga sytuacji, gdy do danego AS prowadza˛ co najmniej dwie ścieżki o tej samej długo-
ści. Przykładem moga˛ być ścieżki z AS 300 do AS 150. Dwie z nich, czyli 100 150 i 200 150,
maja˛ ta˛ sama˛ długość. Aby wybierać jedna˛ z nich jako ta˛ właściwa,˛ potrzebne sa˛ dodatkowe kry-
teria. Cz˛eść z nich jest standardem a cz˛eść rozwiazaniami
˛ firmowymi. Na przykład w routerach
firmy CISCO te dodatkowe kryteria to:
waga ścieżki – jeśli do danej lokalizacji prowadzi wiele ścieżek, to preferowana jest ta,
która ma przypisana˛ najwi˛eksza˛ wag˛e, wag˛e ustawia administrator;
lokalna preferencja ścieżki – jeśli do danej lokalizacji prowadzi wiele ścieżek, to prefero-
wana jest ta, która ma najwi˛eksza˛ lokalna˛ wartość preferencji;
idendyfikator routera, który najcz˛eściej jest numerem IP p˛etli zwrotnej, a jeśli go nie ma to
jest to najwyższy numer IP na interfejsach routera – jeśli do danej lokalizacji biegnie wiele
równoprawnych ścieżek, to preferowana jest ta, która wiedzie przez router o najniższym
identyfikatorze.
Kolejność wyboru ścieżki zależy od implementacji protokołu BGP na poszczególnych urzadze- ˛
niach. Poszczególne ścieżki można też w sztuczny sposób wydłużać poprzez kilkukrotne po-
wtórzenie w ścieżce numeru któregoś systemu autonomicznego. Co i jak zostanie wykorzystane
zależy wyłacznie
˛ od umów mi˛edzyoperatorskich oraz poszczególnych administratorów.
6.9. Wymiana informacji pomi˛edzy protokołami

Nie zawsze jest możliwe zbudowanie sieci w oparciu o jeden protokół routingu. Jeśli w sieci
pracuje ich wiele, to może zajść konieczność wymiany informacji pomi˛edzy nimi. Informacje
o trasach otrzymanych od innego protokołu sa˛ traktowane jako informacje o trasach zewn˛etrz-
nych. Niektóre protokoły jak np. RIP-2 czy OSPF potrafia˛ oznaczać trasy otrzymane od innych
protokołów, a inne nie (np. RIP). Przy przenoszeniu informacji z jednego protokołu do drugie-
go istotnym parametrem jest przeniesienie informacji o metryce czyli swojego rodzaju kosztach
danej trasy. Jak tego typu informacja jest przeniesiona zależy do implementacji oprogramowania
na routerach. Moga˛ być to stałe wartości lub wartości, które może skonfigurować administrator.
Przed użyciem tego typu mechanizmu należy zapoznać si˛e z dokumentacja˛ routera.
6.10. Wybór protokołu dla sieci

Wybór właściwego protokołu dla danej sieci powinien wynikać z funkcji, jaka˛ ma on spełniać.
Nie ma sensu używać protokołu BGP do wymiany informacji routingowej wewnatrz ˛ małej sieci,
gdyż nie do tego jest przeznaczony. Ten protokół należy zastosować do routingu dynamicznego
pomi˛edzy wieloma zewn˛etrznymi operatorami. Do małych sieci przeznaczone sa˛ protokoły RIP
i OSPF. Obecnie cz˛eściej stosuje si˛e protokół OSPF, gdyż lepiej potrafi on wykorzystać możliwo-
ści sieci. Może si˛e jednak okazać, że jest on zbyt skomplikowany w danej sieci, wtedy pozostaje
protokół RIP w starej wersji lub jego modyfikacja, RIP wersja 2. Ważne jest, aby dobrać i skon-
figurować protokół tak, aby sieć działała stabilnie i efektywnie, gdyż to jest najważniejsze dla
użytkowników, a nie mniej ważne możliwości i ograniczenia poszczególnych protokołów.
Bibliografia

R OZDZIAŁ 7
Podstawowe usługi sieciowe
W tym rozdziale zostana˛ omówione i przedstawione podstawowe usługi sieciowe, z którymi

wi˛ekszość użytkowników ma styczność na codzień. Cz˛eść z nich jest nawet postrzegana jako
synonim posiadania dost˛epu do sieci Internet, np. usługi WWW, poczta elektroniczna, a ich brak
zmniejsza w znaczacym ˛ stopniu atrakcyjność posiadania tegoż dost˛epu. Oprócz nich istnieje
liczna grupa usług, nieco mniej popularnych, wykorzystywanych w sieciach lokalnych i coraz
cz˛eściej w sieciach rozległych, np. usługi terminalowe, o których również b˛edzie mowa w tym
rozdziale.
Kolejność omawiania usług b˛edzie nast˛epujaca:
˛
poczta elektroniczna,
transmisja danych,
usługi terminalowe,
serwisy informacyjne,
synchronizacja czasu,
dost˛ep do informacji o użytkownikach.
Na działanie niektórych z wymienionych usług składa si˛e jeden lub wi˛ecej zaprojektowa-
nych dla tego celu protokołów. W omówieniu działania tych usług, protokoły te zostana˛ również
przedstawione.
7.1. Poczta elektroniczna

Idea przesyłania informacji w postaci elektronicznej mi˛edzy użytkownikami w sieci jest nie-
co starsza od pomysłu połaczenia
˛ komputerów w sieć. Funkcjonowała wcześniej w izolowa-
nych systemach wieloużytkownikowych. Najcz˛eściej pierwszym doświadczeniem z sieciami dla
wi˛ekszości użytkowników było wysłanie lub odebranie e-maila. Wygoda, szybkość i prosto-
ta programów pocztowych sprawiaja,˛ że poczta elektroniczna jest najcz˛e ściej wykorzystywana˛
usługa˛ w sieciach. Co wi˛ecej, dla licznej grupy użytkowników dost˛epność tej usługi całkowicie
zaspokaja ich potrzeby wykorzystania sieci.
Przedstawione poniżej protokoły ukrywaja˛ przed użytkownikiem mechanizm przesyłania
poczty mi˛edzy serwerami oraz metody dost˛epu do jego skrzynek pocztowych.
7.1.1. Protokół SMTP

Simple Mail Transfer Protocol służy tylko i wyłacznie
˛ do przesyłania poczty mi˛edzy komputera-
mi. Nie specyfikuje on systemu pocztowego wysyłajacego˛ ani odbierajacego,
˛ nazw użytkowni-
127
128 7.1. Poczta elektroniczna
ków, sposobu przechowywania informacji przez serwery pocztowe, wielkości przesyłki, liczby
przesyłek.
Standard SMTP określa jedynie format komunikatów wymienianych przez maszyn˛e nadaja- ˛
ca˛ przesyłk˛e i odbierajac
˛ a˛ ja.˛ Komunikaty te sa˛ przesyłane w postaci czytelnych tekstów ASCII,
co pozwala na komunikacj˛e dowolnych serwerów pocztowych bazujacych ˛ na dowolnych syste-
mach operacyjnych. Zestaw znaków ASCII jest bardzo prosty i znany wi˛ekszości użytkowników.
Standardowa procedura wysłania listy opiera si˛e na utworzeniu połaczenia˛ TCP ze zdalna˛ ma-
szyna˛ i oczekiwaniu aż ta przyśle komunikat, np.: 220 gorgan ESMTP server ready. Dalej
nast˛epuje, np.:
HELO howerla
250 gorgan Hello howerla [172.16.7.2], pleased to meet you
MAIL FROM: <xxx@domena.pl>
250 2.1.0 <xxx@domena.pl>... Sender ok
RCPT TO: <yyy@domena.com>
250 2.1.5 <yyy@domena.com>... Recipient ok
DATA
354 Enter mail, end with "." on a~line by itself
treść listu
.
Treść poszczególnych komunikatów może być różna, w zależności od serwera pocztowe-
go. Natomiast numery komunikatów zawsze b˛eda˛ takie same. W przypadku wystapienia ˛ bł˛edów
specyfikacja protokołu SMTP nie określa sposobu obsłużenia takiego komunikatu przez pro-
gram wysyłajacy ˛ poczt˛e. Zreszta˛ wi˛ekszość klientów nie takich wymagań w trakcie wysyłania
poczty. Informacj˛e o bł˛edzie, wraz z nagłówkiem listu, który ten bład
˛ wygenerował, wysyłajacy˛
otrzymuje jako list od systemu pocztowego.
Standard MIME SMTP nie przewiduje przesyłania danych w kodzie innym niż ASCII. Aby
umożliwić dołaczanie
˛ do listów poczty elektronicznej plików różnego rodzaju aplikacji, IETF
(ang.Internet Engineering Task Force) zdefiniowała rozszerzenie SMTP zwane MIME (ang. Mul-
tipurpose Internet Mail Extensions). Umożliwia ono zakodowanie dowolnego typu danych w ASCII.
Dzi˛eki temu, przy pomocy SMTP można przesyłać w listach różnego rodzaju załaczniki.
˛
Dane zakodowane przez MIME w nagłówkach zawieraja˛ informacj˛e konieczna˛ do ich zde-
kodowania. W szczególności jest w nich zawarty typ zakodowanych danych, sposób kodowania
oraz wersja MIME. List zawiera również podobnego typu informacje, aby umożliwić przesyłanie
danych dowolnego dowolnego typu. Przykład przesyłki zawierajacej˛ załacznik
˛ jest przedstawio-
ny poniżej:
Date: Wed, 11 Jun 2003 12:27:08 +0200
From: xxx@domena.pl
To: yyy@domena.pl>
Subject: Re: Problem
Message-ID: <20030611102708.GC7856@domena.pl>
References: <20030611100634.GB7856@domena.pl>
<20030611101656.GA7982@domena.pl>
Podstawowe usługi sieciowe 129
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20030611101656.GA7982@domena.pl>
User-Agent: Mutt/1.4.1i
--/04w6evG8XlLl3ft
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
[...]
Treść listu.
[...]
--/04w6evG8XlLl3ft
Content-Type: application/x-zip-compressed
Content-Disposition: attachment;
filename="IsTapeInserted.zip"
Content-Transfer-Encoding: base64
Jak widać, w nagłówku listu jest umieszczona informacja o użyciu MIME w wersji 1.0 oraz
o tym, że list składa si˛e z kilku cz˛eści (Content-Type: multipart/mixed). Każda z nich może być
zakodowana w innym formacie, co również przedstawia przedstawiony przykład. Standard MI-
ME wymaga od aplikacji używania pary identyfikatorów, rozdzielonych znakiem "/" w nagłówku
Content-Type. Pierwszy identyfikator, oprócz przedstawionego w przykładzie, informuje o typie
danych. Możliwe sa˛ nast˛epujace ˛ typy:
text – tekst,
image – obrazy typu GIF, JPEG, BMP, itd.,
audio – dane audio,
video – dane video,
application – dane programu,
message – list poczty elektronicznej.
Drugi identyfikator natomiast definiuje dokładniej, jakiego typu sa˛ to dane. Standard MIME
wymusza również, aby dany typ danych zawierał konkretne „podtypy”, np. dane audio nie moga˛
w podtypie zawierać gif.
Dla przedstawionego w przykładzie typu multipart, oprócz danych mixed IETF przewidział
inne typy danych:
alternative – wiele typów kodowania tych samych danych,
parallel – gdy pojedyncze cz˛eści powinny być ogladane˛ wspólnie, np. audio i video,
digest – gdy przesyłka zawiera zbiór innych listów, np. fragment archiwum jakiejś listy
dyskusyjnej.
Przesyłanie poczty Dostarczanie przesyłek poczty elektronicznej odbywa si˛e w nast˛epujacy ˛

sposób. Nadawca tworzy list a nast˛epnie łaczy ˛ si˛e przy pomocy swojego klienta pocztowego
(MUA – ang. Mail User Agent) z serwerem (MTA – ang. Mail Transfer Agent), który go wyśle.
Jeżeli połaczenie
˛ si˛e nie uda, to list nie jest wysyłany. Najcz˛eściej program wysyłajacego
˛ umiesz-
cza go w swojej lokalnej kolejce listów oczekujacych ˛ na wysłanie. Po ustalonym czasie lub przy
próbie wysłania kolejnego listu i nawiazaniu ˛ połaczenia
˛ z serwerem, wszystkie listy oczekujace
˛
na wysłanie zostana˛ przekazane do serwera. Przykład konfiguracji klienta poczty przedstawia
rysunek 7.1
Rysunek 7.1: Fragment konfiguracji klienta poczty.
Serwer pocztowy gromadzi listy do wysłania w zdefiniowanych kolejkach. Po umieszczeniu

przesyłki w kolejce, serwer nawiazuje˛ połaczenie
˛ z odległym serwerem pocztowym. Na pod-
stawie informacji w nagłówkach listu, lokalny serwer wie, w jakiej domenie DNS znajduje si˛e
adresat. Dzi˛eki temu oraz rekordom MX systemu DNS może ustalić nazw˛e i adres IP maszyny
obsługujacej˛ poczt˛e elektroniczna˛ w domenie adresata. Po ustaleniu adresu IP próbuje nawiaza˛ ć
połaczenie
˛ TCP z odległa˛ maszyna.˛ Jeśli si˛e to uda, przesyła wiadomość do tej maszyny i po
potwierdzeniu jej odebrania likwiduje kopi˛e przesyłki w lokalnej kolejce.
Zgromadzone w kolejkach przesyłki moga˛ przebywać w nich określony, zdefiniowany czas.
Jeśli ten limit czasowy zostanie przekroczony i list nie zostanie w tym czasie wysłany do odbior-
cy, serwer usuwa taka˛ wiadomość ze swoich kolejek. Nadawca jest informowany o tym fakcie
przez otrzymanie komunikatu o bł˛edzie od serwera. Najcz˛estsza˛ przyczyna˛ powstawania tego
typu sytuacji sa˛ bł˛edne informacje w nagłówkach listów lub brak odpowiednich wpisów w rekor-
dach systemu DNS. Druga˛ z możliwych przyczyn jest awaria, niedost˛epność odległego serwera
pocztowego w tym czasie. Zgodnie ze standardami serwer powinien przechowywa ć listy przez
5 dni.
7.1.2. Protokół POP3

Utrzymywanie serwerów pocztowych na komputerze każdego użytkownika oraz ich ciagła ˛ pra-
ca w ciagu
˛ doby sa˛ zbyt kosztowne dla wi˛ekszości firm. Poza tym jest to zbyt skomplikowane
w przypadku, gdy użytkownicy nie potrafia˛ rozwiazać˛ problemów powstajacych
˛ przy obsłudze
serwera. Dlatego też w prawie 100% firm jest uruchomiony jeden lub kilka serwerów poczto-
wych dla użytkowników. Ułatwia to ich administracj˛e oraz utrzymanie. Jednocześnie powstaje
problem dost˛epu do skrzynek pocztowych użytkowników na serwerze. Najcz˛e ściej administra-
torzy chca˛ unikać sytuacji, w której dost˛ep do serwera pocztowego ma każdy użytkownik chcacy
˛
przeczytać poczt˛e elektroniczna.˛ Z wysłaniem nie ma problemu, gdyż wystarczy otworzy ć se-
sj˛e TCP z serwerem i przekazać mu wiadomość. W celu rozwiazania˛ problemu w dokumencie
RFC 1939 został zdefiniowany protokół dost˛epu do skrzynek pocztowych — POP3 (ang. Post
Office Protocol Version 3). Służy on do wykonywania operacji kasowania oraz odczytywania
listów przechowywanych w skrzynce pocztowej na innym komputerze. Alternatywnym proto-
kołem dla POP3 jest opisany w dalszej cz˛eści IMAP. Użytkownik konfigurujac ˛ swojego klienta
pocztowego zazwyczaj może wybrać jeden z tych protokołów. Przykład przedstawia rysunek 7.2
Rysunek 7.2: Wybór rodzaju protokołu w kliencie pocztowym.
W tym celu, na komputerze (niekoniecznie na serwerze pocztowym), przez który użytkow-

nicy maja˛ mieć możliwość si˛egania do swoich skrzynek pocztowych, na 110 porcie TCP uru-
chamiany jest proces demon oczekujacy ˛ na połaczenia.
˛ Program pocztowy użytkownika otwiera
połaczenie
˛ TCP z serwerem POP3 i oczekuje na zgłoszenie si˛e serwisu. Nast˛epnie wydaje ciag˛
komend oczekujac ˛ na odpowiedzi od serwera. Po ich wykonaniu nast˛epuje rozłaczenie.
˛
Zbiór komend rozumianych przez serwer POP3 jest ściśle zdefiniowany. Komendy musza˛
być przesyłane w ASCII, argumenty oddzielone spacjami, nie moga˛ być dłuższe niż 40 znaków.
Serwer musi odpowiadać na nieznane, nie zaimplementowane komendy informacja˛ o bł˛edzie
-ERR lub +OK w przeciwnym wypadku.
W ramach jednej sesji serwer POP3 pracuje kolejno w kilku trybach. Zaraz po nawiazaniu ˛
połaczenia
˛ znajduje si˛e w trybie autoryzacji. Przejście do nast˛epnego trybu nast˛epuje, gdy klient
pomyślnie przejdzie proces identyfikacji — poda prawidłowa˛ nazw˛e użytkownika i hasło. Ser-
wer wówczas uzyskuje prawo do przeczytania zwartości skrzynki użytkownika. Po przeczytaniu
informuje o liczbie wiadomości w skrzynce i przechodzi do trybu transakcyjnego. Po przesła-
niu wiadomości ze skrzynki serwer czeka na komend˛e QUIT. Po jej otrzymaniu przechodzi do
trybu odświeżania informacji na serwerze. W tym trybie aktualizowana jest informacja o prze-
czytanych badź
˛ nie przeczytanych wiadomościach w skrzynce użytkownika oraz zwalniane sa˛
uprzednio zaj˛ete zasoby systemu. Nast˛epnie serwer zamyka połaczenie˛ TCP.
Przed wejściem w tryb transakcyjny serwer POP3 blokuje dost˛ep do skrzynki, aby ochroni ć
ja˛ przed modyfikacja˛ zanim serwer przejdzie do trybu odświeżania informacji o skrzynce.
Po otwarciu skrzynki serwer POP3 przypisuje każdej wiadomości numer (zaczynajac ˛ od 1)
oraz sprawdza wielkość każdej z nich w bajtach. Gdy serwer zmienia tryb pracy na transakcyjny,
jest wyświetlana informacja o liczbie wiadomości i ich łacznej
˛ wielkości. Prezentuje to przykład:
Escape character is ’^]’.

+OK POP3 gorgan v2001.80 server ready
user <nazwa_użytkownika>
+OK User name accepted, password please
pass <hasło_użytkownika>
+OK Mailbox open, 29 messages
quit
+OK Sayonara
W trybie transakcyjnym serwer może otrzymać komendy:

stat – odpowiada liczba˛ wiadomości oraz ich łaczn
˛ a˛ wielkościa˛ w bajtach,
list – podaje numer każdej wiadomości oraz jej wielkość w bajtach,
retr <numer_wiadomości> – przesyła wraz z nagłówkami treść wiadomości o podanym
numerze,
dele <numer_wiadomości> - usuwa wiadomość o podanym numerze,
noop – serwer nic nie robi, odpowiada +OK,
rset – jeśli jakiekolwiek wiadomości były zaznaczone jako „usuni˛ete” znaczniki usuni˛ecia
sa˛ cofane,
top <numer_wiadomości> <liczba> – komenda może dotyczyć tylko wiadomości nie ozna-
czonych jako skasowane. Serwer odpowiada liczba˛ linii (poczawszy ˛ od nagłówka) wska-
zanej wiadomości,
uidl - <numer_wiadomości> – serwer odpowiada unikalnym numerem wiadomości. Nu-
mer ten jest zawsze stały niezależnie od sesji. Służy programom klientów do rozróżnienia,
które wiadomości sa˛ nowe, a które były już wcześniej odczytane. W przypadku nie po-
dania numeru wiadomości serwer przedstawia identyfikatory dla wszystkich wiadomości
w skrzynce,
quit – rozłaczenie.
˛
Oprócz identyfikacji przez nazw˛e użytkownika i hasło niektóre serwery POP3 maja˛ zaim-
plementowana˛ metod˛e, w której użytkownik jest rozpoznawany na podstawie nazwy oraz skrótu
MD5 znacznika czasowego oraz podanej frazy. W ten sposób hasło użytkownika nie jest przesy-
łane otwartym tekstem przez sieć.
7.1.3. Protokół IMAP

Protokół ten został zdefiniowany w dokumencie RFC1730. Jego uaktualnienie zawiera RFC3501.
Przedstawione poniżej omówienie odnosi si˛e do wersji 4 protokołu IMAP. Poprzednie, 2 i 2bis,
sa˛ raczej rzadko używane.
Podobnie jak POP3, protokół IMAP pozwala użytkownikom na zdalny dost˛ep do swoich
skrzynek pocztowych na serwerach, ich modyfikowanie, przeszukiwanie, tworzenie folderów,
ustawianie flag. Nie pozwala na wysyłanie wiadomości poczty elektronicznej.
Klient pocztowy użytkownika, podobnie jak w poprzednim przypadku, musi nawiaza ˛ ć poła-
˛
czenie TCP z serwerem IMAP, port 143. Przed każda˛ komenda˛ klient generuje dla niej identyfi-
kator tzw. tag, np. A0001. Do serwera wysyłana jest cała komenda poprzedzona tym identyfika-
torem. W przypadku wystapienia˛ bł˛edu serwer odpowiada komunikatem BAD i podaje identyfika-
tor komendy, która bład ˛ spowodowała. W przeciwnym przypadku serwer zwraca OK. Jest jeszcze
jeden rodzaj komunikatu – NO – zwracany przez serwer, gdy wystapi ˛ bład˛ nie zwiazany
˛ z for-
matem komendy lub protokołem. Komendy wysyłane do lub z serwera sa˛ w postaci normalnego
tekstu.
Serwery IMAP również pracuja˛ w kilku trybach. Wi˛ekszość komend, które klient może wy-
dać serwerowi jest ściśle przypisana do trybu pracy. Komend jest znacznie wi˛ecej w porównaniu
z protokołem POP3. Tryby pracy to:
1. nie autoryzowany – serwer pracuje w tym stanie dopóki, użytkownik nie zostanie prawi-
dłowo zidentyfikowany,
2. autoryzowany – serwer przechodzi do tego trybu po podaniu przez użytkownika informacji
potrzebnych do jego rozpoznania; klient musi w tym trybie wybrać skrzynk˛e pocztowa,˛
3. modyfikacje skrzynki – użytkownik może modyfikować wybrana˛ skrzynk˛e,
4. rozłaczanie
˛ – zakończenie sesji.
W przeciwieństwie do POP3, przy pomocy protokołu IMAPv4 użytkownik może mieć zde-
finiowane na serwerze kilka katalogów ze skrzynkami pocztowymi. Dlatego też wymagane jest
określenie jednej skrzynki jako głównej. Kolejne moga˛ być podane w dowolnej kolejności.
Ponieważ to serwer wykonuje zlecone mu zadania zarzadzania
˛ skrzynkami, może on w do-
wolnym momencie wysłać do klienta komunikat, np. o pojawieniu si˛e w skrzynce nowej poczty
czy też prośb˛e o potwierdzenie usuni˛ecia wiadomości. Co wi˛ecej, serwer może przetwarzać ko-
lejne polecenia klienta bez czekania na zakończenie poprzednich komend. Odst˛epstwem od tego
jest sytuacja, w której wynik działania poprzednich komend może mieć wpływ na nast˛epne.
Serwer sam rozpoznaje taka˛ sytuacj˛e i wówczas czeka na zako ńczenie poprzednich poleceń.
Po otwarciu sesji TCP mi˛edzy klientem a serwerem, klient może wydać serwerowi nast˛epu-
jace
˛ komendy:
1. CAPABILITY – serwer odpowiada lista˛ obsługiwanych przez niego opcji,
2. NOOP – nie robi nic,
3. LOGOUT – rozłaczenie.
˛
Sa˛ to jedyne trzy komendy, które klient może wydać serwerowi w każdym stanie. Przedstawia
to przykład:
$ telnet gorgan 143

Trying 172.16.7.1...
Connected to gorgan.
* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] gorgan
IMAP4rev1 2002.328 at Fri, 4 Jul 2003 17:11:08 +0200 (MET DST)
a000 capability
* CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN SORT
THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND LOGIN-REFERRALS
STARTTLS AUTH=LOGIN
a000 OK CAPABILITY completed
a001 N^H
a001 BAD Missing command
a002 noop
a002 OK NOOP completed
a003 logout
* BYE gorgan IMAP4rev1 server terminating connection
a003 OK LOGOUT completed
Connection closed by foreign host.
$
Po otwarciu sesji TCP z serwerem klient protokołu IMAP znajduje si˛e w pierwszym z wy-
mienionych trybów pracy. Przebywajac ˛ w nim może wydać serwerowi komend˛e AUTHENTICATE
lub LOGIN. Komendy te moga˛ mieć kilka różnych argumentów, które określaja˛ sposób autory-
zacji użytkownika. Jeśli serwer obsługuje wybrany sposób autoryzacji, to rozpoczyna wysyłanie
serii zapytań do klienta. Każde z tych zapytań musi zaczynać si˛e od +. Komunikaty sa˛ kodowa-
ne przy użyciu kodowania BASE64. Jeśli klient chce przerwać proces autoryzacji, to wysyła do
serwera znak *. Oprócz samego procesu autoryzacji serwer może negocjować z klientem spo-
sób zabezpieczenia tej sesji. Jeśli obie strony zgodza˛ si˛e na stosowanie wybranego mechanizmu
ochrony sesji, to jest on stosowany do każdego komunikatu wymienianego mi˛edzy serwerem
a klientem. Nie ma jednak wymagań na to, które z metod autoryzacji musza˛ być obsługiwane
przez serwer, jak również wymagań stosowania określonych sposobów zabezpieczania sesji.
Najprostszym sposobem jest podanie nazwy użytkownika i hasła. Prezentuje to poniższy
przykład:
$ telnet gorgan 143

Trying 172.16.7.1...
Connected to gorgan.
* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] gorgan
IMAP4rev1 2002.328 at Mon, 7 Jul 2003 15:39:50 +0200 (MET DST)
a001 login userxxx password
a001 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN
SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User userxxx

authenticated
a002 logout
* BYE gorgan IMAP4rev1 server terminating connection
a002 OK LOGOUT completed
Connection closed by foreign host.
$
Po rozpoznaniu użytkownika przez serwer nast˛epuje przejście do kolejnego z wymienionych

trybów pracy. Użytkownik może wysyłać do serwera polecenia:
SELECT – wybór skrzynki pocztowej; serwer musi odpowiedzieć ustawiajac ˛ jedna˛ z flag:
<n> EXISTS – liczba wiadomości w skrzynce,
<n> RECENT – liczba nowych wiadomości od czasu ostatniego jej czytania,
OK [UIDVALIDITY <n>] – unikalny identyfikator skrzynki; jest on stały dla wszyst-
kich sesji.
Serwer może modyfikować tylko jedna˛ skrzynk˛e na raz. Zmiana skrzynki powodu-
je, że poprzednia przestaje być dost˛epna. Jeśli wybrana skrzynka również okaże si˛e
niedost˛epna, to serwer nie b˛edzie operował na żadnej skrzynce czekajac ˛ znowu na
komend˛e SELECT. Po wydaniu komendy SELECT skrzynka jest otwarta w trybie read–
write.
EXAMINE – działa tak samo jak SELECT ale otwiera skrzynk˛e w trybie read–only,
CRATE – tworzy nowa˛ skrzynk˛e o nazwie podanej jako argument,
DELETE – usuwa skrzynk˛e o podanej nazwie,
RENAME – zmienia nazw˛e podanej skrzynki na nowa,˛
SUBSCRIBE – dodaje skrzynk˛e do zbioru aktywnych lub inaczej zapisanych; klient IMAP4
może użytkownikowi pokazywać wiadomości, pojawiajace ˛ si˛e tylko w tych skrzynkach,
do których użytkownik jest zapisany,
UNSUBSCRIBE – działanie odwrotne,
LIST – służy do pobierania z serwera listy elementów pasujacych ˛ do wzorca, z miejsca
wskazanego argumentem komendy, np.
C: a005 list "~/Mail/" "%"
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/archive
S: a005 OK LIST completed
Pierwszym argumentem zazwyczaj jest katalog ze skrzynkami pocztowymi. Drugi wyszu-

kuje skrzynki zgodnie z maska; ˛ możliwe jest podawanie wzorców np, "%", który oznacza
skrzynk˛e o dowolnej nazwie w katalogu podanym jako argument pierwszy,
LSUB – komenda działa tak samo jak LIST z tym, że brane sa˛ pod uwag˛e tylko skrzynki
oznaczone jako aktywne,
APPEND – zapisuje do wskazanej skrzynki podany argument tesktowy (wiadomość)
Jak widać możliwości, które oferuje serwer IMAP, sa˛ znacznie wi˛eksze niż w protokole
POP3. Daje on użytkownikowi duże możliwości zarzadzania
˛ swoimi wiadomościami na ser-
werze. Dodatkowo możliwości te sa˛ poszerzone o zbiór komend dost˛epny w trybie czytania
wiadomości z wybranej skrzynki:
136 7.2. Przesyłanie plików
CHECK – wymusza na serwerze sprawdzanie wszelkiego typu statusu lub stanów skrzyn-
ki, np. synchronizacj˛e zawartości skrzynki w pami˛eci serwera z zawartościa˛ zapisana˛ na
dysku,
CLOSE – usuwa wszystkie wiadomości z ustawiona˛ flaga˛ usuni˛ eta oraz zamyka wybra-
na˛ wcześniej skrzynk˛e; serwer przechodzi do trybu oczekiwania wyboru skrzynki przez
klienta,
EXPUNGE – usuwa z aktualnej skrzynki wszystkie wiadomości z ustawiona˛ flag˛e usuni˛ eta,
SEARCH – przeszukuje wiadomości pod katem ˛ zawierania wskazanego kryterium; do-
puszczalne sa˛ logiczne wyrażenia: OR, AND i NOT; serwer zwraca identyfikator wiadomości
spełniajacej
˛ podane warunki przeszukiwania,
FETCH – pozwala na pobranie z serwera danych zwiazanych ˛ z dana˛ wiadomościa,
˛ mi˛edzy
innymi przez komendy (sa˛ to tylko przykłady wi˛ekszej liczby komend tego typu):
- ALL – cała wiadomość,
- BODY – treść wiadomości,
- BODY[<section>] – treść ze wskazanej sekcji (przydatne przy wiadomościach typu
multipart/mixed
PARTIAL – pozwala na pobranie z serwera konkretnej liczby bajtów, od wskazanej pozycji
wybranej wiadomości,
ALTER – zapisuje zmiany wprowadzone w wiadomości w skrzynce,
COPY – zapisuje wskazana˛ wiadomość do wskazanej skrzynki.
Z punktu widzenia użytkownika, najważniejsza˛ funkcja˛ oferowana˛ przez serwery IMAP, jest
możliwość przechowywania folderów poczty na serwerze (a nie lokalnie w formacie zależnym
od używanego klienta pocztowego), możliwość szybkiego ich odbierania. W przeciwieństwie do
serwerów POP3, serwery IMAP moga˛ wysyłać klientowi tylko nagłówki wiadomości bez ich
treści. Dla użytkowników łacz ˛ acych
˛ si˛e z siecia˛ przez zwykłe modemy jest to ogromne udo-
godnienie. Moga˛ od razu kasować niechciane wiadomości bez przesyłania ich na swój lokalny
komputer. Użytkownicy moga˛ sortować nadchodzace ˛ przesyłki i zapisywać je do różnych skrzy-
nek zgodnie ze zdefiniowanymi przez siebie regułami.
Inna˛ zaleta˛ korzystania z serwerów IMAP jest możliwość rozsyłania wiadomości w grupie
użytkowników bez potrzeby obciażania
˛ serwera pocztowego. Wystarczy, że zapisze on wiado-
mość w podanej skrzynce, która˛ b˛eda˛ mogli wybrać użytkownicy tej grupy w konfiguracji swo-
ich klientów IMAP. W przypadku serwera POP3 konieczne w takim wypadku jest rozesłanie
wiadomości do wszystkich użytkowników. W konfiguracji klienta POP3 można też stworzyć
dodatkowe konto u każdego klienta w grupie a klientom kazać odbierać poczt˛e również z tych
dodatkowych kont. Jest to jednak rozwiazanie˛ bardziej złożone niż w protokole IMAP.
Podobna,˛ a w niektórych aspektach szersza,˛ funkcjonalność daje serwer Exchange firmy
Microsoft.
7.2. Przesyłanie plików

Przesyłanie plików przez użytkowników jest jedna˛ z najcz˛eściej wykonywanych operacji. Sta-
nowia˛ one znaczna˛ cz˛eść ruchu w sieciach komputerowych.
Protokoły do tego używane zapewniaja˛ dost˛ep do plików na innych komputerach dwiema
drogami: albo przez kopiowanie (FTP, SCP) albo jako dost˛ep zintegrowany z systemem ope-
racyjnym gdzie operacje dost˛epu do zdalnych plików sa˛ dla użytkownika niewidoczne (NFS,
CIFS). W obu jednak przypadkach protokoły musza˛ uwzgl˛edniać prawa dost˛epu do pliku (nie
zawsze zapisywane w ten sam sposób jak w systemie lokalnym), różnice w nazwach plików,
różnice w reprezentacjach binarnych (choć czasami konwersja formatów powodowałaby utrat˛e
danych i jest niemożliwa).
7.2.1. Protokół FTP

FTP (ang. File Transfer Protocol był pierwszym z protokołów przeznaczonych specjalnie do
transferu plików. Choć nie tylko. Jego autorzy założyli możliwość wykorzystania go do wy-
syłania poczty elektronicznej oraz zadań drukarkowych, choć nie jest to implementowane. Aby
z niego korzystać, użytkownik musi mieć program klienta. Program klienta oferuje użytkowniko-
wi dost˛ep interakcyjny. Program ten łaczy˛ si˛e ze wskazanym serwerem FTP, próbujac ˛ otworzy ć
sesj˛e TCP na porcie 21. Przed wykonaniem jakichkolwiek operacji przesłania danych do lub
z serwera, użytkownik musi podać identyfikator w postaci nazwy użytkownika i hasła.
Serwer i klient FTP używaja˛ odr˛ebnego połaczenia
˛ do przesyłania danych sterujacych
˛ oraz
odr˛ebnych połaczeń
˛ do transmisji każdego z czytanych lub zapisywanych plików z osobna. Po-
łaczenie
˛ sterujace
˛ jest otwarte tak długo jak trwa sesja FTP. Wszystkie komendy wysyłane do
serwera oraz jego odpowiedzi sa˛ przesyłane w kodzie ASCII (tak samo jak w przypadku SMTP,
POP3, IMAP).
Do transmisji danych wykorzystywany jest protokół UDP. Klient może używać do pracy
z serwerem jednego z dwóch trybów. W trybie aktywnym (ang. active) klient lokalnie używa

dowolnego, numeru portu (wi˛ekszy od NP 1023) niezaj˛etego przez inna˛ aplikacj˛e. Łaczy ˛ si˛e

z serwerem FTP (port 21) i zaczyna nasłuchiwać na porcie NP 1. Do serwera zaś wysyła po-
lecenie PORT NP+1. Serwer nawiazuje ˛ wówczas połaczenie
˛ z klientem na wskazanym porcie,
lokalnie używajac ˛ portu 20 (TCP). Tryb aktywny jak widać wymaga po stronie klienta możliwo-
ści tworzenia z nim połaczeń,
˛ przez „zewn˛etrzne” komputery, na portach o numerach wi˛ekszych
niż 1023. Z tego powodu bardzo cz˛esto jest on blokowany przez urzadzenia˛ zabezpieczajace
˛ sie-
ci LAN. Alternatywa˛ dla trybu active jest tryb pasywny (ang. passive). W trybie tym klient łaczy˛
si˛e z serwerem FTP używajac
˛ lokalnie dwóch portów NP 1023 i NP 1. Po połaczeniu ˛ z ser-
werem klient wysyła do niego komend˛e PASV. Wówczas serwer wybiera lokalny, losowy port

(P 1023) i wysyła do klienta polcenie PORT P. Klient ustaleniu numeru portu serwera tworzy
z nim połaczenie
˛ P
NP 1. Ten tryb jest najcz˛eściej wykorzystywany. Nie wymaga on
po stronie urzadzeń
˛ zabezpieczajacych,
˛ np. firewalle , otwierania kanałów komunikacyjnych na
wysokich portach z komputerami w chronionej sieci.
W trakcie pracy z serwerem użytkownik może specyfikować format zapisywanych lub odczy-
tywanych danych (dane binarne, w kodzie ASCII). Oprócz tego może wydawa ć serwerowi cały
szereg dodatkowych komend. Ich list˛e można uzyskać przez uruchomienie klienta ftp i wydaniu
komendy help.
Oprócz protokołu FTP istnieje TFTP (ang. Trivial FTP). W odróżnieniu od FTP protokół ten
nie ma wbudowanych mechanizmów autoryzacji i nie ma możliwości pracy w trybie interakcyj-
nym z użytkownikiem. Dzi˛eki temu pliki binarne klienta TFTP oraz serwera zajmuja˛ niewiele
miejsca w pami˛eci. Korzystaja˛ z tego producenci urzadze ˛ ń sieciowych, którzy na kliencie TFTP
opieraja˛ możliwości instalowania nowszych wersji oprogramowania, bezdyskowe stacje robo-
cze, które przy pomocy TFTP pobieraja˛ z serwera pliki z obrazem jadra. ˛
138 7.2. Przesyłanie plików
7.2.2. Protokół NFS

Sieciowy system plików (ang. Network File System) został opracowany przez firm˛e Sun Micro-
systems. System ten zapewnia użytkownikowi „przezroczysty” dost˛ep do plików i programów
położonych na innych komputerach. Konieczne do tego jest jedynie uruchomienie serwera NFS
oraz wyposażenie użytkownika w program klienta.
Klient może wysyłać do serwera polecenia otwarcia, zapisania, odczytania pliku. Serwer
sprawdza czy użytkownik, który wysyła te polecenia ma prawo do wykonania tych operacji.
Informacje o tym sa˛ pobierane przez serwer na podstawie identyfikatora użytkownika, który albo
istnieje w lokalnych dla serwera plikach konfiguracyjnych (np. /etc/passwd i musi by ć identyczny
na stacji użytkownika i serwerze w systemach UNIX) albo sa˛ dost˛epne przez serwisy takie jak
NIS lub NIS+ (ang. Network Information Service).
Oprócz tego serwer określa z jakimi prawami udost˛epniane sa˛ wskazane w konfiguracji za-
soby. W szczególności może zabronić wykonywania programów z ustawionym bitem SUID 1 .
Projektanci NFS oparli ten protokół o dwa wcześniej opracowane protokoły: RPC (ang. Re-
mote Procedure Call) oraz XDR (ang. eXternal Data Representation). Mechanizm RPC daje
możliwość podzielenia kodu aplikacji na kod serwera i klienta. Programista może wydzielić wy-
brane funkcje jako odległe i wskazać to kompilatorowi. Kompilator wówczas dołacza ˛ odpowied-
nie kody procedur RPC w trakcie kompilacji programu. RPC ukrywa przed programista˛ wszelkie
szczegóły protokołów. Dzi˛eki temu jest ch˛etnie wykorzystywany do budowy systemów rozpro-
szonych. Program klient wywołujac ˛ zdalna˛ procedur˛e sam tworzy odpowiedni rodzaj komunika-
tu i wysyła go do serwera. Nawiazanie
˛ połaczenia
˛ jest zupełnie niewidoczne dla użytkownika.
Drugi z protokołów, XDR, daje możliwość przekazywania danych w środowisku heteroge-
nicznym dokonujac ˛ konwersji do odpowiednich typów standardów sprz˛etowych. Jego główna˛
zaleta˛ jest automatyczna konwersja formatów danych mi˛edzy klientami a serwerami systemu
NFS.
7.2.3. Usługa SCP

SCP (ang. Secure Copy) jest usługa˛ najcz˛eściej interpretowana˛ jako fragment oprogramowania
SSH (opisanego w dalszej cz˛eści). Wynika to stad,˛ że usługa ta jest instalowana w systemach
przy okazji uruchamiania serwisu SSH. Można z niej jednak korzystać bez instalacji całego SSH.
W chwili obecnej dost˛epne sa˛ programy SCP działajace ˛ zarówno w środowisku Windows (Win-
SCP, pscp) jak i wszelkiego typu systemach UNIX. Rysunek 7.3 przedstawia przykład działania
programu WinSCP.
W swoim działaniu, z dotychczas wymienionych usług, SCP najbardziej przypomina FTP.
Oferuje mechanizm autoryzacji użytkownika przed wykonaniem operacji odczytu lub zapisu
plików. W przeciwieństwie jednak do FTP, SCP nie używa dwóch odr˛ebnych kanałów do komu-
nikacji i transferu danych. To, co wyróżnia SCP, to stosowanie mechanizmów kryptograficznych
przy wymianie danych mi˛edzy serwerem a klientem. Najcz˛e ściej sa˛ to te same mechanizmy, któ-
re oferuje SSH, gdyż to właśnie ta usługa jest wykorzystywana do zestawiania sesji, wymiany
kluczy mi˛edzy serwerem a klientem, ustalaniu parametrów transmisji (kompresja przesyłanych
danych lub jej brak, cz˛estotliwość wymiany klucza).
1 Programy z ustawionym bitem SUID wykonuja˛ si˛e z rzeczywistymi prawami właściciela pliku a nie użytkow-
nika, który uruchomił program.
Rysunek 7.3: WinSCP - przykład działania.
7.3. Usługi terminalowe

Dosyć cz˛esto zdarza si˛e sytuacja, w której użytkownicy chcieliby mieć możliwość korzystania
z zasobów innych komputerów pracujacych ˛ w odległych miejscach, nie posiadajac ˛ dost˛epu do
konsoli tych maszyn. Jednym ze sposobów zapewniajacych ˛ ten rodzaj pracy sa˛ serwisy WWW,
np. wyszukiwarki internetowe. Poprzez odpowiedni interfejs oferuja˛ one dost˛ep do bazy adre-
sów oraz możliwość ich przeszukiwania. Nie zawsze jednak chodzi tylko o tego typu dost˛ep.
Cz˛esto np. studenci chca˛ korzystać z kompilatorów zainstalowanych na serwerach uczelnianych,
pracownicy ze specjalistycznego oprogramowania używanego w firmie, itd. Wówczas nieoce-
nione staja˛ si˛e możliwości korzystania z opisanych poniżej protokołów oferujacych
˛ dost˛ep do
wszystkich poleceń na odległym systemie.
7.3.1. Protokół TELNET

Protokół ten umożliwia użytkownikowi zestawienie sesji TCP mi˛edzy dwoma odległymi syste-
mami. Na jednym z nich musi pracować proces serwera usługi TELNET. Użytkownik musi być
wyposażony w program klienta. Użytkownik może wskazać serwer TELNET- a podajac ˛ jego
nazw˛e lub numer IP. Serwer przeprowadza autoryzacj˛e użytkownika. W tym celu musi on po-
dać nazw˛e użytkownika i hasło. Jednak przesyłane dane, pomi˛edzy klientem i serwerem, nie sa˛
w żaden sposób zabezpieczone przed podsłuchem.
Po nawiazaniu
˛ sesji TCP klient przesyła do serwera informacje o wszystkich naciśni˛etych
klawiszach. Zwrotnie przyjmuje znaki, które przysłał serwer i wyświetla je na terminalu użyt-
kownika. Ponieważ serwer TELNET-u musi obsługiwać wiele sesji jednocześnie, zazwyczaj je-
den proces serwera oczekuje na nowe połaczenia
˛ na porcie 23 TCP. Dalej przekazuje on obsług˛e
połaczenia
˛ tworzonemu w tym celu procesowi podrz˛ednemu. Dla użytkownika, po nawiazaniu˛
140 7.3. Usługi terminalowe
sesji przy pomocy TELNET- a , praca z odległym systemem przebiega w sposób przypominajacy ˛
prac˛e na lokalnej konsoli.
Najwi˛ekszy problem, z jakim mieli do czynienia autorzy tego protokołu, to różnorodność sys-
temów operacyjnych na jakich może działać klient i serwer. Heterogeniczność środowisk niesie
za soba˛ różna˛ interpretacj˛e znaków pochodzacych
˛ z klawiatury, możliwość używania 7 bitowego
lub 8 bitowego zbioru znaków ASCII.
W celu rozwiazania
˛ problemu TELNET definiuje tzw. sieciowy terminal wirtualny
(ang. Network Virtual Terminal – NVT). Dzi˛eki niemu klient i serwer posługuja˛ si˛e tym sa-
mym interfejsem w komunikacji mi˛edzy soba.˛ Poza tym protokół umożliwia negocjowanie opcji
(oprócz zbioru opcji standardowych) oraz nie wymaga, aby dane wejściowe klienta pochodziły
z klawiatury, a dane wyjściowe były wyświetlane na ekranie.
Sieciowy terminal wirtualny wykorzystuje mechanizm tzw. pseudoterminali w systemach
operacyjnych. Oferuja˛ one działajacym ˛ programom dost˛ep do systemu przekazujac ˛ znaki prze-
syłane przez klienta tak jakby pochodziły z klawiatury. Bez tego mechanizmu budowa serwerów
TELNET byłaby niemożliwa. To, czy wiersze tekstu powinny si˛e ko ńczyć znakiem CR, LF, czy
też CR-LF, który z klawiszy (lub ich sekwencji) daje możliwość przerwania programu, zależy od
systemu operacyjnego. Dlatego też polecenia użytkownika sa˛ tłumaczone na format NVT i wy-
syłane do serwera. Wirtualny terminal po stronie serwera tłumaczy je na format swojego systemu
operacyjnego. Podobnie dzieje si˛e przy przesyłaniu odpowiedzi serwera do klienta.
Umożliwienie przerywania działajacych ˛ programów jest bardzo istotne. Dzi˛eki temu pro-
gram, działajacy˛ bez kontroli, wywołany przez użytkownika, może zostać zatrzymany bez zb˛ed-
nego obciażania
˛ serwera. NVT do tego celu używa funkcji sterujacych:˛
IP – zakończ wykonujacy ˛ si˛e program (ang. Interrupt Process),
AO – wyczyść bufor wyjściowy (ang. Abort Output),
AYT – sprawdź czy serwer odpowiada (ang. Are You There),
EC – skasuj poprzedni znak (ang. Erase Character),
EL – skasuj bieżacy
˛ wiersz (ang. Erase Line),
SYNCH – wyczyść strumień danych aż do punktu z pilnymi danymi, interpretujac ˛ po
drodze polecenia (ang. Synchronize),
BRK – przerwanie (ang. Break).
Projektanci NVT zdecydowali o rozdzieleniu poleceń od zwykłych danych przesyłanych w ko-
dzie ASCII mi˛edzy klientem a serwerem. Dzi˛eki temu definiowanie nowych funkcji kontrolnych
jest bardzo przejrzyste i elastyczne. Nie ma kłopotu z interpretacja,˛ czy znak powinien by ć po-
traktowany jako dane czy jako funkcja kontrolna.
Aby zapanować nad programem, który nie działa prawidłowo na odległej maszynie, to jednak
czasami nie wystarczajace. ˛ W przypadku, gdy program użytkownika wykonuje niesko ńczone p˛e-
tle, nie czytajac
˛ danych z wejścia i nie generujac ˛ danych na wyjściu, w pewnym momencie bufo-
ry systemu operacyjnego moga˛ si˛e zapełnić. Serwer nie b˛edzie mógł wówczas zapisać wi˛ekszej
ilości danych w buforze pseudoterminalu. Musi wi˛ec zaprzestać czytania danych z połaczenia ˛
TCP, co spowoduje zapełnienie buforów połaczenia. ˛ To z kolei zmusi serwer do proponowania
zerowej wielkości okna, czyli zaprzestania przepływu danych. Przy opisanych dotychczas moż-
liwościach nie ma metody wysłania programowi polecenia IP. Dlatego też TELNET przesyła
sygnały poza kolejka˛ normalnych danych. W przypadku wysyłania funkcji kontrolnej protokół
wysyła dodatkowo funkcj˛e SYNCH i dodaje zarezerwowany bajt DMARK (ang. Data Mark).
W nagłówku TCP ustawia flag˛e URG. Dzi˛eki temu sygnał dociera natychmiast do serwera. Bajt
DMARK oznacza, że cz˛eść SYNCH zawiera strumień danych (zawsze pilnych).
Najbardziej złożona˛ cz˛eścia˛ protokołu TELNET jest możliwość negocjacji opcji. Dzi˛eki nim
połaczenie
˛ może być rekonfigurowane np. z trybu half-duplex do trybu full-duplex lub też okre-
ślony zostaje rodzaj terminalu użytkownika. Najcz˛eściej używane opcje zawiera tabela 7.3.1.
Nazwa Kod Znaczenie
TransmitBinary 0 Zmień przesyłanie na 8-bitowe przesyłanie binarne
Echo 1 Pozwolenie jednej ze stron na wykonywanie echa danych,
które otrzymuje
Suppress-GA 3 Nie wysyłaj sygnału "naprzód" po danych (potrzebne przy
połaczeniach
˛ half-duplex)
Status 5 Prośba o stan opcji po drugiej stronie
Timing-Mark 6 Prośba, aby w powrotnym strumieniu był wstawiony
wskaźnik czasowy
Terminal-Type 24 Wymiana informacji na temat wykonania i modelu używa-
nego terminala
End-of-Record 25 Zakończenie wysyłania danych kodem EOR
Linemode 34 Wysyłaj pełne wiersze zamiast pojedynczych znaków
Tabela 7.1: Cz˛esto używane opcje protokołu TELNET
Opcje sa˛ negocjowane na zasadzie zgłaszania próśb. Strona odbierajaca ˛ prośb˛e (komuni-
kat WILL X) o użycie danej opcji albo ja˛ akceptuje (komunikat DO X) albo odrzuca (komunikat
DON’T X). Mechanizm ten pozwala na negocjacj˛e opcji bez jakichkolwiek informacji o drugiej
stronie. Dzi˛eki temu jest możliwa współpraca starszych i nowszych wersji klientów i serwerów.
Niewatpliw
˛ a˛ zaleta˛ TELNET- a jest jego popularność oraz w miar˛e prosta implementacja,
z czego korzysta wielu producentów urzadze ˛ ń sieciowych do zdalnego zarzadzania
˛ swoimi pro-
duktami. Wada˛ jest przesyłanie znak po znaku tego co wpisuje użytkownik (jeśli nie zostana˛
wynegocjowane odpowiednie opcje) oraz zupełny brak zabezpiecze ń przed podsłuchiwaniem
treści przesyłanych mi˛edzy serwerem a klientem.
7.3.2. Protokół SSH

Secure Shell jest usługa˛ funkcjonalnie zbliżona˛ do TELNET- a . Tak samo jak w przypadku
TELNET- a użytkownik musi posiadać program klienta łacz ˛ acego
˛ si˛e z procesem serwera. Po
połaczeniu
˛ ze zdalnym systemem użytkownik ma możliwość korzystania z dost˛epnych na nim
poleceń i programów. SSH zawiera również możliwość negocjowania niektórych opcji połacze-
˛
nia oraz ustalanie parametrów wirtualnych terminali. Jednak na tym podobie ństwa si˛e kończa.˛
Autorzy SSH stworzyli protokół wymiany danych, odporny na podsłuch sieciowy. Cała komu-
nikacja mi˛edzy dwoma zdalnymi systemami jest szyfrowana. Do tego celu użyli silnych kryp-
tograficznie i ogólnie dost˛epnych algorytmów (w niektórych krajach, np. USA niektóre z nich
sa˛ opatentowane i niestety ich eksport poza granice tego kraju jest prawnie zakazany). Z tej za-
lety SSH szeroko korzystaja˛ i doceniaja˛ administratorzy systemów oraz ci użytkownicy, którym
zależy na bezpieczeństwie przesyłanych danych. W szczególności dotyczy to haseł dost˛epu do
systemów.
Program klienta w celu połaczenia

˛ z serwerem musi zestawić sesj˛e TCP z maszyna˛ serwera.
Standardowo proces serwera oczekuje na połaczenia˛ na porcie 22 TCP. Po takim połaczeniu
˛
przekazuje obsług˛e do procesu potomnego, sam czekajac ˛ dalej na nowe połaczenia.
˛
Po zestawieniu połaczenia
˛ TCP klient i serwer SSH ustalaja˛ mi˛edzy soba˛ mi˛edzy innymi ro-
dzaj algorytmu szyfrujacego,
˛ zasady kompresji przesyłanych danych, możliwość przesyłania in-
formacji generowanych przez aplikacje działajace˛ w środowiskach graficznych. Odbywa si˛e to na
zasadzie wysłania informacji o obsługiwanych algorytmach i opcjach przez klienta do serwera.
Nast˛epnie klient otrzymuje listy obsługiwanych algorytmów i opcji od serwera. Wówczas klient
wybiera (jeśli użytkownik wyraźnie tego nie określił) rodzaj stosowanego algorytmu. Zanim
jednak klient wyśle do serwera dalsze informacje, przy pomocy algorytmu Diffiego-Hellmana
ustalany jest wspólny symetryczny klucz w niezabezpieczonym kanale. Klucz ten służy do za-
bezpieczania przesyłanych danych w dalszej komunikacji. Klucz ten posiada każda ze stron ale
nie jest on nigdy przesyłany mi˛edzy nimi. Przykład możliwych do wyboru opcji przedstawia
rys. 7.4
Rysunek 7.4: Przykład możliwych do wyboru opcji w konfiguracji klienta SSH.
Wst˛epne dane sa˛ zabezpieczone wybranym symetrycznym algorytmem szyfrujacym, ˛ ale al-
gorytm opiera swoje działanie na idei szyfrowania asymetrycznego. W systemach tych do szyfro-
wania lub deszyfrowania potrzebne sa˛ dwa odr˛ebne klucze: prywatny i publiczny. Wiadomość
zaszyfrowana kluczem publicznym może być odczytana tylko przez kogoś, kto posiada klucz
prywatny z tej pary kluczy. Klucze prywatny i publiczny powinny być wygenerowane przez
użytkownika programem ssh-keygen w systemach UNIX. Jeżeli sa˛ wygenerowane to, klient SSH
przekazuje serwerowi, której ze znanych mu par klucz–użytkownik ma uży ć. Sa˛ to klucze pu-
bliczne. Serwer, jeżeli nie znajdzie informacji zabraniajacej
˛ mu zestawiania połacze
˛ ń z kom-
puterem użytkownika, wyśle klientowi numer losowy (ang. challenge) zaszyfrowany kluczem
publicznym użytkownika. Ponieważ klucz prywatny jest zabezpieczony hasłem, wi˛ec tylko użyt-
kownik znajacy
˛ to wyrażenie b˛edzie w stanie odczytać wiadomość od serwera. W ten sposób
użytkownik potwierdzi swoja˛ tożsamość.

W przypadku, gdy klucze publiczny i prywatny nie zostały wygenerowane, serwer SSH wyśle
klientowi zapytanie o nazw˛e użytkownika i jego hasło.
W obu przypadkach informacje te b˛eda˛ przesyłane w postaci zaszyfrowanej wybranym al-
gorytmem szyfrujacym. ˛ Dodatkowo serwer może tworzyć tzw. skróty (ang. Message Digest)
wysyłanych wiadomości. Skrót to nic innego jak skompresowana informacja o treści wiadomo-
ści. Jeżeli coś zostanie w treści zmienione, skrót ulegnie również zmianie. Do tego celu SSH
używa dwóch algorytmów: MD-5 lub SHA-1.
Bardziej bezpieczne i zalecane w używaniu SSH jest stosowanie autoryzacji przy pomocy
kluczy. Wprawdzie wymagaja˛ one od użytkownika poświ˛eceniu paru minut na poprawne skon-
figurowanie, lecz w dłuższym używaniu sa˛ wygodniejsze. W celu ułatwienia ich stosowania,
autorzy SSH umożliwiaja˛ uruchomienie programu ssh-agent, który może za nas przeprowadza ć
proces podawania wyrażenia przejściowego do odczytania klucza.
Poniżej został przedstawiony przykład konfiguracji SSH w systemach UNIX:
1. Generowanie kluczy:
$ ssh-keygen -b 2048
Initializing random number generator...
Generating p: ....................................++ (distance 628)
Generating q: ...................................................++
(distance 788)
Computing the keys...
Testing the keys...
Key generation complete.
Enter file in which to save the key
(/home/user/.ssh/identity):
Enter passphrase:
Enter the same passphrase again:
Your identification has been saved in
/home/user/.ssh/identity.
Your public key is:
2048 35
26130318755329891284958302706350910504570076165729387556005907351121793
75185456469393730695648181628956469432434215924236624002960022196112488
88433254676667471486307169774799352608961378925300986011609204630148630
77458164984026266122043631540839590088666265791273820044417158351184938
90674566793365767373714026218773604283910083280504538393226697370418622
86923616634472994624669328811484540034684239132105381434342745738547010
97006725154022281559410683819479264141392952511594709189136187563477949
18323602576628583339731055065081638975085599959494213693860488966132472
7339866673432140546650875521568274388968349883907 user@host
Your public key has been saved in
/home/user/.ssh/identity.pub
2. Kopiowanie klucza publicznego (identity.pub) na zdalny serwer i umieszczenie go w pliku

authorized.keys. W tym momencie, przy łaczeniu
˛ si˛e przez SSH z serwerem z komputera,
na którym zostały wygenerowane klucze, użytkownik powinien zostać poproszony o po-

danie wyrażenia przejściowego zamiast hasła.
3. Automatyczne podawanie hasła zabezpieczajacego˛ klucz prywatny przy użyciu programu
ssh-agent
Uruchomienie programu:
$ eval ‘ssh-agent‘
Agent pid 10562
$
Dodanie klucza
$ ssh-add
Need passphrase for /home/user/.ssh/identity (user@host).
Enter passphrase:
Identity added: /home/user/.ssh/identity (user@host)
$
Od tego momentu agent SSH b˛edzie w imieniu użytkownika odpowiadał na zapytania

o wyrażenie przejściowe.
Oprócz wymienionych dotychczas zalet wynikajacych ˛ ze stosowania SSH jest jeszcze jedna
bardzo istotna. Mianowicie przy pomocy tego protokołu można przekierowywa ć lokalne numery
portów na inne na zdalnej maszynie. Możliwości jakie niesie ze soba˛ ten mechanizm sa˛ ogromne.
Przykładem może być możliwość korzystania z aplikacji graficznych, uruchamianych na serwe-
rze przy dopuszczonym łaczeniu
˛ si˛e z nim tylko i wyłacznie
˛ przy pomocy SSH. Użytkownik,
który chce uruchomić np. przegladark˛
˛ e WWW, środowisko programistyczne lub inny program,
korzystajacy
˛ z środowiska graficznego, wykonuje na swoim komputerze polecenie ssh -X <na-
zwa serwera>. Zakładamy, że sam pracuje w środowisku graficznym z uruchomionym serwerem
XWindows. Wówczas uruchomienie aplikacji na serwerze spowoduje, że lokalne połaczenie ˛ do
serwera XWindows sa˛ przekierowywane do serwera XWindows ale na loklanym komputerze
użytkownika. Tym samy, nie obniżajac ˛ poziomu zabezpiecze ń serwera mamy możliwość wyko-
rzystywania aplikacji na nim zgromadzonych. Co wi˛ecej – wszystkie dane sa˛ wysyłane przez
szyfrowane połaczenie
˛ SSH.
7.3.3. Usługi terminalowe systemów MS Windows

Remote Desktop Protocol podobnie jak SSH czy TELNET daje możliwość zdalnego dost˛epu do
serwera. O ile jednak opisane wcześniej protokoły służa˛ głównie do pracy z terminalami tek-
stowymi, to RDP jest wykorzystywany głównie w usługach Terminal Services systemów firmy
Microsoft. RDP służy do wirtualnego przenoszenia całego środowiska graficznego użytkownika
na lokalny komputer. Przykład konfiguracji klienta RDP przedstawia rysunek 7.5
Protokół RDP nie wprowadza dużego dodatkowego obciażenia ˛ dla lokalnego komputera.
W zasadzie zadaniem lokalnej maszyny jest tylko i wyłacznie
˛ obsługa aplikacji wyświetlajacej
˛
wyniki działania programów uruchomionych na serwerze. Ta cecha sprawia, że:
RDP idealnie nadaje si˛e do centralnego zarzadzania
˛ instalowanym oprogramowaniem,
daje możliwość wprowadzania oszcz˛edności w firmach na sprz˛ecie, gdyż użytkownicy
mniej wydajnych maszyn moga˛ uruchamiać duże aplikacje na serwerze,
Rysunek 7.5: Konfiguracja klienta RDP.
aplikacja, zainstalowana na serwerze Windows NT Terminal Server lub nast˛epnych wer-

sjach systemu Windows, może być wykorzystywana przez dowolnego użytkownika, który
ma aplikacj˛e klienta Terminal Services.
administrator musi dbać o uaktualnienia oprogramowania tylko na jednym komputerze.
Oczywiście wiele tych cech jest wspólnych dla RDP, SSH czy TELNET- a . O ile jednak wyżej
opisane protokoły były znane od dosyć dawna, to usługi terminalowe w systemach Windows ma-
ja˛ znacznie krótsza˛ histori˛e. W ostatnich latach stały si˛e nawet bardzo istotne w heterogenicznych
środowiskach sieciowych dzi˛eki programom takim jak:
rdesktop – pozwala klientom UNIX na łaczenie

˛ si˛e z serwerami Windows Terminal,
SAMBA – pozwalajaca
˛ udost˛epniać w zasoby systemów UNIX dla systemów Windows,
Citrix – komercyjne rozwiazania
˛ firmy Citrix identyczne z Windows Terminal Services,
choć wykorzystuja˛ one własny protokół ICA.
Przy ich wykorzystaniu każdy użytkownik może logować si˛e do zdalnego systemu Windows, tak
jakby to robił lokalnie. Serwer dla każdego połaczenia
˛ tworzy oddzielna˛ sesj˛e, a sesjami takimi
zarzadza
˛ niezależnie. Użytkownik może sesj˛e przerwać wylogowujac
˛ si˛e z serwera lub tylko od
sesji si˛e odłaczyć.
˛ Druga możliwość pozwala na późniejszy do niej powrót. W mi˛edzyczasie
wyglad˛ pulpitu użytkownika nie ulega zmianie.
146 7.4. Serwisy informacyjne
Opis protokołu
Firma Microsoft oparła implementacj˛e RDP o protokół wymiany danych mi˛edzy aplikacjami –
T.128. Jest on również znany jako T.SHARE. Standard został opracowany przez ITU-T. Pod adre-
sem http://www.rdesktop.org/docs/t128.zip i http://www.rdesktop.org/docs/t125.zip
można znaleźć dokumenty ITU-T o tym protokole. Oprócz tego, dodatkowych informacji można
szukać w dokumentach RFC905 i RFC2126.
Najważniejsza˛ cecha˛ rodziny protokołów T.120 jest możliwość przesyłu danych w kilku wir-
tualnych kanałach (do wykorzystania jest 64000 kanałów w jednym połaczeniu).
˛ Dane sa˛ w nich
transmitowane równolegle, a przy tym niezależnie. Dzi˛eki temu dane warstwy prezentacji sa˛
niezależne od informacji pochodzacych
˛ z portów szeregowych, klawiatury, myszy.
W wersji usług terminalowych udost˛epnionych wraz z Windows NT4.0 Server wszystkie
sesje były typu „punkt–punkt”. RDP jednak, jako rozszerzenie T.Share pozwala na sesje typu
multicast.
RDP został zaprojektowany w sposób pozwalajacy ˛ mu wykorzystywać protokoły takie jak
TCP/IP, NetBios, IPX do komunikacji. Czyni go to niezależnym od użytej technologii sieciowej
i pozwala na używanie w różnorodnych środowiskach. Dane pochodzace ˛ z aplikacji, przesyłane
przy pomocy RDP, sa˛ obsługiwane niemal identycznie jak inne programy nie korzystajace ˛ z RDP.
Jedynym dodatkiem jest stos tego protokołu. W stosie tym nast˛epuje podział danych na fragmen-
ty, przekierowanie do odpowiedniego kanału, szyfrowanie, podział danych na ramki i przesłanie
do protokołów warstw niższych. Przy odbiorze danych sekwencja wymienionych operacji od-
bywa si˛e w odwrotnej kolejności. W systemach Windows złożoność tego procesu ukryto przed
programistami udost˛epniajac ˛ im odpowiedniego typu API (ang. Application Programming Inte-
race).
Warto zwrócić uwag˛e na dwa elementy stosu RDP. Skład si˛e on z kilku cz˛eści. Każda z nich
jest odpowiedzialna za odr˛ebne funkcje. Najważniejsze z nich to:
MCSMUX – (ang. Multipoint Communication Service),
GCC – (ang. Generic Conference Control).
Oba elementy sa˛ cz˛eścia˛ rodziny standardów ITU-T T.120. MCS składa si˛e z dwóch takich stan-
dardów:
1. T.122 – definiuje serwisy,
2. T.125 – specyfikuje rodzaj protokołu transmisji danych.
MCSMUX kontroluje przypisania kanałów wirtualnych, ustawienia poziomu priorytetów, wiel-
kość wysyłanych segmentów danych. W zasadzie tworzy on abstrakcyjna˛ warstw˛e, która wiele
stosów RDP prezentuje jako jedna˛ całość z perspektywy GCC. GCC jest odpowiedzialne za
zarzadzanie
˛ kanałami. Pozwala na otwieranie nowych, kasowanie starych sesji oraz kontroluje
zasoby dostarczane przez MCS.
7.4. Serwisy informacyjne

Sieć Internet z cała˛ pewnościa˛ nie byłaby tak atrakcyjna dla użytkowników, gdyby nie zgro-
madzone w niej informacje i, co ważniejsze, możliwość łatwego dotarcia do nich. Oczywiście
możliwość wymiany danych np. poczty elektronicznej, plików jest dużym ułatwieniem w pracy,
bez którego dzisiaj trudno si˛e obejść.
Czasami jednak rozsyłanie tych samych plików do setek użytkowników lub opisywanie
pewnych rzeczy jest znacznie trudniejsze niż np. po prostu narysowanie ich. Oczywiście rysu-
nek trzeba zaprezentować innym użytkownikom sieci. Tu z pomoca˛ przychodzi protokół HTTP
(ang. Hypertext Transfer Protocol) oraz znana dobrze wszystkim usługa WWW (ang. World Wide
Web). Dzi˛eki nim oraz j˛ezykowi służacemu
˛ do tworzenia stron WWW – HTML (ang. Hypertext
Markup Language) użytkownicy moga˛ łatwo przedstawiać wyniki swoich prac, poglady, ˛ firmy
przedstawiać produkty itd. W zasadzie można powiedzieć, że rozwój sieci Internet w ostatnich
latach był motywowany przez rosnac ˛ a˛ popularność serwisów WWW oraz wykorzystywanie pro-
tokołu HTTP do przesyłania danych przez inne aplikacje niż tylko przegladarki
˛ stron WWW.
Oprócz HTTP, nieco wcześniej, powstał inny protokół NNTP (ang. Network News Transfer
Protocol). Dzi˛eki niemu użytkownicy moga˛ wymieniać poglady ˛ i opinie przy pomocy teksto-
wych wiadomości. Podobnie jak w przypadku WWW sa˛ one umieszczane na serwerach i czytane
przy pomocy programów–klientów.
7.4.1. Protokół HTTP

Zanim zostanie przedstawiony protokół HTTP należy przypomnieć, że pomi˛edzy nim a WWW
istnieje różnica i nie sa˛ to dwa tożsame poj˛ecia. WWW składa si˛e z trzech elementów: pro-
tokołu HTTP, j˛ezyka HTML i systemu nazewnictwa URI (ang. Uniform Resource Identifier).
Protokół HTTP jest używany do komunikacji mi˛edzy komponentami WWW, czyli np. przegla- ˛
darkami stron, serwerami proxy. Przy pomocy HTTP informacje sa˛ przesyłane w wielu różnych
formatach, j˛ezykach i kodowaniach znaków. Składnia wiadomości jest oparta o przedstawiony
wcześniej MIME i nie jest w żaden sposób interpretowana przez protokół.
Histori˛e rozwoju protokołu przedstawia tabela 7.4.1.
Data Wydarzenie
Marzec 1990 Laboratoria CERN przedstawiaja˛ dokument z opisem
WWW. Autorem jest jedna osoba Tim Berners–Lee.
Styczeń 1992 Powstaje specyfikacja HTTP/0.9
Luty 1992 Powstaje WWW i propozycja używania WAIS/X.500 do
wyszukiwania zasobów w sieci
Grudzień 1992 Propozycja o dodaniu MIME do HTTP
Luty 1993 Postanie UDI dla sieci
Marzec 1993 Pierwsza szkic specyfikacji HTTP/1.0
Czerwiec 1993 Specyfikacja HTML 1.0
Październik 1993 Specyfikacja URL
Listopad 1993 Druga szkic specyfikacji HTTP/1.0
Marzec 1994 Dodanie URI do WWW
Maj 1996 Standard HTTP/1.0 w RFC 1945
Styczeń 1997 Propozycja standardu HTTP/1.1 (RFC 2068)
Czerwiec 1999 Szkic standardu HTTP/1.1 (RFC 2616)
2001 Formalny standard HTTP/1.1
Tabela 7.2: Rozwój protokołu HTTP
Z tabeli tej widać, że protokół ma stosunkowo krótka˛ histori˛e rozwoju. Mimo to we współ-
czesnych sieciach odgrywa on kluczowa˛ rol˛e.
Zalety protokołu
Generalnie rzecz biorac˛ HTTP jest protokołem bardzo prostym. Mimo to, jest bardzo uniwersal-
ny. Jego główne cechy to:
używanie URI do identyfikacji zasobów w sieci,
stosowanie mechanizmu „zapytanie–odpowiedź” przy wymianie danych,
brak nawiazywania
˛ sesji mi˛edzy klientem a serwerem,
zawieranie informacji o zasobach, które moga˛ być użyte na różne sposoby, .
Oczywiście za tymi czterema punktami kryje si˛e nieco bardziej skomplikowany mechanizm.
URI pozwala na umieszczenie zasobu (pliku) gdziekolwiek w sieci Internet. Separuje jednocze-
śnie nazw˛e od rodzaju zasobu, który si˛e pod nia˛ kryje. W zasadzie, zasób może mie ć nazw˛e przy-
dzielona˛ na zawsze, co nie oznacza, że jego zawartość i sposób reprezentacji nie może w tym
czasie ulec zmianie. Z punktu widzenia protokołu URI jest sformatowanym ciagiem ˛ znaków.
Można powiedzieć, że URI wskazuje na zasób, niezależnie jakiego typu i niezależnie w jakim
miejscu w sieci si˛e znajduje. W tym sensie URI jest kombinacja˛ URL (ang. Uniform Resource
Locator) i URN (ang. Uniform Resource Name). Bardziej znanym jest URL. Powiazanie ˛ mi˛edzy
tymi trzema mechanizmami lokalizacji zasobów jest nast˛epujace: ˛ jeśli zasób X został umiesz-
czony pod adresem www.foo.com/X i adresem www.companyx.com/pub/X to sa˛ to dwa adresy
URL. Każdy z nich jest URI zasobu X. URL w zwiazku ˛ z tym wskazuje na położenie kopii zaso-
bu. Jeżeli zasobem X jest ksiażka
˛ o nadanym numerze ISBN (ang. International Society of Book
Numbers) to jej URN jest właśnie ten numer.
Adresy URI
Adres URI jest uważany za bezwzgl˛edny, jeśli ciag

˛ znaków, który go reprezentuje, zaczyna si˛e
od tzw. schematu i dalej znaków reprezentujacych˛ zasób osiagalny
˛ w sieci przy pomocy tego
schematu. Schemat to nic innego jak wskazanie protokołu, który ma być użyty do pobrania
zasobu. Pierwsza specyfikacja HTTP/0.9 uwzgl˛edniała schematy: file, news, http, telnet, gopher.
Mimo, że określenie protokołu wskazuje wyraźnie jego nazw˛e to, do pobrania zasobu moga˛ by ć
również użyte inne protokoły. Typowe pobranie strony HTML z sieci powoduje skorzystanie
z systemu DNS do odnalezienia numeru IP serwera i z protokołu TCP do nawiazania ˛ z nim
sesji. Najbardziej znanym schematem jest HTTP.
Każdy z protokołów ma inna˛ składni˛e i mechanizm nazywania zasobów. Poprzez oddziele-
nie protokołu i ciagu
˛ znaków lokalizujacego
˛ zasób, mechanizm nazywania w WWW pozwala na
pobieranie tego samego pliku przy pomocy różnych protokołów. Mechanizm ten był bardzo po-
trzebny i cz˛esto wykorzystywany w poczatkowych
˛ czasach funkcjonowania WWW. Dzi˛eki temu
również WWW stało si˛e tak uniwersalnym interfejsem do pobierania zasobów, które zazwyczaj
sa˛ tylko dost˛epne przez np. FTP. Przykładem wykorzystania tego jest rtsp://clips.foo.com/audio/X
lub telnet://ox.mycompany.com.pl. Kiedy przegladarka ˛ spotyka si˛e z takim odwołaniem do
zasobu, interpretuje rodzaj protokołu do pierwszego wystapienia
˛ znaku ":" a nast˛epnie uruchamia
połaczenie
˛ przy jego pomocy – RTSP (ang. Real Time Streaming Protocol) lub TELNET.
Transfer danych
Jak już zostało wspomniane, protokół HTTP jest protokołem bezstanowym do wymiany danych
mi˛edzy klientem i serwerem. Cała komunikacja jest oparta o mechanizm „zapytanie – odpo-
wiedź”. Zapytanie wysłane przez klienta do serwera nie musi być odebrane przez oryginalny
serwer, do którego było kierowane. Może je obsłużyć dowolny serwer posiadajacy ˛ żadany
˛ za-
sób lub np. serwer proxy. Dla klienta jest to zupełnie niewidoczne. Serwer odbierajacy ˛ zapytanie
odsyła odpowiedź.
Protokół HTTP specyfikuje kilka metod, których może użyć klient do pobierania, modyfika-
cji, tworzenia i usuwania zasobu. Sa˛ to:
Metody zdefiniowane w HTTP/1.0
GET – najpopularniejsza metoda pobierania zasobów z serwera. Wywołana do zaso-
bu wyspecyfikowanego w URI powoduje, że serwer zwraca jego aktualna˛ zawartość.
Odpowiedź serwera jest zwracana do klienta, który wysłał zapytanie. Jeżeli w URI,
jako zasób, zostanie wyspecyfikowany program, serwer zwróci wynik jego wykona-
nia. Metoda ta jest uznawana za bezpieczna˛ gdyż nie modyfikuje zasobów. Może za-
wierać parametry, np. GET~http://www.altavista.com/cgi-bin/query?q=aqq123.
Zapytanie to zostało wysłane do programu query z parametrem aqq123 zlokalizowa-
nego pod adresem URI http://www.altavista.com/cgi-bin/. Metoda GET może
również zawierać pola modyfikujace ˛ zapytanie, np. If-Modified-Since. Zapytanie
metody GET, poza wyspecyfikowaniem zasobu i ewentualnych nagłówków modyfi-
kujacych,
˛ nie posiada żadnej treści. Jeśli taka jest, to serwer ja˛ ignoruje.
HEAD – metoda służy do pobierania metadanych o zasobie. Dane zwracane przez
serwer sa˛ takie same, jak np. w przypadku metody GET – tyle, że bez „zawartości”
zasobu. Metoda jest stosowana przez serwery proxy do sprawdzania aktualności za-
pami˛etanych danych,
POST – w przeciwieństwie do GET i HEAD, ta metoda służy do uaktualniania zawar-
tości zasobu. Dane w zapytaniu skierowanego do serwera ta˛ metoda˛ sa˛ nowa˛ treścia˛
wyspecyfikowanego zasobu. Serwer może, ale nie musi dokonać aktualizacji; zależy
to od jego konfiguracji. Cz˛eść danych może być zabezpieczona przed tego typu ope-
racjami, a te, które moga˛ być modyfikowane, wymagaja˛ najcz˛eściej autoryzacji ze
strony użytkownika, który dane wysłał. Cz˛estym zastosowaniem metody POST jest
wysyłanie danych, jako wejściowych, do programu na serwerze. Może to być np.
program „publikujacy”
˛ wiadomości nadsyłane do forum dyskusyjnego na stronach
WWW. Wymaganym nagłówkiem przy metodzie POST jest Content-Length. Dzi˛eki
niemu serwer wie, kiedy otrzymał cała˛ wiadomość. Jeżeli serwer pomyślnie przetwo-
rzy nadesłane dane, to odsyła tego potwierdzenie. W przypadku danych nadesłanych
do programu serwer odpowiada wynikami, jakie wygenerował program.
Oczywiście metoda GET też może być wykorzystywana do wysyłania danych do ser-
wera. Jednak mi˛edzy GET i POST istnieje subtelna różnica. W pierwszym przypadku
parametry sa˛ przekazywane w URI (tak jak przykładzie wyżej). W drugim nagłówek
wyglada˛ mniej wi˛ecej tak:
POST /query.cgi HTTP/1.0
Content-Length: 8
CRLF
q aqq123
Jeżeli użytkownik łaczy

˛ si˛e przez serwer proxy, to zostanie zalogowany cały URI,
a niektóre serwery ograniczaja˛ maksymalna˛ liczb˛e znaków w nim przesyłanych. Me-
toda˛ POST można wtedy rozwiazać ˛ problem przesłania długiego URI do serwera.
Metody implementowane w niektórych wersjach HTTP/1.0
PUT – metoda działa podobnie jak POST w sensie modyfikowania zasobów wyspe-
cyfikowanych w URI. Jednak jeżeli podanego zasobu nie ma, to jest on tworzony.
Jeżeli już istnieje, to jest modyfikowany. Metoda nie była oficjalnie zdefiniowana
w HTTP/1.0.
DELETE – metoda służy do usuwania zasobu. Serwer odbierajacy ˛ komunikat z ta˛
metoda˛ może odpowiedzieć klientowi informacja˛ o pomyślnym usuni˛eciu ale może
też wykonać ta˛ operacj˛e w rzeczywistości później. Druga˛ możliwościa˛ jest oczywi-
ście natychmiastowe usuni˛ecie wskazanego zasobu. Powodem, dla którego serwer
może zachować si˛e dwojako, jest danie mu możliwości wyboru jak i kiedy zostanie
usuni˛ety zasób oraz szybszego zamkni˛ecia połaczenia
˛ z klientem bez utrzymywania
go do czasu zakończenia operacji.
LINK i UNLINK – metody pozwalaja˛ na tworzenie lub usuwanie powiaza ˛ ń mi˛edzy
wskazanym w URI zasobem a innymi zasobami. Po ich utworzeniu, nast˛epne odwo-
łania do zasobu moga˛ być kierowane przez wskazanie URI właśnie dla powiazania. ˛
Metody nie były implementowane w HTTP/1.0 mimo, że specyfikacja je uwzgl˛ed-
niała. W HTTP/1.1 zostały usuni˛ete.
Zasobem może być obiekt, serwis lub zbiór dobrze identyfikowalnych elementów. Jeżeli klient
wyśle do serwera zapytanie:
GET /index.html HTTP/1.0
to /index.html identyfikuje zasób, o który klient pyta metoda˛ GET. Numer wersji używa-
nego przez klienta protokołu jest potrzebny serwerowi do określenia możliwości używania opcji
oferowanych przez HTTP u pytajacego.
˛ Ogólnie, każde zapytanie składa si˛e z metody, której
chce użyć klient, adresu URI, numeru wersji protokołu oraz pól opcjonalnych. Serwer po prze-
tworzeniu zapytania odsyła np. taka˛ odpowiedź:
HTTP/1.0 200 OK
Date: Tue, 5 Aug 2003 15:01:05 GMT
Last-Modified: Mon, 4 Aug 2003 10:05:12 GMT
Content-Length: 3000
.....
<3000 bajtów aktualnej zawartości /index.html>
Odpowiedź serwera składa si˛e z :

numeru kodu odpowiedzi, mówiacego˛ o sukcesie lub bł˛edzie,
przyczyny powstania takiej odpowiedzi,
opcjonalnych nagłówków,
opcjonalnej zawartości żadanego
˛ zasobu.
W zaprezentowanym przykładzie oprócz wymaganych informacji zostały dodane jeszcze po-

la dodatkowe informujace ˛ o dacie ostatniej modyfikacji zasobu oraz jego wielkości. Pola te
nie zawsze maja˛ charakter tylko informacyjny. Klient może, oprócz przedstawionego zapytania,
w opcjonalnych nagłówkach podać metod˛e, która ma być zastosowana do zasobu przy spełnie-
niu określonych warunków. Na przykład, klient może nie chcieć odpowiedzi od serwera, jeżeli
żadany
˛ dokument nie był modyfikowany od ostatniego czasu, kiedy był przez niego pobrany.
Serwer traktuje zasoby troch˛e jak „czarne skrzynki”. Najcz˛eściej taka˛ skrzynka˛ jest plik ze
swoja˛ zawartościa,˛ która˛ serwer czyta i wysyła w odpowiedzi klientowi. Dzi˛eki takiemu podej-
ściu – nie interpretowaniu treści zasobu, a tylko sprawdzaniu treści zapytania – serwer może
dla tego samego zasobu udzielać różnych odpowiedzi w zależności od rodzaju zapytania, czasu
w którym serwer je otrzymał, zmian jakie wprowadzono do zasobu.
W praktyce rola serwera i klienta jest bardzo cz˛esto wymienna. W sieci funkcjonuje całe
mnóstwo serwisów i urzadzeń˛ zdolnych obsługiwać zapytania kierowane przez programy użyt-
kowników. Obecność w sieci serwerów proxy, różnego rodzaju bram, tuneli nie wpływa na pod-
stawowy sposób, w jaki HTTP wymienia informacj˛e mi˛edzy serwerem a klientem. Serwery pro-
xy pozwalaja˛ na łatwe dotarcie do informacji przez użytkownika bez generowania nadmiernego
ruchu w sieci Internet i obciażaniu
˛ serwerów źródłowych. Natomiast, użytkownikowi ko ńcowem
uzapewnia to wi˛ekszy komfort pracy.
Połaczenia
˛ HTTP
Z punktu widzenia komunikacji w sieci, HTTP jest protokołem poziomu aplikacji, używa pro-
tokołów warstw niższych (w rzeczywistości tylko jednego – TCP). Ponieważ nie da si˛e wyge-
nerować odpowiedzi serwera dopóki nie otrzyma on zapytania od klienta, dlatego też kierunek
zapytań zawsze zaczyna si˛e od klienta do serwera. Nast˛epnie wysyłane sa˛ odpowiedzi. Każda
taka wymiana komunikatów jest traktowana przez serwer zupełnie oddzielnie. Protokół HTTP
nie posiada mechanizmów, które potrafiłyby przenosić informacj˛e o wcześniejszych odwoła-
niach klienta do serwera i jego odpowiedziach. Z tego punktu widzenia HTTP jest protokołem
bezstanowym i nie zarzadza
˛ sesjami.
Powód, dla którego postanowiono tak zrobić, jest bardzo prosty. W czasach powstawania
WWW tworzono jeszcze kilka innych, konkurencyjnych systemów. Wszystkie one miały za-
pewnić dost˛ep do dużych zasobów w Internecie. Gdyby dodać do protokołu przechowywanie
informacji o każdej sesji, to mogłoby si˛e okazać, że serwery musza˛ przechowywać duże zbiory
danych o swoich użytkownikach. WWW tym samym stałby si˛e rozwiazaniem ˛ słabo skalowal-
nym.
Nie znaczy to, że serwery, przegladarki
˛ klientów lub inne aplikacje korzystajace
˛ z HTTP do
wymiany danych nie zarzadzaj˛ a˛ sesjami. Serwer WWW może zapami˛etywać adresy IP klientów,
którzy pobierali z niego dane, jak również inne informacje, które klient wysyła w nagłówkach.
Dzieje si˛e to jednak na poziomie oprogramowania serwera i klienta. Problem utrzymywania se-
sji zaczał˛ być bardzo odczuwalny, gdy serwis WWW musiał przechowywać jakieś informacje
o wcześniejszych odwołaniach, np. sklepy internetowe, banki elektroniczne, itd. Rozwiazaniem
˛
najcz˛eściej stosowanym sa˛ ciasteczka (ang. cookies). Przy każdym wysyłaniu zapytania do ser-
wera, aplikacja użytkownika dołacza ˛ ciasteczko z informacjami o nim.
Problem, jaki niesie za soba˛ model wymiany wiadomości w HTTP, jest zwiazany ˛ z obciaże-
˛
niem, którego nie generuje ten protokół jako taki, ale TCP. Jak wiemy, TCP potrzebuje wymiany
kilku pakietów do otwarcia sesji. HTTP może przesyłać swoje dane dopiero po otwarciu se-
sji TCP. Użytkownicy wykorzystujacy ˛ WWW bardzo cz˛esto po odebraniu odpowiedzi serwera
zmieniaja˛ go na inny. Tak si˛e dzieje np. gdy korzystamy z wyszukiwarek internetowych. TCP
nie zamyka od razu połaczenia
˛ po stronie serwera, a system operacyjny użytkownika nie wysyła
do niego informacji, że sesja nie b˛edzie już używana. Tym sposobem zarówno klient jak i serwer
moga˛ mieć spora˛ liczb˛e otwartych, nieużywanych sesji TCP. Wbrew temu co może si˛e wydawa ć,
zmniejszenie czasu nieaktywności sesji przed jej zamkni˛eciem nie jest rozwiazaniem.
˛ Opóźnie-
nia w sieci maja˛ charakter losowy i cz˛esto dane docieraja˛ w różnym czasie do odbiorcy. Jeżeli
czas nieaktywności b˛edzie zbyt krótki, sesja b˛edzie zamkni˛eta przed odebraniem danych. Użyt-
kownik wówczas b˛edzie otwierał nowa˛ sesj˛e, która znowu po chwili b˛edzie zamkni˛eta. Serwer
b˛edzie obciażany
˛ samymi operacjami zamykania/otwierania sesji. Czas oczekiwania użytkow-
nika na odpowiedź serwera b˛edzie wydłużany o czas potrzebny na zestawienie sesji TCP, co
czasami może trwać kilka sekund. Otwieranie i zamykanie sesji jest w sumie najbardziej kosz-
towna˛ operacja˛ dla serwera. Poza tym w sieci pojawia si˛e ogromna liczba krótkich pakietów IP.
Zwi˛ekszaja˛ one jej obciażenie
˛ zmniejszajac
˛ tym samym szans˛e na przesłanie wi˛ekszej liczby
danych. Sytuacja ta jest dość cz˛esto spotykana w sieciach.
Najnowsza specyfikacja HTTP/1.1 pozwala na utrzymywanie „sesji HTTP” mi˛edzy przegla- ˛
darka˛ a serwerem. Niektóre implementacje HTTP/1.0 pozwalały na używanie nagłówka Keep-Alive.
W HTTP/1.1 zostało to przekształcone do tzw. stałego połaczenia ˛ (ang. persistent connection).
Mechanizm ten pozwala klientowi na poinformowaniu serwera, że jest zainteresowany utrzyma-
niem stałego połaczenia
˛ z nim, poza pojedyncza˛ wymian˛e wiadomości. Należy pami˛etać, że ta
wymiana może składać si˛e z kilkunastu ramek TCP. W przypadku HTTP/1.0 mimo to istnieje
problem określenia, jak długo połaczenie
˛ ma być utrzymywane, gdy serwer odsyła dynamicz-
nie generowana˛ odpowiedź np. przez skrypt. Nie zawiera ona wówczas nagłówka podajacego ˛
jej wielkość. Klient może jedynie stwierdzić, że otrzymał całość gdy serwer zamyka połaczenie.
˛
Na szcz˛eście, poprzez rozszerzenia nagłówka HTTP, serwer może określać jak długo połaczenie˛
b˛edzie utrzymywane po otrzymaniu ostatniego zapytania. Może również określić maksymalna˛
liczb˛e zapytań, które klient może wysłać w danym połaczeniu.
˛
Metadane w HTTP
Metadane sa˛ informacjami zwiazanymi

˛ z przedmiotem, którego dotycza,˛ ale nie sa˛ jego cz˛e ścia.˛
W przypadku HTTP metadane sa˛ przesyłane w nagłówkach. Oczywiście nie do każdego zasobu
da si˛e takie metadane stworzyć, np. w przypadku dynamicznie generowanych odpowiedzi ser-
wer nie umieszcza informacji o jej wielkości gdyż obliczenie tego wprowadzałoby dodatkowe
opóźnienie. Należy jednak pami˛etać, że takie dane maja˛ charakter nie tylko informacyjny. Cz˛esto
moga˛ one istotnie zmienić odpowiedzi serwera, kolejne zapytania klienta.
Najcz˛eściej wykorzystywanymi informacjami sa: ˛
rodzaj kodowania,
dane mówiace, ˛ jak duży jest zasób pobierany przez klienta. Dzi˛eki temu może si˛e on łatwo
zorientować, kiedy otrzymał cała˛ odpowiedź,
czas ostatniej modyfikacji żadanego
˛ zasobu. Informacja ta jest bardzo ważna dla serwerów
cache jak i przegladarek
˛ WWW. Posiadajac ˛ ja˛ sa˛ w stanie stwierdzić, czy kopia która˛ ew.
już maja˛ jest aktualna, czy też należy pobrać zasób jeszcze raz.
7.4.2. Usługa Usenet news

Network News Transfer Protocol – NNTP służy do transmisji artykułów zwiazanych ˛ z „elektro-
nicznymi grupami” usługi news. Programy klienckie użytkowników wykorzystuja˛ ten protokół
do komunikacji z lokalnymi serwerami news a serwery do wymiany wiadomości mi˛edzy soba.˛
Usługa news służy do wymiany wiadomości mi˛edzy użytkownikami, podobnie jak poczta
elektroniczna. Jednak mi˛edzy tymi dwoma serwisami istnieja˛ zasadnicze różnice. Poczta elek-
troniczna służy do wymiany listów e-mail mi˛edzy dwoma osobami lub w kr˛egu niedużej grupy
ludzi. Przykładem może być firma, która może utworzyć list˛e e-mailowa˛ zwiazan ˛ a˛ z danym te-
matem. Użytkownicy zainteresowani otrzymywaniem wiadomości z tej listy moga˛ si˛e na nia˛
zapisać. Pierwsza niedogodność płynaca
˛ z tego rozwiazania ˛ to wysyłanie oddzielnej kopii tego
samego listu do każdej z zapisanych osób. Zwi˛eksza to niepotrzebnie obciażenie ˛ serwera i sie-
ci. Druga, ważniejsza, to sposób zarzadzania
˛ lista.˛ Jeśli nie jest automatyczny, to administrator
listy musi r˛ecznie dodawać lub usuwać użytkowników. Oczywiście lista˛ może zarzadzać ˛ pro-
gram, który odbiera listy kierowane na specjalny adres. Nie likwiduje to jednak problemu do
końca, zwłaszcza gdy użytkownik zapomni zmienić swój adres e-mail na liście zanim zmieni
go w rzeczywistości. Wówczas serwer b˛edzie próbował wysyłać listy pod nieistniejace ˛ adresy,
a lista zapisanych osób b˛edzie rosła.
Opisane problemy staja˛ si˛e ogromne w dużej skali. Dlatego też w 1979 został opracowany
system USENET. W 1983 powstał standard, który dokładnie go określa.
Kluczowe dla systemu jest założenie o utrzymywaniu centralnej bazy danych wiadomości
zamiast oddzielnych kopii dla każdego zapisanego do systemu użytkownika. Baza składa si˛e ze
zbioru tzw. grup wiadomości (ang. newsgroups). Każda z nich jest zwiazana ˛ z zapisana˛ dla niej
lista˛ wiadomości. Nazwa grupy jest zwiazana
˛ z hierarchia,˛ w której została założona (system
podobny do DNS), np. comp.unix.databases. System bazy artykułów oferuje do nich do-
st˛ep, indeksowanie, usuwanie przestarzałych wiadomości, śledzenie powiazań ˛ mi˛edzy artykuła-
mi. Administrator serwera news może ustalić polityk˛e określajac ˛ a˛ maksymalny „wiek” artykułu.
Po jego osiagni˛
˛ eciu system usuwa go.
Podobnie jak w przypadku listu e-mail, artykuł zawiera szereg nagłówków:
adres e-mail autora,
temat wiadomości,
czas utworzenia,
liczb˛e linii tekstu,
identyfikator,
nazwy innych grup news, do których został wysłany.
Jeden centralny serwer news mógłby wprawdzie teoretycznie obsługiwać wszystkie grupy
wiadomości na całym świecie oraz wszystkich użytkowników korzystajacych ˛ z tej usługi. Jednak
nietrudno si˛e domyśleć jaka byłaby jej jakość. Dlatego też artykuły sa˛ replikowane mi˛edzy ser-
werami news. Uczelnia może mieć swój serwer, który b˛edzie udost˛epniał artykuły z popularnych
grup dla studentów. Nie ma konieczności pobierania artykułów ze wszystkich grup dost˛epnych
w USENET-cie. Oprócz tego moga˛ tam być grupy tylko i wyłacznie ˛ dla studentów tej uczelni.
Serwer nie b˛edzie ich wysyłał do innych serwerów news.
Użytkownicy czytaja˛ i wysyłaja˛ artykuły przez programy, które komunikuja˛ si˛e z lokalnym
serwerem. Udost˛epnia on im interfejs do tworzenia i czytania wiadomości, pokazuje niezb˛edne
nagłówki, listy dost˛epnych artykułów w danej grupie. Poza tym wi˛ekszość takich programów
zapami˛etuje w lokalnych plikach, jakie wiadomości zostały już przeczytane oraz które grupy
news sa˛ przez użytkownika odwiedzane.
Grupy news sa˛ identyfikowane w sieci Internet przez nazw˛e, tak samo jak serwisy WWW.
Wi˛ekszość przegladarek
˛ internetowych pozwala na ich czytanie.
Protokół NNTP
NNTP został zaproponowany jako zast˛epstwo starego UUCP (ang. UNIX–to–UNIX Copy Proto-
col) w 1986 r.
Aplikacja, służaca
˛ do odczytywania artykułów z serwera news, otwiera połaczenie ˛ TCP z ser-
werem na porcie 119. Podobnie jak FTP i SMTP serwer zwraca trzycyfrowy kod, z opcjonalna˛
wiadomościa˛ tekstowa˛ do komend wydawanych przez klienta. W zależności od rodzaju odpo-
wiedzi może ona mieć jeszcze dodatkowe parametry. Numer i typ dodatkowych parametrów jest
dołaczany
˛ przez serwer do każdej odpowiedzi, co ułatwia klientowi ich interpretacj˛e. Podczas
przetwarzania komend serwer pami˛eta nazw˛e bieżacej ˛ grupy news oraz numer artykułu pobra-
nego przez klienta.
NNTP ma bogaty zbiór poleceń spełniajacych
˛ różne funkcje. Jednym ze zbiorów takich ko-
mend sa˛ polecenia dostarczajace˛ generalnych informacji o serwerze i dost˛epnych grupach news,
np.:
lista obsługiwanych przez serwer poleceń,
lista dost˛epnych grup wraz z informacja˛ o pierwszym i ostatnim artykule w każdej z nich
oraz informacja˛ o tym, czy użytkownicy moga˛ wysyłać artykuły na dana˛ grup˛e,
lista grup utworzonych od danej daty/czasu,
lista artykułów wysłanych w danej grupie od danej daty/czasu.
Dostarczanie informacji o zmianach w czasie pozwala aplikacjom użytkowników na odświeżanie
dost˛epnych dla nich list artykułów bez potrzeby przechowywania ich na serwerze. Inne zbiory
komend służa˛ do przemieszczania si˛e mi˛edzy grupami (identyfikowane sa˛ przez nazwy), mi˛edzy
artykułami, przejście od aktualnego do poprzedniego lub nast˛epnego artykułu. Oprócz tego sa˛
też komendy zwracajace ˛ tylko nagłówki artykułu albo jego całość. Za każdym razem artykuł jest
identyfikowany przez numer wiadomości albo numer w danej grupie news.
Oczywiście NNTP dostarcza również komend do tworzenia nowych artykułów. Użytkownik
może wysłać prośb˛e o wysłanie wiadomości. Jeżeli serwer odpowie pozytywnie, klient wysy-
ła jego treść podobnie jak w przypadku SMTP. Artykuł kończy si˛e pojedynczym znakiem "."
w ostatniej linii. W tym czasie serwer generuje unikalny identyfikator dla wiadomości i dodaje
ja˛ do listy artykułów danej grupy.
NNTP jest wyposażone w komend˛e służac ˛ a˛ do kopiowania wiadomości mi˛edzy serwerami.
Jest to chyba jedna z bardziej istotnych komend w NNTP. Dzi˛eki niej artykuły sa˛ wymieniane
mi˛edzy serwerami a użytkownicy korzystajacy ˛ z różnych serwerów moga˛ je czyta ć. Serwery nie
udost˛epniaja˛ swojej bazy artykułów komukolwiek, a tylko wyznaczonym w konfiguracji innym
serwerom news (administratorzy usługi news cz˛esto nazywaja˛ to rozwiazanie ˛ feed-em). Serwe-
ry wymieniajace ˛ mi˛edzy soba˛ feed- a sprawdzaja,˛ przed skopiowaniem wiadomości o danym
identyfikatorze, czy nie maja˛ jej już w bazie. Jeżeli tak, to nie kopiuja˛ jej ponownie. Poza tym,
serwery w ramach feed-u moga˛ sobie udost˛epniać tylko artykuły pojawiajace ˛ si˛e na określonych
w konfiguracji grupach. Dzi˛eki temu małe firmowe serwery moga˛ utrzymywać grupy news inte-
resujace
˛ ich pracowników bez potrzeby kopiowania dziennie kilku terabajtów danych grup typu
alt.binaries. Szybkość kopiowania artykułów mi˛edzy serwerami jest bardzo różna. Czasami mo-
że si˛e zdarzyć, że serwer otrzyma dana˛ wiadomość po kilkudziesi˛eciu godzinach. Zależy to od
obciażenia
˛ łacza
˛ do tego serwera jak i jego samego.
Należy również pami˛etać, że każda grupa wiadomości rzadzi
˛ si˛e swoimi, cz˛esto różnymi,
prawami. Wi˛ekszość z nich posiada swoje archiwum lub stron˛e WWW, gdzie jest publikowany
regulamin pisania artykułów do danej grupy. Regulaminu tego powinni przestrzega ć autorzy
artykułów tej grupy.
7.5. Synchronizacja czasu

Usługa synchronizacji czasu mi˛edzy komputerami w sieci jest bardzo istotna. Przyczyn tego jest
wiele. Wymaga tego poprawne działanie niektórych usług, np. NIS, autoryzacja na podstawie
certyfikatów, automatyczne pobieranie z sieci uaktualnień baz wirusów czy też w końcu możli-
wość śledzenia kolejności wpisów logów zbieranych z różnych urzadze
˛ ń.
Usługi tego typu sa˛ dostarczane przez różnego typu serwisy sieciowe, z których standardem
jest opisany poniżej protokół NTP (ang. Network Time Protocol).
7.5.1. NTP
Wi˛ekszość współczesnych systemów operacyjnych wspiera trzecia˛ wersj˛e protokołu NTP. Jest
ona opisana w RFC1305. W tej chwili, czwarta wersja jest w fazie rozwojowej, choć można już
jej używać. Wersja uproszczona SNTP (ang. Simple NTP) jest opisana w RFC2030.
Oprogramowanie potrzebne do uruchomienia NTP jest dost˛epne dla wszystkich na zasadach
Open Source ze strony m.in. http://www.eecis.udel.edu/~mills/ntp. Szczegółowa doku-
mentacja pozwala na samodzielna˛ konfiguracj˛e w zależności od potrzeb. Poza tym ilość dar-
mowego oprogramowania dost˛epnego w sieci Internet powinna zadowolić wi˛ekszość użytkow-
ników. Dotyczy to zwłaszcza systemu Windows, gdyż w przypadku systemów UNIX wszelkie
narz˛edzia, niezb˛edne do uruchomienia czy monitorowania tej usługi sa˛ dostarczane najcz˛e ściej
wraz z systemem (czasem łacznie˛ ze źródłami),
Protokół NTP służy do synchronizacji czasu mi˛edzy serwerami, klientami a serwerami, ser-
werami a wzorcami czasu. W sieciach LAN zapewnia on dokładność rz˛edu kilku milisekund,
w sieciach WAN sa˛ to dziesiatki ˛ milisekund w stosunku do UTC (ang. Coordinated Univer-
sal Time). Zasada działania NTP jest dosyć prosta. Wszystkie urzadzenia
˛ korzystajace
˛ z usługi
synchronizacji za pomoca˛ tego protokołu, sa˛ przydzielone do jednej z czterech warstw określa-
jacej
˛ poziom w hierarchii źródeł synchronizacji czasu. Lub inaczej określajacej
˛ „odległość” od
wzorców czasu. Pogladowo˛ przedstawia to rysunek 7.6.
Na poziome pierwszym (ang. Stratum Zero lub reference clock) znajduja˛ si˛e ogólnie znane
i dost˛epne serwery czasu. Niektóre sa˛ używane przez siły zbrojne (np. US. Navy) i nie sa˛ do-
st˛epne dla użytkowników cywilnych. Komunikuja˛ si˛e one bezpośrednio z wzorcami czasu (ang.
Master Clock) znajdujacymi˛ si˛e mi˛edzy innymi w :
United States Naval Observatory (USNO);
National Institute of Standards and Technology (NIST);
w celu ewentualnej korekcji swoich cezowych wzorców. Na stronie domowej projektu moż-
na znaleźć tabel˛e z rekomendowanymi wzorcami czasu. Dodatkowo adresy serwerów czasu
156 7.5. Synchronizacja czasu
GPS
STRATUM ZERO
STRATUM ONE
STRATUM TWO
STRATUM THREE
Rysunek 7.6: Podział warstw w NTP.
pracujacych
˛ na poziomie Stratum One i Stratum Two można znaleźć pod adresami WWW:
http://www.eecis.udel.edu/~mills/ntp/clock1.htm oraz
http://www.eecis.udel.edu/~mills/ntp/clock2.htm. Udost˛epniaja˛ one publicznie usłu-
g˛e synchronizacji czasu. Natomiast wzorce czasu, z którymi one same si˛e synchronizuja,˛ podane
sa˛ w ich opisach.
Wzorcami czasu moga˛ być satelity systemu GPS (ang. Global Positioning System) oraz ze-
gary atomowe. W krajach europejskich zegary synchronizowane sa˛ także sygnałem DCF77 z na-
dajnika Mainflingen koło Frankfurtu nad Menem w Niemczech.
Źródła czasu pracujace
˛ na pierwszym poziomie hierarchii (Stratum 0) wyznaczaja˛ czas z do-
kładnościa˛ do nanosekund oraz dodatkowo moga˛ synchronizować si˛e mi˛edzy soba.˛ Najcz˛eściej
jednak synchronizuja˛ si˛e z wyznaczonym wzorcem czasu, uznanym za wiarygodny. W przy-
padku zagubienia sygnału synchronizacji z wyznaczonymi wzorcami czasu lub rezerwowymi
źródłami czasu pracujacymi
˛ w tej samej warstwie, serwery w wi˛ekszości przypadków przestaja˛
dystrybuować informacj˛e o dokładnym czasie. Wprawdzie maja˛ one wewn˛etrzne, bardzo dokład-
ne zegary, ale służa˛ im one w tym momencie raczej do podtrzymania ciagłości
˛ pracy układów
generacji czasu i daty, a później, po ponownym otrzymaniu sygnału synchronizacji z wyznaczo-
nych źródeł, szybkiego zsynchronizowania.
Źródła czasu, z którymi można synchronizować urzadzenia
˛ pracujace
˛ we własnej sieci przez
NTP, traktuja˛ jako wzorzec odniesienia, zegary pracujace
˛ w warstwie stratum zero, które dostar-
czaja˛ im informacj˛e o czasie uniwersalnym UTC. Taka˛ też informacj˛e przesyłaja˛ dalej.
Ważnym założeniem autorów protokółu była możliwość synchronizacji urzadzeń ˛ pracuja-
˛
cych w danym segmencie sieci z dowolnym serwerem znajdujacym ˛ si˛e poza nia˛ (np. w Euro-
pie sygnałem DCF77). Takie założenie jest rozsadne. ˛ Bezcelowe wydaje si˛e synchronizowanie
zegarów urzadzeń
˛ bez możliwości sprawdzenia poprawności wskazań z zewn˛etrznym, niezależ-
nym źródłem. Urzadzenia
˛ końcowe np. takie, z którymi już bezpośrednio komunikuja˛ si˛e stacje
robocze użytkowników oraz pozostałe serwery, obliczaja˛ przesuni˛ecie w stosunku do UTC na
podstawie informacji o strefie czasowej w jakiej si˛e znajduja,˛ informacjom zawartych w nagłów-
kach pakietu NTP, i rozsyłaja˛ informacj˛e o czasie lokalnym. Format przekazywania czasu jest
najcz˛eściej parametrem konfiguracyjnym i można go ustawiać w zależności od potrzeb. Protokół
NTP uwzgl˛ednia czas propagacji sygnałów w sieciach, czy też raczej pakietów.
Urzadzenia
˛ pracujace
˛ w warstwach niższych (Stratum Two, Three, Four) synchronizuja˛ si˛e
ze źródłami pracujacymi
˛ w warstwie położonej bezpośrednio nad nia.˛ Ograniczenie co do liczby
warstw, czy też inaczej odległości od wzorców czasu, wynikaja˛ z możliwości powstawania bł˛e-
dów w trakcie przesyłania informacji o czasie przez sieci oraz czasu potrzebnego na wzajemna˛
komunikacj˛e mi˛edzy urzadzeniami.
˛ Teoretycznie warstw może być 15, ale praktycznie stosuje
si˛e tylko 4.
Każdy klient NTP powinien określić najbliższy mu i najlepszy serwer udost˛epniajacy ˛ syn-
chronizacj˛e czasu. Nie zawsze jest to najlepszy rodzaj jego konfiguracji, chociażby ze wzgl˛edu
na możliwość awarii czy brak możliwości zsynchronizowania si˛e z serwerem, kiedy to lepiej jest
synchronizować dane urzadzenie
˛ z kilkoma źródłami (zalecane sa˛ co najmniej 3). Protokół NTP
sam dokona wyboru najlepszego rodzaju, na podstawie:
1. Tego, w której warstwie pracuje dane urzadzenie.
˛
2. Najmniejszego opóźnienia w komunikacji z danym urzadzeniem.˛
3. Zakładanej precyzji.
Istnieje kilka trybów konfiguracji klienta. Jeden z nich zakłada, że urzadzenie˛ b˛edzie syn-
chronizowało si˛e z wybranym wzorcem ale też samo b˛edzie pozwalało na synchronizacj˛e z nim.
Taki tryb pracy ma sens gdy chcemy np. mieć kilka redundantnych urzadzeń ˛ i gwarancj˛e, że
zawsze jakiekolwiek z nich b˛edzie dost˛epne. Drugi tryb powoduje odpytywanie przez klientów
serwera lub serwerów czasu; konfiguracja ta jest najcz˛eściej spotykana. Jej główna˛ wada˛ jest nie-
potrzebne generowanie ruchu w sieci i obciażanie
˛ serwera, natomiast zaleta˛ szybszy start procesu
klienta (bez czekania na komunikaty rozsyłane przez serwer). Kolejny tryb pracy klienta powo-
duje czekanie na rozsyłane co pewien czas komunikaty od serwera o aktualnym czasie. Niektóre
serwery pozwalaja˛ na rozsyłanie komunikatów typu multicast oprócz domyślnych komunikatów
broadcast.
Każdy z tych trybów pracy jest przystosowany do innych potrzeb. Pierwszy z nich ma na
pewno sens w dużych sieciach, gdzie dokładny czas jest istotny i konieczna jest gwarancja, że
zawsze b˛edzie dost˛epne jedno źródło czasu, z którym klienci b˛eda˛ mogli si˛e synchronizowa ć.
Dwa kolejne z wymienionych trybów sa˛ stosowane przez wi˛ekszość użytkowników a ich wybór
zależy wyłacznie
˛ od lokalnych potrzeb. Uwaga ta dotyczy wszystkich klientów NTP.
Ze wzgl˛edu na to, że dla niektórych usług synchronizacja czasu jest w rzeczywiści istotna,
NTP oferuje również mechanizmy zabezpieczajace ˛ przed modyfikowaniem wskaza ń zegarów
przez strony trzecie. Można określić z jakich sieci, adresów, itp. b˛eda˛ rozpatrywane pakiety przy
ustalaniu czasu i czy pakiety maja˛ także zawierać sumy kontrolne generowane przez algorytm
MD5 lub DES.
158 7.5. Synchronizacja czasu
Format pakietu, jaki jest przesyłany mi˛edzy synchronizujacymi

˛ si˛e maszynami przedstawia
rys. 7.7
0 2 5 8 15 23 31
Li VN Mode Stratum Pool Precision
Root Delay
Root Dispersion
Reference Identifier
Orginale Timestamp (64 kB)
Receive Timestamp (64 kB)
Transmit Timestamp (64 kB)
Extension Fields (64 kB)
Key ID
Message Digest (128 kB)
Rysunek 7.7: Nagłówek protokołu NTP.
7.5.2. Usługa DayTime

Zanim powstał protokół NTP, do synchronizacji czasu były używane dwa inne, prostsze, proto-
koły: Time Protocol i DayTime Protocol (DTP). Pozwalaja˛ one również na automatyczna˛ syn-
chronizacj˛e czasu mi˛edzy klientem a serwerem. W przeciwieństwie jednak do NTP, nie uwzgl˛ed-
niaja˛ one w żaden sposób opóźnień zwiazanych
˛ z przesyłaniem komunikatów przez sieć. Dlatego
też jedynym miejscem, gdzie moga˛ być stosowane, sa˛ sieci LAN. W innych przypadkach syn-
chronizacja przy użyciu tych protokołów może spowodować wskazywanie niewłaściwego czasu
w systemach komputerowych.
DTP zostało opisane w dokumencie RFC867. Daje możliwość komunikowania si˛e maszyn
synchronizujacych
˛ czas zarówno przy pomocy protokołu TCP jak i UDP. Serwer oczekuje na
połaczenia
˛ na porcie 13 TCP i 13 UDP. W obu przypadkach serwer po otrzymaniu zapytania
odsyła komunikat ze swoim aktualnym czasem. Informacja ta jest przesyłana jako ciag ˛ znaków
ASCII (podobnie jak w FTP czy SMTP). Format czasu nie jest ściśle zdefiniowany. Zalecane sa˛
dwa formaty przesyłania czasu, choć w istocie może on być dowolny:
1. <Dzień tygodnia, Dzień miesiaca,
˛ Rok, Strefa czasowa> – Tuesday, February 22, 1982
17:37:43-CEST
2. <dd mmm yy hh:mm:ss zzz> – 02 FEB 82 07:59:01 CEST
Ograniczenia dotycza˛ kodowania. Powinno to być ASCII ze znakami spacji, LF (ang. Line Feed),
CR (ang. Carriage Return).
7.6. Informacje o użytkownikach

Różnorodność oraz duża liczba serwisów wyst˛epujacych ˛ w sieciach cz˛esto sprawia, że użyt-
kownicy czuja˛ si˛e zagubieni i nie potrafia˛ wykorzystywać oferowanych im usług. Co gorsza,
najcz˛eściej nie chca˛ z nich korzystać. Każda nowa usługa to dla nich nowa nazwa użytkownika
z hasłem niewykorzystywanym w innych miejscach. W ten sposób powstaja˛ długie listy haseł
z nazwami użytkowników ukrywane pod klawiatura˛ na biurku lub przyklejone do monitora. Po-
ziom bezpieczeństwa, zamiast si˛e zwi˛ekszyć, zostaje obniżony. Z punktu widzenia administra-
tora, który takimi serwisami si˛e opiekuje, dbanie o uaktualnianie haseł w kilku miejscach jest
bardzo pracochłonne i również niewygodne.
Dlatego też pomyślano o systemach przechowujacych ˛ centralnie informacj˛e o użytkowniku.
Sa˛ one same w stanie stwierdzić, czy dana usługa jest dost˛epna dla użytkownika lub komputera.
Wystarczy im do tego ich konfiguracja. Administrator zajmujac ˛ si˛e tylko takim systemem może
poświ˛ecić wi˛ecej czasu na jego zabezpieczanie. Użytkownicy, dla których najcz˛e ściej taki system
jest niewidoczny, ch˛etniej i cz˛eściej korzystaja˛ z udost˛epnionych im serwisów.
Oczywiście istnieje niebezpieczeństwo kompromitacji takiego systemu i potrzeby wymiany
wszystkich haseł. Dlatego też, systemy przechowujace ˛ takie dane nie w każdym miejscu moga˛
być stosowane. Jednak w dużej liczbie przypadków sprawdzaja˛ si˛e one znakomicie; przykładem
moga˛ być sieci akademickie. Powielanie tych samych informacji o tysiacach ˛ studentów w każ-
dym z serwerów byłoby wysoce niewygodne i trudne w zarzadzaniu ˛ dla administratorów.
7.6.1. NIS
Network Information Service, znany wcześniej jako YP (ang. Yellow Pages), jest baza˛ umożli-
wiajac
˛ a˛ centralne zarzadzanie
˛ komputerami i siecia.˛ Został opracowany przez SUN Microsys-
tems. Baza zarzadza˛ ważnymi dla administratorów plikami konfiguracyjnymi. Pliki te zostaja˛
przekształcone ze standardowej postaci, znanej administratorom, do map. Mapy moga˛ by ć odpy-
tywane przez komputery w sieci. Oprócz tego w bazie znajduja˛ si˛e mapy utworzone przez NIS
i zwiazane
˛ z administracja˛ sieci:
/etc/ethers
/etc/hosts
/etc/networks
/etc/protocols
/etc/services
/etc/aliases
Zaleta˛ płynac˛ a˛ ze stosowania NIS jest to, że wszystkie pliki ważne z punktu widzenia ad-
ministratora sieci, moga˛ być zarzadzane
˛ przez jeden centralny serwer i dost˛epne dla wszystkich
stacji roboczych w danej podsieci. Do tego celu na wyznaczonej maszynie działa proces serwera.
Pozostałe maszyny sa˛ wyposażone w oprogramowanie klienta.
Serwer NIS i jego klienci tworza˛ domen˛ e NIS. Jest ona identyfikowana przez nazw˛e. Musi
ona być unikalna w sieci, tak samo jak domena DNS. Firma SUN zaleca nawet nadawanie tych
samych nazw w celu uproszczenia administracji. Należy jednak pami˛etać, że sa˛ to dwa różne
poj˛ecia.
Nazwa domeny jest wykorzystywana przez serwer NIS do tworzenia odpowiednich podkata-
logów. Znajduja˛ si˛e w nich mapy dla danej domeny NIS.
160 7.6. Informacje o użytkownikach
Protokół i programy NIS sa˛ powszechnie dost˛epne w wi˛ekszości systemów komputerowych,

również w systemie Linux. Powszechne sa˛ również nazwy programów klienta i serwera. Do lo-
kalizowania serwera NIS w wi˛ekszości systemów UNIX służy program ypbind. Rozgłasza on
w danej podsieci żadanie
˛ dost˛epu do serwera NIS, korzystajac ˛ z nazwy domeny. W kolejnych
połaczeniach
˛ klient komunikuje si˛e z tym serwerem, który jako pierwszy udzielił odpowiedzi.
Rozwiazanie
˛ to jest oparte na założeniu, że najmniej obciażony
˛ serwer udzieli odpowiedzi ja-
ko pierwszy, a tym samym nie b˛eda˛ powstawały przeciażenia˛ serwerów. Aby zapobiec przy-
padkowej komunikacji ze złym serwerem (lub skonfigurowanym przez włamywacza), systemy
pozwalaja˛ na jawne określenie nazwy serwera NIS.
NIS może być alternatywa˛ dla DNS, choć w rzeczywistości to DNS jest podstawowym sys-
temem nazw a NIS działa równolegle wspomagajac ˛ proces administracji siecia.˛ Nazwy kompu-
terów moga˛ być tłumaczone na adresy DNS lub NIS dzi˛eki tablicy komputerów. O kolejności
wykorzystywania systemu nazewnictwa decyduje plik nsswitch.conf.
Nazwa pliku pochodzi od Name Service Switch. Od jego zawartości zależy też działanie
innych baz danych zarzadzanych
˛ przez NIS. Przedstawia to poniższy fragment zwartości tego
pliku:
hosts: dns nis files

networks: nis [NOTFOUND=return] files
services: nis files
protocols: nis files
Pierwsza linia mówi, że do poszukiwania nazw maszyn najpierw b˛edzie wykorzystany DNS.
Gdy poszukiwanie si˛e nie powiedzie, to zostanie użyty NIS i wreszcie plik /etc/hosts. Dru-
gi wiersz definiuje sposób określania nazw sieci. B˛edzie do tego wykorzystywany NIS. Wpis
[NOTFOUND=return] zezwala na użycie pliku networks tylko w przypadku gdy nie działa NIS.
Jeżeli NIS działa i nie znajdzie nazwy sieci, poszukiwania zostana˛ przerwane.
NIS+
NIS+ jest systemem używanym jedynie przez system SUN Solaris. Jest to zupełnie nowe opro-
gramowanie, a nie nast˛epna wersja NIS. Do NIS zostały dodane nowe mechanizmy:
mechanizm bezpieczeństwa – NIS nie przeprowadza autoryzacji serwera ani klienta usłu-
gi. W NIS+ te mechanizmy sa˛ dost˛epne razem z szyfrowaniem algorytmem DES. NIS+
pozwala również na określenie różnych poziomów dost˛epu w ramach jednej domeny. NIS
pozwalał jedynie na ustawienie takiego samego poziomu dost˛epu dla wszystkich użytkow-
ników w domenie,
rozproszona architektura – NIS+ posiada podobnie jak DNS rozproszona,˛ hierarchiczna˛
baz˛e danych. Dzi˛eki temu może obsługiwać olbrzymia˛ przestrzeń nazw. Zorganizowana
w ten sposób baza jest również spójnie zarzadzana
˛ przez serwery NIS+. NIS ma struktur˛e
płaska,˛ wszystkie informacje pochodza˛ z jednego serwera a jego domeny nie moga˛ na
siebie „zachodzić”,
rozszerzone struktury danych – NIS+ z plików tekstowych buduje wielokolumnowe tablice
baz danych (NIS buduje tylko tablice dwukolumnowe). Wielokolumnowe tablice moga˛
przeszukiwane według wielu kryteriów.
NIS+ jest dużo lepszym systemem od NIS, mimo to nie jest tak popularnie wykorzystywany jak
NIS. NIS+ jest na pewno doskonałym narz˛edziem w dużych i wielkich sieciach. W małych sie-
ciach wykorzystujacych
˛ NIS jedynym argumentem za zmiana˛ NIS- a na NIS+ jest podniesienie
jej bezpieczeństwa. Niestety wiaże
˛ si˛e to z przejściem na inny system operacyjny, co nie zawsze
jest możliwe. Poza tym wi˛ekszość sieci jest chroniona przez systemy firewall a wewnatrz
˛ sieci
nie kładzie si˛e zbyt dużego nacisku na bezpieczeństwo.
7.6.2. LDAP
Lightweight Directory Access Protocol jest serwisem pozwalajacym ˛ na dost˛ep do usług katalo-
gowych. Opisuje go dokument RFC1777. W katalogach moga˛ być zgromadzone różnego rodzaju
informacje, również o użytkownikach. Dzi˛eki temu przy pomocy LDAP jest możliwe centralne
zarzadzanie
˛ użytkownikami dla dowolnej usługi, np. dost˛ep do kont pocztowych przy pomocy
protokołu IMAP lub POP3 bez zakładania tych kont fizycznie na serwerze, zarzadzanie ˛ cer-
tyfikatami elektronicznymi, dost˛ep do firmowej ksiażki˛ adresowej, itd. Usługi katalogowe sa˛
oferowane przez producentów systemów operacyjnych takich jak Microsoft czy Sun Microsys-
tems. Różne dystrybucje Linuxa korzystaja˛ z darmowej implementacji LDAP – OpenLDAP.
W przypadku systemów Windows LDAP jest znany raczej jako Active Directory, natomiast Sun
Microsystems rozpowszechnia swój produkt pod nazwa˛ SunONE Directory Server.
Jak już na wst˛epie zostało napisane, LDAP dostarcza tzw. usług katalogowych. Jest to cen-
tralna baza danych z informacjami o użytkownikach, grupach osób i wszelkiego innego typu
zasobach, które zostana˛ tam umieszczone. Jest to możliwe dzi˛eki dużej elastyczności, jaka˛ daje
LDAP przy tworzeniu takiej bazy. Nie ma jednego, ustalonego z góry, schematu, którego musi
si˛e trzymać administrator bazy LDAP. Może on ja˛ tworzyć zgodnie ze struktura˛ swojej firmy czy
organizacji.
Baza katalogów nie jest baza˛ relacyjna,˛ taka˛ jak np. MySQL. Jest ona przystosowana do
przeszukiwania, odczytywania, przegladania.
˛ Nie można w niej wykonywa ć skomplikowanych
transakcji, czy też korzystać z segmentów wycofania. W bazie LDAP bardzo nieefektywne sa˛
wykonania instrukcji zmieniajacych˛ duże bloki danych. Dlatego też nie można na usłudze kata-
logowej opierać takich serwisów, w których potrzebny jest system szybko zapisujacy ˛ duża˛ liczb˛e
wprowadzanych zmian, pozwalajacy ˛ na zawsze bezpieczne przeprowadzenie transakcji.
Każdy katalog w bazie ma swój treściwy opis oraz atrybuty pozwalajace ˛ na przeprowadzanie
zaawansowanych przeszukiwań w bazie katalogów. Rozmieszczenie katalogów w bazie oraz
jej konstrukcja sa˛ przystosowane do szybkiego dostarczania odpowiedzi przy przegladaniu ˛ oraz
przeszukiwaniu katalogów.
LDAP a usługi katalogowe
Usługi katalogowe można dostarczać na kilka sposobów. Stosowanie danej metody jest zależne
od rodzaju informacji, która ma być przechowywana, sposobie zabezpieczenia przed nieauto-
ryzowanym dost˛epem, sposobie przeszukiwania, uaktualniania. Niektóre usługi sa˛ lokalne, np.
finger w systemach UNIX. Inne z kolei sa˛ szeroko dost˛epne w Internecie. Dane w nich zgro-
madzone sa˛ zazwyczaj rozproszone na kilkudziesi˛eciu, kilkuset, tysiacach
˛ komputerów w sieci.
Komputery te współpracuja˛ ze soba˛ w celu lepszego dostarczania usługi użytkownikom. Ponadto
162 7.6. Informacje o użytkownikach
dane widziane przez użytkownika nie zależa˛ w takiej usłudze od jego miejsca położenia w sieci.
Bardzo dobrym przykładem takiego systemu jest DNS.
LDAP może dostarczać usługi katalogowe zarówno lokalnie, jak i globalnie w ramach firmy
z wieloma oddziałami. Struktura informacji wykorzystywana przez LDAP opiera si˛e o zbio-
ry atrybutów. Każdy taki zbiór musi być kompletny. Każdy zbiór ma swoja˛ unikalna˛ nazw˛e
DN, przez która˛ można si˛e do niego odwoływać. Każdy atrybut ma swój typ i wartość. Typy
maja˛ najcz˛eściej nazwy mnemoniczne, np. cn, mail. Rodzaj wartości zależy od typu: cn mo-
że mieć wartość Jaś Kowalski, a mail wartość jas@example.company.com. Wartościa˛ atrybutu
jpegPhoto byłby obrazek w formacie JPEG.
X.500
Kluczowym protokołem dla działania baz DAP jest protokół X.500. Został on zaprojektowany
do obsługi olbrzymich i skomplikowanych baz budowanych na potrzeby konkretnej organizacji
i przez ta˛ organizacj˛e. Ponieważ protokół X.500 jest skomplikowany, wymaga używania pro-
tokołów rodziny ISO, a jego implementacja trudna, stworzono jego prostsza˛ wersj˛e – jest nia˛
właśnie LDAP. Dzi˛eki temu protokół X.500 ( w zasadzie jego prostsza wersja) jest tak szeroko
używany.
Nazewnictwo w protokole X.500
Struktura katalogów w bazie jest znana dużej liczbie użytkowników, gdyż jest bardzo podobna do
hierarchii domen z systemu DNS. Każda organizacja (obecna w Internecie) należy do domeny,
której nazwa tworzy końcówk˛e adresu, np. .org, .info. Przed końcówka˛ określajac ˛ a˛ „korzeń”
domeny wyst˛epuje nazwa zwiazana ˛ z dana˛ instytucja˛ i jest ona unikalna w sieci. W ramach danej
organizacji może również wyst˛epować kilka poddomen, np. support, marketing.
Nazewnictwo i struktura katalogów w LDAP jest budowana na podobnej zasadzie. Pełna
nazwa obiektu w bazie DN (ang. distinguishedName) jest budowana z unikalnej nazwy obiektu
i nazwy organizacji. Na przykład użytkownik Jaś Kowalski mógłby istnieć w bazie LDAP jako
cn=Jaś Kowalski,dc=example,dc=company,dc=com. Skrót cn pochodzi od Common Name
a dc od Domain Component
LDAP może używać dwóch konwencji nazywania katalogów w swojej strukturze. Pierwsza,
prostsza, odzwierciedla nazwy DNS, tak jak w przykładzie powyżej. Druga, bardziej zwiazana ˛
z metoda˛ opracowana˛ dla X.500, opiera si˛e na położeniu geograficznym. Wówczas DN Jasia
Kowalskiego wygladałoby
˛ np. tak: cn=Jaś Kowalski, o =example company, I =Warsaw, st=woj.
mazowieckie, c=PL. Rysunek 7.8 przedstawia porównanie obu konwencji.
Bardziej popularne jest nazywanie obiektów analogicznie do nazw DNS. System ten jest
prostszy, a przy używaniu tych samych nazw w LDAP i DNS pozwala na łatwa˛ nawigacj˛e. Nale-
ży jednak pami˛etać, że te dwa systemy sa˛ rozłaczne
˛ i niezależne. Jeżeli domena DNS ma postać
example.company.com, to nic nie stoi na przeszkodzie, żeby obiekt w LDAP miał DN nast˛epu-
jace:
˛ dc=example, dc=company, dc=pl.
Niezależnie od tego, który system nazewnictwa jest stosowany, można jeszcze stworzy ć swój
własny. LDAP pozwala na coś takiego. Ważne jest tylko aby system był spójny i a nazwy od-
zwierciedlały prawidłowo, to co pod nimi ukryte.
C=PL C=US dc=net dc=com dc=pl
st=woj. mazowieckie dc=company
o=company Organization dc=example
on=serwis on=serwis
Organization Unit
on=marketing on=marketing
Person
cn=Jan Kowalski uid=jan
Rysunek 7.8: Modele nazewnictwa przyj˛ete w X.500.
7.7. Podsumowanie
W tym rozdziale zostało przedstawionych kilka serwisów, możliwych do spotkania w sieciach.
Cz˛eść z nich wyst˛epuje w zasadzie tylko w starszych sieciach, np. BOOTP. Inne z kolei sa˛ do-
piero w tej chwili wdrażane, np. LDAP. W niektórych sieciach, spośród wymienionych usług,
można jedynie si˛e natknać
˛ na DNS. Na pewno nie jest konieczne uruchamianie wszystkich wy-
mienionych lub niewymienionych serwisów. Łatwo bowiem zauważyć, że cz˛eściowo nakładaja˛
si˛e one na siebie i nie zawsze jest możliwe określenie efektu ich współpracy. Jeśli sa˛ rozsad-
˛
nie wykorzystywane, to na pewno ułatwiaja˛ korzystanie z sieci użytkownikom oraz ułatwiaja˛
jej administracj˛e. Należy również pami˛etać, że nie wszystkie informacje czy też dane można
przesyłać przy pomocy tych serwisów. Czasami trzeba wr˛ecz uruchomić dodatkowy serwer dla
jednej konkretnej dodatkowej usługi.
Bibliografia
[1] Balachander Krishnamurthy, Jennifer Rexford. Web Protocols and Practice. Addison–
Wesley, NewYork, 2001.
[2] M. Crispin. Internet Message Access Protocol – Version 4, December 1994. RFC 1730.
[3] ISO. ISO Transport Protocol Specification, April 1984. RFC 905.
[4] J. Myers, M. Rose. Post Office Protocol – Version 3, May 1996. RFC 1939.
[5] David L. Mills. Network Time Protocoli (Version 3) Specification, Implementation and Ana-
lysis, March 1992. RFC 1305.
[6] J. Postel. Daytime Protocol, May 1983. RFC 867.

[7] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Merners–Lee.

Hypertext Transfer Protocol – HTTP/1.1, June 1999. RFC 2616.
[8] W. Yeong, T. Howers, S. Kille. Lightweight Directory Access Protocol, March 1995.
RFC 1777.
[9] Y. Pouffary, A. Young. ISO Transport Service on top of TCP (ITOT), March 1997. RFC 2126.
R OZDZIAŁ 8
Ochrona danych w sieci
Sieć komputerowa stwarza ogromne możliwości. Za pomoca˛ komputera dołaczonego ˛ do sieci

można pogadać z przyjaciółmi, napisać list, wysłać zdj˛ecia, posłuchać muzyki. Można też zapła-
cić rachunek za telefon, zamówić pizz˛e lub kupić płyt˛e CD. Jednocześnie sieć niesie zagrożenia.
Wraz z listem można otrzymać wirusa, który może skasować cała˛ zawartość komputera, może
ktoś si˛e włamać i przejać
˛ nasze wyniki pracy, numery kont bankowych, kart kredytowych. Na-
leży si˛e przed tym bronić. Sposobów na to jest wiele. Dobór metody zastosowanej do obrony
jak i zakres tej obrony powinien być ściśle zwiazany
˛ z potrzebami. Potrzeby zaś wynikaja˛ ze
specyfiki wykorzystywania sieci. W inny sposób wykorzystuja˛ sieć przedsi˛ebiorstwa a w inny
indywidualni użytkownicy. Niniejszy rozdział ma za zadanie przybliżyć tylko cz˛eść zagadnień
zwiazanych
˛ z bezpieczeństwem. Na całość zabrakło by miejsca. Aby mówić o ochronie w pierw-
szej kolejności należy poznać zagrożenia. Zagrożenia moga˛ być różne i specyficzne dla danego
fragmentu sieci ale z pewnym przybliżeniem możemy je podzielić nast˛epujace ˛ grupy:
uzyskanie przez osoby niepowołane dost˛epu do danych transmitowanych przez sie ć lub
przechowywanych na dołaczonych
˛ do sieci komputerach;
uzyskanie przez osoby niepowołane dost˛epu do innych zasobów (moc obliczeniowa kom-
puterów itd.);
utrata danych na skutek złośliwej ingerencji zewn˛etrznej;
fałszerstwo danych (np. poprzez podszycie si˛e pod innego nadawc˛e w poczcie elektronicz-
nej);
utrata dost˛epu do danych przez uprawnionych urzytkowników na skutek ataku DoS (ang.
Denial of Service).
Wi˛ekszość zagrożeń sieciowych jest zwiazana
˛ z Internetem i wypływa z niedoskonałości proto-
kołu TCP/IP. Do tego dochodzi jeszcze niechlujstwo dostawców systemów operacyjnych i popu-
larnego oprogramowania. Przerzucaja˛ oni kosztowne testy oprogramowania na użytkowników.
Problem stał si˛e na tyle poważny, że żaden użytkownik sieci nie może czuć si˛e bezpiecznie.
Nie można też popadać w paranoj˛e i nie używać sieci. Jak to robić, spróbuje odpowiedzieć ten
rozdział.
8.1. Wirusy komputerowe

Najbardziej znanym zagrożeniem w sieciach komputerowych - i nie tylko - sa˛ wirusy kompu-
terowe. Wirusy komputerowe to proste programy komputerowe, które potrafia˛ si˛e powiela ć na
komputerze użytkownika bez jego wiedzy. Oprócz powielania moga˛ wykonywa ć jeszcze dodat-
kowe zadania. Wirusy komputerowe istnieja˛ prawie tak długo jak istnieja˛ komputery. Cz˛esto
165
166 8.1. Wirusy komputerowe
powstawały jako wynik nudów programistów. Pisali oni proste programiki, aby wykaza ć si˛e
swoimi umiej˛etnościami w zakresie programowania i wiedzy o komputerach. Wirusy wykonu-
ja˛ różne zadania. W zależności od zamysłu twórcy wirusa moga˛ to być zadania nieszkodliwe,
takie jak otwarcie okienka z mniej lub bardziej sensownym komunikatem jak i bardzo goź-
ne takie jak procedura formatowania dysku twardego. Wirusy wykorzystuja˛ luki w zabezpie-
czeniach systemów operacyjnych oraz oprogramowania użytkowego pracujacych ˛ na tych sys-
temach. Wirusy generalnie atakuja˛ systemy operacyjne stworzone przez firm˛e Microsoft czyli
systemy DOS/WINDOWS. Sa˛ też pojedyncze wirusy działajace ˛ w środowisku UNIX, ale poza
jednym przypadkiem z przed wielu lat nie wyrzadziły ˛ one wiele szkód. Wirusy sa˛ programami
binarnymi, czyli sa˛ wynikiem kompilacji programu napisanego w jednym z j˛ezyków programo-
wania jak – na przykład j˛ezyk C – lub zestawami instrukcji napisanych w j˛ezykach wysokiego
poziomu, które sa˛ wykonywane przez interpreter. Wirusy w postaci programów wykonywalnych
były popularne przed laty. Ich główna˛ droga˛ przenoszenia były dyskietki. Aby zarazi ć komputer
trzeba też było wykazać si˛e pewna˛ niefrasobliwościa˛ gdyż polecenie uruchomienia programu
z wirusem musiał wydać użytkownik. Wirus doklejał si˛e wtedy do innych programów wyko-
nywalnych. Skutki posiadania wirusa w systemie mogły si˛e ujawnić po wielu tygodniach lub
miesiacach.
˛ Mógł to być zwykły komunikat na ekranie jak i operacja kasowania dysku. Sposób
przenoszenia wirusów ograniczał ich zasi˛eg, ale w miar˛e popularyzowania si˛e usług sieciowych
zmieniała si˛e ich droga przenoszenia. Wirusy zacz˛eto rozsyłać np. za pomoca˛ poczty elektro-
nicznej. W przypadku wirusów w postaci binarnej użytkownik stosujacych ˛ si˛e do pewnych za-
sad był w stanie uniknać ˛ zarażenia komputera wirusem. Wystarczyło nie otwierać załaczników˛
poczty elektronicznej, które zawierały programy. Użycie poczty do transmisji wirusów spowo-
dowało ich szybkie rozprzestrzenianie si˛e po świecie. Pojawiły si˛e także nowe rodzaje wirusów
wykorzystujace˛ np. możliwość tworzenia makr w popularnym pakiecie Microsoft Office. Zagro-
żeniem stały si˛e wi˛ec nie tylko pliki zawierajace
˛ programy, ale też pliki, w których przesyłane sa˛
dokumenty. Dokumenty nadesłane od znanej osoby sa˛ traktowane jako bardzo ważne i odbior-
ca próbuje je otworzyć, co powoduje uruchomienie makra z wirusem. Bardziej zaawansowani
użytkownicy blokuja˛ możliwość uruchamiania makr w otrzymanym dokumencie. Ogranicza to
możliwość uruchomienia wirusa makrowego, ale go nie eliminuje. Dodatkowo, aby ułatwi ć ob-
sług˛e, poczty firma Microsoft dodała do swojego programu pocztowego szereg funkcji, które
w zamierzeniu miały ułatwić jego obsług˛e. Stały si˛e one pożywka˛ dla wirusów, gdyż pliki doła- ˛
czane do listu były automatycznie otwierane. Wystarczyło wi˛ec nadać list z wirusem a program
pocztowy automatycznie go otworzył i wirus si˛e uaktywniał. Kolejne generacje wirusów potrafia˛
coraz wi˛ecej. Sa˛ wyposażane we własne serwery pocztowe co pozwala im si˛e samodzielnie roz-
syłać. Potrafia˛ korzystać z ksiażek
˛ adresowych programów pocztowych. Wykorzystuja˛ je jako
źródło potencjalnych ofiar. Jako adres nadawcy potrafia˛ wybrać dowolny adres z ksiażki ˛ adre-
sowej. Utrudnia to przeci˛etnemu użytkownikowi poczty wykrycie fałszerstwa, gdyż dość cz˛esto
otrzymuje list od znanej sobie osoby, choć tytuł i treść sa˛ podejrzane. Obecne wirusy wykorzy-
stuja˛ do rozprzestrzeniania si˛e różne technologie sieciowe. Wykorzystywane sa˛ bł˛edy w j˛ezykach
skryptowych baz danych, współdzielone zasoby w systemie windows, dziury w oprogramowa-
niu oraz bł˛edy w protokołach komunikacyjnych takich jak na przykład sieci p2p (np. kaZaA).
Oprócz znanych możliwości niszczenia zasobów zgromadzonych na komputerach wirusy posia-
dły także możliwość zakłócania pracy sieci. Niektóre z nich – próbujac ˛ si˛e rozsyłać – generuja˛
spory ruch sieciowy. Zdarzały si˛e też takie, które rozprzestrzeniały si˛e po sieci tylko po to, by
określonego dnia przypuścić atak na wybrany popularny serwis sieciowy. Atak powodował blo-
Ochrona danych w sieci 167
kad˛e serwisu. Rozwój narz˛edzi programistycznych powoduje też szybkie powstawanie nowych
odmian tego samego wirusa. Najcz˛eściej wykorzystuja˛ t˛e sama˛ luk˛e w systemach do rozprze-
strzenia si˛e zmieniania jest natomiast dodatkowa funkcjonalność. Kolejne odmiany wirusów sa˛
zazwyczaj coraz bardziej groźne. I tak wirus, który wyświetlał napis w stylu "Witaj" może si˛e
zmienić w wirusa niszczacego
˛ dane na dysku. Wirusy zacz˛eto dzielić na różne kategorie. Naj-
cz˛eściej spotykanymi nazwami sa˛ robaki i trojany.
Robaki Robakami (ang. Worms) określa si˛e programy podobne do wirusów, które zostały
opracowane w celu szybkiego zainfekowania jak najwi˛ekszej liczby komputerów. Robaki roz-
przestrzeniajac
˛ si˛e poprzez sieć moga˛ z jednego zainfekowanego komputera rozprzestrzenić si˛e
do tysi˛ecy lub nawet milionów komputerów. Ich masowa reprodukcja powoduje ogromny ruch
w sieci. W symulacjach teoretycznego robaka o nazwie Warhol Worm stwierdzono, że w ciagu ˛
kwadransa jest możliwe zarażenie nawet 9 000 000 komputerów (patrz
http://www.opoka.org.pl/varia/internet/wirusy.html).
Konie trojańskie Konie trojańskie lub trojany swoja nazw˛e wywodza˛ ze starożytnej Troi. Sa˛
jakby współczesna˛ wersja˛ drewnianego konia trojańskiego. Miejscem ich operowania jest sieć
Internet. Po zainfekowaniu systemu nie czynia˛ w nim żadnych zniszcze ń a bardzo cz˛esto udaja˛
że robia˛ coś pożytecznego. Po uruchomieniu oczekuja˛ na polecenia z zewnatrz.
˛ W odróżnieniu
od typowego wirusa ich kod zawarty jest w dwóch plikach. W jednym jest kod "wirusa", który
jest instalowany na komputerze ofiary. W drugim pliku jest kod "sterownika" za pomoca,˛ któ-
rego można sterować trojanem na komputerze ofiary. Trojan daje możliwość przej˛ecia kontroli
nad komputerem ofiary. Zakres kontroli zależy od trojana a w zasadzie od jego twórcy. Trojan
sam w sobie nie jest groźny gdyż, jego szkodliwość jest zależna od osoby, która danego trojana
kontroluje. Cz˛esto może si˛e on ograniczyć do wyświetlenia głupiego komunikatu, ale nie należy
wykluczać działań bardziej destrukcyjnych.
Dialery Dialery sa˛ dość cz˛esto wiazane

˛ z wirusami, choć nimi nie sa.˛ Sa˛ to programiki, które
zmieniaja˛ ustawienia sieciowe komputera wyposażonego w modem. Duża cz˛e ść użytkowników
łaczy
˛ si˛e do internetu wykorzystuje połaczenia
˛ modemowe. Sa˛ to darmowe numery operatorów
jak na przykład numer 0202122 TPSA czy też numery płatne, gdzie użytkownik otrzymuje ja-
kiś dodatkowy zestaw usług. Dialer dokonuje zmiany numeru telefonu, za pomoca˛ którego jest
realizowany dost˛ep do Internetu na inny numer. Najcz˛eściej jest to numer telefonu typu 0-700
gdzie opłata za wynosi kilka złotych za minut˛e. Operatorzy tych numerów maja˛ podpisane umo-
wy na dzielenie zysków z operatorami telekomunikacyjnymi. Oferuja˛ oni najcz˛e ściej dost˛ep do
płatnych serwisów pornograficznych. Problem z dialerami jest taki, że sa˛ one instalowane na
komputerach w sposób podst˛epny, przypominajacy ˛ działanie wirusów. Skutkami działania dia-
lerów zagrożone sa˛ głównie komputery korzystajace˛ z połacze
˛ ń modemowych. Problem był si˛e
na tyle poważny, że niektóre programy antywirusowe sa˛ wyposażane w możliwości wykrywania
i usuwania dialerów. Obecnie o dialerach mniej si˛e mówi i pisze. Zwiazane
˛ jest to z upowszech-
nieniem si˛e stałych łacz
˛ do Internetu.
168 8.1. Wirusy komputerowe
8.1.1. Ochrona antywirusowa

Obrona przed wirusami jest sprawa˛ złożona.˛ Składa si˛e na nia˛ szereg czynników. Jednym z nich
jest dobór miejsca ochrony. Wirusy stanowia˛ najwi˛eksze zagrożenie dla komputerów PC. Kom-
puter taki może pracować w firmie, lub stanowić prywatna˛ własność i pracować w domu użyt-
kownika. W przypadku firmy ochrona komputera jest zależna od polityki firmy, a w przypadku
prywatnego komputera za ochron˛e odpowiedzialny jest jego użytkownik. Ważny jest też dobór
miejsca, w którym chce si˛e ochron˛e zastosować. Przed wirusami można bronić si˛e bezpośrednio
na zagrożonych komputerach jak i na serwerach usług sieciowych, które te wirusy moga˛ przeno-
sić. Zapewnienie skutecznej ochrony jest kombinacja˛ post˛epowania użytkownika i zastowanych
metod ochrony.
Post˛epowanie użytkownika
Użytkownik może w dużej mierze ustrzec si˛e przed zarażeniem komputera wirusem niezależ-
nie od faktu, czy korzysta z komputera firmowego, czy też z komputera prywatnego. Główna˛
droga˛ – choć nie jedyna˛ – rozprzestrzeniania si˛e wirusów jest obecnie poczta elektroniczna. Jeśli
użytkownik nie odbiera podejrzanych przesyłek, to ma duże szans˛e na unikni˛ecie zarażenia kom-
putera wirusem. Dobra˛ metoda˛ jest też zmiana programu pocztowego z popularnego Outlocka
na inny. Wi˛ekszość wirusów rozprzestrzeniajacych
˛ si˛e poprzez poczt˛e korzysta z niedoskonało-
ści tego programu. Zastosowanie innego powoduje zmniejszenie ryzyka wpuszczenia wirusa do
komputera. Trzeba jednak pami˛etać, że wirusy dostaja˛ si˛e do komputera nie tylko poprzez pocz-
t˛e elektroniczna,˛ lecz także poprzez inne usługi. Pociaga˛ to za soba˛ konieczność zastosowania
dodatkowych narz˛edzi. Najcz˛eściej na komputerach instaluje si˛e programy antywirusowe.
Programy antywirusowe
Typowa˛ ochrona˛ komputera jest zainstalowanie programu antywirusowego. Klasyczny program

antywirusowy składa si˛e ze skanera oraz bazy sygnatur wirusów. Skaner dokonuje przegla- ˛
du plików w komputerze. Zawartość porównuje z baza˛ sygnatur. Aby program był skutecz-
ny, to baza z sygnaturami wirusów musi być aktualna. Bazy wi˛ec musza˛ być aktualizowane
nawet kilka razy dziennie. Według Marka Sella twórcy programu antywirusowego MKSVIR
(http://www.mks.com.pl), miesi˛ecznie przybywa około 150 - 200 wirusów (patrz
http://www.computerworld.pl/artykuly/22179.html). Oznacza to że w ciagu ˛ roku w ba-
zie może przybyć nawet około 2000 nowych wirusów. Powoduje to wydłużenie pracy programu
antywirusowego co w efekcie przekłada si˛e na niższy komfort pracy przy komputerze. Ponieważ
niektóre wirusy moga˛ być bardzo niebezpieczne, wymaga to, aby firmy tworzace ˛ oprogramowa-
nie antywirusowe dostarczały bardzo szybko aktualizacje. Wymusza to na nich niemal 24 go-
dzinny cykl pracy. Przekłada si˛e to na koszty tworzenia oprogramowania, a te powoduja˛ wysoka˛
cen˛e oprogramowania. Nowoczesne programy antywirusowe potrafia˛ wykry ć wirusa i zabloko-
wać otwarcie pliku, w którym wirus si˛e znajduje. Potrafia˛ także kontrolować poczt˛e elektroniczna˛
i blokować możliwość otwarcia listu, w którym jest wirus. Nie sa˛ w stanie jednak zabezpieczyć
wszystkiego. Co gorsza, bardzo cz˛esto sa˛ wyłaczane
˛ przez użytkowników, gdyż zwalniaja˛ prac˛e
komputera.
Rozwiazania
˛ systemowe
Problem ochrony antywirusowej można podjać ˛ bardziej kompleksowo. Użytkownicy sieci moga˛
bronić si˛e sami, ale można także wspomóc ich. Identyfikujac ˛ sposoby przenoszenia si˛e wiru-
sów można spróbować przegrodzić im drog˛e, zanim dotra˛ do komputera ofiary. Skoro najwi˛ecej
wirusów roznoszonych jest poczta˛ to można zwalczać wirusy na serwerach pocztowych. Koszty
wdrożenia tego rozwiazania
˛ nie sa˛ małe, ale jest to opłacalne. Sprawdzenie już na serwerze pocz-
ty, czy list nie zawiera wirusa, pozwala na podj˛ecie akcji zanim list trafi do skrzynki. Najcz˛e ściej
list z wirusem trafia do kwarantanny lub jest kasowany. Systemy antywirusowe zainstalowane
na serwerach pocztowych pozwalaja˛ także wysłać list z ostrzeżeniem do nadawcy listu. Kontrola
antywirusowa poczty na serwerze pozwala także wdrożyć centralna,˛ niezależna˛ od użytkownika
polityk˛e post˛epowania z podejrzanymi przesyłkami. Użytkownik nie musi wiedzie ć, że przyszedł
do niego list. Tego typu polityka jest wdrażana w firmach. Centralny serwer pocztowy z syste-
men antywirusowym pozwala także na cz˛eściowa˛ rezygnacj˛e z programów antywirusowych na
stacjach klienckich. Jest to przydatne zwłaszcza w systuacji gdy w firmie pracuja˛ starsze kompu-
tery, na których instalacja programów antywirusowych jest niemożliwa. Operatorzy darmowych
i płatnych portali internetowych także wdrażaja˛ ochron˛e antywirusowa˛ poczty. Maja˛ jednak pro-
blem prawny co zrobić z listem, który zawiera wirusa. W przypadku firmy wystarczy jedno
polecenia właściciela i wszystkie zawirusowane listy moga˛ być kasowane. W przypadku portalu
zachodzi konflikt prawem użytkownika do zachowania poufności korespondencji, a konieczno-
ścia˛ świadczenia bezpiecznej usługi. Problem ten w każdym portalu jest inaczej rozwiazywany ˛
i regulowany przez regulamin, z którym należy si˛e zapoznać przed otwarciem konta poczty elek-
tronicznej.
Choć poczta elektroniczna jest jedna˛ z głównych dróg przenoszenia wirusów w sieci, to nie
jest jedyna.˛ Praktycznie każda z usług sieciowych może być wykorzystana przez wirusy. Powsta-
ja˛ wi˛ec narz˛edzia, które maja˛ usprawnić ochron˛e antywirusowa. ˛ Ograniczaja˛ si˛e one jednak do
najbardziej popularnych usług, jak na przykład serwisy www. Dost˛epne sa˛ też narz˛edzia, które
– po zinstalowaniu w sieci – potrafia˛ przegladać ˛ i analizować dane zanim trafia˛ do komputera
klienta. Tego typu rozwiazania
˛ stosuja˛ najcz˛eściej firmy, których sieci sa˛ dołaczone
˛ do Internetu.
Oprócz możliwości blokowania dost˛epu wirusom, interesujaca ˛ jest też możliwość blokowania
innych niechcianych treści, jak strony serwisów erotycznych. Podobne rozwiazania ˛ mogli by
wprowadzić operatorzy oferujacy ˛ dost˛ep do Internetu indywidualnym klientom. Nie robia˛ jed-
nak tego, gdyż przypomina to cenzurowanie treści.
Dla mniej popularnych usług raczej nie powstaja˛ specjalizowane narz˛edzia kontroli anty-
wirusowej. Wynika to rachunku ekonomicznego. Usług jest bardzo dużo i zrobienie dla każdej
z nich specjalizowanego narz˛edzia było by kosztowne, a rynek potencjalnych nabywców byłby
niewielki. Taniej wychodzi blokowanie za pomoca˛ firewali dost˛epu do zb˛ednych usług siecio-
wych.
8.2. Ochrona danych

Kilkadziesiat
˛ lat temu nieliczne firmy posiadały centra obliczeniowe, w których obrabiano dane
dla potrzeb firmy. Niektóre firmy nie posiadały własnych centrów ale korzystały z mocy obli-
czeniowej centrów przetwarzania danych. Wraz z upowszechnieniem si˛e komputerów PC moż-
170 8.2. Ochrona danych
liwość przetwarzania danych została przeniesiona z centr do własnych ośrodków firmowych.

W firmach powstały sieci LAN. Pozwalały one na łatwiejsza˛ wymian˛e danych w obr˛ebie firmy.
Wi˛eksze maja˛ oddziały, a w nich sieci LAN. Pomi˛edzy tymi odległymi sieciami dość cz˛esto za-
chodzi konieczność wymiany danych, gdyż ułatwia to zarzadzanie
˛ firma.˛ Niemniej jednak dane
pozostawały w obr˛ebie jednej firmy. Obecnie dane moga˛ być obrabiane zarówno wewnatrz ˛ danej
firmy jak także za pomoca˛ Internetu poprzez wymian˛e z innymi. Dane sa˛ także gromadzone na
prywatnych komputerach. Cz˛esto wartość zgromadzonych danych przewyższa wartość kompu-
terów, na których sa˛ gromadzone. Dla przeci˛etnego użytkownika komputer to sprz˛et (procesor,
pami˛eć, dyski, klawiatura) oraz oprogramowanie (system Windows, pakiet Office itp). W przy-
padku utraty komputera zakup nowego i instalacja oprogramowania zajmuje kilka godzin - na-
tomiast odtworzenie danych, jeśli w ogóle b˛edzie możliwe, może zajać ˛ lata. Dokumentów, które
pisało i gromadziło si˛e przez lata, nie da si˛e odtworzyć szybko. Dlatego należy chronić dane, któ-
re si˛e zgromadziło lub wytworzyło. Charakter tych danych może być różny bo moga˛ być to dane
o klientach, bazy danych z produktami, zdj˛ecia, filmy reklamowe, itd. Niezależnie od charakteru
danych czy posiadacza tych danych, musza być one gromadzone na fizycznych nośnikach. Przez
nośniki można rozumieć komputery z dyskami twardymi, dyskietki, serwery, macierze dysków,
taśmy magnetyczne, CD-ROM-y i inne mniej lub bardziej znane rozwiazania. ˛ Wszystko to wy-
maga ochrony. Niestety, najcz˛eściej przez ochron˛e rozumie si˛e bezpieczeństwo informatyczne,
czyli firewalle i ograniczone uprawnienia kont użytkowników oraz oprogramowanie antywiru-
sowe. Jest to podejście bardzo ograniczone gdyż problem jest zdecydowanie bardziej złożony.
W pierwszej kolejności należy przeanalizować modele gromadzenia danych. W typowym mo-
delu dane firmy sa˛ gromadzone na centralnym serwerze (serwerach). Tak funkcjonuje wi˛ekszość
firm, ale – jak pokazuje Internet – nie jest to jedyny możliwy model gromadzenia i przecho-
wywania danych. Innym jest system, w którym dane sa˛ rozpraszane pomi˛edzy użytkowników –
członków danej organizacji. Przykładem takich modelów przechowania danych sa˛ systemy P2P
używane przez internautów do wymiany plików z muzyka,˛ filmami, grami. Możliwe sa˛ także
różne systemy pośrednie. Krótka analiza obu modeli powinna przybliżyć problemy, zwiazane ˛
z bezpieczeństwem danych choć prawdopodobnie nie naświetli wszystkich.
8.2.1. Model centralny gromadzenia danych

Jako pierwszy przeanalizowany zostanie model centralny gromadzenia danych. Typowy przy-
kład takiego modelu gromadzenia danych to serwer lub serwery, które dość cz˛esto wyposażone
sa˛ w macierze dyskowe, ale już nie zawsze w biblioteki taśm do robienia kopii zapasowych. Taki
model ma wiele, zalet, ale też i wady. Najwi˛eksza˛ zaleta˛ jest to, że wiadomo gdzie te dane fi-
zycznie sa˛ przechowywane, a wi˛ec można zorganizować ich sprawna˛ ochron˛e. Ochrona powinna
być całościowa, a wi˛ec obejmować musi:
fizyczne bezpieczeństwo samego serwera;
zasilanie;
strategi˛e tworzenia kopii zapasowych;
procedury awaryjne;
zasady dost˛epu;
ochron˛e sieciowa.˛
Bezpieczeństwo fizyczne serwera

Kluczowym aspektem bezpieczeństwa fizycznego serwera, a co za tym idzie danych na nim zgro-
madzonych, jest dobór miejsca, w którym zostanie ulokowany. Najcz˛e ściej o tym miejscu mówi
si˛e "serwerownia", ale nie zawsze miejsce jest dobrane właściwie. Przy budowie serwerowni
zwraca si˛e uwag˛e na nast˛epujace
˛ czynniki:
zasilanie;
klimatyzacja;
zabezpieczenia antywłamaniowe;
autoryzowany dost˛ep.
Zasilanie Zasilanie w serwerowni powinno zapewnić prace serwera (serwerów) a także klima-
tyzacji. Powinno być także przewidziane zasilanie awaryjne całej serwerowni na wypadek awarii
zasilania podstawowego. W wielu firmach, zwłaszcza mniejszych, zdarza si˛e, że zasilanie awa-
ryjne nie zapewnia zasilania dla potrzeb klimatyzacji. Może to jednak spowodowa ć uszkodzenia
serwera lub serwerów, co może zakończyć si˛e zniszczeniem danych. Aby zapobiegać takim sy-
tuacjom, niektórzy producenci serwerów i urzadze ˛ ń sieciowych instaluja˛ w swoich urzadzeniach
˛
bezpieczniki temperaturowe, co cz˛eściowo rozwiazuje ˛ problem, choć bardziej całościowym roz-
wiazaniem
˛ były by czujniki zintegrowane z zasilaniem. Rozważajac ˛ problem zasilania najcz˛e-
ściej skupiamy si˛e na zasilaniu w energi˛e serwerowni oraz urzadze ˛ ń w niej zgromadzonych.
Tymczasem powinno si˛e podchodzić do tego bardziej kompleksowo. Jeśli dost˛ep do danych ma
być zapewniony co najmniej tak długo jak pracuja˛ serwery to należy zadbać o zasilanie urzadzeń˛
sieciowych ten dost˛ep zapewniajacych. ˛ Dobrze było by, aby obiekt, w którym zlokalizowana
jest serwerownia posiadał dwa niezależne podejścia energetyczne. Pozwala to utrzymać wi˛ek-
sza˛ bezawaryjność centrów danych, ale niesie za soba˛ dodatkowe koszty. Jeśli serwerownia jest
zabezpieczona różnymi zamkami elektrycznymi, to także należy zapewnić im odpowiednie za-
silanie. Jeśli si˛e o to nie zadba, to może si˛e okazać, że na skutek przerwy w zasilaniu zamki si˛e
otworza.˛
Zabezpieczenia antywłamaniowe Jeśli serwery nam si˛e nie spala,˛ to moga˛ stać si˛e łupem
złodziei. Najbardziej popularne sa˛ włamania i wykradanie danych poprzez sieć, ale nie należy
wykluczyć próby kradzieży całych serwerów lub przynajmniej dysków twardych z danymi. Cza-
sami jest to znacznie prostsze, niż włamanie poprzez sieć. Świadcza˛ o tym przypadki kradzieży
komputerów z ważnymi danymi z różnych firm czy agend rzadowych. ˛ Na taka˛ ewentualność na-
leży si˛e przygotować. Jeśli dane sa˛ bardzo ważne to można z serwerowni zrobić sejf. W wi˛ekszo-
ści wypadków powinna wystarczyć sprawna ochrona budynku oraz systemy alarmowe. Systemy
te powinny być ściśle powiazane
˛ z autoryzowanym dost˛epem do pomieszcze ń. To ostatnie jest
najtrudniej wymóc.
Lokalizacja Ważnym aspektem lokalizacji serwerowni oraz jej wyposażenia, a co za tym idzie
bezpieczeństwa danych, jest zapewnienie odporności na swojego rodzaju kl˛eski żywiołowe. Mo-
że si˛e okazać, że poniesione zostały ogromne koszty na zasilanie awaryjne, zapasowe serwe-
ry i inne rozwiazania,
˛ gdy tymczasem cała praca pójdzie na marne na skutek p˛ekni˛ecia rury
centralnego ogrzewania i zalania całej serwerowni. Ulewny deszcz oraz dziurawy dach potra-
fi wyrzadzić
˛ podobne szkody. Koszty działania serwerowni może także podnieść umieszczenie
serwerowni tak, że okna wychodza˛ na południe. Nie zawsze serwerownie sa˛ lokalizowane w po-
mieszczeniach bez okien. Słońce potrafi nagrzać takie pomieszczenie, co powoduje w systemie
klimatyzacji konieczność wi˛ekszego chłodzenia. To zaś powoduje zwi˛ekszenie poboru pradu.
˛ Zi-
ma˛ pomieszczenie serwerowni moga˛ zaś dogrzewać kaloryfery, cz˛esto całkowicie niepotrzebnie,
gdyż urzadzenia
˛ wydzielaja˛ wystarczajaco
˛ dużo ciepła potrzebnego do ogrzania pomieszczenia.
Nadmiar ciepła musi wi˛ec usunać˛ klimatyzacja, co znowu powoduje zwi˛ekszony pobór pradu.˛
Klimatyzacja Nowoczesne komputery wymagaja˛ stałej temperatury pracy oraz stałej wilgot-
ności. Takie warunki zapewnia klimatyzacja. Moc klimatyzacji powinna zapewnić możliwość
usuni˛ecia ciepła wytworzonego przez pracujace˛ urzadzenia.
˛ Dobrze jest zapewni ć rezerw˛e mocy
na urzadzenia,
˛ które moga˛ si˛e dopiero pojawić, jak również na niespodzianki typu dogrzewanie.
Klimatyzacja musi być też serwisowana. Może si˛e na niej skraplać woda, która kapiac ˛ może
spowodować zwarcia w zasilaniu.
Kopie zapasowe Dane z jakiegoś powodu moga˛ ulec zniszczeniu. Aby nie narazić firmy lub
siebie na całkowita˛ utrat˛e danych, które cz˛esto stanowia˛ podstaw˛e działalności, należy wykony-
wać kopie zapasowe. Już samo wykonywanie kopii jest skomplikowanym problemem technicz-
nym, szczególnie gdy system pracuje całodobowo. Zawartość danych w takim systemie ulega
ciagłym
˛ zmianom. W praktyce, aby wykonać kopie systemu na dana˛ chwil˛e należało by sys-
tem odłaczyć
˛ na czas wykonywania kopii. Nowe systemy operacyjne, jak np. Solaris 8, potrafia˛
zablokować stan plików na potrzeby wykonania kopii zapasowej bez konieczności przerywania
pracy systemu. Tworzenie kopii zapasowych powinno być ściśle określone w strategii ochro-
ny informatycznej. Nośniki, na których wykonywana jest kopia, powinny być udokumentowane
i właściwie przechowywane. Może si˛e okazać, że znacznie prościej b˛edzie ukraść zestaw taśm,
na których jest kompletna kopia systemu niż dokonać włamania do systemu poprzez sieć kom-
puterowa.˛ Taśmy lub inne nośniki z kopiami zapasowymi nie powinny być przechowane w tym
samym pomieszczeniu, w którym znajduja˛ serwery. Jest to wygodne, ale w wypadku jakiejś
katastrofy może okazać si˛e zgubne. Najlepiej kopie zapasowe trzymać w innym budynku. Jak
pokazały wydarzenia 11 września lub powodzie z przed kilku lat, wymóg ten wcale nie jest
przesadzony.
Procedury awaryjne System może ulec awarii i dane zostana˛ utracone, badź ˛ dost˛ep do nich
b˛edzie niemożliwy. Na taka˛ okoliczność należy utworzyć procedury awaryjne, które pozwola˛
przywrócić system do pracy. Procedury powinny być na bieżaco˛ aktualizowane. Podnosi to koszt
bieżacej
˛ obsługi systemu, bo ktoś musi nad tym czuwać, ale w przypadku awarii powinno wy-
datnie skrócić czas jej usuwania. Długość przerwy pracy może si˛e w przypadku firmy przenieść
na konkretne straty finansowe.
Zasady dost˛epu Zasady dost˛epu zostały już cz˛eściowo tu opisane. Firma musi mieć jasne
i określone procedury opisujace
˛ zasady dost˛epu do zarówno do centrów danych znajdujacych
˛ si˛e
w jej posiadaniu jak i do samych danych.
Ochrona danych na serwerze

W rozwiazaniach
˛ centralnych ważna˛ rol˛e w ochronie danych spełniaja˛ serwery. Ich zadaniem
podstawowym jest przechowywać i udost˛epniać dane. Jest szereg rozwiazań
˛ sprz˛etowych do-
st˛epnych w serwerach, które pozwalaja˛ na popraw˛e wydajności serwerów z jednoczesna˛ popra-
wa˛ ochrony danych. Najbardziej znane to systemy RAID. Powszechnie stosuje si˛e trzy wersje
RAID: 0,1,5 oraz kombinacje RAID 0+1.
RAID 0 RAID 0 tzw. striping pozwala co najmniej dwa dyski twarde wykorzystać jako je-
den wspólny wolumen na dane, co pozwalana na poprawienie wydajności ale nie polepsza bez-
pieczeństwa. Poszczególne bloki danych sa˛ na przemian zapisywane na kolejnych dyskach, co
przyspiesza operacje zapisu. Przyspiesza także operacje odczytu, gdyż podczas pobierania da-
nych plik jest odczytywany z kilku dysków na raz. Dzi˛eki temu otrzymujemy lepsza˛ wydajność
transferu. Teoretycznie, transfer z dysków połaczonych
˛ w macierz RAID 0 powinien by ć ilo-
razem transferu najwolniejszego dysku i liczby dysków w macierzy. Rozmiar takiej macierzy
jest iloczynem pojemności najmniejszego dysku i liczby dysków. Czas dost˛epu do RAID 0 jest
równy lub niewiele wi˛ekszy od czasu dost˛epu do najwolniejszego dysku. System jest idealny
dla rozwiazań,
˛ gdzie najważniejsza jest wydajność macierzy, a nie bezpieczeństwo danych gdyż
awaria jednego z dysków powoduje utrat˛e danych w całym wolumenie. Przykładem miejsca,
w którym RAID 0 można z powodzeniem stosować, jest serwer proxy WWW.
RAID 1 RAID 1 zwany "mirrorem" polega na powielaniu wszystkich informacji na dwóch

lub wi˛ecej dyskach. Wszystkie dane zapisywane sa˛ jednocześnie na co najmniej dwa dyski, co
w przypadku awarii jednego z nich nie powoduje utraty danych. Jeśli jeszcze serwer pozwala
w czasie pracy wymienić uszkodzony dysk, to jest duża szansa na niezauważenie awarii przez
użytkowników. RAID 1 w porównaniu z RAID-em 0 nie przyspieszenia dost˛epu do danych,
a niektórych rozwiazaniach
˛ może powodować jego opóźnienia, szczególnie gdy sa˛ wykonywane
operacje zapisu. RAID 1 powoduje zmniejszenie efektywnej pojemności dyskowej, gdyż dost˛ep-
na jest pojemność tylko jednego dysku. RAID 0+1 - striping and mirroring jest połaczeniem
˛ zalet
RAID 0 i 1. Zapewnia wydajność jak dla RAID 0, bezpieczeństwo jak dla RAID 1. Do dyspozy-
cji jest połowa pojemności dysków. Aby zbudować taka˛ macierz, potrzebna jest parzysta liczba
nap˛edów dyskowych. Znaczacy ˛ wzrost wydajności zapewnia zastosowanie co najmniej czterech
dysków, co jednak podnosi koszty rozwiazania.
˛
RAID 5 RAID 5 - "striping with interspersed parity" - paskowanie dysków z bitami parzysto-
ści rozłożonymi na wszystkie dyski. W RAIDzie 5 informacje o parzystości sa˛ przechowywane
na wszystkich dyskach. RAID 5 zapewnia dość wysoki poziom bezpieczeństwa, korzystne trans-
fery i stosunkowo niskie koszty budowy takiej macierzy. Awaria jednego z dysków nie powoduje
utraty danych w systemie. Systemy RAID moga˛ być realizowane poprzez rozwiazania ˛ sprz˛etowe
oraz programowe. Rozwiazania ˛ programowe realizowane sa˛ poprzez systemy operacyjne. Ich za-
leta˛ jest niższy koszt, niż systemów sprz˛etowych, ale nie zapewniaja˛ one takiej wydajności, jak
systemy sprz˛etowe. Oprócz systemów ochrony danych zwiazanych ˛ z dyskami serwery można
wyposażyć w różnorodne dodatkowe rozwiazania.˛ Dobór właściwego rozwiazania
˛ powinien być
zwiazany
˛ z rachunkiem ekonomicznym. Serwery moga˛ być wyposażone w zduplikowane zasi-
lacze, matryce krzyżowe i inne systemy poprawiajace ˛ niezawodność. Możliwe jest także w celu
poprawienia wydajności i bezpieczeństwa systemu zestawienie kilku serwerów w klaster. Kla-

ster to grupa komputerów połaczona
˛ prywatna˛ siecia,˛ które z zewnatrz˛ widziane sa˛ jako jedno
urzadzenie.
˛ Klaster może znajdować w jednej obudowie lub być kilkoma niezależnymi od sie-
bie komputerami. Komputery te moga˛ być zgromadzone w jednej serwerowni lub rozproszone
po różnych serwerowniach znajdujacych
˛ si˛e w różnych zakatkach
˛ świata. Komputery tworzace
˛
klaster sa˛ nazywane w˛ezłami (ang. node). Klastry moga˛ mieć jedna˛ wspólna˛ macierz dyskowa,˛
lub wi˛ecej. O jakości klastra decyduja˛ mechanizmy pozwalajace ˛ na stwierdzenie awarii inne-
go w˛ezła. Mechanizmy powinny pozwolić na przej˛ecie procesów uszkodzonego w˛ezła oraz na
przyłaczanie
˛ i odłaczanie
˛ w˛ezłów. Ważna˛ cecha˛ klastra jest zdolność migracji procesów pomi˛e-
dzy w˛ezłami. W razie awarii któregoś z w˛ezłów, pozostałe po stwierdzeniu jego awarii powinny
przejać
˛ jego procesy. Klastry pozwalaja˛ na popraw˛e jakości przetwarzania danych, a także –
z racji swojej funkcjonalności – dobrze potrafia˛ chronić dane.
Podsumowanie: Najszybszy w pracy jest RAID 0, najbezpieczniejszy RAID 1 zaś kompromi-

sem jest RAID 5. Co i kiedy powinno być zastosowane powinno wynikać z konkretnych potrzeb.
8.2.2. Bezpieczeństwo plików

Pliki na zgromadzone w systemie moga˛ ulec niepożadanym
˛ zmianom. Zmiany te moga˛ by ć np.
efektem włamania do serwera. Nie można całkowicie zapobiec włamaniom. Można za to zadba ć,
aby modyfikacje plików były możliwie szybko wykrywane. Posłużyć si˛e można sumami kontro-
lnymi md5. Należy wyliczyć te sumy dla wszystkich plików krytycznych. Ważne jest aby plik
z obliczonymi sumami trzymać poza serwerem - najlepiej na wymienialnym nośniku np. dyskiet-
ce. Okresowo należy dokonywać sprawdzenia sum kontrolnych plików. W wypadku zamierzo-
nej zmiany zawartości plików na serwerze należy dokonać nowego wyliczania sum kontrolnych
md5. Do tego celu sa˛ dost˛epne darmowe pakiety np. tripwire (patrz http://www.tripwire.org).
Sumy kontrolne można wykorzystać jeszcze do jednego celu. W wypadku dystrybucji danych np.
za pomoca˛ technik CDN lub serwerów lustrzanych można użyć sum jako narz˛edzia do potwier-
dzania prawidłowego transferu. Dodatkowo poprzez oficjalne publikowanie sum pozwalamy po-
tencjalnym użytkownikom na sprawdzenie, czy dane, które użytkownik otrzymał, sa˛ tymi, które
zamawiał.
8.2.3. Ochrona danych na pojedynczym komputerze

Obecnie coraz wi˛ecej ludzi pracuje w domu. Cz˛eść z nich wykonuje prac˛e dla firm, w których jest
zatrudniona a cz˛eść robi to na własny rachunek. Ich praca powoduje powstawanie plików, cz˛esto
bardzo ważnych dla firmy lub dla posiadacza komputera. Budowanie własnych serwerowni nie
wchodzi raczej w rachub˛e. Zbyt kosztowne może być także zakup systemu, który pozwalałby
robić kopie zapasowe na taśmach. Sa˛ jednak na rynku rozwiazania
˛ pozwalajace˛ na robienie ko-
pii plików. Wykorzystać do tego można nagrywarki CD, DVD czy nawet dyskietki. Nośniki te
charakteryzuja˛ si˛e różna˛ pojemnościa˛ i czasem dost˛epu. Zwykle dla pojedynczego komputera
pojemność tych nośników jest wystarczajaca. ˛ Sposób ich wykorzystania zależy to od potrzeb
i finezji użytkowników. Możliwe jest zakupienie komputera PC wyposażonego w system RAID.
Najcz˛eściej sa˛ to RAID 0 lub 1 pracujace˛ z dyskami IDE montowanym w klasycznych kompu-
terach PC. RAID 0 realizujac

˛ lustrzana˛ kopie dysków pozwala pozbyć si˛e obawy utraty danych
z powodu awarii dysku, nie ustrzeże nas jednak przed utrata˛ danych na skutek działa ń wirusa
czy włamywacza. Z tym można sobie nieco poradzić poprzez wyj˛ecie dysku i przechowywanie
go w bezpiecznym miejscu. Należy co jakiś czas dyski synchronizować. W przypadku pracy na
rzecz firmy można wykorzystać narz˛edzia synchronizacji plików. Dane za pomoca˛ tych narz˛edzi
sa˛ kopiowane na serwer firmy a na serwerze obowiazuje
˛ już procedura bezpiecze ństwa firmy.
Osoby pracujace
˛ na własny rachunek musza˛ radzić sobie same.
8.2.4. Model rozproszony przechowywania danych

W odróżnieniu od modelu centralnego, w modelu rozproszonym nie ma wyróżnionych miejsc
gromadzenia danych. Każdy uczestnik tego typu sieci oferuje miejsce na dysku dla danych. Mo-
del ten ma szereg zalet. Dane sa˛ rozproszone pomi˛edzy użytkowników, wi˛ec trudno jest dokona ć
całkowitego ich zniszczenia. Należy jednak zadbać, aby konkretny plik z danymi znajdował si˛e
na odpowiednio dużej liczbie komputerów użytkowników. Oczywiście w tym przypadku mamy
do rozwiazania
˛ problem kontroli wersji pliku oraz praw do jego modyfikacji. Wersje można kon-
trolować za pomoca˛ sum kontrolnych md5 lub za pomoca˛ podpisów cyfrowych. Podpisy cyfrowe
moga˛ też pozwolić na określenie, kto dokonywał modyfikacji. System realizujacy˛ te zadania jest
jednak bardzo skomplikowany. Na razie sprawdza si˛e on, w przypadku nie do ko ńca legalnej
dystrybucji plików multimedialnych. W przypadku tego typu plików praktycznie nie zachodza˛
zdarzenia zwiazane
˛ z modyfikacja plików. Plik zawierajacy
˛ film raz włożony do systemu point-
to-point kraży
˛ po nim bez modyfikacji. Z danymi biznesowymi nie zawsze tak b˛edzie. Przy takim
modelu gromadzenia i rozsyłania danych mamy też poważny problem zwiazany ˛ z bezpiecze ń-
stwem komputerów użytkowników. Każdy użytkownik udost˛epnia miejsce do zapisu danych.
Nie zawsze ma kontrol˛e nad tym, co b˛edzie na jego komputerze zapisane. Bezpiecze ństwo po-
winna zapewnić aplikacja, które dołacza˛ go do takiej sieci. Niestety w takich aplikacjach zda-
rzały si˛e bł˛edy, które zostały wykorzystane przez wirusy komputerowe. Bład ˛ w aplikacji może
wykorzystać nie tylko wirus, ale i włamywacz komputerowy. Ma wtedy szans˛e przejać ˛ kontro-
l˛e nad wszystkimi komputerami współpracujacymi ˛ ze soba.˛ W przypadku modelu z centralnym
składowaniem wystarczy odłaczyć ˛ od sieci główny serwer lub serwery i rozpoczać ˛ procedur˛e
naprawcza.˛ W przypadku modelu rozproszonego takie post˛epowanie nie jest możliwe. Należy
powiadomić wszystkich użytkowników, a także znaleźć sposób na uaktualnienie oprogramowa-
nia na wszystkich komputerach, które należałoby ze wzgl˛edów bezpiecze ństwa zainstalować od
poczatku.
˛
8.3. Sieci bezpieczne

Jak już wspominano poprzednio, Internet jest siecia˛ sieci. Chcemy aby nasza sie ć była siecia˛ bez-
pieczna.˛ Tymczasem nie ma jednoznacznej definicji czym jest sieć bezpieczna . Można przyjać, ˛
że bezpieczna sieć to sieć, w której spełnione sa˛ wymagania:
dost˛epności i niezawodności;
integralności przechowywanych i przetwarzanych danych;
poufności i autentyczności.
176 8.3. Sieci bezpieczne
Kiedyś za taka˛ sieć uważało si˛e sieć LAN (Local Area Network). Sieci LAN były małe, obejmo-
wały jedno pi˛etro lub budynek. Dzisiaj sieć może obejmować wiele budynków na różnych krań-
cach świata. Sieci LAN buduja˛ firmy dla własnych potrzeb, powstaja˛ w sieciach osiedlowych.
Różne sa˛ cele budowy tych sieci. Firmom służa˛ one do wsparcia działalności biznesowej, a sieci
osiedlowe moga˛ służyć ich użytkownikom do zabawy. Sieć jest tak bezpieczna, jak bezpieczne
sa˛ komputery przyłaczone
˛ do niej. W przypadku firmy może istnieć centralna polityka określa-
jaca
˛ co na komputerze w sieci LAN może być zainstalowane, a co nie powinno być. Inaczej jest
w sieci osiedlowej. Pracuja˛ tam prywatne komputery i ich właściciele decyduja˛ co na nich jest.
Sieć LAN to nie tylko komputery i ich oprogramowanie; to także urzadzenia,
˛ które posłużyły do
jej zbudowania. Obecnie do budowy sieci LAN wykorzystuje si˛e urzadzenia ˛ pracujace
˛ w stan-
dardzie Ethernet. Standard ten oferuje szereg rozwiaza ˛ ń, które moga˛ podnieść bezpieczeństwo
sieci LAN.
8.3.1. VLAN-y
Sieć LAN można podzielić obecnie na mniejsze kawałki. Pozwala to na zgrupowanie użytkowni-
ków o określonych uprawnieniach we wspólnym LAN-ie. Takie wydzielone LAN-y można bu-
dować w oparciu o dedykowane urzadzenia
˛ dla poszczególnych LAN-ów, lub w oparciu o techni-
k˛e VLAN. Budowa LAN-ów z dedykowanym urzadzeniami˛ jest rozwiazaniem
˛ bardzo bezpiecz-
nym ale i kosztownym. Taniej jest budować sieci w oparciu o VLAN-y. Różne urzadzenia
˛ oferuja˛
różne techniki VLAN-ów. Najprostsza˛ z nich jest podział urzadze
˛ ń na segmenty. Poszczególne
porty sa˛ przypisane do poszczególnych segmentów. Dzi˛eki temu ruch pomi˛edzy dwoma kompu-
terami w różnych segmentach musi przejść poprzez urzadzenie
˛ filtrujace.
˛
IEEE 802.1Q
Do niedawna, problemem było rozszerzenie VLAN-ów na wszystkie urzadzenia.
˛ Standard IE-
EE 802.1Q pozwala budować jednolite VLAN-y w oparciu o urzadzenia
˛ różnych producentów.
Pozwala on zbudować 4096 VLAN-y, w obr˛ebie jednej sieci Ethernet.
Media w sieciach LAN

Sieć LAN to komputery oraz urzadzenia
˛ realizujace
˛ transmisje danych. Pomi˛edzy urzadzeniami
˛
a komputerami musi być zrealizowane połaczenie.
˛ Obecnie w sieciach LAN do budowy poła- ˛
czeń wykorzystuje si˛e kable miedziane, światłowody oraz radio. Każda z tych technik niesie ze
określone zagrożenia.
Kabel koncentryczny Za pomoca˛ tego typu kabli budowano sieci w topologii szyny. Najcz˛e-
ściej używanym kablem był kabel RG 58. Wówczas poszczególne stacje sa˛ oddalone co najmniej
2,5 metra (liczonego po kablu). Maksymalna długość kabla wynosi 185 metrów. Sposób budo-
wy sieci w oparciu o kable koncentryczne powoduje poważne niebezpiecze ństwo. Każda stacja
podłaczona
˛ do kabla otrzymuje wszystkie pakiety, które pojawiaja˛ si˛e na kablu. Wystarczy wi˛ec
przejać˛ jeden z komputerów i za pomoca˛ oprogramowania typu sniffer można podsłuchiwa ć
dowolna˛ transmisje danych. Dodatkowym niebezpieczeństwem jest konieczność wykonania do-
brego uziemienia kabla. W warunkach polskich jest to trudne do uzyskania. Ponieważ kabel taki
łaczy
˛ komputery przyłaczone
˛ do różnych faz zasilania, wi˛ec pomi˛edzy kablem a komputerem
pojawiaja˛ si˛e duże różnice napi˛ecia. Moga˛ prowadzić one do uszkodzeń sprz˛etu, jak również
moga˛ stanowić zagrożenie dla osób pracujacych
˛ przy komputerach.
Skr˛etka kategorii 5 i 5+ Za pomoca˛ tego typu kabli buduj˛e si˛e obecnie wi˛ekszość okablowa-
nia strukturalnego. Sieć LAN zbudowana jest wtedy w topologii gwiazdy. W środku gwiazdy
ulokowane sa˛ urzadzenia
˛ aktywne. Ponieważ połaczenia
˛ sa˛ typu komputer – urzadzenie,
˛ to o da-
nych transmitowanych do komputera decyduja˛ urzadzenia
˛ aktywne. Istnieje także możliwość
podsłuchu, co jest transmitowane w kablu, za pomoca˛ specjalistycznych urzadze
˛ ń.
Urzadzenia
˛ sieci LAN
Sieci bezprzewodowe Buduje si˛e je tam, gdzie położenie kabli jest kosztowne i nie zawsze si˛e
opłaca. Z punktu widzenia sieci LAN najcz˛eściej stosuje si˛e standardy IEEE: 802.11, 802.11a,
802.11b i 802.11g. Centralnym urzadzeniem
˛ lokalnej sieci bezprzewodowej jest punkt dost˛e-
powy (ang. access point) wyposażony w anteny dookólne. Zasi˛eg sieci nie przekracza kilkuset
metrów. Tego typu sieć jest łatwa do podsłuchania. Zdarza si˛e, że nie potrzeba do tego żadnych
specjalnych urzadzeń.
˛ Mechanizmy bezpieczeństwa zastosowane dla celów autoryzacji użytkow-
ników okazały si˛e niewystarczajace.
˛ Zostały one poprawione w standardzie 802.11g, ale dopiero
okaże si˛e w praktyce na ile spełnia˛ swoje zadania.
Huby – jeszcze par˛e lat temu podstawowym urzadzeniem ˛ sieci LAN był hub czyli repeater.
Działanie huba jest proste. Pakiety otrzymane na jednym porcie wysyła do innych. Oznacza to, że
każdy komputer podłaczony
˛ do huba otrzymuje cały ruch przez niego przechodzacy. ˛ Wystarczy
wi˛ec, aby ofiara˛ włamywaczy stał si˛e jeden z komputerów, a po zainstalowaniu programu typu
sniffer b˛eda˛ mieli wglad
˛ do całej sieci. Niektóre huby miały możliwość zdalnego zarzadzania.
˛
Może to stanowić potencjalne niebezpieczeństwo, gdyż bardzo cz˛esto pozostawione sa˛ domyślne
hasła. Grozi to przej˛eciem kontroli nad urzadzeniem
˛ poprzez nieuprawnione osoby. Ponieważ
huby maja˛ dość ubogie możliwości zwiazane
˛ z zarzadzaniem,
˛ to stopień zagrożenia nie jest
wysoki. Może si˛e jednak zdarzyć że złośliwy włamywacz wyłaczy
˛ cz˛eść lub wszystkie porty na
hubie, co spowoduje przerw˛e w pracy sieci.
Przełaczniki
˛ Sa˛ to obecnie podstawowe urzadzeniami
˛ wykorzystywane do budowy sieci LAN.
Przełaczniki
˛ ucza˛ si˛e adresów MAC urzadze˛ ń przyłaczonych
˛ do ich poszczególnych portów. Po-
zwala im to na efektywne kierowanie pakietów. Otrzymany pakiet przełacznik ˛ wysyła wyłacz-˛
nie do urzadzenia,
˛ które ma go otrzymać. Utrudnia to możliwość podsłuchiwania, co si˛e dzieje
w sieci, przez dowolny komputer pracujacy ˛ w tej sieci. Przełaczniki
˛ można podzieli ć na dwie
grupy: zarzadzalne
˛ i niezarzadzalne.
˛ Przełaczniki
˛ niezarzadzalne,
˛ jak sama nazwa wskazuje, nie
maja możliwości zarzadzania.˛ Przenosza˛ tylko ruch w sieci. Przełaczniki
˛ zarzadzalne
˛ pozwa-
laja˛ na ustawienie różnych opcji zależnych od możliwości przełacznika.
˛ Najcz˛eściej możliwe
jest podzielenie przełacznika
˛ na VLAN-y oraz zbieranie statystyk ruchu z poszczególnych por-
tów. W cz˛eści przełaczników
˛ możliwe jest mirrorowanie ruchu jednego portu na drugi. Opcja
ta może być wykorzystana przez potencjalnego włamywacza do podsłuchania ruchu wybranego
178 8.4. Łacza
˛ WAN
komputera. Aby temu zapobiec należy zadbać o bezpieczeństwo urzadzeń.

˛ Powinny mieć one
pozmieniane domyślne hasła i ustawienia protokołu SNMP.
8.4. Łacza
˛ WAN
Obecnie sieci LAN posiadaja˛ podłaczenia
˛ do Internetu lub połaczenia
˛ z innymi sieciami LAN.
Połaczenia
˛ te nie zawsze można zrealizować wykorzystujac ˛ technologi˛e sieci LAN. Rozwiazana
˛
sieci LAN maja˛ z reguły zbyt mały zasi˛eg. Połaczenia
˛ te można zbudować w oparciu o dzierżaw˛e
dedykowanych łacz.
˛ Moga˛ być to dzierżawione linie telefoniczne, światłowody, kanały cyfrowe,
linie napowietrzne. Każde z tego typu łacz˛ niosa˛ za soba˛ określone możliwości zapewnienia
bezpieczeństwa.
Linie telefoniczne
Linie telefoniczne nie oferuja˛ dużego pasma transmisji. Pozwalaja˛ na realizacj˛e krótkich łaczy
˛
rz˛edu kilometrów. Linie tego typu nie oferuja˛ wysokiego poziomu bezpiecze ństwa. Można je
w stosunkowo prosty sposób podsłuchiwać. Wystarczy zainstalować podsłuch obok linii gdzieś
na trasie jej przebiegu. Podsłuchy tego typu nie należa˛ do kosztownych. Wykrycie tego typu
podsłuchu może być bardzo trudne, a zatrudnienie ochrony do strzeżenia linii bardzo kosztowne.
Aby realizować bezpieczna˛ transmisje poprzez tego typu linie należy posłużyć si˛e technikami
kryptograficznymi – szyfrować dane.
Linie światłowodowe
Linie światłowodowe zapewniaja˛ duże pasmo transmisji na bardzo duże odległości. Same w so-
bie zapewniaja˛ wysoki poziom bezpieczeństwa. Jest je dość trudno podsłuchać. Do niedawna
nie było to w ogólne możliwe. Sa˛ one jednak dość kosztowne. Budowa tego typu linii lub ich
dzierżawa może być zbyt kosztowna dla pojedynczej firmy. Ponadto w warunkach polskich coraz
trudniej otrzymać dzierżaw˛e takich linii.
Kanały cyfrowe
Kanały cyfrowe zapewniaja˛ określona˛ przepływność pomi˛edzy dwoma punktami. Kanały może
zestawić operator telekomunikacyjny. Generalnie sa˛ dwa typy kanałów: kanały cyfrowe zesta-
wione dla potrzeb transmisji danych realizowane w technikach Frame Relay i ATM oraz kanały
zestawiane dla potrzeb transmisji głosu. Niezależnie od wyboru typu kanału, jego bezpiecze ń-
stwo jest zależne od operatora, od którego kanał jest dzierżawiony. W zasadzie najlepiej jest za-
łożyć, że kanał nie jest bezpieczny i dla podniesienia bezpiecze ństwa danych transmitowanych
poprzez kanał cyfrowy należy je szyfrować.
Linie napowietrzne
Obecnie na rynku dost˛epna jest szeroka gama urzadze
˛ ń pozwalajacych
˛ na zrealizowanie bezprze-
wodowej transmisji danych. Bezpieczeństwo tych rozwiazań
˛ jest zależne od użytych technik.
Jeśli transmisja b˛edzie realizowana za pomoca˛ technik laserowych, to jest szansa na ogranicze-
nie możliwości podsłuchu. W przypadku technik radiowych ograniczenie możliwości podsłuchu
jest bardzo trudne ze wzgl˛edu na rozproszenie wiazki.
˛ W zasadzie, aby unikna˛ć kłopotów należy
transmitowane dane szyfrować.
8.5. Bezpieczne połaczenia

˛ sieci
Sieci LAN sa˛ dołaczane
˛ do Internetu lub innych sieci LAN. Takie połaczenie ˛ niesie za soba˛ –
oprócz korzyści takich jak dost˛ep do różnych danych zawartych w Internecie – także niebezpie-
czeństwa. Łaczność
˛ z inna˛ siecia˛ oznacza możliwość dost˛ep do jej zasobów jak i dost˛ep z jej
komputerów do naszej sieci. Jeśli ta˛ siecia˛ jest Internet, to potencjalny dost˛ep możliwy jest pra-
wie dla całego świata. Aby ograniczyć potencjalne niebezpieczeństwa zwiazane ˛ z połaczeniem
˛
z inna˛ siecia,˛ należy określić a nast˛epnie wdrożyć polityk˛e bezpieczeństwa. Polityka musi defi-
niować, co ma być udost˛epnianie, a co nie, oraz do jakich zasobów moga˛ si˛egać użytkownicy
sieci. W realizacji tych celów moga˛ pomóc nam różnorodne rozwiazania ˛ techniczne.
8.5.1. Protokoły sieciowe

Komputery pracujace ˛ w obecnych sieciach używaja˛ protokołu IP w wersji 4. Znaczna wi˛ek-
szość zagadnień zwiazanych
˛ z bezpieczeństwem zwiazanych
˛ jest z protokołem IP. Protokół ten
powstał dla potrzeby sieci wojskowych i miał działać w zamkni˛etym środowisku. Nie wprowa-
dzono bezpośrednio do niego mechanizmów poprawiajacych ˛ bezpiecze ństwo transmisji. Różne
jego niedoskonałości posłużyły jako mechanizmy realizacji ataków. Najbardziej znane rodzaje
ataków sieciowych to:
Skanowanie sieci – jest to wst˛ep do złośliwego. Skanowanie sieci pozwala atakujacemu ˛
wykryć właczone
˛ komputery i urzadzenia
˛ sieciowe. W zależności od rodzaju skanu możli-
we jest też wykrycie otwartych portów TCP/UDP, co pozwala potencjalnemu napastnikowi
określić, które usługi sa˛ aktywne. Skanowanie sieci można przyrównać do wykonywania
zwiadu przed decydujacym ˛ atakiem;
Fałszowanie adresu (ang. adress spoofing) – jest to atak, w którym sfałszowany zostaje
adres nadawcy. Zamiast orginalnego adresu wstawiany jest adres z wewn˛etrznej sieci. Atak
ten pozwala na oszukanie prostych filtrów ochronnych opartych na adresach;
Routing źródłowy (ang. Source Routing) – w protokole TCP/IP można podać tras˛e, przez
jaka˛ ma przejść pakiet aby dotrzeć do miejsca docelowego. Ponieważ możliwość ta bar-
dzo rzadko jest wykorzystywana, to wi˛ekszość urzadzeń
˛ sieciowych ignoruje pakiety ze
znacznikami routingu źródłowego co uniemożliwia różnorodne ataki;
Denial of Service – atak polegajacy ˛ na wysyłaniu serii pakietów IP, który powoduje spo-
wolnienie lub zaprzestanie pracy usługi, do której pakiety sa˛ wysyłane. Odmiana ataku
Distributed Denial of Service (DDOS) jest wykonywana z wielu komputerów równocze-
śnie.
Przej˛ecie sesji – atak polegajacy ˛ na przej˛eciu przez osob˛e nieuprawniona˛ (hackera)sesji
użytkownika. Od momentu przej˛ecia sesji hacker uzyskuje dost˛ep do zasobów z upraw-
nieniami osoby, której sesje zawłaszczył;
180 8.5. Bezpieczne połaczenia
˛ sieci
Przepełnienie bufora – atak polegajacy ˛ na wykorzystaniu niedoskonałości stosu TCP/IP

implementowanego w urzadzeniach
˛ sieciowych. Odpowiednio spreparowany zestaw pa-
kietów jest w stanie przepełnić bufor w stosie, co najcz˛eściej prowadzi do odci˛ecia urza- ˛
dzenia od sieci. Efektem dodatkowym może być reset urzadzenia.
˛
Przed cz˛eścia˛ z tych ataków można si˛e uchronić, jeśli wykorzysta si˛e możliwości urzadzeń,
˛
które przenosza˛ ruch pakietów IP.
8.5.2. Routery
Urzadzeniami,
˛ które realizuja˛ połaczenia
˛ mi˛edzysieciowe, sa˛ routery. Usytuowanie routerów na
styku sieci LAN z Internetem lub pomi˛edzy sieciami LAN czyni z niego bardzo ważny element
bezpieczeństwa. Wi˛ekszość routerów jest optymalizowana pod katem ˛ transmisji pakietów IP.
Bardzo cz˛esto jako funkcj˛e dodana˛ posiadaja˛ one możliwość zakładania tzw. list dost˛epu (ang.
access list). Pozwalaja˛ one na tworzenie różnych filtrów. Filtry tworzone na routerach moga˛ wy-
korzystywać pola zawarte w nagłówkach protokołu IP oraz TCP i UPD. Filtry moga˛ obniżać
wydajność routera, gdyż każdy pakiet przed przesłaniem musi być przeanalizowany pod ka- ˛
tem zgodności z filtrem. Im dłuższy filtr, tym przetwarzanie pojedyńczego pakietu trwa dłużej.
Przydatnym filtrem, który można zastosować na routerach, jest filtr antyspofingowy. Pozwala on
na ograniczenie znacznej ilości ataków wykonywanych na sieć. Router jako urzadzenia ˛ pośred-
niczace˛ w transmisji pakietów pomi˛edzy sieciami musi być także urzadzeniem ˛ bezpiecznym.
Routery maja˛ możliwość zdalnego zarzadzania,
˛ co może pozwolić nieuprawnionym osobom na
przej˛ecie kontroli nad nimi. Jeśli jest to możliwe należy cz˛esto zmieniać domyślne ustawienia
zwiazane
˛ z hasłami, a także utworzyć filtry, które ogranicza˛ możliwość zdalnego zarzadzania
˛
tylko to wybranych komputerów. Routery wymieniaja˛ z innymi routerami tablice routingu. Czy-
nia˛ to za pomoca˛ protokołów routingu. Za pomoca˛ takich protokołów można podesła ć fałszywe
tablice. Nieautoryzowanych zmian w tablicach routingu można uniknać ˛ stosujac
˛ mechanizmy
bezpieczeństwa zawarte w protokołach dynamicznego routingu. Protokoły takie jak RIP-2 czy
OSPF pozwalaja˛ na autoryzacj˛e rozsyłanych tablic. Pozwala to uniknać ˛ zaakceptowania fałszy-
wych danych. W wi˛ekszości routerów można też określić, poprzez które to interfejsy b˛eda˛ wy-
mieniane informacje o routingu. W połaczeniu
˛ z filtrami pozwala to na ograniczenia do minimum
możliwości zaakceptowania przez router fałszywych tablic routingu.
8.5.3. Firewall
Termin firewall czyli ściana ogniowa pochodzi z techniki budowlanej. Terminem określa si˛e
specjalnie skonstruowana˛ ścian˛e, która ma zapobiegać rozprzestrzenianiu si˛e ognia. W sieciach
komputerowych terminem firewalla określa si˛e oprogramowanie, które jest usytuowane na sty-
ku sieci LAN z inna˛ siecia˛ np. Internetem i ma zapobiegać przedostawaniu si˛e pożaru z innej
sieci do chronionej sieci LAN. Usytuowania firewalla jest podobne jest do usytuowania routera.
Z tego powodu firewall dość cz˛esto jest lokowany tuż za routerem lub wyst˛epuje jako połacze-
˛
nie funkcjonalności routera i firewalla w jednym pudełku. Firewall podobnie jak router posiada
możliwość filtrowania pakietów. Zasadnicza różnica jest w możliwości pami˛etania stanu sesji.
Filtr pakietów z pami˛ecia˛ określa si˛e mianem statefull inspection. Tego typu filtr pozwala na
pełniejsza˛ kontrol˛e przechodzacych
˛ pakietów. Jeśli zostana˛ wykryte pakiety nie przynależne do
danej lub do żadnej, sesji to moga˛ być ignorowane. W wypadku resetu firewalla wszystkie sesje
sa˛ zrywane i musza˛ być od poczatku˛ zainicjowane.
Mimo, że przyjmuje si˛e, że firewall broni dost˛epu z zewnatrz
˛ do chronionej sieci, to jednak
równie dobrze może blokować dost˛ep na zewnatrz ˛ sieci. Ta właściwość pozwala na określenie,
jakie usługi moga˛ być udost˛epniane z sieci LAN. Te możliwości techniczne firewalla pozwalaja˛
na zbudowanie polityki dost˛epu, która zawiera co ma być z chronionej sieci dost˛epne na zewnatrz˛
jak również co zewnatrz
˛ jest dost˛epne w sieci.
Na firewallach integruje si˛e także szereg innych usług. Firewalle sa˛ obecnie bramami VPN,
pozwalaja˛ autoryzować użytkowników oraz logować zdarzenia. Potrafia˛ także przekierowywać
ruch z niektórych usług. Przykładem może być poczta elektroniczna. Bardzo cz˛esto firewall prze-
kierowuje ruch z poczty elektronicznej do specjalnego hosta, na którym działa skaner antywiru-
sowy lub filtr antyspamowy. Pozwala to lepiej chronić sieć.
Firewalle potrafia˛ także realizować usługi zwiazane
˛ z translacja˛ adresów. Ponieważ adresów
IP zaczyna brakować to w sieciach LAN, powszechne si˛e stało używanie adresów prywatnych
(klasy 172.16.0.0 – 172.31.255.255, 10.0.0.0 - 10.255.255.255, 192.168.0.0 – 192.168.255.255).
Aby jednak możliwy był dost˛ep z sieci LAN wykorzystujacej ˛ prywatna˛ pul˛e adresów, stosuje
si˛e techniki NAT ( ang. Network Address Translation) oraz PAT (ang. Port Adress Translation).
Pozwalaja˛ one komputerom z niepublicznymi adresami IP korzystać z Internetu. Użycie prywat-
nych adresów w sieci LAN podnosi jej bezpieczeństwo. Niemożliwe jest bowiem dostanie si˛e
z Internetu do dowolnego komputera. Zagrożone sa˛ wylacznie ˛ komputery, które w jakiś sposób
sa˛ widoczne w sieci Internet.
Podstawowym założeniem przy stosowaniu firewalli jest to, że sieci można podzielić na cz˛eść
bezpieczna˛ i "obca"˛ niebezpieczna.˛ Firewall chroni bezpieczna˛ przed atakami z sieci niebez-
piecznej - obcej ale nie chroni przed atakami, których źródło znajduje si˛e wewnatrz˛ bezpiecznej
sieci.
NAT
NAT jest technika˛ mapowania adresu IP na adres IP w skali 1 do 1. Oznacza to, że aby udost˛epni ć
dost˛ep wszystkim komputerom z sieci LAN, musielibyśmy posiadać tyle adresów, ile mamy
komputerów. W tym momencie numeracja przy użyciu prywatnych adresów IP traci nieco sens.
Numeracja 1 do 1 odkrywa przed potencjalnym napastnikiem cała˛ nasza˛ sieć. Technika NAT
ma sens stosowania w odniesieniu do serwerów. W przypadku komputerów jako użytkowników
sieci jest ona zbytnia˛ rozrzutnościa.˛
PAT
PAT albo IP Masquerading pozwala na mapowanie 1 do wielu. Pozwala to wielu komputerom
posiadajacych
˛ prywatne adresy IP korzystać z dost˛epu do Internetu. W technice tej wykorzysty-
wany jest fakt, że sesja TCP/IP składa si˛e z par (adres źródła, port źródła) (adres docelowy, port
docelowy). W przypadku translacji NAT na urzadzeniu˛ realizujacym
˛ translacj˛e podmieniany jest
tylko adres źródłowy, natomiast w przypadku translacji PAT podmieniany jest adres źródłowy
i port źródłowy. Ponieważ portów może być ponad 65 000, to teoretycznie tyle komputerów mo-
że być ukrytych za jednym adresem IP. PAT ukrywa struktur˛e sieci LAN przed potencjalnym
napastnikiem. Nie łatwo jest określić, ile komputerów jest schowanych za pojedynczym adre-
˛ sieci
10.0.0.1,2345 193.4.5.7,2345
175.10.2.7,80 175.10.2.7,80
175.10.2.7,80 175.10.2.7,80
10.0.0.1,2345 193.4.5.7,2345
NAT
10.0.0.2,2345 193.4.5.8,2345
175.10.2.7,80 175.10.2.7,80
175.10.2.7,80 175.10.2.7,80
10.0.0.2,2345 193.4.5.8,2345
Rysunek 8.1: Działanie NAT.
sem. Niestety ta technika ma problemy z usługami korzystajacymi

˛ ze stosu protokołów UDP/IP.
10.0.0.1,4368 193.4.5.6,23456
175.10.2.7,80 175.10.2.7,80
175.10.2.7,80 175.10.2.7,80
10.0.0.1,4368 193.4.5.7,23456
PAT
10.0.0.2,1683 193.4.5.6,15307
175.10.2.7,80 175.10.2.7,80
175.10.2.7,80 175.10.2.7,80
10.0.0.2,1683 193.4.5.8,15307
Rysunek 8.2: Działanie PAT.
8.5.4. Proxy
Serwer proxy jest to program wyst˛epujacy ˛ w roli pośrednika dla innego programu działajacego ˛
na innym komputerze. Serwery proxy moga˛ być także pośrednikami dla konkretnych protoko-
łów. Najcz˛eściej spotykanymi sa˛ serwery proxy dla www. Zasada działania serwera proxy jest
bardzo prosta. Program żadaj
˛ acy
˛ dost˛epu do danych przesyła swe zapytanie do serwera proxy
a on wysyła je w świat – do komputera, który wysłał zapytanie. Serwer proxy może być jaw-
nie zdefiniowany w konfiguracji programu, lub też przekierowanie zapyta ń do serwera proxy
może być realizowane przez router lub firewall bez wiedzy użytkownika programu. W takiej sy-
tuacji serwer proxy określa si˛e jak transparent proxy. Serwery proxy ukrywaja˛ przed światem
zewn˛etrznym wewn˛etrzna˛ struktur˛e sieci. Moga˛ także poprawiać jakość pracy sieci. Np serwery
proxy www moga˛ zapisywać na dyskach wyniki zapytań, a na nast˛epne zapytanie odpowiadać
korzystajac
˛ z już zgromadzonych danych. Powoduje to zmniejszenie ruchu na łaczu ˛ do Internetu
(patrz rysunek 8.4).
Sieæ LAN INTERNET

Proxy
server
Rysunek 8.3: Działanie serwera proxy.
Rysunek 8.4: Działanie buforujacego

˛ serwera proxy .
8.5.5. Systemy IDS

Firewalle, serwery proxy oraz routery z filtrami potrafia˛ zapewnić dost˛ep do i z sieci na podstawie
konkretnych protokołów i usług. Nie potrafia˛ zaś ocenić, czy przez dopuszczona˛ usług˛e nie jest
dokonywany jakiś atak. Takie funkcje potrafia˛ realizować systemy IDS (ang. Intrusion Detection
Systems). Istnieja˛ dwa typy systemów IDS:
sieciowe;
systemowe.
IDS sieciowy (ang. network-based) bazuje na badaniu ruchu sieciowego. IDS pracuje podobnie
jak sniffer. Pobiera z sieci pakiety (na poziomie warstwy fizycznej) poprzez adapter (kart˛e) sie-
ciowy ustawiony w trybie pasywnym promiscous. Tryb ten umożliwia przechwytywanie wszyst-
kich pakietów podróżujacych
˛ w danym segmencie sieciowym. W przypadku gdy IDS zostanie
podłaczony
˛ podłaczony
˛ do przełacznika
˛ to na port, do którego jest przyłaczony,
˛ musi by ć kopio-
wany ruch z portu, który ma być nadzorowany. Najcz˛eściej w ten sposób nadzorowany jest port,
poprzez który odbywa si˛e transmisja danych z siecia˛ zewn˛etrzna.˛ Przechwycone pakiety sa˛ na-
st˛epnie poddawane analizie w czasie rzeczywistym. Wymaga to sporych mocy obliczeniowych
od urzadzenia
˛ realizujacego
˛ analiz˛e. Przechwycone pakiety moga˛ być analizowane pod katem: ˛
dopasowywanie wzorców – dopasowywane sa˛ pakiety jak i ich zawartość, która jest po-
˛ sieci
równywana z baza˛ sygnatur;

badanie cz˛estości zdarzeń i przekraczania ustalonych limitów ich ilości;
wykrywania odst˛epstw od standardów RFC określajacych ˛ działanie protokołów;
wykrywania korelacji pomi˛edzy pomniejszymi zdarzeniami;
wykrywania anomalii statystycznych.
Najcz˛eściej realizowane jest dopasowywanie wzorców, gdyż jest to technicznie najłatwiejsze
w realizacji. Podobnie ma si˛e z wykrywaniem odst˛epstw od definicji protokołów. Określenie
limitów zdarzeń wymaga sporej wiedzy od administratora. Pewne nietypowe zachowania sieci
nie musza˛ oznaczać zagrożenia, a moga˛ być tylko specyfika˛ jej funkcjonowania. Tak samo ma si˛e
rzecz z wykrywaniem anomalii statystycznych oraz korealacji pomi˛edzy zdarzeniami. W razie
wykrycia ataku system IDS może wykonać jedna˛ ze zdefiniowanych przez administratora akcji.
Może to być:
email do administratora z informacja˛ o zdarzeniu;
aktualizacja filtrów na routerze, która powoduje blokad˛e dalszego ataku;
aktualizacja filtrów na firewallu, która powoduje blokad˛e dalszego ataku.
Wykrywanie zdarzeń w trybie rzeczywistym oraz możliwość aktualizacji filtrów pozwala na bar-
dzo szybka˛ automatyczna˛ reakcj˛e. Niestety, możliwe staje si˛e wtedy przeprowadzenie takiego
ataku, po którym automatycznie ustawione filtry odetna˛ możliwość funkcjonowania niektórym
pożadanym
˛ usługom.
IDS systemowy (określany czasami Host IDS) jest instalowany sa˛ na chronionych kompute-
rach. Podstawowym zadaniem takiego IDS-a jest wykrywanie nietypowych zachowa ń w obr˛ebie
komputera. Mniej istotne jest źródło ich pochodzenia. Analizie poddawana jest komunikacja
mi˛edzy wybranymi procesami, kontrolowana jest integralność kluczowych plików systemowych
oraz analizowane sa˛ logi. W wypadku wykrycia niepożadanych˛ zdarze ń o ich wystapieniu
˛ in-
formowany jest administrator sieci lub użytkownik komputera. Działanie tego typu systemów
IDS jest ściśle zwiazane
˛ z systemami operacyjnymi komputerów, na których te systemy pracuja.˛
Bardzo cz˛esto możliwa jest też analiza ruchu sieciowego wchodzacego ˛ do komputera. Ma to t˛e
zalet˛e, że wykrywa to zdarzenia wewnatrz ˛ sieci LAN, które nie moga˛ być nadzorowane przez
sieciowy IDS. Wymaga to jednak rezerwy mocy komputera, na którym ten system ma pracowa ć.
8.5.6. Firewalle personalne

Kilka lat temu podstawowym celem ataków były serwery sieciowe i pracujace ˛ na nich serwisy.
Wraz z rozwojem Internetu w sieci pojawiła si˛e ogromna liczba komputerów. Twórcy systemów
operacyjnych nie przywiazywali
˛ dużej wagi do bezpiecze ństwa. Na systemach uniksowych wła- ˛
czone były wszystkie serwisy sieciowe niezależnie od tego, czy były potrzebne czy nie. Systemy
Windows firmy Microsoft realizowały podobna˛ zasad˛e. Ułatwiało to życie użytkownikom, bo
wystarczyło właczyć
˛ komputer i wszystko działało. Sieci w firmach maja˛ administratorów oraz
sa˛ chronione centralnymi firewallami. Inaczej jest ze zwykłymi posiadaczami komputerów. Po-
nieważ zacz˛eli korzystać z Internetu, to ich komputery stały si˛e potencjalnymi celami ataków.
Jako odpowiedź na to powstały rozwiazania
˛ nazywane Personal Firewall. Podstawowa różnica
w stosunku do klasycznych firewalli polega na tym, że chronia˛ one pojedynczy komputer w sieci,
a nie sieć. W zależności od producenta moga˛ mieć one funkcjonalność zarówno filtra pakietów
jak i IDS systemowego. Moga˛ też być wyposażane w klientów sieci VPN. Wi˛ekszość z personal-
nych firewalli posiada predefiniowana˛ polityk˛e bezpieczeństwa, która w znacznym stopniu pod-
nosi bezpieczeństwo pojedynczego komputera. Możliwe jest też centralne zarzadzanie

˛ polityka˛
bezpieczeństwa na firewallach zainstalowanych na komputerach firmowych. Tego typu rozwia- ˛
zania dostarczaja˛ producenci firewalli chroniacych
˛ sieci. Pozwala to podnieść bezpieczeństwo
poszczególnych komputerów wewnatrz ˛ sieci, jak wreszcie na obj˛ecie polityka˛ bezpiecze ństwa
komputerów użytkowników mobilnych korzystajacych ˛ z laptopów jak również obj˛ecie polityka˛
bezpieczeństwa użytkowników pracujacych
˛ na rzecz firmy w domu.
8.5.7. UTM
UTM (ang. Unified threat management jest terminem określajacym ˛ nowa˛ klas˛e urzadzeń
˛ do
realizacji komplesowej ochrony sieci. Urzadzenia
˛ te w jednej skrzynce łacz ˛ a˛ w sobie funckje
firewall-a, bramy VPN, systemu IDS, sytemu chrony antywirusowej i inne. Zakres funckji jest
zwiazany
˛ z producenem konkretnego rozwiazania.
˛ Ich najwi˛eksza˛ zaleta˛ jest kompleksowość re-
alizowanej ochrony oraz łatwość zarzadzania.
˛ Niestety właczenie
˛ wszystkich dost˛epnych funkcji
ochronnych najcz˛eściej powoduje spadek ich wydajności.
8.6. Kryptografia
Ponieważ prawie niemożliwe jest zbudowanie sieci, w której nie dało by si˛e zrealizowa ć podsłu-
chu, trzeba pomyśleć o innym sposobie zabezpieczenia transmisji. Z pomoca˛ przychodza˛ techni-
ki kryptograficzne. Nie zabezpieczaja˛ one w 100 % transmisji, ale utrudniaja˛ możliwość jej od-
czytania w momencie przechwycenia. Techniki kryptograficzne dostarczaja˛ także mechanizmy
potwierdzania tożsamości oraz integralności przesyłanych danych. Najcz˛eściej kryptografia jest
kojarzona z szyfrowaniem. Dane lub tekst w postaci jawnej sa˛ przekształcane za pomoca˛ funkcji
szyfrujacej
˛ do postaci zaszyfrowanej. Z przekształceniem tym zwiazany˛ jest jakiś klucz lub para
kluczy. Przekształcenie to może być jednokierunkowe lub dwukierunkowe. W przypadku prze-
kształceń jednokierunkowych bardzo trudne jest odzyskanie tekstu jawnego z zaszyfrowanego
tekstu. Jest to wykorzystywane przy przechowywaniu haseł. Szyfry dwukierunkowe pozwalaja˛
odtworzyć tekst jawny z zakodowanej informacji. W zależności od użytego algorytmu szyfro-
wania możliwe jest odzyskanie treści wiadomości za pomoca˛ tego samego klucza (szyfry sy-
metryczne) lub innego klucza z pary (szyfry asymetryczne). Poniżej sa˛ omównione podstawowe
poj˛ecia zwiazane
˛ z kryptografia.˛
Szyfr – jest to algorytm oraz klucz. Algorytm to umowny sposób zamiany tekstu jawnego
na tekst zaszyfrowany. Algorytm określa przekształcenie, które zostanie wykonane przy uży-
ciu klucza. Ilustruje to nast˛epujacy
˛ przykład algorytmu: bierzemy znak tekstu, odszukujemy go
w tekście gazety. Zliczamy, który to jest znak i zamieniamy na numer jego wystapienia.˛ Klu-
czem, który zostanie użyty do szyfrowania b˛edzie gazeta. Jak widać algorytm jest prosty i każdy
może go poznać, ale aby zaszyfrować i odszyfrować tekst potrzebne jest te same wydanie gazety.
W technice cyfrowej mamy do czynienia z bitami. Kluczem najcz˛e ściej jest jakaś liczba losowa
o określonej długości. Najcz˛eściej spotykane wartości to 40, 64, 128, 512 lub 1024 bity. Można
przyjać,
˛ że im dłuższy klucz, tym zaszyfrowana wiadomość jest trudniejsza do odczytania przez
osoby nieupoważnione.
186 8.6. Kryptografia
Funkcja skrótu - tworzy unikalna˛ dla danej wiadomości sum˛e kontrolna. ˛ Wiadomość może
mieć dowolna˛ długość, funkcja skrótu wygeneruje zawsze liczb˛e o ustalonej długości (np. 126
lub 160 bitów). Funkcja skrótu uzyskana bezpiecznym algorytmem (np. SHA-1) ma dwie bardzo
ważne własności: każda zmiana w wiadomości (nawet jednego bitu) powoduje nieprzewidywal-
na˛ zmian˛e wartości skrótu oraz praktycznie niemożliwe jest obliczenie oryginalnej wiadomości
na podstawie jej skrótu (jednokierunkowość). Dodatkowo dwie różne wiadomości nie powinny
"wygenerować" takiej samej wartości funkcji skrótu. W praktyce nie jest to możliwe do zapew-
nienia. Im mniejsze jest prawdopodobieństwo otrzymania powtórzenia wartości skrótu z różnych
wiadomości tym funkcja jest lepsza. Funkcje skrótu sa˛ wykorzystywane przy sprawdzaniu za-
chowywania integralności przesyłanych danych.
Szyfr symetryczny - szyfr z jednym kluczem. Bezpieczeństwo wiadomości w systemie syme-

trycznym opiera si˛e na utrzymaniu w tajemnicy klucza służacego
˛ jednocześnie do szyfrowania,
jak i do rozszyfrowywania przesyłanej wiadomości. W idealnym przypadku klucz powinny znać
tylko dwie osoby: nadawca i odbiorca.
Szyfr asymetryczny Powstał w wyniku prac matematycznych nad teoria˛ liczb i funkcji asyme-
trycznych, czyli takich, które łatwo obliczyć (zakodować), ale bardzo trudno obliczyć ich funkcja˛
odwrotna˛ (złamać kod). W efekcie złamanie kodu asymetrycznego o dostatecznie długości klu-
czy może wymagać pracy najsilniejszych komputerów świata przez setki lat. W praktyce, szyfr
asymetryczny to szyfr z para˛ kluczy: prywatnym (znanym tylko jego właścicielowi) i publicznym
(dost˛epnym dla każdego), obydwa klucze sa˛ ze soba˛ powiazane
˛ matematycznie. Wiadomość za-
szyfrowana jednym z kluczy (publicznym) może być rozszyfrowana tylko drugim (prywatnym),
co pozwala na bezpieczna˛ korespondencj˛e w kierunku "świat zewn˛etrzny" - właściciel klucza
prywatnego. W przypadku podpisu cyfrowego nast˛epuje zamiana: nadawca szyfruje skrót wia-
domości kluczem prywatnym, a każda zainteresowana osoba może go zweryfikowa ć kluczem
publicznym.
SSL
SSL jest protokołem opracowanym przez firm˛e Netscape. Jest on otwartym standardem, dzi˛eki
czemu jest zaimplementowany mi˛edzy innymi w wi˛ekszości przegladarek ˛ internetowych. Obec-
nie sa˛ w użyciu dwie specyfikacje tego protokołu wersja: 2.0 i 3.0. Protokół SSL zapewnia trzy
podstawowe funkcje:
prywatność - dane transmitowane przy użyciu protokołu SSL sa˛ szyfrowane; obejmuje
to też potwierdzenie tożsamości serwera za pomoca˛ certyfikatów cyfrowych, co utrudnia
możliwość podszycia si˛e pod serwer;
integralność przesyłanych danych przy użyciu sum kontrolnych - utrudnia to dokonanie
wandalizmu na transmitowanych danych.
SSL pierwotnie został opracowany do zabezpieczenia transmisji pomi˛edzy serwerem a przegla- ˛
darka WWW. Pierwsza˛ przegladark ˛ a,˛ która posiadała wsparcie dla SSL była przegladarka
˛ firmy
Netscape. Ponieważ na stosie protokołów TCP/IP warstwa SSL znajduj˛e si˛e pomi˛edzy warstwa˛
aplikacji a warstwa˛ transportowa, ˛ to możliwe jest wykorzystanie protokołu SSL dla różnych
aplikacji. Umieszczenie SSL nad stosem TCP/IP pozwala wykorzystać istniejace ˛ internetowe
standardy bez konieczności ustawienia SSL jako protokołu aplikacji. SSL jest obecnie wykorzy-
stywany przez wiele aplikacji, jak telnet czy ftp.
Cyfrowe certyfikaty SSL
Za pomoca˛ protokołu SSL klient może potwierdzić tożsamość serwera, do którego si˛e łaczy. ˛
W tym celu protokół SSL korzysta z algorytmu RSA, oraz certyfikatów nadawanym serwerom
przez jedna˛ z niezależnych organizacji certyfikujacych
˛ ( Thawte, Verisign). Organizacje te maja˛
upoważnienie od RSA Data Security Inc. właściciela algorytmu szyfrowania RSA. Oczywiście,
aby otrzymać certyfikat należy wystapić
˛ o jego otrzymanie. Certyfikat taki jest podpisany przez
organizacj˛e, która go wydała. Wi˛ekszość przegladarek
˛ posiada list˛e centrów certyfikujacych
˛ i jest
w stanie automatycznie zweryfikować poprawność certyfikatu serwera, z którym połaczenie˛ na-
st˛epuje. Ponieważ certyfikaty podpisywane przez organizacje certyfikujace ˛ sa˛ płatne, wi˛ec nie
zawsze sa˛ stosowane. Każda organizacja może samodzielnie wygenerować certyfikat. W takim
wypadku, po uzyskaniu połaczenia
˛ z serwerem należy certyfikat obejrzeć i samodzielnie podjać ˛
decyzje o akceptacji.
Szyfrowanie z kluczem publicznym
W czasie transmisji danych wykorzystywany jest jednorazowy klucz sesji. Aby go uzgodni ć,
program klienta oraz serwer wykorzystuja˛ technik˛e kluczy publicznych. W uproszczeniu me-
chanizm ustanawiania sesji wyglada ˛ nast˛epujaco:
˛
klient wysyła komunikat Client.Hello zawierajacy ˛ informacje o kliencie oraz klucz pu-
bliczny (najcz˛eściej generowany w czasie instalacji);
serwer analizuje dane. Jeśli wersja SSL oraz mechanizmy szyfrowania si˛e zgadzaja,˛ od-
syła zaszyfrowany kluczem publicznym klienta komunikat Server.Hello. W odpowiedzi
znajduje si˛e klucz publiczny serwera;
klient po otrzymaniu odpowiedzi odsyła komunikat zawierajacy ˛ żadanie
˛ przesłania klucza
sesji. Komunikat jest zaszyfrowany za pomoca˛ klucza publicznego serwera;
po otrzymaniu komunikatu od klienta serwer odsyła zaszyfrowany kluczem publicznym
klienta klucz sesji, który b˛edzie wykorzystany do transmisji danych.
Ten sposób przekazywania klucza jest wykorzystywany nie tylko przez SSLa. Można go spotka ć
także w innych technikach kryptograficznych używanych w Internecie.
Szyfrowanie RSA w SSL SSL wykorzystuje technologi˛e potwierdzania serwerów i szyfro-

wania opracowana˛ przez RSA Data Security, Inc., która jest właścicielem algorytmu RSA. Ze
wzgl˛edu na ograniczenia exportowe USA, maksymalna długość klucza wynosiła do niedawna
40 bitów. Obecnie ograniczenia zostały osłabione. Długość klucza, jaki można stosować, wyno-
si 128 bitów. Ograniczenie to nie dotyczy USA gdzie można wykorzystywać klucz o długości
512 bitów. Im dłuższy klucz tym wyższy poziom bezpiecze ństwa. Poziom rośnie wykładniczo
wraz ze wzrostem długości klucza. Pozwolenie na używanie klucza 128 bitowego w wersjach
eksportowych produktów kryptograficznych prawdopodobnie jest zwiazane ˛ z tym, że rzad
˛ USA
dysponuje komputerami, które sa˛ w stanie rozszyfrować dane zaszyfrowane takim kluczem w
bardzo krótkim czasie. Jednakże moc obliczeniowa zwykłych komputerów też wzrasta i naj-
pewniej w niedalekiej przyszłości stosowanie klucza 128 bitowego też nie b˛edzie rozwiazaniem
˛
gwarantujacym
˛ rozsadny
˛ poziom bezpieczeństwa.
8.6.1. VPN
Sieć komputerowa pozwala na zdalny dost˛ep do zasobów. Nie zawsze wymiana danych pomi˛e-
dzy komputerami odbywać si˛e b˛edzie za pomoca˛ protokołu http z szyfrowaniem SSL. Może
si˛e zdarzyć konieczność użycia użycia innych aplikacji, np. już działajacych
˛ w sieciach LAN.
Koszty modyfikacji aplikacji tak by – na przykład – korzystały z mechanizmów protokołu SSL
moga˛ okazać si˛e bardzo duże. Rozwiazaniem
˛ dla tej sytuacji jest zastosowanie technik VPN
(ang. Virtual Private Network).
Koncepcja VPN
VPN - jest rozszerzeniem prywatnej sieci LAN najcz˛eściej chronionej firewallem na wybrane
komputery znajdujace
˛ si˛e w sieci publicznej. Osiagane
˛ jest to za pomoca˛ dwukierunkowych
kanałów służacych
˛ transmisji danych przez sieci publiczne (najcz˛e ściej Internet) z zachowa-
niem bezpieczeństwa przesyłanych danych. Podczas transmisji poprzez kanał dane sa˛ szyfro-
wane, dzi˛eki czemu nawet po ich przechwyceniu przez niepowołane osoby ich odczytanie jest
bardzo utrudnione, a czasami prawie nie możliwe, gdyż proces deszyfrowania wymaga użycia
odpowiedniego klucza. W ramach koncepcji VPN możliwe jest sprawdzanie tożsamości zdalne-
go użytkownika poprzez uwierzytelnianie kryptograficzne. Dodatkowo, dane sa˛ szyfrowane oraz
enkapsulowane w pakietach IP, co pozwala na przeźroczyste przenoszenie danych transmitowa-
nych w różnych protokołach.
Architektura VPN
Przy użyciu VPN-ów można realizować różnorodne architektury połaczeń,

˛ które sa˛ najcz˛eściej
kombinacja˛ trzech podstawowych typów:
klient do klienta,
klient do sieci,
sieć do sieci.
W przypadku transmisji typu klient do klienta możliwa jest bezpieczna wymiana danych pomi˛e-
dzy dwoma komputerami. Trudno jest to kwalifikować do VPNu, ale moga˛ zdarzyć si˛e sytuacje,
że taki tryb transmisji b˛edzie potrzebny. VPN powstały głównie jako odpowiedź na potrzeb˛e za-
pewnienia bezpiecznej transmisji danych pomi˛edzy użytkownikami znajdujacymi ˛ si˛e poza firma˛
(np. w podróży) a siecia˛ firmy. Pierwsze standardy VPN odpowiadały właśnie tym oczekiwa-
niom. Okazało si˛e, że taniej jest wykorzystywać jako platform˛e transmisji Internet. Połaczenie
˛
do lokalnego dostawcy Internetu jest znacznie tańsze niż połaczenie
˛ do siedziby firmy, która to
można znajdować si˛e nawet za granica.˛ Wkrótce okazało si˛e, że budowa bezpiecznych połacze˛ ń
pomi˛edzy oddziałami firm za pomoca˛ dedykowanych łaczy ˛ jest równie kosztowna, wi˛ec rozsze-
rzono standardy VPN na potrzeby budowy połacze ˛ ń typu sieć do sieci.
Elementy składowe połacze

˛ ń VPN
W skład połaczenia
˛ VPN wchodza˛ nast˛epujace˛ elementy:
serwer VPN - komputer lub dedykowane urzadzenie,
˛ które akceptuje połaczenia
˛ od klien-
tów VPN. Serwer ten może obsługiwać zarówno połaczenia
˛ zdalnego dost˛epu połaczenia
˛
od pojedynczych klientów jak i połaczenia
˛ VPN pomi˛edzy sieciami;
klient VPN - komputer lub dedykowane urzadzenie,
˛ który inicjuje połaczenie
˛ VPN z ser-
werem. W wielu wypadkach różnica pomi˛edzy serwerem a klientem jest czysto umowna;
tunelowanie - proces enkapsulacji, czyli umieszczanie pakietów w specjalnych ramkach,
które umożliwiaja˛ transport tunelem. Mechanizm enkapsulacji pozwala transportowa ć da-
ne poprzez tunel w dowolnym protokole.
połaczenie
˛ VPN - jest to połaczenie,
˛ które emuluje transmisj˛e punkt-punkt z szyfrowaniem
przesyłanych danych. Do obu punktów moga˛ być dołaczone˛ badź
˛ pojedyncze komputery,
badź
˛ też całe sieci.
Zasada działania VPN

Zasada działania wirtualnej sieci prywatnej polega na zestawieniu wirtualnego kanału komuni-
kacyjnego wewnatrz˛ publicznej sieci, do której ma si˛e ograniczone zaufanie, a poprzez która˛ b˛e-
da˛ przesyłane zaszyfrowane dane. Transmisja kanałem komunikacyjnym jest obsługiwana przez
protokół tunelujacy
˛ (ang. tunneling protocol). Zasada działania wirtualnego kanału polega na
zestawieniu logicznego połaczenia
˛ mi˛edzy klientem VPN zlokalizowanym na przykład na kom-
puterze użytkownika i serwerem VPN. Kanał pozwala na bezpieczna˛ prac˛e w taki sposób, jakby
istniało bezpośrednie połaczenie
˛ z siecia˛ prywatna,˛ w której zlokalizowany jest serwer. Podczas
inicjacji połaczeń
˛ wirtualnej sieci prywatnej oprogramowanie klienta komunikuje si˛e z bramka˛
(serwerem) VPN. Kiedy serwer VPN pozytywnie zweryfikuje uprawnienia, oprogramowanie ze-
stawi odpowiednie połaczenie.
˛ Pakiety przesyłane przez tunel b˛eda˛ opatrywane odpowiednimi
nagłówkami zależnymi od sieci, poprzez która˛ b˛edzie zestawione połaczenie.
˛ Kiedy pakiety do-
tra˛ do serwera na drugim końcu tunelu, nagłówek pakietu zostanie usuni˛ety, a informacje b˛eda˛
ostatecznie przekazane do właściwego odbiorcy w sieci lokalnej.
Bezpieczeństwo tuneli VPN

Bezpieczeństwo tuneli VPN jest ściśle zwiazane
˛ z protokołami użytymi do ich tworzenia i szy-
frowania. Obecnie dost˛epnych jest kilka standardów VPN. Nie sa˛ one ze soba˛ zgodne, należy
wi˛ec zadbać o to, aby po stronie klienta i serwera były zainstalowane te same protokoły.
Standardy VPN
Patrzac
˛ na siedmiowarstwowy model ISO/OSI można przyjać, ˛ że sa˛ trzy kategorie VPN-ów.
W warstwie drugiej można umieścić produkty oparte na protokołach PPTP (Point-to-Point Tun-
neling Protocol) i L2TP (Layer 2 Tunneling Protocol), które obecnie sa˛ stosowane w wi˛ekszości
połaczeń
˛ wirtualnych sieci prywatnych. W warstwie trzeciej można umieścić produkty zbudowa-
ne na protokole IPSec. Produkty VPN warstwy czwartej wykorzystuja˛ również kapsułkowanie
i szyfrowanie, ale produkty zwiazane
˛ z ta˛ warstwa˛ sa˛ mniej uniwersalne, gdyż zapewniaja˛ moż-
liwość bezpiecznej transmisji danych dla konkretnej aplikacji, np. poczty elektronicznej.
PPTP (Point-to-Point Tunneling Protocol) Opracowany został wspólne przez Microsoft i US

Robotics, PPTP jest rozszerzeniem PPP (Point-to-Point Protocol), standardowego protokołu ko-
munikacyjnego Internetu, używanego do asynchronicznej transmisji łaczem
˛ szeregowym punkt-
punkt bez ograniczania przepływności. PPP funkcjonuje w warstwie drugiej, wi˛ec połaczenie
˛
PPTP, które umożliwia enkapsulacje pakietów PPP, pozwala przesyłać pakiety IP, IPX i Net-
BEUI (NetBIOS Extended User Interface). Oprogramowanie darmowego klienta PPTP jest do-
st˛epne na wi˛ekszość systemów operacyjnych Microsoftu, a także na systemy Linux. W syste-
mach MS-Windows jako protokół szyfrujacy ˛ wykorzystywany jest MPPE (Microsoft Point to
Point Encryption). Jest oparty na standardowym systemie kryptograficznym RSA (Rivest, Sha-
mir, Adleman), który obsługuje szyfrowanie 40-bitowe lub 128-bitowe. Można dyskutowa ć, czy
jest to wystarczajacy
˛ poziom szyfrowania.
L2TP (Layer 2 Tunneling Protocol) L2TP jest dziełem organizacji zajmujacej ˛ si˛e standary-
zacja˛ w Internecie IETF (Internet Engineering Task Force). Powstał poprzez połaczenie
˛ PPTP
oraz L2F (Layer 2 Forwarding), który to opracowała firma Cisco. L2F zaprojektowany przez Ci-
sco Systems jest przeznaczone głównie do obsługi transmisji mi˛edzy routerami. Protokół L2TP,
podobnie jak PPTP, pozwala na transport ramek PPP (Point-to-Point Protocol). Zaleta˛ L2TP jest
możliwość transmisji danych po sieci IP, lecz również po sieciach X.25, Frame Relay oraz ATM
(Asynchronous Transfer Mode).
IPSec (Internet Protocol Security) IPSec powstał z inicjatywy firmy Cisco System jest proto-
kołem warstwy trzeciej i jak sama nazwa wskazuje zapewnia szyfrowanie na poziomie protoko-
łu IP. IPSec tak naprawd˛e nie jest protokołem, tylko zbiorem otwartych standardów. W ramach
standardów IPSec zdefiniowanych jest kilka nowych formatów pakietów: nagłówek autentyka-
cyjny (authentication header AH), który zapewnia integralność przesyłanych danych, oraz obszar
danych - encapsulating security payload (ESP), zapewniajacy ˛ dodatkowo poufność transmisji.
Parametry IPSec pomi˛edzy dwoma urzadzeniami˛ moga˛ być negocjowane poprzez centralna˛ jed-
nostk˛e Internet Key Exchange (IKE, znana˛ wcześniej jako Internet Security Association Key
Management Protocol, lub ISAKMP/Oakley). IKE używa cyfrowych certyfikatów do autoryza-
cji urzadzenia,
˛ umożliwiajac
˛ tworzenie dużych sieci wirtualnych. Możliwe jest użycie statycznie
zdefiniowanych współdzielonych kluczy zamiast certyfikatów. Zastosowanie tego do dużych sie-
ci jest raczej trudne w realizacji, gdyż dla każdego połaczeniu
˛ należało by wygenerowa ć oddziel-
na˛ par˛e kluczy. IPSec jest zaprojektowany do bezpiecznego tworzenia tuneli przez sie ć IP mi˛edzy
ochranianymi sieciami lokalnymi, lub pomi˛edzy klientem a siecia˛ chroniona.˛ IPSec wykorzystu-
je w transmisji 168-bitowe szyfrowanie Triple DES, a także umożliwia szyfrowanie pakiet po
pakiecie.
IPSec pracuje w dwóch trybach, transportowym i tunelowym (tunnel mode) – szczegóły na
rysunku 8.5. W trybie transportowym kodowane sa˛ w pakiecie wyłacznie ˛ dane, natomiast ory-
ginalny nagłówek IP pozostaje niezmieniony. Powoduje to konieczność dodania kilku bajtów
do każdego pakietu. Nieruszony nagłówek IP umożliwia urzadzeniom˛ sieci publicznej określa-
nie adresu poczatkowego
˛ i docelowego każdego pakietu. Pozwala to urzadzeniem
˛ pośrednim
bezproblemowo przetwarzać dodatkowe informacje z nagłówka IP (np. informacje o gwarancji
jakości usług). Z drugie strony, pozostawienia niezakodowanego nagłówka umożliwia nieautory-
zowanym użytkownikom prowadzenie analizy ruchu pomi˛edzy poszczególnymi w˛ezłami. Maja˛
jednak oni nikłe szanse na stwierdzenie, jakiego typu była ta transmisja.
Tryb Tunelowy
Nag³ówek
IP DANE
Nowy Nag³ówek Nag³ówek

Nag³ówek IP
DANE
IPSec IP
Zaszyfrowane
Tryb Transportowy
Nag³ówek DANE
IP
Nag³ówek Nag³ówek
IP IPSec DANE
Zaszyfrowane
Rysunek 8.5: Tryby pracy protokołu IPsec.
W trybie tunelowym oryginalny pakiet wejściowy IP jest w całości szyfrowany, stajac ˛ si˛e
zawartościa˛ z danymi w nowym pakiecie IP. Tryb ten umożliwia urzadzeniom˛ sieciowym prac˛e
jako IPSec proxy. IPSec proxy przejmuje niezaszyfrowany ruch od hostów, szyfruje go i wy-
syła wzdłuż tunelu IPSec. IPSec proxy na drugim końcu tunelu deszyfruje oryginalny pakiet
IP i przesyła go do docelowego miejsca w systemie. Główna˛ zaleta˛ tego rozwiazania ˛ jest fakt,
że docelowe systemy nie musza˛ być modyfikowane, by korzystać z usług IPSec. W trybie tu-
nelowym prawie niemożliwe jest dokonanie analizy ruchu poprzez osoby nieuprawnione, gdyż
w tym trybie można jedynie określić końce tunelu, a nie właściwego nadawc˛e i odbiorc˛e infor-
macji. Z drugiej strony, jeśli oryginalny nagłówek IP zawierał dodatkowe informacje o jakości
ruchu stana˛ si˛e one niewidoczne dla hostów pośredniczacych
˛ w transmisji.
Security Association (SA bezpieczne połaczenie)
˛ jest relacja˛ pomi˛edzy dwoma lub wi˛ecej
jednostkami, która określa w jaki sposób jednostki używać b˛eda˛ systemów zabezpieczeń do
bezpiecznej komunikacji. Security Association jest relacja˛ jednokierunkowa. ˛ Oznacza to, że dla
każdej pary komunikujacych
˛ si˛e urzadze
˛ ń należy zdefiniować przynajmniej dwa bezpieczne po-
łaczenia
˛ - z A do B i z B do A. Security Association jest para˛ składajac ˛ a˛ si˛e z losowo wybranego
numeru Security Parameter Index (SPI) i adresu IP odbiorcy. Kiedy system wysyła pakiet, który
wymaga ochrony IPSec, przeglada ˛ SA w swojej bazie, uruchamia odpowiedni proces i wtedy
wkłada właściwy SPI do nagłówka IPSec. Kiedy w˛ezeł wyposażony w IPSec otrzymuje pakiet,
przeglada
˛ SA po adresie docelowym i SPI w swojej bazie i wtedy analizuje pakiet IPSec posia-
da mechanizmy stwierdzajace, ˛ czy SA jest ustawione, natomiast samo z siebie nie ma mecha-
192 8.7. Autoryzacja i potwierdzanie tożsamości
nizmów pozwalajacych˛ takie połaczenia

˛ budować. Za negocjacje i budow˛e połaczeń
˛ odpowie-
dzialny jest Internet Key Management Protocol (IKMP). IKE negocjuje bezpieczne połaczenie ˛
dla IPSec. W ramach procesu negocjacji każda jednostka sprawdza si˛e nawzajem i ustanawia
wspólne klucze.
Aby połaczenie
˛ IPSec mogło być zestawione, oba końce, które b˛eda˛ połaczone
˛ musza˛ si˛e
wzajemnie autentyzować. W ramach IKE dopuszczone jest kilka sposobów uwierzytelniania.
Ważne jest to że obie jednostki musza˛ wyrazić zgod˛e na wspólny protokół autentyzacyjny, który
zbuduja˛ w procesie negocjacyjnym. Obecnie zaimplementowane sa˛ trzy mechanizmy autentyza-
cji:
Pre-shared keys - takie same klucze pre-instalowane sa˛ na każdym hoście.
IKE autentykuje każdy w˛ezeł przez wysyłanie skróconych danych klucza, które zawieraja˛
klucze typu pre-shared. Public key cryptography - czyli każda strona generuje pseudo
losowy numer i koduje go w kluczu publicznym drugiej strony.
Digital signature (podpis elektroniczny) - każde urzadzenie
˛ podpisuje cyfrowo zbiór da-
nych i wysyła je do drugiej strony.
IPSec jest obecnie dost˛epny w wielu urzadzeniach
˛ sieciowych takich jak routery i przełaczniki
˛
oraz systemach operacyjnych. Implementacje IPSec sa˛ dost˛epne w systemach Windows 2000,
XP, Linux, FreeBSD. Nie wszystkie chca˛ ze soba˛ współpracować. Wynika to na przykład z braku
wsparcia dla niektórych odmian algorytmów szyfrujacych.˛ Przykładem może by ć implementacja
FreeSWAN na linuxa, która nie pozwala na użycie pojedynczego DESa.
8.7. Autoryzacja i potwierdzanie tożsamości

Kodowanie danych w czasie transmisji, trzymanie ich na serwerach z systemami RAID nie za-
pewnia nam pewności, że do danych nie si˛egaja˛ osoby postronne. Cz˛eściowa˛ pewność możemy
uzyskać określajac,
˛ które komputery maja˛ dost˛ep do pewnych zasobów. Jest to jednak nie do
końca wystarczajace,
˛ bo w domu przy komputerze może usiaść˛ dziecko a firmie inny pracownik.
Aby mieć pewność, że do danych ma dost˛ep osoba lub instytucja do tego uprawniona, należy
zastosować mechanizmy autoryzacji i potwierdzania tożsamości. Można to osiagn˛ ać
˛ za pomoca˛
haseł, certyfikatów, kluczy prywatnych i innych metod.
8.7.1. Konto i hasło

Standardowa˛ metoda˛ potwierdzania tożsamości jest konto w systemie. Konto pozwala na okre-
ślenie tożsamości użytkownika, opisania jego praw w systemie, czasu jego ważności. Wymusza
to na prowadzenie bazy kont. Konto stanowi par˛e: identyfikator użytkownika oraz hasło. Sys-
tem kont wychodzi z założenia, że tylko osoba korzystajaca ˛ z danego identyfikatora zna wła-
ściwe hasło. Hasło powinno być tajne. W tej chwili konta można prowadzić na pojedynczych
komputerach, np. na komputerach pracujacych ˛ pod kontrola˛ systemu Windows XP. Gdy liczba
komputerów jest wi˛eksza, to należy rozważyć utworzenie centralnej bazy kont. Istnienie takiej
bazy oznacza konieczność przesyłania identyfikatora użytkownika oraz jego hasła poprzez sieć.
Stanowi to potencjalne zagrożenie dla systemu kont.
Bezpieczeństwo konta jest zwiazane
˛ z hasłem. Hasło w wi˛ekszości systemów jest przecho-
wywane w postaci zaszyfrowanej. Najcz˛eściej do zaszyfrowania hasła sa˛ używane algorytmy
jednokierunkowe. Z tekstu jawnego, jakim jest hasło, tworza˛ one ciag

˛ odpowiadajacych
˛ mu zna-
ków. Aby potwierdzić hasło w czasie logowania do sytemu użytkownik jest proszony o podanie
swojego identyfikatora a nast˛epnie swojego hasła. Hasło jest szyfrowane i porównywane z za-
szyfrowanym hasłem przechowywanym w systemie. Jeśli weryfikacja przebiegnie prawidłowo,
to użytkownik uzyskuje dost˛ep do przyznanych mu zasobów.
Bezpieczne hasła
Sposób przechowywania haseł nie pozwala na ich łatwe odczytanie. Niestety pami˛e ć ludzka
jest zawodna i jako hasło wybiera si˛e proste w zapami˛etaniu teksty. Najcz˛e ściej sa˛ to trywial-
ne hasła typu imi˛e żony, dziecka czy teściowej. Takie hasła jest bardzo łatwo złamać metodami
słownikowymi. Z drugie strony bardziej skomplikowane hasła staja˛ si˛e trudne do zapami˛eta-
nia. Może to prowadzić do sytuacji zapisywanie haseł i naklejania ich na monitorach oraz pod
spodem klawiatur. Obniża to bezpieczeństwo całego systemu, bo nie mamy pewności, że osoba,
która si˛e autoryzowała w systemie, jest osoba˛ właściwa.˛ Ważnym czynnikiem wpływajacym ˛ na
bezpieczeństwo jest długość hasła. Hasła krótkie sa˛ podatne na ataki polegajace
˛ na przeszuka-
niu wszystkich możliwych kombinacji znaków. To nie zajmuje zbyt dużo czasu przy obecnych
mocach obliczeniowych komputerów. Dodanie jednej litery powoduje wydłużenie przeszuka-
nia 24–krotnie. Obecnie, niektóre systemy unixowe nie pozwalaja˛ założyć haseł krótszych niż
pi˛ecioznakowe. Dodatkowo wśród znaków musi si˛e pojawić co najmniej jeden lub dwa znaki
nie b˛edace
˛ litera.˛ Zwi˛eksza to znaczaco
˛ zbiór przeszukiwania, ale także utrudnia zapami˛etanie
hasła.
Hasła jednorazowe
Nie zawsze można posłużyć si˛e dwukrotnie tym samym hasłem. Powodów może być wiele. Jed-
nym z nich jest brak zaufania do miejsca, z którego realizuje si˛e połaczenie
˛ do systemu. Rozwia-
˛
zaniem sa˛ hasła jednorazowe. Każdemu użytkownikowi generuje si˛e list˛e jednorazowych haseł.
Użytkownik po użyciu hasła do zalogowania skreśla je z listy. Podczas nast˛epnego logowania
musi wykorzystać nast˛epne hasło. Każde hasło można wykorzystać tylko raz. Gdy lista haseł zo-
stanie wyczerpana, trzeba użytkownikowi stworzyć nast˛epna.˛ Niestety, każdy użytkownik musi
nosić przy sobie list˛e haseł i zawsze korzystać z nich w odpowiedniej kolejności. Pomini˛ecie
choćby jednego hasła z listy uniemożliwi nast˛epne logowanie. Problemem jest także dystrybu-
cja haseł. Użytkownik musi otrzymać wydrukowana˛ list˛e haseł. Oznacza to, że musi osobiście
zgłosić si˛e do administratora lub też zestaw haseł musi być do niego wysłany listem poleconym.
8.7.2. Biometria
Konta wymuszaja˛ na użytkownikach konieczność pami˛etania haseł lub zapisywania ich w note-
sach. Nie jest to wygodne a zapisywanie nie jest bezpieczne. Rozwiazaniem
˛ tego problemu moga˛
być metody biometrii. Kryminalistyka posługuje si˛e od wielu lat odciskami palców. Obecnie sa˛
rozwiazania
˛ techniczne pozwalajace ˛ na szybkie skanowanie odcisków palców i dokonywania na
ich podstawie autoryzacji. Teoretycznie rozwiazywało
˛ by to w całkowicie problem potwierdza-
nia tożsamości, ale zdarzaja˛ si˛e ludzie z amputowanymi r˛ekoma lub palcami. Możliwe jest już
także podrabianie odcisków palców. Podobne możliwości oferuje badanie siatkówki oka ale jest
194 8.8. Podpis cyfrowy
na świecie troch˛e ludzi niewidomych, który utracili oczy. Pomimo tych niedogodności, metody
te sa˛ stale rozwijane. Czy zastapi
˛ a˛ hasła, trudno dziś powiedzieć.
8.7.3. SSL i potwierdzanie tożsamości klienta

SSL teoretycznie umożliwia wykupienia sobie prywatnego certyfikatu przez klienta. Certyfikat
ten można stosować dla potrzeb potwierdzanie tożsamości klienta. Ze wzgl˛edu na koszty ra-
czej trudno jest oczekiwać, by certyfikat był masowo wykupywany przez osoby prywatne i małe
firmy. Nie jest wi˛ec to metoda masowo używana, ale nie należy wykluczać możliwości jej zasto-
sowania dla potrzeb weryfikacji użytkowników.
8.7.4. Certyfikaty
Certyfikaty można wykorzystać nie tylko w SSL-u. Ich zastosowanie może być znacznie wi˛ek-
sze. Można je wykorzystywać do szerszej weryfikacji użytkowników. Firmy moga˛ zredukować
problem kosztów poprzez uruchomienie własnego centrum certyfikujacego.
˛ Centrum takie może
świadczyć usługi dla potrzeb firmy, jak i jej partnerów.
8.8. Podpis cyfrowy

W relacjach biznesowych konieczne jest zawieranie umów. Ważność umowy jest ściśle zwiazana
˛
z podpisem - obecnie odr˛ecznym. Liczba osób uprawniona do składania podpisów w danej fir-
mie jest ograniczona. Firmy współpracujace˛ ze soba˛ moga˛ znajdować si˛e w różnych zakatkach
˛
świata i trudno jest oczekiwać ciagłych
˛ podróży uprawnionych osób w celu składania podpi-
su. Cz˛eściowo ten problem rozwiazano
˛ za pomoca˛ uznawania dokumentów przesłanych faksem.
Rozwiazać
˛ ten problem może podpis cyfrowy.
8.8.1. Definicja podpisu cyfrowego

Definicja podpisu cyfrowego wg PN-I-02000 (Polska Norma) jest nast˛epujaca:
˛ "Przekształcenie
kryptograficzne danych umożliwiajace
˛ odbiorcy danych sprawdzenie autentyczności i integral-
ności danych oraz zapewniajace
˛ nadawcy ochron˛e przed sfałszowaniem danych przez odbiorc˛e."
8.8.2. Wymagania dla podpisu cyfrowego

Podpis cyfrowy musi spełniać te same warunki co podpis odr˛eczny, tzn. powinien być trudny lub
niemożliwy do podrobienia, umożliwiać weryfikacj˛e i na trwałe łaczyć
˛ si˛e z dokumentem. Sama
idea podpisu cyfrowego pochodzi z roku 1976. Stała si˛e możliwa do zrealizowania dzi˛eki post˛e-
pom w kryptografii. Przy podpisach cyfrowych używa si˛e kryptografii klucza publicznego (np.
RSA) opartej na dwóch dużych liczbach pierwszych: kluczach prywatnym i publicznym. Taka˛
par˛e unikalnych kluczy przypisuje si˛e każdemu użytkownikowi systemu. Warunkiem koniecz-
nym jest założenie, że dost˛ep do klucza prywatnego posiada tylko i wyłacznie
˛ jego właściciel
(oraz tylko on używa go do podpisywania dokumentów), natomiast odpowiadajacy ˛ mu klucz
publiczny musi być osiagalny
˛ dla każdej zainteresowanej osoby (np. poprzez umieszczenie na
dedykowanym serwerze kluczy publicznych). W ten sposób odbiorca podpisanej wiadomości

może zweryfikować otrzymany dokument wraz z podpisem. Podpis cyfrowy powinien zapew-
niać:
uniemożliwienie podszywanie si˛e innych pod dana˛ osob˛e (uwierzytelnienie osoby, auten-
tyfikacja),
zapewnienie wykrywalności wszelkiej zmiany w danych transakcji (integralność transak-
cji),
zapewnienie niemożliwości wyparcia si˛e podpisu przez autora,
umożliwienie weryfikacji podpisu przez osob˛e niezależna.˛
8.8.3. Infrastruktura podpisu cyfrowego

Matematyka dla realizacji podpisu cyfrowego gotowa jest od wielu lat. Problemem podstawo-
wym jest stworzenie infrastruktury podpisu cyfrowego. Infrastruktura potrzebna jest dla potrzeb
całkowitego ustalenia właściciela klucza. W przypadku małej organizacji można posłużyć me-
todami kurierskimi dla celów wymiany kluczy publicznych. W świecie podpisów odr˛ecznych
w przypadku watpliwości
˛ dokumenty potwierdza si˛e u notariusza. Podobnie jest przy podpi-
sie cyfrowym. W warunkach powszechnego stosowania podpisu konieczne jest wprowadzenie
do schematu tzw. zaufanej trzeciej strony (ang. Trusted Third Party). Trzecia strona zwana Orga-
nem Certyfikacji b˛edzie musiała zarejestrować w swojej bazie danych wszystkich użytkowników
podpisu cyfrowego i wygenerować im klucze. Oczywiście generacja kluczy musi być poprze-
dzona fizyczna˛ identyfikacja˛ petenta, który wpierw okazuje swój dowód osobisty, a nast˛epnie
otrzyma spersonalizowana˛ kart˛e mikroprocesorowa˛ z zapisanymi na niej kluczami. Klucze b˛eda˛
rozprowadzane wraz dołaczonymi
˛ do nich certyfikatami. Po otrzymaniu wiadomości podpisanej
certyfikowanym kluczem, jej weryfikacja nieco si˛e wydłuża, gdyż najpierw należy sprawdzi ć po-
prawność wiadomości kluczem publicznym nadawcy, a nast˛epnie sprawdzamy certyfikat klucza,
tym razem używajac ˛ klucza publicznego Organu Certyfikacji. Oczywiście musimy ufać Organo-
wi Certyfikacji, że nie pomylił si˛e podczas ustalania tożsamości nadawcy.
8.8.4. Działanie podpisu cyfrowego

Realizacja podpisu cyfrowego składa si˛e z dwóch faz. W fazie pierwszej wyznaczany jest skrót
wiadomości (np. za pomoca˛ algorytmu MD5). Skrót jest szyfrowany przy użyciu prywatnego
klucza za pomoca˛ algorytmu kryptografii z kluczem publicznym (np. RSA) . Zaszyfrowany skrót
jest traktowany jako podpis wiadomości. Jest do niej dołaczany
˛ i razem z nia˛ wysyłany do odbior-
cy. W drugiej fazie odbiorca weryfikuje podpis (patrz rysunek 8.7). Podobnie jak w przypadku
nadawcy wyznaczany jest skrót wiadomości oraz dekodowany jest podpis wiadomości przy uży-
ciu klucza publicznego nadawcy. Po odszyfrowaniu podpisu powinien zosta ć otrzymany skrót
wiadomości. Jeśli zdekodowany skrót oraz wyliczony sa˛ sobie równe, to oznacza, że wiadomość
podpisała właściwa osoba.
8.8.5. Wdrożenie podpisu cyfrowego

Podpis cyfrowy może w przyszłości mieć ogromne znaczenie dla prowadzenia działań gospo-
darczych. Pozwala on na szybkie zawieranie umów poprzez sieć, co obniży ich koszty. Pozwala
196 8.8. Podpis cyfrowy
Wiadomoœæ
Skrót Funkcja Podpis

Wiadomoœci Funkcja skrótu wiadomoœci szyfruj¹ca wiadomoœci
Podpisany
prywatny klucz
Rysunek 8.6: Podpisywanie wiadomości.
Skrót
Wiadomoœæ Funkcja skrótu Jeœli oba skróty s¹
wiadomoœci
identyczne to
Podpis Funkcja Skrót wiadomoœæ jest
wiadomoœci szyfruj¹ca wiadomoœci prawdziwa.
Jeœli ró¿ne to
wiadomoœæ
Podpisany zosta³a
publiczny klucz podrobiona.
Rysunek 8.7: Weryfikacja podpisu wiadomości.
także na weryfikacj˛e użytkowników. Wszystko to b˛edzie zależne od powszechności wdrożenia.

Ustawy zwiazane˛ z podpisem cyfrowym narzucaja˛ na firmy ogromne wymagania. Jednym z nich
wiaże
˛ si˛e ze wdrożeniem PKI (ang. Public Key Infrastructure). PKI składa si˛e z trzech głównych
elementów :
Urz˛edu Rejestracji (ang. Registration Authority - RA), który dokonuje weryfikacji danych
użytkownika a nast˛epnie jego rejestracji;
Urz˛edu Certyfikacji (ang. Certification Authority - CA), który wydaje certyfikaty cyfrowe.
Wydanie jest poprzedzone procesem identyfikacji zgłaszajacego. ˛ Po pozytywnym rozpa-
trzeniu zgłoszenia nast˛epuje wydanie certyfikatu wraz z data˛ jego rozpatrywania.
Repozytoriów kluczy, certyfikatów i list unieważnionych certyfikatów (ang. Certificate
Revocation Lists - CRLs). Typowa jest realizowana w oparciu o protokół LDAP. Podsta-
wowym celem repozytorium jest udost˛epnianie publicznych kluczy, certyfikatów oraz dat
ich unieważnienia. LDAP to jedno z rozwiaza˛ ń. Inne rozwiazania
˛ moga˛ być oparte o pro-
tokoły X.500, HTTP, FTP, czy też wykorzystywać poczt˛e elektroniczna.˛ Certyfikat może
zostać unieważniony przed data˛ jego wygaśni˛ecia. Przyczyny tego moga˛ być rozmaite np.
ślub i zmiana nazwiska lub zmiana adresu poczty elektronicznej czy ujawnienie klucza
prywatnego lub kradzież PINu. W takich przypadkach CA powinno odwołać certyfikat
i umieścić jego numer seryjny na ogólnodost˛epnej liście CRL.
Jak widać, PKI jest kombinacja˛ środków technicznych, oprogramowania oraz regulaminów.
Zalecane jest aby RA i CA były oddzielnymi instytucjami. RA ma za zadanie sprawdza ć dane
użytkowników. W przedsi˛ebiorstwie rol˛e RA może pełnić dział kadr. Wydawaniem certyfikatów
zajmować si˛e może pion informatyki. Certyfikat cyfrowy składa si˛e z klucza publicznego wła-
ściciela, który jest podpisany przez centrum certyfikacji, oraz danych o właścicielu. Format cer-
tyfikatu jest opisany przez norm˛e X.509. Wydanie certyfikatu przez CA wiaże ˛ si˛e ono głównie
z przeprowadzeniem procesu generacji kluczy i powiazaniem ˛ ich z danymi użytkownika oraz
umieszczeniem danych w repozytorium. Repozytorium jest już typowym oprogramowaniem.

Aby to wszystko sprawnie funkcjonowało potrzebne sa˛ także aplikacje, które bez problemów b˛e-
da˛ si˛e odwoływać do zasobów PKI. Szacuje si˛e, że koszty zbudowania własnej infrastruktury dla
potrzeb podpisu elektronicznego, sa˛ na tyle wysokie, że zaczyna si˛e to opłaca ć przy co najmniej
10 000 użytkownikach. W warunkach rentowności polskich firm może być to znacznie wi˛eksza
liczba. Rozwiazaniem
˛ jest korzystanie z usług zewn˛etrznych operatorów, którzy utworza˛ ogól-
nodost˛epne centra PKI. W praktyce, ze wzgl˛edu na koszty, firmy wykupuja˛ klucze wyłacznie ˛
dla tych pracowników, którym jest to niezb˛edne. Należy zwrócić uwag˛e, że darmowe certyfikaty
gwarantuja˛ zazwyczaj tylko tyle, że ich posiadacz był w stanie odebrać poczt˛e wysłana˛ na adres
zawarty w certyfikacie i nic wi˛ecej.
8.9. Przelewy bankowe

Obecnie dokonanie przelewu bankowego nie wymaga udania si˛e do oddziału banku. Można to
zrealizować dostajac˛ si˛e do konta poprzez internet lub poprzez specjalny numer telefoniczny
i aplikacje. Dost˛ep poprzez jest najcz˛eściej realizowany przy pomocy przegladarek ˛ www uży-
wajacych
˛ protokołu SSL ze 128 bitowym kluczem szyfrujacym. ˛ Dodatkowo użytkownik musi
podać swój identyfikator i hasło. Hasło może być generowane za pomoca˛ specjalnego urza- ˛
dzenia zwanego tokenem. Każdy bank stosuje swój własny system tokenów. Najcz˛e ściej sa˛ to
rozwiazania
˛ sprz˛etowe wygladem
˛ przypominajace ˛ kalkulator. Pozwalaja˛ one na wygenerowa-
nie hasła ważnego przez stosunkowo krótki czas. Podnosi to bezpiecze ństwo systemu, bo tym
samym hasłem nie da si˛e posłużyć dwa razy. Alternatywa,˛ która˛ oferuja˛ banki dla celów re-
alizowanie przelewów, jest dost˛ep do konta poprzez specjalna˛ aplikacj˛e i numer telefoniczny.
Bezpieczeństwo tego typu transakcji jest zwiazane
˛ z aplikacja,˛ która˛ dostarcza bank.
Bibliografia

198
Skorowidz
1 ATM, 7, 31, 45–48, 178

adresacja, 46
10 Gigabit Ethernet, 25
AFI, 46
10G Base-CX4, 26
ESI, 47
10G Base-ER, 25
Adresacja, 46
10G Base-EW, 25
DDC, 46
10G Base-LR, 25
E.164, 46
10G Base-LW, 25
HO-DSP, 47
10G Base-LX4, 25
IDC, 46
10G Base-SR, 25
prefiksy, 46
10G Base-SW, 25
10G Base-T, 26 SEL, 47
CLP, 49
Forum, 46
A GFC, 49
Active Directory, 161 HEC, 49
adres ILMI, 54
broadcast, 82, 92 klasy ruchu, 52
broadcastowym, 22 LAN, 45
fizyczny, 22 LAN Emulation, 55
IP, 78, 79 MPOA, 69
klasy, 80, 81 NNI, 49, 54
MAC, 22, 78, 79, 93 Protkół PNNI, 54
p˛etla, 82 PT, 49
rozgłoszeniowy, 22 PTSN, 45
adres IP PVC, 47
klasy, 81 Standard, 45
adresowanie SVS, 47
globalne, 42 UNI, 53
mulitcast, 42 VCC, 48
adresy VCI, 48, 49
MAC, 177 VCL, 48
PA, 123 VP, 48
PI, 123 VPI, 48, 49
algorytm szyfrujacy,
˛ 142 WAN, 45
architektura rozproszona, 160 ATM Forum, 46
ARP, 11, 77, 78 ATM LAN Emulation 2.0, 60
ARPA, 3 autonegocjacja, 24, 25
ARPANET, 3 autoryzacja, 132, 139
199
200 SKOROWIDZ
B struktura, 95
zapytania, 96
baza LDAP, 161
domyślna ścieżka, 82
BECN, 41
DSL, 38
bezpieczeństwo
DTE, 37, 41, 42
zasady dost˛epu, 172
dupleks, 19
bezpieczeństwo informatyczne, 170
BGP, 103
wyznaczanie trasy, 124 E
bit DE, 40
BOOTP, 79, 92 EIR, 40
brama, 12 enkapsulacja, 84, 85
bridge, 11 Ethernet, 5, 7, 17–34
broadcast, 22, 157 10 Base-2, 23
10 Base-5, 23
10 Base-T, 23
C
adresacja, 22
cenzurowanie treści, 169 format ramki, 21–22
CIDR, 81 Ethernet II, 21
CIR, 39–41, 118 IEEE 802.3, 21
CLLM, 41 external BGP, 123
CRC, 36
CSMA/CD, 18, 19
cut through, 27 F
cut-through switching, 37
fałszowanie adresu, 179
Fast Ethernet, 23
D 100 Base-FX, 24
100 Base-T4, 24
Day Time, 158
100 Base-TX, 23
DCE, 38, 41
FCS, 36
DCF77, 156
FDDI, 6
dekapsulacja, 85
FECN, 41
denial of service, 179
filtr pakietów, 180
DHCP, 77, 79, 92
firewall, 180
nagłówek, 92
firewall personalny, 184
diagnozowanie, 90
dialery, 167 FRAD, 37, 42
DLCI, 38, 42 fragmentacja, 84, 92, 99
DNS, 4, 77, 80, 82, 86, 94, 130, 148, 160, kontrola, 85
162 Frame Relay, 7, 35, 37, 178
domena, 130 FTP, 137, 138
hierarchia nazw, 94 active, 137
nagłówek, 96 passive, 137
rekord, 130 funkcja skrótu, 186
rekordy, 96
SKOROWIDZ 201
G IDS systemowy, 184

IEEE, 17, 21
gateway, 12
802.11, 177
GCC, 146
802.11a, 177
Gigabit Ethernet, 14, 24
802.11b, 177
1000 Base-LX, 24
802.11g, 177
1000 Base-SX, 24 802.1D, 30, 31
1000 Base-TX, 25 802.1p, 30
głos 802.1Q, 29, 176
kodowanie, 41 802.1w, 33
GPRS, 97 802.2, 22
GPS, 156 802.3, 21
grupowe 802.3ab, 25
połaczenia,
˛ 42 802.3ad, 33
802.3ae, 25
H 802.3ak, 25, 26
802.3an, 25, 26
hacker, 179 802.3i, 23
hasła 802.3u, 23
bezpieczne, 193 802.3z, 24
jednorazowe, 193 IETF, 17, 98, 128, 129
hasło, 193 IMAP, 131, 133, 134, 136
host, 101 identyfikator, 133
HTML, 147 internal BGP, 123
HTTP, 4, 147 Internet, 3, 4, 175
DELETE, 150 IP, 82
GET, 149 nagłówek, 82
HEAD, 149 opcje, 83
LINK, 150 przetwarzanie, 85
metadane, 152 IP over ATM, 72
połaczenia,
˛ 151 IPSec
POST, 149 Security Association, 191
PUT, 150 tryb tunelowy, 190, 191
sesja, 152 IPv4, 77, 80
UNLINK, 150 adresowanie, 80
hub, 177 IPv6, 97
nagłówek, 98
I nagłówki, 99
rozszerzenia, 99
ICMP, 90 IPX, 146
bł˛edy, 90 ITU-T, 146
nagłówek, 91
identyfikacja, 90, 132, 133
J
identyfikator, 138
IDS sieciowy, 183 jumbogram, 99
202 SKOROWIDZ
K mechanizm bezpieczeństwa, 160

medium transmisyjne, 13
Kabel koncentryczny, 176
kabel miedziany, 13
kanały cyfrowe, 178
kabel koncentryczny, 13, 17
kanały wirtualne, 146
skr˛etka komputerowa, 14, 18
kasowanie echa, 41
kabel światłowodowy, 14, 18
kategoria okablowania, 14 jednomodowy, 15
klaster, 174 wielomodowy, 15
klastry, 174 metryka OSPF, 118
klucz prywatny, 142 MIME, 128, 129, 147
klucz publiczny, 187 MKSVIR, 168
kodowanie model
BASE64, 134 internetowy, 13
kolizja, 5, 18, 19 ISO/OSI, 9–13, 20, 35, 189
komendy warstwa aplikacji, 9
ASCII, 132, 137 warstwa fizyczna, 9, 20
komórka ATM, 48 warstwa łacza,
˛ 9, 20
komunikacja warstwa prezentacji, 9
połaczeniowa,
˛ 35 warstwa sesji, 9
dwukierunkowa, 37 warstwa sieciowa, 9
koncentrator, 18, 26 warstwa transportowa, 9
konto, 192 LAN, 20–21
konwergencja, 4 LLC, 20
kopie zapasowe, 172 MAC, 20
PMD, 21
L PMI, 20
Mosaic, 4
LAN, 176, 178, 179, 181 mostek, 11
LDAP, 161, 196 MPOA, 70
CN, 162 MTA, 130
DN, 162 MTU, 98
linie telefoniczne, 178 MUA, 130
LMI, 42 multicast, 157
multipleksacja, 21
M
N
maska
naturalna, 82 nagłówki opcjonalne, 151
podsieci, 81 NAT, 181
MCSMUX, 146 NetBios, 146
md5, 174, 175 NFS, 138
MD5, 133 NIS, 138, 155, 159
mechanizm domena, 159
kontroli, 41 mapy, 159
zabezpieczajacy,
˛ 157 NIS+, 138, 160
SKOROWIDZ 203
NNTP, 147, 153, 154 potwierdzanie, 36, 88

NTP, 155, 156 półdupleks, 19
konfiguracja klienta, 157 preamuła, 21
Master Clock, 155 priorytety ruchu, 30
Stratum Three, 157 procedury awaryjne, 170, 172
Stratum Two, 157 programy antywirusowe, 168
Stratum Zero, 155 protokół
wybór serwera, 157 bezstanowy, 149
NVT, 140 routingu, 101
routowalny, 101
protokół bezpołaczeniowy,
˛ 85, 151
O
protokół BGP, 122
obwody Protokół OSPF, 116
logiczne, 38 protokół RIP, 104
wirtualne, 38, 42 proxy, 182
ochrona danych, 169 proxy serwer, 147
okno emisyjne, 41, 140 przeciażenia,
˛ 41
OpenLDAP, 161 przełacznik,
˛ 18, 27
opóźnienia, 152 przełaczniki,
˛ 177
OSPF, 180 przepełnienie bufora, 180
pakiety LSA, 117 przesyłanie
router ABR, 121 poczty, 129
router desygnowany, 117 pseudoterminal, 140
zapasowy router desygnowany, 117 PVC, 39, 42
P Q
pakiet, 9 QoS, 99
pakiety
fragmentacja, 41
R
PARC, 17
PAT, 181 RAID, 173, 174, 192
PKI, 196 RAID 0, 173, 175
pliki RAID 0+1, 173
transfer, 136 RAID 1, 173
poczta elektroniczna, 4, 127, 166, 169 RAID 5, 173
podpis cyfrowy, 194 ramka, 9
definicja, 194 RARP, 78, 92
podsłuch sieciowy, 141 RDP, 144, 146
POP3, 131–133, 136 repeater, 11, 18
port retransmisje, 89
numery, 86 RIP, 104
portal, 4 Poison Reverse, 111
porty rozczepiony horyzont, 110
przekierowywanie, 144 split horizon, 111, 112
204 SKOROWIDZ
sztuczna metryka, 112 LAN, 7

RIP 2, 180 MAN, 8
RIP wersja 2, 114 pakietowa, 35
RIPE, 81 rozległa, 8
rodzaje ataków sieciowych, 179 WAN, 8
router, 11, 101 sieć bezpieczna, 175
routery, 180 sieć wirtualna, 28
routing, 101 skanowanie sieci, 179
bezklasowy, 81 skr˛etka, 177
metryka trasy, 102 skr˛etka komputerowa, 14
protokoły dystans-wektor, 104 FTP, 14
protokoły dystans-wektor, 104 STP, 14
protokoły stanu łacza,
˛ 104, 116 UTP, 14
protokoły wewn˛etrzne, 103 skróty wiadomości, 143
protokoły zewn˛etrzne, 103 sliding window, 89
routing dynamiczny, 103 SMTP, 12, 127, 128
routing statyczny, 102 sniffer, 177, 183
routing źródłowy, 179 SNTP, 155
RPC, 86, 138 SONET, 50, 51
RSA, 190 SSH, 138, 141, 142, 144
RSVP, 41, 42 SSL, 186, 194
RTP, 42 cyfrowe certyfikaty, 187
RTSP, 148 standard ATM, 45
stopa bł˛edów, 36, 37, 39
store & forward, 27
S
store-and-forward, 37
SCP, 138 stos TCP/IP, 9
scrambling, 21 STP, 31
SDH, 6 SUID, 138
segment, 18 SunONE, 161
serwer proxy, 149, 151 SVC, 39, 42
serwerownia synchronizacja czasu, 155
klimatyzacja, 172 sytsemy IDS, 183
lokalizacja, 171 szyfr, 185
zabezpieczenia antywłamaniowe, 171 asymetryczny, 186
serwery cache, 152 symetryczny, 186
sesja szyfrowanie, 141
FTP, 137
HTTP, 152
T
TCP, 152
zamykanie, 152 T.120, 146
sieci bezprzewodowowe, 177 T.122, 146
sieci p2p, 166 T.125, 146
sieć, 7 T.128, 146
kampusowa, 8 tablica routingu, 102
SKOROWIDZ 205
TCP, 4, 9, 77, 87 UTM, 185

flagi, 88 UUCP, 154
nagłówek, 87
okno, 89
V
sesja, 88, 133, 134, 139
TCP/IP, 4 VLAN, 28, 176
Telefonia ATM VoIP, 30
ATM Trunking using AAL2, 75 VPN, 42, 188
CES, 74 IPSec, 190
DBCES, 75 IKE, 190
telnet, 9, 139–141, 144 klient, 189
opcje, 141 L2F, 190
terminal wirtualny, 140 L2TP, 189, 190
terminator, 18 PPTP, 189, 190
TFTP, 92, 137 serwer, 189
Token Bus, 5 tunelowanie, 189
Token Ring, 6
topologia sieci, 5, 17
W
gwiazda, 6, 18, 37
krata, 7, 37 warstwa
pierścień, 5 AAL, 51
szyna, 5, 17 ATM, 50
TOS, 99 warstwa fizyczna, 77
transakcja, 132 wirus makrowy, 166
transceiver, 17 wirusy komputerowe, 165
tripwire, 174 konie trojańskie, 167
trójnik, 17 robaki, 167
TTL, 83, 99 WWW, 4, 147
typy komórek ATM, 49 wzorzec czasu, 156
U X
UDP, 77, 85, 137 X.500, 162
nagłówek, 85 nazewnictwo, 162
UNI, 36, 49 XDR, 138
URI, 147, 148, 150
URN, 148
Y
urzadzenia
˛ ATM, 46
Usenet, 153 Yellow pages YP, 159
feed, 154
grupy news, 153
Z
regulamin, 155
usługi katalogowe, 161 zapytanie
usługi terminalowe, 127, 139, 144 RARP, 79
UTC, 155, 157 zarzadzanie
˛ sesja,˛ 151
206 SKOROWIDZ
zasady dost˛epu, 170

zasilanie, 170, 171

Pod Recznik

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pod Recznik

Uploaded by

Copyright:

Available Formats

Ośrodek Kształcenia na Odległość

Piotr Jankowski, Dominik Łoniewski,

Wydanie II, Warszawa 2007

Ośrodek Kształcenia na Odległość

Seria: Akademickie Podr˛eczniki Multimedialne

2 Rozwój standardu Ethernet 17

3 Sieci Frame Relay 35

5 Protokoły z rodziny TCP/IP 77

5.9. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6 Routing pakietów IP 101

7 Podstawowe usługi sieciowe 127

7.1.3. Protokół IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

8 Ochrona danych w sieci 165

8.7.3. SSL i potwierdzanie tożsamości klienta . . . . . . . . . . . . . . . . . . 194

Podr˛ecznik niniejszy jest wynikiem doświadczeń zespołu autorskiego w nauczaniu i przekazy-

W rozdziale przedstawiono zasadnicze poj˛ecia zwiazane˛ ze współczesnymi sieciami komputero-

1.1. Historia sieci komputerowych

1.2. Topologie sieciowe

Rysunek 1.1: Schemat sieci komputerowej zbudowanej w topologii szyny.

Rysunek 1.2: Schemat sieci komputerowej zbudowanej w topologii pierścienia.

Sieci pierścieniowe cechuja˛ si˛e zazwyczaj przewidywalnymi charakterystykami czasowymi

Rysunek 1.3: Schemat sieci komputerowej zbudowanej w topologii gwiazdy.

unieruchomienie jednego komputera. Zdecydowanie utrudnione jest też podsłuchiwanie transmi-

Rysunek 1.4: Schemat sieci komputerowej zbudowanej w topologii kraty.

1.3. Rodzaje sieci

Sieć LAN (Local Area Network) to sieć łacz˛ aca

metrów, do kilku kilometrów. Komputery, podłaczone

1.4. Model ISO/OSI

1.4.1. Transmisja danych

Rysunek 1.6: Transmisja danych przez poszczególne warstwy modelu ISO/OSI.

W przypadku rzeczywistej transmisji przesyłane dane sa˛ uzupełniane o nagłówki poszcze-

repeater jest urzadzeniem

bridge (mostek) jest urzadzeniem

router jest również urzadzeniem

Rysunek 1.7: Droga ramek w sieci, której poszczególne segmenty podłaczone

Rysunek 1.8: Droga pakietów w sieci, której poszczególne segmenty podłaczone

gateway (brama) jest urzadzeniem

1.4.3. Internetowy model sieciowy

Rysunek 1.9: Model internetowy i model ISO/OSI.

1.5. Media transmisyjne

1.5.1. Kable miedziane

warstwa˛ dielektryka. Zewn˛etrzny kabel ma zazwyczaj form˛e plecionki. Obecnie wykorzysty-

Rodzaj Liczba par Maks. cz˛est. Zastosowanie

Tabela 1.1: Kategorie okablowania komputerowego według specyfikacji EIA/TIA.

Obecnie instalowane okablowanie miedziane wykonywane jest zazwyczaj w kategorii 5e lub

1.5.2. Kable światłowodowe

[2] Praca zbiorowa. Vademecum teleinformatyka I. Sieci komputerowe, telekomunikacja, insta-

W rozdziale przedstawiono podstawowe poj˛ecia zwiazane

2.1. Podstawy standardu

2.1.1. Topologia sieci Ethernet

2.1.2. Transmisja danych

2.1.3. Model sieci LAN

LLC IEEE 802.2

MAC IEEE 802.5

2.1.4. Budowa ramki

eliminować długie, powtarzajace

DA SA typ dane FCS

IEEE 802.3 + IEEE 802.2

2.2. Ethernet w kolejnych wcieleniach

2.2.1. Ethernet 10 Mb/s

2.2.2. Fast Ethernet

Oznaczenie Medium transmisyjne Zasi˛eg

Tabela 2.1: Standardy sieci Ethernet.

W przypadku okablowania kategorii 3 (powszechnie wykorzystywanego w pierwszych sie-