TCP/IP. Szkoła programowania [PDF]

Zitiervorschau

W yszukaj inne elementy; Pliki lub foldery Komputery

Heather Osterloh

S z c z e g ó ło w e o m ó w ie n ie z a g a d n ie ń z w ią z a n y c h z d z ia ła n ie m sieci in te rn e to w e j A dresow anie i routing D> S terow anie transmisją

s Am s

PUBLISHING

[> P rotokoły internetowe

fa . ' M

Cidlion

w

i AUTORCE Heather O sterloh dogłębnie poznała branżę informatyczną, o czym świadczą po­ siadane przez nią certyfikaty: CCNA (Cisco Certified Network Associate), CCNP (Cisco Certified Network Professional), CCDA (Cisco Certified Design Associate), CCDP (Cisco Certified Design Professional), szkoleniowca Network Associate Sniffer, CNX (Certified Network eXpert) dla sieci Ethernet i TokenRing, CNI/ECNE firmy Novell, MCSE (Microsoft Certified Systems Engineer) i MCT (Microsoft Certified Trainer). Zdała też część pisemną egzaminu CCIE (Cisco Certified Internetworking Expert), w trakcie wydawania oryginału tej książki (2002 rok) czekając na praktyczny egzamin laboratoryjny. Po 15 latach prowadzenia szkoleń i konsultacji na całym świecie, Heather uzyskała znaczącą pozycję w branży sieciowej. Napisała książkę CCNA 2.0 Prep Kit 640-507 Routing and Switching oraz nagrała na zlecenie firm Microsoft, Cisco i Novell szereg popularnych, adresowanych do wiecznie zajętych profesjonalistów cykli progra­ mów wideo. W ciąż tworzy materiały pomagające nauczać pracy w sieciach kom­ puterowych. Heather prowadziła też wykłady na Uniwersytecie Kalifornijskim w Berkeley, pod­ czas konferencji użytkowników NetWare (NetUCon) w San Jose i na Uniwersytecie Portoryko, a przez trzy lata była prezesem IT Academy LLC. Mieszka w północnej Kalifornii z mężem Kirkiem oraz psami o imionach Kakao i Katon.

WSTĘP Franz Kafka kiedyś napisał: „Książka musi być siekierą dla zam arzniętego morza wewnątrz nas". Niniejsza książka pomaga przebić się przez lód, pozwalając Czytel­ nikowi zrozumieć świat TCPAP, będąc przy tym bardziej zrozumiała niż cytat z Kafki. Sprawa nie dotyczy przecież statków kosmicznych, tylko kilku routerów, klawiatur, komputerów i protokołów, powodujących że wszystko działa... albo i czasem nie działa. Informacje zawarte w książce powinny być wystarczające do zrozumienia tego co działa, a co nie, zdejm ując zasłonę tajem nicy z zagadnień pra­ cy sieciowej. Rozdziały książki zostały ułożone w przemyślany sposób: zaczynając od omówie­ nia podstaw modeli OSI i DoD, skupiając się przy tym na warstwach łącza danych i fizycznej. Następnie książka przechodzi do m odelu OSI i omawia znajdujące się w jego warstwach różne protokoły TCP/IP. Rezultatem przeczytania tej książki po­ winna być solidna i gruntowna znajom ość wszystkich najw ażniejszych protokołów obecnych w pakiecie TCPAP. Można też czytać ją na wyrywki, korzystając z odsyła­ czy do rozdziałów poświęconych danym protokołom lub koncepcjom . Książka stara się możliwie mocno angażować Czytelnika w działania. Często książki omawiają TCPAP w sposób teoretyczny lub tak, jakby w działaniu sieci nie uczest­ niczyli ludzie. Jak wiadomo, jest dokładnie na odwrót. To człowiek konfiguruje ro­ uter lub wysyła pocztę elektroniczną do współpracownika. W książce wykorzystano wielu zrzutów z ekranu komputera. Odwołania do nich w treści książki zostały oznaczone następująco: „zrzut ekranu z aplikacji Sniffer" lub „Sniffer NetWork Analyzer". Zrzut taki po prostu pokazuje ramki (ruch siecio­ wy) w sposób czytelny i zrozumiały dla Użytkownika. Aplikacja Sniffer jest, mó­ wiąc pokrótce, narzędziem do rozwiązywania problemów sieciowych, jedn ak w tej książce służy tylko do obserwacji działań zachodzących w sieci (czynności wyko­ nyw anych w niej przez protokoły). Zrzuty ekranowe aplikacji Sniffer często pokazują konkretną, wyróżnioną ramkę. Lista, zawarta poniżej zawartości ramld takiego zrzutu, wyszczególnia wówczas

TC P/IP. SZKOŁA PROGRAMOW ANIA

informacje zawarte w nagłówku. Można się z nich wyciągnąć wiele ciekawych in­ formacji - adresy IP, kody operacji, i stosowane protokoły. Dodatkowo zrzuty te często występują w parze z suchymi schematami nagłówków. Schem aty takie opi­ sują protokoły w sposób zdefiniowany przez dokum enty RFC (RFC, Request For Comments, ang. Wezwanie do komentarzy), natomiast zrzuty pokazują je bardziej reali­ stycznie. Pokazanie obydwu form powinno zapewnić bardziej praktyczne i szersze doświadczenie. W książce znajdują się też odwołania do dokumentów RFC wraz z ich numerami (np. RFC 1583). Są one na ogół suchymi faktograficznymi dokumentacjami i specy­ fikacjami protokołów TCP/IP. Zamiast po prostu powtarzać, co mówi dane RFC, po odwołaniu do niego jest ono opisywane w sposób bardziej interesujący i zrozu­ miały. Tym niemniej w Dodatku A znajduje się lista dokum entów RFC, uporząd­ kowana według rozdziałów tej książki. Dokum enty te są bezpłatnie dostępne w sieci WWW (szczegóły w książce).

SPIS TREŚCI O a u to rce ........................................................................................................................................................ 15 w stęp ...............................................................................................................................................................17 Rozdział 1. Om ówienie modeli i standardów branżow y ch .......................................................... 19 Omówienie modelu referencyjnego O S I ................................................................................ 19 Omówienie modelu Departamentu O b ro n y ........................................................................ 22 Zalety warstwowej konstrukcji O S I .........................................................................................22 Jasne sprecyzowanie funkcji warstw .............................................................................. 23 Dobrze określony schem at dla dostawców ................................................................... 23 M niejsza złożoność pracy w sieci ....................................................................................23 Popieranie s p e cja liz a cji........................................................................................................ 24 Opis ogólny warstw O S I ..............................................................................................................24 Warstwa a p lik a c ji................................................................................................................... 26 Warstwa p re z e n ta cji.............................................................................................................. 27 W arstwa s e s ji ........................................................................................................................... 27 Warstwa transportowa ......................................................................................................... 28 Warstwa sie c io w a ................................................................................................................... 29 Warstwa łącza danych ......................................................................................................... 30 Warstwa fizyczna ................................................................................................................... 31 Architektura i topologie łącza d a n y c h .....................................................................................31 Ethernet i IEEE 802.3 ............................................................................................................ 31 Powolny Ethernet ................................................................................................................... 38 Szybki Ethernet .......................................................................................................................39 Gigabitowy E th e rn e t.............................................................................................................. 40 Token-Ring i IEEE 802.5 ...........................................................................'.......................... 40 FDDI i ANSI X 3 T 9 .5 .............................................................................................................. 42 Technologie sieci rozległych (WAN) ........................................................................................43 Protokoły herm etyzacji W A N ............................................................................................ 46 Dokum enty R F C .............................................................................................................................47 Internet kontra in tra n e t................................................................................................................48 Grupy odpowiedzialne za technologię In tern etu ............................................................... 49 Pod su m ow an ie...............................................................................................................................49 Pytania sprawdzające ...................................................................................................................49

6

TCP/IP. SZKOŁA PROGRAMOW ANIA

Rozdział 2. Adresowanie I P .....................................................................................................................51 Istota konwersji dwójkowo-dziesiętnej ..................................................................................51 Adresowanie I P ...............................................................................................................................52 Klasy ad resó w .......................................................................................................................... 53 M aski sieci i p o d s ie c i............................................................................................................58 Podział na podsieci. P rzy k ład y ..........................................................................................61 Tłumaczenie adresów sieciowych (NAT) ...............................................................................73 Statyczne ...................................................................................................................................74 D y n a m iczn e..............................................................................................................................74 Podsumowanie ...............................................................................................................................75 Pytania sprawdzające ...................................................................................................................76 Rozdział 3. Protokoły internetow e i warstwa sieciowa ................................................................. 77 Protokół I P ........................................................................................................................................77 Nagłówek I P ..............................................................................................................................79 Protokół ICMP ................................................................................................................................90 Format nagłówków i komunikatów ICMP ........................................................................... 91 Kod komunikatów ICMP a ich ro d z a je ...........................................................................92 Sum a kontrolna ...................................................................................................................... 93 Typ komunikatu IC M P ................................................................................................................ 94 Ping: żądanie i odpowiedź echa — typy 8 i 0 ..............................................................94 Odbiorca nieosiągalny — typ 3 ........................................................................................ 96 Tłum ienie nadawcy — typ 4 ...........................................................................................100 Przekierowanie — typ 5 .................................................................................................... 100 Ogłaszanie i poszukiwanie routera — typy 9 i 10 ................................................... 101 Przekroczony czas — typ 11 ............................................................................................ 101 Problem z parametrami — typ 1 2 .................................................................................. 103 Żądanie i odpowiedź znacznika czasu — typy 13 i 14 ......................................... 103 Żądanie i odpowiedź inform acji — typy 15 i 16 .................................................. 103 Żądanie i odpowiedź maski adresu — typy 17 i 18 .............................................. 104 Podsumowanie .............................................................................................................................104 Pytania sprawdzające .................................................................................................................104 Rozdział 4. Zamiana a d re só w .............................................................................................................. 105 Protokół A R P ................................................................................................................................. 107 Działanie protokołu ARP .................................................................................................. 107 M echanizm y bufora ARP .................................................................................................. 110 Proxy A R P .......................................................................................................................................111 Działanie proxy A R P .......................................................................................................... 111 Nagłówek A R P .............................................................................................................................. 113 Typ sprzętu (Hardware T y p e ) ......................................................................................... 114 Typ protokołu (Protocol Type) ....................................................................................... 114 Długość adresu sprzętowego (Hardware address Length. HLen) ....................... 115 Długość adresu protokolarnego (Protocol address Length. P L e n )......................115 Kod operacji (Operation code. Opcode) ...................................................................... 115 HA nadawcy (Sender’s HA) ............................................................................................. 115

SPIS TREŚCI

7

PA nadawcy (Sender’s PA) ...............................................................................................115 HA odbiorcy (Target HA) .................................................................................................. 115 PA odbiorcy (Target PA) ................................................................................................... 116 Protokół RARP .............................................................................................................................. 116 Działanie protokołu R A R P ........................................................................................................ 116 Działanie ARP a działanie R A R P ....................................................................................117 Wady protokołu RARP ....................................................................................................... 119 Nagłówek R A R P ...........................................................................................................................119 Typ sp rz ę tu .............................................................................................................................119 Typ p ro to k o łu ........................................................................................................................ 119 Długość adresu sprzętowego (HLen) .............................................................................120 Długość adresu protokolarnego (PLen) ........................................................................120 Kod operacji (Opcode) ....................................................................................................... 120 HA nadawcy .......................................................................................................................... 120 PA n a d a w cy ............................................................................................................................120 HA odbiorcy .......................................................................................................................... 121 PA odbiorcy ........................................................................................................................... 121 Protokół B O O T P ...........................................................................................................................121 Nagłówek BOOTP ................................................................................................................122 Żądanie i odpowiedź BOOTP ..........................................................................................126 Protokół D H C P .............................................................................................................................127 Przydzielanie inform acji konfiguracyjnych ............................................................... 128 Komunikaty D H C P .............................................................................................................. 128 Wymiany komunikatów DHCP ...................................................................................... 129 Nagłówek DHCP ................................................................................................................... 136 Podsumowanie .............................................................................................................................139 Pytania sprawdzające ................................................................................................................. 140 Rozdział 5. Routing I P .............................................................................................................................141 Podstawy routingu I P .................................................................................................................141 Interfejs podłączony b ezp ośred n io................................................................................ 142 Routing sta ty cz n y .................................................................................................................142 Routing domyślny ............................................................................................................... 143 Routing d y n a m iczn y ...........................................................................................................144 Protokoły routingu i najlepsza ścieżka ................................................................................. 145 Protokoły wektora o d leg ło ści........................................................................................... 145 Protokoły stanu łącza ......................................................................................................... 148 Protokoły hybrydowe ......................................................................................................... 149 P od su m ow an ie.............................................................................................................................151 Pytania sprawdzające ................................................................................................................. 151 Rozdział 6. Protokoły ro u tin g u .............................................................................................................153 W prow adzenie.............................................................................................................................. 153 Protokół RIP .................................................................................................................................. 154 RIP w .l ..................................................................................................................................... 155 Nagłówek RIP w .l ............................................................................................................... 158

8

TCP/IP. SZKOLĄ PROGRAM OW ANIA

Wady protokołu RIP w. 1 ................................................................................................... 160 Czasomierze RIP ...................................................................................................................163 Protokół RIP a obwody tworzone na żądanie .......................................................... 164 RIP w .2 ..................................................................................................................................... 167 Protokół O S P F ...............................................................................................................................169 Charakterystyka OSPF .......................................................................................................170 Bazy danych OSPF ..............................................................................................................171 Działanie O S P F ..................................................................................................................... 172 Nagłówek LSA ...................................................................................................................... 176 Stany routera O S P F ............................................................................................................. 178 Typy routerów O S P F ...........................................................................................................183 Działanie O SPF w różnych architekturach łącza danych .....................................184 Typy obszarów ..................................................................................................................... 187 Standardowe pola pakietu O S P F ................................................................................... 190 Nagłówki d odatkow e...........................................................................................................192 Protokół IGRP ...............................................................................................................................199 Sieci IGRP ...............................................................................................................................200 Protokół E IG R P .............................................................................................................................202 Działanie EIGRP ...................................................................................................................202 Typy pakietów EIGRP ........................................................................................................ 205 Protokół B G P ................................................................................................................................. 205 Protokoły IGP versus protokoły EGP ............................................................................ 206 Routery BGP .......................................................................................................................... 207 Działanie B G P ........................................................................................................................209 Nagłówek BGP ...................................................................................................................... 209 Atrybuty ścieżki ...................................................................................................................214 BGP w.3 a BGP w.4 .............................................................................................................217 Podsumowanie ............................................................................................................................ 217 Pytania sprawdzające .................................................................................................................218 Rozdział 7. Warstwa transportowa .................................................................................................... 221 Protokoły warstwy transportowej ..........................................................................................221 Protokoły p o łącze n io w e.................................................................................................... 223 Protokoły bezpołączeniowe ............................................................................................. 225 Protokoły bezpołączeniowe a protokoły p o łączen io w e......................................... 225 Porty i g n ia z d a ...................................................................................................................... 226 Podsumowanie .............................................................................................................................228 Pytania sprawdzające .................................................................................................................229 Rozdział 8. Protokół sterowania transmisją (TCP) ........................................................................ 231 W prow adzenie..............................................................................................................................231 Nagłówek T C P ..............................................................................................................................232 Port źródłowy (Source Port) ............................................................................................ 233 Port docelowy (Destination P o rt)....................................................................................233 Numer kolejny (Sequence Number) ............................................................................. 234

SPIS TREŚCI

9

Numer potwierdzenia (Acknowledgement Number) ............................................. 234 Przesunięcie danych (Data Offset) ................................................................................ 236 Zarezerwowane (Reserved) ...............................................................................................236 Flagi (Flags) ............................................................................................................................236 Okno (Window) .................................................................................................................... 237 Sum a kontrolna (Checksum) ........................................................................................... 237 W skaźnik pilności (Urgent Pointer) ..............................................................................237 O pcje (Options) .................................................................................................................... 238 Podstawowe zasady działania T C P ........................................................................................238 U stanaw ianie i zrywanie p o łą cz e n ia .............................................................................239 Zw ielokrotnianie .................................................................................................................. 240 Przesył danych ..................................................................................................................... 241 Sterow anie przepływem ................................................................................................... 241 Niezawodność .......................................................................................................................242 Priorytety i z ab ezp ieczen ia...............................................................................................242 Cechy charakterystyczne p o łączeniow ośd ......................................................................... 244 Ustanawianie s e s ji ............................................................................................................... 244 Zrywanie sesji .......................................................................................................................249 Sekw encjonow anie i p otw ierd zenia.............................................................................. 250 Komunikaty utrzymywania przy ż y c iu ........................................................................255 Sterow anie przepływem ................................................................................................... 255 Porty T C P ........................................................................................................................................258 Podsumowanie .............................................................................................................................259 Pytania sprawdzające .................................................................................................................259 Rozdział 9. Protokół datagramów użytkownika (U D P )...............................................................261 Działanie U D P ............................................................................................................................... 262 A plikacje UDP .......................................................................................................................263 Porty U D P .......................................................................................................................................263 Nagłówek U D P .............................................................................................................................264 Port źródłowy (Source Port) ............................................................................................ 265 Port docelowy (Destination P o rt)....................................................................................265 Długość (Length) ..................................................................................................................265 Sum a kontrolna (Checksum) ........................................................................................... 266 Pod su m ow an ie.............................................................................................................................267 Pytania sprawdzające .................................................................................................................267 Rozdział 10. Protokoły górnej w arstw y ............................................................................................. 269 W prowadzenie do protokołów górnej w arstw y ................................................................269 Warstwa aplikacji ........................................................................................................................ 270 World Wide Web (sieć WWW) i HTTP (protokół przesyłania h ip ertek stu ) 271 Poczta elektroniczna oraz SMTP (prosty protokół przesyłania poczty elek tron iczn ej).....................................................272 Telnet (sieć telekom unikacyjna).............................................................................................. 272 Przesyłanie p lik ó w ...................................................................................................................... 273

10

TCP/IP. SZKOŁA PROGRAM OW ANIA

Warstwa p rezentacji.................................................................................................................... 273 Warstwa s e s ji................................................................................................................................. 274 NetBIOS (NetWork Basic Input Output System) — interfejs programowy aplikacji ...................................................................................... 275 Sieciowy system plików NFS (Network File System) oraz protokoły O N C 275 Podsumowanie ............................................................................................................................ 275 Pytania sprawdzające .................................................................................................................276 Rozdział 11. T e ln e t................................................................................................................................... 277 Komunikacja zewnętrzna .........................................................................................................277 Usługi podstawowe ....................................................................................................................279 W irtualny terminal sieciow y ...........................................................................................280 NVT ASCII (American Standard Code for Inform ation Interchange — standardowy amerykański kod wymiany in fo rm a cji)................................... 280 Polecenia protokołu T e ln e t .............................................................................................. 281 Negocjacja o p c ji.................................................................................................................... 283 O pcje protokołu Telnet ......................................................................................................284 N egocjacje s u b o p c ji.............................................................................................................287 Podsumowanie ............................................................................................................................ 288 Pytania sprawdzające .................................................................................................................288 Rozdział 12. Protokół przesyłu plików (FTP) ..................................................................................289 W prowadzenie do przesyłania p lik ó w .................................................................................289 Sesja FTP .........................................................................................................................................291 Reprezentacja d a n y ch ................................................................................................................ 294 Typy danych FTP ................................................................................................................ 295 Kontrola formatu ..................................................................................................................296 Struktury danych FTP ................................................................................................................297 Tryby transm isji FTP ......................................................................................................... 298 Polecenia F T P ................................................................................................................................298 Odpowiedzi F T P .......................................................................................................................... 301 Działanie FTP oraz p rzy k ład y ................................................................................................. 302 Anonimowy F T P .......................................................................................................................... 303 Podsumowanie ............................................................................................................................ 304 Pytania sprawdzające .................................................................................................................305 Rozdział 13. Prosty Protokół Przesyłania Poczty Elektronicznej (SM T P ).............................. 307 Model nazewniczy X .4 0 0 ........................................................................................................... 310 Agenci Transferu Wiadomości (M TA )................................................................................... 311 Format SMTP ................................................................................................................................311 Polecenia SMTP ........................................................................................................................... 313 Odpowiedzi S M T P ......................................................................................................................314 M IM E ............................................................................................................................................... 316 Podsumowanie ............................................................................................................................ 317 Pytania sprawdzające .................................................................................................................317

SPIS TREŚCI

11

Rozdział 14. Przekształcanie n a z w ......................................................................................................319 Dlaczego potrzebujem y przekształcenia nazw? ................................................................319 Przestrzeń nazw ...........................................................................................................................320 Delegacja zarządu domenami DNS .......................................................................................322 Nazwy domen in tern eto w y ch ..........................................................................................325 Zapytania i m ap ow anie..............................................................................................................326 Buforowanie (cachin g)................................................................................................................326 Format wiadomości serwera d o m e n ..................................................................................... 327 Identyfikator (ID) ..................................................................................................................327 QR ............................................................................................................................................. 327 Opcode ..................................................................................................................................... 328 Flagi ..........................................................................................................................................328 Rcode ....................................................................................................................................... 329 Nagłówki pytań i od p ow ied zi..........................................................................................330 Typy nazw d o m e n ............................................................................................................... 330 Przykłady DNS .............................................................................................................................331 N etBIOS ..........................................................................................................................................334 N etBIOS a TCP/IP........................................................................................................................ 335 Typy węzłów (node types) ....................................................................................................... 337 B -n o d e ...................................................................................................................................... 337 P-node ...................................................................................................................................... 337 M -n o d e ..................................................................................................................................... 338 H-node ..................................................................................................................................... 338 WINS (Windows Internet Naming Server — internetow y serwer nazewniczy Windows) .............................................................. 338 Agent proxy WINS .............................................................................................................. 339 Przykłady działania N etB IO S .................................................................................................. 339 P od su m ow an ie.............................................................................................................................340 Pytania sprawdzające .................................................................................................................341 Rozdział 15. Protokół przesyłania hipertekstu (HTTP) ............................................................... 343 HTTP oraz World Wide W e b ................................................................................................... 343 Cechy HTTP .................................................................................................................................. 344 Kom ponenty H T T P ..................................................................................................................... 345 W idoczni i niew idoczni agenci p ro x y .......................................................................... 345 Sesje H T T P ..................................................................................................................................... 346 Format wiadomości H T T P ........................................................................ 348 Wiersz sta rto w y ............................................................................................................................348 Nagłówek ogólny ........................................................................................................................ 349 Kontrola bufora .................................................................................................................... 349 P o łą cz e n ie ............................................................................................................................... 349 Data ........................................................................................................................................... 349 Pragma ..................................................................................................................................... 350 Stopka (tra ile r).......................................................................................................................350

12

TCP/IP. SZKOŁA PROGRAM OW ANIA

Kodowanie tra n s fe ru .......................................................................................................... 350 Aktualizacja ........................................................................................................................... 350 Via ............................................................................................................................................. 350 Ostrzeżenie ............................................................................................................................ 351 Nagłówki wiadomości (zapytania, odpowiedzi lub obiektu) ....................................... 351 Nagłówek zapytania ............................................................................................................351 Nagłówek od p ow ied zi........................................................................................................352 Obiekt ...................................................................................................................................... 352 Pusty wiersz (CRLF) ............................................................................................................352 T reść w iad om ości................................................................................................................ 352 Wiadomości odpowiedzi, stan i kody błędów H T T P .......................................................353 Wiadomości o błędzie HTTP ................................................................................................... 355 Podsumowanie ............................................................................................................................ 355 Pytania sprawdzające .................................................................................................................356 Rozdział 16. Trywialny protokół przesyłania plików (TFTP) .................................................... 357 W prowadzenie do protokołów przesyłania p lik ó w .........................................................357 Typy pakietów T F T P ...................................................................................................................358 Pakiety RRQ i W R Q ....................................................................................................................360 Pakiety danych ..................................................................................................................... 360 Pakiet A C K ..............................................................................................................................360 Pakiety błędu .........................................................................................................................361 Działanie T F T P ..............................................................................................................................362 Rozszerzenia T F T P ......................................................................................................................364 Pakiet O A C K .................................................................................................................................365 Podsumowanie ............................................................................................................................ 365 Pytania sprawdzające .................................................................................................................366 Rozdział 17. Prosty protokół zarządzania siecią (S N M P )............................................................ 367 W prowadzenie do zarządzania s ie cią ................................................................................... 367 SN M P ............................................................................................................................................... 369 M enadżer SNMP ......................................................................................................................... 369 Agenci SNMP ........................................................................................................................370 Widoki MIB ........................................................................................................................... 370 Proxy ........................................................................................................................................ 370 Format wiadomości S N M P .......................................................................................................371 W ersja ...................................................................................................................................... 371 Nazwa społeczności ........................................................................................................... 372 Jednostki danych protokołu (P D U )................................................................................373 Pułapka PDU .........................................................................................................................373 Podsumowanie ............................................................................................................................ 374 Pytania sprawdzające .................................................................................................................375

SPIS TREŚCI

13

Rozdział 18. Protokoły otwartego przetwarzania sieciowego (ONCP) ..................................377 W prowadzenie do protokołów otwartego przetwarzania sieciowego ......................377 Cechy N F S ......................................................................................................................................378 Działanie N F S ................................................................................................................................ 380 Klient N F S .......................................................................................................................................381 Serwer N F S .................................................................................................................................... 383 Składniki i działanie automountera ..............................................................................383 Auto-polecenie ..................................................................................................................... 384 X D R ...................................................................................................................................................384 RPC ...................................................................................................................................................385 W iadomość w yw ołująca.............................................................................................................386 ID tra n sa k cji........................................................................................................................... 387 Typ ............................................................................................................................................ 387 W ersja ...................................................................................................................................... 387 P rog ram ....................................................................................................................................387 P roced u ra................................................................................................................................ 389 Rodzaj uwierzytelniania ................................................................................................... 390 Rozmiar uwierzytelniania w b a jta c h .............................................................................390 Dane uw ierzytelniania ....................................................................................................... 390 W eryfikacja u w ierzy teln ian ia..........................................................................................390 O d p ow ied ź.................................................................................................................................... 391 Stan ........................................................................................................................................... 391 Stan akceptacji ..................................................................................................................... 391 Przykłady działania N F S ........................................................................................................... 391 Podsumowanie .............................................................................................................................393 Pytania sprawdzające .................................................................................................................393 Dodatek A Dokum enty RFC wg rozdziałów .................................................................................. 395 Dodatek B Skróty i ak ro nim y ................................................................................................................467 D odatek C Numery portów TCP/UDP.............................................................................................. 477 Dodatek D Sło w n iczek ............................................................................................................................479 D odatek E Odpowiedzi do pytań spraw dzających....................................................................... 521 Skorowidz ...................................................................................................................................................539

Podziękowania Przedsięwzięcie takiej skali wymaga licznych podziękowań: Po pierwsze, wydawnictwu Sams Publishing za możliwość napisania tej książki, a także wszystkim jego pracownikom, którzy przyczynili się do jej powstania, zwłaszcza Williamowi Brownowi, Markowi Renfrow, Christinie Smith, Racheli Bell, Kitty Jarrett i Michelle Truman oraz wszystkim tym, którzy pomagali mi bardziej niż wyni­ kało to z ich obowiązków. Mojemu niezwykłemu zespołowi — Jasonowi Buricie i Christinie Sepiol — którzy pomagali mi się skupić i wygładzali pisane przeze mnie jak kura pazurem bazgroly tak, aby zrobić z nich porządny tekst. Zespołowi IT Academy — Heidi, Beverly i Bryce ■ — bez których dodatkowego wsparcia i poświęcenia to przedsięwzięcie nie byłoby możliwe. Laurze Chappell, która wciągając mnie w świat certyfikatów sieciowych stała się moim pierwszym źródłem inspiracji. W szystkim moim studentom, którzy byli wobec mnie wymagający podczas zajęć i pobudzali do napisania możliwie najlepszej książki. Moim rodzicom — Ricie i Karłowi — którzy zawsze byli pomocni i popierali mnie w stu procentach. Moim psom — Kakao i Katonowi — które podczas pisania książki wskakiwały na mój laptop, zm uszając mnie do robienia jakże potrzebnych przerw i wprowadzając trochę zabawnego urozmaicenia. Przede wszystkim zaś mojemu mężowi Kirkowi za cierpliwość podczas napadów paniki, stresujących terminów końcowych i bezsenności, m ających miejsce w trak­ cie powstawania tej książki. Swoim ciągłym wsparciem mąż zdobywa m oje serce i pozwala mi uzmysłowić sobie, że mogę osiągnąć co tylko zechcę. Dzięki, kochanie.

m

OMÓWIENIE MODELI I STANDARDÓW BRANŻOWYCH Przegląd treści rozdziału: •

M odel OSI

•

A rchitektura i topologie sieci

•

Model DoD

•

Technologie sieci rozległych (W AN )

•

A rchitektura siedm iow arstw ow a

o D okum enty RFC

Omówienie modelu referencyjnego OSI Na początku powstawania sied istniały tylko systemy i protokoły wewnątrzfirmowe. Systemy operacyjne projektowane przez duże firmy, np. SNA firmy IBM (In­ ternational Business Machines) czy DECNet firmy DEC (Digital Equipm ent Corpo­ ration), zawierały własne pakiety protokołów. Systemy te i odpowiadające im protokoły przede wszystkim umożliwiały kom unikację siedow ą pomiędzy kom­ puterami klas mini- i mainframe. Firmy nie zapewniały jedn ak obsługi w zajemnych połączeń ani nie umożliwiały komunikacji z systemami zewnętrznymi. Kiedy IBM projektował SNA, a DEC — DECNet, nikt nie przewidywał obecnego rozpo­ wszechnienia się mieszanych środowisk komputerowych. Komunikować się ze so­ bą i wymieniać dane mogły więc tylko kom putery korzystające z kompatybilnych protokołów i systemów operacyjnych.

20

TCP/IP. SZKOŁA PROGRAMOW ANIA

Jak nietrudno sobie wyobrazić, systemom różnych firm ciężko było komunikować się ze sobą, o ile w ogóle było to możliwe. Wkrótce okazało się konieczne stworzenie jakiegoś mechanizmu translacji protokołów, umożliwiającego firmom komunikację i współdzielenie informacji. We wczesnych latach 1970-tych amerykański Departament Obrony (DoD, Department o f Defense) zaprojektował model komunikacji międzykom puterowej, który stał się modelem źródłowym dla pakietu protokołów TCP/IP. Model ten został jednak w znacznym stopniu zastąpiony modelem referencyjnym OSI (OSI Reference Model), powstałym we wczesnych latach 80-tych . Model referen­ cyjny OSI ma budowę (architekturę) siedmiowarstwową, określającą poszczególne funkcje sieciowe występujące w każdej z warstw (por. rysunek 1.1). W dalszym dągu rozdziału znajduje się szersze omówienie modelu DoD wraz z jego odwzoro­ waniem w modelu OSI. W ystępujące w całej książce opisy przeznaczenia i funkcji protokołów, obecnych w pakiecie TCP/IP, zawierają odwołania do obu tych modeli. R y s u n e k 1 .1 .

W a rstw y i fu n k c je M o de lu O SI

Model referencyjny OSI definiuje siedem warstw i ich funkcje

O fe ro w a n ie u s łu g a p lik a c jo m u ż y tk o w n ik a

T łu m a c z e n ie , k o n w e rs ja , s z y fro w a n ie , o d s z y fro w y w a n ie , k o m p re s ja d a n y c h Z a rz ą d z a n ie s e s ja m i i s te ro w a n ie d ia lo g a m i

transportow a

K o m u n ik a c ja n a c a łe j d ro d z e tra n s m is y jn e j p o m ię d z y p ro g ra m a m i łu b p ro c e s a m i

sieciow a

A d re s o w a n ie lo g ic z n e i tra s o w a n ie (ro u tin g )

tacza danych

W y s y ła n ie i o d b ió r ra m e k

fizyczna

K o d o w a n ie syg n a łó w , o b s łu g a n o ś n ik a i z łą c z y

Model referencyjny OSI umożliwia bezkonfliktową kom unikaqę dowolnych systemów, oferując producentom i dostawcom schemat architektoniczny służący do projektowania sprzętu, protokołów i środowisk operacyjnych. Dzięki niemu inży­ nierowie i projektanci mogą korzystać ze standardowych specyfikacji komunikacji m iędzysystemowej. Pozwala on także na korzystanie z różnych protokołów w róż­ nych architekturach sieciowych i odnoszących się do niższych warstw typach no­ śników. Choć nie zawsze da się osiągnąć bezkonfliktową kom unikację, jest ona podstawowym celem modelu referencyjnego OSI. Zanim powstał model OSI, istniejące protokoły nie ułatwiały wzajemnych połączeń. W większości przypadków próba zapewnienia wstecznej kompatybilności z tymi protokołami byłaby niewykonalna. Stąd większość protokołów i sprzętu, obecnie wdra­ żanych przez producentów i dostawców, spełnia wytyczne modelu OSI. Sprawna i szybka wymiana danych oraz bezkonfliktowa łączność wzajemna, wymagana w dzi-

R ozdział 1. • OM Ó W IEN IE MODELI I STAN D ARD Ó W BRANŻOW YCH

21

siejszych mieszanych środowiskach komputerowych, zależy od zastosowania się przez producentów i dostawców do znormalizowanego modelu referencyjnego. Model OSI jest schematem koncepcyjnym. Składa się na niego szereg standardów, definiujących co powinno się zdarzyć i jak należy zapakować dane, aby po okablo­ waniu dostały się do zdalnego hosta. W arstwy logiczne tego modelu nie definiują dokładnie czynności wykonywanych w każdej warstwie, a jedynie opisują funkcje dostępne w każdej z nich. Sposób zapewnienia zestawu funkcji określonych w po­ szczególnych warstwach zależy od dostawcy lub producenta, tworzącego lub w drażającego sprzęt lub protokoły. Konkretni producenci mogą swobodnie inter­ pretować i wybierać stopień wierności wobec specyfikacji danej warstwy. W rezulta­ cie nie zawsze uzyskuje się całkowitą zgodność komunikacji m iędzy niepodobnymi urządzeniami, ale omawiany schemat dostarcza najlepszych m ożliwych wzorców do je j osiągnięcia. Model OSI składa się z następujących siedmiu warstw (od góry do dołu): ► aplikacji, prezentacji, ► sesji, ► transportowej, ► sieciowej, ► łącza danych, ► fizycznej. Mówiąc ogólnie, każda warstwa dostarcza odrębnych funkcji, które muszą zostać użyte wewnątrz niej, aby przygotować dane do wysłania przez okablowanie do zdalnej staq'i. Dostawca może określać szczegóły wewnętrzne tych funkq'i ogólnych. Innymi słowy, producenci lub projektanci definiują działanie szczegółów, tak, że dostawcy muszą troszczyć się tylko o swoją część układanki. Dopóki organizacja lub dostawca przestrzega zasad, ustalonych przez ISO (International Standards Organization) dla konkretnej warstwy, produkt końcowy łatwo integruje się z innymi produktami zgodnymi z zasadami tego modelu. Warto pamiętać, że m odel O SI jest stosowany tylko podczas przygotowywania da­ nych wysyłanych do zdalnego hosta, podobnego lub niepodobnego (tzn. korzysta­ jącego z tych samych protokołów i systemu operacyjnego lub nie). Modelu referen­ cyjnego O SI nie stosuje się podczas lokalnego dostępu do danych systemu. Na przykład dostęp do usług plików i wydruku wymaga jedynie dostępu do twardego dysku komputera lokalnego i otwarcia lokalnej aplikacji. W takiej sytuacji dostęp do danych nie wymaga żadnej interw encji użytkownika. Jeśli jednak to samo działanie ma zostać wykonane na zdalnym hośde, trzeba jakoś wysiać do innego urządzenia komunikat o potrzebie dostępu do plików lub drukarki, zmuszający je do odpowiedzi - przesiania danych.

22

TCP/IP. SZKOŁA PROGRAM OW ANIA

Aby przekierować żądanie dostępu do usiug plików i wydruku, potrzebny jest readresator (redirector). Przekierowuje on żądanie do zdalnego hosta, celem jego przetworzenia. Zdalny host przygotowuje żądanie do transmisji przez sieć, dodając informaq'e nagłówkowe (header) i kontrolne, pozwalające stacji docelowej zrozu­ mieć, co powinna zrobić z danymi i jak zareagować.

Omówienie modelu Departamentu Obrony Historia modelu DoD zaczęła się na długo przed modelem OSI, który wkrótce go zastąpił. Już w 1973 roku Agencja Zaawansowanych Projektów Badawczych Departamen­ tu Obrony (DARPA, DoD Advanced Research Projects Agency) rozpoczęta program mający na celu stworzenie technologii, które mogłyby łączyć m iędzy sobą różne ro­ dzaje pakietów sieciowych. Nadano m u nazwę „Internetting Project", a jego wyni­ kiem — czego można domyślać się na podstawie nazwy — jest dzisiejszy Internet. Model zaprojektowany przez agencję DARPA, będący wyjściowym standardem któremu podporządkowane są podstawowe protokoły internetow e, jest właśnie znany jako m odel DoD. Składa się on z następujących czterech warstw (od góry do dołu): ► aplikacji ► transportowej ► sieciowej ► dostępu do sieci Jak widać na rysunku 1.2, model DoD z grubsza odpowiada modelowi OSI. Rys u n e k 1 .2 .

Model DoD sktada się z czterech odrębnych warstw

W a rstw y m o de lu D oD a p lik a c ji

tra n s p o rto w a

d o s tę p u d o s ie c i

Zalety warstwowej konstrukcji OSI Warstwowa konstrukcja m odelu referencyjnego OSI jest korzystna dla producen­ tów sprzętu i projektantów oprogramowania oraz osób zawodowo oferujących pomoc techniczną i rozwiązywanie problemów (np. inżynierów sieciowych). Zalety tego modelu można podzielić następująco:

Rozdział 1. • OM Ó W IEN IE MODELI I STANDARDÓW BRANŻOW YCH

23

► Jasne sprecyzowanie ogólnych funkcji każdej warstwy. ► Zapewnienie dostawcom dobrze określonego schematu dla potrzeb pisania aplikacji i projektowania sprzętu. ► Zm niejszenie złożoności pracy w sied dzięki skategoryzowaniu funkcji modelu. ► Zwiększenie współdziałania niepodobnych sied i protokołów. ► Uproszczenie rozwiązywania problemów dzięki łatwiejszemu umiejscawianiu źródła problemów siedowych. ► Przyspieszanie rozwoju branży przez ułatwienie specjalizacji.

Jasne sprecyzowanie funkcji warstw Dzięki zawężeniu zakresu odpow iedzialnośa poszczególnych warstw, m odel OSI zmniejsza problemy na jakie napotykają producend i inżynierowie sietiowi. Poza tym nie trzeba ponownie wymyślać wytycznych produktu lub protokołu dla kon­ kretnych zastosowań. Dzięki jasnem u określeniu funkcji każdej z warstw dostawcy mogą projektować produkty przeznaczone dla jednej konkretnej warstwy, a nie dla wszystkich siedmiu. Pozwala im to na specjalizację w wybranych dziedzinach i zmniejsza złożoność sied.

Dobrze określony schemat dla dostawców Dostawcy mogą tworzyć specyfikacje przeznaczone dla jednej lub kilku warstw. Podejśde warstwowe upraszcza takie tworzenie, pozwalając dostawcom koncentro­ wać się i specjalizować we własnej, konkretnej warstwie m odelu OSI. Dodatkowo zwiększa współdziałanie między systemami, tworząc otwarte środowisko umożliwiają­ ce współistnienie wielu protokołów. Na przykład dostawca tworzący kartę sieciową (NIC, Network Interface Card) może zajmować się tylko warstwą łącza danych modelu OSI. Modułowa konstrukcja OSI umożliwia dostawcom tworzenie wyspecjalizowanych produktów. Ponieważ nie muszą zajmować się wszystkimi funkcjami od góry do dołu m odelu, mogą skupić się na konkretnej warstwie i funkcji. Dzięki temu tworzenie sprzętu i oprogramowania oraz wprowadzanie go na rynek jest prostsze. Poza tym, bez względu na różne dostosowywanie się przez dostawców do zasad koncepcyj­ nych każdej warstwy, samo istnienie znormalizowanego modelu zwiększa zarówno bieżący poziom współdziałania m iędzy systemami, jak i prawdopodobieństwo harmonijnego współistnienia przyszłych protokołów i produktów w tej samej sied.

Mniejsza złożoność pracy w sieci Podejśae warstwowe pozwala inżynierom sieaowym rozwiązywać problemy zgodnie z zasadą „dziel i rządź". Kiedy wiadomo, jakie procesy powinny zachodzić w każ­ dej warstwie, wówczas źle działającą funkcję m ożna zidentyfikować wiedząc, która

24

TCP/IP. SZKOŁA PROGRAMOW ANIA

warstwa nie spełnia swych funkcji. Protokół lub część sprzętu powinny działać zgod­ nie ze specyfikacjami zdefiniowanymi dla danej warstwy. Co chyba ważniejsze, dzięki temu modelowi umiejscawianie problemów nie wy­ maga zajmowania się całą strukturą, a tylko siedmioma m niejszymi jej fragmenta­ mi. Gdy konkretna warstwa nie działa poprawnie, w oparciu o model można wy­ dzielić i zaszufladkować problem, a dzięki temu dużo łatwiej go rozwiązać. Mówiąc ogólnie, operacje sieciowe funkcjonują jako prostsze fragmenty, a nie jedna, bar­ dziej skomplikowana całość.

Popieranie specjalizacji Stosowanie powszechnie przyjętego, „ogólnobranżowego" zestawu zasad obsługi sied jest inspiracją dla powstawania jeszcze szybszych i bardziej niezawodnych progra­ mów i protokołów. Dostawcy wiedząc, że mogą współzawodniczyć w ulepszaniu specyfikacji i skutecznośd w dowolnej warstwie modelu referencyjnego OSI, w dąż przesuwają granice w ydajnośd. Ponieważ wystarczy spełnianie specyficznych standardów tylko jednej warstwy, mogą specjalizować się w wytwarzaniu produk­ tów spełniających specyficzne potrzeby klientów. Przykładem może być router działający na warstwie trzedej, przeznaczony dla małego biura lub domu.

Opis ogólny warstw OSI Kiedy trzeba wysiać dane (np. wiadomość poczty elektronicznej lub żądanie od­ czytu pliku ze zdalnego hosta), żądanie to musi zostać przekształcone w pakiet da­ nych i przekierowane. System wysyłający musi wykonać następujące działania, oparte na poszczególnych funkcjach modelu referencyjnego OSI: 1. Zaadresować żądania. 2. Skojarzyć z nim protokoły. 3. Zmodulować go. 4. Wysiać go poprzez okablowanie. Gdy system przygotowuje dane do wysiania przez okablowanie, najpierw readresator przechwytuje komunikat, nakłada na niego swoje informacje nagłówkowe i kontrol­ ne, po czym przesyła go w dól do następnej warstwy. Niższe warstwy w modelu OSI obsługują warstwy wyższe, zapewniając im niezawodny transport, routing i adreso­ wanie. Usługi te są stosowane nawet wtedy, gdy komunikat to zwykłe „Hej" prze­ syłane od jednego użytkownika do drugiego. Każda warstwa w modelu OSI dołącza sw oje informacje nagłówkowe i kontrolne tak, aby odpowiadająca jej warstwa na zdalnym hośde mogła je usunąć i wiedziała, co z nimi zrobić. Każda z warstw odgrywa odrębną rolę podczas przygotowywania

R ozdział 1. ■ OM Ó W IEN IE MODELI I STANDARDÓW BRANŻOW YCH

25

danych do wysiania celem komunikacji ze zdalnym hostem partnerskim (por. ry­ sunek 1.3). Wszelkie działania właściwe dla tych ról pozostają dla użytkownika niewidoczne. R y s u n e k 1 .3 .

Partnerska współpraca w arstw

Każda warstwa modelu OSI dodaje Informacje nagłówkowe I kontrolne, wykorzystywane przez odpowiadającą w jej warstwę na hoścle a odbierającym s

|p a n e |

aplikacji

------------------------------------- 1 AH |D anej—

PH I A H | Danej—

prezentacji

PH

transportow a

AH

aplikacji

prezentacji

Dane,

ł | A H |p

transportow a

t

w

- j NH | TH 11

y łącza danych

fizyczna

♦j OH

PH | A H | Danej—

I [Danej [

| N H | T H | SH

-C U

Bity

łą c z a danych

fizyczna

Gdy kom puter przekazuje dane z jednej warstwy do następnej, każda kolejna war­ stwa dodaje do nich informacje nagłówkowe oraz kontrolne i tak dane te wędrują w dół do warstwy fizycznej i rzeczywistego nośnika fizycznego (przewodu czy też kabla sieciowego). Każda warstwa traktuje wszystko to, co przekazuje w dół, jako ogólne dane warstw wyższych. Przypomina to wkładanie w każdej warstwie jednej koperty do drugiej. Na przykład warstwa aplikacji dodaje inform acje nagłówkowe i kontrolne, prze­ znaczone dla odpowiadającej jej warstwy aplikacji na zdalnym hośde. Następnie przekazuje je wraz z danymi w dół, do warstwy prezentacji. Warstwa ta odczytuje informacje warstwy wyższej jako dane, nie dzieląc ich na inform acje nagłówkowe i kontrolne ani dane. Warstwa prezentacji dodaje sw oje inform acje nagłówkowe i kontrolne, przeznaczone dla warstwy prezentacji na zdalnym hośde. Innymi sło­ wy każda warstwa niższa (w tym przypadku prezentacji) nie zważa na informacje nagłówkowe i kontrolne ani dane warstwy wyższej, traktując to wszystko jako jed ­ ną całość — dane. Każda warstwa w ykorzystuje jedynie informacje kontrolne i na­ główkowe oraz dane odpowiadającej jej warstwy partnerskiej ze zdalnego hosta. Każda kolejna warstwa dodaje swoje własne informacje nagłówkowe i kontrolne oraz wysyła dane w dół, na następny poziom. Gdy dane osiągną poziom łącza danych, system uruchamia algorytm zwany cykliczną kontrolą nadmiarowości (CRC, Cyclical Redundancy Check) lub sekwencją kontroli ram­ ki (FCS, Frame Check Sequence). Następnie dodaje w ynik CRC jako stopkę (trailer) na końcu informacji, gwarantującą zgodność bitów wysyłanych z bitami odbieranymi

26

TCP/IP. SZKOŁA PROGRAM OW ANIA

przez hosta końcowego. Term in ram ka odnosi się do logicznego pogrupowania in­ formacji, jakiemu ulegają dane w warstwie łącza danych. Dalej dane te wychodzą na okablowanie jako sygnały elektryczne lub świetlne — jedynki (1) i zera (0) — a zamie­ rzony host zdalny je odbiera (por. rysunek 1.4). R y s u n e k 1 .4 .

Host odbierający usuwa nagłówki i stopki, po czym wysyła dane w górę, do następnej warstwy

N agłówki i stopki

Hi

aplikacji H2

prezentacji H3

sesji

H4

transportow a

H5

sieciow a łącza danych

Hg

fizyczna

K om unikaty K om unikaty Kom unikaty S egm enty D atagram y lu b Pakiety R am ki

CRC

Bity 1 0 1 0 1 0 s

Po odebraniu danych proces się odwraca. Każda warstwa usuwa swoje informacje nagłówkowe i kontrolne oraz przekazuje dane w górę, do następnej warstwy, odsła­ niając informacje nagłówkowe i kontrolne oraz dane właśnie tej warstwy. Gdy dane wreszcie dojdą do warstwy aplikacji, ta ściąga swoje własne informacje nagłówko­ we i kontrolne oraz przekazuje dane wzwyż. Dzieje się tak z każdą pojedynczą ramką przechodzącą przez okablowanie. Każda warstwa musi dołączać do danych informacje nagłówkowe i kontrolne tak, aby jej odpowiadająca jej warstwa partnerska mogła zidentyfikować warstwę wyższą, która powinna je otrzymać jako następna.

Warstwa aplikacji Czasem mylnie uważa się, że nazwa szczytowej warstwy modelu O SI odnosi się do aplikacji użytkownika, takich jak Word, Excel, PowerPoint, itp. Nazwa ta nie wiąże się jednak z samym oprogramowaniem aplikacyjnym, ale raczej z możliwością do­ stępu przez sieć do danych jednej aplikacji z innej oraz z dostępem do modelu refe­ rencyjnego OSI, m ającym na celu przygotowanie danych do umieszczenia ich w pakiecie i wysiania przez okablowanie. Warstwa aplikacji umożliwia aplikacjom użytkownika wysyłanie danych przez sieć, po prostu zapewniając im dostęp do warstw niższych (dostęp do modelu OSI). Jej zadaniem jest dostarczenie interfejsu do stosu protokołów. W przeciwieństwie do innych warstw OSI, nie oferuje ona usług żadnym innym warstwom, udostępniając jedynie własne usługi. Usługi warstwy aplikacji obejm ują m. in.: ► aplikacyjne usługi sieciowe i międzysiedowe; ► usługi plikowe i wydruku;

R ozdział 1. • O M Ó W IEN IE M ODELI I STAN D ARD Ó W BRANŻOW YCH

27

► pocztę elektroniczną (e-mail); ► dostęp do sied WWW (World Wide Web) i protokół przesyłania hipertekstu (HTTP, HyperText Transfer Protocol); ► dostęp za pomocą protokołu Telnet ze zdalnego hosta; ► protokół przesyłania plików (FTP, File Transfer Protocol). Te i inne usługi zostaną omówione w niniejszej książce.

Warstwa prezentacji Warstwa prezentacji zapewnia różnym platformom wspólny format danych. Od­ powiada ona za następujące usługi: ► konwersję i tłumaczenie (translację) danych; ► kompresję i dekompresję; ► szyfrowanie i odszyfrowywanie. Przykładem rzeczywistego protokołu tej warstwy jest XDR (external Data Repre­ sentation), stosowany w opartym na schemacie klient-serwer systemie plików NFS (Network File System), stworzonym przez firmę Sun MicroSystems. Protokół ten zapewnia niezależność od platformy. Jest on w istode włączony do kodu oprogra­ mowania. System plików NFS i protokół XDR będą dokładnie om awiane w roz­ dziale 18.

Warstwa sesji Warstwa sesji ustanawia sesje i zarządza nimi. Sesja składa się z dialogu między warstwami prezentacji w przynajmniej dwóch systemach. Warstwa ta obsługuje też żądania dostępu do różnych usług, występujące m iędzy systemami, i zarządza od­ powiedziami na te żądania. Poza tym steruje dialogiem m iędzy dwoma aplikacjami na różnych hostach i zarządza strumieniami danych. W ydajność sterowania dialogiem między hostami w warstwie sesji zależy od tego, czy komunikacja odbywa się w trybie p o łow iczn ie dw u kieru n kow ym (half-du plex) czy c a łk o w ic ie d w u kieru n kow ym (full-duplex). W trybie połowicznie dwukierun­ kowym tylko jedno urządzenie m oże w danej chwili się komunikować (nadawać), natomiast wszystkie pozostałe oczekują na swoją kolej. Każda strona komunikacji musi czekać na koniec wysyłania przez inną, a następnie odpowiadać odrębnym potwierdzeniem. W trybie całkowicie dwukierunkowym wysyłanie i odbieranie może być jednoczesne, co zwiększa wydajność komunikacji. Wydajność w tym trybie osiąga się przez tz.w jazdę na barana (piggybacking) lub zawieranie danych w obrębie tej sa­ mej ramki.

28

TCP/IP. SZKOŁA PROGRAMOW ANIA

Przykładem znanego protokołu warstwy sesji może być NetBIOS (Network Basic Input/Output System). Ustanawia on sesje między dwoma komputerami z systemem operacyjnym typu Windows (NT lub 9x) firmy Microsoft. Protokół ten zapewnia usługi nazewnicze i zarządzanie sesjami między dwoma urządzeniami korzystają­ cymi z nazewnictwa prostego. Warstwa sesji obsługuje też zdatne wywoływanie procedur (RPC, Remote Procedure Call), zaprojektowane przez firmę Sun, umożliwiające klientom tworzenie żądań przeznaczonych do zdalnego wykonywania. Żądania te są wysyłane do zdalnego hosta celem przetworzenia i udzielenia odpowiedzi, co pozwala na komunikację mię­ dzy dwoma hostami przez sieć. System plików NFS stosuje RPC do wysyłania wy­ w ołań i odbierania odpowiedzi w warstwie sesji, zaś w warstwie prezentacji wyko­ rzystuje protokół XDR.

Warstwa transportowa Warstwa transportowa w zasadzie ma zapewniać gwarantowane, niezawodne do­ starczanie danych tylko między dwoma komunikującymi się procesami lub pro­ gramami, uruchomionymi na zdalnych hostach. Jest to jednak prawdą tylko wtedy, gdy dostawca zdecyduje się zaimplementować protokół sterowania transmisją TCP (TCP, Transmission Control Protocol) zamiast jego mniej niezawodnego odpo­ wiednika, protokołu datagramów użytkownika UDP (UDP, User Datagram Protocol). Protokoły te omówimy w rozdziałach 8 i 9. Warstwa transportowa w ykonuje następujące działania: ► Steruje komunikacją całościową („od końca do końca") między dwoma procesami uruchomionymi na różnych hostach. ► Zapewnia usługi połączeniowe i bezpolączeniowe warstwom wyższym. ► W ykorzystuje adresy portów klienta i serwera do identyfikacji procesów uru­ chom ionych w obrębie hosta. ► Segm entuje dane dla aplikacji warstw wyższych. Zadaniem tej warstwy jest identyfikowanie procesów kom unikujących się na każ­ dym hośde oraz zapewnianie usług połączeniowych i niezawodnego transportu, bądź szybkości dostarczania. Zarządza ona przepływem danych, a gdy sesja jest połączeniowa zajmuje się sterowaniem przepływem. W warstwie tej rezydują pro­ tokoły TCP i UDP. Segm entuje ona dane (komunikaty) podawane w dół przez aplikacje warstw wyż­ szych. Obsługuje adresowanie za pomocą p ortów , zwanych też gn iazd am i (sockets), identyfikujących programy lub procesy warstw wyższych, komunikujące się na kon­ kretnym urządzeniu. Śledzenie różnych segmentów i zarządzanie nimi zapewniają jej num ery portów każdej aplikacji.

Rozdział 1. • O M Ó W IEN IE M ODELI I STAN D ARD Ó W BRANŻOW YCH

29

Łączenie gniazd w pary Gdy występuje komunikacja całościowa między dwom a hostaml, w której uczestni­ czą źródłowe i docelowe adresy IP I porty (zwane też gniazdami), wówczas w branży nazywa się to parą g n ia zd {socket p a ir).

Warstwa transportowa może zapewniać protokołom warstw wyższych zarówno obsługę połączeniową, jak i bezpołączeniową. Zawsze jedn ak zajm uje się portami i adresami. Adresy klienta i serwera (np. porty TCP lub UDP) służą do identyfikacji procesów uruchomionych w obrębie hosta. Warstwę transportową dokładnie omówimy w rozdziale 7.

Warstwa sieciowa Warstwa sieciowa przede wszystkim przypisuje logiczne adresy źródłowy i doce­ lowy oraz określa najlepszą ścieżkę routingu danych między sieciami. Warstwa ta zapewnia: ► komunikację całościową między dwoma hostami, ► adresowanie logiczne, ► dostarczanie pakietów, ► routing. Protokoły warstwy Sieciowej zajm ują się adresoioan iem logiczn ym , które należy od­ różnić od adresowania MAC (Media Access Control) warstwy fizycznej, skojarzo­ nego z kartami sieciowymi. W przeciwieństwie do adresów fizycznych (przypisa­ nych na stałe), dostawcy nie um ieszczają na stale adresów logicznych w kartach. Zamiast tego administratorzy sied przypisują je ręcznie lub dynamicznie. Adresy logiczne warstwy siedow ej będą omawiane w rozdziałach 4 - 6 . Aby zapewnić najlepszy routing danych, urządzenia warstwy siedow ej (takie, jak routery) stosują przełączan ie p a k ie tó ic (p acket sw itching). W procesie tym router identyfikuje logiczny adres docelowy (warstwy siedow ej) ruchu siedow ego odbie­ ranego na jednym interfejsie, po czym z innego interfejsu wysyła go do miejsca przeznaczenia. W warstwie siedow ej działają następujące protokoły: ► RA RP, ARP, BootP, DHCP — zapew niające konfigurację lub rozwiązywanie adresów; ► ICM P — diagnostyczny i kontrolny; ► R IP, IG R P, EIG RP, O SPF i BG P — trasujące.

30

TCP/IP. SZKOŁA PROGRAMOW ANIA

Warstwa łącza danych Do głównych obowiązków warstwy łącza danych modelu O SI należy wysyłanie i odbiór ramek oraz adresowanie fizyczne. Warstwa ta przed wysłaniem otrzymanych z góry danych dodaje do nich zarówno nagłówek z przodu, jak i czterobajtową stopkę na końcu, tworząc w ten sposób ram kę (fram e) wokół tych danych. Termin ram kow an ie p a k ie tó w (packet fram in g) oznacza tworzenie ciągów takich ramek. Stopki dodaje do danych tylko warstwa łącza danych. Warstwa łącza danych ma następujące cechy i obowiązki: ► Steruje dostępem do nośnika. ► Dodaje adresy sprzętowe — źródłowy i docelowy. ► Przygotowuje ramki do transmisji, konw ertując pakiety danych na ramki. ► Bierze na siebie funkcję wysyłania i odbierania danych przez okablowanie. ► Oblicza wielkości CRC lub FCS. ► Obsługuje mosty (bridges) i przełączniki (switches).

Adresy warstwy drugiej Producenci zapisują na stale w każdej karcie sieciowej adres warstwy łącza danych (adres MAC). Podczas produkcji kart określają ich numery seryjne. Każdy adres ma sześć bajtów długości, zgodnie z zaleceniem IEEE. Pierwsze trzy bajty określają konkretnego dostawcę, który z kolei w sposób niepowtarzalny przypisuje wartości ostatnim trzem bajtom. Urządzenia działające w warstwie łącza danych muszą mieć możliwość identyfikowania tych adresów. Warstwa łącza danych dodaje do nagłówka adresy MAC — źródłowy i docelowy — celem identyfikacji karty sieciowej urządzenia wysyłającego ramkę, jak i urządzenia które powinno ją odebrać. Każdy adres MAC musi być niepowtarzalny (unikatowy) w całej sieci. Urządzenia warstwy 2 w oparciu o adres docelowy decydują, czy in­ formacje należy przekazać dalej. Przed transmisją nadające urządzenia stosują algorytm cyklicznej kontroli nadmiarowości (CRC) lub sekwencji kontroli ramki (FCS). W branży te dwa terminy stosowane są zamiennie. Urządzenia warstwy łącza danych dodają wynik CRC lub FCS jako stopkę na końcu danych podawanych w dól przez warstwę sieciową, obramowując w ten sposób przesyłane bity. Z tego powodu w warstwie łącza danych mówi się właśnie o „ramkach". Wartości sum kontrolnych CRC (lub FCS) nie gwarantują do­ starczenia danych, a służą jedynie do sprawdzania, czy bity wysyłane zgadzają się z bitami odebranymi przez hosta docelowego. Za pomocą tego samego algorytmu hosty odbierające sprawdzają, czy w trakcie przesyłania ramka nie została uszkodzo­ na. Gdy wielkości CRC (lub FCS) nie są zgodne, host odbierający po prostu odrzuca ramkę bez powiadamiania stacji wysyłającej. Jeżeli ramka nie jest prawidłowa, stacja docelowa nigdy nie przekaże danych do warstwy wyższej. Obowiązek ponownego wysyłania uszkodzonych ram ek spoczywa na urządzeniach wysyłających.

R ozdział 1. • O M Ó W IEN IE M ODELI I STAN D ARD Ó W BRANŻOW YCH

31

Warstwa fizyczna Warstwa fizyczna zajmuje się jedynkami (1) i zerami (0), czyli bitami tworzącymi ramkę. B ity kodowane są jako impulsy elektryczne lub świetlne. Warstwa ta zajmuje się też charakterystykami elektrycznymi i mechanicznym i, kodowaniem sygnałów i poziomami napięcia. Mówiąc ogólnie: dotyczy ona elementów namacalnych, czyli takich elementów fizycznych, których można dotknąć, np. okablowania czy wtórników (repeaters). Warstwa fizyczna obejmuje: ► charakterystyki elektryczne i m echaniczne; ► kodowanie sygnałów; ► jedynki (1) i zera (0); ► specyfikacje złączy fizycznych.

Architektura i topologie łącza danych Termin a p lik a c ja oznacza literalne zastosowanie standardów w formie architektury sieciowej i specyfikacji dotyczących głów nych topologii. Standardy te obejmują specyfikacje IEEE i ANSI (American National Standards Institute), przeznaczone dla następujących technologii: ► Ethernet, ► Szybki (Fast) Ethernet, ► Gigabitowy Ethernet, ► Token-Ring, ► FDDI. Standardy obejm ują też typy ram ek i m etody dostępu do kanału, określane przez IEEE i ANSI. Kolejne punkty w charakterze przypomnienia zawierają ogólne om ó­ wienie tych technologii.

Ethernet i IEEE 802.3 Zaczynamy od najbardziej popularnej architektury łącza danych, mianowicie tech­ nologii ethernetowych, zdefiniowanych przez IEEE w ramach specyfikacji 802.3. Zasługę wynalezienia Ethernetu zwykle przyznaje się firmie Xerox Corporation, jednak w rzeczywistości uzyskała ona źródłową technologię o nazwie Aloha Net w latach 1970-tych od Uniwersytetu Hawajskiego. Następnie Xerox dołączył do firm DEC i Intel celem zaprojektowania najwcześniejszego standardu ethernetowego, wypuszczonego w roku 1980 jako wersja 1. W 1982 roku te trzy firmy wydały kolejny, ulepszony standard: ethernet wersja 2.

32

TCP/IP. SZKOŁA PROGRAMOW ANIA

W połowie lat 1980-tych komitet 802 organizacji IEEE zaadoptował ethernet jako standard 802.3. Wszystkie aktualne i przyszłe projekty technologii ethernetowych rzekomo m ają się opierać właśnie na tym standardzie bazowym. Ze względu na swoje początki Ethernet stal się najpopularniejszym, stosowanym na całym św iede standardem sied LAN (Local Area NetWork). Warto pamiętać, że Ethernet to nie to samo, co implementacje IEEE 802.3, a terminów tych nie powinno się stosować zamiennie (choć czasem się tak robi). Firmy Xerox, DEC i Intel zaprojektowały wersje 1 i 2 z dość podobnymi parametrami, a komitet IEEE 802 dodał do nich szereg znormalizowanych funkcji rozszerzonych, nie współ­ dzielonych z poprzednikami. Tabela 1.1 zawiera omówienie podobieństw i różnic między tymi implementacjami. TABELA 1.1. Wersje 1 i 2 ethernetu oraz IEEE 8 0 2 .3 W ersja 1

W ersja 2

IEEE 8 0 2 .3

A rchitektura w arstw y łącza danych.

Zawiera E th e rn e tJ I, celem w ykryw ania 1 odrzucania w a d liw ych ram ek We facto schemat branżowy przenoszenia ruchu IP przez

Dodaje nadbiorniki (transceivers) z kontrolą rozwlekania (lub pochłanianiem rozwlekania).

sieci LAN typu ethernet). Dostarczała dane z szybkością 1 0 Mb/s w topologii magistrali liniowej (linear bus).

Dostarcza dane z szybkością 10 M b/s w topologii m agistrali liniow ej.

Rozciąga obsługę topologii fizycznych na konfiguracje gwiazdy (star).

Mogła korzystać tylko z nośnika

grubego koncentrycznego

Może korzystać tylko z nośnika grubego

(th ick coaxial).

koncentrycznego.

Dodaje takie typ y nośników, ja k cienki koncentryczny (thin coaxial), światłowód (fiber) 1 skrętka dwużylowa (tw isted pair).

Stosowała sygnalizację niezrównoważoną (unbalanced

Stosuje sygnalizację zrównoważoną

signaling) z uziem ieniem jako punktem odniesienia, w rażliw ą na szum (noise) i interferencje

(balanced slgnaling).

Rozszerzenia z 1 9 9 5 roku oferują szybkości przesyłu 1 0 0 M b/s (specyfikacja 8 0 2 .3 U ).

elektrom agnetyczne (EM I, Electro-M agnetic Interference). Nie obsługiw ała błędu jakości sygnału (SQE, Signal Q uality Error), zw anego też sygnałem taktowania (heartbeat), w ięc w ykryw anie kolizji

Dodaje SQE.

Obsługuje SQE, ale jest to konieczne tylko przy nadbiornikach zewnętrznych.

(collisions) było trudniejsze. Niezgodna z w ersją 2 .

Niezgodna z w ersją 1.

Niezgodna z w ersją 1.

R ozdział 1. • O M Ó W IEN IE M ODELI I STAN D ARD Ó W BRANŻOW YCH

33

W ersja 1 specyfikacji Ethernet reprezentuje dane w opardu o obecność lub nie­ obecność napięda, co nosi nazwę sy g n aliza cji n iezrów now ażonej. Ten typ transmisji jest wysoce podatny na zakłócenia zewnętrzne. Przykład takiej sygnalizacji widać na rysunku 1.5. R y s u n e k 1 .5 .

Ethernet, Wersja 1

W sygnalizacji niezrównoważonej dane są reprezentowane przez poziomy napięcia zmieniające się od 0 (uziemienie) do + 5 w oltów W wersji 2 Ethernetu wprowadzono lepszą m etodę sy g n alizacji zrów n ow ażon ej, re­ prezentującej dane w opardu o zmiany napięda z dodatniego na ujem ne, z napiędem 0 (uziemieniem) jako wspólnym punktem odniesienia (por. rysunek 1.6). Dzięki niej wpływ zakłóceń transmisji m aleje, a przez to wzrasta jakość sygnału. R y s u n e k 1 .6 .

Sygnalizacja zrównoważona zwiększa jakość sygnału dzięki wspólnemu punktowi odniesienia, a dane reprezentuje przez dodatnie i ujemne poziomy napięcia Specyfikacja IEEE 802.3 opisuje ogólne działanie, składniki i ograniczenia odleglośdow e Ethernetu: ► Definiuje wszystkie składniki, funkcje, metody dostępu do kanału i działania warstw łącza danych i fizycznej. ► Daje dostawcom reguły wdrażania i rozwijania technologii sied LAN typu 802.3. ► Jest oparta na standardzie IEEE o nazwie 10Base5, z drobnymi odchyleniami spełnianym przez wszelkie inne standardy 802.3. Standard IEEE 802.3 definiuje opartą na rozgłaszaniu (broadcast) liniową architektu­ rę sieaow ą o szybkośd 10 Mb/s, opartą na rywalizacyjnej metodzie dostępu do ka­ nału, zwanej dostęp z n asłu chiw an iem n ośn ej z d etekcją k o liz ji (CSMA/CD, Carrier Sense Multiple Access with Collision Detection) — por. niżej.

34

TCP/IP. SZKOŁA PROGRAM OW ANIA

Metoda dostępu do kanału Obecnie istnieją różne m etody dostępu do kan ału , zależne od architektury sieciowej (Ethernet wykorzystuje metodę opartą na rywalizacji). Opisują one reguły dyktujące urządzeniom sposób: ► dostępu do nośnika komunikacyjnego, ► przesyłania ramek, ► zwalniania kanału dla innych urządzeń. Urządzenia korzystające z m etody CSMA/CD: ► rywalizują o prawo do transmisji; ► mogą pomyślnie transmitować tylko pojedynczo (jedno urządzenie naraz); ► muszą poczekać na dostępność kanału aby wysiać ramkę w sytuacji, gdy inne urządzenia wykorzystują kanał (działanie połowicznie dwukierunkowe). Gdy urządzenia nadają jednocześnie na tym samym kanale, występują kolizje sy­ gnałów i ramki ulegają uszkodzeniu. Taki dostęp oparty na rywalizacji nosi nazwę CSMA/CD. Ponieważ dla Ethernetu wskaźnikiem możliwości wysyłania jest cisza, aby ją wykryć urządzenia przeprowadzają nasłuchiwanie nośnej. Jeśli nie wykryją w przewodzie żadnej częstotliwości, uzyskują dostęp do kanału i mogą od razu za­ cząć transmisję. Po transmisji urządzenia zwalniają kanał, a zanim ponow nie spró­ bują uzyskać do niego dostęp, czekają przynajmniej 9,6 p s (mikrosekund). Dzięki temu inne nadbiorniki m ają szansę na wysianie własnych ramek.

Kolizje K olizje to, jak sama nazwa wskazuje, właśnie kolizje. W jakiejkolw iek danej chwili w sied o transmisji w paśmie podstawowym (baseband) kanał powinien być zajęty przez najwyżej jeden sygnał. Jeśli przez przewód jednocześnie przemieszcza się więcej sygnałów, wynikiem jest kolizja utrudniająca pomyślną transmisję. Podczas transmisji nadbiornik (nadajnik-odbiornik) koduje sygnał na nośniku i nasłuchuje kolizji. Gdy taka nastąpi, wówczas w ewnętrzny zespól obwodów nadbiornika, słu­ żący do detekcji kolizji, powiadamia kartę siedow ą za pomocą sygnału zmuszają­ cego ją do przerwania transmisji. Za w ykryde i ponow ne wysłanie ram ek po kolizji odpowiada urządzenie nadające. Kolizje są codziennośaą Ethernetu, jednak kolizje nadmierne lub spóźnione są po­ wodem do zmartwień. Nadmierne kolizje są powodowane przez przedążenie oda n k a (segmentu) zbyt wieloma urządzeniami. Gdy każde z nich współzawodniczy o kanał, prawdopodobieństwo kolizji rośnie wskutek samej ilośd sygnałów. Specyfikacja 802.3 definiuje k o liz je spóźn ion e (la te collision s) jako występujące po 64-tym bajdę ramki. Ich przyczyną może być przekroczenie maksymalnego ograni­ czenia dlugośa nośnika, znane jako opóźn ien ie pro p ag acji (propagation delay) lub

R ozdział 1. • O M Ó W IEN IE MODELI I STANDARDÓW BRANŻOW YCH

35

aw aria sprzętu (hardw are failure). Zderzeń spóźnionych nigdy nie powinno się uważać za część normalnego działania Ethernetu.

Ramki Ethernetowe W dziedzinie standardów Ethemetowych istnieją następujące cztery różne typy ramek, każdy zaprojektowany przez kogo innego i dla innych celów: ► E th e m e tJI (DIX); ► Ethernet_802.3 (zastrzeżony przez Novella); t> IEEE 802.3; ► IEEE 802.3 SNAP (SubNetwork Access Protocol). Pierwotną ramkę ethernetową, o nazwie Ethernet_II lub DIX, wspólnie zaprojek­ towały firmy DEC, Intel i Xerox (w skrócie właśnie DIX). Novell zaprojektował swoją własną, zastrzeżoną ramkę Ethernet_802.3, przeznaczoną wyłącznie dla ruchu IPX/SPX. Ostatnie dwie ramki zaprojektował i nazwał instytut IEEE. Mimo nazewnictwa fir­ mowego tych typów ramek, IEEE i branża stosują nazwy odmienne. Różnice pocho­ dzą przede wszystkim od firm, stosujących ramki we własnych architekturach i ję ­ zykach. Na przykład firma Cisco odwołuje się do ramki Ethernet_II jako do ARPA. Tabela 1.2 zawiera opis nazewnictwa typów ramek, a tabela 1.3 — informacje spe­ cyficzne dla każdego z nich. Wszystkie cztery typy ram ek mogą współistnieć w jednej sied, ale nie są ze sobą zgodne. Gdy informacje chcą wymieniać stacje korzystające z niepodobnych typów hennetyzacji (encapsulation), muszą one komunikować się za pośrednictwem route­ ra obsługującego oba typy. Router taki przeprowadza konw ersję m iędzy hostami. Ponieważ konwersja niepotrzebnie zwiększa obdążenie i opóźnia ruch danych w sied, wewnątrz jednej sied najlepiej korzystać tylko z jednego typu ramek. Ta­ bela 1.4 zawiera opis cech podstawowych i drugorzędnych, charakteryzujących ramki ethernetowe. Na rysunkach 1.7 - 1 .1 0 pokazano wszystkie typy ramek. Warto porównać zarówno ich reprezentacje funkcyjne, ja k i faktyczny wygląd. Wszystkie ramki mają te same podstawowe cechy charakterystyczne: zaczynają się 6-bajtowym adresem docelo­ wym MAC, po którym następuje 6-bajtowy adres źródłowy MAC, a kończą się 4-bajtowym polem CRC. TABELA 1.2. Odwzorowanie nazw ethemetowych IEEE

Branża

-

E th e rn e tJ I (DIX)

-

E th e rn e t_8 0 2 .3

8 0 2 .3

E th e rn e t_8 0 2 .2

8 0 2 .3 SNAP

Ethernet SNAP

36

TC P/lP. SZKOŁA PROGRAM OW ANIA

TABELA 1.3. Typy ramek ethemetowych E th e rn e tJ 1 (DIX)

E th e rn e t_ 8 0 2 .3

E th e rn e t_ 8 0 2 .2

E thernet_SN A P

Służy do przenoszenia ruchu IP.

Służy do przenoszenia ruchu IPX/SPX.

Zawiera nagłów ki LLC, w ykorzystujące adresy D S A P i SSAP

Zaw iera nagłów ki LLC, w ykorzystujące adresy DSAP i SSAP

do ide n tyfika cji proto kołó w w arstw wyższych.

do identyfikacji protokołów w arstw

W ykorzystuje do identyfikacji protokołów 2 -bajtow e zastrzeżone w artości Ether-Type, np. 0 8 0 0 = IP.

Ograniczony do przenoszenia samego protokołu IPX.

W ykorzystuje zastrzeżone adresy SAP, np. E 0 = IP X .

wyższych. U względnia specjalny adres SAP AA, w skazujący na idący za nim nagłówek SNAP z d w u b a jtow ą w artością Ether-Type.

Najczęściej obecnie stosow any ty p ram ki. Był faktycznym typem

Po nagłówku LLC dodaje pięciobajtow y nagłów ek SNAP,

ram ki w sieciach IPX przed pow staniem typu E th e rn e t_8 0 2 .2 .

służący do identyfikacji protokołu.

TABELA 1.4. Charakterystyki ramek ethemetowych Podstaw ow e ce ch y ch ara kterystyczne Przed tran sm isją dodaje 1 4 -b a jto w y nagłówek.

D rugorzędne ce ch y ch ara kterystyczne Pierwsze 12 b ajtó w składa się z 6-bajtow ego adresu docelowego MAC i 6-bajtow ego adresu źródłowego (nadaw cy) MAC. Po nich następuje pole 2-ba jto w e, d efiniujące długość datagram u lub typ protokołu.

Przed tran sm isją dołącza 4 -ba jto w ą stopkę (CRC lub FCS).

Dodawana przez nadawcę i porównywana przez odbiorcę po to, żeby u pew nić się, że ram ka nie została uszkodzona

Przed tran sm isją każdej ram ki w ysyła 6 4 -b ito w ą pream bułę celem osiągnięcia synchronizacji.

Zawiera 7 b a jtó w na przem ian jedynek (1 ) i zer (0 ); ostatnie 2 b ity 8-ego bajtu a la rm u ją stacje o nadchodzeniu danych.

N ajm niejszy dozw olony rozm iar ram ki w ynosi 6 4 b ajty (ram ki mniejsze muszą

Zaw iera 1 4 -b a jto w y nagłówek Łącza D anych,

być dopełniane), a najw iększy 1 5 1 8 bajtów .

4 -b a jto w ą doczepkę oraz m aksym alnie 1 5 0 0 bajtów protokołów i danych w arstw w yższych.

Rozdział 1. • O M Ó W IEN IE MODELI I STANDARDÓW BRANŻOW YCH

R y s u n e k 1 .7 .

37

EthernetJI

Ramka EthernetJI jako jedyna zawiera po adresie źródłowym 2-bajtow ą wartość Ether-Type, służącą do identyfikacji protokołu przenoszonego wewnątrz ramki

Preambuła DA SA EType

6

Dane

CRC

6 127.0.0.1 — służy do testowania wewnętrznej pętli zwrotnej. Oznacza węzeł lo­ kalny i nie generuje żadnego ruchu sieciowego. Adres 255.255.255.255, uważany za rozgłaszanie na całą sieć, nie jest jednak przeka­ zywany przez routery (ograniczające w ten sposób rozgłaszanie do podsieci). Roz­ głaszanie do wszystkich hostów w podsieci lub sieci występuje wtedy, gdy wszyst­ kie bity hostowe są ustawione na 1. Na przykład w sieci klasy B o adresie 131.107.0.0 (ze standardową maską 255.255.0.0) rozgłaszanie do wszystkich hostów musi mieć adres docelowy 131.107.255.255. Adresy zarezerwowane dotyczą też sieci prywatnych, o zakresach następująco zdefiniowanych przez RFC 1918: ► 10.0.0.0 -10.255.255.255; ► 172.16.0.0 -172.31.255.255; ► 192.168.0.0 -192.168.255.255. Niezarejestrowanych adresów prywatnych nie można wykorzystywać w Interne­ cie. Są one na ogól stosowane w wewnętrznych sieciach firm. Sieci prywatne 10.x.x.x, zapewniające elastyczność adresowania wewnętrznego, są wykorzystywane przez wiele firm. Dzięki 3 bajtom dostępnym dla podsieci i ho­ stów, obsługują one potrzeby adresowe dowolnej firmy w stopniu bardziej niż wy­ starczającym. Ponieważ zaczyna brakować zarejestrowanych adresów IP, wewnątrz firm przeważnie stosuje się schematy adresowania prywatnego uzupełnione o me­ chanizmy tłumaczenia adresów, pozwalające na dostęp do Internetu za pośred­ nictwem jednego lub dwóch zarejestrowanych zewnętrznych adresów IP. Tłumaczenie (translacja) wewnętrznych adresów prywatnych na zewnętrzne adre­ sy zarejestrowane (i odwrotnie) nosi nazwę tłumaczenia adresów siecioiuych (NAT, NetWork Address Translation). Za proces ten odpowiada zwykle brama (router) lub zapora ogniowa (firewall), łącząca sieć firmy ze światem zewnętrznym czy też Inter­ netem (gdzie adresy prywatne są niedozwolone). Technikę NAT omówimy dalej (w tym rozdziale).

58

TCP/IP. SZKOŁA PROGRAMOWANIA

Maski sieci i podsieci „Co to są maski podsieci i do czego są potrzebne?" — mógłby ktoś spytać. Odpo­ wiedź jest prosta: są to wskaźniki adresowe, w oparciu o które hosty i routery okre­ ślają, czy należy rozgłosić, czy też skierow ać ruch tak, aby przekazać da ta gramy do hosta docelowego. Można by dalej zapytać: „Co oznacza rozgłaszanie, a co kierow a­ nie (rautowanie)?" Mówiąc krótko: jeśli host wysyłający wie, że docelowy znajduje się w tym samym segmencie lokalnym , może on wykonać lokalne rozgłoszenie ARP (Address Resolution Protocol) celem zamiany logicznego adresu IP warstwy sieciowej na fizyczny adres MAC. Jeśli natomiast host wysyłający wie, że odbiorca znajduje się w podsieci lub sieci oddalonej, nadawca musi skierow ać ramkę wysyłając ją do bramy lokalnej (lokalnego routera bramowego). Host wysyłający określa za pomocą maski lokalnej, czy powinien rozgłaszać, czy też kierować. Dokładne omówienie protokołu ARP i zamiany (rozwiązywalna) adresów znajduje się w rozdziale 4. Każdy z trzech klasowych typów sieci posiada odpowiadającą mu domyślną maskę klasową podsieci. Jak już wiemy, adresy klasy A wykorzystują maskę domyślną 255.0.0.0, czyli /8. Adresy klasy B wykorzystują maskę domyślną 255.255.0.0, czyli /16. W tym przypadku pierwsze 2 bajty zostały „wymaskowane" przez włączenie wszystkich 8 bitów w obrębie każdego z tych bajtów. Po dodaniu wartości wszyst­ kich bitów w takim oktecie, uzyskujemy maksymalną wartość 255. Ostatnie 16 bi­ tów (2 bajty) pozostaje nieużywanych (i nie zdefiniowanych dla celów sieciowych) — wszystkie mają wartość 0 i są dostępne dla podsieci i hostów. Adresy klasy C mają domyślną maskę 255.255.255.0, czyli /24, wyraźnie wskazującą na pierwsze 3 bajty adresu jako na jego część sieciową. Ostatnie 8 bitów pozostaje nie zamaskowanych, dostępnych dla podsieci i hostów. Przypuśćmy, że host 166.3.22.1 (adres klasy B) chce ustanowić połączenie ze zdalnym serwerem Telnetu o adresie 151.10.5.2 (znów klasy B). Warto zapamiętać, że host wysyłający w ogóle nie wie, gdzie naprawdę znajduje się host docelowy. Innymi słowy sam adres IP hosta do­ celowego jeszcze nie mówi nadawcy, gdzie lub jak można się do mego dostać, ani nawet czy znajduje się on w segmencie lokalnym. Aby host wysyłający mógł określić, czy host docelowy znajduje się w tym samym segmencie lokalnym, porównuje on swoją maskę podsieci z docelowym adresem IP. Gdy nadawca stwierdzi, że host odbierający znajduje się w podsieci lokalnej, będzie mógł wysłać lokalne rozgłoszenie ARP celem zamiany tego adresu logicznego na fi­ zyczny (MAC). Host źródłowy określa czy host docelowy znajduje się w tej samej podsieci, wyko­ nując koniunkcję bitow ą (bitw ise ANDing) porównującą adres IP hosta docelowego z maską podsieci hosta wysyłającego (operację tę omówimy nieco dalej). Dopóki tego nie zrobi, nie ma pojęcia czy host docelowy jest lokalny, czy też oddalony. Gdy nadawca stwierdzi, że odbiorcy nie ma w segmencie lokalnym (jest oddalony), bę­ dzie wiedział, że wysłanie lokalnego komunikatu ARP nie dotrze do oddalonego hosta. Będzie zatem wiedział, że musi skierować ramkę do bramy lokalnej celem jej

Rozdział 2. ° ADRESOW ANIE IP

59

dalszego przekazania. Host wysyłający musi więc znać adres MAC tej bramy. Na szczęście host ten już z niej korzystał, więc nadal ma te informacje w buforze. Jeśli nie, wówczas przed wysłaniem datagramów do dalszego przekazania host nadają­ cy musi wysłać lokalny komunikat ARP, służący do zamiany adresu IP bramy na jej adres MAC (por. rysunek 2.6). Rys u n ek 2 .6 .

To, czy cel jest lokalny, czy też zdalny określa, w jaki sposób router przystępuje do zamiany (rozwiązywania) adresów

M o g ę ro z g ło s ić ? C zy te ż p o w in ie n e m s k ie ro w a ć ?

Ź ró d ło w y a dre s IP:

166.3.22.1

H ost d o ce lo w y:

151.10.5.2

M A S K A hosta źró dło w e g o :

2 55 .25 5 .0 .0

Warto wiedzieć, że niewłaściwie skonfigurowana maska podsieci może spowodo­ wać, iż host wysyłający będzie rozgłaszał (wysyłał lokalne rozgłoszenie ARP, doty­ czące hosta końcowego) wtedy, kiedy powinien skierować (wysłać lokalne rozgło­ szenie ARP, dotyczące bramy) i vice versa. Powiedzmy na przykład, że hosty A i B znajdują się w tym samym odcinku fizycznym. Użytkownik hosta A (adres IP = 155.10.1.1) wpisuje polecenie Telnet i adres IP, chcąc podłączyć się do hosta B (adres IP = 155.10.2.2). Dopóki jednak host A nie porówna adresu hosta B ze swoją maską podsieci, nie będzie wiedział czy host B znajduje się w tym samym segmencie. Oba hosty mają adresy klasy B, tzn. ich pierwsze 2 bajty są adresami sieci 155.10.0.0, więc powinny mieć maskę 255.255.0.0. Maska hosta A jest jednak niepoprawnie skonfigurowana jako 255.255.255.0, wskutek czego traktuje on pierwsze 3 bajty jako adres sieci. Porównując tę maskę z adresem IP hosta B wydaje mu się, że adres sieci docelowej wynosi 155.10.2.0, czyli że host B jest oddalony. W efekcie zamiast rozgłosić (wysłać lokalne rozgłoszenie ARP przeznaczone dla hosta końcowego) i przekazać datagramy bezpośrednio do hosta B, kieruje (wysyła lokalne rozgłoszenie ARP przeznaczone dla bramy) i przekazuje datagramy do bramy wyznaczonej dla tego hosta. Gdyby host A miał właściwą maskę podsieci, wówczas stwierdziłby obecność hosta B w tej samej podsieci lokalnej, w efekcie wysyłając lokalne rozgłoszenie ARP celem zamiany adresu IP hosta B na jego adres MAC. Następnie przekazałby datagramy do tego hosta bez pomocy bramy. Ponieważ jednak host A ma złe informacje, dokonuje niezbyt dobrego wyboru wysyłając do bramy coś, co powinno być ramką lokalną. Jeśli brama jest właściwie skonfigurowana, tak samo porównuje ona adres IP z maską podsieci, stwierdza że host B znajduje się w podsieci lokalnej, po czym zwraca ramkę tym samym interfejsem, którym ją odebrała. Brama wysyła też do hosta A komuni­ kat przekierowania ICMP (Internet Control Message Protocol), powiadamiający go o lepszym sposobie wysłania tej ramki (komunikaty takie będą dokładnie omawiane

60

TCP/IP. SZKOŁA PROGRAMOWANIA

w rozdziale 3, natomiast ARP i RARP w rozdziale 4). Nie rozwiązuje to jednak proble­ mu ze źle skonfigurowaną maską na hoście A. Najlepiej w takiej sytuacji poprawić na nim maskę podsieci. W przeciwnym razie host A wciąż będzie wysyłał do bramy ramki lokalne, które mogłyby być wysyłane bezpośrednio do lokalnych hostów w da­ nym segmencie.

Koniunkcja bitowa Koniunkcja bitowa (mnożenie logiczne bit po bicie) służy do porównywania adresu IP hosta docelowego z maską podsieci hosta wysyłającego (por. rysunki 2.7 i 2.8). Procesem tym rządzi szereg reguł, przed zastosowaniem których należy przekształ­ cić adresy na ich postacie dwójkowe. Oto reguły koniunkcji: > Jeśli obie wartości wynoszą 1, wynikiem jest 1. > Jeśli jedna z wartości wynosi 0, a druga 1, wynikiem jest 0. > Jeśli obie wartości wynoszą 0, wynikiem jest 0. Rys u n e k 2 .7 .

A d re s IP h o s ta d o c e lo w e g o :

1 5 1 .1 0 .5 .2

Podczas mnożenia bitowego iloczyn pozostaje jedynką tylko wtedy, gdy oba czynniki są jedynkami

n/laska h o s ta w y s y ła ją c e g o :

2 5 5 .2 5 5 .0 .0

1 0 0 1 0 1 1 1 .0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 1 .0 0 0 0 0 0 1 0 M a s k a 1 1 1 1 1 1 1 1 .1 1 1 1 1 1 1 1 . 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 1 .0 0 0 0 1 0 1 0 .

00000000.00000000

N r s ie c i 1 5 1 .1 0 .

Rys u n ek 2 .8 .

Aby porównać adres IP hosta wysyłającego z maską podsieci hosta docelowego, przekształcamy ich wartości dziesiętne na dwójkowe

A d re s IP h o s ta w y s y ła ją c e g o M a ska h o s ta d o c e lo w e g o

MASKA

= 166.3.22.1 = 255 . 255 . 0 . 0

10100110.00000011.00010110.00000001 11111111.11111111.00000000 00000000 10100110.00000011 00000000.00000000

Korzystając z rysunku 2.7 określmy, czy host docelowy znajduje się w tej samej pod­ sieci lokalnej, co host wysyłający. W tym celu: 1. Porównajmy adres IP hosta docelowego z maską podsieci hosta wysyłającego. Wynoszą one odpowiednio 151.10.5.2 (adres) i 255.255.0.0 (maska). 2. Przekształćmy ten adres i maskę na postać dwójkową.

Rozdział 2. ° ADRESOW ANIE IP

61

3. Narysujmy pionową linię, oddzielającą obszar zamaskowany (reprezentujący adres sieci) od obszaru nie zamaskowanego (reprezentującego część hostową). 4. Uznajmy wartość w obrębie adresu IP, przypadającą na zamaskowaną część po lewej, za część sieciową. W tym przypadku „wymaskowane" są pierwsze dwa bajty, reprezentując sieć (151.10), czyli 151.10.0.0. 5. Wartość po prawej strome linii pionowej reprezentuje adres hosta, w tym przy­ padku są to ostatnie dwa bajty o wartości 5.2. Pamiętajmy, że oddziaływanie ro­ uterów — w dziedzinie kierowania ruchu do celu - dotyczy tylko sieci i podsieci. Korzystając z rysunku 2.8 określmy, czy host wysyłający znajduje się w tej samej podsieci, co host docelowy. W tym celu: 1. Porównajmy adres IP hosta wysyłającego z maską podsieci hosta docelowego. 2. Mając adres 166.3.22.1 i standardową maskę 255.255.0.0 klasy B, przekształćmy ten adres i maskę na ich dwójkowe równoważniki celem zidentyfikowania, któ­ ra część adresu reprezentuje sieć lub podsieć. 3. Naiysujmy pionową linię, oddzielającą obszar zamaskowany (reprezentujący adres sieci) od obszaru nie zamaskowanego (reprezentującego część hostową). 4. Uznajmy wartość w obrębie adresu IP, przypadającą na zamaskowaną część po lewej, za część sieciową. W tym przypadku „wymaskowane" są pierwsze dwa bajty, reprezentując sieć (166.3). 5. Wartość po prawej stronie linii pionowej reprezentuje adres hosta, w tym przy­ padku są to ostatnie dwa bajty o wartości 22.1. Jak widać, host 5.2 (rysunek 2.7) nie znajduje się w tej samej podsieci, co host 22.1 z podsieci 166.3 (rysunek 2.8). W efekcie host A będzie wysyłał ramki do swojej bramy, a nie bezpośrednio do hosta B. Router (brama) będzie następnie przekazy­ w ana) te ramki na sąsiedni odcinek, zawierający hosta B (por. rysunek 2.91).

Podział na podsieci. Przykłady Powiedzmy, że mamy sieć TCP/IP, a rejestr ARIN lub nasz ushigodaiuca internetowy (ISP, Internet Service Provider) przypisał tej sieci adres IP i domyślną maskę klaso­ wą. Pierwszy z czterech bajtów adresu wyznacza jego klasę. Gdy nasz adres sieci wynosi 130.57.0.0 z maską domyślną 255.255.0.0, wówczas mamy sieć klasy B zdol­ ną do obsługi ponad 65 000 hostów. Prawdopodobnie to wystarczy, jednak może być przydatny podział takiej sieci na mniejsze, lepiej nadające się do zarządzania fragmenty zwane podsieciami (subnets), połączone ze sobą za pośrednictwem bram.

1 W rz ecz y w isto ści ry s u n e k ten p o k a z u je coś in n eg o , a m ian o w icie o m ó w io n ą w cześn iej sy tu ację z b łę d n ie sk o n fig u ro w an ą m ask ą — przyp. tłum.

62

TCP/IP. SZKOŁA PROGRAMOWANIA

Rys u n e k 2 .9 .

Ź le k ie ro w a n e ra m k i

Na hoście A skonfigurowano błędną maskę, uniemożliwiającą mu wysyłanie datagramów bezpośrednio do lokalnego hosta B

Cli

R ou te r

Ramka danych

im

Podział na podsieci (subnetting) jest to dzielenie większych sieci na mniejsze. Weźmy przykład placka. Mając cały placek, przypuszczalnie nie będziemy chcieli zjeść wszystkiego, tylko potniemy go na kawałki i zjemy tyle, na ile mamy ochotę. Podob­ nie z siecią: wystarczy pożyczyć bity ze strony hostowej i dodać je do strony siecio­ wej, tworząc w ten sposób podsieć. Chcąc równomiernie podzielić dużą sieć, trzeba mieć na uwadze cztery sprawy: > Ilu podsieci wymaga obecnie organizacja? Ile dodatkowych podsieci trzeba będzie utworzyć w przyszłości? > Jaka jest liczba hostów w największej podsieci tej sieci? > Jaki jest przewidywany rozmiar największej przyszłej podsieci w tej sieci? Zajmijmy się podziałem sieci 130.57.0.0 o domyślnej masce 255.255.0.0, pożyczając bity hostowe i dodając je do strony sieciowej. Powiedzmy, że potrzebne są 254 pod­ sieci. W tym celu trzeba pożyczyć 8 bitów hostowych i wykorzystać je na podsieci 130.57.x.0 (x oznacza pożyczony bajt). Maska 255.255.0.0 zmienia się wówczas w maskę podsieci 255.255.255.0. Na rysunku 2.10 sieć 130.57.0.0 została podzielona na kilka podsieci przez pożyczenie wszystkich 8 bitów z trzeciego bajtu i ich „wymaskowanie". Z tego powodu identy­ fikatory sieciowe nowych podsieci wynoszą 130.57.1, 130.57.2 itd., a zamiast jednej sieci mogą istnieć 254 nadające się do użytku podsieci. Bity można pożyczać dalej, zwiększając w ten sposób liczbę podsieci, a zmniejszając liczbę zawartych w nich hostów. Choć na przykładzie widać tylko 2 podsieci, ich dopuszczalna liczba wyno­ si 254, zapewniając spełnianie przyszłych potrzeb firmy. Przy 1 bajcie pozostawio­ nym dla hostów, każda z tych podsieci może obsługiwać maksymalnie 254 hosty.

Rozdział 2. ° ADRESOW ANIE IP

63

Jeśli zwiększymy długości maski sieci poza domyślną granicę klasową, uzyskamy tak zwaną maskę podsieci o zmiennej długości (VLSM, Variable Length Subnet Mask). Niektóre protokoły routingu nie przewidują istnienia masek VLSM, mają więc trud­ ności z kierowaniem datagramów przeznaczonych dla sied, których nie potrafią od­ krywać. Routing zostanie omówiony w rozdziale 5, a jego protokoły w rozdziale 6. Rys u n e k 2 .1 0 .

Podział sieci klasy B na podsieci

Sieć klasy B

130. 57.

2 .0

255^255^255^0 '

130. 57.

Nr sieci Nr Identyfikatory hostów podsieci

1 .0

2^255^255^0

Nr sieci Nr Identyfikatory hostów podsieci

Aby określić ile trzeba będzie pożyczyć bitów, najpierw powinno się wiedzieć ile bę­ dzie potrzebnych podsieci. Powiedzmy na przykład, że w sieci 192.3.1.0 klasy C o masce domyślnej 255.255.255.0 potrzebnych jest 13 dodatkowych podsieci. W celu obliczenia liczby bitów wymaganych dla konkretnej liczby podsieci, korzystamy ze schematu na rysunku 2.11. Rys u n ek 2 .1 1 .

Schem at obliczeń IP 65536 . 32768 X

.

X

16384

8192

4096

2048

1024

512

X

X

X

X

X

X

256 . 128 64 32 16 8 4 2 1 X . X

X

X

X

X X

X X

Schemat służący do określania, Ile bitów jest wymaganych dla podsieci I hostów

Aby określić liczbę bitów, które należy pożyczyć: 1. Zacznij od prawej. 2. Znajdź w tabeli wartość przynajmniej o 2 większą od wymaganej liczby podsieci.

64

TCP/IP. SZKOŁA PROGRAMOWANIA

3. Odejmij od tej wartości liczbę 2 (eliminując w ten sposób 2 wartości niepoprawne — same jedynki bądź same zera). 4. Wynik oznacza maksymalną liczbę podsieci możliwych do uzyskania przez po­ życzenie ilości bitów równej logarytmowi binarnemu wartości odnalezionej w punkcie 2, albo też pomniejszonej o 1 pozycji (licząc od prawej) tej wartości w tabeli. Na przykład dla 13 podsieci: 1. Pierwsza od prawej wartość przynajmniej o 2 większa od liczby potrzebnych podsieci (13) to 16. 2. Odejmij 2 od 16, uzyskując w ten sposób 14. 3. Pożyczając 4 bity (16 jest piąte od prawej), uzyskasz maksymalnie 14 podsieci, więc 13 na pewno też (por. rysunek 2.12). RYSUNEK 2 . 1 2 .

Ile bitów trz e b a p o życzyć,

W tym przypadku

jeśli P°trzebnYch iest 14 podsieci?

trzeba pożyczyć 4 bity

128

64

32

X

x

x

27< -------------------------------2° 8

16

x

x

4

x 1

2

x 1

1

1

x 1

8 + 4 + 2 + 1 =15 15 - 1 = 14 podsieci

Korzystając z tego samego schematu i metody, można obliczać liczbę bitów nie­ zbędnych dla hostów. Warto zauważyć, że mając skończoną liczbę bitów rozdziela­ nych międzypodsiecii hosty, bity wykorzystywane przez pierwsze nie mogą być wykorzystywaneprzez drugie. Na przykład gdy jest dostępnych 16 bitów, a 7 po­ życzamy dla podsieci, dla hostów zostaje tylko 9 bitów. Pożyczając 12 bitów dla podsieci, 4 pozostawiamy dla hostów. Rachunek jest prosty (16 = 9 + 7 = 12 + 4). Tak samo jak wcześniej można określić, ile podsieci uzyskamy przez pożyczenie 7 lub 12 bitów, a ile hostów w oparciu o 9 lub 4 bity. Gdy już wiadomo, że do 13 podsieci wymagane są 4 bity, trzeba rozciągnąć maskę sieci tak, aby obejmowała podsieci, tj. na 4 bity przydzielone podsieciom (maskę podsieci). Jak pamiętamy, domyślna maska klasowa dla sieci 192.3.1.0 ma 24 bity długości, czyli wynosi 255.255.255.0 (tych bitów nie ruszamy). Aby określić maskę podsieci: 1. Zacznij od skrajnego lewego bitu w obrębie ostatniego bajtu (bitu 25-ego itd.). 2. Odlicz od lewej do prawej 4 pozycje bitowe i ustaw ich bity na 1. 3. Oblicz wartość dziesiętną uzyskanej liczby w zapisie dwójkowym — 11110000 (dodaj wartości odliczonych pozycji bitowych: 128 + 64 + 32 + 16 = 240 — por. rysunek 2.13).

Rozdział 2 . - ADRESOW ANIE IP

Rys u n ek 2 .1 3 .

65

J a k a je s t m a s k a d la o s ta tn ie g o b a jtu ?

Aby wyliczyć maskę podsieci, trzeba dodać bity zamaskowane

27< -

128 X 1

64 X 1

32 X 1

16 X 1

8 X

4 X

2 X

1 X

128 + 64 + 32 + 16 = 240 4 b ity m a s k i = 240

4. Maska podsieci dla 14 podsieci wynosi zatem 240. Standardowa maska sieci kla­ sy C zmienia się tak, aby uwzględnić podsieci w obrębie ostatniego oktetu, wskutek czego nowa maska sieci i podsieci wynosi 255.255.255.240. Dostępnych jest teraz 14 podsieci, w każdej z których 4 bity są pozostawione dla hostów. Trzeba też określić dostępny zakres podsieci w obrębie maski 240. Sposoby są dwa. Jeden z nich polega na wypisaniu wszystkich możliwych kombinacji bitów przy­ dzielonych podsieciom: 1. Wypisz wszystkie możliwe kombinacje 4 bitów zarezerwowanych na adresy podsieci. 2. Dla każdej z nich dodaj do siebie wartości bitów ustawionych. Pamiętaj, żeby odrzucić kombinację złożoną z samych jedynek oraz złożoną z samych zer. 3. Powinieneś otrzymać wartości 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208 i 224. Tych 14 numerów reprezentuje adresy podsieci (por. rysunek 2.14). Rys u n e k 2 .1 4 .

Zakres podsieci. Same zera albo same jedynki są niedozwolone

J a k i je s t z a k re s p o d s ie c i? 240 128 64 32 16 X

X

X

X

-o— e— e—e—e 16

0

1

32

1

0

48

1

1

64

0

0

80

1

0

1

96

1

1

0

1

112

1

1

128

1

0

0

144

1

0

1

1 60

1

1

0

1 76

1

1 92

1

1

1

1

0

0

208

1

1

0

1

224

1

1

1

0

-2 4 0 -----1

H— 1— 1-

4

2

X X X

1

66

TCP/IP. SZKOŁA PROGRAMOWANIA

Drugi sposób polega na obliczaniu następującym: 1. Weź jako wartość bazową najniższą wartość w zamaskowanym obszarze (tutaj 16). Jest to pierwsza poprawna podsieć. Za pomocą tej wartości wyliczysz resztę podsieci. 2. Kolejno dodawaj do wartości bazowej właśnie tę wartość (oznaczającą teraz różnicę między każdym zakresem) tak długo, aż osiągniesz najwyższą wartość poniżej maski. Otrzymane liczby tworzą zakres podsieci. 3. Na przykład 16 + 16 = 32,32 + 16 = 48,48 + 16 = 64 itd. Teraz trzeba jeszcze wyliczyć liczbę hostów na podsieć, zależną od klasy sieci i liczby bitów pożyczonych dla podsieci. Ponieważ z ostatniego bajtu (8 bitów) pożyczyliśmy 4 bity, dla hostów zostały też tylko 4 bity. Obliczenia dla 4 bitów już robiliśmy — są one takie same, jak dla podsieci. Aby wyliczyć liczbę hostów na podsieć i zakres hostów: 1. Zacznij od najmniej znaczącego bitu i przechodź w lewo. Pomiń 4 bity pozosta­ wione dla hostów. Możesz też podnieść dwa do potęgi równej liczbie bitów po­ zostawionych dla hostów. 2. Spójrz na uzyskaną wartość (16). 3. Odejmij 2 i zobacz, ile hostów uzyskasz z pozostawionych bitów (16 - 2 = 14). 4. W celu uzyskania identyfikatorów hostów w każdej podsieci, dodaj 1 do wartości początkowej zakresu podsieci (16 + 1 = 17), a odejmij 2 od następnej wartości w tym zakresie (32 - 2 = 30). 5. Kontynuuj ten proces dla każdej wartości z zakresu podsieci, a uzyskasz poprawne numery hostów w każdej z nich. 6. Powinieneś otrzymać zakresy hostów 17 - 30, 33 - 46, 49 - 62, 65 - 78, 81 - 94, 97 - 110,113 - 126,129 - 142,145 - 158,161 - 174,177 - 190,193 - 206, 209 - 222 i 225 - 238 (por. rysunek 2.15). Rys u n ek 2 .1 5 .

P o p ra w n e a d r e s y h o s tó w i ro z g ła s z a n ia

Poprawne zakresy hostów

| 240' CO CM

64 32 16

8

4

2

1

X

X

X

X

X

X

X

X

- o — - e —- 6 - - e - -© -

Zakres h o s tó w

R ozgłaszanie

16

0

0

0

1

17

-

30

31

32

0

0

1

0

33

-

46

47

48

0

0

1

1

49

-

62

63

64

0

1

0

0

65

-

78

79

80

0

1

0

1

81

-

94

95

96

0

1

1

0

97

-

110

111

112

0

1

1

1

113

-

126

127

128

1

0

0

0

129

-

142

143

144

1

0

0

1

145

-

158

159

160

1

0

1

0

161

-

174

175

176

1

0

1

1

177

-

190

191

192

1

1

0

0

193

-

206

207

208

1

1

0

1

209

-

222

223

224

1

1

1

0

225

-

238

239

-240-—1— —4—H —- 4 -

Rozdział 2. ° ADRESOW ANIE IP

67

Jak już wiemy, typ klasy wpływa na liczbę możliwych do pożyczania bitów hostowych. Na szczęście procedura obliczeniowa się nie zmienia. Przyjrzyjmy się adresom kla­ sy B. Dla takiego adresu ze standardową 16-bitową maską 255.255.0.0 i dodatkowy­ mi 4 bitami pożyczonymi dla podsieci, dla hostów pozostaje dostępnych 12 bitów. Obliczenia dla 4 bitów już robiliśmy — w zależności od tego, do czego te bity służą, uzyskamy 14 podsieci lub hostów. Rozciągnięcie domyślnej maski klasy B na 4 dodatkowe bity (celem uwzględnienia podsieci) daje nową maskę 255.255.240.0. Korzystając ze schematu obliczeń IP (rysu­ nek 2.11) można wyliczyć, ile hostów na podsieć uzyskamy z 12 bitów pozostawio­ nych w obrębie trzeciego i czwartego bajtu. Po zasłonięciu 12 bitów od prawej, kolej­ na wartość wynosi 4096. Odejmując 2 (4096 - 2 = 4094) otrzymujemy liczbę hostów na podsieć (por. rysunek 2.16). Rys u n ek 2 .1 6 .

Sieć 130.100.0.0 klasy B została podzielona na podsieci przez „wymaskowanie” czterech bitów hostowych z trzeciego bajtu (maska 240)

12 b itó w d la h ostó w

MASKA

255

255

240 16

XXXXXXXX

.

XXXXXXXX

100

130

XX

X X XXXX

.

XXXXXXXX

X

V ID sieci K lasy B

4 B ity p odsieci

4 bity p o d sie cio w e = 14 p o d sie ci 12 b itó w h o sto w ych = 4 0 9 4 h osty na p o d s ie ć

Wcześniej nauczyliśmy się wyprowadzać zakres podsieci dla 4 bitów podsieciowych (co prawda dla klasy C, ale dla klasy B jest tak samo). Dla tej liczby bitów uzy­ skujemy następujący zakres podsieci (numery czy też adresy podsieci): 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208 i 224. Znając ten zakres, można określić poprawne identyfikatory hostów i adresy rozgłaszania w każdej podsieci. W tym miejscu zmieniamy metodę obliczeń — dla klasy C trzeba było się martwić tylko 8-oma bitami, teraz musimy się zająć aż 16-oma. Dla sieci klasy B (w przykładzie sieć 130.100.0.0 z maską 255.255.240.0), przekracza­ nie granicy 8-bitowej między trzecim a czwartym bajtem nieco komplikuje oblicza­ nie zakresów hostów. Najlepiej zabrać się do tego w systemie dwójkowym. Aby ob­ liczyć zakres hostów: 1. Weź adres pierwszej podsieci 130.100.16.0 (najniższy adres w obrębie maski) i przekształć go na dwójkowy. 2. Zacznij od najniższej możliwej wartości dla bitów hostowych. Uzyskasz w ten sposób pierwszy poprawny ID hosta w tej podsieci.

68

TCP/IP. SZKOŁA PROGRAMOWANIA

3. Określ najwyższą możliwą wartość (reprezentującą rozgłaszanie w tej podsieci). Dzięki temu łatwo cofniesz się do najwyższego poprawnego numeru hosta w zakresie (zawsze o jeden mniejszego od adresu rozgłaszania). 4. Przekraczając granicę oktetów, wartości z każdego oktetu dodawaj oddzielnie. Pamiętaj, żeby w każdym bajcie dodawać tylko bity ustawione. 3-ci bajt

4-ty bajt

4-bitowa maska 240 128 64 0

0

32 0

16

1

|

8

4

|

0

0

2 0

1 0

.

128 64

.

0

0

32 0

16 0

8 0

4 0

2 0

1 1

5. W celu określenia pierwszego poprawnego adresu hosta w podsieci 16, umieść zera na wszystkich pozycjach bitów hostowych oprócz skrajnej prawej, gdzie wpisz 1. Jest to najniższy możliwy numer hosta w tej podsieci. Pamiętaj, że część hostowa nie może zawierać samych zer (taki ID hosta jest niepoprawny). 6. Traktując każdy bajt oddzielnie, dodaj ustawione bity w każdym z nich. Trzeci bajt zawiera tylko jeden bit ustawiony, o wartości 16, więc wartość tego bajtu wynosi 16. 7. Czwarty bajt zawiera tylko jeden bit ustawiony, o wartości 1, więc wartość tego bajtu wynosi 1. Zatem pierwszy poprawny adres IP hosta w podsieci 130.100.16 wynosi 130.100.16.1 (por. rysunek 2.17). Ry s u n ek 2 .1 7 .

Obliczanie pierwszego poprawnego numeru hosta w każdej podsiec

Jaki je s t pierwszy poprawny host w każdej podsieci?

I 240 J Pod­ 128 64 32 16 sieci X X X X

4

2

8

4

2

1 . 128 64 32 16 8

X

X

X

X .

X

X

X

X

X X

X X

1

Pierwszy poprawny host

16

0

0

0

1

0

0

0

0 .

0

0

0

0

0

0

0

1

16.1

32

0

0

1

0

0

0

0

0 .

0

0

0

0

0

0

0

1

32.1

48

0

0

1

1

0

0

0

0 .

0

0

0

0

0

0

0

1

48.1

64

0

1

0

0

0

0

0

0 .

0

0

0

0

0

0

0

1

64.1 80.1

80

0

1

0

1

0

0

0

0 .

0

0

0

0

0

0

0

1

96

0

1

1

0

0

0

0

0 .

0

0

0

0

0

0

0

1

96.1

112

0

1

1

1

0

0

0

0 .

0

0

0

0

0

0

0

1

112.1

128

1

0

0

0

0

0

0

0 .

0

0

0

0

0

0

0

1

128.1

144

1

0

0

1

0

0

0

0 •

0

0

0

0

0

0

0

1

144.1

160

1

0

1

0

0

0

0

0 •

0

0

0

0

0

0

0

1

160.1

176

1

0

1

1

0

0

0

0 .

0

0

0

0

0

0

0

1

176.1

192

1

1

0

0

0

0

0

0 .

0

0

0

0

0

0

0

1

192.1

208

1

1

0

1

0

0

0

0 .

0

0

0

0

0

0

0

1

208.1

224

1

1

1

0

0

0

0

0 .

0

0

0

0

0

0

0

1

224.1

Przejdźmy teraz do drugiej skrajności i wyprowadźmy adres rozgłaszania. Ustaw­ my wszystkie 12 bitów hostowych w pozycji 1 i oddzielnie dodajmy bity ustawione z trzeciego i czwartego bajtu (por. rysunek 2.18).

Rozdział 2. « ADRESOW ANIE IP

Ry s u n e k

2.18.

69

Jaki jest adres rozgłaszania w każdej pods eci?

Adres rozgłaszania jest wskazywany przez same jedynki na bitach hostowych

I 240

I

Pod­ 128 64 32 16 sieci X X X X

8

4

2

1

X

X

X

X

128 64 32 16 X

8

4

2

1

X

X

X

X

X

X

X

Rozgłaszanie w podsieci

16

0

0

0

1

1

1

1

1

1

1

1

1

1

1

1

1

31.255

32

0

0

1

0

1

1

1

1

1

1

1

1

1

1

1

1

47.255

48

0

0

1

1

1

1

1

1

1

1

1

1

1

1

1

1

65.255

64

0

1

0

0

1

1

1

1

1

1

1

1

1

1

1

1

79.255

80

0

1

0

1

1

1

1

1

1

1

1

1

1

1

1

1

95.255

96

0

1

1

0

1

1

1

1

1

1

1

1

1

1

1

1

111.255 127.255

112

0

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

128

1

0

0

0

1

1

1

1

1

1

1

1

1

1

1

1

143.255

144

1

0

0

1

1

1

1

1

1

1

1

1

1

1

1

1

159.255

160

1

0

1

0

1

1

1

1

1

1

1

1

1

1

1

1

175.255

176

1

0

1

1

1

1

1

1

1

1

1

1

1

1

1

1

191.255

192

1

1

0

0

1

1

1

1

1

1

1

1

1

1

1

1

207.255

208

1

1

0

1

1

1

1

1

1

1

1

1

1

1

1

1

223.255

224

1

1

1

0

1

1

1

1

1

1

1

1

1

1

1

1

239.255

3-ci bajt

4-ty bajt

4-bitowa maska 240 128 64 0

0

32 0

16

|

1 1

8 1

4 1

2 1

1 1

. .

128 64 1

1

32 1

16 1

8 1

4 1

2 1

1

1

Po dodaniu wszystkich ustawionych bitów trzeciego (16 + 8 + 4 + 2 + l = 31), a potem czwartego bajtu (128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255) uzyskujemy adres rozgłaszania 130.100.31.255 w podsieci 130.100.16.0. Teraz można łatwo okre­ ślić największy możliwy ID hosta w tej podsieci, zawsze o jeden mniejszy od jej ad­ resu rozgłaszania. Robiąc to zwyczajnie (255 - 1 = 254) lub dwójkowo (przez za­ mianę skrajnego prawego bitu na 1 i dodanie wszystkich ustawionych bitów ostatniego bajtu) uzyskujemy ostatni poprawny numer hosta 130.100.31.254 w rozważanej podsieci (por. rysunek 2.19). 3-ci bajt

4-ty bajt

4-bitowa maska 240 128 64

32

16

|

4

0

0

1

I

1

0

2 1

1 1

. .

128 64 1

1

32 1

16 1

8 1

4 1

2 1

1 0

Łączenie w nadsieci, zbiorcze przedstawianie, skupianie, CIDR Branża sieciowa regularnie przerzuca się określeniami łączenie w nadsieci (supernetting), sumaryzacja tras (route summarization), agregacja tras (route aggregation) i bezklasowy routing międzydomenowy (CIDR, Classless Inter-Domain Routing) — tak, jakby to były całkiem różne technologie. Nie warto jednak ich odróżniać. W gruncie rze­ czy wszystkie te terminy opisują metodę zmniejszania ruchu uaktualniającego trasy i zmniejszania tabel routingu, polegające na scalaniu grupy sąsiadujących adresów IP w jeden reprezentatywny dla całej grupy.

70

TCP/IP. SZKOŁA PROGRAMOWANIA

Rys u n e k 2 .1 9 .

Jak widać, ostatni poprawny adres hosta w podsieci jest zawsze o 1 mniejszy od adresu rozgłaszania (wskazuje na to cyfra O na skrajnej prawej pozycji bitowej)

J a k i je s t o s ta tn i p o p r a w n y h o s t w k a ż d e j p o d s ie c i?

I 240

I

P od­ 128 64 32 16 s ie c i X X X X

8

4

2

1

X

X

X

X

8

4

2 1

X

X

X

X

X

X

128 64 32 16 X

X

O statni p o p ra w n y h o s t

16

0

0

0

1

1

1

1

1

1

1

1

1

1

1

1

0

31.254

32

0

0

1 0

1

1

1

1

1

1

1

1

1

1

1

0

47.254

48

0

0

1

1

1

1

1

1

1

1

1

1

1

1

1

0

65.254

64

0

1

0

0

1

1

1

1

1

1

1

1

1

1

1 0

79.254

80

0

1

0

1

1

1

1

1

1

1

1

1

1

1

1

0

95.254

96

0

1

1

0

1

1

1

1

1

1

1

1

1

1

1

0

111.254

112

0

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

127.254

128

1

0

0

0

1

1

1

1

1

1

1

1

1

1

1

0

143.254

144

1

0

0

1

1

1

1

1

1

1

1

1

1

1

1

0

159.254

160

1

0

1

1

1

1

1

1

1

1

1

1

1

0

175.254

176

1

0

1

1

1

1

1

1

1

1

1

1

1

0

191.254

192

1

1

1 0 1 1 0 0

1

1

1

1

1

1

1

1

1

1

1 0

207.254

208

1

1

0

1

1

1

1

1

1

1

1

1

1

1

1

0

223.254

224

1

1

1

0

1

1

1

1

1

1

1

1

1

1

1

0

239.254

Bez względu na przyjęty termin metoda ta pozwala routerom ogłaszać podzbiór tras, zmniejszając liczbę wysyłanych uaktualnień tras i rozmiar tabel routingu. Dalej będziemy posługiwać się nazwą sumaryzacja. Choć wyrażenie sumaryzacja może się brzmieć obco, w rzeczy samej istnieje ona w każdej sieci podłączonej do Internetu. Ponieważ sieć taka ma zarejestrowany adres IP, jej ISP lub cały ARIN przedstawiają zbiorczo tę sieć pozostałym użytkownikom Internetu. Dzięki schematowi adresowania klasowego A, B i C, roztropnie zdefiniowanemu przez ARIN, jeden adres przypisany firmie sumaryzuje całą jej sieć wraz ze wszyst­ kimi podsieciami zewnętrznymi. Oczywiście można by ogłaszać w Internecie wszystkie swoje podsieci, nie warto jednak tego robić z dwóch powodów: narażania bezpieczeństwa i braku konieczności. Aby dostać się do sieci firmy i jej podsieci, zewnętrznym routerom w Internecie wy­ starczy umiejętność dostania się do jej głównej sieci klasowej, jednoznacznie przy­ pisanej przez ARIN. Gdy ruch przeznaczony dla tej sieci osiągnie jej bramę ze­ wnętrzną, o resztę zadba właśnie ta brama i wewnętrzne bramy firmy. Ogłaszanie wszystkich tras pociągałoby za sobą dodatkowy ruch sieciowy związany z ich uak­ tualnianiem, a śledzenie wszelkich istniejących sieci i podsieci przez wszystkie ro­ utery internetowe obciążałoby dostępne zasoby. Z tego powodu tak ważna jest su­ maryzacja tras. Sumaryzację można też stosować wewnątrz infrastruktury routingu w firmie, zmniej­ szając w ten sposób ruch obsługujący uaktualnianie tras i rozmiary tabel routingu. Sumaryzację zazwyczaj przeprowadza się na routerach łączących z rdzeniem firmy, gdzie zatłoczenie łącza i szerokość pasma mają istotne znaczenie. Sumaryzując wiele adresów IP w postaci jednego adresu, a dopiero potem wysyłając tę informację na rdzeń, zmniejszamy ruch uaktualniający i zachowujemy cenną szerokość pasma.

Rozdział 2. ° ADRESOW ANIE IP

71

CIDR Nazwą „CIDR" branża jest skłonna określać sumaryzację, wykonywane na sąsia­ dujących adresach klasy C. Taki typ sumaryzacji jest stosowany na ogól przez firmy ISP lub innych dostawców usług, dysponujących grupą sąsiadujących adresów kla­ sy C, po kolei przydzielanych przez te firmy swoim klientom znajdującym się niżej w hierarchii Internetu.

ISP a dostawcy usług Określeniami ISP (Internet Service Provider) i dostawca ustug (service provider) na ogól można posługiwać się zamiennie. Tym niemniej ISP jest to dostawca usług internetowych (oferujący tylko i wyłącznie usługi internetowe), natomiast dostawca usług bezprzymiotnikowy może oferować zarówno usługi internetowe (być ISP), jak i usługi nieoferowane przez zw ykłych ISP (np. Frame Relay i połączenia W AN).

Dostawca zna adres klasy C reprezentujący sieć każdego klienta, więc może go ogłaszać w całym Internecie lub jakimś jego podzbiorze. Mógłby on jednak prze­ prowadzić sumaryzację szeregu tych adresów do postaci jednego, zmniejszając w ten sposób ilość informacji o trasach, przekazywaną innym bramom w Internecie. Sumaryzacja grupy adresów jest możliwa tylko dla adresów sąsiadujących ze sobą i tylko na granicy potęg 2-ki. Rozpatrzmy następujący przykład: mamy sieć 130.100.0.0 klasy B (maska domyślna 255.255.0.0) z wieloma podsieciami wewnętrznymi. Dla prostoty przyjrzyjmy się jedynie ich podzbiorowi: mamy x sąsiadujących adresów IP, które chcemy przedstawić zbiorczo zamiast ogłaszać je oddzielnie. W tym celu: 1. Przekształć rozważane adresy IP do postaci dwójkowej (por. tabelę 2.2). 2. Przechodź z lewa na prawo. 3. Szukaj najdłuższej zgodności bitów (wspólnego wzorca bitowego) we wszyst­ kich adresach. Reprezentuje on(-a) adres IP przedstawienia zbiorczego. Ponieważ wszystkie adresy zaczynają się od 130.100, w rzeczywistości nie trzeba przekształcać ich całych, a tylko zająć się trzecim bajtem. Z listy wartości dwójko­ wych dotyczących podsieci wynika, że dla nich wszystkich wspólne są 4 pierwsze bity (oprócz 16 bitów z pierwszego i drugiego bajtu). Wszystkie te podsieci można zatem zsumaryzować za pomocą jednego adresu IP o wartości 130.100.16.0 i 20-bitowej maski (16 bitów sieciowych plus 4 bity podsieciowe) o wartości 255.255.240.0 (ina­ czej /20).

72

TCP/IP. SZKOŁA PROGRAMOWANIA

TABELA 2.2. Zbiorcze przedstawianie tras Adres IP

130.100.16.0

Maska

255.255.255.0

Reprezentacja dwójkowa 128

64

32

16

8

4

2

1

0

0

0

1

0

0

0

0

0

0

1

130.100.17.0

2 55.255.255.0

0

0

0

1

0

130.100.18.0

2 55.255.255.0

0

0

0

1

0

0

1

0

130.100.19.0

255.255.255.0

0

0

0

1

0

0

1

1

130.100.20.0

255.255.255.0

0

0

0

1

0

1

0

0

130.100.21.0

2 5 5.255.255.0

0

0

0

1

0

1

0

1

130.100.22.0

255.255.255.0

0

0

0

1

0

1

1

0

130.100.23.0

255.255.255.0

0

0

0

1

0

1

1

1

0

0

0

255.255.255.0

0

0

0

1

1

130.100.25.0

255.255.255.0

0

0

0

1

1

0

0

1

130.100.26.0

255.255.255.0

0

0

0

1

1

0

1

0

130.100.27.0

255.255.255.0

0

0

0

1

1

0

1

1

130.100.28.0

255.255.255.0

0

0

0

1

1

1

0

0

130.100.29.0

255.255.255.0

0

0

0

1

1

1

0

1

130.100.30.0

255.255.255.0

0

0

0

1

1

1

1

0

130.100.31.0

255.255.255.0

0

0

0

1

1

1

1

1

130.100.24.0

Warto zapamiętać, że głównym celem sumaryzacji jest redukcja liczby uaktualnień tras. Jak można zauważyć, podzbiory tej grupy zawierają dalsze zgodności, jednak zsumaryzowane mogą być tylko te adresy, które dokładnie do siebie pasują, i tylko w oparciu o najdłuższy wzorzec. Podzbiór takich „dopasowań" można by zgrupo­ wać i oddzielnie zsumaryzować, ale taką grupę trzeba byłoby też oddzielnie ogła­ szać. Ponieważ wszystkie 16 wymienionych sieci ma 4 bity wspólne, sieci te można zgrupować i zsumaryzować za pomocą jednego adresu. Sumaryzacja podzbiorów byłaby mniej wydajna i niepotrzebna.

r m Ł _ J

- -----------------------------------------------------------------------

implementacja sumaryzacji tras

Do im plem entacji sumaryzacji tras w sieci konieczna jest konfiguracja routerów, której szczegóły zależą od ich dostawców, a ich omówienie wykracza poza zakres niniejszej książki.

Rozdział 2. ° ADRESOW ANIE IP

73

Tłumaczenie adresów sieciowych (NAT) Tłumaczenie adresów sieciowych (NAT) jest to proces tłumaczenia niezarejestrowanych (prywatnych) adresów IP (opisanych w tym rozdziale, tylko wcześniej) na je­ den zarejestrowany poprawny adres IP lub zakres takich adresów, służący(-ch) do komunikacji z hostami w Internecie. Pamiętamy, że zarejestrowane adresy IP, moż­ liwe do użytku w Internecie, przypisuje organizacjom rejestr ARIN. Sęk w tym, że zaprojektowany dawno temu schemat adresowania 32-bitowego nie spełnia dzisiej­ szych potrzeb obsługi milionów hostów internetowych. Aby rozwiązać problem kurczenia się liczby dostępnych adresów IP i wykładnicze­ go przyrostu liczby hostów w Internecie, konieczne są nowe pomysły dotyczące ad­ resowania. Branża sieciowa zaproponowała zwiększenie liczby bitów warstwy sie­ ciowej z 32 na 128 (czyli zmianę bieżącego schematu adresowania), udostępniające większą liczbę adresów. Dla takiego rozwiązania przyjęto następujące oznaczenia: O IPNG (NG oznacza Next Generation, czyli „następne pokolenie" — nazwa pochodzi chyba od jakichś fanów Star Treka z odległej galaktyki wirtualnej); D> IPv6 (v oznacza version, czyli wersję, w tym przypadku szóstą). Bieżąca wersja protokołu IP ma numer 4. Choć branża regularnie debatuje nad IPv6, opcja ta jest w dużej mierze pomijana ze względu na wymóg przerobienia schematów adresowych przez wszystkich uczestników Internetu. Do skutecznej implementacji tego rozwiązania konieczne byłyby też poprawki w bieżących proto­ kołach routingu itd. W międzyczasie pojawiły się inne rozwiązania, umożliwiające dalsze korzystanie z istniejącej struktury adresowej. Jednym z nich jest NAT. Usługę NAT musi włączyć i skonfigurować administrator na routerze (temat ten wykracza poza ramy niniejszej książki). Zasadniczo routery obsługujące NAT prze­ kształcają wewnętrzne adresy prywatne (np. lO.x.x.x) na zarejestrowane zewnętrz­ ne adresy IP, umożliwiając hostom z sieci prywatnych komunikację z hostami w Internecie. Istnieją trzy typy technologii NAT: >- Statyczna (rysunek 2.20); R ys u n e k 2 .2 0 .

Wzajemnie jednoznaczne odwzorowanie adresu wewnętrznego na zewnętrzny (statyczne)

O d w z o ro w a n ia s ta ty c z n e Tabela NAT W e w nę trzn y p ryw a tn y

Z e w n ę trz n y z a re je s tro w a n y

10.1.1.2

3 6 .1 .2 .3

10.1.1.3

3 6 .1 .2 .4

74

TCP/IP. SZKOŁA PROGRAMOWANIA

> Dynamiczna (rysunek 2.21); Ry s u n ek 2 .2 1 .

Odwzorowanie wielu adresów prywatnych na ten sam zarejestrowany adres zewnętrzny za pomocą różnych numerów portów (dynamiczne)

O d w z o ro w a n ia d y n a m ic z n e W e w n ę trzn y

Z e w n ę trz n y

P ort

pryw a tn y

z a re je s tro w a n y

klienta

1 0.1 .1 .2

3 6.1.2.3

1004

10.1.1.3

3 6.1.2.3

6 002

> Połączenie dwóch poprzednich typów.

Statyczne Jest to tłumaczenie wzajemnie jednoznaczne — każdy adres wewnętrzny jest odwzo­ rowywany na inny adres zewnętrzny. Administrator musi ręcznie tworzyć odwzo­ rowania statyczne na routerze tłumaczącym. Do takiego tłumaczenia potrzeba tyle adresów zewnętrznych, ile jest wewnętrznych, co powoduje raczej bezużyteczność tej technologii.

Dynamiczne Jest to tłumaczenie typu „wiele na jeden" lub „wiele na niewiele" — wiele adresów wewnętrznych jest odwzorowywanych na jeden adres zewnętrzny lub na ich małą pulę. Typowo administratorzy definiują małą pulę zarejestrowanych adresów, słu­ żącą do tłumaczenia dowolnego adresu wewnętrznego. Wskutek braku wzajemnej odpowiedniości adresów, administrator musi zaimplementować metodę jedno­ znacznej identyfikacji każdego hosta wewnętrznego. Cel ten może osiągnąć dołączając do adresu zewnętrznego numer portu warstwy transportowej hosta źródłowego. Jest to typ NAT najczęściej stosowany w branży. Dzięki niemu użytkowanie zarejestrowanych adresów jest najbardziej wydajne. Routery wykonujące NAT przechowują tabele, które śledzą odwzorowywane adresy. Gdy host wewnętrzny chce wysłać datagram do hosta zewnętrznego, wysyła go do bramy celem podania dalej. Router odwzorowuje adres wewnętrzny na zarejestro­ wany zewnętrzny za pomocą jednej z opisanych metod i podaje datagram dalej, zachowując to odwzorowanie w pamięci dla przyszłych potrzeb (por. rysunek 2.22).

Rozdział 2. ° ADRESOWANIE IP

75

R ysu n ek 2 .2 2 .

Router przechowuje w pamięci odwzorowanie adresów prywatnych na ten sam adres zewnętrzny

W e w n ę trzn y p ryw a tn y

Z e w n ę trz n y za re je s tro w a n y

p o rt

10.1.1.2

36.1 .2 .3

1004

10.1.1.3

36.1 .2 .3

6002

Gdy router odwzorował (zamapował) adres wewnętrzny na zewnętrzny, wykorzy­ stuje go w nagłówku IP datagramu wskazującym hosta źródłowego czyli wysyłają­ cego. Host docelowy nie wie, że adres hosta wysyłającego jest w istocie adresem przetłumaczonym, ani o to nie dba. Gdy host docelowy daje odpowiedź hostowi źródłowemu, router przemapowuje adres zewnętrzny na wewnętrzny i dostarcza odpowiedź do hosta wyjściowego. Ponieważ tłumaczenie jest przezroczyste (nie­ widoczne), pozwala skutecznie ukrywać hosty i infrastrukturę sieci wewnętrznej przed światem zewnętrznym, nadal umożliwiając im komunikację z tym światem.

P odsum ow anie System liczenia o podstawie 10, zwany dziesiętnym, wykorzystuje cyfry 0,1, 2, 3, 4, 5, 6, 7, 8 i 9. Komputery korzystają z systemu dwójkowego, czyli o podstawie 2. Przekształcanie liczb dwójkowych na dziesiętne pozwala zrozumieć te pierwsze. Warstwa sieciowa kontroluje routing: gdzie należy kierować ruch sieciowy. Decyzje te opierają się na 4-oktetowych (32-bitowych) adresach IP. Adres sieci reprezentuje sieć i podsieci firmy (jej sieć główną), zaś adres węzła — konkretne urządzenie w tej sieci. Istnieje pięć głównych klas adresów: A, B, C, D i E. Ogólnodostępne są tylko klasy A, B i C. Maski podsieci pomagają routerom i hostom trasować (routować) datagramy. Jeśli host docelowy znajduje się w tym samym segmencie lokalnym, host źródłowy mo­ że wysłać rozgłoszenie ARP służące do zamiany logicznego adresu IP warstwy sie­ ciowej na adres MAC. Jeśli jest oddalony, datagramy są kierowane do lokalnego ro­ utera bramowego.

76

TCP/IP. SZKOŁA PROGRAMOWANIA

Proces porównywania adresu IP hosta docelowego z maską podsieci hosta wysyła­ jącego polega na koniunkcji bitowej. Sumaryzacja pozwala routerom ogłaszać tylko podzbiory tras, zmniejszając rozmia­ ry tabel routingu i liczbę koniecznych uaktualnień tras.

Pytania sprawdzające 1. Jakie są klasy adresów IP i ich zakresy? 2. Do czego służą maski podsieci? 3. Jaka jest różnica między adresem sieci a adresem węzła? 4. Jakie adresy są zarezerwowane i do czego służą? 5. Ile bitów w adresie klasy C definiuje numer sieci? 6. Ile jest dostępnych podsieci, a ile hostów na podsieć, dla sieci o adresie 193.1.1.0 z maską podsieci 255.255.255.240? 7. Jaka powinna być maska podsieci dla podsieci 193.1.1.32 typu /28? 8. Jaka jest poprawna liczba podsieci i hostów dostępnych w sieci klasy B o masce podsieci 255.255.254.0? 9. He bitów trzeba byłoby pożyczyć w sied klasy C, jeśli potrzebnych jest 19 hostów? 10. Ile bitów trzeba byłoby pożyczyć w sied klasy B, jeśli potrzebnych jest 1000 hostów? 11. Jaki jest zapis dziesiętny liczby dwójkowej 10110111? 12. Jaki jest zapis dwójkowy maski podsieci 201?

m

PROTOKOŁY INTERNETOWE I WARSTWA SIECIOWA Przegląd treści rozdziału: ® Działanie, pola i funkcje protokołu IP o Fragmentacja 1ponowne składanie datagramów

o Komunikaty ICMP 1Ich znaczenie

Protokół IP Protokół internetowy (IP, Internet Protocol) wykonuje większość pracy pakietu pro­ tokołów TCP/IP. Wszystkie protokoły i aplikacje tego pakietu „przemieszczają" się protokołem IP, wykorzystując go do adresowania logicznego warstwy sieciowej i transmisji datagramów między hostami internetowymi. Protokół IP jest przypisany do warstwy sieciowej modelu DoD i warstwy sieciowej modelu OSI. Protokół komu­ nikatów sterujących Internetu (ICMP, Internet Control Message Protocol) jest uważany za integralną część IP i wykorzystuje go do dostarczania swoich datagramów. Protokół ICMP omówimy w dalszym ciągu rozdziału. Miejsce IP w modelach DoD i OSI zo­ stało pokazane na rysunku 3.1.

78

TCP/IP. SZKOŁA PROGRAMOWANIA

DOD

Ry s u n e k 3 .1 .

Protokół IP zapewnia wszystkim protokołom pakietu TCP/IP adresowanie logiczne i bezpołączeniowe dostarczanie datagramów

OSI aplikacji

aplikacji

prezentacji

w a r s t w

sesji transportowa transportowa sieciowa

IP, IC M P

sieciowa

y dostępu do sieci

tącza danych fizyczna

Jak można kupić bilet na pociąg IP? Wyrażenie „przemieszczają się protokołem" brzmi tak, jak gdyby aplikacja lub proto­ kół kupowały bilet na podróż pociągiem IP. Określenie to w istocie nie ogranicza się do protokołu IP. Jest to żargon branżowy opisujący schodzenie dowolnej aplika­ cji lub protokołu w arstw wyższych w dół modelu OSI i w ykorzystyw anie przez nią (niego) cech innego protokołu z w arstw y niższej (w tym przypadku protokołu IP w arstw y Sieciowej).

Protokół IP oferuje niepewne (zawodne), bezpołączeniowe dostarczanie datagramów, tzn. nie gwarantuje pomyślnego osiągania celu przez swoje datagramy. Zamiast tego stara się dostarczać je najlepiej jak potrafi, tzn. wysyła z nadzieją, że datagra­ my dotrą gdzie trzeba. Po prostu dołącza on logiczne adresy źródłowy i docelowy warstwy sieciowej, w dostarczaniu datagramów polegając na innych warstwach gwa­ rantujących ich dotarcie do celu. Gdy występuje problem z dostarczaniem, IP ko­ rzysta z protokołu ICMP wysyłającego odpowiednie komunikaty. Po natknięciu się na błąd protokół IP po prostu unicestwia datagram, powodując wysłanie do źródło­ wego hosta komunikatu ICMP, szczegółowo opisującego jakiego rodzaju problem wy­ stąpił z dostarczeniem. Niezawodność zapewniają natomiast protokoły warstw wyższych, np. TCP (por. rozdział 8). Podstawową funkcją protokołu IP jest adresowanie logiczne hostów i dostarczanie informacji w formie datagramów między nimi. Adresowanie IP omówiliśmy w roz­ dziale 2. Protokół ten spełnia też inne ważne funkcje, np. fragmentację i ponowne składanie datagramów, konieczne gdy są one zbyt duże do wysłania dla hosta do­ celowego i muszą zostać podzielone na mniejsze. Ponieważ IP jest protokołem bezpołączeniowym, nie wymaga połączeń między hostami. Nie określa następstwa, nie potwierdza i nie kontroluje przepływu danych między hostami. Traktuje wszystkie datagramy jak odrębne całości, jedynie adresując je i wysyłając w nadziei, że osią­ gną swoje przeznaczenie.

Rozdział 3 . ° PROTOKOŁY INTERNETOWE I W ARSTW A SIECIOWA

79

Protokół IP otrzymuje strumień danych od protokołu UDP lub TCP, dzieli te infor­ macje na fragmenty, adresując i umieszczając je w postaci datagramów wysyłanych następnie przez sieć do hosta docelowego. Wybór ścieżki między źródłem a celem określają routeiy i protokoły routingu (por. rozdziały 5 i 6).

RFC 7 9 1 Dokum ent RFC nr 791 definiuje protokół IP oraz jego pola I dostępne funkcje. W bieżącym rozdziale przyjrzymy się nagłówkowi IP i jego polom oraz zbadamy inne protokoły warstwy sieciowej. Routing (trasowanie) IP omówim y w rozdziałach 5 i 6.

Nagłówek IP Na rysunku 3.2 widać, zdefiniowany przez RFC 791, format datagramu IP. Nagłówek IP zawiera przynajmniej 20 bajtów, o ile nie korzysta się z opcjonalnych parametrów. Rysunek 3.3 pokazuje z kolei nagłówek IP, widziany przez analizator protokołów Sniffer. Na podstawie tych rysunków opiszemy każde pole. Rys u n ek 3 .2 .

Nagłówek protokołu IP zapewnia identyfikację logicznych adresów sieciowych źródła i celu

Rys u n ek 3 .3 .

Wartość Ethertype zawarta w nagłówku sterowania łączem danych (DLC, Data Link Control) dowodzi, że ramka przenosi protokół typu 0x0800 czyli IP

C';\Snillci Pio - Local/DialUp Adaptei_l - [Snifl : 1/1 Ethernet frames) £H P i Mcri-'ci Capiuie Dirpby J o d i Window Help

tglHl afel alSBtolatlaiiiaigi gy .¿Toil 0 VP DLC: DLCHeader — — ! I Q DLC: y DIC: Frane 1 arrived at 11:24:25 07B2. frame size is 60 (003C hex) bytes. Q DLC: Destination = Station DECnetl0742D ,1.1 DLC. Source “ Station cisco007727 JJ DLC Ethertype = 0800 (IP) D DLC b T I P IP Header ----;O ip. Cl TP. Version = 4. header length ■ 20 bytes Q IP Type of service = 00 Q IP 000. . .. = routine :Q IP ...0 .... ■ nornal delay Q IP .. 0 . = nornal throughput y IP: .. . 0 .. = nornal reliability Cl IP: Total length * 40 bytes Q l P . Identification - 25276 Q IP: Flags = OX Q ip 0 ....... =* nay fragment ¿15 IP ..0..... ■ last fragnent Q IP. Fragnent offset = 0 bytes y IP Tine to live = 59 secondsZhops Q IP- Protocol = 6 (TCP) Ij IP: Header checksun = D344 (correct) y IP: Source address = [36 56.0.152] y IP: Destination address = [36.53.0.203] y IP Ho options

UIP

v Decode / 1/MrU A Holt Tatti A Prctocd Diit. A Statdci / For Hdp. piet» FI

££

I

.li. |

vj I

I

80

TCP/IP. SZKOŁA PROGRAMOWANIA

Spójrzmy na nagłówek IP z rysunku 3.3. Pierwsze pole zawiera numer Wersji (Version), który zawsze powinien wynosić 4 (oficjalna norma). Po nim następuje pole Długości nagłówka IP (IHL, Internet Header Length), wynoszącej 20 bajtów. Wartość pola Typ Usługi (ToS, Type of Service) w tym przypadku (i najczęściej) wynosi 0 (ToS jest rzadko używany). Tym niemniej coraz lepsza znajomość tej funkcji i rosnąca liczba z powo­ dzeniem stosujących ją w swoich produktach dostawców powoduje zmianę trendu. Pojawiają się aplikacje zdolne do ustawiania tych bitów tak, aby wpływać na routing datagramów przez routery. Dzięki temu mogą one wymagać od routerów konkret­ nego poziomu ToS dla przesyłanych danych. Długość całkowita (Total Length) datagramu wynosi 40 bajtów, co obejmuje nagłó­ wek IP i dane przenoszone w ramce. Wartość numeru identyfikacyjnego (ID, Identifi­ cation) dla tego datagramu wynosi 25 276. Pole Flagi (Flags) określa możliwość fragmentacji datagramu i czy jest to ostatni fragment. Ponieważ przesunięcie fragmentu (Fragment Offset) ma wartość 0, możemy domyślić się, że jest to pierwszy, ostatni i jedyny fragment w obrębie strumienia. Wartość TTL (Time To Live — Czas życia) aktualnie wynosi 59 sekund. Jest to ilość czasu pozostawiona datagramowi na przeżycie w intersieci. Protokół (Protocol) przenoszony w ramce to TCP. Suma kontrolna nagłówka (Header Checksum) służy do identyfikowania ramek zniszczonych. Adres źródłowy (Source Address), czyli adres IP hosta wysyłającego wynosi 36.56.0.152, natomiast adres docelowy (Destination Ad­ dress), a więc adres IP hosta odbierającego ma wartość 36.53.0.203.

Wersja Wartość 4-bitowego pola wersji identyfikuje wersję zaimplementowanego proto­ kołu IP. Powinna ona wynosić 4 (najbardziej aktualna i popularna wersja IP).

Długość nagłówka IP 4-bitowe pole długości nagłówka określa rozmiar nagłówka IP w słowach 32-bitowych. Wszystkie nagłówki IP muszą mieć przynajmniej 20 bajtów długości, o ile nie są wykorzystywane opcje (por. niżej).

Typ Usługi (ToS) 8 bitów pola ToS może wpływać na ścieżkę przekazywania datagramów przez ro­ utery ze źródła do celu. Bity te umożliwiają wyższym aplikacjom i procesom wska­ zywanie typu lub jakości usługi spodziewanej od routera. Do niedawna z bitów ToS nie korzystano. Obecnie natomiast wiele firm stosuje je, aby umożliwić bardziej inteligentny wybór ścieżek. Gdy nie zaimplementowano ToS, pole to ma wartość 0 (spodziewaną ze względu na nietypowość stosowania tej technologii). Opis specy­ ficznych zastosowań i funkcji tych bitów znajduje się w dokumentach RFC nr 1340 i 1349, a krótkie wyjaśnienie poniżej.

Rozdział 3 . ° PROTOKOŁY INTERNETOWE I W ARSTW A SIECIOWA

81

Bity 0 -2 : priorytet Bity te, stosowane w wymienionych niżej kombinacjach, oznaczają różne rzeczy. Na ogół wykorzystuje je tylko rząd, definiując ważność datagramów. Dalszy opis żądanego typu priorytetu zapewnia pole opcji nagłówka IP (por. dalej). Wartość priorytetu przeważnie opisuje typ wymaganego poziomu zabezpieczeń, zdefinio­ wany przez Agencję Wywiadu Obronnego (Defence Intelligence Agency). Ustawienia bitów priorytetu zawiera tabela 3.1. TABELA 3.1. Bity 0 - 2 = priorytet U s ta w ie n ie b itó w

O pis

000

In fo rm a cje rutyn o w e

001

In fo rm a cje p rio ryte to w e

010

D ostarczenie n a ty c h m ia s to w e

011

Flesz (przełączenie)

100

O bejście flesza (prze łą cze n ia )

101

In fo rm a cje o zn aczeniu krytycznym

110

S te ro w a n ie in te rs ie c ią (sie cią połączoną)

1 11

S te ro w a n ie sie cią

Do niedawna większość aplikacji nie obsługiwała, ani nie korzystała z bitów prio­ rytetu. Bity te mają jednak sens w sieciach rządowych, wymagających wielopozio­ mowych funkcji zabezpieczeń. Nie będziemy dalej omawiać bitów priorytetu, na­ tomiast sam priorytet jest bardziej dokładnie opisany w rozdziale 8. Organizacja, która chce korzystać z priorytetu, musi specjalnie zdefiniować te bity oraz ich wy­ korzystanie i znaczenie. Następne trzy bity ToS najczęściej służą do wpływania na wzorce ruchu sieciowego. Bit 3: opóźnienie Bit ten może mieć dwie wartości: i> 0 = opóźnienie normalne; > 1 = opóźnienie niskie. Rzecz dotyczy opóźnienia propagacji danych przesyłanych łączem między dwoma końcami. Gdy istnieje wiele ścieżek do celu, po drodze aplikacja może skłaniać ro­ utery do wybierania ścieżek o najmniejszym opóźnieniu (tj. najszybszej). Bit 4: przepustow ość Bit ten może przyjmować dwie wartości: > 0 = przepustowość normalna; > 1 = przepustowość wysoka.

82

TCP/IP. SZKOŁA PROGRAMOWANIA

Gdy aplikacja potrzebuje ścieżki do celu oferującej wysoki wskaźnik przepustowo­ ści, ustawia ten bit na 1. Routery będą przekazywać ruch ścieżkami obsługującymi najwyższą możliwą szybkość transmisji danych, mierzoną jako szerokość pasma dla łącza między źródłem a celem. Bit 5 : niezawodność Bit ten może mieć dwie wartości: > 0 = niezawodność normalna; > 1 = niezawodność wysoka. Routery mierzą niezawodność łącza na podstawie liczby napotykanych błędów i traconych datagramów podczas przekazywania lub odbierania danych za pośred­ nictwem określonego interfejsu. Jeśli istnieje wiele ścieżek, a jedna okazuje się bardziej niezawodna od innych, router będzie przekazywał tym interfejsem ruch genero­ wany przez aplikacje ustawiające bit 5 na 1. Tego typu obsługi mogą żądać aplikacje o znaczeniu krytycznym, nie tolerujące utraty danych. Bity 6 i 7 (zarezerwowane) Bity 6 i 7 są zarezerwowane i obecnie niewykorzystywane. Aplikacje i procesy warstw wyższych mogą żądać od routerów dostarczania danych ścieżkami spełniającymi ich wymagania odnośnie usługi. Jeśli tego rodzaju dostar­ czanie ma działać, wszystkie routery i protokoły routingu na ścieżce od źródła do celu muszą znać zasady przekazywania datagramów w oparciu o wartość pola ToS, a konfiguracja tych protokołów i routerów musi im umożliwiać takie działanie. Nie wszystkie protokoły routingu obsługują te bity. Do tych, które interpretują prawi­ dłowo ToS należą: > OSPF, > EIGRP, > IGRP, > BGP. Następujące protokoły nie obsługują bitów ToS: > R IP w .l; > RIPw.2. Protokół routingu, zdolny do interpretacji i obsługi tych bitów, wymaga skonfigu­ rowania. Nieskonfigurowany odpowiednio router po prostu zignoruje te informacje, przekazując datagram tylko najlepiej jak potrafi. Rozpatrzmy następujący przykład. Gdy aplikacja żąda wysyłania datagramów ścieżką o niskim opóźnieniu, ustawia war­ tość bitu 3 na 1. Routery wzdłuż ścieżki próbują wysyłać datagramy łączami oferują­

Rozdział 3 . • PROTOKOŁY INTERNETOWE I W ARSTW A SIECIOWA

83

cymi szybszą transmisję, np. przez 100 Mb Ethernet zamiast wolniejszy WAN. Pa­ miętajmy, że opóźnienie dotyczy propagacji tam i z powrotem (round-trip) na łączu, zatem preferowaną ścieżką będzie łącze o niższym opóźnieniu. Wysoka przepustowość przekłada się na łącza o wysokiej pojemności, zdolne do przenoszenia większych ilości danych w krótszym czasie (a więc przydatne do przesyłu dużych plików). Routery mierzą pojemność łącza w kategoriach szeroko­ ści pasma, tzn. szybkości przesyłu w bitach za pośrednictwem danego interfejsu. Na przykład 100 Mb Ethernet przenosi około 100 milionów bitów na sekundę, czyli szybciej niż interfejs 10 Mb/s (ok. 10 min bitów na sek.). Jeśli celem jest niezawod­ ność (np. dla aplikacji wykonującej procesy o znaczeniu krytycznym lub wyma­ gającej bezpieczeństwa), ustawiając bit 5 na 1 aplikacja może żądać bardziej niezawod­ nej śdeżki transmisji. Rzecz może dotyczyć aplikacji przetwarzania transakcyjnego, wymagającej dostępu do odpornej na uszkodzenia sieci szkieletowej firmy. Warto pamiętać, że ustawiając bity ToS zmieniamy sposób kierowania ruchem sie­ ciowym przez routery. Bez dogłębnej znajomości typów protokołów, aplikacji, przepływów ruchu i czasomierzy protokołów w danej sieci, manipulacja tymi bita­ mi może przynieść katastrofalne skutki. Przed wykorzystaniem pola ToS obowiąz­ kowo trzeba zmierzyć wszystkie parametry własnej sieci. Stosowane właściwie, pole to z kolei może radykalnie zwiększyć wydajność sieci i aplikacji sieciowych.

Długość całkowita Pole 2-bajtowe, definiujące długość w bajtach całego datagramu IP. Wartość ta uw­ zględnia nagłówek IP i dane przenoszone w datagramie.

Numer identyfikacyjny (ID) Pole 2-bajtowe, zawierające wartość przypisywaną przed wysłaniem każdemu datagramowi IP przez nadawcę. Jednoznacznie identyfikuje ona pojedynczy datagram lub cały ich strumień. Host docelowy wykorzystuje ją do ponownego składania odbieranych datagramów. Gdy proces IP hosta źródłowego otrzymuje od proto­ kołu UDP lub TCP duży strumień zwartych danych celem zapakowania ich w datagramy, a otrzymany pakiet jest zbyt duży dla nośnika transmisyjnego, proces ten dzieli strumień (ma miejsce fragmentacja). Następnie protokół IP przypisuje ten sam numer ID wszystkim datagramom należącym do jednego strumienia. Datagramy przesyłane ze źródła do celu mogą obierać różne ścieżki o znacznie róż­ niących się charakterystykach, więc mogą przybywać na miejsce nie po kolei. Host docelowy w oparciu o wartość ID stwierdza, że wszystkie należą do jednego strumie­ nia, a następnie składa je ponownie w oparciu o wartość przesunięcia fragmentu (por. niżej).

84

TCP/IP. SZKOŁA PROGRAMOWANIA

Flagi Bit 0 jest zarezerwowany i musi mieć wartość 0. Bit 1 może mieć następujące wartości: £> 0 = można fragmentować (May Fragment); > 1 = nie fragmentować (Don't Fragment). 3-bitowe pole flag jest wykorzystywane przez hosty i bramy do celów fragmentacji. Host lub brama obsługujący (-a) fragmentację może przed transmisją podzielić strumień danych na mniejsze kawałki. Jeśli nie obsługuje fragmentacji (ustawiony jest bit „nie fragmentować"), nie będzie możliwy podział strumienia. Za fragmenta­ cję odpowiada na ogól host wysyłający. Host docelowy ponownie składa datagramy w pierwotny strumień, a następnie przekazuje go do przetworzenia warstwie wyższej (protokołowi TCP lub UDP). Jednak nie zawsze tak się dzieje. Gdy host źródłowy wysyła na segment datagram zbyt duży, by możliwe było jego dalsze przekazanie, brama dokonuje fragmentacji, dzieląc go na mniejsze jednostki o wielkości akceptowanej przez nośnik. Nie warto jednak nakazywać bramom po­ średniczącym fragmentacji datagramów podczas ich tranzytu. Routery zmuszane do wykonywania tej funkcji wymagają dodatkowych zasobów, dostarczając datagramy z większym wysiłkiem i opóźnieniem. Ponieważ różne bazowe architektury sieciowe obsługują różne rozmiary ramek, należy zbadać najmniejszy dopuszczalny rozmiar maksymalnej jednostki transmisji (MTU, Maximum Transmission Unit) w całej sieci, po czym skonfigurować jego obsługę przez hosty i routery. Na przykład mak­ symalny rozmiar ramki dla sieci Ethernet wynosi 1518 bajtów, a dla sieci TokenRing od 4500 do 17800 bajtów. Bit DF (Don't Fragment) ma jeszcze inne zastosowanie. Niektóre implementacje wykorzystują go do dynamicznego odkrywania rozmiaru MTU na całej długości sieci. Ustawienie tego bitu na routerze pośredniczącym spowoduje, że nie będzie on przekazywał ramek większych niż dopuszczalne w następnym odcinku na ścieżce transmisji. Bedzie on porzucał takie ramki, odsyłając do hosta źródłowego komunikat ICMP wskazujący na przekroczenie maksymalnego rozmiaru ramki. W oparciu o tę informację host wysyłający będzie mógł zmienić rozmiar kolejnego datagramu. Proces ten będzie postępował tak długo, aż host źródłowy odkryje rozmiar właściwy do wysyłania, umożliwiający routerom pośredniczącym przeka­ zywanie datagramów bez ich fragmentowania po drodze do celu. Bit 2 może przyjmować następujące wartości: > 0 = ostatni fragment (Last Fragment); > 1 = więcej fragmentów (More Fragments). Wskazują one na to, że dany datagram jest ostatni w strumieniu albo że po nim ma nastąpić ich więcej. Gdy datagram jest tylko jeden, bit ten ma wartość zero, oznaczając

Rozdział 3. « PROTOKOŁY INTERNETOWE I W ARSTW A SIECIOWA

85

pierwszy i zarazem ostatni datagram w strumieniu. Odbierając datagram host doce­ lowy notuje jego wartość ID i sprawdza omawiany bit. Jeśli spodziewanych jest więcej fragmentów (2-gi bit flagi = 1), przechowuje ten datagram w pamięci aż przy­ będą pozostałe z tym samym identyfikatorem, po czym składa je ponownie i przeka­ zuje strumień do przetworzenia odpowiedniemu protokołowi warstwy wyższej. Dopasowując wartości ID i odwołując się do ostatniego bitu flagi host poznaje, kiedy nie może się już spodziewać nowych datagramów w strumieniu i powinien zacząć ponownie je składać.

Przesunięcie fragmentu Za pomocą tej 13-bitowej wartości host wysyłający określa miejsce datagramu w strumieniu (właściwą kolejność datagramu, gdy więcej niż jeden ma ten sam numer identyfikacyjny). Pierwszemu datagramowi zawsze przypisuje offset zero­ wy, kolejnym — oparty na rozmiarze MTU. Odbiorca za pomocą wartości przesu­ nięcia z powrotem łączy odebrany strumień datagramów w całość, bądź wykrywa brakujące datagramy. Na przykład jeśli host źródłowy ma wysłać trzy datagramy należące do jednego strumienia, postępuje następująco: 1. Przypisuje każdemu z trzech datagramów ten sam ID. 2. W pierwszych dwóch datagramach ustawia bit „więcej fragmentów", wskazujący na to, że nie są one jedynymi datagramami w strumieniu (po nich mają nastąpić inne). 3. W trzecim i ostatnim datagramie ustawia bit „ostatni fragment". 4. Każdemu datagramowi przypisuje wartość przesunięcia, identyfikującą jego kolejność w strumieniu. Na rysunku 3.4 widać przykład hostów wysyłającego i odbierającego, które w oparciu o przesunięcie fragmentów określają kolejność datagramów. Stacja A chce nawiązać łączność ze stacją B, wysyłając na przewód pojedynczy datagram z 1500 bajtami informacji. Rozmiar MTU dla odcinka lokalnego, do którego jest przyłączona ta sta­ cja, wynosi 1518 bajtów (a więc wystarczająca). Datagram ten dociera do routera 1, który przekazuje go bez zmian do routera 2 (odcinek między routerami 1 i 2 ma tę samą MTU). Odcinek sieci WAN między routerami 2 i 3 nie przyjmuje datagramów większych niż 512 bajtów, zatem router 2 musi podzielić otrzymany datagram tak, aby zmieścił się na przewodzie (jest to właśnie fragmentacja). W efekcie do routera 3 i w końcu do samego hosta B trafiają aż trzy datagramy. Host ten ponownie je składa, a potem wysyła całość procesowi warstwy wyższej. Do ich złożenia wykorzystuje pola: numer identyfikacyjny, flagi (bit 2) i przesunięcie fragmentu.

86

TCP/IP. SZKOŁA PROGRAMOWANIA

Ry su n e k 3 .4 .

Host A wysyła 1500-bajtowy datagram, zbyt duży dla sieci WAN. Router 2 (R2) dzieli datagram (fragmentuje) na mniejsze fragmenty i przekazuje je dalej. Za ich ponowne złożenie odpowiada host docelowy

Fragmentacja i ponowne składanie

M TU=1518 bajtów

M TU=1518 bajtów

r R2 [l0 2 4

-j|nm m iM || R1

!

[ s i a l

MTU sieci L W AN=512 t

0

|

A M ■IIpgs

^J5QĆTj

W omawianym przykładzie host odbierający przeprowadza ponowne składanie datagramów w oparciu o następujące informacje: 1. Pieiwszy datagram w strumieniu ma wartość offsetu zawsze równą 0. 2. Drugi datagram ma wartość przesunięcia równą 512. 3. Trzeci datagram ma wartość przesunięcia wynoszącą 1024. Odbiorca, czekając na przybycie datagramów strumienia, przechowuje je w swoim buforze pamięci. Nie zawsze jednak otrzymuje datagramy we właściwej kolejności. Jeśli na przykład jako pierwszy przybył datagram drugi (z offsetem 512), odbiorca spodziewa się także innych z następujących powodów: l> W data gramie tym jest ustawiony bit „więcej fragmentów". t> Nie jest w nim ustawiony bit „ostatni fragment". > Nie dostał datagramu z tym samym identyfikatorem, ale z przesunięciem 0 (oznaczającym początek strumienia). Z tych trzech względów odbiorca spodziewa się przybycia zarówno datagramów wcześniejszych, jak i późniejszych (według kolejności w strumieniu). Po uzyskaniu wszystkich fragmentów strumienia, może je złożyć po kolei i przekazać wyżej do przetworzenia. Na rysunkach 3.5, 3.6 i 3.7 zobrazowano inny przykład fragmentacji i ponownego składania, pokazany za pomocą aplikacji Sniffer. Rysunek 3.5 zawiera szczegóły pierwszego, rysunek 3.6 szczegóły drugiego, a rysunek 3.7 -— ostatniego datagramu strumienia. Jak widać na rysunku 3.5, wartość ID dla ramki 1 (podświetlonej w okienku

Rozdziat 3. » PROTOKOŁY INTERNETOWE I W ARSTWA SIECIOWA

87

szczegółów) i pozostałych ramek 2 - 5 (pokazywanych w okienku podsumowa­ nia) wynosi tyle samo, czyli 2052 („Identification = 2052" na dole, „continuation of ident = 2052" u góry). Oznacza to, że wszystkie ramki 1 - 5 należą do jednego strumienia o numerze 2052. Ry s u n e k 3 .5 .

d-|g|xj EH Füe Monitor gaplure Display Tools Window Help

Flaga „więcej c?lB| algi aliatoltelalial-ot p.\ ol o! ¡Sialu:15olicsAddress IPestAddress iLayer |Surrrm ary fragmentów” oznacza, N [ 1 2 8 .1 6 9 2 0 1 .2 5 ] RFC [ 1 2 8 .1 6 9 2 0 0 ,4 0 ] R XID=91024 Fl [1 2 6 .1 6 9 2 0 0 .4 0 ] [1 2 6 169 2 0 1 .2 5 ] IP ¡c o n tin u a tio n r: [1 2 8 169 2 0 0 . 10] [1 2 8 169 201 25] IP ¡c o n tin u a tio n n że w strumieniu jest [1 2 8 1 6 9 .2 0 0 .4 0 ] r4 [1 2 8 .1 6 9 201 25] IP c o n tin u a tio n [1 2 8 .1 6 9 2 0 0 .4 0 ] ¡c o n tin u a tio n ns [1 2 8 169 2 0 1 .2 5 ] IP więcej niż jeden I ÉT IP: - ■ IP H eader datagram. . QIP: a IP: V e rsio n = 4 . i cheead er le n g th 20 b y te s Przesunięcie ; a IP: Type ofD00s e.r v.... = r o u tin e a IP: fragmentu równe zero ...0 .... = norm al d e la y ! a IP: = norm al throughput l à IP : oznacza, że jest to al r e l i a b i l i t y a IP: T o ta l le n g th == norm 1500 b y te s \ a IP : pierwszy datagram . a ip - FI dlaegnst i f i c a t i o i == 2052 2X ! a IP IP:: = may fragm ent tego strumienia IP : = more frag m en ts

of of of of

i d e n t=2052 id e n t= 2 0 5 2 id e n t= 2052 i d e n t=2052

B

ent o f f s e t ■ 0 b y te s Q IP: Fragm = 255 seco n d s/h o p s Time t o l i ’ I-Q a IP o to c o l = 17 (ÜDP) IP:: PHreader = FB77 ( c o r r e c t ) ¡ a IP: S o u rc e checksum a d d re s s = [1 2 8 1 6 9 .2 0 0 .4 0 ] a ip D e s tin a tio n a d d re s s = [ 1 2 B . 1 6 9 .2 0 1 . 2 5 ] ip: Ho IP: o p tio n s 1aa IP IP:: Multi-Frame IPdata. Frames. 1 . 2 . 3. D é c o d a A M altuAH ostToiiaAProtocolDel.A£1 For He'p, press F1

e

aasim tjl I H S

Rysu n ek 3 .6 .

Przesunięcie fragmentu stuży hostowi odbierającemu do ponownego składania datagramów

4. 5 j

[~

ftl E j >3 II OWeiTieel ^3l,Flg...| Q-|Eq 2 = odpowiedź BOOTP (wysyłana przez serwery).

Rozdział 4. » ZAM IAN A ADRESÓW

Rys u n e k 4 .1 2 .

Op

Nagłówek BOOTP zawiera 300 bajtów. Protokoły BOOTP i DHCP mają ten sam format nagłówka

H type

123

Skoki

H ien

ID tra n sa kcji N ie u żyw a n e

S e ku nd y A d re s IP klienta Tw ój adres IP A d re s IP serw era A d re s IP bram y

A d re s s p rzę to w y klie n ta (16 o k te tó w )

N azw a h osto w a se rw e ra (64 o k te ty)

N azw a p liku ro zru ch o w e g o (128 o kte tó w )

O b sza r s p e cyfic z n y dla d o sta w cy (64 okte ty)

Ry s u n ek 4 .1 3 .

Przykładowy nagłówek BOOTP

P o le o p

P o le s e k u n d y

P o le n ie u ż y w a n e

Snillei Pm ■Locol/Dial Up Adaplci_1 - [Ś nili : 1/1 Elheinel liâmes] J 2 Eüö H w ä a

kiptutó Q.kptay Xoob Üfmdow H&fp

c?lH l a l - J l ¡ 5 la lQ lla i'lä la ü |w | tí¡ ä j jO || Np

n Uaktualnienia wyzwalane — routery od razu powiadamiają o zmianach, nie czekając na okresowe czasomierze. > Routing bezklasowy — protokół OSPF obsługuje VLSM-y. I> ToS lub QoS — routery OSPF potrafią przekazywać datagramy do celu w oparciu 0 poziom usługi wymagany przez aplikację. > Uwierzytelnianie — routery mogą korzystać z ochrony hasłami, umożliwiającej im wymianę informacji tylko z upoważnionymi routerami. > Trasy o kosztach równych i nierównych — routery mogą przekazywać data­ gramy do celu za pośrednictwem nadmiarowych ścieżek o kosztach równych 1 nierównych, równoważąc w ten sposób obciążenie łączy ruchem sieciowym.

Rozdział 6. • PROTOKOŁY ROUTINGU

171

> Obszary — protokół OSPF można stosować w jednym lub wielu obszarach. Podział systemu autonomicznego na obszary zmniejsza ilość ruchu uaktualniającego. (Bazę danych stanu łączy i obliczanie SPF omówimy w dalszym ciągu rozdziału). Protokół OSPF, włączając maski podsieci do uaktualnień, obsługuje VLSM-y. Ro­ utery OSPF ogłaszają nie tylko docelową sieć lub hosta, ale także maskę podsieci, umożliwiając odbiorcy identyfikację sieci podzielonych na podsieci. OSPF obsługuje wskaźnik ToS protokołu IP, rozpoznając bity ustawione w na­ główku IP, umożliwiające routerom przekazywanie datagramów do celu w oparciu o poziom lub klasę usługi, wymagany(-ą) przez daną aplikację. Obsługa ToS jest różna dla różnych dostawców. Wybierając najlepszą ścieżkę, protokół OSPF polega przede wszystkim na następujących metrykach złożonych: > szerokości pasma, l> opóźnieniu, > niezawodności, > obciążeniu, > MTU. Routery OSPF na ogół posługują się tylko jedną z nich: szerokością pasma. Korzy­ stanie z pozostałych wymaga specjalnej konfiguracji. Dowolną z wartości metiyk można modyfikować w celu określenia parametru kosztu, w oparciu o który router określa najlepszą ścieżkę — im niższy koszt, tym lepsza trasa. Administratorzy mo­ gą konfigurować różne wartości kosztu na różnych interfejsach routera. Jeśli do celu prowadzi wiele ścieżek o różnych metrykach, ścieżki o najniższym koszcie są umieszczane w tabeli routingu jako trasy preferowane. Jeśli protokół IP wykorzy­ stuje ToS, i istnieją nadmiarowe ścieżki oferujące różne typy usług,routery umiesz­ czają w tabeli routingu po jednej trasie dla każdego z nich. Jeśli istnieje wiele ścieżek o tym samym koszcie, routery mogą przekazywać nimi datagramy jednocześnie (określa się to jako równoważenie obciążenia).

Bazy danych OSPF Wszystkie routery OSPF tworzą i przechowują trzy oddzielne bazy danych: > bazę danych przylegania (tj. tabelę sąsiadów); > bazę danych stanu łączy (tj. mapę topologii); > bazę danych przekazywania (tj. tabelę routingu).

Bazy danych przylegania Aby router OSPF mógł wymieniać i poznawać trasy, najpierw musi stworzyć relacje przylegania (adjacency) z sąsiadami bezpośrednio podłączonymi do segmentu lo­ kalnego. Jeśli tego nie zrobi, nie będzie mógł uczestniczyć w routingu OSPF.

17 2

TCP/IP. SZKOŁA PROGRAMOWANIA

Włączany po raz pierwszy router OSPF następująco tworzy relacje przylegania: 1. Wysyła na lokalny przewód pakiet Hello, w którym przedstawia się sąsiadom. 2. Odbierające routery OSPF dodają do swoich baz danych przylegania nowy router i odpowiadają swoimi pakietami Hello, w których się przedstawiają. Wszyscy sąsiedzi powinni znać się nawzajem i teoretycznie posiadać ukształtowane stosunki międzysąsiedzkie. Jest to jednak wizja bardzo uproszczona, zakładająca, że wszystkie wymagane parametry z pakietu Hello pasują do siebie i zgadzają się na nie sąsiedzi. Gdy tak nie jest, nie jest możliwe stworzenie relacji przylegania. Pa­ kiet Hello i pozostałe typy pakietów omówimy w dalszym ciągu tego rozdziału.

Bazy danych stanu łączy Gdy router OSPF już wie, z którymi routerami ma wymieniać informacje, może utworzyć bazę danych stanu łączy, czyli kompletną mapę topologii sieciowej obsza­ ru OSPF, identyfikującą każdą sieć i podsieć oraz prowadzące do nich ścieżki. Na podstawie tej bazy danych każdy router tworzy strukturę drzewa, z sobą jako jego korzeniem połączonym z każdym miejscem przeznaczenia za pośrednictwem naj­ krótszej ścieżki.

Bazy danych przekazywania Baza danych przekazywania, czyli tabela routingu, powstaje w oparciu o bazę da­ nych stanu łączy. Gdy każdy router ma kompletną mapę topologii, za pomocą algo­ rytmu SPF może określić najlepszą trasę do każdego znanego miejsca przeznacze­ nia. Następnie umieszcza te trasy w swojej lokalnej tabeli routingu, co umożliwia mu w efekcie przekazywanie danych.

Działanie OSPF Protokół OSPF potrafi obsługiwać różne architektury warstwy łącza danych, np. połączenia LAN i WAN. Sposoby kształtowania się sąsiedztwa i wymiany baz da­ nych zależą od architektury, w której działa OSPF. Dla celów tego punktu skupimy się na architekturach opartych na sieci LAN (rozgloszeniowych). Inne architektury opiszemy w dalszym ciągu tego rozdziału. Omówmy najpierw działanie OSPF wewnątrz pojedynczego obszaru. Gdy istnieje tylko jeden obszar, jest on tożsamy z systemem autonomicznym OSPF. Wszystkie routery w obszarze OSPF przechowują kopię tej samej bazy danych stanu łączy (por. rysunek 6.11). Gdy istnieje wiele obszarów, routery podłączone do nich wszystkich przechowują oddzielne bazy danych dla każdego obszaru.

Rozdziat 6. • PROTOKOŁY ROUTINGU

173

R ys u n e k 6 .1 1 .

W jednoobszarowej implementacji OSPF wszystkie routery wewnątrz obszaru przechowują trzy bazy danych: mapę topologii, tabelę sąsiadów i tabelę routingu

Protokół OSPF korzysta z sześciu różnych Ogłoszeń stanu łączy (LSA, Link State Ad­ vertisements), podzielonych na trzy kategorie: ► ogłoszenia wewnątrzobszarowe (intra-area); ► ogłoszenia międzyobszarowe (inter-area); ► ogłoszenia zewnętrzne (external). Nazwa każdej z nich wskazuje, gdzie takie ogłoszenia są propagowane. Opis sze­ ściu typów LSA znajduje się w tabeli 6.4.

TABELA 6 .4 . Typy LSA Typ LSA

Nazwa ogłoszenia (kategoria)

Opis

1

Łącze routerowe (wewnątrzobszarowe)

Opisuje sieć bezpośrednio podłączoną do routera wraz ze stanem interfejsów.

2

Łącze sieciowe (wewnątrzobszarowe)

Identyfikuje wszystkie routery podłączone do sieci lokalnej.

3

Łącze zbiorcze (międzyobszarowe)

Sumaryzuje dany podobszar routerów sieci leżącej na zewnątrz obszaru.

4

Łącze zbiorcze (międzyobszarowe)

Sumaryzuje trasy na potrzeby zewnętrznych sieci nie korzystających z OSPF, leżących poza systemem autonom icznym .

5

Łącze zewnętrzne systemu autonomicznego (zewnętrzne)

Opisuje trasę do celu w innym systemie autonom icznym .

7

Łącze zewnętrzne systemu autonom icznego (zewnętrzne)

szczątkową (stub network).

Przenosi inform acje o trasach przez

sieć

174

TCP/IP. SZKOŁA PROGRAMOWANIA

Ogłoszenia wewnątrzobszarowe Routery wysyłają ogłoszenia wewnątrzobszarowe w obrębie obszaru. Ogłoszenia te rozchodzą się się tylko w obszarze ich powstawania, opisując łącza routera lokalnego i sied w tym obszarze. Routery masowo wysyłają ogłoszenia typu 1 (rozsyłane przez wszystkie routery) i typu 2 (wysyłane tylko przez routery typu DR) jedynie na terenie pojedynczego obszaru. Istnieją dwa typy wewnątrzobszarowych ogłoszeń LSA: > 1 (łącze routerowe); > 2 (łącze sieciowe). Routeiy wysyłają ogłoszenia typu 1 na docelowy adres multiemisyjny 224.0.0.6 (ad­ res grupy multiemisyjnej routerów typów DR i BDR). Ogłoszenia te opisują sieci podłączone do nich bezpośrednio i stan podłączonych do tych sieci interfejsów. W sieciach LAN (rozgłoszeniowych) router DR wysyła ogłoszenie typu 2 na doce­ lowy adres 224.0.0.5 (adres grupy multiemisyjnej wszystkich routerów OSPF). Ogłoszenie to identyfikuje wszystkie routery podłączone do sieci lokalnej. Na rysunku 6.12 pokazano przykład wewnątrzobszarowego LSA typu 1, zaś na ry­ sunku 6.13 — wewnątrzobszarowego LSA typu 2. Rysunek 6 .1 2 .

Wszystkie routery wysyłają wewnątrzobszarowe ogłoszenia LSA typu 1 na docelowy adres multiemisyjny 224.0.0 .6 O g ło s z e n ia łą c z a ro u te ro w e g o : „ O ” (O S P F ) • W y s y ła n e p rz e z w s z y s tk ie ro u te ry n a a d re s 2 2 4 .0 .0 .6

RYSUNEK 6 . 1 3 .

Tylko routery DR wysyłają wewnątrzobszarowe ogłoszenia LSA typu 2 do wszystkich routerów w tym samym segmencie

Ogłoszenia stanu łączy

typ 2

O g ło s z e n ia łą c z a s ie c io w e g o : „O ” (O S P F ) • W y s y ła n e ty lk o p rz e z ro u te ry D R na a d re s 2 2 4 .0 .0 .5

Rozdział 6. • PROTOKOŁY ROUTINGU

175

Ogłoszenia międzyobszarowe Routery granicy obszaru (ABR, Area Border Routers) wysyłają ogłoszenia międzyobszarowe między bezpośrednio połączonymi obszarami OSPF. Na ogół routery ABR łączą podobszary ze szkieletem (obszarem 0) — głównym obszarem tranzy­ towym całego ruchu międzyobszarowego. Ogłoszenia te sumaryzują trasy w obrębie podobszaru OSPF. Routery ABR wysyłają je do obszaru 0, gdzie inne ABR poznają je, a następnie w swoich własnych obszarach propagują nowe informacje mię­ dzyobszarowe. Istnieją dwa typy międzyobszarowych ogłoszeń LSA: > 3 (łącze zbiorcze); > 4 (łącze zbiorcze). Routery ABR wysyłają też ogłoszenia typu łącza zbiorczego po to, żeby sumaryzować swój podobszar obszarowi 0 (szkieletowi). Wykorzystują je również do ogła­ szania w swoich własnych podobszarach tras zbiorczych z innych podobszarów, poznanych za pośrednictwem obszaru 0. Ogłoszenia typu 4 routery ABR wysyłają w celu identyfikacji routerów Granicy systemu autonomicznego (ASBR, Autonomous System Boundary Routers), zapewniających dostęp do leżących poza ich systemem autonomicznym zewnętrznych, niekorzystających z OSPF, sieci. Na rysunku 6.14 pokazano przykłady międzyobszarowych ogłoszeń LSA typu 3 i 4. R ysunek 6 . 1 4 .

Ogłoszenia stanu łączy

Routery ABR wysyłają międzyobszarowe ogłoszenia zbiorcze LSA typu 3 i 4

O g ło s z e n ia z b io r c z e : „!A ” ( In te r - A r e a ) • ty p u 3 : w y s y ła n e p r z e z r o u te r y A B R d o o b s z a r u 0 z p r z e d s t a w ie n ie m z b io r c z y m ic h w ła s n y c h o b s z a r ó w • ty p u 4 : s łu ż ą c e d o id e n ty fik a c ji tr a s y d o r o u t e r ó w A S B R

Ogłoszenia zewnętrzne Ogłoszenia zewnętrzne są wysyłane tylko przez routery typu ASBR, i są propago­ wane w całym systemie autonomicznym OSPF z wyłączeniem obszarów szczątko­ wych (stub areas), opisanych w dalszym ciągu rozdziału. Ogłoszenia opisują trasy

176

TCP/IP. SZKOŁA PROGRAMOWANIA

zewnętrzne typu innego niż OSPF, leżące poza systemem autonomicznym. Przy­ kładem takiej trasy może być trasa RIP, wszczepiana (tzn. na nowo rozprowadzana) w systemie autonomicznym OSPF celem jej ogłaszania. Ponieważ RIP jest proto­ kołem innego typu niż OSPF, protokół OSPF uzna te informacje za obce i będzie je jako takie ogłaszał. (Tematyka wszczepiania tras zewnętrznych wykracza poza zakres niniejszej książki, a jego konfiguracja zależy od dostawców. Za trasę zewnętrzną będziemy po prostu uważać dowolną trasę, której protokół OSPF nie potrafi poznać w sposób natywny (wrodzony).) Istnieją dwa typy zewnętrznych ogłoszeń LSA: > 5 (łącze zewnętrzne); > 7 (łącze zewnętrzne). Ogłoszenia typu 5 są wysyłane tylko przez routery ASBR, które oprócz OSPF korzystają z przynajmniej jeszcze jednego protokołu routingu (RIP, IGRP, EIGRP, routingu sta­ tycznego itd.). Administrator może skonfigurować routery ASBR tak, aby do środowi­ ska OSPF dało się wszczepiać trasy innego typu. Ogłoszenia typu 5 umożliwiają ogłaszanie obcych tras w całym systemie autonomicznym, podając je do wiadomości pozostałym obszarom i routerom OSPF. Ogłoszenia typu 7 są wysyłane tylko przez routery ASBR podłączone do „Obszaru nie tak szczątkowego" (NSSA, Not So Stubby Area), omówionego w dalszym ciągu roz­ działu, i routery podłączone do sieci szczątkowej, które oprócz OSPF korzystają z przynajmniej jeszcze jednego protokołu routingu (RIP, IGRP, EIGRP, routingu statycznego itd.). Routery ASBR można skonfigurować tak, aby przyjmowały trasy typu innego niż OSPF i wszczepiały je do środowiska NSSA za pomocą ogłoszeń typu 7, przenoszących informacje o trasach przez sieć szczątkową. Router ABR podłą­ czony do obszaru 0 przekształca ogłoszenie LSA typu 7 na typ 5 i dopiero potem przekazuje te informacje do szkieletu. Na rysunku 6.15 pokazano przykład zewnętrznego ogłoszenia typu 5, zaś na ry­ sunku 6.16 — zewnętrznego ogłoszenia typu 7.

Nagłówek LSA Pakiet opisu bazy danych zawiera przynajmniej jedno ogłoszenie LSA. Każdy na­ główek LSA, o długości 20 bajtów, ma taki sam format i zawiera te same pola. Format i pola nagłówka LSA protokołu OSPF pokazano na rysunku 6.17. Poniżej w kolejnych podpunktach omawiamy pola nagłówka LSA.

Rozdział 6. • PROTOKOŁY ROUTINGU

Ry s u n e k 6 . 1 5 .

177

O głoszenia sta n u łączy ty p 5

Routery ASBR wysyłają LSA typu 5 w celu ogłaszania tras zewnętrznych typu innego niż OSPF

O głoszenia zew nętrzne AS: „E 1” (External 1) • W ysyłane przez routery A SBR ; słu ż ą do identyfikacji tras do zew nętrznych sieci autonom icznych

O głoszenia stanu łączy ty p 7

Ry su n ek 6 .1 6 .

Routery ASBR stosują ogłoszenia typu 7, podobne do ogłoszeń typu 5, w celu przesyłania przez obszar NSSA do obszaru 0 uaktualnień tras zewnętrznych innych niż OSPF

Ry s u n e k 6 .1 7 .

O głoszenia zew nętrzne AS: „E2” (External 2) • W ysyłane przez routery ASBR tylko w obszarze NSSA, celem ogłaszania tras zew nętrznego AS O pcje

W iek LS

Nagłówek LSA protokołu OSPF zawiera 20 bajtów

Typ LS

ID stanu łączy

Nagłówek ogłoszenia stanu łączy

R outer ogłaszający N um er kolejny LS Suma kontrolna LS

Długość

Wiek LS (LS Age) Pole zawierające wartość czasu (mierzoną w sekundach), który upłynął od wysłania ogłoszenia LSA przez router, który go nadał.

Opcje (Options) Pole zawierające te same wartości, co w pakiecie Hello. Pakiety Hello omówimy dalej, w punkcie „Nagłówki dodatkowe".

178

TCP/IP. SZKOŁA PROGRAMOWANIA

Typ LS (LS Type) Pole to definiuje typ wysyłanego LSA jako wewnątrzobszarowy (1 lub 2), międzyobszarowy (3 lub 4) albo zewnętrzny (5 lub 7).

ID stanu łączy (Link State ID) W zależności od typu ogłoszenia LSA, wartość tego pola identyfikuje adres IP ro­ utera z którego wyszło ogłoszenie (typy 1 i 4) albo adres IP ogłaszanej sieci (typy 2, 3, 5 i 7). Opis istniejących wartości ID znajduje się w tabeli 6.5. TABELA 6.5. ID stanu łączy Wartość ID

Opis

1

ID routera

2

DR

podległego (slave)

3

Adres IP ogłaszanej sieci docelowej

4

ID routera ASBR

5

Adres IP ogłaszanej sieci docelowej

Router ogłaszający (Advertising Router) Pole identyfikujące router, który zapoczątkował ogłoszenie.

Numer kolejny LS (LS Sequence Number) Pole gwarantujące doręczanie i odbiór pakietów opisu bazy danych (DD, Database Description). Za każdym razem gdy router OSPF zapoczątkowuje ogłoszenie, umieszcza w nim identyfikujący je numer kolejny. Pakiety DD bardziej szczegółowo omówimy w punkcie „Nagłówki dodatkowe".

Suma kontrolna LS (LS Checksum) Wartość tego pola potwierdza, że zawartość pakietu DD protokołu OSPF nie została uszkodzona w czasie tranzytu.

Długość (Length) Pole zawierające długość datagramu OSPF, podaną w bajtach.

Stany routera OSPF Jak już wiemy, aby wymieniać z sąsiadami informacje o trasach, router musi najpierw stworzyć relacje przylegania (tj. stać się ich sąsiadem). Routery OSPF przechodzą po kolei przez następujące stany:

Rozdział 6. • PROTOKOŁY ROUTINGU

179

1. Wyłączony (Down); 2. Inicjalizacja (Init); 3. Dwukierunkowy (Two-way); 4. ExStart; 5. Wymiana (Exchange); 6. Ładowanie (Loading); 7. Pełne dopasowanie(Full). Najłatwiej zapamiętać stany pierwszy i ostatni. Stan zoyłączony oznacza, że na da­ nym routerze nie został włączony protokół OSPF albo został wyzerowany interfejs. Innymi słowy router nie może aktualnie uczestniczyć lub aktualnie nie uczestniczy w wymianie informacji o trasach. W stanie pełnego dopasoiuania osiągnięto zbież­ ność tabeli routingu i router może czynnie kierować datagramy. Aby dojść do stanu pełnego dopasowania, router musi przejść przez pozostałe stany. Poniżej w kolej­ nych podpunktach opisujemy je wszystkie.

Stan inicjowania Po włączeniu protokołu OSPF na interfejsie, router przedstawia się wszystkim swoim sąsiadom. Robi to generując multiemisyjny datagram Hello, przedstawiający go i jego parametry. W tym momencie między sąsiadami nie istnieją żadne relacje przylegania. Przykład stanu inicjalizacji pokazano na rysunku 6.18. RYSUNEK 6.18. W stanie inicjalizacji router inicjuje ze swoimi sąsiadami proces tworzenia relacji przylegania

Stan inicjalizacji - brak DR/BDR

° Routery w ysyła ją kom unikaty „H ello” w celu ustanow ienia z sąsiednim i routeram i relacji przylegania

W stanie inicjalizacji nie istnieje jeszcze router DR ani BDR (nie nastąpił jeszcze proces ich wyboru). Router przechodzi przez ten stan po początkowym włączeniu protokołu OSPF lub wyzerowaniu interfejsu przez administratora. W tym stanie routery transmitują komunikaty Hello, zapowiadając swoją obecność pozostałym routerom w sieci. Ogłoszenie to wysyłają wszystkie routery do wszystkich route­ rów w tym samym segmencie. Komunikat jest odbierany przez routery przyłączone do tej samej podsieci, wskutek czego poznają swoich nowych sąsiadów, których mogą następnie umieścić w swoich bazach danych przylegania.

180

TCP/IP. SZKOŁA PROGRAMOWANIA

Stan dwukierunkowy Po otrzymaniu przez router komunikatów Hello od innych routerów lokalnych, za­ czynają się kształtować relacje przylegania. Każdy router poznaje swoich sąsiadów i dodaje ich do swojej lokalnej bazy danych przylegania. Relacje przylegania kształtują się tylko wtedy, gdy pasują do siebie następujące pola pakietu Hello: > ID obszaru (Area ID); > czasomierze powitania (Hello) i braku aktywności (Dead); > uwierzytelnianie (Authentication); B> ID namiastki (Stub ID). Gdy któreś z nich się nie zgadza, sąsiednie routery nie ukształtują przylegania, więc nie będą mogły wymieniać informacji o trasach. (Jest to tylko część parametrów Hello — wszystkie bardziej szczegółowo omówimy w dalszym ciągu rozdziału.) Na rysunku 6.19 pokazano router OSPF, wykorzystujący komunikat Hello do utworzenia bazy danych przylegania. Rys u n e k 6 .1 9 .

Routery wykorzystują komunikaty Hello protokołu OSPF do budowania bazy danych przylegania

Z a w ia d o m ie n ia „H e llo ” p ro to k o łu O SPF

W a rto ści m u s z ą s ię z g a d za ć na p rzyle g łych ro ute ra ch

ID ro ute ra ID o b sza ru O S P F S ą sie d zi P rio ry te t ro ute ra A d re s IP ro ute ra DR C z a s o m ie rz e p o w ita n ia /b ra k u a k ty w n o ś c i H asło O S P F ID fla g i o b sza ru s z c z ą tk o w e g o

U w a g a : Je śli p rz y p is a n o h a s ło u w ie rz y te ln ia n ia , on o te ż m u si s ię z g a d z a ć !

W tym momencie każdy router segmentu lokalnego zna swoich sąsiadów i ustano­ wił relację dwukierunkową (por. rysunek 6.20). Stan dwukierunkowy zakłada, że routery odebrały i wymieniły początkowe komunikaty Hello oraz włączyły je do swoich tabel przylegania. Aby podtrzymać relacje sąsiedzkie z routerami lokalnymi, każdy router OSPF co 10 sekund transmituje komunikaty Hello.

Stan ExStart Po przejściu przez stany inicjowania i dwukierunkowy, wszystkie routery w seg­ mencie mają dość informacji, by wybrać DR i BDR. Każda sieć rozgłoszeniowa (tzn. LAN) wybiera DR i BDR każdego segmentu. Do ich wyboru routery wykorzystują dwa parametry (pola) pakietu Hello: ID ■priorytetu (Priority ID) i ID routera (Router ID).

Rozdział 6. » PROTOKOŁY ROUTINGU

RYSUNEK 6 . 2 0 .

181

S tan d w u k ie ru n k o w y - b ra k D R/BDR

W stanie dwukierunkowym routery z tej samej sieci tworzą relację dwukierunkową

£

d

H I

I R ou te r 3 |

J

R o u te r 1 R o u te r 3

R o u te r 1 R o u te r 2

« K ażd y ro u te r d o d a je do sw o je j b a zy d a n ych p o zo sta łe ro u te ry

Najpierw brane jest pod uwagę ID priorytetu, potem ID routera. Router o najwyż­ szym ID priorytetu zostaje wybrany na funkcję DR, a router o drugim co do wielkości wartości ID — na funkcję BDR. Jeśli wszystkie routery mają taką samą wartość ID priorytetu, DR-em zostaje router o najwyższym ID routera, a BDR-em — router o drugiej w kolejności wartości ID. Oba te parametry można modyfikować, mani­ pulując w ten sposób wyborem DR i BDR. Routery DR i BDR stają się kluczowymi punktami segmentu, odpowiadając za na­ stępujące działania: > Zbieranie wszystkich ogłoszeń o trasach od routerów lokalnych. > Tworzenie bazy danych stanu łączy. >• Rozsiewanie tych informacji do pozostałych routerów tego samego segmentu (tylko DR — BDR jest rezerwą na wypadek, gdyby DR nie mógł tego robić). Pozostałe routery stają się podległe wobec DR i BDR, które stają się wobec nich nad­ rzędne . Routery DR i BDR są odbiorcami ogłoszeń wszystkich routerów, należąc do grupy multiemisyjnej 224.0.0.6, do której wszystkie routery adresują swoje ogłosze­ nia. DR i BDR odbierają i przetwarzają ogłoszenia typu 1, pochodzące od pozosta­ łych routerów segmentu. Tylko DR odpowiada jednak za rozprowadzanie tych in­ formacji do routerów lokalnych, adresując je do grupy multiemisyjnej 224.0.0.5. Router BDR pozostaje w stanie spoczynku do momentu, kiedy router DR nie bę­ dzie w stanie rozsyłać informacji. BDR staje się wówczas DR. Gdy zawodzi DR, jego rolę przejmuje BDR, a przywrócony router spełniający uprzednio funkcję DR nie zajmuje miejsca aktualnego routera DR.

18 2

TCP/IP. SZKOŁA PROGRAMOWANIA

Wybieranie DR każdego segmentu zmniejsza liczbę relacji przylegania, niezbęd­ nych w całej intersieci. Ogranicza to przetwarzanie ruchu multiemisyjnego OSPF, koniecznego do wykonania przez wszystkie routery (por. rysunek 6.21). Rys u n ek 6 .2 1 .

ExStart należy traktować jak stan, przez który routery muszą przejść przed rozpoczęciem wymiany (exchange starting) posiadanych informacji o trasach

S tan E x S ta rt [

H

BDR

dr]

I

m H ello

u

//

• Wszystkie routery wysyłają ogłoszenia LSA do routerów DR i BDR na adres multiemisjl 224.0.0.6

Stan wymiany Jak wynika z nazwy, w stanie wymiany wszystkie routery podległe wymieniają z routerami DR i BDR informacje o trasach. Routeiy podlegle wysyłają te informacje na adres 224.0.0.6 (DR/BDR). Routery DR i BDR przyswajają sobie zmiany w bazach danych, ale synchronizacją i rozsyłaniem informacji zarządza tylko DR. Transmituje on poznane informacje o trasach do wszystkich podległych routerów segmentu, na adres multiemisji 224.0.0.5 (por. rysunek 6.22). Rys u n e k 6 .2 2 .

Stan wymiany umożliwia routerom wymianę posiadanych informacji o trasach

S tan W y m ia n y DR - N ad rzę d ny

-------------------

np=^y

—

— —

| BDR |

224.0.0.5

M B .

Gdy zawiedzie któryś z poprzednich stanów, nie zostanie zbudowana mapa topo­ logii. Przy pierwszym wejściu w stan wymiany router ma pustą bazę danych stanu łączy, chcąc ją zatem utworzyć odbiera wszystkie informacje o trasach. Później wy­ syła tylko uaktualnienia pokazujące zmiany topologii. Tym niemniej routery OSPF co 30 minut wysyłają wszystkie posiadane informacje o trasach, zapewniając w ten sposób znajomość bieżącej topologii wszystkim routerom OSPF.

Rozdział 6. • PROTOKOŁY ROUTINGU

183

Stan ładowania Router wchodzi w stan ładowania tylko po otrzymaniu od DR sprzecznych infor­ macji w stanie wymiany. Jeśli odebrana informacja różni się od aktualnie posiada­ nej mapy topologii, router może w stanie ładowania zażądać informacji bardziej szczegółowych, pozwalających mu na uzupełnienie mapy. Gdy nie stwierdzi żad­ nych rozbieżności, pominie ten stan.

Stan pełnego dopasowania Po przejściu przez pozostałe stany router osiąga końcowy stan pełnego dopasowa­ nia. W tym stanie na podstawie mapy topologii buduje tabelę routingu. Wykonując algorytm SPF dla wszystkich tras określonych w bazie danych stanu łączy, wypro­ wadza i zapisuje w bazie danych przekazywania najlepsze trasy prowadzące do miejsc przeznaczenia. Routeiy przechodzą przez wszystkie stany tylko wtedy, gdy administrator pierwszy raz włącza protokół OSPF, w działaniu którego routery te jeszcze nie brały czynnego udziału. Po osiągnięciu stan pełnego, router będzie przechodził przez najwyżej trzy stany: > wymiany, > ładowania, t> pełnego dopasowania. Gdy coś się zmieni, router wygeneruje uaktualnienie wyzwalane i zacznie się wy­ miana. Jeśli otrzyma w uaktualnieniu sprzeczną informację, wejdzie w stan łado­ wania, w którym zażąda od routera DR większej liczby informacji. Po odebraniu niezbędnych informacji wykona na bazie danych LS algorytm SPF, nastąpi zbież­ ność i zacznie się routing.

Typy routerów OSPF Protokół OSPF określa różne role, przyjmowane przez routery w zależności od ich umiejscowienia w systemie autonomicznym. Pamiętamy, że system autonomiczny jest grupą routerów wymieniających informacje poprzez wspólny protokół routin­ gu (w tym przypadku OSPF). Router może przyjmować jednocześnie wiele ról. Ist­ nieją cztery typy routerów OSPF (por. rysunek 6.23): > Wewnętrzny — wszystkie jego interfejsy zawarte są w jednym obszarze OSPF. Ten typ routera nie korzysta z innych protokołów routingu. E> Szkieletowy — przynajmniej jeden jego interfejs jest podłączony do obszaru 0 (szkieletu). Router posiadający wszystkie interfejsy w obszarze 0 jest wewnętrz­ nym routerem szkieletowym.

184

TCP/IP. SZKOŁA PROGRAMOWANIA

Rysunek 6.23. Umiejscowienie routera w obrębie sieci OSPF decyduje o jego typie

Typy routerów OSPF

ASBR

f l

Z e w n ę trz n y A S ; A R IP lub I n t e r n e t /

> ABR — znajduje się na granicy przynajmniej dwóch obszarów OSPF. Routery tego typu na ogól łączą się z wieloma obszarami, przeważnie podobszarami ob­ szaru 0. ABR-y łączące się z obszarem 0 są jednocześnie routerami szkieletowy­ mi. Routery typu ABR przechowują wiele baz danych stanu łączy, po jednej dla każdego obszaru do którego są podłączone. > ASBR — znajduje się na granicy dwóch systemów autonomicznych, z których jeden korzysta z OSPF, a drugi z jakiegoś innego protokołu routingu (np. RIP). ASBR-y można konfigurować tak, aby w systemie autonomicznym OSPF ogłaszały trasy innego typu, rozsiewając informacje o trasach zewnętrznych we wszystkich jego obszarach.

Działanie O SPF w różnych architekturach łącza danych Jalc już wcześniej mówiliśmy, protokół OSPF działa w różnych typach sieci. Jego dostępne funkcje różnią się jednak w zależności od typu takiej sieci. OSPF obsłu­ guje architektury oparte na rozgłaszaniu, a także łącza „punkt-punkt" i sieci dostępu wielokrotnego bez rozgłaszania (NBMA, Non-Broadcast Multi-Access).

Rozgłaszanie Sieci LAN oparte na rozgłaszaniu (Ethernet, Token-Ring i FDDI) obsługują ruch rozgłoszeniowy i multiemisyjny, umożliwiając dynamiczne odkrywanie sąsiadów, wybór DR i BDR oraz wymiany informacji o trasach (por. rysunek 6.24).

Rozdział 6 . • PROTOKOŁY ROUTINGU

Rys u n e k 6 . 2 4 .

Każda sieć dostępu wielokrotnego z rozgłaszaniem zawiera jeden DR i jeden BDR. Ponieważ te typy sieci domyślnie obsługują ruch rozgłoszeniowy i multiemisyjny, relacje sąsiedzkie i DR-y/BDR-y są tworzone automatycznie

185

R e la cje s ą s ie d z k ie w s ie c ia c h d o s tę p u w ie lo k ro tn e g o z ro z g ła s z a n ie m

„Punkt-punkt" Połączenie „punkt-punkt", czyli oparte na dedykowanej linii dzierżawionej, składa się z dwóch routerów podłączonych do końców łącza. W takim środowisku admi­ nistrator musi ręcznie skonfigurować na routerze adres IP jego sąsiada. Dzięki temu można stworzyć relację przylegania i wymieniać informacje o trasach za pośred­ nictwem łącza. Ponieważ istnieją tylko dwa routery, nie jest potrzebny DR ani BDR, sterujący tworzeniem i synchronizacją bazy danych stanu łączy (por. rysunek 6.25). Rys u n e k 6 . 2 5 .

Łącza WAN typu „punkt-punkt” (połączenia oparte na dedykowanej linii dzierżawionej) nie posiadają DR ani BDR, gdyż zawierają tylko dwa routery, po jednym na każdym z końców łącza

R e la c je s ą s ie d z k ie w p o łą c z e n ia c h s z e re g o w y c h „p u n k t- p u n k t”

N ie je s t w ym a g a n y w y b ó r DR ani BD R, g d y ż na łą c z u is tn ie ją ty lk o d w a u rządzenia.

NBMA Sieci dostępu wielokrotnego bez rozgłaszania (NBMA) składają się z przynajmniej dwóch routerów, komunikujących się przez sieć nierozgłoszeniową (np. X.25 lub Frame Relay). Ponieważ sieć NBMA nie obsługuje rozgłoszeń, aby ukształtować re­ lacje przylegania trzeba ręcznie skonfigurować na każdym routerze adresy IP jego routerów sąsiedzkich. Routery mogą wówczas wybrać DR i BDR oraz wymieniać informacje o trasach bez korzystania z rozgłoszeń.

186

TCP/IP. SZKOŁA PROGRAMOWANIA

Gdy architektura bazowa nie obsługuje rozgłoszeń, informacje o sąsiadach trzeba konfigurować ręcznie. W przeciwnym razie wszystko to, co dotyczy odkrywania są­ siadów, wyboru DR/BDR i wymiany informacji o trasach, dzieje się automatycznie (por. rysunek 6.26). Rysunek 6 .2 6

Sieci NBMA nie obsługują rozgłaszania

Sieci złożone z wielu obszarów W małych i średnich intersieciach można stosować jednoobszarową implementację protokołu OSPF. W większości jednak średnich i dużych intersieci system auto­ nomiczny jest dzielony na mniejsze, bardziej nadające się do zarządzania obszary (podsystemy). Implementacja jednoobszarowa ma jedną zasadniczą wadę: wraz ze wzrostem licz­ by sieci i routerów rośnie rozmiar bazy danych stanu łączy, a routery w tym obsza­ rze muszą śledzić wszelkie zmiany stanu routerów i sieci obszaru. Przechowywanie i obsługa dużych baz danych wymaga dużej ilości pamięci i czasu procesora (CPU) od wszystkich objętych tym routerów. Ilekroć łącze wewnątrz obszaru stanie się niedostępne lub dostępne, wszystkie routery w tym obszarze muszą ponownie ob­ liczać algorytm SPF dla wszystkich tras z bazy danych. Dzieląc system autonomiczny na wiele obszarów, zmniejszamy ilość ruchu uaktu­ alniania tras, ograniczając go do każdego obszaru i zmniejszając całkowity rozmiar tabeli routingu. Routery przechowują bazy danych tylko tych obszarów, do których są bezpośrednio podłączone, ograniczając ruch uaktualniania tras wewnątrzobszarowych do tego obszaru, w którym został on zapoczątkowany. Zmiany stanu, doty­ czące tras w jednym obszarze, nie zmuszają routerów z innych obszarów do przeli­ czania tabel tras. Dzięki temu radykalnie maleje liczba obliczeń SPF wykonywanych przez routery. System autonomiczny można dzielić w dowolny sposób, choć w typowy podział wynika z geografii — każde położenie fizyczne staje się jednym obszarem (podsyste­ mem). W systemie wieloobszarowym musi istnieć obszar 0 (tzn. obszar szkieletowy),

Rozdział 6. » PROTOKOŁY ROUTINGU

187

stanowiący główny obszar tranzytowy całego ruchu międzyobszarowego (por. ry­ sunek 6.27). Tak jak „wszystkie drogi prowadzą do Rzymu", wszystkie trasy muszą prowadzić do i przez obszar 0. R ysunek 6.27.

W implementacji wieloobszarowej OSPF cała domena routingu nosi nazwę systemu autonomicznego OSPF. Wszystkie obszary muszą łączyć się z głównym szkieletowym obszarem tranzytowym, zwanym obszarem 0

AS o wielu obszarach System autonomiczny (AS)

Routery wewnątrz obszaru mogą wymieniać informacje tylko z routerami tego sa­ mego obszaru. Na rysunku 6.27 istnieją trzy obszary (podsystemy) — 1, 2 i 3 — fi­ zycznie połączone z obszarem 0 (szkieletem) za pośrednictwem routerów ABR, sumaryzujących i ogłaszających trasy rdzeniowi (szkieletowi), który z kolei ogłasza informacje o trasach każdego obszaru pozostałym obszarom.

Typy obszarów Każdy typ obszaru w środowisku wieloobszarowym ma dwa wyróżniki: typy ak­ ceptowanych ogłoszeń LSA i typy generujących je routerów. Istnieją trzy główne typy obszarów OSPF: ► szkieletowy (obszar 0); ► standardowy; dwa obszary szczątkowe czy też namiastkowe (standardowy szczątkowy i NSSA). Łącze wirtualne nie jest obszarem, zapewnia jedynie połączenie logiczne między dwoma obszarami za pośrednictwem innego.

Obszar 0 Szkielet jest spoiwem pozostałych obszarów. Oprócz wszystkich propagowanych w nim ogłoszeń wewnątrzobszarowych, przez obszar ten przechodzą wszystkie zbiorcze ogłoszenia międzyobszarowe (wysyłane przez ABR-y) i ogłoszenia tras

188

TCP/IP. SZKOŁA PROGRAMOWANIA

zewnętrznych systemów autonomicznych (wysyłane przez ASBR-y) po drodze do innych obszarów. Obszar ten może przyjmować wszystkie typy ogłoszeń tras OSPF, tzn. typy 1 - 5 ogłoszeń LSA.

Obszar standardowy Obszar standardowy funkcjonuje jako podobszar obszaru 0, akceptując ogłoszenia wewnątrzobszarowe (typy 1 i 2) i międzyobszarowe (typy 3 i 4) od innych podobszarów, wysyłane przez ABR łączący ten obszar ze szkieletem. Obszar ten przyj­ muje też trasy zewnętrznych systemów autonomicznych (typ 5), ogłaszane przez podłączony do niego ASBR. Obszary standardowe można fizycznie łączyć z obsza­ rem 0 za pośrednictwem wielu bram, tworząc w ten sposób ścieżki nadmiarowe na i poprzez rdzeń.

Obszary szczątkowe Obszar szczątkow y (stub area) (zwany też wejściowym) ma tylko jedno wejście i jedno wyjście, tzn. jedno połączenie z obszarem 0. Przez to łącze na ogół nie trzeba wysyłać uaktualnień OSPF, zwłaszcza w przypadku powolnego łącza WAN lub połączenia wdzwanianego. Najczęściej w tej sytuacji ścieżkę prowadzącą do sieci usytuowanych poza obszarem szczątkowym określa się za pomocą trasy domyślnej. Skonfigurowanie trasy domyślnej (statycznej) wyklucza ruch uaktualniający na łączu, oszczędzając cenną szerokość pasma. W RFC 1583 zdefiniowano dwa typy obszarów szczątkowych: > standardowy, > NSSA. (Firma Cisco Systems dodatkowo ma własny obszar szczątkowy, zwany całkowicie szczątkowym — totally stubby — którego w tej książce nie będziemy omawiać.) Obszary szczątkowe mają następujące ograniczenia ogólne: > W skład obszaru szczątkowego nie może wchodzić obszar 0 ani żaden ASBR. > Administrator musi skonfigurować wszystkie routery podłączone do lub znaj­ dujące się w obrębie obszaru szczątkowego jako routery pasywne (stub routers). Standardowy obszar szczątkowy Choć obszary szczątkowe implementując trasy domyślne oszczędzają na ogłosze­ niach OSPF wysyłanych do obszaru, standardowy obszar szczątkowy przyjmuje ogłoszenia wewnątrz- i międzyobszarowe (LSA typu 1, 2, 3 i 4). Obszar ten nie ak­ ceptuje natomiast żadnych ogłoszeń tras zewnętrznych (typu 5 i 7), wysyłanych przez ASBR-y.

Rozdział 6. • PROTOKOŁY ROUTINGU

189

N SSA Obszar nie tak szczątkow y (NSSA) akceptuje ogłoszenia wewnątrzobszarowe (typu 1 i 2). Gdyby tego nie robił, nie miałoby sensu uruchamianie w nim protokołu routingu, który nie potrafiłby poznać przynajmniej tras leżących w obrębie własnego obszaru. Obszar NSSA nie przyjmuje zaś ogłoszeń tras zewnętrznych (LSA typu 5), wysyłanych przez ASBR-y. Tym niemniej z nazwy „nie tak szczątkowy" wynika, że zezwala on na coś jeszcze: na przenoszenie przezeń po drodze do obszaru 0 tras zewnętrznych, mających postać ogłoszeń LSA typu 7 routerów ASBR. Ogłoszenia zewnętrzne typu 7 są przekształcane przez ABR-y na typ 5, a dopiero potem ogłaszane na rdzeniu (por. rysunek 6.28). Rys u n e k 6 .2 8 .

Obszary NSSA przenoszą trasy zewnętrzne do obszaru 0

N SSA (O b s z a r n ie ta k s z c z ą tk o w y )

O śro d e k zdalny

A S B R w szczep ia tra sy R IP /E IG R P do N S S A ja k o LSA typu 7

ce ntra ln e lub ISP

NSSA (obszar 1) na rysunku 6.28 bezpośrednio łączy się poprzez ABR z obszarem 0, a za pośrednictwem ASBR z drugą domeną routingu (tj. systemem autonomicz­ nym), typu innego niż OSPF. ASBR podłączony do tej zewnętrznej domeny korzy­ sta z protokołów RIP, EIGRP i OSPF. Informacje o trasach zewnętrznych trzeba od nowa rozprowadzać w sieci OSPF właśnie za pośrednictwem tego ASBR. Generuje on zatem ogłoszenia LSA typu 7, wysyłane do NSSA. Gdy dotrą one do ABR łączą­ cego NSSA z obszarem 0, przekształcane są na LSA typu 5 i propagowane w całej reszcie obszarów systemu autonomicznego OSPF.

Łącza wirtualne Łącze wirtualne zapewnia ścieżkę logiczną do obszaru 0 przez jego podobszar: albo łącząc nowy obszar ze szkieletem, gdy połączenie fizyczne jest niemożliwe, albo łą­ cząc wiele fizycznie oddzielonych od siebie obszarów 0 (przykład: scalanie dwóch sieci, posiadających oddzielne implementacje OSPF). W każdym przypadku łącza wirtualne wykorzystają obszar standardowy jako ścieżkę tranzytową, łączącą nowy obszar z obszarem 0 lub nawzajem dwa szkielety.

190

TCP/IP. SZKOŁA PROGRAMOWANIA

Na rysunku 6.29 dodano nowy obszar OSPF, ale bez nie połączono go z rdzeniem. Ścieżkę wirtualną do tego rdzenia zapewnia obszar 3, służący do tranzytu. Na ry­ sunku 6.30 scalono dwa działy firmy, posiadające wieloobszarowe implementacje OSPF. Oba obszary 0 muszą być połączone za pośrednictwem ścieżki wirtualnej, prowadzącej przez tranzytowy obszar 51. Rys u n ek 6 .2 9 .

Ł ą c z e w irtu a ln e - p rz y k ła d 1

Łącze wirtualne — ścieżka logiczna prowadząca przez podobszar, łącząca inny obszar z obszarem 0

Łącze wirtualne tworzy ścieżkę logiczną do obszaru 0. YSUNEK 6 .3 0 .

Ł ą c z e w irtu a ln e - p rz y k ła d 2

ba obszary 0 \szkieletami

• Łącze wirtualne między dwoma szkieletami po scaleniu sieci.

Uwaga Łącza w irtu a ln e trzeba konfigurow ać ręcznie na routerach granicznych. Konfiguracja zależy od d o s ta w c ó w , a je j o m ó w ie n ie w ykra cza poza zakres te j książki.

Standardowe pola pakietu OSPF Wszystkie pięć typów pakietów OSPF (opisanych dalej, w podpunkcie „Tyrp Pakietu") ma te same wspólne pola 24-oktetowego nagłówka (por. rysunek 6.31). Pakiety te wykonują działania protokołu OSPF. Pola nagłówka OSPF opisujemy w podpunktach pod rysunkiem.

Rozdział 6. » PROTOKOŁY ROUTINGU

Rys u n e k 6 .3 1 .

Typ

W ersja

Pięć typów pakietów OSPF wykorzystuje ten sam standardowy nagłówek

191

Długość pakietu ID routera nagłów ek pakietu

ID obszaru Sum a Kontrolna

AuType

OSPF

Uw ierzytelnianie

N agłów ek Hello, opisu bazy danych, żądania stanu łączy, uaktualnienia stanu łączy lub potw ierdzenia stanu łączy, plus dane

Różne typy pakietów i ich nagłówki opiszemy dalej, w punkcie „Nagłówki dodat­ kowe".

Numer wersji (Version Number) Ośmiobitowe pole, identyfikujące numer wersji protokołu OSPF (obecnie jest to wersja 2).

Typ Pakietu (Packet Type) Ośmiobitowe pole, identyfikujące typ pakietu OSPF. Listę pięciu różnych typów pakietów wraz z ich funkcjami zawiera tabela 6.6.

TABELA 6.6. Typu pakietów OSPF Nr pakietu

Typ pakietu

Opis

1

H e llo

U sta n a w ia i z a c h o w u je relacje p rzylegania.

2

O pis bazy da n ych (D D )

P rzedstaw ia zb io rczo z a w a rto ść bazy d a n ych.

3

Ż ą d a n ie sta n u łą czy

Żąda In fo rm a c ji o k o n kre tn e j tra s ie lu b pełnego

4

U a k tu a ln ie n ie sta n u łączy

W ysyła in fo rm a c je o tra sa ch w o d p o w ie d zi

u a k tu a ln ie n ia (tzn. w y sła n ia bazy d a n ych ).

na żą d a n ie (tzn. u a ktu a ln ia bazę d a n ych ). 5

P o tw ie rd ze n ie sta n u łą czy

P o tw ie rd za o d b ió r in fo rm a c ji o tra sa ch .

Długość pakietu (Packet Length) Szesnastobitowe pole określające w bajtach długość datagramu OSPF (nagłówka i zawartości).

19 2

TCP/IP. SZKOŁA PROGRAMOWANIA

ID routera (Router ID) Trzydziestodwubitowe pole zawierające niepowtarzalną wartość identyfikującą router, który pierwotnie wysłał pakiet OSPF. Protokół OSPF stosuje tę wartość do wyboru routerów DR i BDR. ID routera może być konfigurowane ręcznie (przez administratora) lub dynamicznie.

ID obszaru (Area ID) Trzydziestodwubitowe pole identyfikujące obszar pochodzenia datagramu OSPF. Obszar 0 ma zawsze ID obszaru równe 0.0.0.0. Wartości dla jego podobszarów mo­ gą się różnić. Administrator może skonfigurować je tak, aby odpowiadały numerom podsieciowym danego podobszaru.

Suma kontrolna (Checksum) Szesnastobitowe pole sprawdzające czy zawartość pakietu OSPF nie została naru­ szona podczas tranzytu. Podczas obliczanie tej sumy nie jest uwzględniane pole uwierzytelniania.

Typ uwierzytelniania (AuType) i uwierzytelnianie (Authentication) Routery OSPF potrafią obsługiwać proste uwierzytelnianie za pomocą haseł. Od­ powiednio skonfigurowane tworzą relacje przylegania tylko z routerami współ­ dzielącymi to samo hasło uwierzytelniania. Oba te pola łącznie uprawomocniają pakiet. Pole AuType (Authentication Typel ma długość 16 bitów, a pole uwierzytel­ nianie — 32 bitów.

Nagłówki dodatkowe Każdy pakiet OSPF za nagłówkiem standardowym zawiera nagłówek dodatkowy, opisujący informacje o routingu przynależne do jednego z pięciu typów pakietów OSPF: > Hello (typ 1); > Opisu bazy danych (typ 2); f> Żądania stanu łączy (typ 3); > Uaktualnienia stanu łączy (typ 4); E> Potwierdzenia stanu łączy (typ 5). W kolejnych podpunktach omawiamy te pakiety wraz z ich nagłówkami.

Rozdział 6. • PROTOKOŁY ROUTINGU

193

Pakiety Hello Datagramy Hello są pakietami OSPF typu 1. Ustanawiają i zachowują one relacje przylegania. Na rysunku 6.32 pokazano ogólny format pakietu Hello, zaś na rysun­ ku 6.33 — przykładowy pakiet Hello w oknie aplikacji Sniffer. Rysunek 6 .3 2 . Pakiety Hello protokołu OSPF zawierają dodatkowe pola Maska sieci, Interwał powitania, Opcje, Priorytet routera, Interwał braku aktywności, Router desygnowany, Zapasowy router desygnowany i Sąsiad

W ersja

D ługość pakietu

Typ = 1 ID routera

Nagłów ek pakietu O SPF

ID O bszaru AuType

Sum a kontrolna

Uw ierzytelnianie

M aska sieci O pcje

Interw ał pow itania

R tr Pri

Interw ał braku aktywności Router desygnow any Zapasow y router desygnowany Sąsiad

Rysunek 6 .3 3 . Informacje przetworzą i przyleganie ukształtują Tylko bramy OSPF z pasującymi wartościami ID obszaru, hasłami uwierzytelniania, konfiguracją szczątka oraz interwałami powitania i braku aktywności mogą przetworzyć informacje i stworzyć relację przylegania

ID ro ute ra K o m u n ika t H e llo (typ 1)

U w ie rz y te ln ia n ie l-lfftx

JSC!

2 2 £2o Morntof Captuie Q.i;p!oy Jools ¡¿¿¡ndow Help

alai aUl sglalpltdalálgl p.\ ej oj IP ' Source add ress ■ [192 20 1 0 1 .1 3 4 ] ć-3 IP. D estin ation address » [2 2 4 .0 .1 5] ¿ J J IP: Ho options y IP: OSPF Header --------0 § 0 OSPF ” ■ OSPF OSPF Version » 2. Type = 1 (Hello). OSPF Router ID = [0 0 .0 . 0 ] OSPF Area ID OSPF Header checksun ! AFCO (correct) (Simple Passw ord). OSPF A u th en tication : OSPF E) OSPF Hetuork mask £255 255 .2 5 5 125] OSPF Hello in te rv a l 1 10 (seconds) OSPF O ptional ca p a b ili' ' 02 ■ Opaqui -ISAs not forwarded OSPF OSPF 1 Demand C i r c u it b it OSPF “ E xtern il A ttrib u te s b it 3 OSPF = no USEt c a p a b ility ) nul ;ic a s t c a p a b ility OSPF e x te rn >1 ro u tin g c a p a b ility . n OSPF no Typ : of S e rv ice ro u tin g c a p a b ility OSPF OSPF Router p r i o r i t y » OSPF: Router dead i n te r v a l ! 40 (st onds) OSPF Designated ro u te r [1 9 2 .; .1 0 1 .1 3 1 ] OSPF: Backup d esignated r o u te r ■ [1 9 2 .; .101 132] OSPF: neighbor (1 ) ■ [0 0.0 OSPF- neighbor ( 2 ) ■ [0.0 0 2 ]

- [0 0.1.0]---

L

1]

\ Dacoile /\M iim \ H a d Tebls /\Protocol Dill. }KStatistics / For Help, pie« F1 |Amerèa Qräne 4Ü) i n s t a r ! [I E ¡ & g j &

%>

I ggManTimtl jjM y C o .. | ¿ JE>

O p cje

¡J?! 1*4 ! U s ta w io n y b it m o żliw ości tra s o w a n ia z e w n ę trz n e g o

194

TCP/IP. SZKOŁA PROGRAMOWANIA

Na rysunku 6.33 router 192.28.101.134 przedstawia się jednoznacznie za pomocą swojego ID routera, służącego do wyboru routerów DR i BDR. Pamiętamy, że router o najwyższym priorytecie lub ID routera staje się routerem DR, a drugi w kolejności — routerem BDR. ID obszaru określa obszar OSPF, z którego wyszło ogłoszenie. Po zastosowaniu haseł (co nie jest konieczne) relacje przylegania będą mogły kształto­ wać tylko bramy posługujące się tymi samymi hasłami. Maska podsieci dla tej bramy wynosi 255.255.255.128, a obsługiwane opcje — 02 (h). Wartość 1 w dowolnej części pola opcji („Optional capabilities" — możliwości nieobowiązkowe) — w tym przypadku „External routing capabilities" (możliwości routingu zewnętrznego) — oznacza, że jest obsługiwana właśnie ta konkretna opcja. Wi­ doczna brama obsługuje zatem ogłoszenia typu innego niż OSPF oraz istnieje ASBR albo inny router w obszarze, obsługujący przechodzące przezeń ogłoszenia zewnętrzne. Poza tym adres IP routera DR wynosi 192.28.101.131, a BDR — 192.28.101.132. Na koń­ cu widać listę znanych sąsiadów naszego routera: 0.0.0.1, 0.0.0.2 itd. W kolejnych punktach dokładnie omówimy poszczególne pola pakietu Hello. M aska sieci (Network Mask) Pole to identyfikuje maskę podsieci lokalnego interfejsu. Interwal powitania (Hello Interval) Steruje częstością nadawania datagramów Hello przez router. Wartość ta zależy od topologii łącza danych, w której działa protokół OSPF. W sieciach rozgłoszeniowych routery wysyłają pakiety Hello co 10 sekund, zaś w sieciach nierozgłoszeniowych — domyślnie co 30 sekund. Opcje (Options) Pole to wyszczególnia funkcje nieobowiązkowe, obsługiwane przez router. Nie wszystkie routery potrafią obsługiwać opcje. W takim przypadku są one odrzucane albo ignorowane. Zdefiniowane są dwie następujące opcje: > Bit T — wartość 1 wskazuje na możliwość obsługi routingu ToS/QoS przez dany router, a wartość 0 na jej brak. Routery z możliwością obsługi ToS tworzą dwa drzewa najkrótszych ścieżek, w których są korzeniami: jedno dla tras z możli­ wością obsługi ToS, unikające routerów bez tej możliwości, a drugie dla tras bez możliwości obsługi ToS (por. rysunek 6.33). !> Bit E — wartość 1 umożliwia routerowi przetwarzanie informacji o trasach ze­ wnętrznych innego typu niż OSPF. Routery obszaru szczątkowego (namiastkowe­ go) nie obsługują uaktualniania tras zewnętrznych, więc nie ustawiają i nie roz­ poznają ustawień tego bitu. Routeiy ASBR zawsze mają ustawiony bit E (por. rysunek 6.33). Dostawcy mogą też implementować inne opcje (por. rysunek 6.33).

Rozdział 6. • PROTOKOŁY ROUTINGU

195

Priorytet routera (RtrPri, Router Priority) ID priorytetu routera OSPF służy wyłącznie do wyboru routerów DR i BDR każde­ go segmentu. Router o najwyższej wartości priorytetu staje się DR-em, sterującym zbieraniem, synchronizacją i rozsiewaniem informacji o trasach dotyczących segmentu. Router o drugiej co do wielkości wartości priorytetu staje się BDR-em, jedynie zbie­ rającym i tworzącym bazę danych stanu łączy. BDR pozostaje w stanie spoczynku dopóki nie zawiedzie DR. Gdy to nastąpi, BDR samoczynnie promuje się na DR-a odcinka, a routery OSPF wybierają nowy router BDR. Wartość domyślna tego parametru zależy od implementacji (dostawcy). Jeśli wszystkie routery mają tę samą wartość priorytetu (tzn. administrator nie skonfigurował na żadnej bramie wartości wyższej niż na innych), DR i BDR są wy­ znaczane w oparciu o ID routera. Interwał braku aktywności (Dead Interval) Wartość ta służy do wykrywania sąsiada, który uległ awarii. Jeśli router w tym in­ terwale czasowym nie usłyszy któregoś ze swoich sąsiadów (tj. nie otrzyma od nie­ go pakietów Hello), uzna go za nieaktywnego. Interwał ten jest domyślnie cztery razy większy od interwału powitania (w sekun­ dach). Jego wartość zależy od topologii łącza danych, w której działa protokół OSPF: w sieciach rozgłoszeniowych wynosi 40 sekund, zaś w sieciach nierozgłoszeniowych — domyślnie 120 sekund. Router desygnowany (Designated Router) Pole to zawiera adres IP routera DR, o ile jest znany; w przeciwnym razie — 0.0.0.0. Zapasowy router desygnowany (Backup Designated Router) Pole to zawiera adres IP routera BDR, o ile jest znany; w przeciwnym razie — O.O.O.O. Sąsiad (Neighbor) Pole to zawiera listę ID-ów wszystkich routerów sąsiedzkich, poznanych przez dany router za pośrednictwem lokalnych pakietów Hello.

Pakiety Opisu Bazy Danych Pakiety Opisu Bazy Danych (typ 2) przenoszą dane potrzebne do inicjowania topo­ graficznych baz danych urządzeń przyległych. Ich format przedstawiono na rysun­ ku 6.34.

196

TCP/IP. SZKOŁA PROGRAMOWANIA

Ry su n e k 6 .3 4 .

W ersja

Pakiety opisu bazy danych protokołu OSPF zawierają dodatkowe pola MTU interfejsu, opcje i numer kolejny, a także nagłówek LSA

Typ = 2

D ługość Pakietu ID routera ID O bszaru

Sum a kontrolna

AuType

Nagłów ek pakietu O SPF

U w ierzytelnianie

MTU interfejsu

O pcje

0 0 0 0 0 I M MS

N um er kolejny

N agłów ek ogłoszenia stanu łączy (LSA)

O pcje (Options) Pole to opisuje funkcje obsługiwane przez router OSPF. Istnieje ono także w innych typach pakietów OSPF, mając jednak różne znaczenie w zależności od użytkowanego typu. Dla pakietów DD w polu tym znajdują się trzy bity znaczące (por. tabela 6.7).

TABELA 6.7. Opcje pakietów Opisu Bazy Danych (DD) Opcja

Opis

1 (In it — inicjacja)

Gdy jest ustawiony (włączony), bit ten oznacza pierwszy transm itow any pakiet opisu bazy danych.

M (More — więcej)

Ustawiony oznacza, że powinno nadejść więcej pakietów DD. W yłączony (wartość 0) oznacza pakiet ostatni.

MS (Master/Slave — nadrzędny/podległy)

Określa czy transm itujący router jest nadrzędny (DR), czy podległy (pozostałe): 1 = nadrzędny; 0 = podległy.

Num er k olejn y (Sequence Number) Nadawca ustawia po kolei wszystkie pakiety opisu bazy danych, a odbiorca potwier­ dza każdy z nich. Wartość początkowa tego pola jest w sposób niepowtarzalny wy­ bierana podczas wysyłania pierwszego pakietu DD (I = 1), a potem jest zwiększana w sposób ciągły.

Rozdział 6. » PROTOKOŁY ROUTINGU

197

Nagłówek LSA (Link State Advertisement Header) Router może zawierać w pakiecie DD co najmniej jeden nagłówek LSA. Pola takiego ogłoszenia opisaliśmy wcześniej, w punkcie „Nagłówek LSA".

Pakiety żądania stanu łączy Pakiety żądania stanu łączy (typ 3) służą do zdobywania bieżących informacji o tra­ sach lub pobierania baz danych z konkretnego routera sąsiedzkiego. Ich format po­ kazano na rysunku 6.35. Rys u n ek 6 . 3 5 .

Pakiety żądania stanu łączy protokołu OSPF zawierają dodatkowe pola typ LS, IDstanu łączy i router ogłaszający

W ersja

D ługość pakietu

Typ = 3 ID routera ID obszaru

AuType

Sum a kontrolna

Nagłów ek pakietu OSPF

Uw ierzytelnianie

Typ stanu łączy ID stanu łączy R outer ogłaszający

Typ stanu łączy (LS Type) Pole identyfikujące typ ogłoszenia LSA. ID stanu łączy (Link State ID) Pole dokładniej opisujące ogłoszenie LSA, przydziela mu niepowtarzalny identyfikator wykorzystywany przez inne routery. Router ogłaszający (Advertising Router) Pole identyfikujące router, który pierwotnie wysłał ogłoszenie LSA.

Pakiety uaktualnienia stanu łączy Pakiety uaktualnienia stanu łączy (typ 4) są wysyłane przez routery w odpowiedzi na żądania stanu łączy. Zawierają one informacje o stanie łączy w intersieci. Jeden pakiet uaktualnienia stanu łączy może zawierać szereg ogłoszeń LSA (opisanych wcześniej, w punkcie „Nagłówek LSA"). Format takiego pakietu przedstawiono na rysunku 6.36.

1 198

TCP/IP. SZKOŁA PROGRAMOWANIA

ii

Q.

W ersja

■sr

Pakiety uaktualnienia stanu łączy protokołu OSPF zawierają dodatkowe pola liczba ogłoszeń i ogłoszenia stanu łączy

P

Rysu n e k 6 .3 6 .

D ługość pakietu ID routera Nagłów ek pakietu O SPF

ID O bszaru AuType

Sum a kontrolna

U w ierzytelnianie

—

—

Liczba O głoszeń

—

O głoszenia stanu łączy (LSA)

Liczba ogłoszeń (Number of Advertisements) Pole to określa liczbę ogłoszeń LSA, zawartych w pakiecie uaktualnienia. Ogłoszenia stanu łączy (LS Advertisements) Pole to stanowi przeważającą część pakietu uaktualnienia stanu łączy. Zawiera ono listę ogłoszeń LSA. Za nagłówkiem każdego z nich (tego samego formatu dla wszystkich) następuje jeden z sześciu typów LSA. Pełna lista ogłoszeń LSA wraz z opisem ich pól została przedstawiona wcześniej, w punktach „Działanie OSPF" i „Nagłówek LSA".

Pakiety potwierdzenia stanu łączy Pakiety potwierdzenia stanu łączy (typ 5) potwierdzają odbiór informacji o trasach. Mają format podobny do pakietu DD i zawierają listę nagłówków LSA. Format takich pakietów pokazano na rysunku 6.37. Ry su n ek 6 .3 7 .

Pakiety potwierdzenia stanu łączy protokołu OSPF udowadniają, że informacje zostały odebrane

W ersja

D ługość pakietu

Typ = 5 ID routera ID obszaru

AuType

Sum a Kontrolna

Uw ierzytelnianie

Nagłów ek ogłoszenia stanu łączy (LSA)

N agłów ek pakietu O SPF

Rozdział 6. - PROTOKOŁY ROUTINGU

19 9

Protokół IGRP Odległościowo-welctorowy protokół routingu IGRP umożliwia bramom budowanie tabel routingu przez wymianę informacji z bramami przyległymi (tzn. sąsiadam i). Informacje o trasowaniu (routingu) zawierają sumaryzację reszty sieci, co pomaga protokołowi IGRP podejmować decyzje co do wyboru najlepszej ścieżki. W przeci­ wieństwie do protokołu RIP, opierającego wybór ścieżki tylko na ilości skoków, IGRP umie podejmować decyzje odnośnie routingu w oparciu o różne metryki (mimo, że też jest uważany za protokół odległościowo-wektorowy). Korzystając z protokołu IGRP można dostosowywać szereg wartości tak, aby spełniały konkretne potrzeby danej sieci: ► Czas opóźnienia — mierzy szybkość łącza w jednostkach 10-mikrosekundowych. ► Szerokość pasma — odzwierciedla tempo przesyłu danych przez łącze, od 1200 b/s do 10 Gb/s. ► Niezawodność — przedstawiona w postaci ułamka liczby 255 (tj. 255 = 100%). ► Obciążenie — reprezentuje nasycenie łącza jako ułamek liczby 255 (tzn. 0 oznacza brak obciążenia, a 255 oznacza łącze w pełni obciążone). ► Liczba skoków — może wynosić maksymalnie 255. Opis funkcji tych metryk kosztów znajduje się w tabeli 6.8. TABELA 6.8. Metryki kosztów protokołu IGRP Miernik

Funkcja

Czas opóźnienia

Oznacza ilość czasu, jaką zajm uje sygnałowi rozprzestrzenianie się od końca do końca. Przy sieci obciążonej występuje opóźnienie dodatkowe, tym niemniej rozm iar zajętości kanału liczy się do obciążenia.

Szerokość pasma

Przedstawia szerokość pasma (w Kb/s) najwolniejszego łącza na ścieżce.

Niezawodność

Pokazuje bieżącą stopę błędów, mierząc odsetek pakietów przybyłych do celu bez uszkodzenia.

Obciążenie

W ylicza zajętość kanału w czasie, wskazując na rozm iar aktualnie użytkowanej szerokości pasma.

Ponieważ protokół IGRP umie podejmować decyzje odnośnie routingu w oparciu o różnorodne metryki, oferuje też dodatkowe funkcje: > Obsługuje większe sieci niż protokół RIP, ze względu na maksymalną liczbę skoków równą 255. ► Potrafi równoważyć obciążenie ruchu, o ile istnieją trasy równoległe. Obsługuje metryki złożone.

200

TCP/IP. SZKOŁA PROGRAMOWANIA

Jako że IGRP bierze pod uwagę różnorodne metryki, wylicza dla ścieżki jedną metrykę złożoną (com posite m etńć). Metryka taka scala wartości ważone różnych metryk w jedną liczbę, reprezentującą najlepszy koszt. Następnie IGRP wybiera najlepszą trasę w oparciu o najmniejszą metrykę złożoną (koszt). Choć protokół IGRP śledzi też dwie informacje dodatkowe — liczbę skoków i jed­ nostkę MTU (tzn. maksymalny rozmiar pakietu, który może przemieszczać się wzdłuż całej ścieżki bez fragmentacji) — nie stosuje ich do obliczania kosztu. Mimo że potrafi łączyć i podawać dalej różne wartości, domyślnie wykorzystuje tylko opóźnienie i szerokość pasma. Chcąc oddziaływać na wybór ścieżki, można zmieniać którąkolwiek z tych wartości. Szerokość pasma ma wyższy priorytet, a routeiy korzystają z niej podczas oblicza­ nia algorytmów routingu. Wartość ta nie wpłyrwa jednak na ilość danych, którą mo­ że obsługiwać konkretne łącze. Z drugiej strony oddziałuje jednak bezpośrednio na wybór ścieżki, trzeba więc dokładnie ją określać w sposób odzwierciedlający fak­ tyczne tempo przesyłu danych przez łącze. Wartość niewłaściwa może spowodo­ wać wybór przez routery błędnych ścieżek przekazywania danych.

Sieci IGRP Sieć IGRP obejmuje pojedynczą domenę routingu, identyfikowaną przez numer systemu autonomicznego. Zasadniczo, każdy system autonomiczny jest zarządzany i kontrolowany przez jedną firmę, a każdy system autonomiczny jest uważany za odrębny od innych. Routery ze skonfigurowanym protokołem IGRP współdzielą jeden numer systemu autonomicznego (przypisywany przez administratora), umożliwiający im wymianę informacji o trasach. W tym kontekście wyrażenie system autonomiczny oznacza domenę routingu IGRP i wszystkie zawarte w niej routery. Choć firma może w swoim systemie autonomicznym korzystać także z innych protokołów routingu typu IGP, numer tego systemu autonomicznego definiuje tylko domenę routingu IGRP w obrębie większego systemu. Na przykład sieć dużego przedsiębiorstwa, rozciągniętą na wiele kontynentów oraz zawierającą wiele routerów i łączy, można podzielić na wiele systemów autonomicz­ nych. Kierowałyby one ruch uaktualniający w oparciu o wyraziste domeny. Routery jednej domeny współdzieliłyby te same informacje sieciowe i dostosowywałyby się do występujących w niej zmian, nie odczuwając zmian tras z innych domen. Definiowanie granic zmniejsza ilość ruchu uaktualniającego w obrębie domeny, zwiększając wydajność użytkowania szerokości pasma przez trzymanie uaktual­ nień międzydomenowych z dala od krytycznych odcinków szkieletowych i mniej szybkich łączy WAN. Powoduje też, że odległe awarie są niezauważalen dla pozo­ stałych domen, na przykład awaria trasy w Japonii nie wpływa na routery w San Francisco.

Rozdział 6. • PROTOKOŁY ROUTINGU

201

Stabilność sieci Protokół IGRP zapewnia stabilność sieci za pomocą wielu technik. Podobnie do pro­ tokołu RIP stosuje okresowe rozgłoszenia, a w sieciach nierozgłoszeniowych uaktu­ alnienia wyzwalane, zaś pętlom routingu zapobiega w oparciu o powstrzymywanie, dzielony horyzont, odtrutkę i liczenie do nieskończoności (= 256). Jako protokół routingu klasowego, nie obsługuje podziału na podsieci. Poza tym stabilność sieci zapewnia r o u t i n g w i e l o ś c i e ż k o w y (;m u l t i p a t h r o u t i n g ) . Zwiększa on elastyczność trasowania, umożliwiając dzielenie ruchu między łącza nadmiarowe o podobnych lub prawie podobnych metrykach, czego skutkiem jest równoważenie obciążenia. Routing wielościeżkowy dostarcza też możliwości au­ tomatycznego przełączania na drugie łącze w sytuacji, gdy jedno stanie się niedo­ stępne.

Czasomierze IGRP Protokół IGRP posiada kilka czasomierzy kontrolnych, określających jego działanie (por. tabela 6.9). Sterują one propagacją i wygasaniem tras. Choć mają ustawienia domyślne, można je zmieniać. TABELA 6.9. Czasomierze IGRP Czasomierz

Funkcja/Ustawienie domyślne

Uaktualniania

Definiuje przedział czasu występujący m iędzy uaktualnieniam i tras. W artość domyślna wynosi 9 0 sekund.

Nieważności

Określa czas oczekiwania przez router pod nieobecność kom unikatu z uaktualnieniem trasy, zanim zadeklaruje on jej nieważność. W artość dom yślna wynosi 2 7 0 sekund (trzy razy czasomierz uaktualniania).

Powstrzymywania

Wyszczególnia okres przetrzym ywania dla celu nieosiągalnego. Router w tym okresie nie przyjm uje uaktualnień dotyczących takiego celu. W artość domyślna wynosi 2 8 0 sekund (trzy razy czasomierz uaktualniania plus 10).

Usuwania

W skazuje na ilość czasu, która powinna upłynąć przed usunięciem wadliwej trasy z tabeli routingu. W artość domyślna wynosi 6 3 0 sekund (siedem razy czasomierz uaktualniania).

Rów now ażenie i podział obciążenia Protokół IGRP potrafi wysyłać ruch ścieżkami nadmiarowymi, dzieląc jego stru­ mień między łącza o kosztach równych lub nierównych — jest to tzw. r ó w n o w a ż e ­ n i e o b c i ą ż e n i a ( l o a d b a l a n c i n g ) . Umożliwia ono maksymalne użytkowanie szeroko­ ści pasma łączy prowadzących do ośrodka docelowego. Gdy nie skonfiguruje się nierównokosztowego równoważenia obciążenia, IGRP będzie równoważył ruch tylko ścieżkami o kosztach równych. Protokół ten nie obsługuje natomiast masek typu VLSM.

202

TCP/IP. SZKOŁA PROGRAMOWANIA

Protokół EIGRP EIGRP, własny protokół routingu firmy Cisco, łączy zalety protokołów łączowostanowych i odległościowo-wektorowych. Z tego powodu jest uważany za zrów­ noważony p rotokół hybrydow y. Oto niektóre jego cechy charakterystyczne: ► Zapewnia szybszą zbieżność, natychmiast wysyłając uaktualnienia częściowe. ► Obsługuje VLSM-y, włączając maski podsieci do uaktualnień. ► Obsługuje wiele stosów protokolarnych, w tym TCP/TP, IPX/SPX i AppleTalk. ► Przechowuje w tabelach routingu ścieżki zapasowe. ► Obsługuje opcje ToS protokołu IP. ► Wykorzystuje metryki oparte na kosztach, podobnie do protokołu IGRP. ► Zachowuje ścieżki zapasowe gdy istnieje wiele tras. ► Korzysta z multiemisji i monoemisji.

Działanie EIGRP Gdy router EIGRP przejdzie przez początkowe uruchomienie, otrzymuje od swoich sąsiadów kopie tabel routingu. Po wykryciu zmian wysyła im tylko uaktualnienia częściowe. Dzięki temu użytkowanie szerokości pasma jest mniejsze, a wydajność większa. EIGRP jest korzystającym z jednego protokołu routingu rozwiązaniem dla sieci wieloprotokołowych (np. IP, IPX i AppleTalk). Daje to spore korzyści firmom po­ siadającym takie sieci, gdyż nie muszą one stosować oddzielnego protokołu routin­ gu dla każdego z protokołów komunikacyjnych (co znacznie zwiększałoby ilość ru­ chu uaktualniającego, służącego do poznawania i konserwowania tras). Jedyną wadą protokołu EIGRP jest wymóg korzystania z routerów Cisco, chyba że obsłu­ guje go jakiś router firmy trzeciej. Protokół EIGRP przechowuje bardzo dokładną mapę topologii (tzn. bazę danych stanu łączy), a do wyliczania zmian i unikania pętli routingu stosuje algorytm DU­ AL (Diffusing Update AlgorithmJ. Pętlom zapobiega odwołując się do kopii tabel routingu sąsiadów i korzystając ze szczegółowej mapy topologii. Ze względu na brak pętli routingu i stosowanie uaktualnień wyzwalanych, zbież­ ność w sieciach EIGRP jest bardzo szybka. Poza tym dla każdej trasy protokół EIGRP wysyła maskę podsieci, co pozwala mu obsługiwać VLSM-y (jest protoko­ łem routingu bezklasowego). Podobnie do protokołu IGRP, EIGRP definiuje swoją domenę routingu (obejmującą wszystkie routery i sieci w jej obrębie z włączonym protokołem EIGRP) za pomocą

Rozdział 6. • PROTOKOŁY ROUTINGU

203

numeru systemu autonomicznego. Wymieniać informacje mogą tylko routery EIGRP współdzielące ten sam numer (uważane za część jednej domeny). Między systemami autonomicznymi o różnych numerach wymiana nie jest możliwa. Ad­ ministrator przypisuje numer całkiem dowolnie, włączając i konfigurując protokół EIGRP na pierwszym routerze domeny. Po jego przypisaniu pozostałe routery systemu autonomicznego muszą współdzielić tę samą wartość. Routery EIGRP jednego systemu autonomicznego muszą najpierw odkryć swoje routery sąsiedzkie (tj. bezpośrednio podłączone do tego samego segmentu lokalne­ go lub łącza WAN). Identyfikując swoich sąsiadów routery mogą wykrywać także routery niedostępne, tym samym wykrywając awarie sieci. Pozwala im to na szybką reakcję i dostosowanie wyboru ścieżek. Procesem odkrywania sterują pakiety Hello. Routery odkrywają swoje routery są­ siedzkie tworząc i przechowując tabelę sąsiadów (tabelę przylegania), zawierającą listę wszystkich poznanych w ten sposób routerów. Po zbudowaniu tabel sąsiadów, routery mogą zacząć wymieniać z nimi informacje o trasach. Choć protokół EIGRP nie jest połączeniowy, próbuje jednak gwarantować doręcza­ nie i odbiór uaktualniających danych w oparciu o wartości kolejne, zawarte w czę­ ści nagłówkowej swoich datagramów. Odbiorcy muszą potwierdzać odbiór infor­ macji o trasach. Jeśli odbiorca nie wyśle potwierdzenia, nadawca retransmituje uaktualnienie. Urządzenie wysyłające śledzi numery kolejne uprzednio wysłanych uaktualnień, zapewniając uwzględnienie wszystkich potwierdzonych uaktualnień.

Trasy: spadkobierca i dopuszczalny spadkobierca Protokół EIGRP potrafi przechowywać w tabeli routingu wiele tras do jednego celu. Trasa najlepsza (tzn. o najniższym koszcie, domyślnie opartym na szerokości pasma i opóźnieniu) nosi nazwę następnika (successor), a druga w kolejności (zapasowa) — m ożliwego następnika (feasible successor). Routery EIGRP poznają te trasy uruchamiając algorytm DUAL na mapie topologii, zbudowanej podczas procesu odkrywania sąsiadów (najpierw odkrywają sąsiadów, po czym tworzą te mapy wymieniając informacje uaktualniające). Wykonując ten algorytm dla każdej obecnej w mapie trasy do celu, tworzą lokalną tabelę routingu z informacjami następującymi: ► następnikiem i możliwym następnikiem; ► interfejsem lokalnym; ► adresem routera następnego skoku, służącym do przekazywania ruchu do celu. Przechowując w tabeli routingu ścieżki zapasowe, routery EIGRP mogą szybko pro­ mować możliwego następnika na następnika, gdy ten ostatni staje się niedostępny. Umożliwia to routerowi dalsze kierowanie ruchu do danego celu. W międzyczasie

204

TCP/IP. SZKOŁA PROGRAMOWANIA

może on czynnie pytać swoich sąsiadów o nowego możliwego następnika. Dzięki temu routery EIGRP mogą szybko wykrywać i poprawiać wszystkie ścieżki, które zawiodły. Protokół EIGRP przechowuje oddzielną kopię każdej z wyżej wymienionych tabel dla każdego głównego pakietu protokołów, dla którego przeprowadza routing (np. TCP/IP, IPX/SPX czy AppleTalk). Osiąga to uruchamiając oddzielne procesy routingu dla każdego z nich. Jeśli zatem w sieci działają wszystkie te trzy stosy protoko­ łów (por. rysunek 6.38), routery EIGRP mają trzy oddzielne bazy przylegania i ma­ py topologii, a także tabele routingu. W takim przypadku router ma dziewięć baz danych, po trzy dla każdego protokołu (bazę danych sąsiadów, bazę danych topo­ logii i bazę danych routingu). Do obsługi takiej ilości map i tabel potrzeba dużo za­ sobów i mocy obliczeniowej. Normalnie na każdym routerze trzeba byłoby uru­ chamiać trzy różne protokoły routingu, oddzielne dla TCP/IP, IPX/SPX i AppleTalk, z których każdy musiałby oddzielnie śledzić routowany (trasowany) protokół. Ta­ kie rozwiązanie istotnie zwiększałoby ilość ruchu rozgłoszeniowego i multiemisyjnego, generowanego przez każdy wdrożony protokół routingu. Rys u n e k 6 .3 8 .

Wszystkie routery EIGRP w obrębie jednego systemu autonomicznego muszą przechowywać trzy oddzielne bazy danych dla każdej rodziny protokołów, którą trasują

Tabele EIGRP

r Rozdział 6. • PROTOKOŁY ROUTINGU

205

Typy pakietów EIGRP Protokół EIGRP stosuje pięć różnych typów pakietów, umożliwiających routerom wymianę wiadomości z innymi routerami na temat stanu ich systemu autonomicznego: > Hello/ACK — wysyłane jako ogłoszenia multiemisyjne. Pakiety Hello służą ro­ uterom EIGRP do budowania tabeli przylegania. Niektóre pakiety Hello — po­ twierdzenia (ACK) — nie zawierają danych i zawsze są wysyłane jako datagramy monoemisji (skierowane). > Uaktualnienia — wysyłane przez routery celem wymiany informacji o trasach. W oparciu o zebrane w ten sposób informacje routery tworzą mapy topologicz­ ne intersieci. Uaktualnienia zawsze zawierają numery kolejne. Są wysyłane jako datagramy multiemisji lub monoemisji. > Zapytania (Queries) — wysyłane do sąsiadów przez router, który nie ma do­ stępnego następnika lub możliwego następnika, bądź chce wybrać nowego. Są wysyłane jako datagramy multiemisji (do wszystkich sąsiadów) lub monoemisji (do konkretnego sąsiada). > Odpowiedzi — wysyłane przez routery w odpowiedzi na zapytania sąsiadów. Zawsze są wysyłane jako datagramy monoemisji. > Żądania — wysyłane do wszystkich sąsiadów przez router włączany po raz pierwszy. Żądają pełnej listy wszystkich miejsc przeznaczenia, celem zbudowania własnej tabeli routingu. Mogą też żądać konkretnych informacji od określonego sąsiada. Zależnie od tych dwóch opcji, są wysyłane jako datagramy multiemisji lub monoemisji.

Protokół BGP Protokoły dotychczas opisane w bieżącym rozdziale (tj. typu IGP) stosują częste uaktualnienia i inne metody propagacji tras, są więc niezdolne do obsługi bardzo dużych środowisk. Poza tym zasadniczo są wykorzystywane przez firmy w obrębie jednego systemu autonomicznego czy też intersieci firmowej. Eksplozja Internetu stworzyła zapotrzebowanie na BGP: niezawodny, silny i oparty na regułach proto­ kół typu EGP, zapewniający bezpętlowy routing międzydomenowy. Dokument RFC 1771 definiuje czwartą, aktualną wersję protokołu BGP (BGP w.4), jako protokół routingu między systemami autonomicznymi. Jest to podstawowy protokół w Internecie, obsługujący tranzyt ruchu wielką superautostradą. Rozszerze­ nia wersji 4 — maski VLSM i bezklasowy routing międzydomenowy (CIDR, tj. łączenie w nadsieć) — umożliwiły protokołowi BGP obsługę rozrastającego się w wykładniczym tempie Internetu. Większość firm podłączających się do Internetu nie musi korzystać z protokołu BGP. Jeśli organizacja ma tylko jedną bramę łączącą jej intersieć ze światem zewnętrznym

206

TCP/IP. SZKOŁA PROGRAMOWANIA

(tzn. jeden punkt wyjścia), zwykle może ograniczyć się do trasy domyślnej. Dzięki temu cały ruch przeznaczony dla nieznanych sieci będzie przekazywany ścieżką domyślną, obsługiwaną przez bramy usługodawcy internetowego tej firmy, uczest­ niczącego w sieci BGP. Zastosowanie trasy domyślnej likwiduje obciążenie ruchem uaktualniania tras i uwalnia zasoby bramy, niezbędne do przechowywania i obsługi wszystkich tras w Internecie. Protokół BGP powinno się wdrażać w następujących sytuacjach: > Gdy istnieje wiele punktów wyjścia, łączących z jednym ISP (do podziału obcią­ żenia). > Gdy istnieje wiele ścieżek do różnych ISP i chciałoby się dyktować sposób prze­ kazywania ruchu tymi łączami. > Gdy wykorzystywane zasady, czy też metody routingu są różnorodne bądź wy­ kraczają poza uproszczone stosowanie trasy domyślnej (tzn. potrzebny jest in­ teligentny wybór ścieżki i specyficzne kryteria). > Jeśli infrastruktura sieci służy za obszar tranzytowy ruchu sieciowego innej or­ ganizacji.

Protokoły IGF versus protokoły EGP Routery BGP poznają i przechowują informacje o wszystkich sieciach docelowych w Internecie i ścieżkach prowadzących do tych sieci przez systemy autonomiczne. Po osiągnięciu ostatecznej sied przez ruch siedowy, przekazywanie trasami lokalnymi w systemie autonomicznym biorą na siebie protokoły IGP (RIP, IGRP, EIGRP i OSPF). BGP, jako protokół typu EGP, łączy ze sobą niezależne systemy autonomiczne. Numery tych systemów, przypisywane przez rejestr ARIN, definiują domeny ro­ utingu BGP. Numer przypisany organizacji reprezentuje główny skok (tj. obszar tranzytowy) w Internecie. W każdym systemie autonomicznym może działać wiele protokołów IGP, ale ich liczba i typy są nieistotne i przezroczyste dla protokołu BGP. Choć protokół ten może spełniać rolę IGP, prawie wyłącznie jest stosowany jako EGP. Dzisiejszy Internet składa się z wielu obszarów tranzytowych, kontrolowanych przez różne organizacje, z których żadna nie panuje nad nimi wszystkimi. Ogrom i brak centralnego zarządzania Internetem stworzyły zapotrzebowanie na protokół BGP. Obecnie w Internecie istnieje ponad 105 000 tras. Każdy router BGP w Internecie musi poznawać i przechowywać informacje o nich oraz przeprowadzać inteligent­ ny wybór ścieżek umożliwiających przekazywanie datagramów przez Internet, nie mówiąc o zasobach (takich jak pamięć i czas procesora) koniecznych do obsługi tych informacji. Przy tak wielu trasach, obszarach tranzytowych i rozmaitych ścież­ kach prowadzących przez ten labirynt sieci połączonych, protokół BGP musi posia­ dać umiejętność wykrywania i poprawiania błędów (np. niedziałających sieci lub pętli routingu).

Rozdział 6. - PROTOKOŁY ROUTINGU

207

Źródła bieżących numerów tabel routingu Internetowego Inform acje o bieżących tabelach routingu Internetowego można znaleźć w nastę­ pujących źródłach: >

httpj/antc. uoregon. edu/route-views/dynamics-,

>

h ttp-.Hwww. mcvax. org/~jhma/routing/bgp-hist. html\

> http://www.apnic.net/stats/bgp/TOTAL/totalann.html. Ponieważ protokół BGP musi umieć wykrywać i rozwiązywać problemy sieciowe, potrafi on wylduczać pętle routingu. Protokół ten (w wersji 4) można implemento­ wać na dwa sposoby: > Pełnej kraty (Fułl mesh) — w topologii takiej konieczne są oddzielne połączenia logiczne TCP między wszystkimi routerami BGP w obrębie tego samego systemu autonomicznego, umożliwiające bramom szybkie stwierdzanie istnienia pętli i ich wycinanie. > Częściowej kraty (Partial mesh) — w topologii takiej nie jest konieczne, aby wszystkie routery utrzymywały między sobą połączenia logiczne. Dzięki temu liczba połączeń TCP jest mniejsza, ale otwiera się możliwość powstawania pętli routingu. BGP ma jedną inną odróżniającą go od pozostałych protokołów routingu cechę, gwarantującą niezawodność: w oparciu o protokół TCP zapewnia połączeniowy, niezawodny transport własnego ruchu uaktualnień. Wszystkie protokoły IGP są bezpołączeniowe — aby przekazywać informacje do innych bram, nie potrzebują połączeń logicznych. Protokoły te na ogół wysyłają uaktualnienia jako rozgłoszenia albo multiemisje, choć niektóre jako monoemisje (datagramy skierowane). Bez względu na metodę robią to za pośrednictwem protokołów bezpołączeniowych, takich jak IP i UDP. Protokół BGP gwarantuje niezawodne dostarczanie danych, działając za pośred­ nictwem logicznej sesji TCP, sekwencjonującej (ustawiającej po kolei) i potwierdza­ jącej każdą ich wymianę między partnerami BGP. Protokół ten korzysta z portu 179 protokołu TCP. BGP w.4, w przeciwieństwie do poprzednich wersji, obsługuje routing bezklasowy, podczas opisywania miejsc przeznaczenia włączając maski pod­ sieci do uaktualnień tras — są to tzw. inform acje o osiągalności sieci (network reachability informatioń). Też inaczej niż wcześniejsze wersje, BGP w.4 obsługuje sumaryzację tras (tzn. scalanie wielu adresów IP w ogłoszenie jednej trasy).

Routery BGP Routery umieszczone w różnych obszarach sieci BGP noszą różne nazwy, określające ich typ:

208

TCP/IP. SZKOŁA PROGRAMOWANIA

> Routery-nadajniki BGP (BGP speaker routers) — są to routery BGP. i> Routery partnerskie (Peer) lub sąsiedzkie (neighbor routers) — są to routery łą­ czące ze wspólnym odcinkiem. > Wewnętrzne routery partnerskie (Internal peer routers) — są to partnerzy w obrębie tego samego systemu autonomicznego. > Zewnętrzne routery partnerskie (External peer routers) — są to sąsiedzi BGP z różnych systemów autonomicznych. Jeśli na przykład system autonomiczny numer 100 (AS 100) składa się z trzech bram skonfigurowanych w topologii pełnej kraty, każdy z routerów będzie miał połącze­ nia TCP z pozostałymi i będzie tworzył relację wewnętrznego BGP (Internal BGP, IBGP) ze swoimi sąsiadami z tego systemu autonomicznego. Brama łącząca AS 100 z innym systemem autonomicznym — np. AS 200 — utworzy relację zewnętrznego BGP (External BGP, EBGP) z bramą tego innego systemu. Typ relacji sąsiada z jego partnerem — wewnętrzny czy zewnętrzny — definiuje reguły wymiany (por. ry­ sunek 6.39). Rys u n ek 6 .3 9 .

Reguły wymiany zależą od typu relacji routera z jego partnerem

W ie le p o łą c z e ń BG P z je d n y m ISP

1ebqp

| EBGP~

Wszystkie routery BGP mają jakiś typ relacji partnerskich z innymi routerami. Zale­ ży on od tego, w jakim samym systemie autonomicznym znajdują się routery . Dwa routery łączące różne systemy autonomiczne są partnerami zewnętrznymi, a routery w obrębie tego samego systemu autonomicznego — wewnętrznymi. Routery należące do tego samego systemu autonomicznego są nazywane IBGP-ami. Sąsiedzi IBGP nie mogą ogłaszać informacji o trasach poza swoimi lokalnymi part­ nerami (sąsiadami). Routery należące do różnych systemów autonomicznych są nazywane EBGP-ami. Sąsiedzi EBGP mogą przekazywać wszystkimi interfejsami poznane informacje o trasach pozostałym sąsiadom.

Rozdział 6. • PROTOKOŁY ROUTINGU

209

Działanie BGP Włączając protokół BGP na bramie, przypisujemy jej numer systemu autonomicz­ nego do którego ona należy. Poza tym na nadajniku BGP konfigurujemy adresy IP wszystkich jego partnerów. Uaktywniany nadajnik musi ustanowić połączenia TCP ze wszystkimi swoimi partnerami (wewnętrznymi i zewnętrznymi), umożliwiające wymianę z nimi informacji BGP. Ustanowiona sesja TCP pozwala partnerom BGP na wymianę informacji o osiągalnośd, tworzących ich tabele routingu. Protokół BGP wykorzystuje te informaqe do tworzenia bezpętlowej mapy systemu autonomicznego. Po początkowej wymianie całej tabeli, partnerzy wymieniają tylko zmiany. Wszyst­ kie wymiany śledzi protokół TCP za pomocą sekwencjonowania i potwierdzania. Stosuje on komunikaty utrzymywania przy życiu (keepalives) do podtrzymywania połączeń między partnerami BGP nie wymieniającymi informacji w sposób czynny. Gdy protokół BGP napotka błąd, wygeneruje komunikat powiadomienia, powo­ dujący zakończenie sesji między partnerami. Jeśli zawiedzie sesja TCP, zawiedzie też protokół BGP. Routery BGP nie przechowują informacji o trasach w tej samej tabeli routingu, co poznane trasy IGP. W zależności od dostawcy, mogą one utrzymywać maksymal­ nie trzy dodatkowe tabele routingu lub łączyć je w jedną. Bez względu jednak na liczbę posiadanych tabel, każdy mówca BGP musi rozróżniać następujących dane: > otrzymane informacje o trasach (tj. uaktualnienia); > informacje o trasach przeznaczone do ogłoszenia; > lokalną tabelę routingu BGP. Nadajniki BGP za pomocą wymiany uaktualnień uprzedzają partnerów o zmianach w trasach docelowych. Gdy jakaś trasa staje się niedostępna, wówczas nadajnik ogłasza w uaktualnieniu wysyłanym do sąsiadów, że planuje wycofać tę trasę z ob­ sługi, więc powinni usunąć ją ze swoich tabel. Jeśli nadajnik BGP rozporządza lepszą ścieżką do jakiegoś celu, ogłasza tę nową ścieżkę wraz z atrybutami. Odbiorcy zastępują wówczas starą trasę nową. W przeciwieństwie do wszystkich protokołów IGP, protokół BGP wybierając ścieżkę nie stosuje metryk, takich jak skoki, opóźnienie, szerokość pasma, niezawodność, obciążenie ani MTU. Zamiast nich do wyboru najlepszej ścieżki prowadzącej do celu wykorzystuje w hierarchiczny sposób atrybuty ścieżki (patii attributes). (Atrybuty BGP dokładnie omówimy w dalszej części rozdziału).

N agłów ek BGP Wszystkie datagramy BGP zaczynają się wspólnym dziewiętnastobajtowym na­ główkiem. Format całego nagłówka pokazano na rysunku 6.40.

210

TCP/IP. SZKOŁA PROGRAMOWANIA

Ry su n e k 6 .4 0 .

Wszystkie datagramy BGP mają ten sam początkowy nagłówek

—

—

-

Z n a czn ik

_

_ II o_

D łu g o ść

K o m u n ika t O T W A R C IA , U A K T U A LN IE N IA , P O W IA D O M IE N IA lub U T R Z Y M Y W A N IA P R Z Y Ż Y C IU

Znacznik (Marker) Pole o maksymalnie szesnastobajtowej zawartości, identyfikujące początek otwar­ tego żądania między partnerami i stosowane uwierzytelnianie BGP.

Długość (Length) Dwubajtowe pole, identyfikujące długość w bajtach datagramu BGP (w tym na­ główka).

Typ (Type) Jednobajtowe pole, identyfikujące typ komunikatu BGP wysyłanego przez router. Możliwe są cztery typy komunikatów: l> 1 = Otwarcie (Open); > 2 = Uaktualnienie (Update); > 3 = Powiadomienie (Notification); > 4 = Utrzymywanie przy życiu (Keepalive). Typ komunikatu wpływa na resztę nagłówka BGP. Typy te wraz z formatami na­ główków omawiamy w kolejnych punktach.

Komunikaty otwarcia Routery BGP wysyłają komunikaty otwarcia tuż po ustanowieniu połączenia part­ nerskiego na porcie 179 protokołu TCP. Pierwszy komunikat BGP inicjuje relację partnerską BGP między partnerami wewnętrznymi lub zewnętrznymi. Format ko­ munikatu otwarcia BGP pokazano na rysunku 6.41. W komunikacie otwarcia za nagłówkiem BGP znajduje się sześć innych pól, opisa­ nych w tabeli 6.10.

Rozdział 6. • PROTOKOŁY ROUTINGU

Rys u n ek 6 .4 1 .

Nagłówek kom unikatu BGP 4

Znacznik

-

« IGP — poznane poprzez inform acje o osiągalności sieci, wewnętrzne wobec systemu autonom icznego (AS) routera pochodzenia; > EGP — poznane poprzez EGP; > Niezupełne (Incomplete) — poznane z nieznanego źródła.

Rozdział 6. • PROTOKOŁY ROUTINGU

215

TABELA 6.14. Kody typów atrybutów ścieżek BGP (ciąg dalszy) Kod Typu

Kategoria

Opis

2 — AS_path (ścieżka AS)

Powszechnie znany obowiązkowy

Zawiera listę system ów autonom icznych, opisujących ścieżkę do danego celu. Na przykład sieć docelowa 1 9 2 .1 5 .2 .0 może m ieć ścieżkę AS rów ną 1 0 0 - 3 0 0 -8 0 0 , czyli dotarcie do niej będzie obejm ować trzy skoki przez systemy autonom iczne. Gdy routery system ów autonom icznych (tj. partnerzy EBGP) przekazują między sobą inform acje o trasach, router przekazujący uaktualnienie nowemu systemowi AS dodaje do ścieżki własny AS. U m ożliw ia to nadajnikom BGP Identyfikację ścieżki system ów autonom icznych, którą inform acja o trasie przeszła przez Internet.

3 — Next_Hop (Następny skok)

Powszechnie znany obowiązkowy

Identyfikuje adres IP routera następnego skoku czy też bramy granicy, sfużącego(-ej) do osiągnięcia celu.

4 — M ulti-Exit-Descriptor (Deskryptor wielu punktów wyjścia)

Opcjonalny nieprzechodni

Um ożliw ia routerom systemu AS w pływ anie na decyzje o trasow aniu, podejm owane przez routery innego systemu AS. Gdy istnieje wiele punktów wyjścia, łączących ze sobą dwa systemy AS, routery jednego z nich m ogą ogłaszać zewnętrznemu routerowi sąsiedzkiemu drugiego z nich różne wartości MED (M uIti-E xit-D escriptor). Im niższa wartość, tym lepsza ścieżka. Ogłaszanie różnych wartości powoduje, że routery będą preferowały jedną ścieżkę od innych. Jest to jedyny atrybut zapew niający tę funkcję (rysunek 6 .4 5 ).

5 — Local Preference (Preferencja lokalna)

Powszechnie znany uznaniowy

W ykorzystywany tylko przez routery w obrębie jednego systemu AS (nie jest propagowany do innych AS). Gdy istnieje wiele ścieżek kierowania ruchu na zewnątrz danego AS, routery w nim zawarte mogą podwyższać wartość LP (Local Preference) dla różnych ścieżek, wskazując w ten sposób trasy preferowane. Routery wewnętrzne będą wówczas przekazywały ruch sieciow y ścieżką o najwyższej preferencji (rysunek 6 .4 6 ).

6 — A tom ic_ Aggregate (Agregat atomowy)

Powszechnie znany uznaniowy

W artość ustawiana tylko gdy adm inistrator skonfiguruje sum aryzację tras. Ustawia ją router, od którego pochodzi sumaryzacja. Jest zawierana w ogłoszeniach, uprzedzając inne routery BGP o tym , że ogłaszana trasa reprezentuje mniej szczegółową sum aryzację innych tras, nie identyfikowanych w obrębie uaktualnienia.

7 — Aggregator

Opcjonalny przechodni

W artość ustawiana tylko gdy jest ustawiona wartość poprzednia. Identyfikuje system AS i router, od którego pochodzi sumaryzacja.

(Agregator)

216

TCP/IP. SZKOŁA PROGRAMOWANIA

Rys u n ek 6 .4 5 .

M ED (D e s k ry p to r w ie lu p u n k tó w w y jś c ia )

Atrybut MED wpływa na decyzje o routingu między systemami autonomicznymi (AS). Na przykład jeśli usługodawca ISP utrzymuje wiele ścieżek łączących go z mniej ważnym AS („w dół” czy też „z prądem” Internetu), może on na swoich routerach skonfigurować różne wartości MED, wpływające na ścieżkę wysyłania ruchu przez routery systemu położonego „z prądem" Rys u n e k 6 .4 6 .

Atrybut preferencji lokalnej jest propagowany jedynie w obrębie systemu autonomicznego (AS), wyznaczając preferowaną ścieżkę do celu w przypadku dostępności wielu ścieżek. W tym przypadku AS 300 posiada wiele ścieżek wyjściowych, łączących go poprzez AS 100 i AS 200. Routery będą wybierać jako ścieżkę wyjściową ścieżkę o najwyższej preferencji lokalnej, czyli prowadzącą przez skrajny lewy router (LP = 200)

P re fe re n c ja lo k a ln a

Tra sa p refe ro w a na

Rozdział 6. • PROTOKOŁY ROUTINGU

217

BGP w.3 a BGP w.4 Protokoły BGP w.3 (RFC 1267) i BGP w.4 nie potrafią działać łącznie. Można nato­ miast skonfigurować routery tak, aby obsługiwały je na oddzielnych interfejsach, tworząc w ten sposób środowisko mieszane. Krótką listę różnic między dwoma wersjami protokołu BGP zawiera tabela 6.15. TABELA 6.15. Porównanie protokołów BGP w.3 i BGP w.4 Cecha charakterystyczna

BGP w.3

BGP w .4

Obsługa VLSM (tzn. routingu bezklasowego). Zawieranie masek podsieci w uaktualnieniach.

Nie

Tak

Obsługa sumaryzacjl.

Nie

Tak

Krata pełna czy częściowa?

Pełna

Obie

Obsługa atrybutów : preferencja lokalna, agregat_atom owy i agregator.

Nie

Tak

Podsumowanie Protokoły routingu pozwalają routerom dynamicznie poznawać ścieżki prowadzące do celów i przystosowywać się do zmian w topologii sieciowej. Bez względu na uży­ wany protokół routingu, zamierzenia są takie same: przekazywać datagramy do celu. RIP jest protokołem odległościowo-wektorowym (wektora odległości). Tak jak wszystkie protokoły tego typu, do wybierania najlepszej ścieżki stosuje metrykę odległości (liczoną w skokach). Opiera się na rozgłaszaniu, jest protokołem typu IGP, najlepiej działa w małych sieciach, wykorzystuje algorytm odległościowo-wektorowy. Posiada dwie wersje: RIP w .l i RIP w.2. Protokół OSPF wykorzystuje algorytm łączowo-stanowy (stanu łączy), podejmując odnośnie trasowania (routingu) bardziej inteligentne decyzje niż RIP. Tak jak wszystkie protokoły stanowe, OSPF bierze pod uwagę metryki wybrane spośród następujących: pojemność łącza (szerokość pasma), opóźnienie, niezawodność, ob­ ciążenie i MTU. OSPF ma szereg przewag nad protokołami odległościowo-wektorowymi, ale wciąż najbardziej popularnym protokołem routingu pozostaje RIP, głównie ze względu na swoją prostotę. Odległościowo-wektorowy protokół IGRP, podobnie do OSPF, umożliwia bramom budowanie tabel routingu przez wymianę informacji z bramami przyległymi (tj. są­ siadami). Inaczej niż RIP (też odległościowo-wektorowy), IGRP do wyboru najlep­ szej ścieżki stosuje różnorodne metryki, tworząc tzw. metrykę złożoną. Bierze on pod uwagę szerokość pasma, opóźnienie, niezawodność i obciążenie, zapewniając obsługę sieci dużych i równoważenie obciążenia.

218

TCP/IP. SZKOŁA PROGRAMOWANIA

Uważany za protokół hybrydowy, EIGRP łączy zalety protokołów routingu łączowo-stanowego i odległościowo-wektorowego. RIP, OSPF, IGRP i EIGRP są proto­ kołami typu IGP. Wraz z eksplozją sieci Internet powstało zapotrzebowanie na niezawodny, silny i oparty na regułach protokół, wystarczająco elastyczny, by obsłużyć wciąż zmie­ niający się Internet. Odpowiedzią okazał się być protokół BGP. Jest on protokołem typu EGP, opierającym wybór ścieżki na jej atrybutach. Rozszerzenia wersji 4 (BGP w.4) — obsługa VLSM-ów, scalanie tras i CIDR — umożliwiły mu stanie się pod­ stawowym protokołem Internetu. Podsumowanie charakterystycznych cech różnych protokołów routingu, omawianych w tym rozdziale, zawiera tabela 6.16. TABELA 6.16. Podsumowanie charakterystycznych cech protokołów routingu Cecha

RIP w .l

RIP w.2

OSPF

IGRP

EIGRP

BGP

Typ protokołu

odległościowo-wektorowy

odległościowo-wektorowy

łączowo-stanowy

odległościowo-wektorowy

hybrydowy

ścieżkowo-wektorowy

Max liczba skoków

15

15

nie dotyczy

1 0 0 -2 5 5

nie dotyczy

nie dotyczy

Uaktualnienia

co 30 sekund

co 30 sekund

wyzwalane

co 90 sekund

wyzwalane

nie dotyczy

Typ transmisji

rozgłaszanie

rozgłaszanie

multiemisja

rozgłaszanie

multiemisja

monoemisja

Wysyłana tabela

cała

cała

tylko zmiany

cała

tylko zmiany tylko zmiany

Typ routingu

klasowe

bezklasowe

bezklasowe

klasowe

bezklasowe

bezklasowe

Metryka podstawowa

skoki

skoki

szerokość pasma

szerokość pasma i opóźnienie

szerokość pasma i opóźnienie

atrybuty ścieżki

Obsługa ToS/QoS nie

nie

tak

tak

tak

tak

Typ połączenia

UDP

UDP

UDP

UDP

TCP

UDP

Pytania sprawdzające 1. Za jakiego rodzaju protokół routingu jest uważany RIP? 2. Jakie są niektóre cechy charakterystyczne RIP-a? 3. Jaką metrykę stosuje RIP przy wyborze najlepszej ścieżki? 4. Jak często RIP wysyła swoje rozgłoszenia i co w nich się znajduje? 5. De pozycji może wysyłać RIP w swoich rozgłoszeniach? 6. Ile skoków może wykonać datagram dla protokołu RIP w .l, gdy cel jest uważany za nieosiągalny? 7. Jakie trzy funkcje, nieobsługiwane przez RIP w .l, obsługuje RIP w.2? 8. Dlaczego RIP w.2 jest w istocie przestarzały?

Rozdział 6. • PROTOKOŁY ROUTINGU

9.

219

Jakie są niektóre wady protokołu RIP w .l?

10. Jakie różne mechanizmy stosuje RIP, aby unikać pętli routingu? 11. Jakie czasomierze wykorzystuje RIP? 12. Za jakiego rodzaju protokół routingu jest uważany OSPF? 13. Jakie metryki bierze pod uwagę OSPF, podejmując decyzje odnośnie routingu? 14. Jaką przewagę ma OSPF nad RIP-em? 15. Jakie są niektóre cechy charakterystyczne OSPF-a? 16. Jakie trzy bazy danych tworzą i przechowują routery OSPF? 17. Czym jest baza danych przylegania OSPF? 18. Czym jest baza danych stanu łączy OSPF? 19. Czym jest baza danych przekazywania OSPF? 20. Czym jest LSA protokołu OSPF? 21. Jaka jest różnica między wewnątrzobszarowym a międzyobszarowym ogłosze­ niem OSPF? 22. Jakie sześć stanów może przyjmować router OSPF? 23. Jakie są cztery typy routerów OSPF? 24. Jaki jest typ obszaru szkieletowego OSPF? 25. Jakie pięć typów pakietów OSPF istnieje? 26. Jaka jest funkcja pakietu Hello OSPF? 27. Jaka jest funkcja pakietu opisu bazy danych OSPF? 28. Jakie metryki wykorzystuje IGRP, podejmując decyzje odnośnie routingu? 29. Jaka jest maksymalna liczba skoków dla IGRP? Dlaczego jest ważne, że IGRP ma większy licznik skoków niż RIP? 30. Jakie są różne czasomierze protokołu IGRP i jakie są ich funkcje? 31. Jakie są niektóre cechy charakterystyczne EIGRP? 32. Jakiego typu protokołem jest EIGRP? 33. Jakie są niektóre zalety i wady tego, że EIGRP oferuje obsługę wieloprotokołową? 34. Jaka jest różnica między trasami EIGRP: następnikiem i możliwym następnikiem? 35. Jakie pięć typów pakietów EIGRP istnieje? Opisz krótko każdy. 36. Jaka jest różnica między protokołami IGP a EGP? 37. Jakie rozszerzenia protokołu BGP w.4 umożliwiły mu stanie się podstawowym protokołem wykorzystywanym przez Internet? 38. W jakich sytuacjach należałoby wdrożyć protokół BGP? 39. Jaka jest różnica między topologią częściowo- a pełnokratową BGP?

220

TCP/IP. SZKOŁA PROGRAMOWANIA

40. Jakie są cztery typy routerów BGP? 41. Jakie rzeczy musi rozróżniać każdy nadajnik BGP bez względu na to, jaką tabelę przechowuje? 42. Jakim protokołem przemieszcza się BGP? 43. Jakie są cztery różne typy komunikatów BGP? 44. Kiedy jest wysyłany komunikat otwarcia BGP i jaka jest jego funkcja? 45. Do czego służy komunikat powiadomienia BGP? 46. Jaką metrykę wykorzystuje BGP do określania najlepszej ścieżki do celu? 47. Na jakie cztery kategorie dzielą się atrybuty ścieżek BGP? 48. Co oznacza preferencja lokalna dla protokołu BGP? 49. Jakie są niektóre różnice między BGP w.3 a BGP w.4?

WARSTWA TRANSPORTOWA Przegląd treści rozdziału: o

Protokoły połączeniowe

|

o

Protokoły bezpołączeniowe

P ro to k o ły w a rs tw y transportow ej Systemy komunikacyjne nie obsługują wszystkich zadań transmisyjnych za pomocą jednego protokołu — większość zadań wymaga współpracy szeregu protokołów. Warstwa transportowa zapewnia niezawodny przepływ danych między dwoma pro­ cesami uruchomionymi na zdalnych hostach. Protokoły przebywające w tej warstwie odbierają komunikaty (strumienie danych) od aplikacji warstw wyższych oraz przetwarzają je i przekształcają (konwertują) na odcinki (segmenty), przeznaczone do wysłania w dół, do warstwy sieciowej, gdzie zostaną przekształcone w datagramy (pakiety). Omówimy dwa protokoły warstwy transportowej, obecne w zestawie protokołów TCP/IP: protokół sterowania transmisją (TCP, Transmission Control Protocol) w roz­ dziale 8, oraz protokół datagramów użytkownika (UDP, User Datagram Protocol) w rozdziale 9. W rozdziale bieżącym ograniczymy się natomiast do funkcji i usług oferowanych przez protokoły tej warstwy. Oferowany typ usługi zależy od wybra­ nego protokołu. Bezpołączeniowy (connectionless) protokół UDP zapewnia szybkie i niepewne (zawodne) dostarczanie fragmentów danych między zdalnymi procesami. Połączeniowy (connection-oriented) protokół TCP zapewnia zaś sekwencjonowanie

222

TCP/IP. SZKOŁA PROGRAMOWANIA

(ustawianie w kolejności) danych, dzięki czemu dostarczanie między dwoma hostami jest niezawodne (pewne). Każdy protokół jest albo połączeniowy, albo bezpołączeniowy. Dostawcy oprogramowania mogą wybierać, czy aplikacje warstw wyższych będą korzystać z UDP czy z TCP. Jeśli zależy im na szybkości, wybiorą protokół UDP, oferujący szybkie, możliwie jak najlepsze, dostarczanie datagramów. Gdy nato­ miast szybkość jest mniej ważna od niezawodności, zastosują protokół TCP, za­ pewniający dostarczanie wolniejsze, ale gwarantowane. Mówiąc krótko, wybór sprowadza się do wyboru między szybkością a niezawodnością. Miejsce protokołów TCP i UDP w modelu DoD (Departamentu Obrony USA) i modelu referencyjnym OSI zostało pokazane na rysunku 7.1. Rys u n ek 7 .1 .

DOD

Zwróćmy uwagę, że protokoły TCP i UDP są przypisane do warstwy transportowej modelu OSI i DoD

OSI

a plikacji p rezentacji

aplikacji

sesji

W a r s t w

tra n sp ortow a

tra n sp ortow a

T C P lub UDP

■ H

y _

d ostępu do sieci

tącza danych fizyczn a

UDP oferuje szybkie, zawodne dostarczanie komunikatów między aplikacjami uru­ chomionymi na zdalnych hostach. Uważany za prosty, protokół UDP zapewnia szybką obsługę ograniczając się do wysyłania pakietów z jednego hosta na drugi, pozostawiając gwarantowanie niezawodności protokołom warstw wyższych (apli­ kacyjnym). Ma on jedną zasadniczą wadę: nie daje żadnej gwarancji, że wysyłane przez niego datagramy faktycznie dotrą na drugi koniec komunikacji. TCP oferuje dostarczanie danych wolniejsze, ale gwarantowane. Robi to kontrolu­ jąc przepływ i rozmiar wysyłanych datagramów, dzięki czemu warstwa sieciowa może obsłużyć transmisję. Następnie przechodzi przez serię potwierdzeń i sekwencjonowanie, gwarantujące osiągnięcie celu przez każdy segment danych. Ze wzglę­ du na wszystkie sprawdzenia i uzgodnienia, wykonywane w trakcie doręczania, zapewnia niezawodny choć wolniejszy przepływ danych. Warstwy wyższe — ina­ czej niż w przypadku UDP — nie muszą troszczyć się o gwarantowanie doręczania.

Rozdział 7. - W ARSTWA TRANSPORTOWA

223

Warstwa transportowa oferuje następujące usługi: > Steruje komunikacją „od końca do końca" (end-to-end), czyli całościową, między dwoma procesami uruchomionymi na różnych hostach. > Zapewnia warstwom wyższym usługi połączeniowe oraz bezpołączeniowe. > Wykorzystuje adresy portów klienta i serwera do identyfikacji procesów uru­ chomionych na hoście. > Segmentuje (dzieli na segmenty) dane aplikacji warstw wyższych.

Protokoły połączeniow e TCP jest jedynym protokołem połączeniowym warstwy transportowej w pakiecie protokołów TCP/łP. Jeśli aplikacja wymaga korzystania z jego funkcji, dostawcy implementują go jako jej protokół transportowy. Bez względu na warstwę w której przebywają, protokoły połączeniowe zawsze mają następujące cechy: > Ustanowienie sesji (Session setup) — tworzy obwód wirtualny między dwoma komunikującymi się procesami, uruchomionymi w systemach końcowych (por. rysunek 7.2). Rys u n e k 7 .2 .

U s ta n o w ie n ie s e s ji

Dowolna aplikacja, wykorzystująca TCP jako swój protokół transportowy, przed rozpoczęciem transmisji danych musi ustanowić połączenie

Potwierdzenia (Acknowledgements) — powiadamiają urządzenie wysyłające o dotarciu danych. > Selcwencjonowanie (Sequencing) — śledzi kolejność datagramów. > Sterowanie przepływem (Flow control) — kontroluje szybkość danych wcho­ dzących. Hosty mogą nakazywać innym hostom spowalnianie lub przyspieszanie transmisji danych.

224

TCP/IP. SZKOŁA PROGRAMOWANIA

► Komunikaty utrzymywania przy życiu (Keepalives) — podtrzymują połączenie gdy nie występuje transmisja danych. ► Zerwanie sesji (Session teardown) — następuje gdy któryś z systemów końcowych zażąda zakończenia połączenia wirtualnego (por. rysunek 7.3). Rys u n ek 7 .3 .

Z e rw a n ie s e s ji

Wyjście z aplikacji (zakończenie jej) daje początek zerwaniu sesji TCP

Ustanowienie sesji połączeniowej zawsze zaczyna się od warstw niższych, przecho­ dząc do warstw wyższych modelu OSI. TCP jest podstawowym protokołem połą­ czeniowym zestawu TCP/IP. Ilekroć aplikacja działa za pośrednictwem tego proto­ kołu, przed transmisją jakichkolwiek znaczących danych ustanawia on połączenie wirtualne. Po ustanowieniu sesji między odpowiednimi warstwami, może nastąpić przesył danych przez to połączenie między komunikującymi się aplikacjami. TCP ustanawia sesję za pomocą wymiany trójramkowej. Szczegóły omówimy w rozdziale 8. Protokoły połączeniowe zapobiegają traceniu danych przez hosty podczas transmi­ sji, sekwencjonując je (ustawiając w kolejności) i wymieniając potwierdzenia. Spo­ sób sekwencjonowania danych zależy od protokołu. Niektóre sekwencjonują ram­ kę po ramce, inne — każdy bajt w obrębie ramki. Bez względu na sposób, cel pozostaje ten sam: wykrywanie utraty danych i odzyskiwanie ich przez ponowną transmisję. Gdy hosty są bezczynne (nie wymieniają danych), nadal muszą podtrzymywać połączenie wirtualne. Robią to za pomocą krótkich kom unikatów utrzymywania przy życiu, przesyłanych między dwoma maszynami celem zapewnienia łączności. Dzięki nim połączenie wirtualne jest podtrzymywane podczas bezczynności proce­ sów hosta. Komunikaty te nie przenoszą danych warstw wyższych, a służą tylko do podtrzymywania połączeń bezczynnych.

Rozdział 7. • W ARSTW A TRANSPORTOWA

225

Czasami host wysyła naraz zbyt dużo danych, przepełniając w ten sposób bufory hosta odbierającego. Korzystając z mechanizmów sterowania przepływem proto­ kołu połączeniowego, host odbierający może nakazać hostowi wysyłającemu spo­ wolnienie (w innych sytuacjach — przyspieszenie) wysyłania danych, tym samym regulując ilość ruchu sieciowego. Metody sterowania przepływem zależą od stoso­ wanego protokołu. Sterowanie przepływem dla protokołu TCP opiera się na mechanizmie okna prze­ śnionego (sliding window). Umożliwia on w razie potrzeby dynamiczne przystoso­ wywanie rozmiaru okna protokołu, mające na celu powiadomienie hosta wysyłają­ cego, żeby spowolnił transmisję lub całkiem ją zatrzymał. Warstwy wyższe zrywają połączenie wirtualne, gdy którakolwiek ze stron wyśle żądanie zaprzestania sesji. Wszystkie sześć cech protokołu TCP bardziej szczegółowo omówimy w rozdziale 8.

Protokoły bezpołączeniow e Bez względu na warstwę w której przebywają, protokoły bezpołączeniowe wysy­ łają dane bez sprawdzania, czy host odbierający faktycznie je otrzymał, czy też nie. Dotarcie wysłanych danych do odbiorcy i odzyskiwanie danych utraconych za­ pewniają im inne protokoły. Protokoły bezpołączeniowe nie dają niezawodności cechującej ich połączeniowe odpowiedniki, zapewniają jednak coś, czego te ostat­ nie nie potrafią — szybkość i minimalne koszty obsługi. Protokół UDP bardziej do­ kładnie omówimy w rozdziale 9.

Protokoły bezpołączeniow e a protokoły połączeniow e Przed wdrożeniem konkretnego protokołu dostawcy zadają sobie pytanie stare jak sieć: szybkość czy niezawodność i dodatkowy narzut pracy? Protokoły bezpołącze­ niowe są szybsze i bardziej wydajne, gdyż nie są obciążone sekwencjonowaniem i potwierdzaniem każdego bajtu czy ramki (cechującym np. ustanawianie sesji po­ łączeniowej). Poza tym nie muszą podtrzymywać połączeń bezczynnych (za pomocą stosownych komunikatów), co jeszcze bardziej zwiększałoby obciążenie. Gdy dostawcy wymagają szybkiego doręczania, wybierają protokoły bezpołącze­ niowe, gdy zaś od szybkości ważniejsza jest niezawodność — połączeniowe. Na przykład dostawca aplikacji drukowania najpewniej wykorzysta w niej protokół połączeniowy (użytkownicy chcą mieć pewność — a nie nadzieję — że ich zadania wydruku zostaną wykonane). Porównanie tych dwóch typów protokołów zawiera tabela 7.1.

226

TCP/IP. SZKOŁA PROGRAMOWANIA

TABELA 7.1. Protokoły bezpołączeniowe a połączeniowe

Typ protokołu

Cecha

Bezpołączeniowy

Brak ustanawiania sesji Brak zrywania sesji Brak potwierdzeń Brak sekwencjonowania Brak sterowania przepływem Brak kom unikatów utrzym ywania przy życiu Dostarczanie w miarę możności Szybkie dostarczanie danych Mały narzut pracy Brak usuwania błędów i ponownej transm isji danych

Połączeniowy

Ustanawianie sesji Zrywanie sesji Potwierdzenia Sekwencjonowanie Sterowanie przepływem Kom unikaty utrzym ywania przy życiu Dostarczanie niezawodne, gwarantowane W olniejsze dostarczanie danych Spory narzut pracy Usuwanie błędów Ponowna transm isja danych

Porty i gniazda Warstwa transportowa, bez względu na typ wykorzystywanego protokołu (połą­ czeniowy — TCP — czy bezpołączeniowy — UDP), procesy uruchomione na hoście identyfikuje za pomocą portów, inaczej zwanych gniazdami (sockets). Obsługuje ona adresowanie portów źródłowych i docelowych, identyfikując w ten sposób protokoły lub procesy warstw wyższych chcące komunikować się na danym urzą­ dzeniu. Warstwa ta korzysta z adresów klienckich (przeznaczonych dla klienta) i serwerowych (przeznaczonych dla serwera) portów TCP i UDP, za ich pomocą rozpoznając procesy działające w obrębie hosta. Wcześniej wspomnieliśmy, że warstwa transportowa odpowiada za segmentację (podział na segmenty) danych podawanych w dół przez aplikacje warstw wyż­ szych. Panowanie nad tymi segmentami, śledzenie ich i zarządzanie nimi jest moż­ liwe dzięki numerom portów tej warstwy, przeznaczonym dla każdej aplikacji. Pa­ miętajmy, że dostawca może w tej warstwie stosować protokoły połączeniowe albo bezpołączeniowe, w zależności od czego dostarczanie danych będzie gwarantowane

Rozdział 7. • W ARSTW A TRANSPORTOWA

227

albo nie. Niektórzy mylnie sądzą, że warstwa transportowa zapewnia wyłącznie dostarczanie gwarantowane (niezawodne), należy jednak zapamiętać, że jest inaczej i dostarczanie nie zawsze jest gwarantowane. Przypuśćmy, że użytkownik chce utworzyć połączenie klienckie Telnetu ze zdal­ nym serwerem. W sesji zostaje otwarty niepowtarzalny port, o zmiennym (przy­ dzielanym na bieżąco) numerze, a połączenie klienckie wykorzystuje go do osią­ gnięcia serwera Telnetu. Porty klienckie są wybierane losowo, natomiast porty serwerowe mają wartości przypisane, na ogół zwane p o r t a m i s t a n d a r d o w y m i (sto­ sowane są też terminy port dobrze znany, albo zarezerwowany, ang.well-known ports). Podłączając się do hosta czy też serwera, zwykle podłączamy się do portu standar­ dowego (dla Telnetu jest to port 23 — por. rysunek 7.4). Opis różnych kategorii portów zawiera tabela 7.2. Rysunek 7 .4 . Serwer Telnetu zawsze wykorzystuje port 23 protokołu TCP

P o rty k lie n c k ie i s e rw e ro w e

P o rt se rw e ra

.0.0.2

^>|110.0.'

Z a kre s kliencki = 1024 -6 5,53 5 Z a kre s s e rw e ro w y = 1-1023

TABELA 7 .2 .

K a te g o rie p o rtó w

Kategoria portu

Zakres/Opis

Porty serwerowe standardowe

0-255 Porty program ów powszechnie znanych w branży, które stały się przyjętą norm ą ich adresowania.

Porty serwerowe m niej standardowe

2 5 6 - 1023 Porty zarezerwowane, które dostawcy mogą stosować w razie potrzeby.

Porty klienckie

1 0 2 4 -6 5 5 3 5 Porty zmienne, otwierane na poczekaniu za każdym razem, gdy tworzony proces kliencki otwiera nowy port.

228

TCP/IP. SZKOŁA PROGRAMOWANIA

Widoczne na rysunku 7.4 adres IP (100.0.0.2) i port (4001 — zmienny, stworzony na poczekaniu) klienta oraz adres IP (110.0.0.10) i port (23 — standardowy serwera Telnetu) hosta docelowego składają się na parę gniazd (socket pair). Para taka okre­ śla połączenie całościowe („końca z końcem") między dwoma hostami (źródłowym i docelowym), wykorzystujące („łączące w pary") obydwa ich adresy IP i porty. Porty kliencki i serwerowy jednoznacznie identyfikują proces komunikujący się na każdym z tych hostów. Łącząc adres i port hosta wysyłającego z adresem i portem hosta docelowego, protokoły TCP i UDP mogą zarządzać komunikacją między ho­ stami i ich procesami oraz odróżniać je od innych połączeń wirtualnych do tych samych hostów.

Uwaga Pam iętajm y, że warstw a transportow a zajm uje się adresami gniazd czy też por­ tów . Łączenie gniazd w pary opisuje połączenie całościowe dwóch hostów (źró­ dłowego i docelowego), obejm ujące zarówno ich adresy IP, ja k i porty.

Porty protokołów TCP i UDP (z zestawu TCP/IP) identyfikują proces lub program uruchomiony na hoście. TCP, jako protokół połączeniowy, utrzymuje połączenie między procesami (programami) na dwóch różnych hostach. Bezpołączeniowy protokół UDP tylko przekazuje dane licząc, że dotrą one do miejsca przeznaczenia, a w zakresie podtrzymywania połączenia polega na protokołach warstw wyższych.

Podsumowanie Warstwa transportowa steruje komunikacją całościową („końca z końcem") między dwoma procesami uruchomionymi na różnych hostach, zapewniając warstwom wyższym usługi połączeniowe oraz bezpołączeniowe. Poza tym procesy działające na hoście identyfikuje za pomocą adresów portów (klienckich i serwerowych) oraz segmentuje dane aplikacji warstw wyższych. W warstwie tej znajdują się dwa, znacznie różniące się od siebie, protokoły z ze­ stawu TCP/IP: bezpołączeniowy UDP i połączeniowy TCP. Wszystkie protokoły dzielą się na połączeniowe i bezpołączeniowe. Protokoły połączeniowe zapewniają gwarantowane, niezawodne dostarczanie da­ nych między dwoma systemami końcowymi. Protokoły bezpołączeniowe oferują szybkie, ale niepewne dostarczanie. Protokoły połączeniowe zawsze cechuje następujących sześć właściwości: ustana­ wianie sesji, potwierdzenia, sekwencjonowanie, sterowanie przepływem, komuni­ katy utrzymywania przy życiu i zrywanie sesji.

Rozdział 7. • W ARSTWA TRANSPORTOWA

229

Warstwa transportowa obsługuje adresowanie za pomocą portów (gniazd), identy­ fikujących protokoły (procesy) warstw wyższych, które chcą komunikować się na konkretnym urządzeniu. Port klienta (zmienny) i port serwera (przypisany) oraz adresy IP (źródłowy i docelowy) dwóch komunikujących się hostów wspólnie two­ rzą parę gniazd.

Pytania sprawdzające 1. Jakie cztery usługi zapewnia warstwa transportowa? 2. Czym charakteryzują się wszystkie protokoły połączeniowe? 3. Czym są porty standardowe i jaki jest ich zakres? 4. Czym są porty mniej standardowe i jaki jest ich zakres? 5. Czym są porty klienckie i jaki jest ich zakres? 6. Co to jest parowanie gniazd? 7. Czym istotnie różnią się dwa protokoły warstwy transportowej obecne w pakiecie TCP/1P? 8. Co to jest sterowanie przepływem? 9. Jakiego wyboru muszą dokonywać dostawcy implementujący poszczególne protokoły warstwy transportowej? 10. Jaki protokół wykorzystuje potwierdzenia i sekwencjonowanie? Jakie są ich funkcje?

230

TCP/IP. SZKOŁA PROGRAMOWANIA

PROTOKOŁ STEROWANIA TRANSMISJA (TCP) Przegląd treści rozdziału: o

Nagłówek TCP

o

Ustanawianie i zrywanie połączenia

o

Działanie TCP

o

Sekwencjonowanie i potwierdzenia

Wprowadzenie Protokół TCP pierwotnie zaprojektowali Vinton Cerf i Robert Kahn, chcąc zapewnić niezawodną transmisję danych między zdalnymi hostami, komunikującymi się przez sieć przełączaną pakietowo (packet-switched). Przed jego wynalezieniem transmisja przez takie sieci okazywała się dość niepewna. Jakość dostarczania (brak nieza­ wodności), różne typy nośników i możliwość zatorów (ograniczających dostarcza­ nie danych) zrodziły zapotrzebowanie na protokół połączeniowy, zapewniający niezawodne usługi całościowe („od końca do końca") procesom i aplikacjom komuni­ kującym się między zdalnymi hostami. Departament Obrony (DoD) USA przyjął TCP jako podstawowy protokół niezawodnego dostarczania informacji przez sieć ARPA. Następnie stał on się standardowym protokołem Internetu, zapewniającym gwarantowane dostarczanie danych między hostami. TCP jest przypisany do warstwy transportowej w modelach DoD i OSI. W warstwach tych działają jedynie protokoły TCP i UDP (ze stosu TCP/IP). Dostawcy chcąc gwa­ rantować dostarczanie danych mogą stosować protokół TCP, a gdy wolą szybkość od gwarancji — protokół UDP. Miejsce protokołu TCP w modelach DoD i OSI po­ kazano na rysunku 8.1.

232

TCP/IP. SZKOŁA PROGRAMOWANIA

Rysu n ek 8 .1 .

DOD

OSI

TCP g w a ra n tu je aplikacji

d o s ta rc z a n ie d a n y c h aplikacji

w w a rs tw ie tra n s p o rto w e

prezentacji sesji

W

i

a r

transportowa

TCP

transportowa

fi

w

dostępu do sieci

łącza danych fizyczna

Nagłówek TCP Znając ogólne funkcje i zastosowania połączeniowego protokołu TCP, zbadajmy dokładniej pola jego nagłówka. Schemat nagłówka TCP, zdefiniowany w RFC 793, przedstawiono na rysunku 8.2. Z kolei na rysunku 8.3 pokazano konkretny przy­ kład takiego nagłówka, występującego w określonej sytuacji. W nagłówku tym wy­ szczególnione są porty źródłowy i docelowy, wartości sekwencj onowania i po­ twierdzania (ACK), a także flagi określające sposób przetwarzania informacji przez hosta. Wszystkie elementy nagłówka TCP opisano w punktach pod rysunkami. Ry s u n e k 8 .2 .

Port źródłowy

F o rm a t n a g łó w k a

Port docelowy N um er kolejny

T C P. N o rm a ln ie N um er potwierdzenia

n a g łó w e k te n z a w ie ra 2 0 b a jtó w , c h y b a że s to s o w a n e s ą o p c je . W a rto o d n o to w a ć ,

Przesunięcie

Zarezerw.

U A P R S F

Suma kontrolna

Okno W skaźnik pilności

Opcje + dopełnienie

że n a g łó w e k m oże nie z a w ie ra ć o p c ji an i d a n y c h Dane

Rozdział 8. • PROTOKÓŁ STEROWANIA TRANSM ISJĄ (TCP)

Ry su n e k 8 .3 .

P o rt d o c e lo w y

W tym konkretnym nagłówku TCP nie występują żadne opcje i nie jest obecne pole wskaźnika pilności

P o rt źró d to w y

Monitor Capture fiisplay Jools Windo

I" 1

ISlalu ; ISom caÄi jress

Ok

j-Q lP :

a IP:

P rz e s u n ię c ie d a n y c h F la g i -

O knoS u m a k o n tro ln a B ra k o p c ji T C P -

>

ar|B l a i d iS lŁ ilQ l'.i,jj| a | !: | No.

[ 3 6 .5 !

i

: [ . .T:

N u m e r p o tw ie rd z e n ia

N u m e r k o le jn y

Up Adapt«_l - JSw

¡2 £¿5

233

¡Np....

ftj jgj o| ZJEül

lie n |R
Ustanawianie sesji, > Zrywanie sesji, > Sekwencjonowanie, > Potwierdzenia, > Komunikaty utrzymywania przy życiu, > Sterowanie przepływem. Cechy te szczegółowo opiszemy w kolejnych punktach.

Ustanawianie sesji Zanim będzie mogła nastąpić jakakolwiek transmisja danych, między komunikują­ cymi się procesami lub aplikacjami hostów zdalnych musi zostać ustanowiony nie­ zawodny, połączeniowy obwód logiczny. Ustanawianie sesji jest takie samo bez względu na proces (aplikację). Protokół TCP identyfikuje wszystkie procesy i apli­ kacje warstw wyższych za pomocą numerów portów (gniazd), wykorzystując je do odróżniania procesów na jednym hośde, co zapewnia właściwe doręczanie i przetwa­ rzanie danych. Przypuśćmy na przykład, że użytkownik chce zapoczątkować sesję kliencką Telnetu ze zdalnym serwerem. Użytkownik rozpoczyna lokalny proces kliencki Telnetu, co powoduje otwarcie na hoście lokalnym źródłowego portu klienckiego, identyfiku­ jącego proces. Wartość portu jest wybierana losowo z zakresu 1024 - 65535. Proto­ kół TCP wykorzystuje port źródłowy w połączeniu z portem docelowym (standar­ dowym portem 23 serwera Telnetu), wskazuj ącym na zamierzonego odbiorcę komunikacji. Jednoczesne korzystanie z portu źródłowego i docelowego pozwala TCP śledzić parę komunikujących się procesów i wiedzieć, między którymi procesami otwiera sesję. Jeśli użytkownik zapoczątkowuje sesję z hostem zdalnym za pomocą jego nazwy, a nie adresu IP, musi nastąpić jakiegoś rodzaju rozpoznawanie (zamiana) nazw, odwzorowujące nazwę hosta na adres warstwy sieciowej ostatecznego celu (gdy znajduje się on w tej samej podsieci) albo prowadzącej do niego bramy. Po poznaniu adresu warstwy sieciowej docelowego hosta IP, protokół ARP zamieni go na adres MAC, służący do lokalnego doręczania.

Rozdział 8. • PROTOKÓŁ STEROWANIA TRANSM ISJĄ (TCP)

245

Łączenie gniazd w pary Po zakończeniu procesu zamiany adresów, TCP ma dość informacji do rozpoczęcia procesu ustanawiania sesji. Adres źródłowy warstwy sieciowej i porf/gniazdo klienta oraz adres docelowy warstwy sieciowej i porf/gniazdo serwera wspólnie tworzą parę gniazd. Ponieważ ten sam klient, bądź wielu klientów podłączających się do tego samego portu/gniazda serwera zdalnego, może żądać wielu połączeń TCP, łączenie gniazd w pary oddziela od siebie różne żądania, jednoznacznie identy­ fikując i obsługując komunikację między parami. Ze względu na potencjalną mno­ gość połączeń, łączenie gniazd w pary ma kluczowy wpływ na udane funkcjono­ wanie protokołu TCP. Ustanowienie sesji zaczyna się od ustawienia przez klienta w nagłówku TCP flagi SYN, oznaczającej żądanie synchronizacji z docelowym procesem TCP. Protokół TCP hosta odbierającego musi potwierdzić (ACK) odbiór tego żądania i wysłać własne żądanie SYN. To żądanie z kolei musi zostać potwierdzone przez pierwszego hosta. Rysunki 8.10 - 8.12 obrazują przykład ustanawiania sesji. Widać na nich dwa hosty (192.42.252.20 i 192.42.252.1), ustanawiające połączenie TCP. W pierwszej ramce klient 192.42.252.20 korzystający z portu 2921 żąda połączenia TCP, wysyłając początkowy komunikat SYN do serwera Telnetu (port 23) o adresie IP równym 192.42.252.1. R am ka 1

Rysu n ek 8 .1 0 .

Pierwsza część ustanawiania sesji TCP zaczyna się od klienta wysyłającego serwerowi żądanie SYN. Ramka ta nie zawiera pola ACK, gdyż ani klient, ani serwer nie wysłał jeszcze żadnych danych, które wymagałyby potwierdzenia

H e K1or»loi £ep!uie Drtplay Jo o li ¡¿¿irałow Help

¡ g | H ir r |

I a l a t o l u i i f c l a l :A t.\ ś d

252.1] [192.42 252 20] .252.20] [192 42.252.1]

TCP D-2921 S«23 SYH ACK-1545216001 SE'.>49056QQQ IE1I0 yUI-409£ 64 TCP D*23 S=2921 ACK=498S6001 0111=4096 64

yD ecodef\ M atro:ĄH ostTobfa\ ProtocolD tót.XStatisficsj

ForH elp,pies:FI i ^jSloitjl| fS Ud ® 1¡Sił'*011!"11® I iijE>pk!io9--!|SSni(,0,— Ew ptw ing..{

P. ; JJliUKt EJ® «PU

Serwer Telnetu wysyła drugą ramkę, spełniającą rolę ACK dla uprzedniego SYN klienta i zarazem własnego żądania SYN. Ramka ta zawiera pole ACK, potwier­ dzające początkowy SYN klienta. Ponieważ protokół TCP umie komunikować się w trybie całkowicie dwukierunkowym (full-duplex), tzn. potrafi wysyłać i potwierdzać

246

TCP/IP. SZKOŁA PROGRAMOWANIA

Rys u n ek 8 .1 1 .

Ramka 2

Druga część ustanawiania sesji TCP to potwierdzenie (ACK) przez serwer żądania SYN klienta i wystanie do niego własnego żądania SYN

Rys u n ek 8 .1 2 .

Ramka 3

Trzecia część ustanawiania sesji TCP to potwierdzenie (ACK) przez klienta żądania SYN serwera

odbiór danych w tej samej ramce zamiast w dwóch oddzielnych, w ramce tej znaj­ duje się też własne żądanie SYN serwera. Dzięki temu działanie protokołu TCP jest bardziej wydajne. Klient wysyła trzecią ramkę jako ACK uprzedniego SYN, wysłanego przez serwer Telnetu. Skoro te dwa hosty ustanowiły sesję TCP, mogą transmitować dane Telnetu. Zauważmy, że bez względu na typ żądanej przez hosta aplikacji warstw wyższych (Telnet, SMTP, FTP itd.), przedstawiona trójramkowa wymiana zawsze ma miejsce.

Rozdział 8. • PROTOKÓŁ STEROWANIA TRANSM ISJĄ (TCP)

247

Żądania i potwierdzenia, wchodzące w skład tej wymiany ramek, noszą nazwę po­ rozumienia trzyetapoivego (three-way handshake). Ponieważ TCP ma możność ko­ munikacji dwukierunkowej, do przeprowadzenia tego procesu potrzebuje tylko trzech ramek (zamiast czterech). Gdy odbiorca otrzymuje od nadawcy pierwsze żą­ danie SYN, odpowiada potwierdzeniem wysłanym do niego wraz ze swoim żąda­ niem SYN (w jednej ramce). Aby dokończyć całą transakcję, w następnej (końcowej) ramce porozumienia trzyetapowego nadawca wysyła własne ACK, potwierdzające odbiór SYN odbiorcy. Ry­ sunki 8.13 - 8.15 przedstawiają szczegółowy przykład porozumienia trzyetapowego. Jak widać w nagłówku TCP, host ustawił bit SYN (na co wskazuje wartość 1). Poza tym podał kiłka parametrów początkowych, mianowicie początkowy numer ko­ lejny (ISN, Initial Sequence Number) równy 1545216000, rozmiar okna 4096 bajtów i maksymalny rozmiar segmentu (MSS) — 1024 bajty. Wartości te omówimy do­ kładniej dalej. Rysunek 8 . 1 3 . Żądanie SYN wysłane przez klienta w pierwszej części porozumienia trzy etapowego

2 £Ho tlenici gjptuiB Qitptay Iool: ¡¿fmdow Hołp s j a\& \ © IP : © IP : ¿3 IP : © IP : © IP : Q IP : £3 TCP: £3 TCP: ©TCP: ©TCP: ©TCP: ©TCP: ©TCP: £ 3 TCP: © TCP: Q TCP: - © TCP: © TCP: © TCP: ©TCP: ©TCP: ©TCP: © TCP: ©TCP:

M

-

Source p o rt = 2921 D e stin a tio n p o rt = 23 (T e ln e t) I n i t i a l sequence number = 1545216000 Data o f f s e t = 24 b y tes F la g s - 02 . . 0 .............» (No u rg e n t p o in te r) . . . 0 . . . . = (No acknowledgment) ------ 0 . . . - (No push) .............0 . . - (No r e s e t ) ............... 1 . - SYN ..................0 - (No FIN) Window - 4096 Checksum ° B9D4 ( c o r r e c t ) O ptions follow Maximum segment s i z e = 1024

VDecnda^MalrctĄHcU For Help. piesi FI ^

o||

P ro to c o l - 6 (TCP) H eader checksum - EADB ( c o r r e c t ) S ource addross - [ 1 9 2 .4 2 .2 5 2 .2 D ] D e s tin a tio n a d d ress » [ 1 9 2 .4 2 . 2 5 2 .1 ] No o p tio n s

Starł|i j E9 5S

Table/yProtocolDid./yStatisticsj S3 ^ ! i SMauTn* |UJEcptoting. ||SSnUicr... U J

I (3

Ti. f

Exploring...|

ft r U tM O II

M2W

Na rysunku 8.14 widać ramkę odpowiedzi serwera Telnetu (adres IP = 192.42.252.1, port źródłowy = 23). Serwer ten dołącza do niej swoje ACK (ustawił flagę), wska­ zujące na odebranie początkowego żądania klienta (o numerze kolejnym 1545216000). Potwierdzenie to mówi, że serwer jako następnego spodziewa się numeru kolejne­ go 1545216001, a więc otrzymał wszystkie mniejsze (bez niego samego). Z kolei ISN seiwera wprosi 49856000 (a więc klient powinien odesłać numer potwierdzenia 49856001). Serwer ustawił bit SYN, oznaczający chęć synchronizacji z klientem, po­ za tym określił wielkość okna na 4096 bajtów, a MSS na 1024 bajty.

243

TCP/IP. SZKOŁA PROGRAMOWANIA

Rys u n e k 8 .1 4 .

Potwierdzenie ACK i żądanie SYN, jednocześnie wystane przez serwer w drugiej części porozumienia trzyetapowego

•

L'-Smtl«« Pio •Loc.il/OMl-llpAil.iplei_1 - |Cml? 2/3Ëlhernrl linmet) £2 Po Monitor £apiura Qisplay Iools Yfmdow Help CS|H| S lr-.il E t e t o M S l & t e l -

H 0JE 3

R j © I O l! -j

£3 £3 £3 £3

I P : H eader checksum = 1304 ( c o r r e c t ) - [ 1 9 2 .4 2 . 2 5 2 .1 ] I P : S ou rce ad d re ss I P : D e s tin a tio n ad d re ss - [ 1 9 2 .4 2 . 2 5 2 .2 0 ] I P : No o p tio n s -£3 I P : 3 3 TCP: -------- TCP h e a d e r --------£3 TCP: £3 TCP : S o u rce p o rt » 23 (T e ln e t) £3 TCP: D e s tin a tio n p o rt » 2921 £3 TCP: I n i t i a l sequence number = 49056000 £3 TCP: Acknowledgment number “ 1545216001 £3 TCP: D ata o f f s e t “ 24 b y te s £3 TCP: F la g s = 12 •£3 TCP: . . 0 . . . . . » (No u rg en t p o in te r ) £3 TCP: . . . 1 . . . . = Acknowledgment £3 TCP: ____ 0 . . . = (No push) £3 TCP: ____ . 0 . . = (No r e s e t ) £ 3 TCP: ____ . . 1 . SYN £3 TCP ------ . . . 0 (No FIN) £3 TCP Window 4096 £3 TCP Checksum C0CA ( c o r r e c t ) £3 TCP Q T C P : O p tion s fo llo w £3 TCP: Maximum segm ent s i z e 1024 £3 TCP

3

“ = »

: : : :

= : | \DecodeAM atrixAH nctToiteAProtocolD ietASloilstlcc/ FoiH olp.pressFI ©i dk1 |S95I«||IIH & & E l ’S IIESH«Tim » |[]£JExploring.| SniffeiPr..||Y)Exploring..j Rys u n ek 8 .1 5 .

Potwierdzenie ACK wystane przez klienta w trzeciej (ostatniej) części porozumienia trzyetapowego

~ n

f." Snillet Pio Loc.il/Di.il Up Adoplci j |Snii2 : 3/3 Ethernet liumcs] [52 £¿0 Mcrûoi Capture Dbpląy Jcdt Vfiretow He'p e s |h

|

i

|

| ÎJlP ''M l'E !ÎË 4:43PM |

H 0E3 .je j x t f

s|.,.-i sfelQlto-lala|g|ft| ©I e||

£ 3 I P : Time t o l i v e ° 30 se co n d s/h o p s Q I P : P r o to c o l = 6 (TCP) ! £ 3 I P : H eader checksum = EADB ( c o r r e c t ) £3 I P : S o u rce a d d re ss = [192 .4 2 .2 5 2 . 2 0 ] £3 I P : D e s tin a tio n a d d re ss = [192 . 4 2 .2 5 2 . 1 ] 1 £3 I P : Wo o p tio n s £3 IP : 0 S3 T C P : ---------TCP h ead er — — : £ 3 TCP: £ 3 TCP: S o u rce p o rt 2921 £ 3 TCP: D e s tin a tio n p o rt 23 (T e ln e t) £ 3 TCP: Sequence number » 1 5 45216001 £3 TCP: Acknowledgment number 49056001 £ 3 TCP: D ata o f f s e t 20 b y te s £ 3 TCP: F la g s 10 £ 3 TCP: . . 0 .............(No u rg e n t p o in te r ) £3 TCP: . . . 1 ____ = Acknowledgment £ 3 TCP: ____0 . . . (No push) £3 TCP: .............0 . . - (No r e s e t ) £3T C P : ................0 . » (No SYN) £3 TCP: .................. 0 = (No FIN) £ 3 TCP: Window 4096 £ 3 TCP: Checksum = DED3 ( c o r r e c t ) £ 3 TCP: No TCP o p tio n s £3 TCP : k DecodoX MatrixĄ Host TableX Prolocol Dist ĄStatistics/ For Help, press FI IViewChannel:1 13Q Slorl |j J 0

g*

¿p i

-Ik |

| ^ E K p fa n n fl-K S S n ifle i... ; ajE^ptoing ...|______________ j

& I **2PM

Po ustanowieniu sesji przez obie strony, nadawca sekwencjonuje każdy bajt wysy­ łany, a odbiorca sekwencjonuje każdy bajt otrzymywany. Każdy nagłówek TCP ma pole długości, wyznaczające ilość danych transmitowanych w odcinku (w bajtach). Host docelowy dodaje tę wartość do numeru kolejnego, wysyłanego przez hosta źródłowego, obliczając w ten sposób zwracaną przez siebie wartość potwierdzenia. Jeśli na przykład host wysyłający ma numer kolejny 200 i wysyła 100 bajtów da­ nych, host odbierający powinien w ramce odpowiedzi wysłać ACK (czyli spodzie­ wany następny numer kolejny) równy sumie otrzymanego numeru kolejnego i ilo­ ści otrzymanych bajtów danych, tzn. 200 + 100 = 300. Zastosujmy ten wzór do ramek z rysunków 8.20 - 8.21. Telnet jest znakomitym przykładem, gdyż przeważ­ nie wysyła tylko 1 bajt danych jednorazowo, co łatwo pozwala zrozumieć działanie sekwencjonowania i potwierdzeń. Ry su n ek 8 .2 0 .

Protokół TCP sekwencjonuje każdy oktet

£3 M onScr £aptuic Ecpłaji Iools ¡¿indówH eip esjal a ir/I felaloltoiiaiłalgl p.\ $1 ol[ jPerlA ddrett [192 42 "52 1]

E g j TCP: TCP header —— ! 0 TCP: 0 TCP Source port j i -iQ TCP: Destination port 0 TCP: Sequence nunber 0 TCP. Acknovledgnent nunber ■ TCP: Data o ffset : ! 0 TCP: Flags "'TC P: . . 0 ........... TCP: . . .1 ___ TCP: 1 ... TCP: a .. • 0 TCP: 0. 0 TCP: C : 0 TCP: Uindov 0 TCP: Checksum 0 TCP: Ho TCP options 0 TCP: [1 byte(s) of data] | 0 TCP. B j|k} T elnet: — - Telnet -------0 T elnet: , 0 Telnet 1 0 T elnet:

■ 2921 ■ 23 (Telnet) ■ 1545216045 ■ 49056261 > 20 bytes

■10

■ (Ho urgent pointer) ■ Acknauledgnent * Push 1 (Ho re s e t) ■ (Ho 5YH) ■ (Ho Fill) ■ 4096 ■ 719A (co rrect)

D ecodaXM irfrixf\H odTabicĄProtocolD ist Statistics}

Foi Heip. piejs FI 3gSlatt|j j E |

S3

II ^M axTine

~

| ^Eypionng.. | ¡gSnifctPi... | L3JEnptoting...|

Rozdział 8. ° PROTOKÓŁ STEROWANIA TRANSMISJĄ (TCP)

Ry s u n e k o . 2 1 .

TZEE us.*

*fds M orelogsotureO ipbyTed: ¡¿fm dow(JiĄ)

P ro to k ó ł TCP

¿ ¡ H l^ Ą B la lo f e la t o lg l

p o tw ie rd z a

[192.4

n\

253

fel e l f

|De:lAdd’et: R PORT“2921 1

każd y o k te t - TCP header = 23 (Telnet) TCP: Source port 3 2921 TCP: Destination port 3 49856261 TCP: Sequence nunber - 1545216046 TCP. Acknowledgment nunber TCP: Data offset * 20 bytes 3 10 G TCP: Flags = (llo urgent pointi Q TCP: ..0. QTCP: . ..1 ___ 3 Acknowledgment ___ 1. .. 3 Push G TCP: .0. . •> (Ho reset) O TCP ......0. 3 (Ho SYH) G TCP: Q TCP: ....... t) 3 (Ho FIH) 3 4096 G TCP: Uindow 3 7199 (correct) Q TCP: Checksum Q TCP: Ho TCP options O TCP: [1 byte(s) of data] G TCP: Telnet:; ----- Telnet ----iCł Telnet: ¿¿Telnet: 1 G Telnet: Q Q Q 0 Q

yD ecodef\ ĄH oit ĄProtocolD istĄ3dltto7 FoiH elp.picssFI Matrix

Tabte

agglllH s& s)»

fei. -

I SjMtoPi... [ . i . ) - |

r

jUS-SU-BlTŁDaPMI

W pierwszej ramce host 192.42.252.20 wysłał 1 bajt danych Telnetu. Widać to w na­ główku TCP, gdzie pole długości zawiera napis [1 byte(s) of data], czyli [1 bajt(-ów) danych]. Z kolei w nagłówku Telnet widać transmitowany znak (1). Numer se­ kwencyjny tej ramki wynosi 1545216045. Aby przewidzieć, jaką wartością ACI< po­ winien odpowiedzieć odbiorca, zastosujmy wzór: numer kolejny (1545216045) plus długość (1) równa się 1545216046. W drugiej ramce widać odpowiedź na pierwszą. Serwer Telnetu potwierdza odbiór jednego bajtu danych, zgodnie z oczekiwaniami wysyłając ACK równe 1545216046.

Retransmisja Potrzebę retransmisji datagramu stwierdza host wysyłający. Ponieważ datagramy mogą obierać różne ścieżki i się gubić, urządzenie wysyłające przechowuje ich ko­ pie na wypadek, gdyby musiało retransmitować jakiś datagram do hosta docelowe­ go. Gdy host źródłowy wysyła dane, umieszcza ich kopię w kolejce retransmisyjnej na wypadek, gdyby musiał wysłać je ponownie, po czym uruchamia czasomierz (licznik czasu). Jeśli w odpowiedzi na wysłane dane otrzyma odpowiednie po­ twierdzenie, usunie z kolejki tę kopię. Jeśli jednak nie otrzyma odpowiedzi lub cza­ somierz wygaśnie (wyzeruje się licznik czasu), host źródłowy uzna datagram za utracony podczas tranzytu i retransmituje kopię z kolejki.

Czasomierze Wartość czasomierza retransmisji jest obliczana za pomocą algorytmu, opartego na długości czasu między wysyłaniem datagramów a odbiorem stosownych potwier­ dzeń. Algorytm ten wylicza czas retransmisji dynamicznie, szacując czas między transmisją datagramu a odpowiadającym jej potwierdzeniem. Wynik tego szacunku wykorzystuje do obliczenia SRTT (Smooth Round-Trip Timer). W oparciu o tę war­ tość i wartość bazową, skonfigurowaną na hoście, wylicza stosowaną przez hosta

254

TCP/IP. SZKOŁA PROGRAMOWANIA

wartość RTO (Retransmit Time-Out). Administrator może zmieniać wartość bazową tak, aby wpływała na RTO hosta TCP. Sposób konfiguracji tego parametru zależy od użytkowanego systemu operacyjnego. Dokładna znajomość tego algorytmu nie jest najistotniejsza. Wystarczy wiedzieć, że wartość ta steruje długością czekania przez hosta TCP na potwierdzenie, a po jej upłynięciu uznaje on wysłany datagram za utracony i wymagający retransmisji. Przykład upływu czasu oczekiwania (timeout) skutkującego retransmisją pokazano na rysunku 8.22. Host A wysyła do hosta B numery kolejne 11 i 12. Host B potwierdza ich odbiór, odsyłając ACK = 12 i ACK = 13. Wysyłając to ostatnie, host B spodziewa się otrzymać od hosta A numer kolejny 13 jako następny. Host A wysyła ten numer, ale gdzieś na ścieżce występuje błąd transmisji, powodując utratę tej ramki. Host A nie otrzymuje od hosta B kolejnego potwierdzenia (ACK = 14), a wygasa czaso­ mierz retransmisji. W tym momencie host A uznaje ramkę za utraconą i retransmituje numer kolejny 13. Rys u n e k 8 .2 2 .

Jeśli host w ciągu określonego czasu nie otrzyma potwierdzenia, retransmituje dane

U p ły w u c z a s u o c z e k iw a n ia i r e tra n s m is ja H ost B

H o st A

E /ajjiifcito

N u m e r ko le jn y 11 -

-D U -* - A c k = 12

N u m e r ko le jn y 1 2 - A c k = 13 N um e r kolejny 1 3 -

-G3—

W yg a sł c z a so m ie rz retransm isji!! R e tran sm isja num e ru ko le jn e g o 13

------------- A c k = 14

Z powodu dużych fluktuaqi szerokości pasma i szybkości transmisyjnej różnych sied, niekiedy czasomierz retransmisji nie potrafi dotrzymywać kroku transmisji. W takiej sytuacji trzeba dostosować wartość bazową na hoście. Jeśli czasomierz retransmisji ma zbyt niską wartość, host może retransmitować datagramy zbyt szybko. W tym przypadku host docelowy wysyła potwierdzenie otrzymanej ramki, ale za­ nim dotrze ono do hosta źródłowego, czasomierz retransmisji wygasa. Host źró­ dłowy przyjmuje więc, że host docelowy ramki nie otrzymał, po czym retransmi­ tuje jej kopię. Powoduje to duplikację datagramów, zwiększając ruch i zatłoczenie w sied. Taki niepotrzebny ruch przyczynia się do wzrostu problemów zwłaszcza na powolnych łączach WAN, gdzie zasoby są w cenie.

Rozdział 8. ° PROTOKÓŁ STEROWANIA TRANSM ISJĄ (TCP)

255

W przeciwnym razie (gdy wartość bazowa czasomierza jest zbyt wysoka) może nawet dochodzić do zrywania połączeń. Jeśli host wysyłający nie będzie w odpo­ wiednim czasie wykrywał i retransmitował utraconych datagramów, aplikacja może się poddać i zamknąć połączenie.

Komunikaty utrzymywania przy życiu Każdy protokół połączeniowy musi w jakiś sposób podtrzymywać obwód logiczny między komunikującymi się procesami, nawet gdy nie są wymieniane żadne dane. TCP nie jest wyjątkiem — w tym celu wysyła kom unikat utrzymywania przy życiu (keepalive), nie zawierający danych warstw wyższych. Komunikaty te wykorzystuje do utrzymywania sesji przy życiu (stąd nazwa). Ponieważ nie zawierają one danych, wartość ich pola długości wynosi zero, a zatem nie wzrasta kolejny numer ACK.

Zatory TCP stosuje komunikaty utrzymywania przy życiu jako zwykły sposób podtrzy­ mywania sesji. Zwiększa to jednak obciążenie sieci. W zależności od liczby otwar­ tych połączeń TCP w danej sieci, komunikaty utrzymywania przy życiu mogą do­ dawać zbędne obciążenie do już zatłoczonego łącza. Nie użytkowane połączenia ze zdalnymi hostami powinny być zwalniane (zamykane), a otwierane tylko w razie potrzeby. Wyobraźmy sobie wszysddch użytkowników w naszej sieci oraz wszystkie skróty izmapowane dyski na ich komputerach lokalnych, wskazujące na hosty zdalne. Zapewniają one użytkownikom szybkie i łatwe podłączanie się do tych hostów oraz korzystanie z ich zasobów. Wszystkie te szybkie odwołania wymagają jednak otwierania i podtrzymywania odpowiadających im połączeń TCP, nawet gdy nie są one użytkowane. Warto zatem je porozłączać i odmapować dyski aktualnie nie­ używane lub już wykorzystane, a także ograniczyć liczbę skrótów na pulpicie użyt­ kownika służących do połączeń sieciowych. Takie postępowanie wytnie mnóstwo niepotrzebnego ruchu TCP, uwalniając potrzebną szerokość pasma, zwłaszcza na powolnych łączach WAN.

Sterowanie przepływem Sterowanie przepływem jest funkcją właściwości okien protokołu TCP. Pozwala ono zarządzać napływem danych do bufora odbiorcy tak, aby unikać jego przepeł­ niania. Jeśli host wysyłający transmituje dane szybciej niż odbiorca może je prze­ twarzać, host odbierający prosi nadawcę o stłumienie przepływu i wysyłanie mniej­ szej ilości danych do chwili, kiedy odbiorca będzie mógł przyjmować ich więcej. Czasami odbiorca otrzymuje przytłaczającą ilość danych. Wysyła wówczas pakiet tłumienia (choke packet), nakazujący nadawcy całkowite zatrzymanie transmisji. Gdy sytuacja zbliża się do poziomu krytycznego, może on nawet zamknąć sesję TCP.

256

TCP/IP. SZKOŁA PROGRAMOWANIA

Nagłówek TCP zawiera pole okna (por. rysunki 8.2 i 8.3). Przy każdej wymianie ra­ mek, łącznie z początkowym ustanawianiem sesji (ramki SYN), każda strona kon­ wersacji ogłasza drugiej stronie bieżący rozmiar swojego bufora odbiorczego (receive buffer). Przykładowe ogłaszanie okna pokazano na rysunku 8.23. Rys u n ek 8 .2 3 .

Oba hosty ogłaszają rozmiar okna równy 4096 (W IN =4096)

Re M onit«CapturoQ iptaji loolt y/tndowJJeip SouiccAdiess JO estAitkess |Lov*|Sum m eij>

£2

£ | q | s ia l s la to te la la te l »1 ©1 ol!

[192 -52 252 1] [192 42 252 20] [192 42 252 20] [192 42 252 1]

*[ V A Fw Heip.

TC? D-2921 S-23 SYK ACK-1545216001 SE !»4'*a56000 LEli-0 WIH-4096 64 64 TCP D=23 3-2921 ACK-49856001 PIH« 096

D ecode M atrix H ostTotto ProtocolD ist. Statistics press A

X

FI

^Starl|j| Q

££ *|j S| ^

A

I

>

i

Expbuna

|! ¡0MaxTime | [¿J

. |j

M ogę p rz y ją ć najw yżej 4 0 9 6 bajtów !

S e g m e n t nr 2 Segm ent nr 3 S e g m e n t nr 4 -O k n o = 1 024 bajty S e g m e n t nr 5 -

-jj0 2 4 j—>

W olniej! - O k n o = 0 b a jtó w K o n ie c w ysyła n ia !

Dla nadawcy okno jest wskaźnikiem ilości danych, które może wysyłać, zanim od­ biorca wysyłając ACK pozwoli mu na następne. Jeśli przez dłuższy przeciąg czasu utrzymuje się okno zerowe bez zmiany na dodatnie, w końcu zmusza ono połącze­ nie do zamknięcia. Warto zanotować, że nawet gdy na hoście istnieje okno zerowe, host ten nadal może wysyłać dane, ale odbierać może tylko ramki krytyczne, takie jak ACK czy RST lub URG. Na rysunku 8.25 widać przykład występowania okna zerowego (ramka 6). Ogła­ szane okno zerowe wskazuje hostowi wysyłającemu (w tym przypadku serwerowi FTP), żeby zatrzymał wysyłanie danych do chwili ogłoszenia okna dodatniego. Ogłaszanie okna zerowego zwykle oznacza, że host ogłaszający ma ograniczone za­ soby lub jest zajęty obsługiwaniem innych hostów i może być tym przytłoczony. Dopóki nie występuje ono zbyt często, okno zerowe nie sprawia kłopotów. Ciągłe ogłaszanie tego okna przez hosta oznacza zwykle, że potrzebuje on więcej pamięci, większej mocy procesora (CPU) lub przerzucenia większej liczby aplikacji na inne hosty. Okno zerowe trwające przez dłuższy okres spowoduje zamknięcie połączenia.

258

TCP/IP. SZKOŁA PROGRAMOWANIA

Rys u n e k 8 .2 5 .

Host za pomocą pakietu ttumienia może powstrzymać hosta wysyłającego od transmitowania kolejnych danych

Porty TCP Do ustanawiania relacji typu klient-serwer (kliencko-serwerowych) protokół TCP stosuje porty standardowe (warstwy transportowej). Określają one, które procesy warstw wyższych wysłały lub powinny otrzymać strumienie danych. Listę numerów niektórych portów standardowych TCP zawiera tabela 8.1. T A B E LA 8 .1 . Numery niektórych standardowych portów TCP Nr dziesiętny

Słowo kluczowe

Protokół

Opis

20

FTP-Data

TCP

Protokół przesyłu plików (Dane)

21

FTP

TCP

Protokół przesyłu plików (Sterowanie)

23

Telnet

TCP

Emulacja term inala

25

SMTP

TCP

Simple M ail Transfer Protocol (prosty protokół przesyłu poczty)

49

LOGIN

TCP

Login Host Protocol (protokół hosta logowania)

53

DNS

TCP/U DP

Domain Name Sen/ice (usługa nazw dom enowych)

63

VIA-FTP

TCP

VIA-Systems-FTP (FTP-VIA-Systemowe)

70

Gopher

TCP

Usługa plikow a Gopher

80

WWW

TCP

W orld W ide Web („O gólnoświatowa Pajęczyna” )

Rozdział 8. • PROTOKÓŁ STEROWANIA TRANSM ISJĄ (TCP)

259

Podsumowanie Protokół TCP jest zdefiniowany w RFC 793. Po wynalezieniu stal się standardowym protokołem Internetu, zapewniającym gwarantowane dostarczanie danych między hostami. Tworzy on dwukierunkowy potok komunikacyjny miedzy procesami hostów zdalnych, identyfikowanymi przez porty. TCP kontroluje komunikację między tymi procesami poprzez ustanawianie i zrywanie sesji, zwielokrotnianie, przesył danych, sterowanie przepływem, niezawodność oraz poprzedzanie i zabezpieczenia. Aby gwarantować dostarczanie danych, TCP sekwencjonuje każdy bajt wysyłany i wymaga stosownego potwierdzania przez drugą stronę każdego bajtu odebranego. W tym celu ustanawia i zrywa sesje za pomocą porozumienia trzyetapowego. Aby zarządzać wpływem danych do bufora odbiorczego, TCP wykorzystuje stero­ wanie przepływem. Dzięki mechanizmowi okienkowemu, obecnemu w nagłówku TCP, odbiorca może prosić nadawcę o spowalnianie, przyspieszanie lub zatrzymy­ wanie transmisji (zależy to od ilości danych, które jego bufor może przyjmować). Proces ten nosi nazwę oknowania lub mechanizmu okna przesuwnego.

Pytania sprawdzające 1. Jakie sześć podstawowych funkcji wykorzystuje TCP w trakcie swojego działania do kontroli komunikacji między procesami hostów zdalnych? 2. Co musi nastąpić, zanim aplikacje warstw wyższych będą mogły wymieniać znaczące dane? 3. Co pozwala TCP ustanawiać i podtrzymywać wiele ścieżek komunikacyjnych między hostami naraz? 4. TCP otrzymuje od aplikacji warstw wyższych________ , organizuje je w _______ , które przekazuje w dół, do warstwy sieciowej, gdzie staną się _______. 5. Jaki mechanizm steruje wejściowym potokiem danych? 6. W jaki sposób TCP zapewnia niezawodne dostarczanie pakietów? 7. Jakich sześć podstawowych cech charakterystycznych mają protokoły połącze­ niowe? 8. Czym jest łączenie gniazd w pary? 9. Kiedy występuje retransmisja danych? 10. Jakie pola zawiera nagłówek TCP?

260

TCP/IP. SZKOŁA PROGRAMOWANIA

PROTOKOŁ DATAGRAMOW UŻYTKOWNIKA (UDP) Przegląd treści rozdziału: o

Działanie UDP

o

Porty UDP

o

Nagłówek UDP

rotokół datagramów użytkownika (UDP), opisany w RFC 768, oferuje szyb­ kie choć zawodne dostarczanie komunikatów między aplikacjami urucho­ mionymi na zdalnych hostach. Jest on przypisany do warstwy transporto­ wej OSI i DoD. Stanowi alternatywę dla powolnego lecz niezawodnego protokołu TCP (umieszczonego w tych samych warstwach). Miejsce protokołu UDP w mode­ lach DoD i OSI pokazano na rysunku 9.1. R ysunek 9.1.

Protokół UDP jest przypisany do warstwy transportowej modelów OSI i DoD

DOD

OSI aplikacji

aplikacji

prezentacji sesji

W a

transportowa

i I

t w y

.

i

UDP

transportowa

fc u c ip r in w a

dostępu do sieci

tącza danych fizyczna

262

TCP/IP. SZKOŁA PROGRAMOWANIA

Działanie UDP Podobnie do TCP, protokół UDP otrzymuje strumień danych (komunikaty) od identyfikowanych przez porty aplikacji lub procesów warstw wyższych. Następnie dzieli te komunikaty na segmenty i podaje je w dół, do warstwy sieciowej, gdzie proto­ kół IP przekształca je w datagramy, przeznaczone do doręczenia hostowi zdalnemu poprzez intersieć. UDP jest identyfikowany w nagłówku IP przez typ protokołu równy 17 (por. rysunek 9.2). Rys u n ek 9 .2 . T y p p ro to k o łu ró w n y 1 7 id e n ty fik u je U D P w n a g łó w k u IP

Sn illci Pro - Lo cal/ln tcl ElhciE xpicts PRO/100B PCI Ethernet Adaplcr (TX)_1 * ISnmp.enc : 1/1 SD Ethernet liâmes] £E £2e Mordor

cs|H | No.

Capture fiisploy Tool: Window Help

aD I

¡B lfa la lia tla la lg l

l5cu:ce Addis:: 0 DLC :

Qdlc Q DLC Qdlc j - Q DLC - Q DLC Q DLC

lD s:!A d d ic::

p\

& oil IL j-IEI

ICUT"'..:,

■ DLC Header ■ Frame 1 arrived at 12:49:05.1394; frame size is 129 (0081 hex) bytes. Destination ■= Station Sun01E954 Source = Station DECnet07F2Fl Ethertype ■=> 0800 (IP)

ó-r;

_ IP : ! - Q l P : Version “ 4, header length ! 20 bytes -Q I P : Type of service = 00 0 0 0 .............. routine -Q I P : normal delay - Q IP : . . . 0 ____ normal throughput Q IP : normal reliability i- Q IP : 115 bytes -Q I P: Total length 51521 Q I P : Identification OX Q I P : Flags . 0 ................. m a y fragment Q IP : last fragment .. 0 .... Q IP : 0 bytes Q I P : Fragment offset 30 seconds/hops Q I P : Time to live 17 (UDP) Q I P : Protocol CC0F (correct) O IP : Header checksum = [130.128.1.1] : Q I P : Source address Q IP : Destination address = [130.128.1.40] Q IP : No options D IP :

0. . . 0. .

Inaczej niż TCP, protokół UDP nie ustanawia sesji. Jako protokół bezpołączeniowy nie sekwencjonuje danych wysyłanych ani potwierdza ich otrzymywania. UDP za­ kłada, że jakiś inny protokół (zwykle warstwy wyższej) będzie śledził osiąganie celu przez dane. Gdy nie dotrą one do celu, uzna że ten inny protokół powinien rozpo­ znać sytuację i zażądać ich retransmisji. Ponieważ UDP nie tworzy połączenia, nie musi przed transmisją ustanawiać obwodu logicznego. Z tego też powodu nie od­ powiada za podtrzymywanie połączenia. UDP nie fragmentuje — jedynie identyfikuje porty źródłowy i docelowy. Protokół ten stwarza dwukierunkowy potok między komunikującymi się urządzeniami, za­ danie fragmentacji i ponownego składania zostawiając protokołowi IP. Protokół UDP działa na bardzo prostej zasadzie — dostarczania w miarę możności (najlepiej jak potrafi). O ile TCP gwarantuje dostarczanie danych, sekwencjonując i potwierdzając każdy pojedynczy bajt wysyłany lub otrzymywany, UDP tylko do­ starcza jak może, w zadaniach wykrywania i odzyskiwania datagramów utraco­ nych lub spóźnionych polegając na innych warstwach. Mimo tej wady ma nad TCP

Rozdział 9. • PROTOKÓŁ DATAGRAMÓW UŻYTKOW NIKA (UDP)

263

jedną przewagę — szybkość. Uproszczona natura UDP radykalnie zmniejsza obcią­ żenie związane z transmisją danych, wskutek czego jest on dużo szybszą, choć za­ wodną, alternatywą dla protokołu TCP.

Aplikacje UDP W zależności od wymaganego przez aplikację typu obsługi, dostawcy mogą w war­ stwie transportowej stosować protokół TCP lub UDP. Na przykład większość aplikacji drukowania (sieciowego) wykorzystuje protokół TCP, gdyż większość użytkowni­ ków chce mieć gwarancję — a nie tylko nadzieję — pomyślnego wykonywania za­ dań wydruku. Dwa protokoły warstw wyższych, oba służące do przesyłu plików między hostami — protokół przesyłu plików (FTP, File Transfer Protocol) i trywial­ ny protokół przesyłu plików (TFTP, Trivial File Transfer Protocol) — zapewniają podobne funkcje, ale korzystają z innych protokołów warstwy transportowej. FTP korzysta z usług TCP, gwarantujących pomyślną realizację przesyłu plików, w tym wykrywanie i naprawianie błędów wynikających z utraty, spóźniania się lub dupli­ kacji datagramów. Protokół FTP zwykle służy do przesyłania danych o znaczeniu krytycznym (najistotniejszych). TFTP korzysta natomiast z usług UDP, zapewniających szybsze dostarczanie i mniejsze obciążenie (niższy narzut pracy). Wadą takiej metody dostarczania jest słaba nie­ zawodność, tym niemniej z nazwy wynika, że protokół TFTP jest przeznaczony do szybkiego przesyłania plików trywialnych (małych). Jak widać, w zależności od te­ go, co jest ważniejsze — szybkość czy niezawodność — dostawcy mogą wybierać stosowany protokół warstwy transportowej. Protokół TFTP zakłada istnienie nastę­ pujących warunków: > Stabilność infrastruktury sieciowej; t> Możliwość występowania tylko trywialnych błędów dostarczania (lub żadnych). Protokół FTP dokładnie omówimy w rozdziale 12, a TFTP — w rozdziale 16.

Forty UDP Jako protokół bezpołączeniowy, UDP nie sekwencjonuje i nie potwierdza danych. Po prostu identyfikuje on w swoim nagłówku porty wysyłający (źródłowy) i odbie­ rający (docelowy), a zadanie spakowania i dostarczenia danych zostawia protoko­ łowi IP. Listę typowych portów UDP zawiera tabela 9.1 (bardziej obszerna lista znajduje się w dodatku C).

264

TCP/IP. SZKOŁA PROGRAMOWANIA

TABELA 9.1. Typowe porty UDP Nr dziesiętny

Słowo kluczowe

Protokół(-oły)

53

DNS

TCP/U DP

Opis Domain Name Service (usługa nazw dom enowych)

67

BootPS

UDP

Bootstrap Protocol Sen/er (serwer protokołu rozruchu wstępnego)

68

BootPC

UDP

Bootstrap Protocol Client (klient protokołu rozruchu wstępnego)

69

TFTP

UDP

tryw ia lny protokół przesyłu plików

80

SNMP

UDP

Simple Netw ork Management Protocol (prosty protokół zarządzania siecią)

N a g łó w e k U D P W rozdziale 8 omówiliśmy pola nagłówka TCP i ich funkcje. Nagłówki TCP mogą mieć różną długość, zależną od wykorzystywanych opcji TCP, ale zawsze nie mniejszą niż 20 bajtów. Z kolei bezpołączeniowy protokół UDP zawiera w swoim nagłówku tylko minimum informacji. Dla porównania, nagłówki UDP mają długość zaledwie 8 bajtów. Schemat nagłów­ ka UDP, zdefiniowany w RFC 768, przedstawiono na rysunku 9.3. Z kolei na ry­ sunku 9.4 pokazano przykład rzeczywistego nagłówka UDP, występującego w konkretnej sytuacji.

Uwaga Tak jak TCP, UDP musi identyfikować porty źródłowy i docelowy. Inaczej niż TCP, UDP nie uwzględnia sekwencjonowania ani potwierdzeń. UDP posługuje się swoją sum ą kontrolną, w ykryw ającą tylko uszkodzenia ramek.

Rys u n ek 9 .3 .

Format nagłówka UDP. Nagłówek taki zawiera tylko 8 bajtów

P o rt ź ró d ło w y

P o rt d o ce lo w y

D łu g o ść

S u m a kontro ln a

D ane

U D P nie z a w ie ra z b y t d u ż o in fo rm a c ji

13 b | a \ 3 \ ¡ s l a d & l i m l a l a l & l n \ & | Na

ISouceAddict. TIP: Q IP: Q IP: a IP: a IP: a IP: a IP: aip: a IP: a IP: a IP: a IP: a IP: a IP: a IP: a IP: a IP: aiP: a IP: aiP: a IP: 3 DU D P : a udp a udp a udp a udp a udp a udp

lD«lAd±es:

265

1

I

s

J2 £fc Mon.tor

!

Rys u n e k 9 .4 . J a k w id a ć , n a g łó w e k

1

Rozdział 9. • PROTOKÓŁ DATAGRAMÓW UŻYTKOW NIKA (UDP)

ol| Have,

iSumaan,

— - IP Header ----Version = 4 , header length = 20 bytes Type of service = 00 0 0 0 ..... = routine ...0 .... = normal delay .... 0... = normal throughput ..... 0.. = normal reliability Total length = 115 bytes Identification ° 51521 Flags = OX .0.......= m a y fragment ..0..... = last fragment Fragment offset ° 0 bytes Time to live = 30 seconds/hops Protocol = 17 (UDP) Header checksum = CC0F (correct) Source address = [130.1 2 B .1.1] Destination address = [130.128.1.40] No options ---- UDP Header ----Source port = 161 (SNMP) Destination port = 1112 Length = 95 Checksum = 0D1A (correct) f87 byte(s) of datal

Port źródłowy (Source Port) Dwubajtowe pole, podobnie jak w nagłówku TCP, identyfikujące aplikację lub pro­ ces warstwy wyższej hosta wysyłającego. Jego wartość zależy od rodzaju tego pro­ cesu (kliencki czy serwerowy). Porty procesów klienckich mieszczą się w zakresie 1 024 - 65 535, a serwerowych (w tym aplikacji powszechnie znanych) — w zakresie 0 - 1 023.

Port docelowy (Destination Port) Dwubajtowe pole, podobnie jak w nagłówku TCP, identyfikujące aplikację lub pro­ ces warstwy wyższej hosta odbierającego. Jego wartość zależy od rodzaju tego pro­ cesu (kliencki czy serwerowy). Porty procesów klienckich mieszczą się w zakresie 1 024 - 65 535, a serwerowych (w tym aplikacji powszechnie znanych) — w zakresie 0 - 1 023.

Długość (Length) Dwubajtowe pole określające całkowitą ilość danych zawartych w datagramie (w baj­ tach). Wartość ta obejmuje nagłówek UDP i następujące za nim dane (protokoły i informacje warstw wyższych), a więc wynosi przynajmniej 8 (tyle bajtów zawiera nagłówek) plus długość danych warstw wyższych (różnie w różnych sytuacjach).

266

TCP/IP. SZKOŁA PROGRAMOWANIA

Suma kontrolna (Checksum) Choć protokół UDP, jako bezpołączeniowy, nie ma mechanizmów wykrywania i naprawiania błędów wynikających z utraty, spóźniania się lub podwajania ramek, posiada jednak skromny sposób wykrywania ramek uszkodzonych. Zapewnia go dwubajtowe pole sumy kontrolnej, sprawdzające czy nie doszło do jakichś uszkodzeń podczas tranzytu. Nie gwarantuje to jednak naprawiania takich ramek, a tylko ich wykrywanie i unicestwianie. Najpierw proces UDP hosta wysyłającego oblicza sumę kontrolną, czyli CRC (Cyclic Redundancy Check), umieszczając ją w omawianym polu swojego nagłówka. Po dotarciu do celu proces UDP hosta odbierającego wykonuje to samo obliczenie, sprawdzając w ten sposób otrzymaną zawartość. Jeśli wartości CRC nie będą się zgadzać, host odbierający uzna, że wystąpił błąd transmisji i unicestwi wadliwy datagram. Suma kontrolna sprawdza poprawność następujących elementów: ► nagłówka UDP, ► danych warstw wyższych, ► informacji zawartych w pseudonagłówku UDP. Pseudonagłówek UDP składa się z 12 bajtów, obejmując niektóre pola z nagłówka IP. Pozwala on protokołowi UDP upewnić się, czy dane zostały dostarczone do właściwego miejsca, ale nie wchodzi w skład nagłówka UDP. Schemat pseudonagłówka UDP pokazano na rysunku 9.5. R y s u n e k 9 .5 .

Pseudonagłówek UDP pozwala protokołowi UDP upewnić się, że protokół IP nie dostarczył datagramów w niewłaściwe miejsca (takie jak niewłaściwy host czy nieodpowiedni protokół warstwy wyższej)

Ź ró d ło w y a d re s IP D o ce lo w y a d re s IP Z e ro

P ro to k ó ł IP

Pseudonagłówek UDP zawiera informacje następujące: ► Adres logiczny (warstwy sieciowej) hosta źródłowego; ► Adres logiczny (warstwy sieciowej) hosta docelowego; ► Typ protokołu warstwy transportowej; ► Długość datagramu UDP.

D łu g o ś ć U DP

Rozdział 9. » PROTOKÓŁ DATAGRAMÓW UŻYTKOW NIKA (UDP)

267

Nazwa „pseudonagłówek" bierze się stąd, że protokół UDP w istocie nie włącza tych informacji do własnego nagłówka. Śledzi on natomiast te informacje, żeby za­ bezpieczać się przed niewłaściwie kierowanymi datagramami. Host przechowuje informacje pseudonagłówka w pamięci, dzięki czemu może się do nich odwoływać protokół UDP.

Podsumowanie UDP jest zdefiniowany w RFC 768. Protokół ten oferuje szybkie, choć zawodne do­ starczanie komunikatów między aplikacjami uruchomionymi na zdalnych hostach. Obecny w warstwie transportowej, UDP otrzymuje strumień danych (komunikaty) od aplikacji lub procesów warstw wyższych. Następnie dzieli je na segmenty i po­ daje w dół, protokołowi IP warstwy sieciowej, który wysyła je jako datagramy do­ starczane do miejsca przeznaczenia przez sieć. Jako protokół bezpołączeniowy, UDP nie sekwencjonuje danych wysyłanych i nie potwierdza ich odbioru. Śledzenie, czy dane docierają do celu, pozostawia innym protokołom. Ponieważ UDP nie tworzy połączenia logicznego, nie musi zarządzać jego podtrzymywaniem. Protokół ten działa na zasadzie „dostarczam najlepiej jak potrafię". Choć nie gwarantuje dostarczania pakietów, jego uproszczona natura skrajnie zmniejsza koszty jego obsługi (powodowane przezeń obciążenie sieci). Dzięki temu stanowi on alternatywę dla powolnego protokołu TCP. Zależnie od typu obsługi, wymaganego przez aplikacje, ich dostawcy mogą stosować dla nich w warstwie transportowej protokół TCP lub UDP.

Pytania sprawdzające 1. Które RFC definiuje UDP? 2. Co zapewnia protokół UDP aplikacjom uruchomionym na zdalnych hostach? 3. Jaki typ protokołu identyfikuje UDP w nagłówku IP? 4. Jaki związek ma UDP z sekwencjonowaniem i potwierdzaniem odbioru wysyła­ nych danych? 5. Co zakłada protokół UDP podczas operacji przesyłania danych? 6. Za co odpowiada UDP w trakcie podtrzymywania połączenia? 7. Co takiego daje UDP, czego dać nie może TCP? 8. Jaki mechanizm stosuje UDP do wynajdywania uszkodzonych ramek? 9. Poprawność jakich trzech elementów sprawdza suma kontrolna? 10. Jakie informacje zawiera pseudonagłówek UDP?

268

TCP/IP. SZKOŁA PROGRAMOWANIA

PROTOKOŁY GÓRNEJ WARSTWY Przegląd treści rozdziału: o W arstwa aplikacji

o W arstwa sesji

•

•

W arstwa prezentacji

Protokoły górnej warstw y

Wprowadzenie do protokołów górnej warstwy Warstwa aplikacji modelu DoD traktuje trzy protokoły górnej warstwy modelu OSI — aplikacji, prezentacji oraz sesji — jako jedną warstwę. W warstwie aplikacji DoD można we współpracy z hostem korzystać z następujących funkcji: ► Przesyłania plików (FTP lub TFTP) ► Operacji typu Klient/Serwer za pomocą Sun Microsystems (NFS) ► Zdalnego dostępu (protokołu Telnet) ► Poczty elektronicznej (e-mail) (SMTP) ► Zarządzania siecią (SNMP) ► Przekształcania nazwy (DNS) Wszystkie wymienione wcześniej protokoły mają swoją specyfikę i przypisane są do różnych warstw modelu OSI, jednakże w modelu DoD występują jako jedna warstwa aplikacji. W tym rozdziale omówimy każdą z warstw modelu OSI, opi­ szemy ich funkcje oraz krótko scharakteryzujemy każdy z protokołów górnej war­ stwy (ULPs). Rysunek 10.1 przedstawia różne protokoły znajdujące się w warstwie aplikacji modelu DoD oraz pokazuje jak odnoszą się one do modelu OSI.

270

TCP/IP. SZKOŁA PROGRAMOWANIA

W ars tw a A R PA

Aplikacji

Z a s to s o w a n ie p ro to k o łu Przesyłanie

Przesyłanie

hypertekstu Protokół przesyłania hipertekstu (HTTP) RFC 2068

plików

Poczta elektroniczna

Emulacja Terminala

Nazwy dom en

Protokół przesyłania plików (FTP)

Prosty P rotokół przesyłania poczty elektronicznej

Protokół TELNE T

System N azw dom en (DNS)

M IL-STD -1780

(SM TP) M IL-STD-1781

MIL-STD -1782

RFC 9 59

RFC 821

RFC 854

W arstw a OSI Przesyłanie plików Trywialny Protokół przesyłania plików (TFTP)

RFC 1 0 34 ,1 03 5

P rotokół sterow ania tran sm isją (TCP) Transportowa

Sieciow a

Klient/Serw er

Zarządzanie siecią

Protokoły S ieciow ego Protokół Prostego system u plików Sun zarządzania s ie c ią M icrosystem (NSF) (SNMP)

RFC 783

RFC 1014,

v1: R FC 1157 v2: RFC 1901-10

1057 i 1094

v3: RFC 2 271-75

Protokół d atagram ów użytkow nika (UD P )

MIL-STD -1778 RFC 793

Aplikacji

Prezentacji

Sesji

Transportowa

RFC 768

Przekształcanie adresu AR P RFC 826 RARP RFC 903

Protokół Internetu (IP) MIL-STD-1778 RFC 791 Karty interfejsów sieciowych: E thernet, Token Ring, ARCNET, MAN i W AN

Protokół k om unikatów sterujących Internetu (ICMP)

Sieci

RFC 792

Łącza danych

R FC 894, RFC 1042, RFC 1201 I inne

□ostępu d o sieci.

M edia transm isyjne: Fizyczna Przewód s ieciow y "skrętka", koncentryk, św iatłowód, m edia bezprzewodow e, itp.

R ysunek 1 0 .1 . N a le ży z w ró c ić u w a g ę , iż trz y o d d z ie ln e w a rs tw y m o d e lu OSI o d p o w ia d a ją w a rs tw ie a p lik a c ji (g ó rn e j w a rs tw ie ) m o d e lu D oD

W przeciwieństwie do pozostałych warstw modelu OSI oraz DoD, górne warstwy nie są niewidoczne dla użytkownika końcowego. Użytkownicy mogą uzyskać do­ stęp do górnej warstwy bezpośrednio przez system operacyjny hosta. Użytkownicy końcowi korzystają z górnej warstwy w celu przeprowadzenia zadań takich jak: przesyłanie plików, zarządzanie siecią, poczta elektroniczna, itp.

Warstwa aplikacji Wiele osób myli w arstw ę ap likacji z ap likacjam i takimi jak Word, Excel, PowerPo­ int, itp. Warstwę aplikacji należy kojarzyć z otwartym oknem, które umożliwia do­ stęp do modelu OSI. Warstwa aplikacji umożliwia zainstalowanym aplikacjom przesyłanie danych poprzez sieć. Umożliwia po prostu dostęp do dolnych warstw — jest oknem do modelu OSI. Jeżeli wysyłamy na przykład wiadomość elektroniczną, musimy określić jakie dane chcemy przesłać. Oczywiście, warstwa aplikacji przygotowuje dane dodając na­ główek oraz informacje kontrolne dla warstwy równorzędnej, zanim zostaną one przekazane do kolejnej warstwy i przesłane w końcu przez przewód. Warstwa aplikacji zapewnia dostęp do usług na rzecz plików oraz drukowania; na przykład, readresator klienta oparty na Microsoft SMB oraz responder serwera, które są im­ plementowane jako sterowniki systemu plików (analogicznie, RDR.sys i SRV.sys) Jeżeli korzystamy z systemu Windows NT, readresator klienta pracuje jako protokół warstwy aplikacji. Zgłaszając zapytanie o plik oraz usługę drukowania do zdalnego serwera NT, readresator klienta przygotowuje informacje dla następnej warstwy.

Rozdział 10. • PROTOKOŁY GÓRNEJ W ARSTWY

27 1

Sąsiadująca warstwa otrzymuje je gotowe do wysłania przez łącze. Jeżeli przesyła informacje do hosta znajdującego się w oddaleniu, warstwa odbierająca na przeciw­ ległym końcu znajduje się w warstwie aplikacji. U hosta zdalnego warstwa ta odpo­ wiada usłudze serwera; dlatego część odpowiadająca za zapytania klienta oraz część spełniająca funkcję respondera serwera w Windows NT zapewniają obsługę zapy­ tania i odpowiedzi w imieniu aplikacji (rozumiane jako usługi w arstw y aplikacji). Należy pamiętać, że warstwa aplikacji zapewnia dostęp do stosu protokołu. Usługi warstwy aplikacji to: ► Aplikacje z usługami sieciowymi i międzysieciowymi ► Usługi na rzecz plików i drukowanie ► Poczta elektroniczna ► Dostęp do sieci Web oraz HTTP ► Dostęp poprzez Telnet do zdalnego hosta ► Przesyłanie plików (FTP i TFTP)

W o rld W Ide W eb (siec W W W ) i H T T P (p ro to k ó ł przesyłania h ip e rte kstu ) Praktycznie każdy na tej planecie słyszał już o World Wide Web (sieci WWW), ale większość nie wie, że to protokół HTTP zapewnia użytkownikom dostęp do sieci. Kluczowy mechanizm dla komunikacji WWW, HTTP, umożliwia przesyłanie do­ kumentów typu Web z serwera do przeglądarki za pomocą TCP oraz podstawowej architektury klient/serwer. Strony WWW składają się z dokumentów typu hipermedia. Przedrostek hiper oznacza, że dokument może składać się z odnośników odwołujących się do skorelowanych dokumentów; na przykład, odnośniki do stron WWW zawierających informacje o Picassie. Człon m edia oznacza składowe inne niż prosty tekst, takie jak obrazy multimedialne. Jeżeli chcemy uzyskać dostęp do strony Web, wpisujemy URL (jednolity lokalizator zasobów). URL identyfikuje konkretną stronę WWW, a każda strona WWW posia­ da przypisaną, identyfikującą ją unikalną nazwę. Wpisując zapytanie, lub URL, uaktywniamy przeglądarkę WWW (klienta) w celu nawiązania przez nią kontaktu z serwerem i uzyskania dostępu do pożądanej strony. HTTP umożliwia komunika­ cję pomiędzy przeglądarką a serwerem WWW lub pomiędzy urządzeniami po­ średniczącymi, takimi jak bramki i ściany ogniowe (firewalls). W rozdziale 15 protokół HTTP zostanie omówiony bardziej szczegółowo.

272

TCP/IP. SZKOŁA PROGRAMOWANIA

Poczta elektroniczna oraz SMTP (prosty protokół przesyłania poczty elektronicznej) Poczta elektroniczna (e-mail) umożliwia wysyłanie wiadomości poprzez Internet za pomocą standardowej architektury klient/serwer. Architektura klient/serwer umożliwia obu stronom wysyłanie, przechowywanie i otrzymywanie wiadomości. SMTP dyktuje standard dla wymiany poczty elektronicznej pomiędzy komputerami. Systemy pocztowe wykorzystują technikę nazywaną spooling. Jeżeli wysyłamy do kogoś wiadomość, system przechowuje tą wiadomość (dane) w odosobnionym buforze (nazywanym spool) wraz z adresem docelowym (skrzynia pocztowej lub adresem poczty elektronicznej), nazwą nadawcy, nazwą odbiorcy oraz informacją 0 czasie wysłania wiadomości. Następnie system przesyła wiadomość do oddalonego komputera. Umożliwia to nadawcy kontynuowanie pracy na własnym komputerze po wysłaniu wiadomości, bez czekania, aż odbiorca otworzy wiadomość. Zdalny komputer klienta korzysta z systemu nazw domen (DNS) aby ustalić adres IP odbiorcy i ustanowić połączenie TCP z serwerem pocztowym. Jeżeli połączenie zostało ustanowione, komputer przesyła kopię wiadomości do serwera pocztowego, który przechowuje ją w obszarze spool, aby mogła zostać odebrana przez adresata. W rozdziale 13 protokół SMTP zostanie omówiony bardziej szczegółowo.

Telnet (sieć telekomunikacyjna) Jest trzecia nad ranem i bardzo chce nam się spać, ale musimy jeszcze sprawdzić coś na komputerze znajdującym się poza domem. Prawdopodobnie wolelibyśmy sko­ rzystać z protokołu Telnet zamiast jechać w pidżamie samochodem do pracy. Tel­ net umożliwia (klientowi) uzyskanie dostępu przez terminal do oddalonego hosta (serwera). Korzystając z TCP, Telnet umożliwia komunikowanie się za pomocą klawiatury podłączonej do własnego komputera, tak jakby była ona podłączona bezpośrednio do zdalnego komputera. Ścieżka danych prowadzi z klawiatury do systemu operacyjnego klienta, a następnie poprzez połączenie TCP do zdalnego systemu operacyjnego (serwera). Telnet wykorzystuje wirtualny terminal sieciowy (NVT — Network Virtual Termi­ nal) aby umożliwić kanoniczne (standardowe) przedstawienie danych. Telnet umożliwia również klientowi oraz serwerowi negocjację opcji. Telnet zapewnia do­ datkowo symetrię składni negocjacyjnej, która umożliwia zarówno klientowi jak 1 serwerowi żądać określonych opcji podczas połączenia. W rozdziale 11 protokół Telnetu zostanie omówiony bardziej szczegółowo.

Rozdział 10. • PROTOKOŁY GÓRNEJ W ARSTWY

273

Przesyłanie plików Dwa protokoły zapewniające możliwość przesyłania plików znajdują się w war­ stwie aplikacji: FTP(protokół przesyłania plików) oraz TFTP (trywialny protokół przesyłania plików). Częściej używany jest FTP niż TFTP; FTP jest odpowiedzialny za znaczną część przesyłów TCP/IP. Oba protokoły umożliwiają przesyłanie (od­ czyt lub zapis) plików z własnego komputera do komputera zdalnego. Niektóre firmy stosują serwery plików zamiast droższych komputerów z własnymi pamię­ ciami dyskowymi. Niezależnie od protokołu na jaki się zdecydujemy, umożliwia on i dyktuje sposób przesyłania plików pomiędzy systemem klienta, a systemem serwera. FTP wykorzystuje dwa rodzaje połączeń TCP: jedno dla danych, drugie do kontro­ li. Daje to gwarancje przesiania plików , mimo że powoduje spowolnienie. TFTP korzysta z UDP, który nie gwarantuje dostarczenia pliku ale umożliwia szybki transfer między komputerami. W rozdziale 16 protokół TFTP zostanie omówiony bardziej szczegółowo.

Warstwa prezentacji Warstwa prezentacji jest szóstą warstwą modelu OSI, znajdującą się zaraz poniżej warstwy aplikacji. W warstwie tej dane wciąż mają postać wiadomości, która zosta­ nie przekazana do warstwy sesji. Podstawowym zadaniem warstwy prezentacji jest zapewnienie wspólnego formatu danych dla różnych platform. Innymi słowy, war­ stwa prezentacji tłumaczy informacje pochodzące z warstwy aplikacji na język zro­ zumiały dla wszystkich pozostałych warstw. Do zadań warstwy prezentacji należą: > Konwersja i tłumaczenie danych Kompresja/dekompresja Kodowanie/odkodowywanie > Multimedia i dźwięk Tabela 10.1 przedstawia najczęściej używane protokoły warstwy prezentacji. Tabela 1 0 .1 . Powszechnie używane protokoły warstwy prezentacji Typy

Protokoły

Protokoły związane z danym i i tekstem

ACII, EBCDIC, Kodowanie/odkodowywanie

Protokoły związane z grafiką i obrazami

TIFF

Protokoły w arstw y prezentacji

JPEG, PICT, GIF

Protokoły m ultim edialne

MIDI, MPEG, QuickTime

274

TCP/IP. SZKOŁA PROGRAMOWANIA

Część protokołów istniała zanim wprowadzony został model OSI i są nadal w uży­ ciu w ramach aktualnego modelu OSI. Oznacza to, że istnieje tylko kilka prawdzi­ wych protokołów warstwy prezentacji, a większość protokołów górnej warstwy nie „wpasowuje" się zbyt dobrze do modelu OSI. Większość producentów opracowało protokoły obejmujące wszystkie trzy górne warstwy, pomijające niektóre warstwy lub wykonujące funkcje we wszystkich trzech warstwach. Producenci decydują, które protokoły górnych warstw będą funkcjonować na poszczególnych poziomach; dlatego niektóre protokoły mogą pełnić funkcje warstwy prezentacji, ale również spełniać funkcje innych protokołów górnej warstwy. Mówiąc krótko, trudno jest znaleźć prawdziwy protokół warstwy prezentacji. Jest jeden prawdziwy protokół warstwy prezentacji: XDR (zewnętrzna prezentacja danych — External Data Representation). Sun Microsystem wykorzystuje XDR w swoim sieciowym systemie plików NFS (Network File System) opartym na ar­ chitekturze klient/serwer. NFS wykorzystuje ten protokół, wcielony do kodu pro­ gramu, aby zapewnić niezależność platformową. W rozdziale 16 protokoły XDR i NFS zostaną omówione bardziej szczegółowo.

Warstwa sesji Warstwa sesji jest piątą warstwą modelu OSI, znajduje się zaraz pod warstwą prezenta­ mi. W warstwie tej dane przedstawione są wdąż w formie wiadomośd, przed przeka­ zaniem do warstwy transportowej. Jest to ostatnia warstwa, w której dane mają format wiadomości, zanim zostaną one podzielone na segmenty w warstwie transportowej. Warstwę sesji należy kojarzyć z koordynatorem działań. Warstwa ta koordynuje dialog pomiędzy dwoma aplikacjami (górnej i dolnej warstwy), a następnie zarzą­ dza czynnością komunikowania każdej ze stron, monitoruje dialog oraz, jeżeli jest to konieczne, przerywa sesję. Warstwa sesji kontroluje również rodzaj oraz efektywność komunikacji pomiędzy dwoma aplikacjami. Komunikacja między aplikacjami może odbywać się w trybie połowicznie dwukierunkowym (half-duplex) oraz transmisji w pełni dwukiemnkowej (full-duplex). W trybie połowicznie dwukierunkowym jednoczesna transmisja jest możliwa tylko przez jedno urządzenie, podobnie jak w przypadku radia. Tryb w pełni dwukierunkowy umożliwia prowadzenie symultanicznej transmisji przez oba urządzenia. Warstwa sesji zawiera następujące protokoły: t> NetBIOS > SQF > X Windows > RPC

Rozdział 10. • PROTOKOŁY GÓRNEJ W ARSTWY

275

NetBIOS (Network Basic Input Output System) — interfejs programowy aplikacji Wynaleziony przez IBM oraz Sytek, NetBIOS umożliwia aplikacjom komunikowa­ nie się z urządzeniami sieciowymi. NetBIOS zapewnia cztery główne usługi: usługę nazewniczą, usługę sesji, usługę datagramu oraz funkcje różnorodne (miscellanoeus function). W tej książce skoncentrujemy się na usłudze nazewniczej. NetBIOS zapewnia użytkownikom prosty sposób na uzyskanie dostępu do zewnętrz­ nych usług oraz zasobów korzystając z nazwy zamiast adresu. NetBIOS transmitując rozgłoszenie wykonuje przekształcenia nazwy, zwracając się z zapytaniem do lo­ kalnego segmentu. Modyfikacje NetBIOS umożliwiają mu funkcjonowanie w trzeciej warstwie poprzez zastosowanie TCP/IP. W rozdziale 14 protokół NetBIOS zostanie omówiony bardziej szczegółowo.

Sieciowy system plików NFS (Network File System) oraz protokoły ONC Opracowany pierwotnie przez Sun Microsystems, protokół NFS umożliwia grupie współpracujących komputerów dokonywanie wymiany plików, tak jakby znajdo­ wały się w sieci lokalnej. Wymiana plików jest niewidoczna dla użytkownika. Nie­ które firmy wykorzystują NFS do łączenia swoich systemów plików. NFS przyporządkowany jest do warstwy aplikacji, lecz wymaga dwóch innych protokołów — aby mógł funkcjonować: XDR (eXtemal Data Representation) oraz RPC (Remote Procedurę Cali). Jak sugeruje jego nazwa, XDR przynależy do war­ stwy prezentacji. Natomiast RPC rezyduje w warstwie sesji. Grupa protokołów (XDR, NFS i RPC) nazywana jest protokołami ONC (Open Network Computing). Ta rodzina protokołów, wspólnie umożliwia korzystającym z różnych technologii niekompatybilnym systemom uzyskiwanie dostępu do plików w sposób transparentny, obsługując również technologie typu PC — mainframe. Język opisu danych — XDR zapewnia jednolitą reprezentacje danych pomiędzy różnymi implementacjami NFS. Niezależny transportowo protokół wiadomości — RPC umożliwia nawiązywanie transparentnej komunikacji pomiędzy klientem, a serwerem. W rozdziale 18, protokół ONC zostanie omówiony bardziej szczegółowo.

Podsumowanie Warstwa aplikacji modelu DoD traktuje trzy protokoły górnej warstwy modelu OSI — aplikacji, prezentacji oraz sesji — jako jedną warstwę. W warstwie aplikacji DoD można współpracować z hostem, aby spełniać funkcje użytkownika. W warstwie tej

276

TCP/IP. SZKOŁA PROGRAMOWANIA

możemy korzystać z następujących funkcji: przesyłania plików, operacji typu klient/ serwer, zdalnego dostępu, poczty elektronicznej (e-mail), zarządzania siecią oraz przekształcania nazw. Trzy warstwy modelu OSI składające się na warstwę aplikacji modelu DoD to warstwy: aplikacji, prezentacji oraz sesji. Warstwa aplikacji umożliwia aplikacjom przesyłanie danych w sieci. Podstawowym zadaniem warstwy prezentacji jest zapewnienie wspól­ nego formatu danych dla różnych platform. Warstwa sesji koordynuje dialog po­ między urządzeniami sieciowymi.

Pytania sprawdzające 1. Z jakich trzech warstw modelu OSI składa się warstwa aplikacji modelu DoD? 2. Jaka jest podstawowa funkcja warstwy aplikacji DoD? 3. Jakie protokoły przyporządkowane są warstwie aplikacji? 4. Jaka jest podstawowa funkcja warstwy prezentacji? 5. Jaka jest podstawowa funkcja warstwy sesji? 6. Jakie protokoły składają się na ONC i do jakich warstw są przyporządkowane?

TELNET Przegląd treści rozdziału: o Relacje klient-serwer protokołu Telnet

o W irtualny Term inal Sieciowy (N etw ork Virtual Term inal — NVT)

o

o Opcje protokołu Telnet

Podstawowe usługi protokołu Telnet

Komunikacja zewnętrzna Protokół Telnet (Sieć Telekomunikacyjna) umożliwia użytkownikowi uruchamianie klienta sesji terminala w celu uzyskania dostępu do zewnętrznego hosta (lub ser­ wera Telnet) poprzez Internet. Telnet współpracuje z TCP na zasadzie transportu połączeniowego, korzystając ze standardowego portu 23, umożliwiając terminalowi oraz hostowi wymianę 8-bitowych znaków danych. Telnet zaprojektowany jest w taki sposób, iż umożliwia pracę z dowolnym hostem oraz terminalem poprzez ustanowienie połączenia TCP z hostem zewnętrznym, co umożliwia wpisywanie poleceń poprzez klawiaturę, tak jakby podłączona była bezpośrednio do urządze­ nia zewnętrznego. Za pośrednictwem Telnetu możemy również odczytywać ko­ munikaty podawane przez zewnętrznego hosta. Relacja klient-serwer protokołu Telnet przebiega w sposób niewidoczny — oznacza to, iż powstaje wrażenie, iż klawiatura podłączona jest bezpośrednio do zewnętrznego hosta. Rysunek 11.1 przedstawia klienta i serwer Telnetu oraz obrazuje serię zdarzeń, które muszą zajść, aby doszło do ustanowienia sesji protokołu Telnet: 1. W momencie rozpoczęcia sesji protokołu Telnet, aplikacja na danym kompute­ rze staje się klientem. 2. Klient ustanawia połączenie TCP z serwerem Telnet (hostem zewnętrznym), ko­ rzystając ze standardowego połączenia trzyetapowego TCP, które zostało opisa­ ne w rozdziale 8.

278

TCP/IP. SZKOŁA PROGRAMOWANIA

Rys u n ek 1 1 .1 . D roga d a n y c h z k la w ia tu ry d o ze w n ę trz n e g o sy s te m u

Serwer przesyła do pseudoterminala

o p e ra c y jn e g o

3. Klient komunikuje się poprzez połączenie TCP korzystając z klawiatury tak jakby podłączona była bezpośrednio do terminala zewnętrznego hosta. 4. Serwer korzysta z urządzenia pseudoterminala. Urządzenia te określają punkt wejścia systemu operacyjnego, który umożliwia programowi takiemu jak Telnet przesyłanie danych do innych systemów operacyjnych, na takich samych zasa­ dach jakby pochodziły z klawiatury komputera lokalnego. Telnet wprowadzono w latach 70-tych kiedy urządzenia końcowe były bardzo dro­ gie i prymitywne, gdzie za przetwarzanie danych odpowiedzialny był zazwyczaj host zewnętrzny. Te proste terminale mogły przesyłać jednocześnie tylko jeden znak do zewnętrznego serwera, który wysyłał echo polecenia wydanego przez klienta z powrotem na jego ekran. Klienci potrzebowali tego rozwiązania ponieważ nie posiadali miejsca na przechowywanie lub przetwarzanie informacji. Dzisiaj do­ stępne są już inteligentne urządzenia, które utrzymują własne zasoby i przetwa­ rzają swoje lokalne dane jeżeli istnieje taka potrzeba, jednakże wciąż muszą emu­ lować oryginalny model. Nowoczesne urządzenia tego typu oferują różnego rodzaju tryby transmisji, takie jak tryb wierszowy, który powoduje, iż niektóre im­ plementacje Telnetu stają się bardziej wydajne. Jednakże nie wszystkie implemen­ tacje obsługują te tryby.

Tryby Transmisji Danych Istnieją różne tryby transm isji, w tym tryb znakowy oraz wierszowy. Tryb znakowy oznacza, że jednorazowo przesyłany jest jeden znak lub bit — jest to najmniej wy­ dajny sposób transmisji danych. Tryb wierszowy umożliwia przesyłanie całego wier­ sza danych w postaci jednego bloku, co umożliwia znacznie wydajniejszą transmisję.

Pomimo braku wyrafinowania w stosunku do pozostałych protokołów, admini­ stratorzy powszechnie korzystają z Telnetu do zdalnego administrowania oraz usuwania usterek. Zazwyczaj oprogramowanie klienta Telnetu umożliwia użyt­ kownikowi podłączenie się do zewnętrznego komputera poprzez podanie nazwy

Rozdział 11. • TELNET

279

IP oraz adresu IP hosta. Kiedy klient Telnetu zwraca się o rozpoczęcie sesji podając nazwę IP hosta, musi przekształcić najpierw tą nazwę na adres warstwy sieciowej, a następnie na lokalny adres sprzętowy. Jeżeli host próbuje ustanowić połączenie i podaje adres warstwy sieciowej, wystar­ czy jeżeli wykona ostatnie dwie wymienione wyżej czynności. Kiedy host lokalny zna już adres sprzętowy, może zaadresować na niego datagram. TCP może wów­ czas ustanowić połączenie pomiędzy hostami, umożliwiając w ten sposób działanie protokołu Telnet. W rozdziale 14 przekształcanie nazw zostanie omówione bardziej szczegółowo. Telnet rezyduje w trzech górnych warstwach (aplikacji, prezentacji i sesji) modelu OSI lub w warstwie aplikacji modelu DoD (patrz rys. 10.1 w rozdziale 10). W modelu OSI układ ten ma swoje zalety oraz wady. Oczywistą zaletą Telnetu są stwarzane przez niego możliwości, jakie daje administratorom, umożliwiając modyfikacje działania nie podłączonego bezpośrednio urządzenia. Dodatkowo, kod nie jest wbudowany wewnątrz systemu operacyjnego, co ułatwia korzystanie z niego administratorowi. Jednakże, Telnet jest mimo wszystko mało wydajny. Należy mieć na uwadze, iż wykonanie każdego przyciśnięcia klawiatury generuje następujący ruch: 1. Poprzez system operacyjny klienta. 2. Od klienta poprzez intranet lub Internet do serwera. 3. Przez system operacyjny serwera. 4. Z powrotem do klienta, dostarczając dane dla aplikacji, z której korzysta użyt­ kownik. W międzyczasie dane w postaci wyświetlanej na ekranie muszą przebyć tą samą drogę powrotną do klienta. Powoduje to znaczne obciążenie, i z tego powodu jest to nieefektywny sposób wykorzystywania zasobów. Ponadto proces ten zachodzi w trakcie sesji TCP, która wymaga aby każda transmisja odbywała się w sekwen­ cjach za potwierdzeniem zwrotnym, zwiększając dodatkowo obciążenie. Korzysta­ jąc z Telnetu zyskujemy pewność kosztem dodatkowego narzutu obciążenia.

Usługi podstawowe RFC 854 opisuje trzy podstawowe usługi Telnetu, natomiast RFC 855 opisuje różne opcjonalne możliwości Telnetu. Opcje te omówimy w dalszej części tego rozdziału. Telnet oferuje trzy podstawowe usługi: 1. Wirtualny terminal sieciowy (NVT), który zapewnia interfejs do obsługi systemów zewnętrznych 2. Zdolność do negocjowania przez klienta oraz serwer różnych opcji 3. Symetryczny widok terminala oraz przetwarzania.

280

TCP/IP. SZKOŁA PROGRAMOWANIA

Wirtualny terminal sieciowy Telnet komunikuje się korzystając z protokołów TCP/IP w oparciu o zestaw stan­ dardów sieciowych (zwanych również kanonami lub formami standardowymi), znanych jako Wirtualny terminal sieciowy (NVT). NVT zapewnia przezroczystość komunikacji pomiędzy klientami i obsługę dla minimalnego zestawu opcji. Poprzez utworzenie wirtualnego terminala, ukrywane są różnice pomiędzy urządzeniami komunikacyjnymi i zapewniony zostaje wspólny zestaw poleceń, co sprawia, iż wszystkie urządzenia komunikacyjne działają na równych zasadach. Korzystając z Telnetu, klient końcowy lub użytkownik jest odpowiedzialny za za­ mianę przychodzących kodów NVT na właściwe kody, wymagane przez urządze­ nie wyświetlające (np. monitor), zapewniając jednolitość komunikacji pomiędzy różnymi systemami. Jest on również odpowiedzialny za przekształcanie sekwencji wprowadzanych z klawiatury na sekwencje NVT. RFC 854 definiuje NVT jako wirtualne urządzenie, które wymusza na systemie operacyjnym klienta mapowanie rodzaju terminalu, z którego korzysta użytkownik na NVT, emulując powszechnie znane terminale, takie jak IBM 3270, VT100, VT200, itd. Następnie serwer mapuje NVT na dowolny terminal przez siebie obsługiwany. Jeżeli dane zostaną już prze­ kształcone w postać kanoniczną lub standardową przez obydwa urządzenia koń­ cowe, mogą one się komunikować niezależnie od posiadanych rodzajów terminali (np. jeżeli jeden z nich to DEC VT-100).

NVT ASCII (American Standard Code for Information Interchange — standardowy amerykański kod wymiany informacji) Zdefiniowany format NVT wykorzystuje 7-bitowy kod ASCII posługując się inter­ netowym zestawem protokołów dla znaków i urządzeń wyświetlających (np. mo­ nitor). Kod ASCII transmitowany jest w 8-bitowych oktetach, gdzie wartość naj­ istotniejszego bitu wynosi 0. RFC definiuje urządzenie wyświetlające jako drukarkę umożliwiającą drukowanie standardowych znaków ASCII, reprezentowanych przez 7-bitów, oraz rozpoznające i przetwarzające określone kody kontrolne.

____________________________ ASCII____________________________ Wiele aplikacji stosuje kod ASCII. Kom putery w ysyłają w tym kodzie wiadomości, które czytamy. Ich treść może być różna, poczynając od wiadom ości o błędach, kończąc na kom unikatach o stanie . ASCII przedstawia zarówno dane tekstowe (listy, liczby, znaki przestankowe), ja k i znaki sterujące, reprezentujące polecenia takie ja k return i znak nowej linii.

Umożliwia to protokołowi Telnet działanie z wieloma różnymi systemami ponie­ waż dostosowuje cechy szczególne heterogenicznych komputerów oraz systemów operacyjnych. Niektóre systemy stosują inną składnie tekstową (np. znak karetki

Rozdział 11. • TELNET

281

(carriage control) lub now ej linii (line feed)). Aby uniknąć różnic, Telnet definiuje w jaki sposób sekwencje danych i poleceń są rozsyłane poprzez Internet. Rysunek 11.2 przedstawia proces przekształcania danych z formatu hosta lokalnego na format NVT. Ry s u n e k 1 1 .2 .

Operacje prowadzone przez NVT polegają na przekształcaniu formatu terminalu użytkownika i hosta na format NVT i odwrotnie

Połączenie TC P przez Internet

Klawiatura i m onitor użytkownika

S erwer

Klient

Form at używany przez system klienta

Form at używany przez NVT

Form at używany przez system serwera

Klawiatura NVT może wygenerować wszystkie 128 kodów ASCII z zastosowaniem klawiszy, kombinacji klawiszy lub sekwencji, na które składają się: 95 znaków, które mogą zostać przedstawione graficznie (listy, numery, znaki przystankowe) i mających to samo znaczenie > 33 kody sterujące Tabela 11.1 przedstawia standardowe kody kontrolne, które wszystkie sieciowe im­ plementacje Wirtualnego Terminala Sieciowego muszą rozpoznawać. Tabela 11.1. Wymagane przez NVT kody kontrolne Nazwa

Kod

Wartość dziesiętna

Funkcja

NULL

NUL

0

Brak działania.

Line Feed

LF

10

Przenosi głowicę drukarki do następnej linii, utrzym ując tę sam ą pozycję horyzontalną.

Carriage Return

CR

13

Przenosi głowicę drukarki do lewego marginesu bieżącego wiersza

Tabela 11.2 przedstawia opcjonalne kody sterujące, które powinny powodować zamierzony skutek niezależnie czy są rozpoznawane przez NVT.

Polecenia protokołu Telnet NVT protokołu Telnet zawiera różne polecenia sterujące czynnościami zachodzą­ cymi pomiędzy klientem, a serwerem, a następnie umieszcza te polecenia w stru­ mieniu danych. Polecenia Telnetu składają się z dwuoktetowej obowiązkowej se­ kwencji z trzecim opcjonalnym oktetem. Telnet korzystając z pierwszego oktetu, zwanego "Interpretuj jako polecenie"(IAC — Interpret as command) określa, że przesłana informacja jest poleceniem i tak też powinna być interpretowana. Drugi oktet identyfikuje kod jednego z poleceń wymienionych w tabeli 11.3. Trzeci oktet precyzuje znaczenie polecenia, jeżeli poprzedni oktet był w tym względzie niewy­ starczający. Tabela 11.4 przedstawia różne opcje Telnetu.

282

TCP/IP. SZKOŁA PROGRAMOWANIA

Tabela 1 1 .2 . Wymagane przez NVT kody kontrolne Nazwa

Kod

Wartość dziesiętna

Funkcja

BELL

BEL

7

Powoduje słyszalny lub w idzialny znak (nie przemieszcza głow icy drukarki)

Back Space

BS

8

Przenosi głowicę drukarki o jeden znak w kierunku lewego marginesu.

Horizontal Tab

HT

9

Przenosi głowicę drukarki w poziomie do następnego tabulatora. Nie określa w jaki sposób drugie urządzenie końcowe ustala lokalizację tabulatora.

Vertical Tab

VT

11

Przenosi głowicę drukarki w pionie do następnego tabulatora. Nie określa w ja ki sposób drugie urządzenie końcowe ustala lokalizację tabulatora.

Form Feed

FF

12

Przenosi głowicę drukarki do początku następnej strony, utrzym ując tę samą pozycję horyzontalną. W przypadku monitora, czyści ekran i przenosi kursor w lewym górnym rogu.

T abela 1 1 .3 . Polecenia Telnetu zgodnie z interpretacją IAC(255) Polecenie

Kod dziesiętny

Znaczenie

EOF

236

Koniec pliku.

SUSP

237

Zatrzymaj proces bieżący

ABORT

238

Przerwij proces

EOR

239

Koniec rekordu.

SE

240

Koniec param etrów subnegocjacji.

NOP

241

Brak działania.

DM

242

Znacznik danych, fragm ent Synch. Zawsze z towarzyszącą pilną notyfikacją TCP.

BRK

243

Przerwij; oznacza sygnał “przerwa".

IP

244

Zawieś, przerwij lub zatrzymaj proces.

AO

245

Zam knij wyjście. Zezwala na zakończenie bieżącego procesu, nie przesyła jednakże rezultatu użytkow nikow i.

AYT

246

Czy jesteś tam? Proces powinien odpowiedzieć dając znak że na drugim końcu otrzymano AYT.

EC

247

Usuń znak. Odbiorca powinien usunąć ostatni nieusunięty znak strum ienia danych.

EL

248

Usuń linię. Odbiorca powinien usunąć znaki ze strum ienia danych z wyłączeniem poprzedniego CRLF.

Rozdział 11. • TELNET

283

T abela 1 1 .3 . Polecenia Telnetu zgodnie z interpretacją IACC255) (ciąg dalszy) Polecenie

Kod dziesiętny

Znaczenie

GA

249

Zaczynaj. Poinform uj adresata, że może rozpocząć transmisje.

SB

250

Rozpoczęto subnegocjacje wskazanych opcji.

W ILL

251

Negocjacja opcji. W skazanie na chęć rozpoczęcia korzystania lub potwierdzenia wykonywania określonych opcji.

WONT

252

Negocjacja opcji. Oznacza odm owę wykonania lub kontynuacji wykonania wskazanych opcji.

DO

253

Negocjacja opcji. Oznacza zapytanie o wykonywane opcje lub potwierdzenie oczekiwania wykonywania określonych

DONT

254

Negocjacja opcji. Oznacza żądanie zaprzestania wykonywania lub potwierdzenia, że już nie oczekujemy od drugiej strony w ykonywania określonych opcji.

IAC

255

Interpretuj kolejny oktet jako polecenie.

opcji przez drugą stronę.

Negocjacja opcji Pomimo, że obie strony przyjmują, że mogą korzystać z NVT, pierwszej wymianie danych wykonywanej przez Telnet towarzyszy sygnał negocjacji opcji. Klienci oraz serwery wykorzystują opcję negocjacji aby uzgodnić parametry i opcje, które zo­ staną zastosowane podczas komunikacji. Telnet traktuje obie strony komunikujące się w sposób jednakowy — każda ze stron może zażądać opcjonalnego parametru. Jeżeli druga strona nie obsługuje danej cechy lub nie może jej używać, żądanie zostaje odrzucone. Obie strony uzgadniają i korzystają z cech, które obsługują, a wszystkie pozostałe opcje utrzymują na minimalnym poziomie wymaganym przez standard NVT. Po tym jak klient i serwer zakończą negocjacje, mogą zacząć wymianę danych w trakcie sesji Telnet. Każda ze stron może wysłać następujące cztery zapytania: > WILL — wysyłający chce uruchomić daną opcję. I> DO — wysyłający chce, aby odbiorca uruchomił daną opcję. > WONT — wysyłający chce wyłączyć daną opcję. > DONT — wysyłający chce, aby odbiorca wyłączył daną opcję. Rysunek 11.3 przedstawia sesję Telnet ustanowioną przez TCP za pomocą uzgod­ nień trzyetapowych. Rysunek ten przedstawia również negocjacje prowadzone pomiędzy klientem a serwerem oraz moment logowania klienta. Należy zwrócić uwagę, iż port 23 TCP jest portem docelowym (D=23) w pierwszym wierszu.

284

TCP/IP. SZKOŁA PROGRAMOWANIA

Ry s u n e k 1 1 .3 .

Po tym jak ustanowiona zostaje sesja TCP (wiersze 1,2 i 3), klient Telnetu oraz serwer rozpoczynają negocjacje, wymieniając zapytania WILL, DO, WONT i DONT

O brullei F m ^ o c a l/D i.ilU p A d a p lc M lle ln e ll l / l P i Ethernet lm tncł| H E łE j 5 FBa Monitor Capture Display jo o h Window H d p ______________________________________________________________________ - .|g |.X j

"¿ I h I e lr d E l a l o M a l a k o l lo. 1

iSlalus 1 ouiceAddxe:s Ok 192.42 252.20] 192 42 252.1] Ok Ok i 192.42 252 20] 3 Ok 192 42 252 20] 5 Ok ,|192.42 252 11 ~ (. Ok 7 Ok 192*42 252 20] _ 0 ;192.42 252 1] Ok 252 20] Ok 1 “ if! jk 192 42 21-: i] 252.20] 11 3k 12 Ok j 192 42 252.11 13 Ok 192 42 252.20] 14 192 42 252 1] 15 Ok 1 192 42 252 20] Ib Ok 192 42 252 20] 17 Ok ! 192.42 252 1] Ok 18 192.42 252 20] 19 Ok 252 20] 1 20 Ok i'*2 42 252 1 ] 21 Ok 192 42 252.20] 252.20] Ok 192 42 252.1] 23 Ok 192 42 252.20] 24 Ok Ok 192 42 252.20] Ok 192 42 252 I] Ok 192.42 252 20] :q Ok 192 42 252 20] 192.42 252 1] Ok 30 Ok 192.42 252 20] 31 Ok 252 1] 32 Ok 192!42 252 20] 33 jk 192 42 252 20] *

— _

b

! ¿1 o i l

iDestAddrew [192 42.252.1] [192 42 252 20] [192 42 252 1] [192 42 1] [192 42 252 20] 192 42 252 20] [192 42 252 1] 192 4 2 252 :-oi 192 42 252 i] 192 4 2 252 20] 192 42 252 11 192 4 2 252 20] 192 42 252 1] 192 42 192 42 252 1] 192 42 U 192 42 20] 192 42 252 1] 42 252 1] 192 4 2 20] 192 42 252 1] 192 4 2 11 192 4 2 252 20] 192 42 252 ij 192 42 1] 192 42 20] 192 42 252 1] 192 1] 42 20] 192 42 252 1] 192 42 252 20] [192 42 252 i] 192 42 252 u

(Laver IStanmaiv TCP D 23 S=2921 TCP D 2921 S u23 iTCP D 23 5=2921 Telnet C PORT-2921 TCP D 2921 S=23 !Telnet P. p o r t . 'TCP D 23 5=2921 J u l Mit !?. FORT“2921 (Telnet 1C PORT*2521 Telnet,R PORT-2921 Telnet C PORT=2921 Telnet R PORT”2921 ¡TCP D 23 5=2921 Telnet R PORT“2921 TCP D 23 5=2921 Telnet C FORT-292i Telnet R FORT-2921 TCP D 23 5=2921 Telnet C FORT*292i ¡Telnet E PORT*2921 ‘TCP P 23 5=2921 Telnet C tORT=2921 'Telnet lR PORT“2921 iTCP D 23 5=2921 Telnet C FORT=2921 ¡Telnet R PORT“2921 TCP D 23 5-2921 Telnet C FORT-2521 Telnet IR FORT-2921 TCP D 23 5=2921 r*ih*t p. FORT=2921 TCP D 23 5=2921 ITelnet C PORT“2921

\DecodeĄM atrixĄH ostTableĄProtocolDist.ĄStatistics/ Fw H dp. press F I

»«»llilHgaa ^

@

I

SY1I SEQ=1545216000 IEH=0 W H - 4 D 9 6 SYll ACK=1S45216001 5 E 0 493S6000 I ACK=49856001 «111=4096 “ IAC bo Suppress o-ahead ACK=154521Ć007 11111=4090 I AC Do T e r a m a lACK=49856Q04 «111=4096 IAC «iii. Sttppres ge-ahead IAC SB TEE11IHAL- "YPE IAC «rll Echo IAC D o Echo Don't Echo ACK=49856050 «111=4096 log ACK=49S5605? «111=4096 d d ACK=49856059 «111=4096 e e ACK=498560S3 «111=4096 ACK=49856Q60 «111=4096 6CK=49856061 «111=4096 49856001 ■ “ 1545216007 =: 20 b ytes

■IB

1 (Ho urgent pointe: 1 Acknowledgment 1 Push 1 (Ho r e s e t ) ■ (Ho SYH) ' (Ho FIH) > 4090 - C6CA (c o r r e c t )

IAC Do T e rn in al-ty p e

Decode X Malrtx Ą Host Tobie Ą Protocol Dfcl. À Statistics/ For Help, press F1

j js i a B g

s & s i rg lipts«-') ¿air-1

aiE^..| iaE^i.. I S = *

9:37 AM

Rozdziat 11. • TELNET

Rys u n e k 1 1 .5 .

Klient jako nazwę swojego terminala podaje Sun

287

-|g|Xl

! Frä Moraler Captura Display Tods ¡¿/rekw Help GSlal all -\ E l & l o j l m l a l i a t e l £:j JüJ o | i ß IP: Source a d d r e s s » [192 42.252 20] ¿-3 IP Destination address • [192. 42.252 1] ¿3 IP Ho options ä IP' 3 §3 TCP: ----- TCP header-----Q Q TCP: Source port = 2921 Q TCP. Destination port ■ 23 (Telnet) Q T C P : Sequence nunber ■ 1545216007 ■Q T C P : Acknowledgnent nunber " 49056013 20 bytes Q TCP: Data offset IB Q TCP: Flags QTCP: .0. (Ho urgent pointer) Q TCP: ...1 Acknovledgnen t u a TCP: Push O TCP: ___ (Ho reset) a TCP: ___ (Ho SYH) ! a TCP: ___ (Ho FIH) a TCP: Uindoo 4096 ACE1 (correct) a T C P : Checksun a TCP: Ho TCP options ■Q T C P : [13 byte(s) of data] O TCP: 3^ Telnet: Telnet ----- O Telnet: a Telnet: IAC SB TERHIHAI-TYPE -3 Telnet: IS SUH-CHD a Telnet: IAC SE

TCP:

DecodeĄM airixĄH ostTafleĄPrdocolDia.ĄSłaliaics/~ ForH aip.Pi«=Fl a O S la n l l H

g

g j

f f ¡1 ggMa)c..| ¿ j3 H F...|

r

.iii

g My C-ljj) Expl.. | 12jExpt-. 1 S

s

1

Äi liJÜ'M Hä.

■5 n .ll« P«

M TA ■

i

1 IA

P7

MS

M TA < ------------

T AU

UA S yste m O bstugi W ia d o m o ści

I

\

IDU U żytko w n ik

M odel fu n k c jo n a ln y X .4 0 0

D Telex

Rozdział 13. ° PROSTY PROTOKÓŁ PRZESYŁANIA POCZTY ELEKTRONICZNEJ (SMTP)

31 1

Agenci Transferu Wiadomości (MTA) Zgodnie z 1123 SMTP programy serwera wykazują podobieństwo do MTA znanych ze standardu X.400. Agenci transferu wiadomości zajmują się wymianą poczty i od­ powiadają za trasowanie (routing) wiadomości elektronicznych przez sieci złożone. Te komutatory wiadomości łączą się ze sobą aby utworzyć System Transferu Wia­ domości (MTS — Message Transfer System). MTA mają następujące funkcje: > Akceptowanie wiadomości UA lub innych MTA, trasowanie ich do właściwych odbiorców UA lub innych MTA, którzy trasują je do odbiorców końcowych. > Analizowanie listy odbiorców dołączonej do wiadomości oraz podejmowanie decyzji trasujących. > Przekazywanie wiadomości do UA oraz tworzenie na żądanie notyfikacji dostawy. > Wysyłanie do MTA wiadomości wskazujących na potrzebę przekazania ich do innych MTA > Generowanie NDN(non-delivery notification), czyli notyfikacji niedostarczenia wiadomości jeżeli jej dostawa nie może zostać zrealizowana ze względu na nie­ właściwy lub nieistniejący adres. > Kopiowanie wiadomości i dostarczanie kopii do poszczególnych odbiorców w przypadku wiadomości skierowanych na wiele adresów. Komitet Międzynarodowego Związku Telekomunikacyjnego opracował i wprowa­ dził model X.400 dla standardów Związków Telekomunikacyjnych X.400 CCITT (Komitet Konsultacyjny dla Międzynarodowej Telekomunikacji i Telefonii). Odnosi się on do szeregu protokołów wykorzystywanych do wymiany wiadomości pomię­ dzy serwerami poczty elektronicznej, omawiając zagadnienia takie jak: > Wiadomości multimedialne (głos, grafika, fax, tekst) > Współdziałanie odmiennych systemów > Bezpieczeństwo transmisji wiadomości > Niezawodny transport wiadomości > Archiwizacja wiadomości > Usługi katalogowe dla lokalizowania adresów > Raportowanie dostarczenia i odbioru wiadomości

Format SMTP Poczta składa się z wiadomości, utworzonej z nagłówka i treści, oraz „koperty" zło­ żonej ze źródłowego i docelowego adresu SMTP. Zawartość oraz znaczenie koperty opisane zostały w RFC 821. Poniższy przykład przedstawia dwa polecenia SMTP (omówione w dalszej części rozdziału), określające kopertę:

312

TCP/IP. SZKOŁA PROGRAMOWANIA

> M ailFrom :h eath er@ itacad em y. com > RCPT To: j asontąitacadem y. com Zgodnie z RFC 822 zawartość wiadomości zawiera tekst w formacie ASCII (Ameri­ can Standard Code for Information Interchange). ASCII reprezentuje zarówno dane tekstowe (litery, liczby oraz znaki przestankowe), jak i znaki kontrolne — polecenia takie jak powrót karetki i nowa linia. Tak jak inne systemy kodujące, ASCII przetwarza informacje do standardowego formatu cyfrowego używając siedmiocyfrowych liczb binarnych. Liczby binarne składają się z sekwencji zerojedynkowych. Kom­ putery w trakcie komunikowania się ze sobą przetwarzają i przechowują dane w tym właśnie formacie cyfrowym. NVT, korzystając ze znaków siedmiobitowych, przekształca siedmiobitowy kod ASCII na ośmiobitowe oktety z najważniejszym bitem przyjmującym wartość 0. Nagłówek składa się z serii linii tekstu znanych jako pola fiagłówlca (header fields). Większość pól nagłówka zależy od konkretnej implementacji systemu — tylko nie­ które pola nagłówka są obowiązkowe. Pusta linia oddziela nagłówek od właściwej treści (body). Właściwa treść wiadomości zawiera tylko tekst ASCII; długość linii nie może przekraczać tysiąca znaków. Wiadomość nie może również przekroczyć okre­ ślonej wielkości całkowitej. W dalszej części tego rozdziału wyjaśnimy jak ominąć te ograniczenia. Większość systemów korzysta z różnych odmian formatu poczty, którego przykład przedstawiony poniżej, został zaczerpnięty z załącznika A do RFC 822. RFC określa ten przykład formatu SMTP jako „tak skomplikowany jak tylko potrzebujesz". Wykorzy­ stuje on jedenaście pól, więcej niż to ma miejsce w większości systemów pocztowych. D ate

: 27 Aug 76 0 9 3 2 PDT

From : Ken D a v i e s k d a v i e s @ t h i s - h o s t . t h i s - n e t S u b je c t : Re: S k ł a d n i a w RFC Sender : K se cy@ O th e r-H o st R e p ly -to

: Sam.

Irv in g @ R e g . o r g a n iz a t io n

To

: G e o rg e J o n e s g r o u p @ s o m e - r e g . A n - o r g , A1 . Neuman @MAD. P u b l i s h e r CC : W ażni o d b io r c y : Tom S o f t w o o d b a l s a @ t r e e , r o o t , "Sam I r v i n g ' @ o t h e r - h o s t ; , S ta n d a rd o w i o d b io rc y : /m ia n /d a v is /p e o p le /s ta n d a rd @ o th e r-h o s t, ,,< jo n e s > s ta n d a rd . d i s t . 3 "@ T o p s-20 -H o st> ; Comment : Sam j e s t w p o d r ó ż y s ł u ż b o w e j . P o p r o s i ł m n ie abym z a j ą ł s i ę j e g o p o c z t ą . W ra ca w p r z y s z ł y m t y g o d n i u w i ę c p r a w d o p o d o b n i e b ę d z i e m ó g ł w y j a ś n i ć swą n i e o b e c n o ś ć b a r d z i e j s z c z e g ó ł o w o . I n - R e p l y - T o : s o m e . s t r i n g @ D M . g r o u p , G e o r g e k s m essage X - S p e c i a l - a c t i o n : To j e s t p r z y k ł a d nazw p ó l d e f i n i o w a n y c h p r z e z u ż y t k o w n i k a . M o g ł o b y t u b y ć p o l e „ S p e c i a l a c t i o n " a l e t a k a nazwa m o g ła b y z o s t a ć p ó ź n i e j u s u n i ę t a M essage-ID

: 4 2 3 1 .6 2 9 .X y z i-w h a t@ o th e r-h o s t

Rozdział 13. - PROSTY PROTOKÓŁ PRZESYŁANIA POCZTY ELEKTRONICZNEJ (SMTP)

313

Polecenia SMTP Polecenia SMTP (RFC 821) określają transakcje pocztowe lub funkcje systemu pocztowego , których zażądał użytkownik. Polecenia SMTP składają się z kodu po­ lecenia oraz argumentu (patrz tabela 13.1). Tabela 13.1. Kody poleceń SMTP Kod polecenia oraz argument

Opis działania

HELO

Przedstawia SMTP nadawcy SMTP odbiorcy.

M A IL< S P >F R O M : < C R L F >

Dostarcza przesyłane dane pocztowe do skrzynki pocztowej.

RCPT < S P > TO: < C R L F >

Identyfikuje odbiorcę przesyłanych danych pocztowych.

DATA < C R L F >

W ysyła zawartość wiadom ości pocztowej.

RSET < C R L F >

Kończy istniejącą w ym ianę poczty, powodując przejście obu stron w stan spoczynku. Czynność ta powoduje usunięcie w szystkich przechowywanych inform acji o nadawcy, odbiorcy lub przesyłanych danych.

SEND < S P > FROM: < C R L F >

Dostarcza pocztę do term inali.

SOML < S P > FROM: < C R L F >

W ysyła lub przesyła.

SAML < S P > FROM: < C R L F >

Wysyła lub przesyła.

VRFY < S P > < la ń cu ch znakow y>

Potwierdza, że argum ent identyfikuje użytkownika. Um ożliw ia to klientow i zapytanie nadawcy o weryfikację adresu odbiorcy bez konieczności wysyłania wiadom ości do odbiorcy (opcja wykorzystywana zazwyczaj przez adm inistratora systemu w celu debugowania problem ów z dostarczeniem poczty).

EXPN < S P > < ta ńcu ch znakow y>

Potwierdza, że argum ent identyfikuje listę wysyłkową. W ydłuża tą listę.

H E L P [< S P > < ta ńcu ch z n a k o w y > ]< C R L F >

Wysyła inform acje.

NOOP < C R L F >

Brak działania.

QUIT < C R L F >

Wysyła odpowiedź OK, a następnie zamyka kanały.

TURN < C R L F > < S P > oznacza znak spacji. < C R L F > oznacza znaki karetki i nowej linii.

314

TCP/IP. SZKOŁA PROGRAMOWANIA

Polecenia SMTP przestrzegają pewnych podstawowych zasad: > Każde polecenie SMTP składa się z kodu polecenia oraz argumentu. > Kod polecenia składa się z czterech znaków alfabetu pisanych wielką lub małą literą. > Kod oddzielony jest od argumentu jedną lub większą ilością spacji. > Ponieważ każdy z hostów może posiadać indywidualne reguły adresowania poczty w ścieżce przekazania oraz ścieżce zwrotnej ważna jest wielkość znaków. > Sekwencja znaków karetki i nowej linii () kończy pole argumentu. > Nawiasy kwadratowe zawierają argumenty opcjonalne.

Odpowiedzi SMTP Odpowiedzi SMTP potwierdzają otrzymanie datagramu SMTP oraz informują o wystąpienia błędu. Odpowiedź składa się z trzycyfrowego kodu (przesyłanego jako trzy znaki alfanumeryczne), po któiym następuje tekst. Odpowiedź zbudowana jest z trzycyfrowego kodu, < S P > , jednej linii tekstu oraz . Tekst różni się w zależności od kodu odpowiedzi, a jego kombinacje wskazują powód odpowiedzi. Klienci i serwery SMTP używają trzech cyfr do komunikowania odbioru informacji oraz powiadamiania drugiej strony o wystąpieniu błędu. Ta trzycyfrowa liczba ma swój porządek. Pierwsza cyfra określa informację ogólną, druga i trzecia cyfra defi­ niują bardziej szczegółowo odpowiedź, przekazując hostowi odbiorcy wystarczającą ilość informacji, aby mógł on określić czy wystąpił jakiś błąd i jak dalej postępować z wiadomością. Odbiorca nie musi patrzeć na wiadomość tekstową; sprawdza tylko cyfry zawarte w odpowiedzi i podejmuje decyzję o odrzuceniu wiadomości w której wystąpił błąd, lub przekazaniu jej użytkownikowi. Tabela 13.2 demonstruje znaczenie pierwszej cyfry. Tabela 13.3 przedstawia znaczenie drugiej cyfry. Natomiast tabela 13.4 przed­ stawia listę pełnych kodów odpowiedzi uporządkowanych zgodnie z ich wartością numeryczną. 1a b e la 1 3 . 2 . Z n a c z e n ie p ie rw s z e j cy fry Pierwsza cyfra

Znaczenie

ly z

Pozytywna odpowiedź wstępna.

2yz

Pozytywna odpowiedź kończąca.

3yz

Pozytywna odpowiedź pośrednia.

4yz

Tymczasowa negatywna odpowiedź kończąca.

5yz

Stata negatywna odpowiedź kończąca.

Rozdział 13. • PROSTY PROTOKÓŁ PRZESYŁANIA POCZTY ELEKTRONICZNEJ (SMTP)

315

T a b e la 1 3 . 3 . Z n a cze n ie d ru g ie j cy fry Druga cyfra

Znaczenie

xOz

Składnia

x lz

Informacja

x2z

Połączenie

x3z

Dotychczas nieokreślone

x4z

Dotychczas nieokreślone

x5z

System pocztowy

T a b e la 1 3 . 4 . U p o rz ą d k o w a n a lis ta k o d ó w o d p o w ie d z i N um er

Opis

211

Odpowiedź systemu stanu lub systemu pomocy.

214

W iadom ość pomocy; wykorzystywana przez użytkownika.

22 0

Usługa gotowa.

221

Usługa zamyka kanał transm isyjny.

250

Żądana czynność przesyłu zakończona pomyślnie.

2 51

Użytkownik nie jest lokalny — zostanie przekierowany do .

354

Rozpoczęcie wprowadzania wiadom ości — < C R L F > oznaczy koniec

421

Usługa nie jest dostępna; zam ykanie kanału transmisyjnego. Może być odpowiedzią na każde polecenie, jeśli usługa wie, że musi zostać zamknięta.

450

Żądana czynność pocztowa nie została wykonana — skrzynka pocztowa niedostępna (skrzynka zajęta).

451

Żądana czynność przerwana — błąd lokalny podczas przetwarzania.

452

Żądana czynność nie została wykonana — niewystarczająca pojemność systemu.

50 0

Błąd składni, polecenie nierozpoznane. Może oznaczać błędy spowodowane m .in. zbyt długą linią polecenia.

501

Błąd składni w parametrach lub argumentach.

502

Polecenie nie zostało wykonane.

50 3

Nieprawidłowa sekwencja poleceń.

504

Parametr polecenia nie został wprowadzony.

550

Żądana czynność nie została wykonana — niedostępna skrzynka pocztowa (skrzynka nie znaleziona; brak dostępu).

551

U żytkow nik nie jest lokalny — spróbuj

55 2

Żądana czynność została przerwana — przekroczona zaalokowana pojemność.

55 3

Żądana czynność nie została wykonana — niedopuszczalna nazwa skrzynki pocztowej.

554

Nieudana transakcja.

315

TCP/IP. SZKOŁA PROGRAMOWANIA

MIME Protokół SMTP, pochodzący z lat 80-tych, dzięki swojej prostocie zawsze miał sporą grupę użytkowników. W wielu przypadkach, użytkownicy przekraczali jego moż­ liwości, chcąc przesyłać wiadomości inne niż tekstowe, takie jak grafika, skanowane fotografie lub wideoklipy. Prostota SMTP skutkuje następującymi ograniczeniami: > Wiadomość może zawierać jedynie znaki ASCII. E> Maksymalna długość linii nie może przekroczyć 1000 znaków. > Wiadomość nie może przekroczyć określonego rozmiaru maksymalnego. Uniwersalne rozszerzenie poczty elektronicznej (Multipurpose Internet Mail Exten­ sions — MIME) zwiększa możliwości standardowej internetowej poczty elektronicznej, a co ważniejsze — SMTP. Wykorzystanie standardu MIME umożliwia zawarcie w wia­ domości dodatkowo: > Zestawów znaków innych niż ASCII > Wiadomości multimedialnych: obrazów, dźwięku i plików wideo > Wielu obiektów w jednej wiadomości > Wiadomości z wieloma czcionkami > Wiadomości o nieograniczonych rozmiarach > Plików binarnych Grupa robocza do spraw technicznych sieci Internet (Internet Engineering Task Force — IETF) zdefiniowała MIME w 1992 roku w RFC 1521 i 1522. MIME opisuje metodę, dzięki której pliki są dołączane do wiadomości SMTP. Rozbudowuje w ten sposób poprzedni standard poprzez zdefiniowanie dodatkowych pól nagłówka wiadomości, które określają nowe rodzaje zawartości wiadomości oraz specyfikują zasady organizacji jej treści. Rozszerzenie MIME zapewnia transmisję dla danych poprzednio nie obsługiwa­ nych przez pocztę Internetową poprzez zakodowanie wiadomości do postaci czy­ telnego ASCII, w celu utworzenia standardowej wiadomości elektronicznej. Roz­ szerzenie protokołu SMTP zapewnia możliwość przesyłania wiadomości nowego rodzaju. RFC 1652 opisuje rozszerzenie dla transmisji ośmiobitowych wiadomości MIME w formacie UUencoded. Dzięki rozszerzeniu zakresu usługi odbiorca SMTP może deklarować gotowość obsługi ośmiobitowych elementów treści wiadomości. Odbiorca może również żądać ośmiobitowej transmisji dla danej wiadomości. MI­ ME rezyduje w nagłówku pocztowym 822.

Rozdział 13. • PROSTY PROTOKÓŁ PRZESYŁANIA POCZTY ELEKTRONICZNEJ (SMTP)

317

Podsumowanie Działający w ramach zestawu protokołów TCP/TP, Prosty Protokół Przesyłania Poczty Elektronicznej (SMTP) określa format przesyłania i odbierania wiadomości dla ser­ werów poczty elektronicznej oraz wysyłania wiadomości do serwera przez klienta. SMTP rozpoczyna swoje działanie uruchomieniu przez klienta połączenia TCP z ser­ werem na standardowym porcie 25. Klient oraz serwer korzystają następnie z kanału komunikacyjnego SMTP. Klient wysyła pocztę do serwera poprzez serię starannie zdefiniowanych transakcji typu polecenie-odpowiedź. Model X.400 ilustruje wymianę poczty elektronicznej pomiędzy Agentami Użyt­ kownika oraz Agentami Transferu Wiadomości. Agenci użytkownika (UA), istnieją­ cy również w modelu SMTP, umożliwiają natychmiastową interakcję z użytkowni­ kiem. Poprzez UA użytkownik przygotowuje, przekazuje i otrzymuje wiadomości elektroniczne. Agenci transferu wiadomości (MTA), podobnie jak programy SMTP, zajmują się wymianą poczty i komunikują się używając NVT ASCII. X.400 definiuje szereg kwestii dotyczących protokołów wykorzystywanych do wymiany wiadomo­ ści pomiędzy serwerami poczty elektronicznej. Poczta składa się z wiadomości, utworzonej z nagłówka oraz zawartości, a także „koperty" obejmującej źródłowy i docelowy adresu SMTP. Nagłówek składa się z serii linii tekstu lub pól. Wymagane pola zależą od konwencji danego systemu. Mimo, że SMTP pozwala jedynie na przesłanie ograniczonej ilości tekstu w forma­ cie ASCII, uniwersalne rozszerzenie poczty elektronicznej (MIME) umożliwia omi­ nięcie tego ograniczenia i dodawanie do wiadomości dokumentów w formatach innych niż ASCII, plików audio, wideo oraz obrazów.

Pytania sprawdzające 1. Jaka jest podstawowa funkcja SMTP? 2. Jak Agenci Użytkownika funkcjonują w modelu SMTP? 3. Jak SMTP różni się od UA? 4. Opisz trzy ograniczenia SMTP. 5. Wymień trzy reguły poleceń protokołu SMTP. 6. Wyjaśnij znaczenie odpowiedzi dla bezproblemowego przesyłania poczty. 7. Dlaczego odpowiedź SMTP jest ważna dla użytkownika? 8. Wyjaśnij jak MIME współpracuje z SMTP.

318

TCP/IP. SZKOŁA PROGRAMOWANIA

PRZEKSZTAŁCANIE K i Przegląd treści rozdziału: o

Nazwy kom puterów

o

Buforowanie (caching)

o

Przestrzeń nazw

o

Format wiadom ości serwera domen

Delegacja zarządzania

o

Internetowe nazwy domen i ich rodzaje

o

dom enam i DNS

Dlaczego potrzebujemy przekształcenia nazw? W początkowej fazie rozwoju sieci komputerowych, użytkownicy musieli identyfi­ kować i określać komputeiy za pomocą długich, niewygodnych adresów numerycz­ nych. Jednakże wraz z rozwojem międzysieci wprowadzono hierarchiczny system adresowania IP, któiy dzielił adresy na ldasy (warstwa sieciowa), oraz oprogramowanie (np. ARP) mogące przekształcać adresy do postaci nislcopoziomowej. Adresy niskiego poziomu (adresy MAC) są to unikalne numery rozpoznawane przez komputer i wyko­ rzystywane do lokalnego przesyłania datagramów w systemie punkt-punkt. Warstwę sieciową omawialiśmy w rozdziale 3 i rozdziale 4, zaś warstwę łącza danych opisali­ śmy w rozdziale 1. Wyobraźmy sobie, że komputer działa tak jak telefon. Telefon nie potrafi zrozumieć naszych imion, ponieważ składają się one z liter i opisują osobę, a nie numer (adres) innego telefonu. Jeżeli chce do nas zadzwonić mama, nie wystarczy, że wymówi na glos nasze imię. Samo imię nie wystarczy do zlokalizowania docelowego adresata i wykonania połączenia. Mama musi znać nasz numer telefonu aby do nas zadzwonić. Numer telefonu określony jest według hierarchicznego schematu numerycznego wskazującego ob­ szar, miasto oraz dom, w którym znajduje się telefon. Centrale telekomunikacyjne wykorzystują te informacje w publicznej sieci telefonicznej do lokalizacji docelowego odbiorcy oraz wykonania połączenia.

320

TCP/IP. SZKOŁA PROGRAMOWANIA

Nasz komputer musi również znać adres protokołu internetowego (IP) jeżeli chcemy za jego pomocą połączyć się ze zdalnym hostem lub stroną internetową. Podobnie jak numer telefonu, adres IP (adres warstwy sieciowej) składa się z liczb, tak, aby każdy komputer mógł go odczytać i odnaleźć na jego podstawie ścieżkę do punktu doce­ lowego. Po zidentyfikowaniu miejsca docelowego przez komputer, nadawca i odbiorca określają adres niższego poziomu (adres MAC), aby przeprowadzić wymianę da­ nych typu punkt-punkt przez uzyskaną ścieżkę. Możliwość skorzystania z nazwy zamiast z adresu jest korzystna dla nas, a nie dla komputerów. Kiedy użytkownik próbuje zlokalizować określone zasoby korzystając z nazwy, urządzenie musi prze­ kształcić tą nazwę na adres logiczny warstwy sieciowej, który z kolei, po dotarciu do docelowej sied, musi zostać przekształcony na adres warstwy łącza danych. Wszyst­ kie te wymienione czynności muszą nastąpić zanim dojdzie do transmisji danych. Aplikacje TCP/IP korzystają z DNS trochę jak my z informacji telefonicznej. Podob­ nie jak w informacji telefonicznej, możemy podać nazwę DNS i uzyskać numer (ad­ res IP). Usługa ta eliminuje potrzebę używania przestrzeni nazw.

Przestrzeń nazw Aktualnie Internet składa się z milionów hostów, z których każdy ma oddzielny ad­ res IP oraz nazwę (jeżeli została skonfigurowana). Aby skontaktować się z hostem, możemy zamiast adresu IP podać jego nazwę. Jednak, aby nazwa została prze­ kształcona na potrzebny nam adres konieczna jest jedna z dwóch rzeczy: serwer DNS (informacja telefoniczna) lub tablica lokalna. Serwery nazw domen, podobnie jak informacja telefoniczna, świadczą usługi po­ szukiwania przekształceń nazw na adresy IP. Załóżmy, że chcemy zadzwonić do pizzerii Italia, znamy jej nazwę, ale nie znamy numeru. Mamy dwie możliwości: > Szukamy w lokalnej książce telefonicznej (tablicy lokalnej) > Dzwonimy na nr informacji telefonicznej (serwer DNS) i uzyskujemy pomoc Którąkolwiek z metod wybierzemy, nazwa musi zostać przekształcona na numer na który będziemy mogli zadzwonić i uzyskać dostęp do zasobu — czyli pizzy. Po­ wstaje pytanie — jak przechowywane są ścieżki do tych wszystkich adresów? Po­ czątkowo, kiedy w Internecie istniało zaledwie kilkaset hostów, sprawa była prosta. Jedna lista w postaci pliku tekstowego zwana przestrzenią nazw, zawierała wszyst­ kie informacje. Centrum Informacji Sieciowej (Network Information Center — NIC) przechowywało listę i decydowało, kto był wpisywany i usuwany, kasując nieuży­ wane nazwy oraz nazwy, które mogły być mylone z innymi. Jeżeli ktoś chciał podłączyć się do Internetu, musiał skontaktować się z NIC, aby otrzymać kopię tej listy i dodać ją do wszystkich lokalnych bram internetowych, które dokonywały niezbędnych przekształceń adresów. Za każdym razem, gdy zmieniała się któraś z nazw lub adres internetowy (albo też został on dodany lub

Rozdział 14. • PRZEKSZTAŁCANIE NAZW

32 1

usunięty z Internetu), zmieniała się również lista i należało zdobyć nową. Wprowa­ dzanie zmian oraz utrzymywanie listy i koniecznych do tego celu zasobów okazało się bardzo niepraktyczne. Z tego powodu powstał DNS, aby rozwiązać problemy związane z płaską i statyczną naturą przekształcania nazw. Ta hierarchiczna usługa dynamiczna umożliwia dokonywanie przekształceń adresów na rzecz hostów ko­ rzystających z Internetu. Przestrzeń nazw NIC możemy porównać z naszą prywat­ na książką telefoniczna lub adresową. Decydujemy kto się na niej znajduje i kto jest wykreślany oraz komu przydzielamy specjalne oznaczenia, aby nie pomylić go z inną osobą znajdującą się na liście. Jeżeli na przykład, mamy dwie osoby o imieniu Magda, możemy nazwać jedną z nich Magdalena, a drugiej przypisać pseudonim Madzia, lub skatalogować je na podstawie ich nazwisk: Wiśniewska i Jankowska. Możemy je nazwać Magdal i Magda2, w zależności od tego, kiedy je poznaliśmy lub ze względu na ich miejsca pracy. Niezależnie od systemu nazewniczego, na który się zdecydujemy, jest możliwych wiele kombinacji.

tU

Uwaga Zauważmy, że system nazw domen (DNS) eliminuje potrzebę korzystania z prze­ strzeni nazw poprzez umożliwienie odnalezienia adresu IP odpowiadającego każdej nazwie dom eny i vice versa.

Zarówno przestrzeń nazw, jak i nasza książka adresowa mają wspólną wadę, wi­ doczną szczególnie, jeżeli chce z nich skorzystać ktoś inny niż my: brak przejrzystości i funkcjonalności. Ponieważ tylko my korzystamy z listy, rozpoznajemy wszystkie indywidualne pseudonimy, dziwne oznaczenia lub wpisy bez nazwiska. Najpraw­ dopodobniej ktoś z zewnątrz nie mógłby skorzystać z tej samej listy, aby w łatwy sposób odnaleźć numer telefoniczny. Nie zorientowałby się, że numer Magdy Wi­ śniewskiej umieściliśmy pod hasłem Magdalena, a Magdy Jankowskiej pod nazwą Madzia. Mógłby zadzwonić do Magdy Jankowskiej zamiast do Magdy Wiśniewskiej. Z biegiem czasu w książce pojawia się coraz więcej osób, numerów, pseudonimów, małżonków i kontaktów biznesowych, czyniąc ją coraz trudniejszą do odczytania dla innych użytkowników. Tablica przestrzeni nazw lokalnego hosta boryka się z tym samym problemem. Każda nazwa znajdująca się na liście składa się z ciągu znaków bez jakiejkolwiek innej struktury. Kiedy NIC dysponował niewielką listą, mała liczba użytkowników Internetu mogła ją odczytać i z niej korzystać. Wraz ze zwiększaniem się liczby użytkowników oraz długości listy, dalsze korzystanie z niej stało się niemożliwe. Lista nazw ma następujące wady: > poszerzanie listy jest trudne ►- związane z jej obsługą przeciążenie pracą komplikuje dodatkowo problem poszerzama > jest niewydajna i kosztowna w utrzymaniu

322

TCP/IP. SZKOŁA PROGRAMOWANIA

Tak jak liczba naszych znajomych wzrasta z upływem czasu, tak też dzieje się z In­ ternetem. W miarę jak Internet ulegał rozszerzeniu, a nowi użytkownicy rejestrowali coraz więcej komputerów oraz nazw domen, M C przestawał radzić sobie z usuwa­ niem powtarzających się nazw, podobnie jak ma to miejsce w przypadku powięk­ szającej się książki adresowej. Lista numerów telefonów, które musimy znać oraz ich użytkowników (współpra­ cowników, znajomych, rodziny, lekarza, itd.), wzrasta każdego dnia — ich wpro­ wadzanie oraz organizacja może być kosztowna. Wyobraźmy sobie, że NIC próbuje uporządkować Internet, gdzie tysiące stron pojawia się każdego dnia, wszystkie z setkami komputerów i stacji roboczych. Za każdym razem, kiedy ktoś podłączałby nowy komputer, NIC musiałby to zatwierdzać. W czasie gdy Internet stawał się siecią globalną z nieograniczoną liczbą użytkowni­ ków, dalsze używanie listy nazw stało się niemożliwe, niewydajne i zbyt kosztowne dla NIC. W dawnym świecie Internetu, M C musiał tworzyć i utrzymywać nową listę za każdym razem gdy dodawał nową nazwę komputera, tracąc czas i pieniądze.

Delegacja zarządu domenami DNS Jeżeli prowadzimy rozwijającą się firmę, w której zwiększa się zakres wykonywa­ nych obowiązków, w celu zmniejszenia obciążenia obowiązki te dzieli się na po­ szczególne wydziały. System nazw domen (DNS) działa na tej samej zasadzie; pra­ cuje jak duże, dobrze funkcjonujące przedsiębiorstwo. Kiedy firma się rozrasta, kadra zarządzająca rozdziela obowiązki na poszczególne wydziały, aby zmniejszyć obciążenie i utrzymać funkcjonalność. Kierownictwo może zatrudniać i zwalniać, zmieniać zakres obowiązków i desygnować kolejne osoby nas stanowiska kierownicze. DNS zachowuje się w podobny sposób. Działa w oparciu o hierarchię drzewa, w której M C zarządza górnym poziomem domen i przekazuje pozostałe obowiązki serwerom nazw. Tabela 14.1 przedstawia domeny górnego poziomu DNS, czyli korzeń drzewa. T a b e la 1 4 .1 . D o m e n y g ó rn e g o p o z io m u Domena

Przeznaczenie

MIL

Siiy zbrojne Stanów Zjednoczonych

GOV

Rząd Stanów Zjednoczonych

EDU

Edukacyjne

COM

Komercyjne

NET

NIC i NOC

ORG

Organizacje pozarządowe

CON

Dw uliterow y kod kraju; na przykład, US reprezentuje Stany Zjednoczone, UK reprezentuje W ielką Brytanię, itd.

Rozdział 14. • PRZEKSZTAŁCANIE NAZW

323

Proponowane nazwy górnej warstwy Powyższe siedem trzyliterowych domen górnego poziomu nazywa się często do­ menami ogólnymi lub generycznymi. Dwuliterowe nazwy domen górnego poziomu (czyli domen CON) oparte są na kodach oznaczających kraje. Zaproponowano również inne nazwy górnego poziomu między innymi .firm, .shop, .web, .arts, .rec, .info, .nom, .aero, .biz, .corp, .info, .museum, .name i .pro. Być może ktoś słyszał o .tv, która jest kodem niewielkiego, leżącego na wyspie na Pacyfiku, kraju Tuvalu. Nazwa ta została rozreklamowana przez rejestratorów domen jako domena telewizyjna. Więcej inform acji na ten tem at można znaleźć na stronie

http://www.icann.org. tlds. Serwery nazw przechowują tzw. rekordy zasobów (resource records — RR), które umożliwiają przekształcanie lub odnajdywanie adresów IP dla nazw domen i vice versa. Serwery nazw można porównać do sekretarek. Kiedy chcemy umówić się na spotkanie z lekarzem nie dzwonimy bezpośrednio do dyrektora szpitala, tylko rozmawiamy z recepcjonistką. Serwery nazw zapewniają taką samą wydajność oraz prostotę. Możemy przekształcić nazwę domeny bez marnowania czasu i energii, bez konieczności przechodzenia przez całą hierarchię DNS. Rysunek 14.1 przed­ stawia hierarchiczny układ DNS. Rysunek 14.1. Hierarchiczny układ DNS umożliwia dalsze delegowanie adresów w postaci zrozumiałej dla użytkownika

„

D om en y o g o ln e

U------------------------------------------

uumeny

p o szczeg óln ych krajów

,

H

Organ zarządzający, jakim jest NIC, pełni pieczę nad górną częścią drzewa (dome­ nami górnego poziomu) dzieląc nazwy domen, których używamy, na określone strefy, czyli „samozarządzające" się gałęzie drzewa DNS. Strefy drugiego poziomu mogą dzielić się na jeszcze mniejsze strefy. Na przykład, jeżeli nasza strona znaj­ duje się na serwerze uniwersytetu, każda strefa może odpowiadać jednemu wy­ działowi. Jeżeli nasza strona reprezentuje firmę prywatną, każda strefa może repre­ zentować inną lokalizację, np. oddział lub dział (np. dział kadr).

324

TCP/IP. SZKOŁA PROGRAMOWANIA

Korzystając z przykładu przedstawionego na rysunku 14.1, możemy zauważyć, że Uniwersytet San Francisco dokonał dalszego oddelegowania swojego adresu do u c s f . e d u . Pozwala to odróżnić go od innych domen edukacyjnych, np. Uniwersytetu Stanu San Francisco ( s f s u . e d u ) . Uczelnia mogłaby dokonać dalszego podziału ad­ resu na wydziały; na przykład używając nazwy f i n . u s c f . e d u do reprezentowania swojego wydziału pomocy finansowej. Hierarchicznemu podziałowi domen interne­ towych przyjrzymy się bliżej w dalszej części rozdziału. Tak jak każdy wydział przedsiębiorstwa potrzebuje pracowników, tak są oni potrzebni również w każdej strefie. W każdej strefie niezbędny jest podstawowy serwer nazw oraz jeden lub więcej serwerów wtórnych. Podstawowy serwer nazw wczytuje in­ formacje z plików znajdujących się na dysku. Serwery wtórne otrzymują informa­ cje od serwera podstawowego. Podobnie jak każdy pracownik, serwery te muszą być niezależne oraz powinny posiadać zdolność usuwania pojawiających się błę­ dów, tak aby usterki nie zakłócały świadczenia usług nazewniczych dla ich stref. Aby dodać nowy host do strefy, należy wprowadzić wymagane informacje — przynajmniej nazwę oraz adres IP — do pliku znajdującego się na systemie na któ­ rym pracuje serwer podstawowy. Spowoduje to, że serwer podstawowy ponownie odczyta swoje pliki konfiguracyjne. Serwery wtórne co trzy godziny zwracają się do serwera podstawowego z zapytaniem o nowe informacje. Jeżeli pojawia się ja­ kaś nowa informacja, serwer wtórny otrzymuje ją od serwera podstawowego po­ przez transfer strefowy. Jednakże, te sprawnie działające serwery nie zawsze posiadają informacje, których potrzebujemy (kiedy zaistnieje tak sytuacja, serwer uznany zostaje za nieautorytatywny dla takiej informacji). W takim przypadku serwer zwraca się do innego ser­ wera i przekazuje mu zapytanie z nadzieją, że dokona on przekształcenia nazwy oraz adresu IP lub przekaże je do serwera nazw posiadającego poszukiwaną przez nas informację (nazywanego serwerem autorytatyiunym). Serwery nazw nie muszą znać sposobu na dotarcie do wszystkich pozostałych ser­ werów nazw. Muszą jednak znać adres IP serwera podstawowego. Podobnie jest w firmach, nie musimy znać wszystkich numerów wewnętrznych, wystarczy znajo­ mość źródeł, w których można je uzyskać. Serwery podstawowe działają na po­ dobnych zasadach, co operatorzy central telefonicznych; znają nazwy oraz adresy IP każdego autorytatywnego serwera wszystkich domen drugiego poziomu. Po zwróceniu się przez serwer do serwera podstawowego, otrzymuje on informację o innym autorytatywnym serwerze, z którym może się skontaktować. Przedsta­ wiony proces referowania umożliwia przeszukanie całego drzewa przestrzeni nazw, aż do momentu odnalezienia serwera nazw, który zna i potrafi przekształcić nazwę oraz przekazać adres IP klientowi zwracającemu się z zapytaniem. DNS może również odnaleźć adres przekaźnika poczty powiązanego z nazwą do­ meny na oraz przechowywać dowolną listę podanych mu podczas konfiguracji hie­ rarchicznych nazw. Możemy korzystać z tych usług i dopasowywać je do naszych

i-

Rozdział 14. ° PRZEKSZTAŁCANIE NAZW

325

potrzeb. Możemy na przykład przechowywać listę usług wraz z przekształceniami nazw i przyporządkowanymi im numerami telefonów, które potrzebne mogą być klientowi poszukującemu informacji o poszczególnych usługach świadczonych przez naszą firmę. Możemy też przechowywać listę produktów wraz z przekształ­ ceniami nazw i adresów producentów je sprzedających.

Autorytatywny lub nieautorytatywny? Serwery nazw uznawane są za autorytatywne jeżeli potrafią przekształcić daną nazwę. Jeżeli nie posiadają w swojej bazie poszukiwanej nazwy (nie są uznawa­ ne za autorytatywne), przekazują zapytanie do innego serwera nazw z nadzieją, że będzie on autorytatywny.

Nazwy domen Internetowych Kiedy przyglądamy się nazwie domeny, w pierwszej kolejności zauważamy, że składa się ona z kilku oddzielonych kropkami skrótów. Jeżeli jesteśmy użytkowni­ kami intensywnie korzystającymi z Internetu, bądź posiadamy własną stronę inter­ netową, wiemy że kolejność tych skrótów nie jest przypadkowa. Skróty oraz ich umiejscowienie mają określone znaczenie. Tak jak w przypadku dziesięciocyfrowego numeru telefonu: wiemy, że pierwsze trzy cyfry są numerem kierunkowym, po­ nieważ jest on zawsze na początku. Jeżeli nie użyjemy numeru kierunkowego lub nie wprowadzimy go przed wybraniem numeru docelowego, nie uzyskamy połączenia. Hierarchia nazw została zorganizowana przez DNS w sposób umożliwiający szyb­ kie połączenie z serwerem w celu odnalezienia adresu poszukiwanej strony inter­ netowej. Przyjrzyjmy się jak DNS dzieli każdą nazwę domeny. DNS dokonuje po­ działu nazwy domeny na poszczególne części reprezentujące stronę lub grupę. Części te nazywane są domenami lub identyfikatorami (label), na przykład F r e . d e v r y . e d u . DNS dzieli nazwę domeny na trzy domeny. Im niższy poziom domeny, tym bar­ dziej staje się ona szczegółowa. W podanym przykładzie najniższym poziomem domeny jest F r e . d e v r y . e d u , nazwa domeny kampusu Fremont Uniwersytetu DeVry. Domena drugiego poziomu to d e v r y . e d u , czyli nazwa domeny Uniwer­ sytetu DeVry. Natomiast . e d u jest nazwą domen używaną przez instytucje eduka­ cyjne i reprezentuje domenę górnego poziomu. Wyobraźmy sobie, co by było gdy­ byśmy musieli wpisywać długie, skomplikowane nazwy domen w nieskróconej postaci. DNS korzysta z przyjętego systemu, aby skracać nazwy domen w celu ułatwienia ich wpisywania oraz organizacji. Podczas tworzenia systemu domen możemy wybrać identyfikatory dla wszystkich części nazwy domeny ponieważ DNS określa tylko formę nazwy — a nie jej war­ tość. Jednakże, większość użytkowników korzysta z identyfikatorów używanych przez oficjalne systemy nazw internetowych. Mimo, że system ustanawia pewien

326

TCP/IP. SZKOŁA PROGRAMOWANIA

porządek, robi to w sposób ogólny i elastyczny. System akceptuje wszystkie dome­ ny i pozwala wybrać hierarchię nazw — geograficzną lub organizacyjną. Po podłą­ czeniu naszej instalacji TCP/IP do sieci globalnej nie musimy już zmieniać nazwy.

Zapytania i mapowanie DNS korzysta z zapytań oraz mapowania, aby przekształcać adresy IP na nazwy domen i na odwrót. Aby pomóc w przekształceniu adresu IP lub nazwy domeny, DNS przechowuje informacje o ich mapowaniu zapisując je na dysku lub buforuje w pamięci RAM. Buforowanie (caching) omówimy w dalszej części rozdziału. Aby zrozumieć dalszą część rozdziału powinniśmy zapoznać się z następującymi okre­ śleniami: > M apoioanie oraz przekształcanie oznaczają odnajdywanie adresu IP nazwy do­ meny. > M apowanie odwrotne oznacza odnajdywanie nazwy domeny dla danego adresu IP. > Zapytanie odw rotne jest poleceniem wywołującym mapowanie odwrotne. Za­ pytania odwrotne wymagają od serwera przeszukania całego zestawu serwerów, co jest rzadko stosowane.

TBuforo'warnie (caching) Podobnie jak wydajny urzędnik, serwery nazw przechowują wszystkie zapytania (mapowania) zapisując je na dysku lub buforując w pamięci RAM. W ten sposób serwer zachowuje wszystkie ostatnio przekazywane dane i posiada najnowsze przekształcenia nazw. Buforowanie, dzięki swojej szybkości, obniża również koszty przekształcania nazw nie znajdujących się w zasobach lokalnych. Buforowanie to kilka różnych czynności, których celem jest odnalezienie przekształcenia adresu IP: 1. Kiedy serwer otrzymuje zapytanie o przekształcenie nazwy, sprawdza czy nazwa ta jest częścią jego strefy (czy serwer ten jest autorytatywny dla tej informacji). 2. Jeżeli nie jest, serwer sprawdza swój bufor, który przechowuje informacje przez około dwa dni. 3. Jeżeli znajduje informacje w buforze, przekazuje je klientowi. 4. Serwer przekazując informacje klientowi, informuje go, iż uzyskał je z zasobów lokalnych lub od innego autorytatywnego serwera (nie z tablicy lokalnej). Prze­ kazuje klientowi nazwę domeny oraz jej rozwiązanie (adres IP mapowany dla poszukiwanej nazwy). 5. Informacja może być nieaktualna. Jeżeli zależy nam na czasie przyjmujemy to co przekazuje nam serwer. Jeżeli potrzebujemy dokładnej informacji, możemy skontaktować się z autorytatywnym serwerem w celu zweryfikowania informacji.

Rozdział 14. • PRZEKSZTAŁCANIE NAZW

327

Format wiadomości serwera domen Jeżeli po sprawdzeniu własnego bufora, serwer nie może wciąż udzielić klientowi odpowiedzi, sam staje się klientem (występując jako pośrednik hosta źródłowego) i za pośrednictwem odpowiednio sformatowanej wiadomości zadaje serię pytań autorytatywnemu serwerowi. Każda wiadomość składa się z trzech elementów: !> nazwy domeny, która ma zostać przekształcona > klasy lub rodziny protokołów używanych przez nazwę domeny > rodzaju nazwy domeny Zapytany serwer odpowiada (informacjami zamieszczonymi w poszczególnych polach wiadomości). Jeżeli dany serwer nie posiada poszukiwanej informacji, jego odpowiedź zawiera informacje oraz adresy IP serwerów, które mogą udzielić pełnej odpowiedzi. Rysunek 14.2 przedstawia przykład formatu wiadomości DNS. Poniżej objaśniamy szczegółowo każde wyszczególnione na rysunku pole. Ry s u n e k 1 4 .2 .

Wiadomość DNS ma 12-bajtowy nagłówek, po którym następują cztery pola o zmiennej długości

ID

QR

OPCODE

Flagi

QDCOUNT

ANCOUNT

NSCOUNT

ARCOUNT

RCODE

se kcja pytań 0 o

se kcja odp o w ie d zi o 0 0

se kcja auto ryzacji 0 0 o

se kcja inform a cji d o d a tko w ych o

Identyfikator (ID) Szesnastobitowe pole identyfikacyjne dopasowuje pytania i odpowiedzi. Klient ustawia wartość identyfikatora, serwer odpowiadając zwraca ją. QR Jednobitowe pole QR odpowiada za identyfikację czy wiadomość jest zapytaniem, czy odpowiedzią. Zero (QR=0) oznacza zapytanie, jeden (QR=1) oznacza odpowiedź.

328

TCP/IP. SZKOŁA PROGRAMOWANIA

Opcode Czterobitowe pole Opcode definiuje bardziej szczegółowo znaczenie bitu QR. Ta­ bela 14.2 przedstawia różne wartości pola opcode oraz ich znaczenie.

Tablica 14.2.

O p co d e

Opcode

Znaczenie

0

Zapytanie standardowe (QUERY)

1

Zapytanie odw rotne (IQUERY)

2

Zapytanie o stan serwera (STATUS)

3-15

Zastrzeżone

Flagi To siedmiobitowe pole określa rodzaj wiadomości. Pole flagi podzielone jest na ko­ lejne pięć części (patrz rysunek 14.3). I> AA (odpow iedź autorytatyw na — authoritative answer) — Bit 5 nagłówka. To jednobitowe pole flagi oznacza odpowiedź autorytatywną, co oznacza, że ser­ wer nazw jest autorytatywny dla poszukiwanego rozwiązania domeny. I> TC (truncation) — Bit 6. To jednobitowe pole flagi oznacza skrócenie, czyli informu­ je, że odpowiedź przekroczyła 512 bajtów i otrzymano tylko pierwsze 512 bajtów. > KD (konieczność rekursji) — Bit 7. To jednobitowe pole flagi oznacza koniecz­ ność rekursji. Ustawienie tej flagi i zwrócenie jej w odpowiedzi, (jeżeli jest usta­ wiona) wskazuje serwerowi nazw, że powinien samemu poszukać odpowiedzi — zapytanie rekursywne. Jeżeli jednak, bit flagi nie jest ustawiony, a serwer nazw nie dysponuje AA, zapytany serwer nazw odsyła listę wszystkich innych seiwerów posiadających odpowiedź na to zapytanie — zapytanie iteracyjne. > RA (rekursja dostępna) — Bit 8. To jednobitowe pole flagi oznacza dostępność rekursji. Jeżeli serwer obsługuje rekursje, wartość tego pola wynosi 1. Większość serwerów nazw obsługuje rekursję. > Zero — Wartość bitów 9 - 1 1 wynosi zawsze zero (0). Należy zwrócić uwagę na to, że rysunek 14.3 przedstawia również pola QR, Opcode i Rcode oraz ich relacje względem pola flag. Ry s u n ek 1 4 .3 . N a le ży z w ró c ić u w a g ę na re la c je p o z o s ta ły c h pól w z g lę d e m p o d z ie lo n e g o pola fla g

QR

opcode

1

4

AA TC RD RA 1

1

1

1

(zero) 3

rcode 4

Rozdział 14. • PRZEKSZTAŁCANIE NAZW

329

Rcode To czterobitowe pole określa kod odpowiedzi oraz dopełnia parametry bitów od 0 do 11. Tabela 14.3 przedstawia znaczenia różnych wartości Rcode. T ablica 1 4 .3 . O p co d e Pole

Znaczenie

0

Brak btędu

1

Błąd form atu w zapytaniu

2

Błąd serwera

3

Nieistniejąca nazwa

4

Niezaim plem entowane

5

Odmowa

6

Zarezerwowane dla przyszłego wykorzystania

Pole Rcode uzupełnia w bitach od 0 do 15 parametry, które rozpoczyna pole QR. Tabela 14.4 przedstawia znaczenie różnych bitów w poszczególnych polach para­ metrów. Tabelę należy czytać wraz z rysunkiem 14.2 (Format wiadomości DNS). T abela 1 4 .4 . Z n a c z e n ie b itó w w po lu p a ra m e tru . Lokalizacja bitu 0

Znaczenie Działanie: 0 Zapytanie

1 Odpowiedź 1 -4

Typ zapytania:

0 Zapytanie standardowe 1 Zapytanie odwrócone 2 Stan serwera 3 - 1 5 Zarezerwowane 5

Ustaw iony w przypadku odpowiedzi autorytatywnej (AA)

6

Ustawiony w przypadku odpowiedzi skróconej (TC)

7

Ustawiony w przypadku potrzeby rekursji (RD)

8

Ustawiony w przypadku rekursji dostępnej (RA)

9-11

Zarezerwowane (o wartości zero)

12-15

Typ odpowiedzi: 0 Brak błędu

4 Niezaim plem entowane

1 Błąd form atu w zapytaniu

5 Odmowa

2 Błąd serwera 3 Nieistniejąca nazwa

6 - 1 5 Zarezerwowane

330

TCP/IP. SZKOŁA PROGRAMOWANIA

Nagłówki pytań i odpowiedzi Kolejne cztery szesnastobitowe pola określają zmienną długość pozostałych czte­ rech sekcji. Pola te są wzajemnie powiązane. W tabeli 14.5 zostały one przedstawio­ ne wraz z wyjaśnieniem ich znaczenia. T abela 1 4 .5 . Ostatnie cztery pola wiadomości DNS Pole

Znaczenie

QDC0UNT

Liczba wprowadzonych zapytań

ANCOUNT

Liczba rekordów zasobów (RR) w sekcji odpowiedzi

NSCOUNT

Liczba rekordów zasobów(RR) serwerów nazw w sekcji autoryzacji

ARCOUNT

Liczba rekordów zasobów (RR) w sekcji inform acji dodatkowych

Większość pól jest wypełniana w sposób automatyczny. Klient wypełnia tylko sekcję pole pytania wiadomości. Zazwyczaj wartość pola pytania wynosi 1, a pozostałych trzech pól 0. Najczęściej pole pytania zawiera tylko jedno pytanie. Rysunek 14.4 przedstawia format wiadomości. Ry s u n ek 1 4 .4 .

Rysunek przedstawia format wiadomości zapytania DNS

i

nazwa zapytania

typ zapytania

klasa zapytania

Pole zapytania składa się z trzech części: nazwy zapytania, typu zapytania, klasy zapytania. Nazwa zapytania określa nazwę domeny będącą przedmiotem zapyta­ nia. Typ zapytania określa rodzaj pytania (o nazwę komputera lub adres poczto­ wy). Generuje to odpowiedź (zwaną rekordem zasobu lub RR). Każda odpowiedź ma swój typ, o czym piszemy w dalszej części tego rozdziału. Pole klasy zapytania umożliwia korzystanie z nazw internetowych. S ew er odpowiada za wypełnianie pola odpowiedzi. Pola odpowiedzi, autoryzacji oraz informacji dodatkowej składają się z RR-ów, ilustrujących nazwy domeny i przekształcenia. Każdy RR reprezentuje jedną nazwę.

Typy nazw domen Gdy DNS umieszcza nazwę w systemie nadaje jej typ, aby wskazać, czy dana na­ zwa domeny spełnia rolę adresu komputera, skrzynia pocztowej, innego użytkow­ nika itp. W ten sposób, choć DNS trzyma wszystkie typy razem, chcący odwiedzić naszą stronę WWW znajdą jej adres bez problemu.

Rozdział 14. ° PRZEKSZTAŁCANIE NAZW

331

T a b e la 1 4 . 6 . T y p y RR DN S

Nazwa

Opis

Zawartość

A

Adres hosta

3 2 -b ito w y adres IP

CNAME

Nazwa kanoniczna

Kanoniczna nazwa domeny, wykorzystywana przez niektóre strony FTP jako aliasy dla innych systemów

HINFO

CPU i OS

Nazwa CPU oraz systemu operacyjnego

MINFO

Inform acje o skrzynce pocztowej

Informacje o skrzynce pocztowej lub liście pocztowej

MX

W ym iana poczty

16-bitow a wartość preferencji oraz nazwa hosta, która dokonuje w ym iany poczty dla domeny

NS

Rekord serwera nazw

Identyfikuje autorytatywne serwery nazw

PTR

Rekord wskaźnika

Adres IP przedstawiony w form ie odwróconej nazwy domeny z końcówką in-addr.arpa

SOA

Początek strefy w pływ ów

Pole definiujące część hierarchii nazewniczej używanej przez serwer

TXT

Tekst nieokreślony

Niezrozumiały łańcuch tekstu ASCII

Przykłady DNS Przyjrzyjmy się niektórym przykładom pochodzącym z programu Sniffer. Roz­ poczniemy od prześledzenia przykładu, w którym host wysyła zapytanie. Przyj­ rzymy się całej jego drodze, aż do momentu przekazania rozwiązania (przekształcenia nazwy). Rysunek 14.5 przedstawia hosta wysyłającego zapytanie o przekształcenie nazwy na adres internetowy. Ry s u n e k 1 4 .5 .

Należy zwrócić uwagę na źródłowy port UDP (2798) oraz port docelowy (53), które wskazują, iż zapytanie pochodzi od klienta DNS zwracającego się do standardowego portu DNS

r Sniłlei Pio - Local/Piał-Up Adaptei, I • [Atlcomp g

!)/4/23UG Liliow e! frameil

Ba [¿entai Çapiu,-e Q .i;płayTopił W indowłjrip

g?|h

| a\3\ islsilatelaltftlgl

B ^1 UDP: UDP: UDP: Source port port i | Q Destination UDP:

e

oil

r.\

■ 53 (Domain) 1 53 (Domain)

Checksum = 777D (correct) [26 byte(s) □£ data] Internet Domain Hane Service header -

! Response ' Authoritative answer ' Hot truncated “ Data HOT verified 1 ...... = Recursion available Response code = Hane error (3) ... 0 .... «• Unicast packet Question count ■ 1, Answer count ° 0 Authority count ■» D. Additional record count 1 ZQHE Section Hane = HART.PRESS Type = Host address (A,1) Class = Internet (IH.l)

iDecodeĄM atrixAH ostTohkĄPrclocslDai.ĄSlntbties7~~ FwH elp,piesiFI a i s » . .'l l i a s fe a

g

I

srj*r I S

j ¿ 3 Col35S

&r

332

TCP/IP. SZKOŁA PROGRAMOWANIA

Korzystając z przykładu przedstawionego na rysunku 14.5, możemy zauważyć, że w nagłówku DNS znajduje się zapytanie o przekształcenie nazwy t rwind. in d . t rw. co na internetowy adres hosta. Klient ustawił bit rekursyjny, wskazując odbierającemu serwerowi DNS, aby przekierował to zapytanie do innego serwera jeżeli sam nie jest autorytatywny dla danej domeny i nie jest w stanie przekształcić jej nazwy wy­ korzystując zasoby lokalne. Rysunek 14.6 przedstawia nieautorytatywny serwer zwracający się z zapytaniem do innego serwera w imieniu klienta. R y s u n e k 1 4 .6 .

Należy zwrócić uwagę, że port DNS UDP źródłowy i port docelowy to ten sam port (53), co oznacza, iż hosty: wysyłający i odbierający są serwerami DNS wykorzystującymi standardowy port serwera

£2 P e

fclcnioi £cp!uc Dnphy lo ch y/nda« He'D

am i e U l

-| 5 | *1

alalolatlaliatel n\ fel o il

IP: Ho options UDP Header Source port » 53 (Donain) Destination port ■ S3 (Donain) j ' - D ODP: length = 36 Q U D P : Checksun = FPDD (correct) Q U D P : [20 byte(s) o£ data] Q UDP: S Ik D U S : ----- Internet Donain Hane Service header ----j - Q D1IS: DUS: ID " 33628 DHS: Flags » 00 D N S : 0 .....= Connand Q DHS: 000 0... = Query ¡L} DHS: .... ..0. = Hot truncated 1-1 DHS: ...... 0 = Ho recursion desired Q DHS: Flags = OX ~ . ..0 . ... •• Hon Verified data HOT acceptable Question count ■ 1, Answer count = 0 Authority count = 0. Additional record count - 0

ClD

ZONE Section Hane ■> HART.PRESS Type = Host address (A.l) Class = Internet (IH.l)

yD ecodeAM etro:ĄH astTableAProiocdD&.ASlailttics/ FraHe!o.p 3 » F lo . | B y M ic .o ..| SMI« - I SUE«**--!_____________ ¡l.?iH>TEtS 1MI9PM

364

TCP/IP. SZKOŁA PROGRAMOWANIA

Rysunek 1 6 .4 . R a m ka p rz e d s ta w ia k lie n ta w y s y ła ją c e g o p ierw szy w s tru m ie n iu

L r S n jife i Pro - Lo c a l/D ia l-lłp Adapter_1 - IS n ill : 3 /3 Ethernet fia ra o ] £ 5 £3=

Mordm

Capline

Disploy Jo o b

Window

FI r : r a

ISource Address* . 0.2 [128. [ 128. 1. 0 . 2]

[128.

1.0.1]

iDestAddreś

[ 1 2 8 . 1 . 0 . 1] [ 1 2 8 .1 .0 .2 ] [ 1 2 8 .1 .0 .1 ]

=Jj9j *]

hjelp

P.I & |

b?|H1 # |r^ l

Ol

iLayei

1Summary

TFTP UDP UDP

¡W r i t s r e q u e s t F i l e = \ i u n k . t : : t D - 1 0 0 1 S= 1 4 8 7 LEtJ=12 D = 1487 S - 1 0 0 1 LEN=88

I

b lo k d a n y c h

2 -Q IP: I d e n t i f i c a t i o n OX a IP: F l a g s . 0 ■ may f r a g m e n t a IP: .. 0 ■ l a s t fra g m e n t 0 IP: Q IP: F r a g m e n t o f f s e t : 0 b y t e s 2 5 5 s e c o n d s /h o p s a IP: T im e t o l i v e 17 (UDP) a IP: P r o t o c o l a IP: H e a d e r c h e c k s u m : BB 79 ( c o r r e c t ) [ 1 2 8 .1 .0 .2 ] a IP: S o u r c e a d d r e s s a IP: D e s t i n a t i o n a d d r e s s = [ 1 2 8 . 1 . 0 . 1 ] a IP: No o p t i o n s a IP: UDP H e a d e r ■ BS0UDP: a udp = 1001 a udp S o u r c e p o r t a udp D e s t i n a t i o n p o r t = 1 4 8 7 = 88 a udp L e n g th ■=■ 3BCC ( c o r r e c t ) a udp C hecksum a udp [ 8 0 b y t e ( s ) o f d a t a ] a udp . Decode A Malm

KH03I Tgtfa A Protocol to t. A statistics

For He'p. press F1

3 B s u .i|[! H

(

&

Sa S3 ^

II ¡ESm».t««|

.Ik [~

¡¡7Mim =..l S S " « ° ~ I u ą En>toi. I

12:09 PM

Rozszerzenia TFTP Pierwotne możliwości TFTP zostały rozszerzone, aby umożliwić klientowi negocja­ cję opcji z serwerem. Zdefiniowana została tylko jedna konkretna opcja (określająca wielkość bloku); jednak specyfikacja jest na tyle ogólna, że twórcy implementacji mogą wedle potrzeb dodawać własne. Większy rozmiar bloku zwiększa wydajność transferu plików pomiędzy zdalnymi hostami. Starsze implementacje mogą jednak nie obsługiwać tego rozszerzenia, co powoduje ograniczenie transferu do standar­ dowych 512 bajtów. Strona klienta kontroluje negocjacje opcji. Strona serwera nie może zażądać nego­ cjacji opcji; może jedynie odpowiedzieć na zapytanie klienta. Jeżeli klient chce sko­ rzystać z dodatkowych opcji, spoza standardowej specyfikacji TFTP, może określić swoje oczekiwania w żądaniu inicjującym (zapisu lub odczytu). Serwery TFTP, które umożliwiają prowadzenie negocjacji opcji, dysponują pakie­ tem potwierdzenia opcji (OACK) w celu informowania klienta o możliwości skorzy­ stania z danej opcji. Jeżeli serwer zaakceptuje opcję, informuje o tym klienta i wprowadza ją do pakietu OACK. Jeżeli natomiast nie akceptuje opcji, po prostu ją ignoruje i nie umieszcza jej w ramce OACK. Klienci korzystają tylko z tego na co zezwalają serwery. Klient może żądać wielu opcji podczas procesu negocjacji, wymieniając je wszystkie w pakiecie odczytu lub zapisu. Klient wprowadza żądanie opcji do standardowego żądania odczytu lub za­ pisu, używanego do inicjowania sesji pomiędzy klientem i serwerem. W w nagłów­

Rozdział 16. • TRYW IALNY PROTOKÓŁ PRZESYŁANIA PLIKÓW (TFTP)

365

kach klientów umożliwiających negocjowanie opcji pojawiają się dwie dodatkowe ramki: opcja, która określa żądaną opcję, np. rozmiar bloku, oraz wartość, która określa wartość podanej opcji. Dla przykładu, oczekiwana wartość rozmiaru bloku wynosi od 0 do 65464.

Pakiet OACK Pakiet OACK wykorzystuje kod Opcode o wartości 6. Serwer wysyła pakiet OACK aby zablokować lub potwierdzić możliwość skorzystania z opcji żądanej przez klien­ ta. Tabela 16.7 opisuje pola pakietu OACK. Pary opcji i ich wartości powtarzają się w zależności od liczby żądanych opcji. Tabela 16.7. Pola p a k ie tu O ACK Pole

O ktety

Opis

Opcode

2

Identyfikuje pakiet OACK za pom ocą Opcode 6.

Opcja 1

2

Odpowiada pierwszej opcji wym ienionej w pakiecie zapytania klienta 0 odczyt lub zapis. Dodatkowe opcje w ym ieniane są jako opcja 2, opcja 3, itd. 1 odpow iadają opcjom w ym ienionym w żądaniu odczytu lub zapisu przez klienta.

W artość 1

2

Odpowiada pierwszej opcji wym ienionej w pakiecie żądania odczytu lub zapisu przez klienta o odczyt. Dodatkowe wartości określane jako wartość 2, wartość 3, itd. odpow iadają opcjom w ym ienionym w żądaniu odczytu lub zapisu przez klienta.

Podsumowanie TFTP umożliwia proste, szybkie i niekosztowne przesyłanie plików pomiędzy hostami. TFTP odczytuje lub zapisuje pliki do lub z seiwera na zlecenie klienta. Każda wymia­ na rozpoczyna się od wystąpienia przez klienta do serwera z żądaniem odczytu lub zapisu pliku. Pierwszy wysłany pakiet żąda transferu plików z serwera i ustanawia połączenie pomiędzy zmiennym portem UDP klienta (znanym jako TiD) oraz standardowym portem 69 serwera TFTP. Początkowo protokół TFTP mógł dokonywać jedynie transfe­ ru 512-bajtowych bloków danych, jednak współczesne implementacje umożliwiają przesyłanie większych bloków. Blok zawierający mniej niż 512 bajtów jest ostatnim blokiem.

366

TCP/lP. SZKOŁA PROGRAMOWANIA

TFTP ma pięć rodzajów pakietów: RRQ, WRQ, ACK, danych i błędu. Pakiety RRQ lub WRQ określają nazwę pliku i rodzaj żądania: odczytu (RRQ) lub zapisu (WRQ) pliku. Pakiety danych przesyłają żądane dane. Pakiety ACK potwierdzają odbiór bloków danych. Pakiety błędu sygnalizują wystąpienie błędu podczas transferu bloków danych.

P ytania sprawdzające 1. Jakie są różnice pomiędzy FTP a TFTP? 2. Wymień niektóre z korzyści wynikające z użycia TFTP. 3. Jakiego rodzaju usługi świadczy TFTP? 4. W jaki sposób rozpoczyna się każda wymiana? 5. Wymień pięć rodzajów pakietów używanych przez TFTP oraz przedstaw do czego służą. 6. Co oznacza blok zawierający mniej niż 512 bajtów? 7. Na czym polega metoda potwierdzeń lock-step i do czego jest ona wykorzystywana przez TFTP? 8. Wymień trzy przypadki wywołania pakietu błędu. 9. Co oznaczają zwroty: zapis pliku i odczyt pliku? 10. Przedstaw krótko działanie TFTP. 11. Rozszerzenia TFTP umożliwiają prowadzenie negocjacji opcji pomiędzy klientem a serwerem. Jaki ma to wpływ na rozmiar bloku? 12. W jaki sposób odbywa się negocjacja opcji TFTP? 13. Co to jest pakiet OACK?

PROSTY PROTOKÓŁ ZARZĄDZANIA SIECIĄ (SNMP) Przegląd treści rozdziału: o

Zarządzanie siecią

•

o

SNMP

o Format wiadomości SNMP

Menadżerowie, agenci i proxy

W p ro w a d zen ie do zarządzania siecią Dla wielu administratorów problem zarządzania siecią może wydawać się abstrak­ cyjny. A tak na marginesie, to kiedy mają oni czas na zarządzanie swoich sieci? Być może po tym jak rozwiążą wszystkie najpilniejsze problemy zagrażające sieci. Czym tak naprawdę jest zarządzanie siecią? Niektórzy uważają, że jest to elimino­ wanie pojawiających się problemów; inni, iż jest to zapobieganie ich powstawaniu — lub przynajmniej ograniczanie problemów do tych, prowadzących do mniej po­ ważnych zakłóceń pracy. Niezależnie od obranego podejścia do zarządzania siecią — prewencyjnego lub reakcyjnego — istnieje protokół, który łączy oba sposoby myślenia: Prosty protokół zarządzania siecią (SNMP).

'I

368

TCP/IP. SZKOŁA PROGRAMOWANIA

W RFC 1157 zdefiniowana została oryginalna implementacja SNMP, który jest dzi­ siaj najczęściej wykorzystywanym protokołem do zarządzania siecią zdalną. SNMP został początkowo zaprojektowany, aby ułatwiać zdalne zarządzanie hostami in­ ternetowymi oraz bramami, wyewoluował jednak w kierunku umożliwiającym mu obsługę znacznie większej liczby urządzeń końcowych. SNMP byl wcześniej znany pod nazwą prosty protokół zarządzania bramą (SGMP — Simple Gateway Mana­ gement Protocol). Największy wkład w rozwój protokołu do zarządzania systemami internetowymi miała Komisja ds. działalności Internetu (IAB — Internet Activities Board). Komitety ds. Internetu powołane zostały w połowie lat osiemdziesiątych w celu opracowania protokołów zarządzających, skutkiem czego było pojawienie się trzech protokołów: ► HEMS (High-level Entity Management Systems) — system zarządzania obiek­ tami wysokiego poziomu. t> SGMP — przemianowany na SNMP. ► ISO's CMIP (Common Management Information Protocol) — wspólny protokół zarządzania informacją.

Uwaga ISO (International Organization for Standarization — Międzynarodowa Organiza­ cja Norm alizacyjna) jest organizacją, która ustanawia standardy dla protokołów sieciowych. Najpopularniejszym jest siedm iow arstw ow y model referencyjny OSI.

Po dogłębnych analizach postanowiono skorzystać początkowo z protokołu SGMP, planując przy tym przejście na protokół zarządzający standardu ISO CMIP w przy­ szłości. Jak wspominaliśmy poprzednio SGMP, któiy zmienił nazwę na SNMP, po­ zostaje najczęściej wykorzystywanym protokołem zarządzającym w Internecie i jest standardem oficjalnym. SNMP jest prostym, niezależnym od producenta, narzędziem zarządzającym. Wszyst­ kie wymienione protokoły korzystają z poświęconych zarządaniu dokumentów RFC 1065 i 1066, w których opisano jak powinny być identyfikowane obiekty za­ rządzane. W tym celu stosowana jest metoda notacji składn i abstrakcyjnej 1 (ASN.l — A bstract Syntax N otation 1) wykorzystująca arbitralne struktury danych do re­ prezentowania obiektów zarządzanych. W RFC 1156 przedstawiono standardowe internetowe MIB-y (Baza informacji zarzą­ dzania — Management Information Bases), określane jako MIB I i II, które przed­ stawiają standardowe obiekty zarządzane orazokreślają ich miejsce w hierarchicznej strukturze drzewa. Wszystkie implementacje SNMP muszą obsługiwać przynajm­ niej te dwa typy MIB. Mogą one również wprowadzać swoje własne podstruktury MIB zawierające zarządzane obiekty, pod warunkiem, że są one zgodne z wymogami

Rozdział 17. • PROSTY PROTOKÓŁ ZARZĄDZANIA SIECIĄ (SNM P)

369

SMI (Standardowe informacje zarządzania) — Standard Management Information) zdefiniowanymi w RFC 1156.

SNMP SNMP pracuje w oparciu o UDP, zapewniając szybką wymianę żądań i odpowiedzi zarządzających pomiędzy hostami korzystającymi z aplikacji bazujących na SNMP, takich jak SunNetManager lub OpenView firmy HP. Są to jedynie przykłady bar­ dzo licznej rodziny programów wykorzystujących SNMP do zdalnego monitoro­ wania i zarządzania urządzeń obsługujących SNMP. SNMP świadczy usługi przesyłania żądań i odpowiedzi zarządzania w imieniu aplikacji. Działa niezależnie od szczegółów aplikacji, architektury warstw niskiego po­ ziomu oraz aplikacji warstw wyższych. Wszystko to czyni SNMP prostym i ogólnym, ale jednocześnie potężnym protokołem zarządzania siecią, mogącym współpracować z wieloma platformami, systemami operacyjnymi oraz protokołami. Mimo, że po­ czątkowo SNMP pracował tylko z IP, to dzięki swojemu ogólnemu charakterowi mo­ że współpracować również z innymi protokołami, takimi jak np. IPX. Na SNMP składają się trzy główne elementy, które umożliwiają zdalne zarządzanie: ► Menadżer — generuje polecenia i odbiera notyfikacje. ► Agent — odpowiada na pytania i tworzy notyfikacje. ► Proxy — przekaźnik. Oprogramowanie urządzenia implementuje wszystkie trzy elementy i udostępnia usługi komunikacyjne SNMP programom warstwy aplikacji.

Menadżer SNMP Jako hosty, menadżerowie SNMP obsługują oprogramowanie (np. OpenView) słu­ żące do zdalnej kontroli i monitorowania agentów SNMP. Hosty te stanowią central­ ny punkt zarządzania zapewniając interfejs użytkownika, umożliwiający przeka­ zywanie poleceń agentom za pośrednictwem SNMP. Pozwala to obsługującemu na pobieranie informacji, zmianę konfiguracji, a nawet ponowne uruchomienie urządze­ nia. Menadżerowie SNMP otrzymują również od agentów niezamawiane notyfika­ cje (nazywane w iadom ościam i- pułapkam i), informujące o naruszeniach zasad pracy — takich jak polecenie zmiany konfiguracyjnej, otrzymane przez nieautoryzowanego menadżera SNMP. Dwa przykłady żądań to: g e t (pobierz), które używane jest do odczytu informacji oraz s e t (ustaw) wykorzystywane do modyfikacji parametrów. Menadżerowie SNMP kierują swoje żądania do docelowego portu UDP 161 agenta, natomiast na­ słuchują wiadomości-pułapek na porcie UDP 162.

370

TCP/IP. SZKOŁA PROGRAMOWANIA

Agenci SNMP Działając jako hosty, agenci SNMP obsługują respondery oraz generatory notyfika­ cji SNMP. Agenci nasłuchują żądań menadżerów na porcie odbiorczym UDP 161. Menadżerowie SNMP zwracają się do agentów z zapytaniami o informacje, które przechowywane są w lokalnych bazach danych, określanych nazwą MIB (Mana­ gement Information Base). Z powodu swoich niewielkich rozmiarów, oprogramo­ wanie agenta mieści się w układach ROM, które znajdują się w urządzeniach takich jak port nadbiornika routera czy interfejs przełącznika, stanowiąc część ich oprogra­ mowania. Agenci nadzorują bazę danych MIB, posiadającą hierarchiczną strukturę drzewiastą składającą się z wielu obiektów, które mają być zarządzane i monitorowane. Przykładowo, interfejs Ethernetu może reprezentować obiekt zarządzany w kon­ tekście określonego agenta jakim może być router. Interfejs możemy monitorować pod kątem określonych informacji związanych z przepływającym przez niego ru­ chem, śledząc np. liczbę rozgłoszeń, błędów CRC, kolizji, itp. Oprócz odpowiadania na żądania menadżera o przekazanie lub zmodyfikowanie określonych informacji, agenci mogą również zostać skonfigurowani, aby przeka­ zywali ostrzeżenia menadżerom. Agenci ostrzegają menadżerów wysyłając nie za­ mówione wiadomości-pułapki w momencie pojawienia się problemu lub kiedy coś próbuje zakłócać działanie agenta — na przykład żądanie modyfikacji parametrów pochodzące od nieautoryzowanego menadżera. Agenci wysyłają menadżerom wiadomość-pułapkę na port 162 UDP.

W idoki MIB Każdy agent przechowuje własne zbioiy lokalnie zarządzanych obiektów wewnątrz MIB, nazywane również widokami MIB (MIB view). Kiedy menadżerowie żądają dostępu do obiektu znajdującego się w widoku MIB, muszą określić nazwę obiektu przedstawiając ją za pomocą zapisu ASN.l. Zapis ASN.l wskazuje lokalizację obiektu w bazie informacyjnej oraz instancję, czyli unikalne wystąpienie obiektu w zarzą­ dzanym urządzeniu. Ciąg dodatnich liczb całkowitych opisujących ścieżkę drzewka MIB reprezentuje nazwę obiektu, która określa jego lokalizację. Dostawcy mogą rejestrować własne ID gałęzi, co umożliwia rozszerzenie drzewa internetowego i ujęcie w nim określonych obiektów. Przydzielaniem wartości ID podgałęzi drzewa różnym organizacjom zaj­ muje się LANA.

Proxy Proxy SNMP zapewniają możliwość przesyłania wiadomości pomiędzy agentami i menadżerami. Pełnią one również funkcje pośredników pomiędzy agentami hostów korzystających z różniących się wersji SNMP, zapewniając w ten sposób kompaty­ bilność pomiędzy hostami.

Rozdział 17. » PROSTY PROTOKÓŁ ZARZĄDZANIA SIECIĄ (SNM P)

371

Społeczność (community) Agend SNMP muszą zarejestrować się u menadżerów, aby móc rozpocząć odbieranie żądań i wiedzieć do kogo i gdzie wysyłać wiadomości notyfikujące. Sposób w jaki agenci identyfikują się i rejestrują u menadżerów zależy od implementacji. Aby wymiana wiadomości była możliwa, agenci i menadżerowie muszą przynależeć do tej samej domeny, zwanej społecznością. Istnieje jedna domena domyślna zwana dom eną publiczną (public domain); jednakże możemy oczywiście definiować inne domeny dla agentów i menadżerów, dzięki czemu mogą powstawać również inne społeczności. Poprzez definiowanie nowych społeczności, które możemy nazywać w dowolny sposób, ograniczamy nieautoryzowany dostęp. Jeżeli ktoś zamierza w złym zamiarze dodać do sieci zarządzanego przez siebie hosta, aby uzyskać dostęp do agentów, musi najpierw odgadnąć nazwę społeczności oraz skonfigurować swojego menadżera dla tej nazwy. Samo utworzenie nowej społecz­ ności oraz nazwanie jej w wymyślny sposób nie przeszkodzi oczywiście sprytnemu hakerowi w pozyskaniu tych informacji, dlatego konieczne jest uwierzytelnianie oraz listy kontroli dostępu dla ochrony zarządzanych obiektów. SNMP nie posiada specjalnych funkcji do sprawdzania uwierzytelniania oraz kontroli dostępu; mają je jednak aplikacje wykorzystywane przez SNMP. Jeżeli zastosowane zostało proxy, musi ono również przynależeć do tej samej co agenci i menadżerowie społeczności oraz musi się u nich zarejestrować, aby mogło dojść do przekazywania wiadomości. Wszystkie obiekty muszą zostać lokalnie skon­ figurowane przy użyciu odpowiedniej nazwy społeczności oraz wszystkich nie­ zbędnych informacji związanych z uwierzytelnianiem oraz ochroną. Aby wysyłać odpowiedzi i niezamawiane notyfikacje agenci muszą znać również adres warstwy sieciowej menadżera.

Format wiadomości SNMP Wszystkie wiadomości SNMP, za wyjątkiem wiadomości-pułapki, posiadają taką samą strukturę podstawową. Każde zapytanie zawiera numer wersji, umożliwiają­ cą minimalny poziom uwierzytelniania nazwę społeczności oraz jedną lub więcej jednostek danych protokołów (PDU — Protocols Data Units) w zależności od informacji żądanych przez menadżera. Rysunek 17.1 przedstawia architekturę sieci komunika­ cyjnej SNMPvl. Rysunek 17.2 przedstawia format podstawowy wiadomości SNMP.

W ersja Pole wersji określa wersję używanego SNMP. Zarówno agent jak i menadżer muszą używać tej samej wersji SNMP, chyba że zapytanie przechodzi przez proxy, któiy może dokonać zamiany wersji.

372

TCP/IP. SZKOŁA PROGRAMOWANIA

Rys u n e k 1 7 .1 .

Należy zwrócić uwagę, że SNMP korzysta tylko z pięciu wiadomości, na czym opiera się jego prostota w podejściu do zarządzania siecią

S ystem zarządzan ia SN M P

S ystem zarządzan ia S N M P

r

Z a rz ą d z a n e a p lik a c je

US

U

1—'

/‘S ' V /' •°s; ir m ti ■ § ra B W tn

A fA ° O J 1 Ä■& C N o . am l» X I Q) °

Z a rz ą d z a n e ^ zasoby

Z arządza ne obiekty ne obiektv SNMP

obiektam i

-u •s O

CU o O.

O c

— m

u

CD

k O) (/)

OJ

o

Ü

g> (U 5

NJ,

ó s S

OJ

3

(U (U CD

'

f

LLJ>

W iad om o ści M enadże r S N M P

A g e n t SN M P

SN M P

UDP

UD P

Łącze

Łącze

< R y s u n e k 1 7 .2 .

Wszystkie wiadomości SNMP (pobierz żądanie, pobierz kolejne żądanie, pobierz odpowiedź i ustaw żądanie), za wyjątkiem wiadomości pułapki, korzystają z tego samego formatu podstawowego

Î

A p lika cja zarządza

S ie ć kom unikacyjna

>

Wiadomość SNMPPDU pobierz żądanie, pobierz kolejne żądanie, pobierz odpowiedź i ustaw żądanie

Typ PDU

ID zapytania

Stan błędu

Indeks błędu

Nazwał: Wartość 1 I

Nazwa 2: Wartość 2

-------------- Zmienneb lo k i----------------

N azwa społeczności Pole to określa nazwę społeczności. Możemy w prosty sposób uwierzytelnić menadże­ rów i agentów poprzez przypisanie ich do tej samej społeczności. Administratorzy przypisują społecznościom nazwy, które są prostymi nazwami tekstowymi służącymi do pogrupowania autoryzowanych menadżerów z agentami. Agenci mogą należeć tylko do jednej społeczności jednocześnie. Menadżerowie mogą natomiast należeć do wielu społeczności, co umożliwia im łączenie się z wieloma różnymi agentami.

Rozdział 17. • PROSTY PROTOKÓŁ ZARZĄDZANIA SIECIĄ (SNMP)

373

Jednostki danych protokołu (PDU) Pole to określa rodzaj PDU. SNMP ma pięć podstawowych rodzajów PDU: ► Pobierz żądanie (Get request) ► Pobierz następne żądanie (Get-next request) ► Pobierz odpowiedź (Get-response) ► Ustaw żądanie (Set request) t> Pułapka (Trap) Wszystkie PDU typu pobierz i ustaw zawierają te same, wymienione poniżej pola (patrz tabela 17.1). PDU pułapka ma inny format wiadomości oraz pole, które omó­ wimy w dalszej części rozdziału. Tabela 17.1. P o d s ta w o w e po la PDU Pole

Opis

ID żądanie

Każde żądanie zawiera unikalny ID wykorzystywany do dopasowania go do odpowiedniej odpowiedzi udzielonej przez agenta.

Stan błędu

W ykorzystywane do wskazania czy został w ykryty błąd. W przypadku żądań wartość ta będzie zawsze wynosiła zero. Jeżeli pojawia się wartość inna niż zero, oznacza to wystąpienie jednego z następujących błędów: ► 0 = brak błędu ► 1 = zbyt duży PDU ► 2 = nazwa nie istnieje ► 3 = błędna wartość

► 4 = tylko do odczytu ► 5 = błąd ogólny Indeks błędu

Określa rodzaj wykrytego błędu, jeżeli pole stanu błędu wskazuje na jego istnienie.

ID obiektu oraz wartość

Określa ID obiektu oraz jego wartość przedstaw ioną za pomocą A S N .l.

Pułapka PDU Pułapka PDU korzysta z innego formatu wiadomości niż pozostałe cztery rodzaje PDU, ponieważ informuje raczej o powstałych zdarzeniach, niż odpowiada na żą­ dania menadżerów. Rysunek 17.3 przedstawia strukturę pułapki PDU; natomiast tabela 17.2 prezentuje jej pola.

374

TCP/IP. SZKOŁA PROGRAMOWANIA

Rysunek 17.3. Należy zwrócić uwagę, Iż pułapka PD U korzysta z Innej struktury niż pozostałe PDU

- Wiadomość SNMP Wersja

Typ PDU

Przedsiębiorstwo (Enterprise)

Społeczność

Adres agenta

Pułapka PDU

Podstawowy Specyficzny Znacznik Rodzaj rodzaj pułapki czasu Pułapki

Nazwa 1: Wartość 1

Nazwa 2: Wartość 2

Zmienne bloki

Tabela 17.2. Pola pułapki PDU Pole

Opis

Przedsiębiorstwo (Enterprise)

Identyfikuje rodzaj obiektu generującego pułapkę.

Adres agenta

Określa adres w arstw y sieciowej agenta, który utworzył wiadom ość-pułapkę.

ID pułapki podstawowej

Określa powód pojawienia się pułapki: > 0 = zim ny start > 1 = gorący start (wtórne uruchom ienie systemu) e>

2 = link down (rozłączenie)

> 3 = link up (połączenie) > 4 = błąd uw ierzytelniania o 5 = utrata sąsiadującego EGP > 6 = specyficzne dla przedsiębiorstwa Specyficzny ID pułapki

Określa pułapkę specyficzną dla danego dostawcy.

Znacznik czasu

Określa czas, w którym agent utw orzył pułapkę będącą rezultatem jakiegoś zdarzenia.

ID obiektu oraz wartość

Określa ID oraz wartość obiektu, dla którego została utworzona pułapka.

P odsum ow anie Od połowy do końca lat osiemdziesiątych komitety ds. Internetu prowadziły prace nad protokołami zarządzającymi, efektem tych prac było pojawienie się trzech proto­ kołów: HEMS, CMIP i SGMP (nazwany później SNMP, czyli prostym protokołem zarządzania siecią). SNMP miał być rozwiązaniem krótkookresowym, jednakże stał się podstawowym protokołem zarządzania siecią. SNMP zapewnia możliwość przesyłania żądań i odpowiedzi zarządzających w imie­ niu aplikacji. SNMP pracuje niezależnie od specyfiki oprogramowania, jest on więc protokołem prostym i ogólnym, mogącym współpracować z wieloma różnymi roz­ wiązaniami. Menadżerowie SNMP korzystają z oprogramowania do zdalnej kon­ troli i monitorowania agentów SNMP. Menadżerowie występują z żądaniami in­ formacji do agentów. Agenci obsługują oprogramowanie służące do odpowiadania i notyfikacji oraz nasłuchują żądań SNMP wysyłanych przez menadżerów.

Rozdział 17. • PROSTY PROTOKÓŁ ZARZĄDZANIA SIECIĄ (SNMP)

Pytania sprawdzające 1. Pod jaką nazwą znany był wcześniej SNMP? 2. Jakie trzy główne obiekty SNMP umożliwiają zdalne zarządzanie? 3. Czym są agenci SNMP? 4. Czym jest proxy SNMP? 5. Wymień menadżerów SNMP? 6. Co to jest pułapka PDU?

375

376

TCP/IP. SZKOŁA PROGRAMOWANIA

PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP) Przegląd treści rozdziału: o Protokoły otwartego przetwarzania sieciowego (ONC — Open Netw ork Computing)

o Zewnętrzna prezentacja danych (XDR — external Data Representation)

o Sieciowy system plików (NFS — Netw ork File System)

o Zdalne wywołanie procedur (RPC — Remote Procedure Calls)

Wprowadzenie do protokołów otwartego przetwarzania sieciowego Firma Sun Microsystem opracowała protokół systemu plików rozproszonych znany jako sieciowy system plików (NFS), który został wprowadzony w roku 1985 jako część rodźmy produktów otwartego przetwarzania sieciowego (ONC). Zwrot ONC jest wspólną nazwą dla wielu protokołów oraz usług oferowanych przez firmę Sun w formie platformy oraz niezależnego systemu operacyjnego. Niezależność ta umoż­ liwia różnym systemom uzyskiwanie w transparentny sposób dostępu do plików i ob­ sługę technologii PC-mainframe. Mimo, że NFS istnieje w warstwie aplikacji modelu OSI, do działania wymaga rów­ nież implementacji dwóch innych protokołów: XDR (zewnętrznej prezentacji danych) oraz RPC (zdalnego wywołania procedur). XDR zapewnia funkcjonalność warstwy

378

TCP/IP. SZKOŁA PROGRAMOWANIA

prezentacji, natomiast RPC gwarantuje funkcjonalność warstwy sesji. Wszystkie protokoły ONC zostaną szczegółowo opisane w dalszej części rozdziału. Wszystkie trzy protokoły wspólnie zapewniają transparentny dostęp do rozpro­ szonych systemów plików poprzez środowisko LAN lub WAN oraz mapują się w warstwie aplikacji modelu DoD. Nasz przegląd rozpoczniemy od protokołu naj­ wyższej warstwy — NFS, a następnie będziemy przesuwać się w dól. Rysunek 18.1 przedstawia w jaki sposób protokoły ONC umiejscowione są w modelu OSI. R ys u n ek 1 8 .1 .

Rodzina protokołów ONC zapewnia transparentny dostęp do rozproszonych systemów plików za pośrednictwem środowiska LAN lub WAN

Aplikacji

Prezentacji

Sesji

Sieciowy system plików (NFS)

Usługi informacyjne NFS (dawne YP)

Sprawdzanie stanu

Menadżer blokady

Zewnętrzna prezentacja danych (XDR)

Zdalne wywołanie procedur (RPC)

Cechy NFS Nazwa sieciowy system plików wskazuje, iż NFS zapewnia dostęp do informacji znajdujących się w rozproszonych systemach plików praktycznie każdej architek­ tury sieciowej. NFS jest protokółem opartym na relacji klient/serwer i umożliwia klientom NFS dostęp do plików rozproszonych po całym świecie poprzez wysyła­ nie zapytań do zdalnych serwerów NFS. NFS współpracuje z wieloma klienckimi systemami operacyjnymi (MS DOS, Ne­ tWare, Windows, NT, VMS, itp.) oraz architekturami łącz danych LAN i WAN ta­ kimi jak: Ethernet, Token-Ring, X.25, Frame Relay, itp. (patrz tabela 18.2). Imple­ mentacje składają się z oprogramowania klienta i serwera (NFS); interpretatora prezentacji danych (XDR), który zapewnia niezależność od systemu operacyjnego oraz protokołu komunikacyjnego (RPC) zapewniającego łączność pomiędzy wy­ mienionymi składnikami, przesyłając zapytania i odpowiedzi. Bieżąca wersja, NFS wersja 3, zastąpiła wersję 2, z tym że firma Sun nigdy nie wydała wersji 1. Firma Sun opracowała NFS i jego komponenty tak, aby pracowały w war­ stwie transportowej UDP; jednak NFS może również działać w TCP. Mimo, że NFS jest obecnie zaimplementowany jedynie dla protokołów TCP/IP, nie jest wyłącznie do niego ograniczony i nic nie stoi na przeszkodzie, aby został w przyszłości przenie­ siony także do innych zestawów protokołów. Tabela 18.1 przedstawia różne cechy wersji 2 i 3 NFS.

Rozdział 18. • PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP)

379

Tabela 18.1. C e chy 2 i 3 w e rs ji NFS Cecha

V2

V3

Korzyści

Autom atyczne przyłączanie (m ounting)

Tak

Tak

Globalny system plików jest dostępny i widoczny dla użytkowników

Skalowalność (scalability)

Tak

Tak

Sieć może się z łatw ością powiększać wraz z rozwojem przedsiębiorstwa

Scentralizowane adm inistrow anie

Tak

Tak

Zmniejsza uciążliw ie zadania adm inistracyjne

W spólna przestrzeń nazw systemu plików

Tak

Tak

Użytkow nicy i aplikacje mogą się swobodnie poruszać w sieci

Obsługuje konfiguracje bezdyskowe, nie przechowujące danych oraz klientów autom atycznych

Tak

Tak

Obsługa tanich systemów klienta

Elastyczna architektura bezpieczeństwa

Tak

Tak

Zapewnianie bezpieczeństwa dzięki szerokiemu wyborow i m echanizm ów ochronnych

W iele sposobów uwierzytelniania

Tak

Tak

DES, Kerberos, „U n ix Style”

W iele sposobów uwierzytelniania

Tak

Tak

ACLS, „U nix Style”

Jednoczesne obsługiw anie wersji 1 i wersji 2

N/A

N/A

N/A

NFS TCP

Tak

Tak

Zapewnienie wydajnego transportu danych w WAN i LAN

Usprawnienia przetwarzania

Tak

Tak

Szybki dostęp do zdalnych plików

Buforowanie lokalnego dysku

Tak

Tak

Zwiększa objętość bufora oraz wydajność

Asynchroniczność

Nie

Tak

Zwiększa przepustowość zapisywania klienta

Zredukowane żądania atrybutów

Nie

Tak

Zwiększa skalowalność oraz ogólną wydajność

Obsługa 64 -bito w ych rozmiarów oraz przesunięć

Nie

Tak

Może pobierać wielo-gigabajtowe pliki znajdujące się na serwerach NFS

Obsługa repliki serwera tylko do odczytu (read-only replica server support)

Tak

Tak

Jeżeli serwer się zepsuje, replika może go zastąpić

W ysoka dostępność serwera NFS (opcjonalnie)

Tak

Tak

Um iejętność obsługi aw arii systemowych lub sieciowych

Zredukowane żądania przeszukiwania

Nie

Tak

Zwiększa skalowalność oraz wydajność

katalogów

Tabela 18.2 przedstawia listę producentów oraz platform OS.

380

TCP/IP. SZKOŁA PROGRAMOWANIA

Tabela 18.2. P ro d u k ty NFS ró żn ych p ro d u c e n tó w . Producent

Platforma OS

Amdahl

UTS

Apple

A/UX

Beame and W hiteside

DOS, W indows

BSD!

Unix

Cray

UNICOS

DEC

U ltrix, VMS

Dell

SVR4

FTP Software

DOS, W indows, OS/2

Frontier Technology

DOS, W indows

Hewlett-Packard

HP-UX

IBM

AIX, MVS

Intel

Unix

ICL

Unix

Net Manage

DOS, W indows

Nixdorf

TOS 3 5

Novell

Netware

OSF

OSF1

Santa Cruz Operation

SCO Unix

Sunsoft

Solaris, DOS, W indows

Silicon Graphics

IRIX

Process Software

VMS

Sony

NeWs

Texas Instrum ents

TI SVR3.2

TGV

VMS

Działanie NFS Centralny punkt modelu stanowią rozsiane geograficznie serwery (serwery NFS), które zapewniają klientom dostęp do udostępnianych informacji (patrz rysunek 18.2). Serwery NFS zapewniają dostęp do systemu plików za pośrednictwem procesu na­ zywanego eksportow aniem . Udostępniane katalogi znane są pod nazwą: eksporto­ wany system plików . Korzystając z polecenia export, administratorzy serwera muszą określić części znajdującego się na serwerze systemu plików, które mają być ekspor­ towane do klientów.

Rozdział 18. • PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP)

Ry s u n e k 1 8 .2 .

Korzystając z polecenia mount informujemy jądro systemu Unix o konieczności podłączenia nowego systemu plików do pliku w określonym punkcie montowania

Klient

Zam ontuj zdalny system plików. Będzie spraw iał

Jgwgggjj^g

w rażenie lokalnego.

S erw er

38 1

/

N ie w id o czne o pe ra cje sie cio w e w fo rm ie p ro ce d u r serw era

Po określeniu przez administratora obszarów eksportowych, klienci NFS mogą użyć polecenia mount, aby uzyskać dostęp do wyeksportowanych obszarów serwe­ ra, poprzez połączenie zdalnej struktury plików z lokalnym obszarem klienta, na­ zywanym punktem montowania (mount point). Procedura ta umożliwia użytkow­ nikowi dostęp do zdalnego systemu plików w sposób identyczny jak do plików lokalnych. Rysunek 18.2 przedstawia przykład podstawowych komponentów wy­ maganych do udostępniania i uzyskania dostępu do plików klienta i serwera.

Klient NFS Oprogramowania wymagane do uczestniczenia w udostępnianiu plików zależy od używanego systemu operacyjnego oraz architektury systemu. Każdy klient potrze­ buje odpowiedniego programu NFS do utworzenia żądań montowania i odmontowywania (przyłączania i rozłączania). Montowanie umożliwia dołączenie udostęp­ nianego obszaru eksportowego do lokalnego systemu plików klienta, nazywanego drzewem klienta (client tree). Odmontowywanie jako przeciwieństwo montowania, umożliwia klientowi zwolnienie poprzednio przyłączonego systemu plików, po­ przez zwolnienie skojarzonych zasobów oraz odłączenie obszaru eksportowego od punktu montowania lokalnego drzewa. Punkt montowania jest punktem w strukturze drzewiastej lokalnego klienta. Punkt ten określa miejsce przyłączenia montowanego systemu plików. Zaawansowane narzędzie montowania — automounte, umożliwia automatyczne przyłączanie i rozłą­ czanie eksportowanych systemów plików w oparciu o konfigurację mapowania. Auto­ matyczne montowanie działa podobnie do ręcznego wydania polecenia mount, któ­ re łączy zdalny obszar eksportowy z punktem w lokalnym systemie plików klienta (punktem montowania). Jednakże proces zachodzi dynamicznie na podstawie uprzednio zdefiniowanych mapowań.

382

TCP/IP. SZKOŁA PROGRAMOWANIA

Koncepcja przyłączania zdalnego systemu plików tak, ze działa on jak część syste­ mu lokalnego, nie jest nowa i nie powinna być nam obca jeżeli pracowaliśmy wcze­ śniej z innymi systemami operacyjnymi, np. NetWare lub którymś z systemów Microsoft Windows. W wymienionych systemach przyłączanie określa się termi­ nem m apow anie. Aby uzyskać dostęp do zasobów zlokalizowanych na zdalnym hoście, wykorzystujemy nieużywaną literę dysku lokalnego, np. E:, F:, itp. i mapuje­ my ją na dany katalog wewnątrz zdalnego systemu plików hosta. Po wykonaniu tej czynności, dostęp do zdalnego obszaru uzyskujemy poprzez wpisanie litery użytej do mapowania zdalnego zasobu. Litera dysku reprezentuje lokalny punkt montowania i jest później wykorzystywana w celu uzyskania dostępu do zdalnego obszaru. Mapowanie jest formą skrótu. Jeżeli chcąc uzyskać dostęp do zdalnych zasobów, musielibyśmy za każdym razem tworzyć nową ścieżkę dostępu do serwera i pod­ katalogu, pochłaniałoby to bardzo dużo czasu i spowalniało uzyskiwanie dostępu do tych zasobów. Poprzez mapowanie, wytyczamy bezpośrednią ścieżkę do zaso­ bów i odwołujemy się do niej za każdym razem Idedy chcemy z nich skorzystać. Lokalnemu punktowi mapowania możemy przyporządkować zrozumiałą dla użyt­ kownika nazwę, np.: /home/madzia. Możemy również wykorzystać literę przypo­ rządkowaną do lokalnego dysku (E:, F:, itd.). Obszar eksportowy serwera (eksportowa­ ny system plików), któiy ma zostać przyłączony, może znajdować się w dowolnym miejscu w strukturze plików serwera oraz zawierać wiele poziomów katalogów i plików np.: NFSServ:/export/homedir/madzia. Po utworzeniu lokalnego punktu montowania, klient łączy z nim strukturę zdalnego systemu plików. Wspólnie punkty montowania tworzą przestrzeń nazw. Od tego momentu użytkownik może uzyskać dostęp do każdej informacji przechowywanej wewnątrz eksportowanego systemu plików, poprzez odwołanie się do nazwy klienta /home/madzia lub litery dysku reprezentującej dany obszar zdalny, np.: f:. Rysunek 18.3 przedstawia przykład mapowań automountera i przestrzeni nazw NFS. R y s u n e k 1 8 .3 .

Klienci NFS uzyskują dostęp do plików znajdujących się na serwerach NFS poprzez przyłączenie eksportowanego systemu plików serwera. Klienci NFS potrzebują mapowań do systemu plików serwera

Rozdział 18. ° PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP)

383

Jeżeli nie potrzebujemy już dostępu do zasobu, możemy po prostu odmapować (lub odmontować) eksportowany system plików. Aby zaoszczędzić czas możemy utworzyć lokalne pliki konfiguracji mapowania, z których w razie potrzeby korzy­ stał będzie automounter w celu dynamicznego przyłączania i odłączania eksporto­ wanych systemów plików, umożliwiając przyłączanie zasobów tylko wtedy, gdy są one potrzebne.

Serwer NFS Serwery NFS zawierają systemy plików, które mogą być udostępniane w postaci obszarów eksportowych (eksportowanych systemów plików) za pomocą polecenia eksportu wydanego przez program udostępniający. Serwery NFS odpowiadają na żądania udostępnienia informacji wysyłane przez klientów NFS. Administrator musi utworzyć plik konfiguracyjny eksportu i określić w nim: > Jakie pliki mają być udostępniane t> Kto może uzyskać dostęp do udostępnianego obszaru > Wszelkie ograniczenia w dostępie do udostępnianego obszaru i zawartych w nim informacji > Pełną ścieżkę dostępu do eksportowanych katalogów > Listę klientów NFS mogących korzystać z obszaru eksportowego > Listę określonych ograniczeń dostępu do informacji znajdujących się w tym ob­ szarze W czasie inicjalizowania serwera NFS, jego program udostępniający korzysta z in­ formacji znajdujących się w pliku konfiguracji eksportu w umożliwienia eksportu oraz określenia systemów plików przeznaczonych do eksportu. Dwie procedury sys­ temu operacyjnego, mount-d i nfs-d ( d oznacza demona) obsługują zgłaszane przez klientów żądania dostępu do systemu plików serwera.

Składniki i działanie antom ountera Jak już wspominaliśmy wcześniej, automounter jest zaawansowanym narzędziem montującym. Umożliwia ono automatyczne przyłączanie i rozłączanie eksportowa­ nych systemów plików w oparciu o informacje mapowania. Proces automount ko­ rzysta z trzech składników: E> Polecenia automount > Automount-d (demona) > Autofs (wirtualnego systemu plików używanego przez automount)

384

TCP/IP. SZKOŁA PROGRAMOWANIA

Auto-polecenie Po uruchomieniu systemu inicjalizuje się auto-polecenie. Następnie, otwiera ono plik auto_master (plik konfiguracji mapowania), który przechowuje lokalne nazwy ścieżek (punkty montowania) do mapowań eksportowanego systemu plików. In­ formacje te są wykorzystywane do zbudowania na hoście lokalnej tablicy montowań. Po utworzeniu tablicy montowań, użytkownik może uzyskać dostęp do systemu plików za pomocą polecenia cd. Kiedy użytkownik próbuje uzyskać dostęp do lo­ kalnego punktu montowania, autofs (automatyczny system plików), który repre­ zentuje miejsce przechowywania (wirtualny system plików) pożądanego przez klienta systemu plików, wywołuje demona automount w celu pozyskania i przyłą­ czenia poszukiwanego systemu plików. Działający po stronie klienta demon automound-d ustanawia ścieżkę komunika­ cyjną z demonen nfs-d serwera aby wyeksportować zdalny system plików. Po przyłączeniu zdalnego systemu plików przez klienta kończą się obowiązki procesu automount i jego komponentów i nie ma dalszej potrzeby utrzymywania stałego dostępu do plików.

XDR Jeden z komponentów NFS — XDR odpowiada za umożliwianie NFS współpracy z różnymi platfonnami systemów operacyjnych. XDR został opracowany przez firmę Sun Microsystem, następnie został wprowadzony do Internetu, co zostało opisane w RFC 1014. Podstawowym zadaniem XDR jest zapewnienie niezależności od platformy. Klient NFS oraz programy serwera mogą pracować na zupełnie różnych systemach operacyjnych i sprzęcie, poczynając od hostów Macintosh do Unixa, mimo tego udostępniając sobie pliki w sposób niewidoczny. Umożliwia to XDR, który ukrywa szczegóły działania systemów obu stron i tłumaczy informacje specyficzne dla danego urządzenia przed ich wysłaniem lub po odebraniu. XDR zapewnia standardowy zestaw procedur bibliotecznych napisanych w języku programowania C. Umożliwia to producentom implementowanie XDR we wła­ snych środowiskach przedstawiających dane w sposób niezależny od urządzenia. Rysunek 18.4 przedstawia sposób w jaki XDR zapewnia funkcjonalność niezależną od urządzenia. W trybie odbiorczym, XDR otrzymuje wiadomość NFS od RPC i dokonuje inter­ pretacji oraz tłumaczenia zawartych w niej informacji na format zrozumiały dla systemu operacyjnego danego hosta. Przypomnijmy sobie kwestie dotyczące pro­ tokołów warstwy prezentacji omawiane w rozdziałach 1 i 10: zadaniem warstwy

Rozdział 18. • PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP)

Rys u n e k 1 8 .4 .

XDR tłumaczy I przedstawia dane w sposób umożliwiający komunikowanie się dwóch różnych systemów

-c p -

d an e p rze n o śn e ■

M

385

-cp -

11

T łu m a cze n ie na sta n d a rd X D R

T łu m a c z e n ie dla sy s te m u o p e ra cyjn e g o

t

I

K o le jn o ść bitów, ko do w a nie liczb ca łko w itych i zm ie n n o p rze cin ko w ych , ko d o w a n ie znaków , itp., s ą d e fin io w a n e p rzez syste m o p e ra cyjn y d a n e g o u rządzenia.

K o le jn o ś ć bitów, k o d o w a n ie liczb ca łko w itych i zm ie n n o p rz e c in k o w y c h , ko d o w a n ie znaków , itp., s ą d e fin io w a n e p rz e z syste m o p e ra c y jn y d a n e g o u rządzenia.

prezentacji jest przedstawienie danych w formacie odpowiadającym systemowi operacyjnemu hosta oraz specyficznym wymaganiom danego urządzenia, wyko­ nanie tłumaczenia, kodowanie, odkodowywanie, konwersja z ASCII na EBCDIC i odwrotnie, itp. Funkcje warstwy prezentacji są zazwyczaj obecne w oprogramowaniu większości protokołów górnej warstwy i nie są definiowane odrębnie, tak jak ma to miejsce w przypadku XDR. Firma Sun Microsystems zdefiniowała w swoim zestawie od­ dzielny protokół, aby umożliwić producentom bardziej wydajne i precyzyjne do­ stosowywanie funkcjonalności ich implementacji XDR. XDR ułatwia komunikację pomiędzy różnymi hostami, stwarzając programistom możliwość precyzyjnego do­ pasowania protokołów do wymogów ich systemów operacyjnych, ułatwiając w ten sposób przenośność do innych systemów operacyjnych. Mimo, że XDR jest okre­ ślany jako odrębny protokół, stanowi on integralną część funkcjonalności protoko­ łów górnej warstwy i z tego powodu nie możemy go zobaczyć za pomocą progra­ mu Sniffer.

RFC Firma Sun Microsystem opracowała również RPC (zdalne wywołanie procedur); Internet przyjął to rozwiązanie w RFC 1057. RPC oferuje protokół oraz niezależny interfejs, które umożliwiają ustanowienie dwukierunkowego łącza komunikacyjnego pomiędzy zdalnymi procesami komunikacyjnymi. RPC rezyduje w warstwie sesji i z tego powodu jest odpowiedzialny za ustanowienie sesji pomiędzy dwoma proce­ sami hosta oraz jej utrzymywanie i prowadzenie. Jeżeli host nie przestaje potrzebować danej sesji logicznej, RPC przerywa ją i uwalnia zasoby lokalne.

386

TCP/IP. SZKOŁA PROGRAMOWANIA

Nazwa protokół zdalnego wywołania procedur dobrze opisuje jego funkcje. Wy­ obraźmy sobie proces lokalny działający wewnątrz hosta i to, jak tworzone są w nim zapytania o informacje; jest to lokalne wywołanie procedury (Local Procedu­ rę Cali — LPC). A teraz przyjmijmy, że host lokalny żąda wykonania procedury przez hosta zdalnego i oczekuje, iż host ją wykona i wyśle odpowiedź; jest to wła­ śnie funkcja RPC. Rysunek 18.5 przedstawia relacje pomiędzy RPC i LPC. Rys u n ek 18.5. Hosty wywołują procedurę, która sprawia wrażenie procedury lokalnej, mimo że jest wykonywana przez urządzenie zdalne

Lokalne wywołanie procedury

i

Komputer A

Program główny

ProoeduraAO

Procedura A ( )

\

Wywołanie RPC

(oczekująca) \

1

s1

Komputer B

Program główny

s Procedura B ( )

Zdalne wywołanie procedury

Procedura B ( )

i

^

Procedura B (oczekująca)

«

*

Wywołanie RPC Wywołanie RPC

>

Wywołanie 1

Procedura A ( )

Procedura B ( )

I

RPC

Hosty korzystają z RPC aby wysyłać zdalne wywołania procedur, takie jak zapisz, czytaj, drukuj, itp., do hostów docelowych, które przetwarzają żądanie i odpowia­ dają pozytywnie lub negatywnie przez RPC. RPC nie wie jaki system operacyjny znajduje się na hoście lokalnym, a jaki na zdalnym, i pozostawia interpretację znaj­ dujących się w żądaniach lub odpowiedziach związanych z urządzeniami informa­ cji protokołom warstw wyższych, takim jak XDR. Można myśleć o RPC jako o mediatorze przenoszącym określone zapytania z pro­ tokołu górnej warstwy, sprawdzającym czy zostało ono wysłane i dostarczone. RPC zazwyczaj pracuje na UDP aby zapewnić szybką dostawę; jednakże z powodu swojej ogólnej natury może również pracować na TCP, aby zapewnić dodatkową niezawodność. Operacje RPC działają na tak typowych zasadach, że został on przenie­ siony do innych systemów operacyjnych oraz środowisk protokołowych, np. do systemów Microsoft NT.

Wiadomość wywołująca W każdym wywołaniu zdalnej procedury uczestniczy aktywna stronę klienta wy­ syłającą wiadomość wywołującą do serwera, który zwraca odpowiedź. Sieć składa się z jednego, bądź większej ilości programów zdalnych. Opiszemy teraz nagłówek RPC oraz pola znajdujące się w wiadomości wywołującej (zapytaniu). Wiadomość wywołująca RPC składa się z następujących pól:

Rozdział 18. • PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP)

387

ID transakcji Nadawca przypisuje numer ID. RPC wykorzystuje to pole do przyporządkowania odpowiedzi do zapytań.

Typ Pole typu określa rodzaj wiadomości RPC, czyli wywołanie lub odpowiedź: 0 = wywołanie > 1 = odpowiedź

W ersja Pole wersji identyfikuje używaną wersję protokołu. Numer wersji powinien wynosić zawsze 2.

Program Pole programu określa program górnej warstwy, który korzysta z RPC, np. NFS. Tabela 18.3 zawiera listę programów, które mogą być uruchamiane na RPC i mają zarejestrowane wartości RPC. Tabela 18.3. Zarejestrowane programy RPC Numer RPC

Program

Opis

100000

PMAPPR0G

M apowanie portów

100001

RSTATPROG

Zdalne statystyki

100002

RUSERSPROG

Zdalny użytkownik

100003

NFSPR0G NFS

NFS

100004

YPPROG

"Yellow Pages" (Książka telefoniczna)

100005

MOUNTPROG

Demon m ontowania (m ount daemon)

100006

DBXPR0G

Zdalny DBX

100007

YBINDPROG

binder YP

100008

WALLPROG

W iadom ość wyłączająca system

100009

YPPASSWDPROG YP

hasło serwera haseł YP

100010

ETHERSTATPROG

Statystyki Ethernetu

100011

QQU0TAPR0G

Przydziały dyskowe

100012

SPRAYPROG

Pakiety rozproszone

100013

IB M 32 70P R 0G

Program mapujący 3 2 7 0

10014

IBMRJEPR0G

Program mapujący RJE

388

TCP/IP. SZKOŁA PROGRAMOWANIA

T a b e la 1 8 .3 . Z a re je s tro w a n e p ro g ra m y RPC (c ią g d a lszy) Num er RPC

Program

Opis

100015

SELNSVCPROG

Usługa wyboru

100016

RDATABASEPROG

Dostęp do zdalnej bazy danych

100017

REXECPROG

Zdalne wykonanie

100018

ALICEPROG

Oprogramowanie autom atyzacji biura Alice

100019

SCHEDPROG

Usługi harmonogramowe

100020

LOCKPROG

Menadżer blokady lokalnej

100021

NETLOCKPROG

Menadżer blokady sieciowej

100022

X.25PROG

Protokół X .25 INR

100023

STATMON1PROG

M onitor stanu 1

100024

STATMON2PROG

M onitor stanu 2

100025

SELNLIBROG

Biblioteka wyboru

100026

BOOTPARAMPROG

Usługa param etrów urucham iania

100027

MAZEPROG

Gra Mazeware

100028

YPUPDATEPROG

Aktualizacja UP

100029

KEYSERVEPROG

Serwer kluczy

100030

SECURECMDPROG

Bezpieczne logowanie

100031

NETFWDIPROG

program in it przekaźnika NFS

100032

NETFWDTPROG

program trans przekaźnika NFS

100033

SUNLINKMAP_PROG

M apowanie Sunlink

100034

NETMONPROG

M onitor sieciowy

100035

DBASEPROG

Niewielka baza danych

100036

PWDAUTHPROG

Uw ierzytelnianie haseł

100037

TFSPROG

Transparentne usługi plikowe

100038

NSEPROG

Serwer NSE

100039

NSE_ACTIVATE_ PROG

Demon aktyw acji NSE

150001

PCNFSDPROG

Uw ierzytelnianie hasła PC

200000

PYRAMI DLOCKINGPROG

Blokada piram idowa

200001

PYRAMIDSYS5

Piramida-sys5

200002

CAD DSJM AG E

CV cadds-image

300001

ADT_RFLOCKPROG

Blokada plików ADT

Rozdział 18. • PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP)

389

Procedura Pole określa numer procedury określonej aplikacji. Wartość ta różni się w zależno­ ści od żądanej procedury oraz żądającej o nią aplikacji. W celu ustalenia numeru procedury należy przejrzeć dokumentację dostarczaną przez danego producenta. Tabela 18.4 zawiera listę procedur serwera NFS. T a b e la 1 8 . 4 . P ro c e d u ry se rw e ra NFS

Numer procedury

Nazwa procedury

Funkcja procedury

0

Brak działania

Um ożliw ia sprawdzanie i mierzenie czasu odpowiedzi serwera.

1

Pobierz atrybuty pliku

U m ożliwia klientow i określanie atrybutów pliku serwera.

2

Ustaw atrybuty pliku

Um ożliwia klientow i ustawianie (niektórych) atrybutów pliku serwera.

3

Pobierz korzeń systemu plików

Nieaktualna

4

Szukaj nazwy pliku

Um ożliwia klientow i poszukiwanie pliku w katalogu.

5

Odczytaj z łącza symbolicznego

Um ożliwia klientow i odczytywanie danych ze wskazanego pliku poprzez łącze symboliczne

6

Odczytaj z pliku

Um ożliw ia klientow i odczytywanie danych z pliku

7

Zapisz w buforze

W ykorzystywana wyłącznie z wersją 3 NFS.

8

Zapisz w pliku

U m ożliwia klientow i zapisywanie danych w pliku serwera.

9

Utwórz plik

U m ożliwia klientow i utworzenie nowego pliku na serwerze.

10

Usuń plik

Um ożliw ia klientow i usunięcie pliku z serwera.

11

Zmień nazwę pliku

Um ożliw ia klientowi zmianę nazwy pliku znajdującego się na serwerze.

12

Utwórz łącze do pliku

Um ożliw ia klientow i utworzenie pliku, który odsyła do innego pliku.

13

Utwórz łącze symboliczne

Um ożliwia klientow i utworzenie pliku, który jest łączem sym bolicznym .

14

Utwórz katalog

Um ożliwia klientow i utworzenie katalogu na serwerze.

15

Usuń katalog

Um ożliw ia klientow i usunięcie katalogu z serwera.

16

Czytaj z katalogu

Um ożliwia klientow i odczytywanie niektórych w pisów w katalogu serwera.

17

Zdobądź atrybuty systemu plików

Um ożliw ia klientow i sprawdzanie atrybutów serwera.

390

TCP/IP. SZKOŁA PROGRAMOWANIA

Tabela 18.5 zawiera listę procedur polecenia mount serwera. T abela 1 8 .5 . Procedury polecenia mount serwera Numer procedury

Nazwa procedury

0

Brak działania

Funkcja procedury Um ożliw ia sprawdzanie i taktow anie odpowiedzi serwera.

1

Dodaj w pis m ontowania

Dodaje nowy system plików do listy zdalnych systemów plików , do których dostęp posiada klient.

2

Zwróć w pisy m ontowania

Um ożliw ia klientowi sprawdzanie własnej listy przyłączonych systemów plików .

3

Usuń w pis montowania

Usuwa system plików z listy zdalnych systemów plików , do których dostęp posiada klient.

4

Usuń wszystkie wpisy montowania

Usuwa wszystkie systemy plików z listy zdalnych systemów plików , do których dostęp posiada klient.

5

Zwróć listę eksportową

Um ożliw ia klientowi sprawdzanie listy zdalnych systemów plików oferowanych przez dany serwer.

Rodzaj uwierzytelniania Rodzaj uwierzytelniania jest określa wskaźnik identyfikacji. Wartość ta określa czy było żądane uwierzytelnianie, a jeżeli tak to jakiego rodzaju: 0 0 = Brak O 1 = Unix (uwierzytelnianie Unix) 0 2 = Skrócone (uwierzytelnianie specyficzna dla producenta) ► 3 = DES (standard szyfrowania danych — data encryption standard)

Rozm iar uwierzytelniania w bajtach Pole rozmiaru uwierzytelniania określa liczbę kolejnych bajtów identyfikujących.

Dane uwierzytelniania Pole danych uwierzytelniania ma zmienną długość i zawiera informacje związane z uwierzytelnianiem.

W eryfikacja uw ierzytelniania Pole weryfikacji uwierzytelniania określa metodę uwierzytelniania, z której powi­ nien skorzystać odbiorca w celu zweryfikowania danego wywołania lub odpowie­ dzi. Komunikujące się hosty muszą obsługiwać te same rodzaje uwierzytelniania:

Rozdział 18. • PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP)

39 1

> 0 = Brak > 1 = Unix (uwierzytelnianie Unix) > 2 = Skrócone (uwierzytelnianie specyficzna dla producenta) > 3 = DES (standard szyfrowania danych — data encryption standard)

Odpowiedź Jak już wspomniano wcześniej, w każdym wywołaniu procedury uczestniczy ak­ tywny klient, który wysyła wywołanie do serwera, któiy z kolei zwraca odpowiedź. Żądanie wywołania może zostać albo przyjęte, albo odrzucone. Omówimy teraz pola nagłówka odpowiedzi RPC. Tylko dwa pola różnią nagłówek odpowiedzi od wywołania: !> stan > stan akceptacji

Stan Pole stanu wskazuje, czy serwer zaakceptował czy też odrzucił uprzednio otrzyma­ ne żądanie wywołania. W polu tym mogą pojawić się dwie wartości: > 0 = Zaakceptowano > 1 = Odrzucono

Stan akceptacji Pole to dokładniej opisuje znaczenie zwrócone przez pole stanu. Może przyjąć na­ stępujące wartości: > 0 = Brak > 1 = Niedostępny program > 2 = Niewłaściwa wersja programu > 3 = Niedostępna procedura > 4 = Argumenty niepotrzebne do procedury

Przykłady działania NFS Istnieje wiele rodzajów procedur NFS; dlatego każdy nagłówek różni się w zależności od wywołania lub odpowiedzi. Rysunek 18.6 przedstawia procedurę odczytu pliku (rodzaj 6). Należy zwrócić uwagę, że rodzaj procedury dla żądania odczytu pliku, to 6. Uchwyt pliku, jakim jest długa liczba numeryczna następująca po tym polu, określa dany plik zdalnego hosta.

392

TCP/IP. SZKOŁA PROGRAMOWANIA

Ry s u n e k 1 8 .6 .

Należy zwrócić uwagę, iż NFS korzysta z paradygmatu (wzorca) serwer/klient, w którym klient lokalny uruchamiający aplikację może mieć dostęp do plików serwera zarządzającego plikiem lub aplikacją programową

£5

iitirnr;rYi=IirTTw^T}ri»W;EŁ^

Meritor Capture Di:p!ay Took Window Help

p RPC: r-1 RPC: r-1 RPC: Q RPC: ¿-3 RPC: pRFC: ¿_3 RPC: pRFC 0RPC P RPC: pRFC. p RPC p RPC 0 RPC0 RPC: P RPC: pRPC: P RPC: P RPC: H “ift HFS: • p H F S. P HFS0 HFS: 0HFS: ©HFS: 0 HFS: P HFS:

Progran = 100003 (HFS). version » 2 Procedure = 6 (Read fron file) Credentials: authorization flavor “ 1 (Unix) len = 60. stanp - 534632013 nachine = "Mafalda“ uid = 102. gid = 15 8 other group id(s): gid 15 gid 0 gid 7 gid 9 gid 10 gid 28 gid 30 gid 36 Verifier: authorization flavor = 0 (Hull) [Verifier: 0 byte(s) of authorization data] [44 bytes of data present] SUH HFS------

File handle = O4O9000O421O000O1B0GO0DD0000000O 00000000000000000000000000000000 Offset = 4096 Count - 4096 [Hornal end of "SOH HFS“ .]

Decodo AMalrix A Hast Talie Ą Protocol Did. X sia lia ic s Foi Hdp. pres: FI IjQ Stall [I j Q

_ |g| x

g j fe j

; j gjjMaxTima

j Q j'

| z^Cofage

ii.

f e j

f

| jffM broxiH..| | g S n iH e i. - .__________________________________ 1D34AM

Zauważmy, iż na rysunku 18.6 wartość offsetowa 4096 bajtów odnosi się do punktu początkowego żądanego pliku, w którym żądanie odczytu powinno się rozpoczynać. Oznacza to, że zapytanie powinno rozpocząć odczyt od 4096 baj tu pliku; liczba 4096 oznacza 4096 odczytanych bajtów. Rysunek 18.7 przedstawia odpowiedź NFS na poprzednie żądanie, w ramach pro­ cedury rodzaju 6 (odczytaj plik). Należy zwrócić uwagę, iż serwer NFS weryfikuje informacje ID klienta oraz ID grupy i ich zezwolenia, aby upewnić się czy użyt­ kownik posiada właściwe uprawnienia do wykonania żądanej procedury. Zezwo­ lenia dla grupy i użytkownika zawierają uprawnienia rw (read and write — odczytu i zapisu). È3HSE*

Rys u n ek 1 8 .7 .

Klient korzystający z NFS, niezależnie od lokalizacji klienta lub serwera, może uzyskać dostęp do plików w sposób niewidoczny

-| g | x

s ia l a im Ë la to lim ia la lg l

Mjj

o]

. Transaction id = 3B2600960 Type = 1 (Reply) : Status = 0 (Accepted) ; Verifier: authorization flavor = 2 (Short) : [Verifier: 12 byte(s) of authorization data] Accept status “ 0 (Do nothing) [76 bytes of data present] SOU HFS ----Proc = 6 (Read fron file) Status = 0 (OK) : File type = 1 (Regular file) ; HodB = D1DQ666 Type = Regular file Owner's pernissions = rw— Group's pernissions = rw— Others' pernissions = rwLink count = 1. DID » 102. GID ■= 0 File size = 4096. Block size = 4096. Ho. of blocks ■ File systen id = 2308. File id = 4162 Access tine ■> 10-Dec-86 19:20:30.910000 GHT Modification tine = 10-Dec-86 19:20:39.710000 GUT Inode change tine = 10-Dec-Q6 19:20:39 710000 GMT [0 byte(s) of data] [Hornal end of "SUH HFS".]

M ainx Table

Decodo X A Hod Fa Help, pieiî FI Ç flS Ia 't lj! g

ë

§ 3 (¿3

A Protocol Dbt. A So la lb s i! p M a xT nig

/

| ^C cSa g s

a r [ gyM ao:oH

| S S n ife iP r.. |

jL ^ E E g ^ -

10:34 AH

Rozdział 18. « PROTOKOŁY OTWARTEGO PRZETWARZANIA SIECIOWEGO (ONCP)

393

Rysunek 18.8 to przykład wywołania RPC. Na rysunku widoczny jest port docelo­ wy UDP identyfikujący RPC jako port 2049. Przyjrzyjmy się teraz nagłówkowi RPC: RPC wykorzysta ID transakcji do dopasowania odpowiedzi po jej otrzymaniu. Ro­ dzaj wysłanej wiadomości RPC to wywołanie. Wartość programu zarejestrowana dla NFS wynosi 100003; wersja to 2. Rodzaj uwierzytelniania to Unix. Zwróćmy uwagę, iż nazwa urządzenia (Mafalda) została przekazana wraz z ID użytkownika (UID) oraz ID grupy (GID), aby umożliwić odbiorcy identyfikację i weryfikację za­ pytania przed jego wykonaniem. Rys u n ek 1 8 .8 .

■ Sniłłci Pio • Locol/Diol Up Adoptoi_1 [Tcpip : 19/300 Ethernet liam o]

NFS umożliwia użytkownikom udostępnianie katalogów i plików, niezależnie od Ich systemu operacyjnego

a lH l air? ! B l a l a M a l a l g l

! P"

H0E3

Ceptuic£=plaj>lools W eidowH elp

U

o ||

: Source part = 1026 : Destination part = 2049 (Sun RPC) Length = 152 Ho checksum : [144 byte(s) a£ data] SUH RPC Header ----: Transaction id = 382600960 : Type = 0 (Call) RPC version = 2 Program » 100003 (HFS). version ■ 2 Procedure = 6 (Read from file) : Credentials authorization flavor ■ 1 (Unix) len " 60, stamp = 534632013 : machine ° "liafalda" uid = 102. gid = 15 B other group id(s): gid 15 gid 0 gid 7 gid 9 gid 10 gid 2B gid 30 gid 36 . Verifier: authorization flavor - 0 (Hull) : [Verifier : 0 byte(s) of authorization data]

D ecodeĄM atrixĄH odtobieĄProtocolD fci.Ągallflies/ FoiH elp,pit»FI a i di r aBStaitlUH& fa23 ‘j||Ma£b!e __ |SSn3leiPio-Loc3l/Dia.|jfjColage

tL

Ł20FM

Podsumowanie NFS inicjuje żądanie lub odpowiada na żądanie odczytu, zapisu, kopiowania, zmianę nazwy, itd. NFS przygotowuje odpowiedź lub zapytanie do przesłania, a następnie przekazuje wywołanie procedury lub odpowiedź do protokołu XDR w celu dokonania interpretacji i tłumaczenia. XDR przekazuje informacje do RPC, który odpowiada za ustanowienie i utrzymanie sesji pomiędzy dwoma hostami.

Pytania sprawdzające 1. Wymień trzy protokoły należące do rodziny ONC. 2. Jaka jest podstawowa funkcja NFS? 3. Jaka jest podstawowa funkcja XDR? 4. Jaka jest podstawowa funkcja RPC? 5. Jaka firma opracowała protokoły ONC?

394

TCP/IP. SZKOŁA PROGRAMOWANIA

DOKUMENTY « i i ROZDZIAŁÓW Rozdział 1. Omówienie modeli i standardów branżowych 1095 Common Management Information Services and Protocol Over TCP/IP(CMOT). U.S (Powszechne usługi informacyjne i protokołowe na bazie TCP/IP) Warrier i L. Besaw. Kwiecień 1989) (Format: TXT=157 506 bajtów) 1180 TCP/IP Tutorial (Samouczek TCP/IP) T. J. Socolofsky i C. J. Kale. (Styczeń 1991) (Format: TXT=65 494 bajtów) (Status: informacyjny) 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments (Wykorzystanie OSI IS-IS w routingu TCP/IP oraz w środowisku podwójnym). R. W. Callon. (Grudzień 1990) (Format: TXT=187866, PS=362 052 bajty) (Status: propozycja standardu)

Rozdział 2. Adresowanie IP 1219 On the Assignment of Subnet Numbers (O przydzielaniu numerów podsieci). P. F. Tsuchiya. (Kwiecień 1991) (Format: TXT=30 609 bajtów) (Status: informacyjny)

396

TCP/IP. SZKOŁA PROGRAMOWANIA

R ozdział 3. P ro to k o ły in terne to w e i w arstw a sieciowa 760 Internet Protocol (Protokół internetowy) 777 Internet Control Message Protocol (Protokół komunikatów sterujących Internetu) 781

Specification of the Internet Protocol (IP) Timestamp Option (Definicja opcji znacznika czasu protokołu IP)

791 Internet Protocol (Protokół internetowy) 792 Internet Control Message Protocol (Protokół komunikatów sterujących Internetu) 815 IP Datagram Reassembly Algorithms (Algorytmy ponownego składania datagramózu IP) 1011 Official Internet Protocols (Oficjalne protokoły internetowe) J. K. Reynolds i J. Postel. (Czerwiec 1987) (Format: TXT=129 194 bajty) (Status: informacyjny) (zastępuje RFC0991) (Status: nieznany) 1016 Something a Host Could Do With Source Quench. )The Source Quench Introduced Delay (SquID) (Co host może poradzić na tłumienie nadawcy. Opóźnienie zuprowadzane przez tłumienie nadawcy). W. Prue, J. Postel. (Lipiec 1987) (Format: TXT=47 922 bajty) (Status: nieznany) 1018 Some Comments on SquID (Komentarze na temat SquID). A. M. McKenzie. (Sierpień 1987) (Format: TXT=7 931 bajtów) (Status: nieznany) 1025 TCP and IP Bake Off (Tworzenie TCP i I P ). J. Postel. (Wrzesień 1987) (Format: TXT=21 297 bajtów) (Status: nieznany) 1027 Using ARP to Implement Transparent Subnet Gateways (Wykorzystanie ARP do implementacji przezroczystych bram podsieci). S. Carl-Mitchell i J. S. Quarterman. (Październik 1987) (Format: TXT=82 440 bajtów) (Status: historyczny) 1051 Standard for the Transmission of IP datagrams and ARP Packets Over ARCNET Networks (Standard transmisji datagramów IP i pakietów ARP przez sieci ARCNET). P. A. Prindville. 01.03.1988. (Format: TXT=7 779 bajtów) (zastąpiony przez RFC1201, std0046) (Status: nieznany) 1054 Host Extensions for IP Multicasting (Rozszerzenia liosta dla rozsyłania gnipowego w I P ). S. E. Deering. Maj-01-1988. (Format: TXT=45 465 bajtów) (zastąpił RFC0988) (zastąpiony przez RFC1112) (Status: nieznany) 1055 Nonstandard for Transmission of IP Datagrams Over Series 1 Lines: SLIP (Niestandardoiue transmisje datagramózu IP przez linie szeregozue). J. L. Romkey. 01.06.1988. (Format: TXT=12 911 bajtów) (Status: standard)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

397

1063 Path MTU Discovery Options (Opcje określania ścieżki MTU). J. C. Mogul, C. A. Kent, C. Partridge, i K. McCloghrie. 01.07.1988. (Format: TXT=27 121 bajtów) (zastąpiony przez RFC119) (Status: nieznany) 1071 Computing the Internet Checksum (Wyznaczanie internetowej sumy kontrolnej). R. T. Braden, D. A. Borman, i C. Partridge. 01.09.1988. (Format: TXT=54 941 bajtów) (uaktualniony przez RFC1141) (Status: nieznany) 1077 Critical Issues in High-bandwidth Networking (Krytyczne zagadnienia przy pracy w sieciach szerokopasmowych). B. M. Leiner. 01.11.1988. (Format: TXT=116 464 bajty) (Status: nieznany) 1141 Computation of the Internet Checksum via Incremental Update (Wyznaczanie internetowej sumy kontrolnej za pośrednictwem uaktualnienia przyrostowego). T. Mallory i A. Kullberg. 01.01.1990. (Format: TXT=3 587 bajtów) (uaktualnia RFC1071) (uaktualniony przez RFC1624) (Status: informacyjny) 1188 Propozycja standardu for the Transmission of IP Datagrams Over FDDI Networks (Proponowany standard transmisji datagramów IP przez sieci FDDI). D. Katz. 01.10.1990. (Format: TXT=2 242 bajty) (zastępuje RFC1103) (Status: wersja robocza standardu) 1191 Path MTU DiscOvery (Określanie ścieżki MTU). J. C. Mogul, S. E. Deering. 01.11.1990. (Format: TXT=47 936 bajtów) (zastąpił RFC1063) (Status: wersja robocza standardu) 1208 Glossary of Networking Terms (Leksykon terminów siecioioych). O. J. Jacobsen i D. C. Lynch. 01.03.1991. (Format: T X T = 41156 bajtów) (Status: informacyjny) 1256 ICMP Router Discovery Messages (Komunikaty ICMP podczas odnajdywania routerów). S. Deering. 01.09.1991. (Format: TXT=43 059 bajtów) (także RFC0792) (Status: propozycja standardu) 1413 Identification Protocol (Protokół identyfikacji). M. St. Johns. Styczeń 1993. (Format: TXT=16 291 bajtów) (zastąpił RFC931) (Status: propozycja standardu) 1624 Computation of the Internet Checksum via Incremental Update (Wyznaczanie internetowej sumy kontrolnej za pośrednictiuem uaktualnienia przyrostowego). A. Rijsinghani, red. Maj 1994. (Format: TXT=9 836 bajtów) (uaktualnił RFC1141) (Status: informacyjny) 1788 ICMP Domain Name Messages (Komunikaty ICMP dotyczące nazwy domeny). W. Simpson. Kwiecień 1995. (Format: TXT=11 722 bajty) (Status: eksperymentalny) 2002 IP Mobility Support (Obsługa mobilności IP). C. Perkins. Październik 1996. (Format: TXT=193 103 bajty) (uaktualniony przez RFC2290) (Status: propozycja standardu)

398

TCP/IP. SZKOŁA PROGRAMOWANIA

2005 Applicability Statement for IP Mobility Support (Oświadczenie na temat możliwości zastosowania mobilnego IP). J. Solomon. Październik 1996. (Format: TXT=10 509 bajtów) (Status: propozycja standardu) 2041 Mobile Network Tracing (Śledzenie sieci mobilnych). B. Noble, G. Nguyen, M. Satyanarayanan i R. Katz. Grudzień 1996. (Format: TXT=64 688 bajtów) (Status: informacyjny) 2058 Microsoft Vendor-specific RADIUS Attributes (Atrybuty protokołu RADIUS specyficzne dla implementacji firmy Microsoft). C. Rigney, A. Rubens, W. Simpson, S. Willens. Styczeń 1997. (Format: TXT=118 880 bajtów) (zastąpiony przez RFC2138) (Status: propozycja standardu) 2059 RADIUS Accounting (Konta użytkowników w protokole RADIUS). C. Rigney. Styczeń 1997. (Format: TXT=44 237 bajtów) (zastąpiony przez RFC2139) (Status: informacyjny) 2113 IP Router Alert Option (Opcja alarmu routera IP). D. Katz. Luty 1997. (Format: TXT=7 924 bajty) (Status: propozycja standardu) 2138 Microsoft Vendor-specific RADIUS attributes (Atrybuty protokołu RADIUS specyficzne dla implementachi firmy Microsof). C. Rigney, A. Rubens, W. Simpson, S. Willens. Kwiecień 1997. (Format: TXT=12 407 bajtów) (zastąpił RFC2058) (Status: propozycja standardu) 2139 RADIUS Accounting (Konta użytkowników w protokole RADIUS). C. Rigney. Kwiecień 1997. (Format: TXT=44 919 bajtów) (zastąpił RFC2059) (Status: informacyjny) 2194 Review of Roaming Implementations (Przegląd implementacji roamingu). B. Aboba, J. Lu, J. Ding. W. Wang. Wrzesień 1997. (Format: TXT=81 533 bajty) (Status: informacyjny) 2290 Mobile-IPv4 Configuration Option for PPPIPCP (Opcje konfiguracji mobilnego Ipv4 dla PPP IPCP). J. Solomon i S. Glass. Luty 1998. (Fonnat: TXT=39 421 bajtów) (uaktualnia RFC2002) (Status: propozycja standardu) 2344 Reverse Tunneling for Mobile IP (Odwrotne tunelowanie dla mobilnego IP). G. Montenegro. Maj 1998. (Format: TXT=39 468 bajtów) (Status: propozycja standardu) 2356 Sun's SKIP Firewall Traversal for Mobile IP (Przejście przez ścianę ogniową Sun SKIP dla mobilnego IP). G. Montenegro i V. Gupta. Czerwiec 1998. (Format: TXT=53 198 bajtów) (Status: informacyjny) 2477 Criteria for Evaluating Roaming Protocols (Kryteria oceny protokołóio roamingu). B. Aboba i G. Zorn. Grudzień 1998. (Format: TXT=23 530 bajtów) (Status: informacyjny)

Dodatek A ° DOKUMENTY RFC WG ROZDZIAŁÓW

399

2486 The Network Access Identifier (Identyfikator dostępu do sieci). B. Aboba i M. Beadles. Styczeń 1999. (Format: TXT=14 261 bajtów) (Status: propozycja standardu) 2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations (Mobilne sieci ad hoc: zagadnienia wydajności protokołu routingu i sprawa oceny). S. Corson i J. Macker. Styczeń 1999. (Format: TXT=28 912 bajtów) (Status: informacyjny) 2521 ICMP Security Failures Messages (Komunikaty ICMP dotyczące awarii bezpieczeństwa). P. Karn i W. Simpson. Marzec 1999. (Format: TXT=14 637 bajtów) (Status: eksperymentalny) 2548 Microsoft Vendor-specific RADIUS Attributes (Atrybuty protokołu RADIUS specyficzne dla implementacji firmy Microsoft). G. Zorn. Marzec 1999. (Format: TXT=80 763 bajtów) (Status: informacyjny) 2607 Proxy Chaining and Policy Implementation in Roaming (Tworzenie łańcucha proxy i implementacja reguł w roamingu)

Rozdział 4. Zamiana adresów 826 Ethernet Address Resolution Protocol: On Converting Network Protocol Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware (Protokół rozpoznawania adresu ethernetowego: O przekształcaniu adresów protokołu sieciowego na 40-bitowe adresy ethernetowe w celu transmisji na sprzęcie Ethernet) 903

Reverse Address Resolution Protocol (Odwrotny protokół rozpoznawania adresu)

925 Multi-LAN Address Resolution (Określanie adresu multi-LAN) 1027 Using ARP to Implement Transparent Subnet Gateways (Wykorzystanie ARP do implementacji przezroczystych bram podsieci). S. Carl-Mitchell i J. S. Quarterman. 01.10.1987. (Format: TXT=21 297 bajtów) (Status: nieznany) 1029 More Fault-tolerant Approach to Address Resolution for a Multi-LAN System of Ethernets (Bardziej odporne na błędy podejście do rozpoznawania adresów dla systemów multi-LAN sieci Ethernet). G. Parr. 1.05.1988. (Format: TXT=44 019 bajtów) (Status: nieznany) 1107 Plan for Internet Directory Services (Plan internetowych usług katalogowych). K. R. Sollins. 01.07.1989. (Format: TXT=51 773 bajty) (Status: informacyjny) 1112 Host Extensions for IP multicasting (Rozszerzenia hosta dla rozsyłania gnipowego IP). S. E. Deering. 01.08.1989. (Format: TXT=39 904 bajty) (zastąpił RFC0988, RFC1054) (Uaktualniony przez RFC2236) (Status: standard)

400

TCP/IP. SZKOŁA PROGRAMOWANIA

1293 Inverse Address Resolution Protocol (Odwrócony protokół rozpoznawania adresu). T. Bradley i C. Brown. Styczeń 1992. (Format: TXT=11 368 bajtów) (Zastąpiony przez RFC2390) (Status: propozycja standardu) 1329 Thoughts On Address Resolution for Dual MAC FDDI Networks (Przemyślenia na temat rozpoznawania adresów dla podwójnych sieci MAC FDDI). P. Kuehn. Maj 1992. (Format: TXT=58 150 bajtów) (Status: informacyjny) 1433 Directed ARP (Skierowany protokół ARP). J. Garrett, J. Hagen i J. Wong. Marzec 1993. (Format: TXT=41 028 bajtów) (Status: eksperymentalny) 1868 ARP Extension-UNARP (Rozszerzenie protokołu ARP -— UNARP). G. Malkin. Listopad 1995. (Format: TXT=7 681 bajtów) (Status: eksperymentalny) 1931 Dynamie RARP Extensions for Automatic Network Address Acquisition (Dynamiczne rozszerzenia RARP dla celów automatycznego pozyskiwania adresu sieciowego). D. Brownell. Kwiecień 1996. (Format: TXT=47 005 bajtów) (Status: propozycja standardu) 2390 Inverse Address Resolution Protocol (Odwrócony protokół rozpoznaiuania adresu). T. Bradley i C. Brown, A. Malis. Sierpień 1998. (Format: TXT=20 849 bajtów) (zastąpił RFC1293) (Status: propozycja standardu)

Rozdział 5. Routing IP 917 Toward An Internet Standard Scheme For Subnetting (Poszukiwanie internetowego standardowego schemata tworzenia podsieci) 932 Toward An Internet Standard Scheme For Subnetting (Poszukiwanie internetowego standardowego schemata tworzenia podsieci) 936 Toward An Internet Standard Scheme For Subnetting (Poszukiwanie internetowego standardowego schemata tworzenia podsieci) 940 Toward an Internet Standard Scheme For Subnetting (Poszukiwanie internetowego standardowego schemata tworzenia podsieci) 950 Internet Standard Subnetting Procedure (Internetowa standardowa procedura tworzenia podsieci) 1042 Standard for Transmission of IP datagrams Over IEEE 802 Networks (Standard transmisji datagramów IP w sieciach IEEE 802). J. Postel i J. K. Reynolds. 01.02.1988. (Format: TXT=34 359 bajtów) (zastąpił RFC0948) (Status: standard)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

401

1136 Administrative Domains and Routing Domains: A Model for Routing in the Internet (Domeny administracyjne i domeny routingu: internetowy model routingu). S. Hares i D. Katz. 01.12.1989. (Format: TXT=22 158 bajtów) (Status: informacyjny) 1219 On the Assignment of Subnet Numbers (O przypisywanie numerów podsieci). P. F. Tsuchiaya. 01.04.1991. (Format: TXT=30 609 bajtów) (Status: informacyjny) 1234 Tunneling IPX Traffic Through IP Networks (Tunelowanie ruchu IPX przez sieci IP). D. Provan. 01.01.1991. (Format: TXT=12 333 bajtów) (Status: propozycja standardu) 1335 A Two-tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion (Dwupoziomowa struktura adresów dla Internetu: rozwiązanie problemu wyczerpywania się przestrzeni adresowej). Z. W angi J. Crowcroft. Maj 1992. (Format: TX T =15 418 bajtów) (Status: informacyjny) 1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing (TCP i UDP o większych adresach. Prosta propozycja adresowania i routingu internetowego). R. Callon. Czerwiec 1992. (Format: TXT=26563, PS=42 398 bajtów) (Status: informacyjny) 1365 An IP Address Extension Proposal (Propozycja rozszerzenia adresów IP). K. Siyan. Wrzesień 1992. (Format: TXT=12 790 bajtów) (Status: informacyjny) 1366 Guidelines for Management of IP Address Space (Wskazówki dotyczące zarządzania przestrzenią adresów IP). E. Gerich. Wrzesień 1992. (Format: TXT=17 793 bajty) (Zastąpiony przez RFC1466) (Status: informacyjny) 1375 Suggestion for New Classes of IP Addresses (Sugerowane nowe klasy adresów IP). P. Robinson. Wrzesień 1992. (Format: TXT=16 990 bajtów) (Status: informacyjny) 1385 EIP: The Extended Internet Protocol (EIP: Rozszerzony protokół internetowy). Z. Wang. Listopad 1992. (Format: TXT=39 123 bajty) (Status: informacyjny) 1454 Comparison of Proposals for the Next Version of IP (Porównanie propozycji dotyczących następnej wersji IP). T. Dixon. Maj 1993. (Format: TXT=35 064 bajty) (Status: informacyjny) 1466 Guidelines for Management of IP Address Space (Wytyczne dotyczące zarządzania przestrzenią adresów IP). E. Gerich. Maj 1993. (Fonnat: TXT=22 262 bajty) (zastąpił RFC 1366) (Status: informacyjny)

402

TCP/IP. SZKOŁA PROGRAMOWANIA

1475 TP/EX: The Next Internet (TP/TX: Następny Internet). R. Ullmann. Czerwiec 1993. (Format: TXT=77 854 bajty) (Status: eksperymentalny) 1526 Assignment of System Identifiers for TUBA/CLNP Hosts (Przypisywanie identyfikatorów systemowych hostom TUBA/CLNP). D. Piscitello. Wrzesień 1993. (Format: TXT=16 848 bajtów) (Status: informacyjny) 1550 IP: Next Generation (IPng) White Paper Solicitation (IP: Następna generacja. Dokument techniczny). S. Bradner i A. Mankin. Grudzień 1993. (Format: TX T = 12 472 bajty) (Status: informacyjny) 1597 Address Allocation for Private Internets (Alokacja adresów dla prywatnych internetów). Y. Rekhter, B. Moskowitz, D. Karrenberg, and G. de Groot. Marzec 1994. (Format: TXT=17 430 bajtów) (Zastąpiony przez BCP0005, RFC1918) (Status: informacyjny) 1621 Pip Near-term Architecture (Tymczasowa architektura protokołu Pip). P. Francis. Maj 1994. (Format: TXT=128 905 bajtów) (Status: informacyjny) 1622 Pip Header Processing (Przetwarzanie nagłówka Pip). P. Francis. Maj 1994. (Format: TXT=34 837 bajtów) (Status: informacyjny) 1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified) (Sieciowa 10 uznana za szkodliwą (Niektóre praktyki nie powinny być kodyfikowane)). E. Lear, E. Fair, D. Crocker, i T. Kessler. Lipiec 1994. (Format: TXT=18 823 bajty) (zastąpione przez BCP0005, RFC1918) (Status: informacyjny) 1667 Modeling and Simulation Requirements for IPng (Wymagania dotyczące modelowania i symulacji dla IPng). S. Symington, D. Wood, i M. Pullen. Sierpień 1994. (Format: TXT=17 291 bajtów) (Status: informacyjny) 1668 Unified Routing Requirements for IPng (Wymagania ujednoliconego routingu dla IPng). D. Estrin, T. Li, i Y. Rekhter. Sierpień 1994. (Format: TXT=5 106 bajtów) (Status: informacyjny) 1669 Market Viability as a IPng Criteria (Opłacalność rynkowa jako kryterium dla IPng). J. Curran. Sierpień 1994. (Format: TXT=8 099 bajtów) (Status: informacyjny) 1670 Input to IPng Engineering Considerations (Informacje do rozważenia przy pracach nad IPng). D. Heagerty. Sierpień 1994. (Format: TXT=5 350 bajtów) (Status: informacyjny) 1671 IPng White Paper on Transition and Other Considerations (Dokument techniczny IPng dotycząca przejścia (na nowy system) i innych uwarunkowań). B. Carpenter. Sierpień 1994. (Format: TXT=17 631 bajtów) (Status: informacyjny)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

403

1672 Accounting Requirements for IPng (Wymagania rozliczeń dla IPng). N. Brownlee. Sierpień 1994. (Format: TXT=6 184 bajty) (Status: informacyjny) 1673 Electrical Power Research Institute Comments on IPng (Komentarze instytutu Electrical Power Research na temat IPng). R. Skelton. Sierpień 1994. (Format: TXT=7 476 bajtów) (Status: informacyjny) 1674 A Cellular Industry View of IPng (Poglądy przedstawicieli przemysłu telefonii komórkowej na temat IPng). M. Taylor. Sierpień 1994. (Format: TXT=6 157 bajtów) (Status: informacyjny) 1675 Security Concerns for IPng (Zagadnienia bezpieczeństwa w IPng). S. Bellovin. Sierpień 1994. (Format: TXT=8 290 bajtów) (Status: informacyjny) 1676 INFN Requirements for IPng (Wymagania INFN względem IPng). A Ghiselli, D. Salomoni i C. Vistoli. Sierpień 1994. (Format: TXT=8 493 bajty) (Status: informacyjny) 1677 Tactical Radio Frequency Communication Requirements for IPng (Wymagania dotyczące częstotliwości komunikacji radiowej dla IPng). B. Adamson. Sierpień 1994. (Format: TXT=24 065 bajtów) (Status: informacyjny) 1678 IPng Requirements of Large Corporate Networks (Wymagania IPng w dużych sieciach korporacyjnych). E. Britton i J. Tavs. Sierpień 1994. (Format: TXT=18 650 bajtów) (Status: informacyjny) 1679 HPN Working Group Input to the IPng Requirements Solicitation (Opinie grupy roboczej HPN na temat wymagań dla IPng). D. Green, P. Irey, D. Marlow i K. O'Donoghue. Sierpień 1994. (Format: TXT=17 846 bajtów) (Status: informacyjny) 1680 IPng Support for ATM Services (Wsparcie IPng dla usług ATM). C. Brazdziunas. Sierpień 1994. (Format: TXT=17 846 bajtów) (Status: informacyjny) 1681 On Many Addresses per Host (O wielu adresach jednego hosta). S. Bellovin. Sierpień 1994. (Format: TXT=11 964 bajty) (Status: informacyjny) 1682 IPng BSD Host Implementation Analysis (Analiza implementacji hosta IPng BSD). J. Bound. Sierpień 1994. (Format: TXT=22 295 bajtów) (Status: informacyjny) 1683 Multiprotocol Interoperability In IPng (Wieloprotokołowe współdziałanie w IPng). R. Clark, M. Ammar, i K. Calvert. Sierpień 1994. (Format: TXT=28 201 bajtów) (Status: informacyjny)

404

TCP/IP. SZKOŁA PROGRAMOWANIA

1686 IPng Requirements: A Cable Television Industry Viewpoint (Wymagania IPng: Poglądy przedstawicieli przemysłu związanego z telewizją kablową). M. Vecchi. Sierpień 1994. (Format: TXT=39 052 bajty) (Status: informacyjny) 1687 A Large Corporate User's View of IPng (Poglądy użytkowników korporacyjnych na temat IPng). E. Fleischman. Sierpień 1994. (Format: TXT=34 120 bajtów) (Status: informacyjny) 1688 IPng Mobility Considerations (Zagadnienia mobilności IPng). W. Simpson. Sierpień 1994. (Format: TXT=19 151 bajtów) (Status: informacyjny) 1705 Six Virtual Inches to the Left: The Problem With IPng (Sześć wirtualnych cali na lewo: problemy z IPng). R. Carlson, i D. Ficarella. Październik 1994. (Format: TXT=65 222 bajty) (Status: informacyjny) 1707 CATNIP: Common Architecture for the Internet (CATNIP: wspólna architektura dla Internetu). M. McGOvern i R. Ullmann. Październik 1994. (Format: TXT=37 568 bajtów) (Status: informacyjny) 1710 Simple Internet Protocol Plus White Paper (Dokumentacja techniczna protokołu SIP Plus). R. Hinden. Październik 1994. (Format: TXT=56 910 bajtów) (Status: informacyjny) 1715 The H Ratio for Addresses per Host (Współczynnik H: ilość adresów przypadających na jednego hosta). C. Huitema. Listopad 1994. (Format: TXT=7 392 bajty) (Status: informacyjny) 1719 A Direction for IPng (Wytyczne dla IPng). P. Gross. Grudzień 1994. (Format: TXT=11 118 bajtów) (Status: informacyjny) 1726 Technical Criteria for Choosing IP The Next Generation (IPng) (Techniczne kryteria wyboru IPng). C. Partridge i F. Kastenhoz. Grudzień 1994. (Format: TXT=74 109 bajtów) (Status: informacyjny) 1744 Observations on the Management of the Internet Address Space (Obserwacje na temat zarządzania w internetowej przestrzeni adresowej). G. Huston. Grudzień 1994. (Format: TXT=43 675 bajtów) (Status: propozycja standardu) 1752 The Recommendation for the IP Next Generation Protocol (Rekomendacje dla protokołu IPng). S. Bradner i A. Mankin. Styczeń 1995. (Format: TXT=127 784 bajty) (Status: propozycja standardu) 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture (Wymagania techniczne dla IPng dla routingu i architektury adresów Nimrod). N. Chiappa. Grudzień 1994. (Format: TXT=46 586 bajtów) (Status: informacyjny)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

405

1797 Class A Subnet Experiment. Internet Assigned Numbers Authority (IANA) (Eksperyment z podsiecią klasy A. LANA). Kwiecień 1995. (Format: TXT= 6 779 bajtów) (Status: eksperymentalny) 1809 Using the Flow Label Field in IPv6 (Wykorzystanie pola etykiety przepływu w IPv6). C. Partridge. Czerwiec 1995. (Format: TXT=13 591 bajtów) (Status: informacyjny) 1814 Unique Addresses Are Good (Unikatowe adresy są dobre). E. Gerich. Czerwiec 1995. (Format: TXT=5 936 bajtów) (Status: informacyjny) 1860 Variable Length Subnet Table for IPv4 (Tablica podsieci o zmiennej długości dla IPv4). T. Pummiłl i B. Manning. Październik 1995. (Format: TXT=5 694 bajty) (Zastąpiony przez RFC1878) (Status: informacyjny) 1878 Variable Length Subnet Table for IPv4 (Tablica podsieci o zmiennej długości dla IPv4). T. Pummill i B. Manning. Grudzień 1995. (Format: TXT=19 414 bajtów) (zastąpił RFC1860) (Status: informacyjny) 1879 Class A Subnet Experiment Results and Recommendations (Wyniki eksperymentu i zalecenia dla podsieci klasy A). B. Manning. Styczeń 1996. (Format: TXT=10 589 bajtów) (Status: informacyjny) 1880 IPv6 Address Allocation Management (Zarządzanie przydzielaniem adresów w IPv6). IAB&IESG. Grudzień 1995. (Format: TXT=3 215 bajtów) (Status: informacyjny) 1883 Internet Protocol, Version 6 (IPv6) Specification (Specyfikacja IPv6). S. Deering i R. Hinden. Grudzień 1995. (Format: TXT = 82 089 bajtów) (Status: propozycja standardu) 1884 IP Version 6 Addressing Architecture (Architektura adresowania IPv6). R. Hinden i S. Deering, red.. Grudzień 1995. (Format: TXT=37 860 bajtów) (Zastąpiony przez RFC2373) (Status: propozycja standardu) 1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) (Protokół ICMP dla IPv6). A. Contra i S. Deering. Grudzień 1995. (Format: TXT=32 214 bajtów) (Status: propozycja standardu) 1886 DNS Extensions to support IP version 6 (Rozszerzenia DNS wspierające IPv6). S. Thomson i C. Huitema. Grudzień 1995. (Format: TXT=6 424 bajty) (Status: propozycja standardu) 1887 Air Architecture for IPv6 Unicast Address Allocation (Architektura alokacji adresów transmisji pojedynczej dla IPv6). Y. Rekhter i T. Li, red. Grudzień 1995. (Format: TXT=66 066 bajtów) (Status: informacyjny)

406

TCP/IP. SZKOŁA PROGRAMOWANIA

1888 OSI NSAPs and IPv6 (OSI NSAP i IPv6). J. Bound, B. Carpenter, D. Harrington, J. Houldsworth i A. Lloyd. Sierpień 1996. (Format: TXT=36 469 bajtów) (Status: eksperymentalny) 1897 IPv6 Testing Address Allocation (Testowanie alokacji adresów IPv6). R. Hinden i J. Postel. Styczeń 1997. (Format: TXT=6 643 bajty) (Status: eksperymentalny) 1900 Renumbering Needs Work (Potrzeby związane z przenumerowanie). B. Carpenter i Y. Rekhter. Luty 1996. (Format: TXT=9 528 bajtów) (Status: informacyjny) 1916 Enterprise Renumbering: Experience and Information Solicitations (Przenumerowanie firmowe: Doświadczenie i informacje). H. Berkowitz, P. Ferguson, W. Leland i P. Nesser. Luty 1996. (Format: TXT=16 117 bajtów) (Status: informacyjny) 1918 Address Allocation for Private Internets (Alokacja adresów dla prywatnych internetów). Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot i E. Lear. Luty 1996. (Format: TXT=22 270 bajtów) (zastąpił RFC1627, RFC1597) (także BCP0005) (Status: najlepsze obecne procedury) 1933 Transition Mechanism for IPv6 Hosts and Routers (Mechanizmy przejścia dla hostów i routerów IPv6). R. Gilligan i E. Nordmark. Kwiecień 1996. (Format: TXT=47 005 bajtów) (Status: propozycja standardu) 1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG (Nowy schemat routingu i adresowania w Internecie). R. Hinden. Czerniec 1996. (Format: TXT=10 115 bajtów) (Status: informacyjny) 1970 Neighbor Discovery for IP Version 6(IPv6) (Określanie sąsiadów dla IPv6). T. Narten, E. Nordmark i W. Simpson. Sierpień 1996. (Format: TXT=197 632 bajty) (Status: propozycja standardu) 1971 IPv6 Stateless Address Autoconfiguration (Bezstanowa autokonfiguracja adresów dla IPv6). S. Thomson iT. Narten. Sierpień 1996. (Format: TXT=61 210 bajtów) (zastąpił RFC1971) (Status: wersja robocza standardu) 1972 Transmission of IPv6 Packets Over Ethernet Networks (Transmisja pakietów IPv6 w sieciach Ethernet). M. Crawford. Sierpień 1996. (Format: TXT=6 353 bajty) (Status: propozycja standardu) 1981 Path MTU DiscOvery for IP version 6 (Określanie ścieżki MTU dla IPv6). J. McCann, S. Deering i J. Mogul. Sierpień 1996. (Format: TXT=56 890 bajtów) (Status: propozycja standardu)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

407

2008 Implications of Various Address Allocation Policies for Internet Routing. (Implikacje różnych reguł alokacji adresów dla routingu internetowego) Y. Rekhter i T. Li. Październik 1996. (Format: TXT=34 717 bajtów) (także BCP0007) (Status: najlepsze obecne procedury) 2019 Transmission of IPv6 Packets Over FDDI Networks (Transmisja pakietów Ipv6 przez sieci FDDI). M. Crawford. Październik 1996. (Format: TXT=12 344 bajty) (Status: propozycja standardu) 2023 IP Version 6 Over PPP (IPv6 przez PPP). D. Haskin, E. Allen. Październik 1996. (Format: TXT=20 275 bajtów) (Status: propozycja standardu) 2036 Observations on the Use of Components of the Class A Address Space Within the Internet (Uwagi na temat wykorzystania komponentów przestrzeni adresowej klasy A w Internecie). G. Huston. Październik 1996. (Format: TXT=20 743 bajty) (Status: informacyjny) 2071 Network Renumbering Overview: Why Would I Want It and What Is It Anyway? (Przegląd informacji o przenumerowaniu sieci: dlaczego tego chcemy i na czym to polega?). P. Ferguson i H. Berkowitz. Styczeń 1997. (Format: TXT=33 218 bajtów) (Status: informacyjny) 2072 Router Renumbering Guide (Przewodnik przenumerowania routera). H. Berkowtiz. Styczeń 1997. (Format: TXT=110 591 bajtów) (Status: informacyjny) 2073 An IPv6 Provider-based Unicast Address Format (Format adresów jednostkowych opartych na dostawcy dla IPv6). Y. Rekhter, PI Lothberg, R. Hinden, S. Deering i J. Postel. Styczeń 1997. (Format: TXT=15 549 bajtów) (zastąpiony przez RFC2374) (Status: propozycja standardu) 2080 RIPng for IPv6 (RIPng dla IPv6). G. Malkin, R. Minnear. Styczeń 1997. (Format: TXT=47 534 bajty) (Status: propozycja standardu) 2081 RIPng Protocol Applicability Statement (Oświadczenie o stosowalności protokołu RIPng). G. Malkin. Styczeń 1997. (Format: TXT=6 821 bajtów) (Status: informacyjny) 2101 IPv4 Address Behavior Today (Zachowanie adresów IPv4 na dzień dzisiejszy). B. Carpenter, J. Crowcroft i Y. Rekhter. Luty 1997. (Format: TXT=31 407 bajtów) (Status: informacyjny) 2133 Basic Socket Interface Extensions for IPv6 (Podstawowe rozszerzenia interfejsu gniazda dla IPv6). R. Gilligan, S. Thomson, J. Bound i W. Stevens. Kwiecień 1997. (Format: TXT=69 737 bajtów) (Status: informacyjny) 2147 TCP and UDP Over IPv6 Jumbograms (Duże pakiety TCP i UDP w IPv6). D. Borman. Maj 1997. (Format: TXT=1 883 bajty) (Status: propozycja standardu)

408

TCP/IP. SZKOŁA PROGRAMOWANIA

2185 Routing Aspects of IPv6 Transition (Związane z routingiem aspekty przejścia na IPv6). R. Callon i D. Haskin. Wrzesień 1997. (Format: TXT=31 281 bajtów) (Status: informacyjny) 2292 Advanced Sockets API for IPv6 (Zaawansowany interfejs programistyczny gniazd dla IPv6). W. Stevens i M. Thomas. Luty 1998 (Format: TXT=152 077 bajtów) (Status: informacyjny) 2373 IP Version 6 Addressing Architecture (Architektura adresowania IPv6) R. Hinden, S. Deering. Lipiec 1998. (Format: TXT=52 526 bajtów) (zastąpił RFC1884) (Status: propozycja standardu) 2374 An IPv6 Aggregatable Global Unicast Address Format (Możliwy do agregacji format globalnego adresu jednostkowego). R. Hinden, M. O'Dell i S. Deering. Lipiec 1998. (Format: TXT=25 068 bajtów) (zastąpił RFC2073) (Status: propozycja standardu) 2375 Address Assignments (Przydzielanie adresu). R. Hinden i S. Deering. Lipiec 1998. (Format: TXT=14 356 bajtów) (Status: informacyjny) 2391 Load Sharing Using IP Network Address Translation (LSNAT). (Współdzielenie obciążenia za pomocą translacji adresów sieci IP). P. Srisuresh i D. Gan. Sierpień 1998. (Format: TXT=44 884 bajty) (Status: informacyjny) 2450 Proposed TLA and NLA Assignment Rule. (Proponowane zasady przypisywania TLA i NLA). R. Hinden. Grudzień 1998. (Format:TXT=24 486 bajtów) (Status: informacyjny) 2452 IP Version 6 Management Information Base for the Transmission Control Protocol. (Baza informacji o zarządzaniu IPv6 dla protokołu TCP). M. Daniele. Grudzień 1998. (Format: TXT=19 066 bajtów) (Status: propozycja standardu) 2454 IP Version 6 Management Information Base for the User Datagram Protocol. (Baza informacji o zarządzaniu IPv6 dla protokołu UDP). M. Daniele. Grudzień 1998. (Format: TXT=15 862 bajty) (Status: propozycja standardu) 2460 Internet Protocol, Version 6 (IPv6) Specification. (Specyfikacja protokołu IPv6). S. Deering i R. Hinden. Grudzień 1998. (Format: TXT=85 490 bajtów) (zastąpił RFC1883) (Status: wersja robocza standardu) 2461 Neighbor DiscOvery for IP Version 6(IPv6). (Określanie sąsiadów dla IPv6). T. Narten, E. Nordmark i W. Simpson. Grudzień 1998. (Format: TXT=222 516 bajtów) (zastąpił RFC1970) (Status: wersja robocza standardu) 2462 IPv6 Stateless Address Autoconfiguration. (Bezstanowa autokonfiguracja adresów dla IPv6). S. Thomson i T. Narten. Grudzień 1998.

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

409

(Format: TXT=61 210 bajtów) (zastąpił RFC1971) (Status: wersja robocza standardu) 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. (Protokół ICMP dla IPv6). A. Contra i S. Deering. Grudzień 1998. (Format: TXT=34 190 bajtów) (zastąpił RFC1885) (Status: wersja robocza standardu) 2464 Transmission of IPv6 Packets Over Ethernet Networks. (Transmisja pakietów IPv6 w sieciach Ethernet). M. Crawford. Grudzień 1998. (Format: TXT=12 725 bajtów) (zastąpił RFC1972) (Status: propozycja standardu) 2465 Management Information Base for IP Version 6: Textual Conventions and General Group. (Baza informacji o zarządzaniu IPv6: konwencje tekstowe i grupa ogólna). D. Haskin i S. Onishi. Grudzień 1998. (Format: TXT=77 339 bajtów) (Status: propozycja standardu) 2466 Management Information Base for IP Version 6:ICMPv6 Group. (Baza informacji o zarządzaniu IPv6: grupa ICMPv6). D. Haskin i S. Onishi. Grudzień 1998. Format: TXT=27 547 bajtów) (Status: propozycja standardu) 2467 Transmission of IPv6 Packets Over FDDI Networks. (Transmisja pakietów IPv6 przez sieci FDDI). M. Crawford. Grudzień 1998. (Format: TXT=16 028 bajtów) (zastąpił RFC2019) (Status: propozycja standardu) 2470 Transmission of IPv6 Packets Over Token Ring Networks. (Transmisja pakietów IPv6 w sieciach Token Ring). M. Crawford, T. Narten i S. Thomas. Grudzień 1998. (Format: TXT=21 677 bajtów) (Status: propozycja standardu) 2471 IPv6 Testing Address Allocation. (Testowanie alokacji adresów IPv6). R. Hinden, R. Fink i J. Postel. Grudzień 1998. (Format: TXT=8 031 bajtów) (zastąpił RFC1897) (Status: eksperymentalny) 2472 IP Version 6 Over PPP. (IPv6 przez PPP). D. Haskin, E. Allen. Październik 1996. (Format: TXT=20 275 bajtów) (Status: propozycja standardu) 2473 Generic Packet Tunneling in IPv6 Specification. (Ogólna metoda tunelowania pakietów w specyfikacji IPv6). A. Contra i S. Deering. Grudzień 1998. (Format: TXT=77 956 bajtów) (Status: propozycja standardu) 2491 IPv6 Over Non-broadcast Multiple Access (NBMA) networks. (IPv6 w sieciach NBMA). G. Armitage. P. Schulter, M. Jork i G. Harter. Styczeń 1999. (Format: TXT=100 782 bajty) (Status: propozycja standardu) 2492 IPv6 Over ATM Networks. (IPv6 w sieciach ATM). G. Armitage, P. Schulter, M. Jork Styczeń 1999. (Format: TXT= 21199 bajtów) (Status: propozycja standardu)

410

TCP/IP. SZKOŁA PROGRAMOWANIA

2497 Transmission of IPv6 Packets Over ARCnet Networks. (Transmisja pakietów IPv6 przez sieci ARCnet). I. Souvatzis. Styczeń 1999. (Format: TXT=10 304 bajty) (także RFC1201) (Status: propozycja standardu) 2526 Reserved IPv6 Subnet Anycast Addresses. (Zarezerwowane podsieci adresów IPv6). D. Johnson i S. Deering. Marzec 1996. (Format: TXT=14 555 bajtów) (Status: propozycja standardu) 2529 Transmission of IPv6 Over IPv4 Domains Without Explicit Tunnels. (Transmisja IPv6 przez domeny IPv4 bez jawnych tuneli). B. Carpenter i C. Jung. Marzec 1999. (Format: TXT=21 049 bajtów) (Status: propozycja standardu) 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Interdomain Routing. (Wykorzystanie wieloprotokołowych rozszerzeń BGP-4 dla międzydomenowego routingu IPv6). P. Marques i F. Dupont. Marzec 1999. (Format: TXT=10 209 bajtów) (Status: propozycja standardu) 2546 6Bone Routing Practice. (Praktyka routingu 6Bone ). A. Durand i B. Buclin. Marzec 1999. (Format: TXT=17 844 bajty) (Status: propozycja standardu) 2553 Basic Socket Interface Extensions for IPv6. (Podstawowe rozszerzenia interfejsu gniazd dla IPv6). R. Gilligan, S. Thomson, J. Bound i S. Stevens. Marzec 1999. (Format: TXT=89 215 bajtów) (Status: informacyjny) 2590 Transmission of IPv6 Packets Over Frame Relay (Transmisja pakietów IPv6 przez sieci Frame Relay) 2675 IPv6 Jumbograms (Wielkie pakiety IPv6) 2710 Multicast Listener DiscOvery (MLD) for IPv6 (MLD dla IPv6) 2711 IPv6 Router Alert Option (Opcje ostrzegania routerów IPv6)

Rozdział 6. Protokoły routingu 823 DARPA Internet Gateway (Brama internetowa DARPA) 827 Exterior Gateway Protocol Formal Specification (Formalna specyfikacja protokołu EGP) 875 Gateways, Architectures, and Heffalumps (Bramy, architektury i hefalumpy) 888 Exterior Gateway Protocol Formal Specification (Formalna specyfikacja protokołu EGP) 890 Exterior Gateway Protocol Formal Specification (Formalna specyfikacja protokołu EGP)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

411

904 Exterior Gateway Protocol Formal Specification (Formalna specyfikacja protokołu EGP) 911

EGP Gateway Under Berkeley UNIX 4.2 (Brama EGP pod nadzorem systemu Berkeley UNIX 4.2)

970

On Packet Switches With Infinite Storage (O przełącznikach pakietów z nieskończoną pamięcią)

975 Autonomous Confederations (Autonomiczne konfederacje) 985

Requirements for Internet Gateways — Draft (Wymagania dla bram internetowych — wersja robocza)

1046 Queuing Algorithms to Provide Type-of-service for IP Links. (Algorytmy kolejkowania dla zapewnienia obsługi typu usługi w łączach IP). W. Prue i J. Postel. 01.02.1988. (Format: TXT=30 106 bajtów) (Status: nieznany) 1058 Routing Information Protocol. (Protokół RIP). C. I. Hedrick. 01.01.1988. (Format: TXT=93 285 bajtów) (Uaktualniony przez RFC1388/RFC1723) (Status: historyczny) 1074 NSFNET Backbone SPF-Based Interior Gateway Protocol. (Oparty na SPF protokół IGP w sieci szkieletowej NSFNET). J. Rekhter. 01.10.1988. (Format: TXT=36 000 bajtów) (Zastąpiony przez RFC1323) (Status: nieznany) 1075 Distance Vector Multicast Routing Protocol. (Protokół routingu rozgłoszenia wektora odległości). D. Waitzman, C. Partridge i S. E. Deering. 01.11.1988. (Format: TXT=54 731 bajtów) (Status: eksperymentalny) 1092 EGP and Policy-based Routing in the New NSFNET Backbone. (EGP i routing oparty na regułach w nowej sieci szkieletowej NSFNET). J. Rekhter. 01.02.1989. (Format: TXT=11 865 bajtów) (Status: nieznany) 1093 NSFNET Routing Architecture. (Architektura routingu NSFNET). H. W. Braun. 01.02.1989. (Format: TXT=20 629 bajtów) (Status: nieznany) 1102 Policy Routing in Internet Protocols. (Routing według reguł w protokołach internetowych). D. D. Clark. 01.05.1989. (Format: TXT=59 664 bajty) (Status: nieznany) 1104 Models of Policy-based Routing. (Modele routingu opartego na regułach). H. W. Braun. 01.01.1989. (Format: TXT=25 468 bajtów) (Status: nieznany) 1105 Border Gateway Protocol (BGP). (Protokół BGP). K. Loughheed i Y. Rekhter. 01.01.1989. (Format: TXT=37 644 bajty) (Zastąpiony przez RFC1163) (Status: eksperymentalny)

412

TCP/IP. SZKOŁA PROGRAMOWANIA

1125 Policy Requirements for Interadministrative Domain Routing. (Wymagania co do reguł dla routingu domen przez granice administracyjne). D. Estrin. 01.01.1989. (Format: TXT=55248, PS=282 123 bajty) (Status: nieznany) 1131 OSPF Specification. (Specyfikacje OSPF). J. Moy. 01.10.1989. (Format: TXT=268, PS=857 280 bajtów) (Zastąpiony przez RFC1247) (Status: propozycja standardu) 1133 Routing Between the NSFNET and the DDN. (Routing między NSFNET a DNN). J. Y. Yu i H. W. Braun. 01.11.1989. (Format: TXT=23 169 bajtów) (Status: informacyjny) 1136 Administrative Domains and Routing Domains: A Model for Routing in the Internet. (Domeny administracyjne i domeny routingu). S. Hares i D. Katz. 01.10.1989. (Format: TXT=22 158 bajtów) (Status: informacyjny) 1142 OSI IS-IS Intradomain Routing Protocol. (Protokół routingu międzydomenowego OSI IS-IS). D. Oran. 01.02.1990. (Format: TXT=425379, PS=1204 297 bajtów) (Status: informacyjny) 1163 Border Gateway Protocol (BGP). (Protokół BGP). K. Lougheed i Y Rekhter. 01.06.1990. (Format: TXT=69 404 bajty) (zastąpił RFC1105) (Zastąpiony przez RFC1267) (Status: historyczny) 1164 Application of the Border Gateway Protocol on the Internet. (Zastosowanie protokołu BGP to Internecie). J. C. Honig, D. Katz, M. Mathis, Y. Rekhter i J. Y. Yu. 01.06.1990. (Format: TXT=56 278 bajtów) (zastąpiony przez RFC1268) (Status: historyczny) 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments. (Wykorzystanie OSI IS-IS w routingu TCP/IP i w środowiskach podwójnych). R. W. Callon. 01.12.1990. (Format: TXT=187866, PS=362 052 bajty) (Status: propozycja standardu) 1222 Advancing the NSFNET Routing Architecture. (Rozszerzanie architektury routingu NSFNET). H. W. Braun i Y. Rekhter. 01.05.1991. (Format: TXT=15 067 bajtów) (Status: informacyjny) 1245 OSPF Protocol Analysis. (Analiza protokołu OSPF). J. Moy. 01.06.1991. (Format: TXT=26160, PS=33 546 bajtów) (także RFC1247,RFC1246) (Status: informacyjny) 1246 Experience With OSPF Protocol. (Doświadczenia z protokołem OSPF). J. Moy. 01.06.1991. (Format: TXT=70441, PS=141 924 bajty) (także RFC1247, RFC1245) (Status: informacyjny) 1247 OSPF Version 2. (OSPF wersja 2). J. Moy. Jul-01-1991. (Format: TXT=433332, PS=989 724 bajty) (zastąpił RFC1131) (Zastąpiony przez RFC1252) (Status: propozycja standardu)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

413

1252 OSPF Version 2 Management Information Base. (Baza informacji o zarządzaniu w OSPF wersja 2). F. Baker i R. Coltun. 01.08.1991. (Format: TXT=74 471 bajtów) (zastąpił RFC1248) (Zastąpiony przez RFC1253) (także RFC1247,RFC1245) (Status: propozycja standardu) 1253 OSPF Version 2 Management Information Base. (Baza informacji o zarządzaniu w OSPF zuersja 2). F. Baker i R. Coltun. 01.08.1991. (Format: TXT=74 453 bajty) (zastąpił RFC1252) (Zastąpiony przez RFC1850) (także RFC1247, RFC1245, RFC1246) (Status: propozycja standardu) 1254 Gateway Congestion Control Survey. (Podsumowanie kontroli zatorów bram). A. Mankin i K. Ramakrishnan. 01.07.1991. (Format: TXT=67 609 bajtów) (Status: informacyjny) 1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria. (Kryteria IETF dla standaryzacji protokołu routingu ). R. M. Hinden. 01.10.1991. (Format: TXT=17 016 bajtów) (Status: informacyjny) 1265 BGP Protocol Analysis. (Analiza protokołu BGP). Y. Rekhter. 01.10.1991. (Format: TXT=20 728 bajtów) (Status: informacyjny) 1266 Experience With the BGP Protocol. (Doświadczenia z protokołem BGP). Y. Rekhter. 01.10.1991. (Format: TXT=21 928 bajtów) (Status: informacyjny) 1267 Border Gateway Protocol 3(BGP-3). (Protokół BGP-3). K. Lougheed i Y. Rekhter. 01.10.1991. (Format: TXT=80 724 bajty) (zastąpił RFC1163) (Status: historyczny) 1268 Application of the Border Gateway Protocol in the Internet. (Zastosowanie protokołu BGP w Internecie). Y. Rekhter i P. Gross. 01.10.1991. (Format: T X T = 3 1 102 bajty) (zastąpił RFC1164) (Zastąpiony przez RFC1655) (Status: historyczny) 1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3. (Definicje obiektów zarządanych dla protokołu BGP: wersja 3). S. Willis i J. W. Burruss. 01.10.1991. (Format: TXT=25 717 bajtów) (Status: propozycja standardu) 1322 A Unified Approach to Interdomain Routing. (Zunifikowane podejście do routingu międzydomenowego). D. Estrin, Y. Rekhteri i S. Hotz. Maj 1992. (Format: TXT=96 934 bajty) (Status: informacyjny) 1364 BGP OSPF Interaction. (Interakcja BGP O SPF). K. Varadhan. Wrzesień 1992. 1370 Application Statement for the OSPF. Internet Architecture Board.. (Zasady aplikacji dla OSPF: Rada architektury internetowej). L. Chapin. Październik 1992. (Format: TXT=4 303 bajty) (Status: propozycja standardu)

414

TCP/IP. SZKOŁA PROGRAMOWANIA

1383 An Experience in DNS-based IP Routing (Doświadczenie z routingiem IP opartym na DNS) 1387 RIP Version 2 Protocol Analysis. (Analiza protokołu RIP wersja 2). G. Malkin. Styczeń 1993. (Format: TXT=5 998 bajtów) (Zastąpiony przez RFC1721) (Status: informacyjny) 1388 RIP Version 2 Carrying Additional Information. (Przenoszący dodatkowe informacje protokół RIP wersja 2). G. Malkin. Styczeń 1993. (Format: TXT=16 227 bajtów) (Zastąpiony przez RFC17213) (uaktualnia RFC1058) (Status: propozycja standardu) 1389 RIP Version 2 MIB Extensions. (Rozszerzenia MIB dla RIP wersja 2). G. Malkin, F. Baker. Styczeń 1993, (Format: TXT=23 569 bajtów) (Zastąpiony przez RFC1724) (Status: propozycja standardu) 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol. (Ogłaszanie domyślnej trasy w protokołach BGP2 i BGP3). D. Haskin. Styczeń 1993. (Format: TXT=4 124 bajty) (Status: propozycja standardu) 1403 BGP OSPF Interaction. (Interakcje PGP OSPF ). K. Varadhan. Styczeń 1993. (Format: TXT=36 173 bajty) (zastąpił RFC1290) (także FY10010) (Status: informacyjny) 1465 Routing Coordination for X.400 MHS Services Within a Multi-Protocol/ Multi-Network Environment Table Format V3 for Static Routing. (Koordynacja routingu dla usług X.400 MHS w wieloprotokolozuym /wielosiedowym środowisku tabeli formatu V3 dla routingu statycznego) 1477 IDPR as a Standard Proposition. (IDPRjako proponowany standard ). M. Steenstrup. Lipiec 1993. (Format: TXT=77 854 bajty) (Status: eksperymentalny) 1478 An Architecture for Interdomain Policy Routing. (Architektura dla routingu międzydomenowego). M. Steenstrup. Lipiec 1993. (Format: TXT=275 823 bajty) (Status: propozycja standardu) 1479 Inter-domain Policy Routing Protocol Specification: Version 1. (Specyfikacje routingu międzydomenowego: wersja 1). M. Steenstrup. Lipiec 1993. (Format: TXT=275 823 bajty) (Status: propozycja standardu) 1482 Aggregate Support in the NSFNET Policy-based Routing Database. (Obsługa agregacji w bazie danych routingu NSFNET). Mark Knopper i Steven J. Richardson. Lipiec 1993. (Format: TXT=25 330 bajtów) (Status: informacyjny)

Dodatek A ° DOKUMENTY RFC WG ROZDZIAŁÓW

415

1504 Appletalk Update-based Routing Protocol: Enhanced Appletalk Routing. (Protokół routingu Appletalk oparty na uaktualnieniach: Rozszerzony routing Appletalk). A. Oppenheimer. Sierpień 1993. (Format: TXT=201 553 bajty) (Status: informacyjny) 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR). (Stosowalność implementacji bezklasowego routingu między domenowego). Internet Engineering Steering Group, R. Hinden. Wrzesień 1993. (Format: TXT=7 357 bajtów) (Status: propozycja standardu) 1519 Classless Interdomain Routing (CIDR): an Address Assignment and Aggregation Strategy. (Bezklasowy routing międzydomenowy: strategie przydziału adresów i agregacji.). V. Fuller, T. Li, J. Yu i K. Varadhan. Wrzesień 1993. (Format: TXT=59 998 bajtów) (zastąpił RFC1338) (Status: propozycja standardu) 1519 Exchanging Routing Information Across Provider Boundries in the CIDR Environment. (Wymiana informacji routingu przez granice dostawców w środowisku CIDR). Y. Rekhter i C. Topolcic. Wrzesień 1993. (Format: TXT=20 389 bajtów) (Status: informacyjny) 1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits. (Analiza protokołu dotycząca rozszerzeń RIP obsługujących obwod yna żądanie). G. Meyer. Luty 1994. (Format: TXT=7 536 bajtów) 1582 Extensions to RIP to Support Demand Circuits. (Rozszerzenia RIP obsługujące obwody na żądanie). G. Meyer. Luty 1994. (Format: TXT=63 271 bajtów) (Status: propozycja standardu) 1583 OSPF Version 2. (OSPF wersja 2). J. Moy. Marzec 1994. (Format: TXT=532636, PS=990 794 bajty) (zastąpił RFC1247) (Zastąpiony przez RFC2178) (Status: wersja robocza standardu) 1584 Multicast Extensions to OSPF. (Rozszerzenia muliemisji dla OSPF). J. Moy. Marzec 1994. (Format: TXT=262463, PS=426 358 bajtów) (Status: propozycja standardu) 1585 MOSPF: Analysis and Experience. (MOSPF: Analiza i doświadczenie). J. Moy. Marzec 1994. (Format: TXT=29 754 bajty) (Status: informacyjny) 1586 Guidelines for Running OSPF Over Frame Relay Networks. (Wskazówki wykorzystania OSPF w sieciach Frame Relay). O. deSouza i M. Rodrigues. Marzec 1994. (Format: TXT=14 968 bajtów) (Status: informacyjny) 1587 The OSPF NSSA Option. (Opcja OSPF NSSA). R. Coltun i V. Fuller. Marzec 1994. (Format: TXT=37 412 bajtów) (Status: propozycja standardu)

416

TCP/IP. SZKOŁA PROGRAMOWANIA

1654 A Border Gateway Protocol 4 (BGP-4). (Protokół BGP-4). Y. Rekhter i T. Li, Editors. Lipiec 1994. (Format: TXT=130 118 bajtów) (Zastąpiony przez RFC1771) (Status: propozycja standardu) 1701 Generic Routing Encapsulation (GRE). (Podstawowa hermetyzacja routingu). S. Hanks, T. Li, D. Farinacci i P. Traina. Październik 1994. (Format: TXT=15 460 bajtów) (Status: informacyjny) 1702 Generic Routing Encapsulation Over IPv4 Networks. (Podstawowa hermetyzacja routingu w sieciach IPv4). S. Hanks, T. Li, D. Farinacci i P. Traina. Październik 1994. (Format: TXT=7 288 bajtów) (Status: informacyjny) 1721 RIP Version 2 Protocol Analysis. (Analiza protokołu RIP wersja 2). G. Malkin. Listopad 1994. (Format: TXT=6 680 bajtów) (zastąpił RFC1387) (Status: informacyjny) 1722 RIP Version 2 Protocol Applicability Statement. (Określenie stosowalności protokołu RIP wersja 2). G. Malkin. Listopad 1994. (Format: TXT=10 236 bajtów) (Status: wersja robocza standardu) 1723 RIP Version 2 — Carrying Additional Information. (Protokół RIP wersja 2 — Przenoszenie dodatkowych informacji). G. Malkin. Listopad 1994. (Format: TXT=18 597 bajtów) (zastąpił RFC1388) (uaktualnia RFC1058) (Status: wersja robocza standardu) 1745 BGP4/IDRP for IP-OSPF Interaction. (Interakcja BGP4/IDRP dla IP-OSPF ). K. Varadhan, S. Hares i Y. Rekhter. Grudzień 1994. (Format: TXT=43 675 bajtów) (Status: propozycja standardu) 1765 OSPF Database Overflow. (Przepełnienie bazy danych O SPF). J. Moy. Marzec 1995. (Format: TXT=21 613 bajtów) (Status: eksperymentalny) 1771 A Border Gateway Protocol 4 (BGP-4). (Protokół BGP-4). Y. Rekhter i T. Li. Marzec 1995. (Format: TXT=11 606 bajtów) (Status: informacyjny) 1772 Application of the Border Gateway Protocol in the Internet. (Zastosowanie protokołu BGP w Internecie). Y. Rekhter & P. Gross. Marzec 1995. (Format: TXT=43 916 bajtów) (zastąpił RFC1655) (Status: wersja robocza standardu) 1773 of the BGP-4 protocol. (Zastosowanie protokołu BGP-4). P. Traina. Marzec 1995. (Format: TXT=19 936 bajtów) (zastąpił RFC1656) (Status: informacyjny) 1774 BGP-4 Protocol Analysis. (Analiza protokołu BGP-4). P. Traina, Editor. Marzec 1995. (Format: TXT=23 823 bajty) (Status: informacyjny)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

417

1786 Representation of the IP Routing Policies in a Routing Registry (ripe-81 + +). (Reprezentacja reguł routingu IP w rejestrze routingu). T. Bates, E. Gerich, L. Joncheray, J. M. Jouanigot, D. Karrenberg, M. Terpstra i J. Yu. Marzec 1995. (Format: TXT=133 643 bajty) (Status: informacyjny) 1787 Routing in a Multi-provider Internet. (Routing w Internecie przy wielu dostawcach). Y. Rekhter. Kwiecień 1995. (Format: TXT=20 754 bajty) (Status: informacyjny) 1793 Extending OSPF to Support Demand Circuits. (Rozszerzenia OSPF do obsługi obwodów na żądanie). J. Moy. Kwiecień 1995. (Format: TXT=16 389 bajtów) (Status: eksperymentalny) 1817 CIDR and Classful Routing. (CIDR i routing klasowy). Y. Rekhter. Sierpień 1995. (Format: TXT=3 416 bajtów) (Status: informacyjny) 1863 A BGP/IDRP Route Server Alternative to Full Mesh Routing. (Serwer trasy BGP/IDRP jako alternatywa dla routingu pełnej kraty). D. Haskin. Październik 1995. (Format: TXT=37 426 bajtów) (zastąpił RFC1645) (Status: eksperymentalny) 1923 RIPvl Applicability Statement for Historic Status. (Ocena stosowalności RIPvl jako przyczyna zmiany jego statusu na historyczny). J. Halpern & S. Bradner. Marzec 1996. (Format: TXT=5 560 bajtów) (Status: informacyjny) 1965 Autonomous System Confederations for BGP. (Konfederacje systemów autonomicznych w BGP). P. Traina. Czerwiec 1996. (Format: TXT=13 575 bajtów) (Status: eksperymentalny) 1966 BGP Route Reflection: An alternative to Full Mesh IBGP. (Odbicie trasy BGP: Alternatywa dla IBGP pełnej kraty). T. Bates i R. Chandrasekeran. Czeiwiec 1996. (Format: TXT=14 320 bajtów) (Status: eksperymentalny) 1992 The Nimrod Routing Architecture. (Architektura routingu Nimrod). I. Casineyra, N. Chiappa i M. Steestrup. Sierpień 1996. (Format: TXT=46 255 bajtów) (Status: informacyjny) 1997 BGP Communities Attribute. (Atrybut społeczności BGP). R. Chandra, P. Traina i T. Li. Sierpień 1996. (Format: TXT=8 275 bajtów) (Status: propozycja standardu) 1998 An Application of the BGP Community Attribute in Multi-home Routing. (Zastosowanie atrybutu społeczności BGP w routingu do wielu stacji domowych). E. Chen & T. Bates. Sierpień 1996. (Format: TXT=16 953 bajty) (Status: informacyjny) 2009 GPS-based Addressing and Routing. (Adresowanie i routing oparte na GPS ). T. Imielinski i J. Navas. Listopad 1996. (Format: TXT=66 229 bajtów) (Status: eksperymentalny)

418

TCP/IP. SZKOŁA PROGRAMOWANIA

2082 RIP-2 MD5 Authentication. (Uwierzytelnienie RIP-2 MD5). F. Baker i R. Atkinson. Styczeń 1997. (Format: TXT=25 436 bajtów) (Status: propozycja standardu) 2091 Triggered Extensions to RIP to Support Demand Circuits. (Wyzwalane rozszerzenia dla RIP obsługujące obwody na żądanie). G. Meyer i S. Sherry. Styczeń 1997. (Format: TXT=44 835 bajtów) (Status: propozycja standardu) 2092 Protocol Analylsis for Triggered RIP. (Analiza protokołu dla wyzwalanych RIP). S. Sherry, G. Meyer. Styczeń 1997. (Format: TXT=10 865 bajtów) (Status: informacyjny) 2102 Multicast Support for Nimrod: Requirements and Solution Approaches. (Obsługa multicast dla Nimrod: wymagania i podejścia do rozwiązania). R. Ramanathan. Luty 1997. (Format: TXT=50 963 bajty) (Status: informacyjny) 2103 Mobility Support for Nimrod: Challenges and Solution Approaches. (Wsparcie mobilności w architekturze Nimrod). R. Ramanathan. Luty 1997. (Format: TXT=41 352 bajty) (Status: informacyjny) 2117 Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification. (Niezależny od protokołu tryb z niedostatkiem midtiemisji: Specyfikacja protokołu). D. Estrin, D. Farinacci, A. Hełmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma i L. Wei. Czerwiec 1997. (Format: TXT=151 886 bajtów) (zastąpiony przez RFC2362) (Status: eksperymentalny) 2154 OSPF with Digital Signatures. (OSPF z podpisem cyfrowym). S. Murphy, M. Badger, B. Wellington. Czerwiec 1997. (Format: TXT=72 701 bajtów) (Status: eksperymentalny) 2178 OSPF Version 2. (OSPF wersja 2). J. Moy. Lipiec 1997. (Format: TXT=495 866 bajtów) (zastąpił RFC1583) (Zastąpiony przez RFC2328) (Status: wersja robocza standardu) 2189 Core-based Trees (CBT Version 2) Multicast Routing. (Routing multiemisji dla drzew opartych na rdzeniu (CTB wersja 2)). A. Balardie. Wrzesień 1997. (Format: TXT=52 043 bajty) (Status: eksperymentalny) 2201 Core-based Trees (CBT) Multicast Routing Architecture. (Architektura routingu mutliemisji drzew opartych na rdzeniu). A. Ballardie. Wrzesień 1997. (Format: TXT=38 040 bajtów) (Status: eksperymentalny) 2260 Scalable Support for Multi-homed Multi-provider Connectivity. (Skalowalna obsługa dla połączeń wielu dostawców i stacji domowych). T. Bates, Y. Rekhter. Styczeń 1998. (Format: TXT=28 085 bajtów) (Status: informacyjny) 2270 Using a Dedicated AS for Sites Homed to a Single Provider. (Korzystanie z dedykowanego AS dla stacji jednego dostawcy). J. Stewart, T. Bates, R. Chadra i E. Chen. Styczeń 1998. (Format: TXT=12 063 bajty) (Status: informacyjny)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

419

2280 Routing Policy Specification Language (RSPL). (Język specyfikacji reguł routingu). C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra i C. Villamizar. Styczeń 1998. (Format: TXT=114 985 bajtów) (Status: propozycja standardu) 2281 Cisco Hot Standby Router Protocol (HSRP). (Protokół Cisco HSRP). T. Li, B. Cole, P. Morton, D. Li. Marzec 1998. (Format: TXT=35 161 bajtów) (Status: informacyjny) 2283 Multiprotocol Extensions for BGP-4. (Wieloprotokołowe rozszerzenia BGP-4). T. Bates, R. Chandra, D. Katz, Y. Rekhter. Luty 1998. (Format: TXT=18 946 bajtów) (Status: propozycja standardu) 2328 OSPF Version 2. (OSPF wersja 2). J. Moy. Kwiecień 1998. (Format: TXT=447 367 bajtów) (zastąpił RFC2178) (także STD0054) (Status: standard) 2329 OSPF Standardization Report. (Raport w sprawie standaryzacji O SPF). J. Moy. Kwiecień 1998. (Format: TXT=15 130 bajtów) (Status: informacyjny) 2338 Virtual Router Redundancy Protocol. (Protokół redundancji wirtualnego routera). S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand i A. Lindem. Kwiecień 1998. (Format: TXT=59 871 bajtów) (Status: propozycja standardu) 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. (Niezależny od protokołu tnyb z niedostatkiem multiemisji (PIM-SM): Specyfikacje protokołu). D. Estrin, D. Farinacci, A. Hełmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma i L. Wei. Czerwiec 1998. (Format: TXT=159 833 bajty) (zastąpił RFC2117) (Status: eksperymentalny) 2370 The OSPF Opaque LSA Option. (Opcja nieprzejrzystego LSA dla O SPF). R. Coltun. Lipiec 1998. (Format: TXT=33 789 bajtów) (także RFC2328) (Status: propozycja standardu) 2385 Protection of BGP Sessions via the TCP MD5 Signature Option. (Ochrona sesji BGP za pomocą opcji podpisu TCP MD5). A. Heffernan. Sierpień 1998. (Format: TXT=12 315 bajtów) (Status: propozycja standardu) 2439 BGP Route Flap Damping. (Płaskie tłumienie trasy BGP). C. Villamiar, R. Chandra, R. Grovindan. Listopad 1998. (Format: TXT=86 376 bajtów) (Status: propozycja standardu) 2453 RIP Version 2. (RIP wersja 2). G. Malkin. Listopad 1998. (Format: TXT=98 462 bajty) (zastąpił RFC1388, RFC1723) (Updates RFC1723, RFC1388) (także STD0056) (Status: standard)

420

TCP/IP. SZKOŁA PROGRAMOWANIA

2519 A Framework for Interdomain Route Aggregation. (Zasady agregacji tras międzydomenowych). E. Chen, J. Stewart. Luty 1999. (Format: TXT=25 394 bajty) (Status: informacyjny) 2622 Routing Policy Specification Language (RPSL) 2650 Using RPSL in Practice 2676 QoS Routing Mechanisms and OSPF Extensions (język specyfikacji reguł routingu) 2676 QoS Routing Mechanisms and OSPF Extensions (Mechanizmy routingu QoS i rozszerzenia OSPF) 2715 Interoperability Rules for Multicast Routing Protocols (Zasady współdziałania dla protokołów routingu multiemisji)

Rozdział 7» Warstwa transportowa 1162 Connectionless Network Protocol (ISO 8473) and End Systems to Intermediate System (ISO 9542) Management Information Base. (Bezpolqczeniowy protokół siecioioy i systemy końcowe dla systemu pośredniczącego bazy informacji o zarządzaniu). G. Satz. 01.06.1990. (Format: TXT=109 893 bajty) (Zastąpiony przez RFC1238) (Status: eksperymentalny)

Rozdział 8. Protokół sterowania transmisją (TCP) 675 Transmission Control Protocol (Protokół sterowania transmisją) 700 Protocol Experiment (Eksperyment z protokołami) 721

Out-of-Band Control Signals in a Host-to-Host Protocol (Sygnały sterujące poza zakresem w protokole host-host)

761

Transmission Control Protocol (Protokół sterowania transmisją)

793 Transmission Control Protocol (Protokół sterowania transmisją) 794

Pre-emption (Wywłaszczanie)

813 Window and Acknowledgement Strategy in TCP (Strategia okien i potwierdzeń w TCP) 872 TCP-on-a-LAN (TCP w sieci LAN) 879

TCP Maximum Segment Size and Related Topics (Maksymalny rozmiar segmentów TCP i inne poioiązane tematy)

889 Internet Delay Experiments (Eksperymenty nad opóźnieniami w Internecie)

Dodatek A » DOKUMENTY RFC WG ROZDZIAŁÓW

896

421

Congestion Control in IP/TCP Internetworks (Kontrola zatorów w połączeniach mięcizysieciowych TCP/IP)

962 TCP-4 Prime (Podstawy TCP-4) 964

Some Problems With the Specifications of the Military Standard Transmission Control Protocol (Problemy ze specyfikacją protokołu MSTCP)

1006 ISO Transport Services On Top of TCP: Version 3 (Usługi transportowe ISO tu TCP: wersja 3). M. T. Rose i D. E. Cass. 01.05.1987. (Format: TXT=31 935 bajtów) (zastąpił RFC0983) (Status: standard) 1072 TCP Extensions for Long-delay Paths (Rozszerzenia TCP dla ścieżek o dużym opóźnieniu). V. Jacobson i R. T. Braden. 01.10.1988. (Fonnat: TXT=36 000 bajtów) (Zastąpiony przezRFC1323) (Status: nieznany) 1078 TCP port service Multiplexer (TCPMUX) (Midtiplekser obsługi portu TCP). M. Lottor. 01.11.1988. (Format: TXT=3 248 bajtów) (Status: nieznany) 1106 TCP Big Window and NAK Options (Opcje dużego okna TCP i N A K ). R. Fox. Jun-01-1989. (Format: T X T = 37105 bajtów) (Status: nieznany) 1110 Problem With the TCP Big Window Option (Problemy z opcją dużego okna TCP). A. M. McKenzie. 01.08.1989. (Fonnat: TXT=5 778 bajtów) (Status: nieznany) 1144 Compressing TCP/IP Headers for Low-speed Serial Links (Kompresja nagłówków TCP/IP dla łączy szeregoiuych o małej szybkości). V. Jacobson. 01.02.1990. (Format: TXT=120959, PS=534 729 bajtów) (Status: propozycja standardu) 1185 TCP Extensions for High-speed Paths (Rozszerzenia TCP dla szybkich ścieżek). V. Jacobson, R. T. Braden i L. Zhang. 01.10.1990. (Format: XT=49 508 bajtów) (Zastąpiony przez RFC1323) (Status: eksperymentalny) 1263 TCP Extensions Considered Harmful (Rozszerzenia TCP uważane za szkodlizoe). S. O'Malley i L. L. Peterson. 01.10.1991. (Format: TXT=54 078 bajtów) (Status: informacyjny) 1323 TCP Extensions for High Performance (Rozszerzenia TCP dla dużej zuydajności). V. Jacobson, R. Braden i D. Borman. Maj 1992. (Format: TXT=84 558 bajtów) (zastąpił RFC1072, RFC1185) (Status: propozycja standardu) 1337 TIME-WAIT Assassination Hazards for TCP (Zagrożenia likwidacją TIME-WAIT dla TCP). R. Braden. Maj 1992. (Format: TXT=22 887 bajtów) (Status: informacyjny) 1379 Extending TCP for Transactions — Concepts (Rozszerzanie TCP dla transakcji — koncepcje). R. Braden. Listopad 1992. (Format: TXT=91 353 bajty) (Status: informacyjny)

422

TCP/IP. SZKOŁA PROGRAMOWANIA

1644 T/TCP — TCP Extensions for Transactions Functional Specifications (T/TCP — Rozszerzenia TCP dla funkcjonalnych specyfikacji transakcji). R. Braden. Lipiec 1994. (Format: TXT=87 362 bajty) (Status: eksperymentalny) 1693 An Extension of TCP: Partial Order Service (Rozszerzenie TCP: obsługa częściowego uporządkowania). T. Connolly, P. Amer i P. Conrad. Listopad 1994. (Format: TXT=26 163 bajty) (Status: propozycja standardu) 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms Algorytmy powolnego startu, unikania zatorów, szybkiej retransmisji i szybkiej odnowy po awarii dla TCP). W. Stevens. Styczeń 1997. (Format: TXT=12 981 bajtów) (Status: propozycja standardu) 2018 TCP Selective Acknowledgement Options (Opcje selektyzunego potwierdzania TCP). M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. Październik 1996. (Format: TXT=25 671 bajtów) (Status: propozycja standardu) 2140 TCP Control Block Interdependence (Współzależność bloku sterowania TCP). ]. Touch. Kwiecień 1997. (Format: TXT=26 032 bajty) (Status: informacyjny) 2398 Some Testing Tools for TCP Implementors (Niektóre narzędzia testowania dla implementacji TCP). S. Parker, C. Schmechel. Sierpień 1998. (Format: TXT=24 107 bajtów) (Status: informacyjny) 2414 Increasing TCP's Initial Window (Zwiększanie początkowego okna TCP). M. Allman, S. Floyd i C. Partridge. Wrzesień 1998. (Format: TXT=32 019 bajtów) (Status: eksperymentalny) 2415 Simulating Studies of Increased Initial TCP Window Size (Badania symulacyjne zwiększonego rozmiaru początkowego okna TCP). K. Poduri i K. Nichols. Wrzesień 1998. (Format: TXT=24 205 bajtów) (Status: informacyjny) 2416 When TCP Starts Up With Four Packets Into Only Three Buffers (Gdy TCP startuje z czterema pakietami i tylko trzeba buforami). T. Shepard, C. Partridge. Wrzesień 1998. (Format: TXT=12 663 bajty) (Status: informacyjny) 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms (Rozszerzanie TCP przez łamały satelitarne za pomocą standardowych mechanizmów). M. Allman, D. Glover i L. Sanchez. Styczeń 1999. (Format: TXT=47 857 bajtów) (także BCP0028) (Status: najlepsze obecne procedury) 2525 Known TCP Implementation Problems (Znane problemy z implementacją TCP). V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, H. Semke i B. Volz. Marzec 1999. (Format: TXT=137 201 bajtów) (Status: informacyjny)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

423

2581 TCP Congestion Control (Kontrola zatorów TCP). M. Allman, V. Paxson, W. Stevens. Kwiecień 1999. (Format: TXT=31 351 bajtów) (zastępuje RFC2001) (Status: propozycja standardu) 2582 The NewReno Modification to TCP'S Fast Recovery Algorithm (Modyfikacje NewReno do algorytmu szybkiej odnowy TCP). S. Floyd, T. Henderson. Kwiecień 1999. (Format: TXT=29 393 bajty) (Status: eksperymentalny)

Rozdział 9. Protokół datagramów użytkownika (UDP) 768 User Diagram Protocol (Protokół datagramów użytkownika)

Rozdział 11. Telnet 91

Proposed User-User Protocol (Proponowany protokół User-User)

97 First Cut at a Proposed Telnet Protcol (Pierwsza przymiarka do proponowanego protokołu Telnet) 103 Implementation of Interrupt Keys (Implementacje kluczy przerwań) 110 Response to NWG/RFC 110 (Odpowiedź na NWG/RFC110) 114 File Transfer Protocol (Protokół przesyłania plików) 135 Response to NWG/RFC 110 (Odpowiedź na NWG/RFC 110) 137 Telnet Protocol — a Proposed Document (Protokół Telnet — proponowany dokument) 139 Discussion of Telnet Protocol (Omówienie protokołu Telnet) 158 Telnet Protocol: A Proposed Document (Protokół Telnet — proponowany dokument) 172 File Transfer Protocol (Protokół FTP) 190 DEC PDP-10-IMLAC Communication System (System komunikacyjny DEC PDP-10-IMLAC) 205

NETCRT — a Character Display Protocol (NETCRT — protokół wyświetlania znaków)

206 User Telnet — a Description of Initial Implementation (Telnet użytkownika — opis wstępnej implementacji)

424

TCP/IP. SZKOŁA PROGRAMOWANIA

215 NCP, ICP, and Telnet: The Terminal IMP Implementation (NCP, ICP i Telnet: implementacja terminala IMP) 216 Telnet Access to UCSB'S Online System (Dostęp z Telnetu do systemu UCSB) 265

File Transfer Protocol (Protokół FTP)

318 Telnet Protocols (Protokoły Telnet) 328 Suggested Telnet Protocol Changes (Sugerowane zmiany protokołu Telnet) 339 MLTNET: A "Multi Telnet" Subsystem for Tenex (MLTNET: „Wielotelnetowy" podsystem dla Telex) 340 Proposed Telnet Changes (Proponowane zmiany Telnetu) 346 Response to NWG/RFC 346 (Odpowiedź na NWG/RFC 346) 354 File Transfer Protocol (Protokół FTP) 355 Response to NWG/RFC 346 (Odpowiedź na NWG/RFC 346) 357 Echoing Strategy for Satellite Links (Strategia echa dla połączeń satelitarnych) 377 Using TSO via ARPA Network Virtual Terminal (Używanie TSO przez wirtualny terminal sieci ARPA) 393 Comments on Telnet Protocol Changes (Komentarze na temat zmian protokołu Telnet) 426 Reconnection Protocol (Protokół ponownego połączenia) 435 Telnet Issues (Zagadnienia Telnetu) 452 TELENET Command on Host LL (Polecenie TELENET na hoście LL) 466 Telnet Logger/Server for Host LL-67 (Telnet Logger/Server dla hosta LL-67) 495 Telnet Protocol Specifications (Specyfikacje protokołu Telnet) 513

Comments on New Telnet Specifications (Komentarze na temat specyfikacji nowego Telnetu)

529 Note on Protocol Synch Sequences (Uioagi na temat sekwencji synchronizacyjnych protokołu) 542 File Transfer Protocol (Protokół FTP) 559 Comments on The New Telnet Protocol and its Implementation (Komentarze na temat nowego protokołu Telnet i jego implementacji)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

560

425

Remote Controlled Transmission and Echoing Telnet Option (Zdalnie kontrolowana transmisja i opcja echa w protokole Telnet)

562 Modifications to the Telnet Specifications (Modyfikacje specyfikacji Telnetu) 563

Comments on the RCTE Telnet Option (Komentarze na temat opcji RCTE iu Telnet)

570

Experimental Input Mapping Between NVT ASCII and UCSB Online System (Eksperymentalne mapowanie loejścia pomiędzy NVT ASCII a systemem UCSB)

576

Proposal and Identifying Linking (Propozycja i identyfikacja połączeń)

581

Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option (Poprawki do RFC 560: zdalnie kontrolowana transmisja i opcja echa w protokole Telnet)

587

Announcing New Telnet Option (Ogłoszenie noiuej opcji protokołu Telnet)

593

Telnet and FTP Implementation Schedule Change (Zmiany harmonogramu implementacji protokołóiu Telnet i FTP)

594

Second Thoughts in Defense of Telnet Go-Ahead (Przemyślenia w obronie Telnet Go-Ahead)

600

Interfacing an Illinois Plasma Terminal to the ARPANET (Tworzenie interfejsu pomiędzy terminalem plazmowym Illinois a siecią ARPANET)

651

Revised Telnet Status Option (Poprawiona opcja stanu protokołu Telnet)

652 Telnet Output Carriage-return Disposition Option (Opcja dyspozycji powrotu łcaretki dla luyjścia Telnet) 653

Telnet Output Horizontal Tabstops Option (Opcje tabulatorów poziomych dla wyjścia Telnet)

654 Telnet Output Horizontal Tab Disposition Option (Opcje dyspozycji tabulatorów poziomych dla wyjścia Telnet) 655 Telnet Output Formfeed Disposition Option (Opcje dyspozycji początku strony dla wyjścia Telnet) 656 Telnet Output Vertical Tabstops Option (Opcje tabulatorów pionowych dla zuyjścia Telnet) 657

Telnet Output Vertical Tab Disposition Option (Opcje dyspozycji tabulatorów pionowych dla wyjścia Telnet)

658 Telnet Output Linefeed Disposition (Opcje dyspozycji nowego wiersza dla wyjścia Telnet)

T

426

TCP/IP. SZKOŁA PROGRAMOWANIA

659 Announcing Additional Telnet Options (Ogłoszenie dodatkowych opcji Telnetu) 669 July, 1975 Survey of New-Protocol Telnet Servers (Opracowanie na temat serwerów nowego protokołu Telnet z lipca 1975) 679 July, 1975 Survey of New-Protocol Telnet Servers (Opracowanie na temat serwerów nowego protokołu Telnet z lipca 1975) 681 Network UNIX (Sieciowy UNIX) 688 Tentative Schedule for the New Telnet Implementation for the TIP (Tymczasowy harmonogram implementacji nowego Telnetu dla TIP) 701 July, 1975 Survey of New-Protocol Telnet Servers (Opracowanie na temat serwerów nowego protokołu Telnet z lipca 1975) 702 July, 1975 Survey of New-Protocol Telnet Servers (Opracowanie na temat serwerów nowego protokołu Telnet z lipca 1975) 703 July, 1975 Survey of New-Protocol Telnet Servers (Opracowanie na temat serwerów nowego protokołu Telnet z lipca 1975) 718

Comments on RCTE from the Tenex Implementation Experience (Komentarze na temat RCTE na podstawie doświadczeń implementacji Tenex)

719

Discussion on RCTE (Dyskusja na temat RYTE)

726 Remote Controlled Transmission and Echoing Telnet option (Zdalnie kontrolowana transmisja i opcja echa w protokole Telnet) 7717 Telnet Logout Option (Opcja wylogowania w protokole Telnet) 728 Minor Pitfall in the Telnet Protocol (Niewielkie problemy z protokołem Telnet) 729 Telnet Byte Macro Option (Opcja makra bajtowego w protokole Telnet) 730 Telnet Data Entry Terminal Option (Opcja terminala wprowadzania danych w protokole Telnet) 731 Telnet Data Entry Terminal Option (Opcja terminala wprowadzania danych w protokole Telnet) 735

Revised Telnet Byte Macro Option (Poprawiona opcja makra bajtowego w protokole Telnet)

736 Telnet SUPDUP Option (Opcje SUPDUP w protokole Telnet) 746 SUPDUP Graphics Extension (Rozszerzenia graficzne SUPDUP)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

427

747 Recent Extensions to the SUPDUP Protocol (Najnowsze rozszerzenia protokołu SUPDUP) 748

Telnet SUPDUP-Output Option (Opcje wyjścia SUPDUP w protokole Telnet)

764 Telnet Protocol Specifications (Specyfikacje protokołu Telnet) 765

File Transfer Protocol (Protokół FTP)

779 Telnet Send-Location Option (Opcja lokalizacji tuysyłającego w protokole Telnet) 782 Virtual Terminal Management Protocol (Protokół zarządzania wirtualnym terminalem) 818

Remote User Telnet Service (Obsługa zdalnych usług protokołu Telneu)

854 Telnet Protocol Specifications (Specyfikacje protokołu Telnet) 855

Telnet Option Specifications (Specyfikacje opcji protokołu Telnet)

856 Telnet Binary Transmissions (Transmisje binarne w protokole Telnet) 857 Telnet Echo Option (Opcja echa w protokole Telnet) 858 Telnet Suppress Go-Ahead Option (Opcja usunięcia Go-Ahead w protokole Telnet) 859 Telnet Status Option (Opcja stanu w protokole Telnet) 860

Telnet Timing Mark Option (Opcja znacznika czasu w protokole Telnet)

861

Telnet Extended Options: List Option (Rozszerzone opcje protokołu Telnet: opcja listowania)

884 Telnet Terminal Type Option (Opcja typu terminala w protokole Telnet) 885 Telnet End of Record Option (Opcja końca rekordu w protokole Telnet) 927 TACACS User Identification Telnet Option (Opcja identyfikacji użytkownika TACACS w protokole Telnet) 930 Telnet Terminal Type Option (Opcja typu terminala w protokole Telnet) 946 Telnet Terminal Location Number Option (Opcja numeru położenia terminala w protokole Telnet) 959 File Transfer Protocol (Protokół FTP) 1041 Telnet 3270 Regime Option (Opcja trybów 3270 w protokole Telnet) Y. Rekhter. 01.01.1988. (Format: TXT=11 608 bajtów) (Status: propozycja standardu)

’

428

TCP/lP. SZKOŁA PROGRAMOWANIA

1043 Telnet Data Entry Terminal option: DODIIS Implementation (Opcja terminala wprowadzania danych w protokole Telnet: implementacja DODIIS). A. Yasuda i T. Thompson. 01.02.1988. (Format: TXT=59 478 bajtów) (uaktualnia RFC0732) (Status: propozycja standardu) 1053 Telnet X.3 PAD Option (Opcja Telnet X.3 PAD). S. Levy i T. Jacobson. 01.04.1988. (Format: TXT=48 952 bajty) (Status: propozycja standardu) 1073 Telnet Window Size Option (Opcja wielkości okna w protokole Telnet). D. Waitzman. 01.10.1988. (Format: TXT=7 639 bajtów) (Status: propozycja standardu) 1079 Telnet Terminal Speed Option (Opcja szybkości terminala w protokole Telnet). C. L. Hedrick. 01.10.1988. (Format: TXT=4 942 bajty) (Status: propozycja standardu) 1080 Telnet Remote Flow Control Option (Opcja zdalnej kontroli przepływu w protokole Telnet). C. L. Hedrick. 01.11.1099. (Format: TXT=6 688 bajtów) (Zastąpiony przez RFC1372) (Status: nieznany) 1091 Telnet Terminal-type Option (Opcja typu terminala w protokole Telnet). J. VanBokkelen. 01.02.1989. (Format: TXT=13 439 bajtów) (zastąpił RFC0930) (Status: propozycja standardu) 1096 Telnet X Display Location Option (Opcja położenia wyświetlacza X w protokole Telnet). G. A. Marcy. 01.03.1989. (Format: TXT=4 634 bajty) (Status: propozycja standardu) 1097 Telnet Subliminal-Message option (Opcja komunikatów podprogowych iu protokole Telnet). B. Miller. 01.04.1989. (Format: TXT=5 490 bajtów) (Status: nieznany) 1116 Telnet Linemode Option (Opcja trybu wierszowego w protokole Telnet). D. A. Borman. 01.08.1989. (Format: TXT=47 473 bajty) (Zastąpiony przez RFC1184) (Status: propozycja standardu) 1143 The Q Method of Implementing TELNET Option Negotiation (Metoda Q implementacji negocjacji opcji w protokole Telnet). D. J. Bernstein. 01.02.1990. (Format: TXT=23 331 bajtów) (Status: eksperymentalny) 1184 Telnet Linemode Option (Opcja trybu wierszowego w protokole Telnet). D. A. Borman. 01.10.1990. (Format: TXT=53 085 bajtów) (zastąpił RFC1116) (Status: wersja robocza standardu) 1205 5250 Telnet Interface (Interfejs 5250 w protokole Telnet). P. Chmielewski. 01.02.1991. (Format: TXT=27 170 bajtów) (Status: informacyjny)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

429

1372 Telnet Remote Flow Control Option (Opcja zdalnej kontroli przepływu 10 protokole Telnet). C. Hedrick, D. Borman. Październik 1992. (Format: TXT=11 098 bajtów) (zastąpił RFC1080) (Status: propozycja standardu) 1408 Telnet Environment Option (Opcja środowiska w protokole Telnet). D. Borman, Editor. Styczeń 1993. (Format: TXT=13 119 bajtów) (Zastąpiony przez RFC1571) (Status: historyczny) 1409 Telnet Authentication Option (Opcja uwierzytelnienia w protokole Telnet). D. Borman, Editor. Styczeń 1993. (Format: TXT=13 119 bajtów) (Zastąpiony przez RFC1416) (Status: eksperymentalny) 1411 Telnet Authentication: Kerberos Version 4 (Uwierzytelnienie w protokole Telnet: Kerberos wersja 4). D. Borman, Editor. Styczeń 1993. (Format: TXT=7 967 bajtów) (Status: eksperymentalny) 1412 Telnet Authentication: SPX (Uwierzytelnienie w protokole Telnet: SPX ). K. Alagappan. Styczeń 1993. (Format: TXT=6 952 bajty) (Status: eksperymentalny) 1416 Telnet Authentication Option (Opcja uwierzytelnienia w protokole Telnet). D. Borman, Editor. Luty 1993. (Format: TXT=13 270 bajtów) (zastąpił RFC1409) (Status: eksperymentalny) 1571 Telnet Environment Option Interoperability Issues (Zagadnienia współdziałania opcji środowiska w protokole Telnet). D. Borman. Styczeń 1994. (Format: TXT=8 117 bajtów) (uaktualnia RFC1408) (Status: informacyjny) 1572 Telnet Environment Option (Opcja środowiska w protokole Telnet). S. Alexander. Styczeń 1994. (Format: TXT=14 676 bajtów) (Status: propozycja standardu) 1576 TN3270 Current Practices (Bieżące praktyki dotyczące TN3270). J. Penner. Styczeń 1994. (Format: TXT=24 477 bajtów) (Status: informacyjny) 1646 TN3270 Extensions for Luname and Printer Selection (Rozszerzenia TN3270 w zakresie wyboru nazwy i drukarki). C. Graves, T. Butts i M. Angel. Lipiec 1994. (Format: TXT=27 564 bajty) (Status: informacyjny) 1647 TN3270 Enhancements (Rozszerzenia TN3270). B. Kelly. Lipiec 1994. (Format: TXT=84 420 bajtów) (zastąpione przez RFC2355) (Status: propozycja standardu) 1921 TNVIP Protocol (Protokół TNVIP ). J. Dujonc. Marzec 1996. (Format: TXT=57 475 bajtów) (Status: informacyjny)

430

TCP/IP. SZKOŁA PROGRAMOWANIA

2066 TELNET CHARSET Option (Opcja zestawu znaków w protokole Telnet). R. Gellens. Styczeń 1997. (Format: TXT=26 088 bajtów) (Status: eksperymentalny) 2217 Telnet Com Port Control Option (Opcja kontroli portu com w protokole Telnet). G. Clark. Październik 1997. (Format: TXT=31 664 bajty) (Status: eksperymentalny) 2355 TN3270 Enhancements (Rozszerzenia TN3270). B. Kelly. Czerwiec 1998. (Format: TXT=89 394 bajty) (zastąpił RFC1647) (Status: wersja robocza standardu)

Rozdział 12. Protokół Przesyłu Plików (FTP) 133 File Transfer and Recovery (Przesyłanie i pobieranie plików) 141

Comments on RFC 114): A File Transfer Protocol ((Komentarze do RFC 114: protokół FTP)

238

Comments on DTP and FTP Proposals (Komentarze na temat propozycji DTP i FTP)

250

Some Thoughts on File Transfer (Przemyślenia na temat transferu plików)

269

Some Experience with File Transfer (Doświadczenia z transferem plików)

281

Suggested Addition to File Transfer Protocol (Sugerowane dodatki do protokołu FTP)

294 The Use of "Set Data Type" Transaction in File Transfer Protocol (Wykorzystanie transakcji „Set data type" w protokole FTP) 310 Another Look at Data and File Transfer Protocols (Inne spojrzenie na protokoły transferu danych i plików (DTP, FTP) 385 Comments on the File Transfer Protocol (Komentarze na temat protokołu FTP) 412 User FTP Documentation (Dokumentacja użytkowiiika FTP) 413 File Transfer Protocol (FTP) Status and Further Comments (Status protokołu FTP i dalsze komentarze) 430

Comments on File Transfer Protocol (Komentarze na temat protokołu FTP)

438 FTP Server-Server Interaction (Interakcja serwer-serwer w FTP) 448

Print Files in FTP (Pliki druku w FTP

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

463

FTP Comments and Response to RFC 430 (Komentarze FTP oraz odpowiedź na RFC 430)

468

FTP Data Compression (Kompresja danych w FTP)

478

FTP Server-Server Interaction — II (Interakcja serwer-senoer w FTP — II)

479

Use of the FTP by the NIC Journal (Wykorzystanie FTP przez NIC Journal)

480

Host-dependent FTP Parameters (Parametiy FTP zależne od hosta)

486

Data Transfer Revisited (Ponownie o transferze danych)

431

487 Free File Transfer (Swobodny transfer plików) 501

Un-muddling "Free File Transfer" (Swobodny transfer plikóiu)

505 Two Solutions to a File Transfer Access Problem (Dwa rozwiązania problemu dostępu w transferze plików) 506

FTP Command Naming Problem (Problem nazewnictwa poleceń w FTP)

520

Memo to FTP Group: Proposal for File Access Protocol (Notatka dla grupy FTP: propozycja protokołu dostępu do plików)

532

UCSD-CC Server-FTP Facility (Serwer FTP centrum komputerowego UCSD-CC)

535

Comments on File Access Protocol (Komentarze na temat protokołu dostępu do plików)

571

Tenex FTP Problem (Problem z implementacją Tenex protokołu FTP)

607

Comments on the File Transfer Protocol (Komentarze na temat protokołu FTP)

614

Response to RFC 607: "Comments on the File Transfer Protocol" (Odpowiedź na RFC 607: „Komentarze na temat protokołu FTP")

624

Comments on the File Transfer Protocol (Komentarze na temat protokołu FTP)

630

FTP Error Code Usage for More Reliable Mail Service (Korzystanie z kodu błędów FTP dla otrzymania bardziej niezawodnych usług pocztowych)

640 Revised FTP Reply Codes (Zmienione kody odpowiedzi FTP) 691

One More Tiy on the FTP (Jeszcze jedno podejście do FTP)

697

CWD Command of FTP (Polecenie CWD w FTP)

737 FTP Extension: XSEN (Rozszerzenie FTP: XSEN) 743 FTP Extension: XRSO/XRCP (Rozszerzenie FTP: XRSO/XRCP)

1 432

TCP/IP. SZKOŁA PROGRAMOWANIA

775 Directory-oriented FTP Commands (Polecenia FTP dotyczące katalogów) 949 FTP Unique-named Store Command (Polecenie zachowania pod unikatową nazwą w FTP) 1415 FTP-FTAM Gateway Specification (Specyfikacje bramy FTP-FTAM). J. Mindel i R. Slaski. Styczeń 1993. (Format: TXT=128 261 bajtów) (Status: propozycja standardu) 1440 SIFT/UFT: Sender-initiated/Unsolicited File Transfer (SIFT/UFT: Inicjowany przez nadawcę/niechciany transfer plikóiu). R. Troth. Lipiec 1993. (Format: TXT=17 366 bajtów) (Status: eksperymentalny) 1545 FTP Operations Over Big Address Records (FOOBAR) (Działania FTP względem rekordów o dużych adresach). D. Piscitello. Listopad 1993. (Format: TXT=8 985 bajtów) (Zastąpiony przez RFC1639) (Status: eksperymentalny) 1579 Firewall-friendly FTP (FTP przyjazne dla ścian ogniowych). S. Bellovin. Luty 1994. (Format: TXT=8 806 bajtów) (Status: informacyjny) 1635 How to Use Anonymous FTP. P. Deutsch (Jak korzystać z anonimowego FTP). A. Emtage i A. Marine. Maj 1994. (Format: TXT=27 259 bajtów) (także FY10024) (Status: informacyjny) 1639 FTP Operations Over Big Address Records (FOOBAR) (Działania FTP względem rekordów o dużych adresach). D. Piscitello. Czerwiec 1994. (Format: TXT=10 055 bajtów) (zastąpi! RFC1545) (Status: eksperymentalny) 2204 ODETTE File Transfer Protocol (Protokół ODETTE FTP). D. Nash. Wrzesień 1997. (Format: TXT=151 857 bajtów) (Status: informacyjny) 2228 FTP Security Extensions (Rozszerzenia bezpieczeństiua FTP). M. Horowitz, S. Lunt. Październik 1997. (Format: TXT=58 733 bajty) (uaktualnia RFC0959) (Status: propozycja standardu) 2389 Feature Negotiation Mechanism for the File Transfer Protocol (Mechanizm negocjowania cech dla protokołu FTP). P. Hethmon i R. Elz. Sierpień 1998. (Format: TXT=18 536 bajtów) (także RFC0959) (Status: propozycja standardu) 2428 FTP Extensions for IPv6 and NATs. M (Rozszerzenia FTP dla IPv6 i NAT). Allman, S. Ostermann i C. Metz. Wrzesień 1998. (Format: TXT=16 028 bajtów) (Status: propozycja standardu) 2577 FTP Security Considerations (Zagadnienia bezpieczeństiua FTP). M. Allman i S. Ostermann. Maj 1999. (Format: TXT=17 870 bajtów) (Status: informacyjny) 2640 Internationalization of File Transfer Protocol (Umiędzynarodowienie protokołu FTP)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

433

Rozdział 13. Prosty Protokół Przesyłania Poczty Elektronicznej (SMTP) 196

Revision of the Mail Box Protocol (Zmiana protokołu skrzynki pocztoiuej)

221

Revision

of the Mail Box Protocol(Zmiana protokołu skrzynki pocztoiuej)

224

Revision

of the

Mail Box Protocol(Zmiana protokołu skrzynki pocztowej)

278

Revision

of the

Mail Box Protocol(Zmiana protokołu skrzynki pocztoiuej)

333

Proposed Experiment with a Message Switching Protocol (Proponowany eksperyment z protokołem przełączania wiadomości)

458 Mail Retrieval via FTP (Pobieranie poczty za pośrednictwem FTP) 475

FTP and Network Mail System (FTP i sieciozuy system pocztowy)

491

What is "Free"? (Co znaczy określenie „wolny"?)

498

On Mail Service to CCN (O usłudze pocztowej w CCN)

524 Thoughts on the Mail Protocol Proposed in RFC 524 (Przemyślenia na temat protokołu pocztowego zaproponowanego w RFC 524) 539 Thoughts on the Mail Protocol Proposed in RFC 524 (Przemyślenia na temat protokołu pocztowego zaproponowanego w RFC 524) 555

Responses to Critiques of the Proposed Mail Protocol (Odpowiedź na krytykę proponowanego protokołu pocztowego)

561

Standardized Network Mail Headers (Standaryzowane sieciowe nagłówki poczty)

574 Announcement of a Mail Facility at UCSB (Ogłoszenie na temat możliwości obsługi poczty w UCSB) 577 Mail Priority (Priorytet poczty) 644

On the Problem of Signature Authentification for Network Mail (O problemie uwierzytelniania podpisu w poczcie sieciowej)

680 Message Transmission Protocol (Protokół transmisji wiadomości) 706

On the Junk Mail Problem (O problemie śmieci)

720 Address Specification Syntax for Network Mail (Składnia specyfikacji adresu w poczcie sieciowej)

434

TCP/IP. SZKOŁA PROGRAMOWANIA

724 Proposed Official Standard for the Format of ARPA Network Text Messages (Proponowany oficjalny standard formatu wiadomości tekstowych w sieci ARPA) 732 Standard for the Format of ARPA Network Text Messages (Standard formatu wiadomości tekstowych sieci ARPA) 744 MARS — a Message Archiving and Retrieval Service (MARS ■ — Usługa archiwizacji i pobierania wiadomości) 751

Survey of FTP mail and MLFL (Zebrane informacje na temat poczty FTP i MLF1)

753 Internet Message Protocol (Internetowy protokół komunikatów) 754 Out-of-net Host Addresses for Mail (Adresy hostów poza siecią na potrzeby poczty) 757 Suggested Solution to the Naming, Addressing, and Delivery Problem for ARPANET Message System (Sugerowane rozwiązanie zagadnień nazewnictwa, adresowania i dostarczania w systemie komunikatów ARPANET) 763 Role Mailboxes (Skrzynki pocztowe o różnej roli) 771 Mail Transition Plan (Plan przekształcenia poczty) 772 Mail Transfer Protocol (Protokół transferu poczty) 780 Mail Transfer Protocol (Protokół transferu poczty) 784 Mail Transfer Protocol: IS ITOPS20 Implementation (Protokół transferu poczty: Implementacja ISI TOPS20) 785 Mail Transfer Protocol: ISI TOPS20 File Definitions (Protokół transferu poczty: Definicje plików ISI TOPS20) 786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL Interface (Protokół transferu poczty: Interfejs ISI TOPS20 MTP-NIMAIL) 788

Simple Mail Transfer Protocol (Protokół SMTP)

806 Proposed Federal Information Processing Standard: Specification for Message Format for Computer-based Message Systems (Propozycja federalnego standardu przetwarzania informacji: specyfikacje formatu wiadomości dla systemu wiadomości opartego na komputerach) 821

Simple Mail Transfer Protocol (Protokół SMTP)

822 Standard for the Format of ARPA Internal Text Messages (Standard formatu wewnętrznych wiadomości tekstowych dla ARPA) 841

Specification for Message Format for the Computer-based Message System (Specyfikacja formatu wiadomości dla systemu wiadomości opartego na komputerach)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

435

886

Propozycja standardu for Message Header Munging (Proponowany standard w przypadku błędów nagłówka komunikatu)

915

Network Mail Path Service (Usługa sieciowej ścieżki poczty)

918

Post Office Protocol: Version 2 (Protokół pocztowy: wersja 2)

934 Propozycja standardu for Message Encapsulation (Proponowany standard hermetyzacji wiadomości) 937 Post Office Protocol: Version 2 (Protokół pocztowy: wersja 2) 974 Mail Routing and the Domain System (Routing poczty i system domen) 975

UUCP Mail Interchange Format Standard (Standard formatu wymiany poczty UUCP)

976 Network News Transfer Protocol (Protokół sieciowego transferu wiadomości) 984

PCMAIL: A Distributed Mail System for Personal Computers (PCMAIL: Rozproszony system pocztowy dla komputerów osobistych)

987 Addendum to RFC 987: (Mapping Between X.400 and RFC-822) (Dodatek do RFC 987: mapowanie między X.400 a RFC-822) 993

PCMAIL: A Distributed Mail System for Personal Computers (PCMAIL: Rozproszony system pocztoiuy dla komputeróiu osobistych)

1026 Addendum to RFC 987:(Mapping Between X.400 and RFC-822) (Dodatek do RFC 987: mapowanie między X.400 a RFC-822). S. E. Kille. 01.09.1987. (Format: TXT=7 117 bajtów) (Zastąpiony przez RFC1327, RFC1495, RFC2156) (uaktualnia RFC0987) (Uaktualniony przez RFC1138, RFC1148) (Status: nieznany) 1047 Duplicate Messages and SMTP (Powielone wiadomości i SMTP). C. Partridge. 01.02.1998. (Format: TXT=15 423 bajty) (Zastąpiony przezRFC1084, RFC1395, RFC1497, RFC1533) (Status: nieznany) 1049 Content-type Header Field for Internet Messages (Pole typu zawartości w nagłówku wiadomości internetowych). M. A. Sirbu. 01.03.1988. (Format: TXT=51 540 bajtów) (Zastąpiony przez RFC1057) (Status: historyczny) 1056 PCMAIL: A Distributed Mail System for Personal Computers (PCMAIL: Rozproszony system pocztowy dla komputerów osobistych). M. L. Lambert. 01.06.1988. (Format: TXT=12 911 bajtów) (Status: standard)

436

TCP/IP. SZKOŁA PROGRAMOWANIA

1064 Interactive Mail Access Protocol: Version 2 (Protokół dostępu do interaktywnej poczty: wersja 2). M. R. Crispin. 01.07.1988. (Format: TXT=57 813 bajtów) (Zastąpiony przez RFC1176, RFC1203) (Status: nieznany) 1081 Post Office Protocol: Version 3. M (Protokół pocztowy: wersja 3). T. Rose. 01.11.1988. (Format: TXT=37 009 bajtów) (Zastąpiony przez RFC1225) (Status: nieznany) 1082 Post Office Protocol: Version 3. Extended Service Offerings (Protokół pocztowy: wersja 3. Propozycja rozszerzenia usług). M. T. Rose. 01.11.1988. (Format: TXT=25 423 bajty) (Zastąpiony przez RFC1225) (Status: nieznany) 1090 SMTP on X.25 (SMTP na X.25). R. Ullmann. 01.02.1989. (Format: TXT=6 141 bajtów) (Status: nieznany) 1113 Privacy enhancement for Internet Electronic Mail: Part I — Message Encipherment and Authentication Procedures (Rozszerzenia prywatności w internetowej poczcie elektronicznej: Część I — Szyfrowanie wiadomości i procedwy uwierzytelniania). J. Linn. 01.08.1989. (Format: TXT=89 293 bajty) (zastąpił RFC0989, RFC1040) (Zastąpiony przez RFC1421) (Status: historyczny) 1114 Privacy Enhancement for Internet Electronic Mail: Part II Certificate-based Key management (Rozszerzenia prywatności w internetowej poczcie elektronicznej: C zęśćII— Zarządzanie kluczami oparte na certyfikatach). S. T. Kent, J. Linn. 01.08.1989. (Format: TXT=69 661 bajtów) (zastąpiony przez RFC1422) (Status: historyczny) 1115 Privacy Enhancement for Internet electronic mail: Part III — Algorithms, Modes, and Identifiers (Rozszerzenia prywatności w internetowej poczcie elektronicznej: Część III — Algorytmy, tryby i identyfikatory). J. Linn. 01.08.1989. (Format: TXT=18 226 bajtów) (Zastąpiony przez RFC1422) (Status: historyczny) 1137 Mapping Between Full RFC 822 and RFC 822 with Restricted Encoding (Mapoioanie pomiędzy pełnym RFC 822 a RFC 822 z ogi'aniczonym szyfrowaniem). S. Kille. 01.12.1989. (Format: TXT= 6 266 bajtów) (uaktualnia RFC0976) (Status: historyczny) 1138 Mapping Between X.400(1988)/ISO 10021 and RFC 822 (Mapowanie pomiędzy X.400(1988)/ISO 10021 a RFC 822). S. E. Kille. 01.12.1989. (Format: TXT=191 029 bajtów) (Zastąpiony przez RFC1327, RFC1495, RFC2156) (uaktualnia RFC0822, RFC0987, RFC1026) (Uaktualniony przez RFC1148) (Status: eksperymentalny) 1148 Mapping Between X.400 (1988)/ISO 10021 and RFC 822 (Mapowanie pomiędzy XAOO(1988)/ISO 10021 a RFC 822). S. E. Kille.

Dodatek A - DOKUMENTY RFC WG ROZDZIAŁÓW

437

1153 Digest Message Format (Format skondensowanych wiadomości). F. J. Wancho. 01.04.1990. (Format: TXT=6 632 bajty) (Status: eksperymentalny) 1154 Encoding Header Message Field for Internet Messages (Szyfrowanie pola nagłówka wiadomości w wiadomościach internetowych). D. Robinson i R. Ullmann. 01.04.1990. (Format: TXT=12 214 bajtów) (Zastąpiony przez RFC1505) (Status: eksperymentalny) 1168 Intermail and Commercial Mail Relay Services (Usługi wymiany poczty i komercyjnego przekazywania poczty). A. Westine, A. L. DeSchon, J. Postel, C. E. Ward. 01.07.1990. (Format: TXT=149 816 bajtów) (Status: informacyjny) 1176 Interactive Mail Access Protocol: Version 2 (Protokół interakcyjnego dostępu do poczty: wersja 2). M. R. Crispin. 01.08.1990. (Format: TXT=67 330 bajtów) (zastąpił RFC1064) (Status: eksperymentalny) 1203 Interactive Mail Access Protocol: Version 3 (Protokół interakcyjnego dostępu do poczty: wersja 3). J. Rice. 01.02.1991. (Format: TXT=123 325 bajtów) (zastąpił RFC1064) (Status: historyczny) 1204 Message Posting Protocol (MPP) (Protokół wysyłania wiadomości — MPP). S. Yeh, D. Lee. 01.02.1991. (Format: TXT=11 371 bajtów) (Status: eksperymentalny) 1211 Problems With Maintenance of Large Mailing Lists (Problemy z utrzymaniem dużych list pocztowych). A. Westine, J. Postel. 01.03.1991. (Format: TXT = 96 167 bajtów) (Status: informacyjny) 1225 Post Office Protocol: Version 3 (Protokół pocztowy: wersja 3). M. T. Rose. 01.05.1991. (Format: TXT=37 340 bajtów) (zastąpił RFC1081) (Zastąpiony przez RFC1460) (Status: wersja robocza standardu) 1327 Mapping Between X.400(1988)/ISO 10021 and RFC 822 (Mapowanie pomiędzy X.400(1988)/ISO 10021 a RFC 822). S. Hardcatle-Kile. Maj 1992. (Format: TXT=228 598 bajtów) (zastąpił RFC987, RFC1026, RFC1138, RFC1148) (Zastąpiony przez RFC1495, RFC2156) (uaktualnia RFC0822, rfc0822) (Status: propozycja standardu) 1339 Remote Mail Checking Protocol (Protokół zdalnego sprawdzania poczty). S. Dorner i P. Resnick. Czerwiec 1992. (Format: TXT=13 115 bajtów) (Status: eksperymentalny) 1341 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (Wielozadanioive rozszerzenia poczty internetowej — MIME: Część pierwsza: Format treści wiadomości). N. Borenstein i N. Freed. Czerwiec 1992. (Format: TXT=211117, PS=347 082 bajty) (Zastąpiony przez RFC1521) (Status: propozycja standardu)

438

TCP/IP. SZKOŁA PROGRAMOWANIA

1342 MIME (Multipurpose Internet Mail Extensions), Part Three (MIME część trzecia). K. Moore. Czerwiec 1992. (Format: TXT=15 845 bajtów) (Zastąpiony przez RFC1522) (Status: informacyjny) 1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information (Mechanizm konfiguracji agenta użytkownika dla informacji o formacie poczty multimedialnej). N. Borenstein. Czerwiec 1992. (Format: TXT=29295, PS=59 978 bajtów) (Status: informacyjny) 1344 Implications of MIME for Internet Gateways (Implikacje MIME dla bram internetowych). N. Borenstein. Czerwiec 1992. (Format: TXT=25872, PS=51 812 bajtów) (Status: informacyjny) 1357 A Format for E-mailing Bibliographic Records (Format wysyłania pocztą rekordów bibliogmficznych). D. Cohen. Lipiec 1992. (Format: TXT=25 021 bajtów) (Zastąpiony przezRFC1807) (Status: informacyjny) 1405 Mapping Between X.400 (1984/1988) and Mail-11 (DECnet mail) (Mapowanie pomiędzy X.400(1984/1988) a Mail-11 — poczta DECnet). C. Allocchio. Styczeń 1993. (Format: TXT=33 885 bajtów) (Zastąpiony przez RFC2162) (Status: eksperymentalny) 1425 SMTP Service Extensions (Rozszerzenia usług SMTP). J. Klensin, WG Chair, N. Freed, Editor, M. Rose, E. Stefferud & D. Crocker. Luty 1993. (Format: TXT=20 932 bajty) (Zastąpiony przez RFC1651) (Status: propozycja standardu) 1426 SMTP Service Extension for 8bit-MIMEtransport (Rozszerzenie usług SMTP dotyczące transportu ośmiobitoiuego MIME). J. Klenisin; W. G. Chan; N. Freed, red.; M. Rose; E. Stefferud i D. Crocker. Luty 1993. (Format: T X T = 1 161 bajtów) (Zastąpiony przez RFC1652) (Status: propozycja standardu) 1427 SMTP Service Extension for Message Size Declaration (Rozszerzenie usług SMTP dotyczące deklaracji wielkości wiadomości). J. Klensin; W. G. Chair; N. Freed, red.; K. Moore. Luty 1993. (Format: TXT=17 856 bajtów) (Zastąpiony przez RFC1653) (Status: propozycja standardu) 1428 Transition of Internet Mail from Just-Send-8 to 8-bit SMTP/MIME (Przejście poczty internetowej z systemu Just-Send-8 na ośmiobitowy SMTP/MIME). G. Vaudreuil. Luty 1993. (Format: TXT=12 064 bajty)(Status: informacyjny) 1460 Post Office Protocol, Version 3 (Protokół pocztowy: wersja 3). M. Rose. Czerwiec 1993. (Format: TXT=38 827 bajtów) (zastąpił RFC1225) (Zastąpiony przez RFC1725) 1494 Equivalences Between 1988 X.400 and RFC-822 Message Bodies (Równoważność między zawartością 1988 X.400 a RFC-822). H. Alvestrand & S.

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

439

Thompson. Sierpień 1993. (Format: TXT=37 273 bajty) (Status: propozycja standardu) 1495 Mapping Between X.400 and RFC-822 Message Bodies (Mapowanie pomiędzy zawartością X.400/88 a RFC-822). H. Alvestrand, S. Kille, R. Miles, M. Rose, i S. Thompson. Sierpień 1993. (Format: TXT=20 071 bajtów) (zastąpił RFC987, RFC987, RFC1026, RFC1138, RFC1148, RFC1327) (Zastąpiony przez RFC2156) (Status: propozycja standardu) 1496 Rules for Downgrading Messages from X.400/88 to X.400/84 when MIME Content Types are Present in the Messages (Zasady konwersji wiadomości z X.400/88 na X.400/84, gdy jest w nich obecna zawartość typu MIME). H. Alvestrand, J. Romaguera i K. Jordan. Sierpień 1993. (Format: TXT=8 411 bajtów) (Status: propozycja standardu) 1502 X.400 Use of Extended Character Sets (Użyioanie rozszerzonego zestawu znaków w X.400). H. Alvestrand. Sierpień 1993. (Format: TXT=27 976 bajtów) (Status: propozycja standardu) 1505 Encoding Pleader Message Field for Internet Messages (Szyfrowanie pola nagłówka wiadomości w wiadomościach internetowych). A. Costanzo, D. Robinson i R. Ullmann. Sierpień 1993. (Format: TXT=63 796 bajtów) (zastąpił RFC1154) (Status: eksperymentalny) 1506 A Tutorial on Gatewaying Between X.400 and Internet Mail (Podręcznik na temat bramkowania pomiędzy X.400 a pocztą internetową). J. Houttuin. Wrzesień 1993. (Format: TXT=85 550 bajtów) (Status: informacyjny) 1521 Multipurpose Internet Mail Extensions (MIME) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies (MIME część pierwsza: Mechanizmy określania i opisu formatu zawartości wiadomości internetowej). N. Borenstein i N. Freed. Wrzesień 1993. (Format: TX T =187424, PS=393 670 bajtów) (zastąpił RFC1341) (Zastąpiony przezRFC2045, RFC2046, RFC2047, RFC2048, RFC2049, BCP0013) (Uaktualniony przez RFC1590) (Status: wersja robocza standardu) 1522 MIME (Multipurpose Internet Mail Extensions), Part Two: Message Header Extensions for Non-ASCII Text (MIME część druga: Rozszerzenia nagłówka wiadomości o tekst nie-ASCII). K. Moore. Wrzesień 1993. (Format: TXT=22 502 bajty) (zastąpił RFC1342) (Zastąpiony przez RFC2045, RFC2046, RFC2047, RFC2048, RFC2049, BCP0013) (Status: wersja robocza standardu) 1523 The Text-enriched MIME Content Type (Typ zawartości MIME o wzbogaconym tekście). N. Borenstein. Wrzesień 1993. (Format: TXT=32 691 bajtów) (Zastąpiony przez RFC1563, RFC1896) (Status: informacyjny)

T 440

TCP/IP. SZKOŁA PROGRAMOWANIA

1524 A User Agent Configuration Mechanism for Multimedia Mail Format Information (Mechanizm konfiguracji agenta użytkownika dla informacji 0 formacie poczty multimedialnej). N. Borenstein. Wrzesień 1993. (Format: TXT=26 464 bajty) (Status: informacyjny) 1544 The Content-MD5 Header Field (Pole nagłówka zawierające MD5). M. Rose. Listopad 1993. (Format: TXT=6 478 bajtów) (Zastąpiony przez RFC1864) (Status: propozycja standardu) 1556 Handling of Bidirectional Texts in MIME (Obsługa dwukierunkowych tekstów w MIME). H. Nussbacher i Y. Bourvine. Grudzień 1993. (Format: TXT=9 273 bajty) (Status: informacyjny) 1563 The Text-enriched MIME Content Type (Typ zawartości MIME o wzbogaconym tekście). N. Borenstein. Styczeń 1994. (Format: TXT=32913, PS=73 543 bajty) (zastąpił RFC1523) (Zastąpiony przez RFC1896) (Status: informacyjny) 1590 Media Type Registration Procedure (Procedura rejestracji typu medióio). J. Postel. Marzec 1994. (Format: TXT=13 044 bajty) (Zastąpiony przez RFC2045, RFC2046, RFC2047, RFC2048, RFC2049, BCP0013) (uaktualnia RFC1521) (Status: informacyjny) 1615 Migrating Form X.400(84)to X.400(88) (Formularz migracji z X.400(84) do X.400(88)). J. Houttuin i J. Craigie. Maj 1994. (Format: TXT=39 693 bajty) (Status: informacyjny) 1616 X.400(1988)for the Academic and Research Community in Europe. RARE WG-MSG Task Force 88 (X.400(1988) dla europejskiego środowiska naukowo badawczego. Grupa robocza RARE WG-MSG). E. Huizer i J. Romaguera, Editors. Maj 1994. (Format: TXT=107 432 bajty) (Status: informacyjny) 1641 Using Unicode With MIME (Używanie Unicode w MIME). D. Goldsmith 1 M. Davis. Lipiec 1994. (Format: TXT=11258, PS=20 451 bajtów) (Status: eksperymentalny) 1642 UTF-7 A Mail-safe Transformation Format of Unicode (UTF-7 — odpowiedni dla poczty format przekształcenia Unicode). D. Goldsmith i M. Davis. Lipiec 1994. (Format: TXT=27770, PS=50 907 bajtów) (Zastąpiony przez RFC2152) (Status: eksperymentalny) 1648 Postmaster Convention for X.400 Operations (Konwencja kierowania pocztą dla działań X.400). A. Cargille. Lipiec 1994. (Format: TXT=8 761 bajtów) (Status: propozycja standardu)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

441

1649 Operational Requirements for X.400 Management Domain in the GO-MHS Community (Wymagania operacyjne dla zarządzania domeną X.400 w społeczności GO-MHS). R. Hagens i A. Hansen. Lipiec 1994. (Format: TXT=23 138 bajtów) (Status: informacyjny) 1651 SMTP Service Extensions (Rozszerzenia usług SMTP). Klensin, N. Freed, M. Rose, E. Stefferud i D. Crocker. Lipiec 1994. (Format: TXT=22 153 bajty) (zastąpił RFC1425) (Zastąpiony przez RFC1869, STD0010) (Status: wersja robocza standardu) 1652 SMTP Service Extension for 8-bit MIME Transport (Rozszerzenie usług SMTP dotyczące transportu ośmiobitowego MIME). Klensin, N. Freed, M. Rose, E. Stefferud i D. Crocker. Lipiec 1994. (Format: TXT=11 842 bajty) (zastąpił RFC1426) (Status: wersja robocza standardu) 1653 SMTP Service Extension for Message Size Declaration (Rozszerzenie usług SMTP dotyczące deklaracji luielkości wiadomości). J. Klenisn, N. Freed i K. Moore. Lipiec 1994. (Format: TXT=17 883 bajty) (zastąpił RFC1427) (zastąpiony przez RFC1870, STD0011) (także STD0011) (Status: wersja robocza standardu) 1685 Writing X.400 O/R Names (Pisownia nazw O/R w X.400). H. Alvestrand. Sierpień 1994. (Format: TXT=21 242 bajty) (także RTR0012) (Status: informacyjny) 1711 Classifications in E-mail Routing (Klasyfikacja w routingu poczty elektronicznej). J. Houttuin. Październik 1994. (Format: TXT=47 584 bajty) (Status: informacyjny) 1725 Post Office Protocol, Version 3 (Protokół pocztowy: wersja 3). J. Meyers i M. Rose. Listopad 1994. (Format: TXT=35 058 bajtów) (zastąpił RFC1460) (Zastąpiony przez RFC1939, STD0053) (Status: wersja robocza standardu) 1730 Internet Message Access Protocol, Version 4 (Protokół dostępu do wiadomości internetowych, wersja 4). M. Crispin. Grudzień 1994. (Format: TXT=156 660 bajtów) (Zastąpiony przez RFC2060, RFC2061) (Status: propozycja standardu) 1731 IMAP4 Authentication Mechanisms (Mechanizm uwierzytelnienia IMAP4). ]. Myers. Grudzień 1994. (Format: TXT=11 433 bajty) (Status: propozycja standardu) 1732 IMAP4 COMPATABILITY WITH IMPAP2 AND IMPA2BIS (Kojnpatybihiość IMAP4 z IMAP2 i IMAP2BIS). M. Crispin. Grudzień 1994. (Format: TXT=9 276 bajtów) (Status: informacyjny) 1733 DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4 (Rozproszone modele poczty elektronicznej w IMAP4). M. Crispin. Grudzień 1994. (Format: TXT=6 205 bajtów) (Status: informacyjny)

442

TCP/IP. SZKOŁA PROGRAMOWANIA

1734 POP3 Authentication command (Polecenie uwierzytelnienia POP3). J. Myers. Grudzień 1994. (Format: TXT=8 499 bajtów) (Status: propozycja standardu) 1740 MIME Encapsulation of Macintosh Files — MacMIME (Hermetyzacja plików komputerów Macintosh 10 MIME — MacMIME). P. Falstrom, D. Crocker i E. Fair. Grudzień 1994. (Format: TXT=31 297 bajtów) (Status: propozycja standardu) 1741 MIME Content-type for BinHex Encoded Files (Typ zawartości MIME dla plików w kodowaniu BinHex). P. Faltstrom, D. Crocker i E. Fair. Grudzień 1994. (Format: TXT=10 155 bajtów) (Status: informacyjny) 1767 MIME Encapsulation of EDI Objects (Hermetyzacja obiektów EDI w MIME). D. Crocker. Marzec 1995. (Format: TXT=15 293 bajty) (Status: propozycja standardu) 1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header (Przekazywanie informacji prezentacyjnych w wiadomościach internetowych: Nagłózuek dyspozycji zawartości). R. Troost i S. Dorner. Czerwiec 1995. (Format: TXT=15 548 bajtów) 1807 A Format for Bibliographic Records (Format rekordów bibliograficznych). R. Lasher i D. Cohen. Czeiwiec 1995. (Format: TXT=29 417 bajtów) (zastąpił RFC1357) (Status: informacyjny) 1820 Multimedia E-mail (MIME) User Agent Checklist (Lista kontrolna agenta użytkownika poczty multimedialnej MIME). E. Huizer. Sierpień 1995. (Format: TXT=14 672 bajty) (Zastąpiony przez RFC1844) (Status: informacyjny) 1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages (Rozszerzenia usługi SMTP dla potrzeb transmisji dużych i binarnych wiadomości MIME). G. Vaudreuil. Sierpień 1995. (Format: TXT=16 555 bajtów) (Status: eksperymentalny) 1838 Use of an X.500/LDAP Directory to Support Mapping Between X.400 and RFC 822 Addresses (Wykorzystanie katalogu X.500/LDAP do obsługi mapowania pomiędzy adresami X.400 a RFC 822). S. Kille. Sierpień 1995. (Format: TXT=12 216 bajtów) (Zastąpiony przez RFC2164) (Status: eksperymentalny) 1844 Multimedia E-mail (MIME) User Agent Checklist (Lista kontrolna agenta użytkownika poczty multimedialnej MIME). E. Huizer. Sierpień 1995. (Format: TXT=15 072 bajty) (zastąpił RFC1820) (Status: informacyjny) 1845 SMTP Service Extension for Checkpoini/Restart (Rozszerzenie usługi SMTP dla potrzeb punktu kontrolnego/restartu). D. Crocker, N. Freed i A. Cargille. Wrzesień 1995. (Format: TXT=15 399 bajtów) (Status: eksperymentalny)

Dodatek A ° DOKUMENTY RFC WG ROZDZIAŁÓW

443

1846 SMTP 521 Reply Code. A. Durand i F. Dupont (Kod odpoioiedzi SMTP 521). Wrzesień 1995. (Format: TXT=6 558 bajtów) (Status: eksperymentalny) 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted (Zabezpieczone wiadomości wieloczęściowe MIME: wieloczęściowa/podpisana i wieloczęściowa/szyfrowana). J. Galvin, S. Murphy, S. Crocker i N. Freed. Październik 1995. (Format: TXT=23 679 bajtów) (Status: propozycja standardu) 1848 MIME Objects Security Services (Usługi bezpieczeństwa obiektów MIME). S. Crocker, N. Freed, J. Galvin i S. Murphy. Październik 1995. (Format: TXT=95 010 bajtów) (Status: propozycja standardu) 1854 SMTP Service Extension for Command Pipelining (Rozszerzenie usługi SMTP dla potrzeb potokowego przetwarzania poleceń). N. Freed. Październik 1995. (Format: TXT=14 097 bajtów) (Zastąpiony przez RFC2197) (Status: propozycja standardu) 1864 The Content-MD5 Header Field (Pole nagłówka zawierające MD5). J. Myers i M. Rose. Październik 1995. (Format: TXT=7 216 bajtów) 1869 SMTP Service Extensions (Rozszerzenia usług SMTP). J. Klensin, N. Freed, M. Rose, E. Stefferud i D. Crocker. Listopad 1995. (Format: TXT=23 299 bajtów) (Zastąpiony przez RFC1651) (także STD0010) (Status: standard) 1870 SMTP Service Extension for Message Size Declaration (Rozszerzenie usługi SMTP dla potrzeb deklaracji wielkości wiadomości). J. Klensin, N. Freed i K. Moore. Listopad 1995. (Format: TXT=18 226 bajtów) (zastąpił RFC1653) (także STD0010) (Status: standard) 1872 Tire MIME Multipart/Related Content-type (Typ zawartości MIME wieloczęściowy/ pozuiązany). E. Levinson. Grudzień 1995. (Format: TXT=15 565 bajtów) (Zastąpiony przez RFC2112) (Status: eksperymentalny) 1873 Message/External-Body Content-ID Access Type (Typ dostępu komunikat/ zewnętrzny — zawartość — ID). E. Levinson. Grudzień 1995. (Format: TXT=5 878 bajtów) (Status: eksperymentalny) 1891 SMTP Service Extension for Delivery Status Notifications (Rozszerzenie usługi SMTP dla potrzeb powiadomień o statusie dostarczenia). K. Moore. Styczeń 1996. (Format: TXT=65 192 bajty) (Status: propozycja standardu) 1892 The Multipart/Report Content-type for the Reporting of Mail System Administrative Messages (Typ zawartości wieloczęściowy/raport dla raportowania komunikatów administracyjnych systemu pocztowego). G. Vaudreuil. Styczeń 1996. (Format: TXT=7 800 bajtów) (Status: propozycja standardu)

444

TCP/IP. SZKOŁA PROGRAMOWANIA

1893 Enhanced Mail System Status Codes (Kody stanu rozszerzonego systemu pocztowego). G. Vaudreuil. Styczeń 1996. (Format: TXT=28 218 bajtów) (Status: propozycja standardu) 1894 An Extensible Message Format for Delivery Status Notifications (Rozszerzalny format wiadomości dla potrzeb powiadomień o statusie dostarczenia). K. Moore i G. Vaudreuil. Styczeń 1996. (Format: TXT=77 462 bajty) (Status: propozycja standardu) 1895 The Application/CALS-1840 Content-type (Typ zawartości aplikacja/CALS-1840). E. Levinson. Luty 1996. (Format: TXT=10 576 bajtów) (Status: informacyjny) 1896 The text/enriched MIME Content-type (Typ zawartości MIME tekst/wzbogacony). P. Resnick & A. Walker. Luty 1996. (Format: TXT=45926, PS=81 217bajtów) (zastąpił RFC1523, RFC1563) (Status: informacyjny) 1957 Some Observations on Implementations of the Post Office Protocol (POP3) (Uiuagi na temat implementacji protokołu pocztowego POP3). R. Nelson. Czerwiec 1996. (Format: TXT=2 325 bajtów) (uaktualnia RFC1939) (Status: informacyjny) 1985 SMTP Service Extension for Remote Message Queue Starting (Rozszerzenie usługi SMTP dla potrzeb zdalnego inicjowania kolejek wiadomości). J. De Winter. Sierpień 1996. (Format: TXT=14 815 bajtów) (Status: propozycja standardu) 2015 MIME Security with Pretty Good Privacy (PGP) (Bezpieczeństwo MIME z wykorzystaniem PGP). M. Elkins. Październik 1996. (Format: TXT=14 223 bajty) (Status: propozycja standardu) 2016 Uniform Resource Agents (URAs) ( Jednolite agenty zasobów — URA). L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan. Październik 1996. (Format: TXT=38 355 bajtów) (Status: eksperymentalny) 2033 Local Mail Transfer Protocol (Protokół transferu poczty lokalnej). J. Myers. Październik 1996. (Format: TXT=14 711 bajtów) (Status: informacyjny) 2034 SMTP Service Extension for Returning Enhanced Error Codes (Rozszerzenie usługi SMTP dla potrzeb zwracania rozszerzonych kodów błędów). N. Freed. Październik 1996. (Format: TXT=10 460 bajtów) (Status: propozycja standardu) 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (MIME część pierwsza: Format zawartości wiadomości internetowej). N. Freed & N. Borenstein. Listopad 1996. (Format: TXT=72 932 bajty) (zastąpił RFC1521, RFC1522, RFC15900) (Uaktualniony przez RFC2184, RFC2231) (Status: wersja robocza standardu)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

445

2046 Multipurpose Internet Mail Extensions (MIME), Part Two: Media Types (MIME część druga: Typy mediów). N. Freed i N. Borenstein. Listopad 1996. (Format: TXT=105 854 bajty) (zastąpił RFC1521, RFC1522, RFC1590) (Status: wersja robocza standardu) 2047 MIME (Multipurpose Internet Mail Extensions), Part Three: Message Header Extensions for Non-ASCII Text. (MIME część trzecia: Rozszerzenia nagłówka wiadomości dla tekstu nie-ASCII). K. Moore. Listopad 1996. (Format: TXT=33 262 bajty) (zastąpił RFC1521, RFC1522, RFC1590) (Uaktualniony przez RFC2184, RFC2231) (Status: Wersja robocza standardu) 2048 Multipurpose Internet Mail Extensions (MIME), Part Four: Registration Procedures (MIME część czwarta: Procedury rejestracji). N. Freed, J. Klensin i J. Postel. Listopad 1996. (Format: TXT=45 033 bajty) (zastąpił RFC1521, RFC1522, RFC1590) (także BCP0013) (Status: najlepsze obecne procedury) 2049 Multipurpose Internet Mail Extensions (MIME), Part Five: Conformance Criteria and Examples. (MIME część piąta: Kryteria zgodności i przykłady). N. Freed & N. Borenstein. Listopad 1996. (Format: TXT=51 207 bajtów) (zastąpił RFC1521, RFC1522, RFC1590) (Status: wersja robocza standardu) 2060 Internet Message Access Protocol, Version 4revl (Protokół IMAP, wersja 4revl). M. Crispin. Grudzień 1996. (Format: TXT=166 513 bajtów) (zastąpił RFC1730) (Status: propozycja standardu) 2061 IMPA4 Compatibility With IMAP2BIS (Kompatybilność IMP4 z IMAP2BIS). M. Crispin. Grudzień 1996. (Format: TXT=5 867 bajtów) (zastąpił RFC1730) (Status: informacyjny) 2062 Internet Message Access Protocol — Obsolete Syntax (Protokół IMAP — nieaktualna składnia). M. Crispin. Grudzień 1996. (Format: TXT=14 222 bajty) (Status: propozycja standardu) 2076 Common Internet Message Headers (Wspólne nagłówki komunikatów internetowych). J. Palmę. Luty 1997. (Format: TXT=47 639 bajtów) (Status: informacyjny) 2077 The Model Primary Content-type for Multipurpose Internet Mail Extensions (Model podstaiuozuego typu zawartości dla MIME). S. Nelson, C. Parks, Mitra. Styczeń 1997. (Format: TXT=30 158 bajtów) (Status: propozycja standardu) 2086 IMAP4 ACL Extension (Rozszerzenia IMAP4 ACL). J. Myers. Styczeń 1997. (Format: TXT=13 925 bajtów) (Status: propozycja standardu) 2087 IMAP4 QUOTA Extension (Rozszerzenia IMAP QUOTA). J. Myers. Styczeń 1997. (Format: TXT=8 524 bajty) (Status: propozycja standardu)

446

TCP/IP. SZKOŁA PROGRAMOWANIA

2088 IMAP4 Non-synchronizing literals (Niesynchonizujqce stałe 1MAP4). J. Myers. Styczeń 1997. (Format: TXT=4 052 bajty) (Status: propozycja standardu) 2095 IMAP/POP Authorize Extension for Simple Challenge/Response (Rozszerzenia autoryzacji IMAP/POP dla prostego wyzwania/odpowiedzi). J. Klensin, R. Catoe i P. Krumviede. Styczeń 1997. (Format: TXT=10 446 bajtów) (Zastąpiony przezRFC2195) (Status: propozycja standardu) 2110 MIME Encapsulation of Aggregate Documents Such As HTML (MHTML) (Hermetyzacja MIME dokumentów zagregowanych takich jak HTML). J. Palme i A. Hopmann. Marzec 1997. (Format: TXT=41 961 bajtów) (Status: propozycja standardu) 2112 The MIME Multipart/Related Content-type (Typ zawartości wieloczęściowy/ powiązany MIME). E. Levinson. Luty 1997. (Format: TXT=17 052 bajty) (zastąpił RFC1872) (Zastąpiony przez RFC2387) (Status: propozycja standardu) 2142 Mailbox Names for Common Services, Roles, and Functions (Nazwy skrzynek pocztozuych dla wspólnych usług, ról i funkcji). D. Crocker. Maj 1997. (Format: TXT=12 195 bajtów) (Status: propozycja standardu) 2152 UTF-7 A Mail-Safe Transformation Format of Unicode (UTF-7 — odpowiedni dla poczty format przekształcenia Unicode). D. Goldsmith, M. Davis. Maj 1997. (Format: TXT=28 065 bajtów) (zastąpił RFC1642) (Status: informacyjny) 2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME (MIXER: Mapowanie pomiędzy XA00 a RFC 822/MIME). S. Kille. Styczeń 1998. (Format: TXT=280 385 bajtów) (zastąpił RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495) (uaktualnia RFC0822) (Status: propozycja standarduS) 2157 Mapping between X.400 and RFC-822/MIME Message Bodies (Mapowanie pomiędzy zawartościami X.400 a RFC 822/MIME). H. Alvestrand. Styczeń 1998. (Format: TXT=92 554 bajty) (Status: propozycja standardu) 2158 X.400 Image Body Parts (Części zawartości obrazu X). H. Alvestrand. Styczeń 1998. (Format: TXT=5 547 bajtów) (Status: propozycja standardu) 2160 Carrying PostScript in X.400 and MIME (Przenoszenie postscriptu w X.400 i MIME). H. Alvestrand. Styczeń 1998. (Format: TXT=7 059 bajtów) (Status: propozycja standardu) 2161 A MIME Body Part for ODA. H. Alvestrand (Część zawartości MIME dla ODA). Styczeń 1998. (Format: TXT=8 009 bajtów) (Status: eksperymentalny)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

447

2162 M aXIM -ll — Mapping Between X.400/Internet Mail and Mail-11 Mail (M aXIM -ll — Mapowanie pomiędzy pocztą internetową X.400 a pocztą Mail-11). C. Allocchio. Styczeń 1998. (Format: TXT=58 553 bajty) (zastąpił RFC1405) (Status: eksperymentalny) 2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) (Korzystanie z internetowego DNS dla dystrybucji mapowania globalnego adresu MIME). C. Allocchio. Styczeń 1998. (Format: TXT=58 789 bajtów) (zastąpił RFC1664) (Status: propozycja standardu) 2164 Use of the X.500/LDAP Directory to Support MIXER Address Mapping (1Wykorzystanie katalogu X.500/LDAP do obsługi mapowania adresu MIXERa). S. Kille. Styczeń 1998. (Format: TXT=16 701 bajtów) (zastąpił RFC1838) (Status: propozycja standardu) 2177 IMAP4 IDLE command (Polecenie IDLE w IMAP4). B. Leiba. Czerwiec 1997. (Format: TXT=6 770 bajtów) (Status: propozycja standardu) 2180 IMAP4 Multi-accessed Mailbox Practice (Praktyka wielodostępowych skrzynek pocztowych IM Afd). M. Gahrns. Lipiec 1997. (Format: TXT=24 750 bajtów) (Status: informacyjny) 2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations (Wartość parametru MIME i rozszerzenia szyfrowanego słowa). N. Freed i K. Moore. Sierpień 1997. (Format:TXT=17 635 bajtów) (zastąpił RFC2184) (Zastąpiony przez RFC2184, RFC2231) (Updates RFC2045, RFC2047, RFC2183) (Status: propozycja standardu) 2192 IMAP URL Scheme (Schemat IMAP URL). C. Newman. Wrzesień 1997. (Format: TXT=31 426 bajtów) (Status: propozycja standardu) 2193 IMAP4 Mailbox Referrals (Przekierowanie w skrzynkach pocztowych IMAP4). M. Gahrns. Wrzesień 1997. (Format: TXT=16 248 bajtów) (Status: propozycja standardu) 2195 IMAP/POP Authorize Extension for Simple Challenge/Response (Rozszerzenia autoryzacji IMAP/POP dla prostego wyzwania/odpowiedzi). J. Kłensin, R. Catoe, P. Krumviede. Wrzesień 1997. (Format: TXT=10 468 bajtów) (zastąpił RFC2095) (Status: propozycja standardu) 2197 SMTP Service Extension for Command Pipelining (Rozszerzenie usługi SMTP dla potrzeb potokowego przetwarzania poleceń). N. Freed. Wrzesień 1997. (Format: TXT=15 003 bajty) (zastąpił RFC1854) (Status: wersja robocza standardu) 2220 The Application/MARC Content-type (Typ zaioartości Application/MARC). R. Guenther. Październik 1997. (Format: TXT=7 025 bajtów) (Status: informacyjny)

’

448

TCP/IP. SZKOŁA PROGRAMOWANIA

2221 IMAP4 Login Referrals (Przekierowanie w logowaniu IMAP4). M. Gahrns. Październik 1997. (Format: TXT=9 251 bajtów) (Status: propozycja standardu) 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N (Wartość parametru MIME i rozszerzenia szyfrowanego słowa). Freed i K. Moore. Listopad 1997. (Format: TXT=19 280 bajtów) (zastąpił RFC2184) (uaktualnia RFC2045, RFC2047 RFC2183) (Status: propozycja standardu) 2298 An Extensible Message Format for Message Disposition Notifications (Rozszerzalny format komunikatu dla potrzeb powiadomień o dyspozycji komunikatu). R. Fajman. Marzec 1998. (Format: TXT=62 059 bajtów) (Status: propozycja standardu) 2302 Tag Image File Format (TIFF) — Image/tiff MIME Sub-type Registration (Format TIFF — Rejestracja podtypu MIME Image/tiff). G. Parsons, J. Rafferty, S. Zilles. Marzec 1998. (Format: TXT=14 375 bajtów) (Status: propozycja standardu) 2311 S/MIME Version 2 Message Specification (Specyfikacja komunikatu S/MIME wersja 2). S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka. Marzec 1998. (Format: TXT=7 091 bajtów) (Status: informacyjny) 2312 S/MIME Version 2 Certification Handling (Obsługa certyfikacji S/MIME). S. Dusse, P. Hofffman, B. Ramsdell i j. Weinstein. Marzec 1998. (Format: TXT=39 829 bajtów) 2318 The Text/CSS Media Type (Typ mediów Text/CSS). H. Lie, B. Bos i C. Lilley. Marzec 1998. (Format: TXT=7 819 bajtów) (Status: informacyjny) 2342 IMAP4 Namespace (Przestrzeń nazw IMAP4). M. Gahrns i C. Newman. Maj 1998. (Format: TXT=19 489 bajtów) (Status: propozycja standardu) 2359 IMAP4 UIDPLUS Extension (Rozszerzenia IMAP4 UIDPLUS). J. Myers. Czerwiec 1998. (Format: TXT=10 862 bajty) (Status: propozycja standardu) 2384 POP URL Scheme (Schemat adresów URL POP). R. Gellens. Sierpień 1998. Format: TXT=13 649 bajtów) (Status: propozycja standardu) 2387 The MIME Multipart/Related Content-type (Typ zawartości MIME wieloczęściowy/ poiuiqzany). E. Levinson. Sierpień 1998. (Format: TXT=18 864 bajty) (zastąpił RFC2112) (Status: propozycja standardu) 2424 ContentDuration MIME Header Definition (Definicja nagłówka MIME zawartość!czas trwania). G. Vaudreuil i G. Parsons. Wrzesień 1998. (Format: TXT=7 116 bajtów) (Status: propozycja standardu)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

449

2425 A MIME Content-type for Directory Information (Typ zawartości MIME dla potrzeb informacji katalogowej). T. Howes, M. Smith i F. Dawson. Wrzesień 1998. (Format: TXT=64 478 bajtów) (Status: propozycja standardu) 2426 vCard MIME Directory Profile (Profil katalogu vCard MIME). F. Dawson i T. Howes. Wrzesień 1998. (Format: TXT=74 746 bajtów) (Status: propozycja standardu) 2442 The Batch SMTP Media Type (Typ mediów wsadowego SMTP). N. Freed, D. Newman, H. Belissen i M. Hoy. Listopad 1998. (Format: TXT=18 384 bajty) (Status: informacyjny) 2449 POP3 Extension Mechanism (Mechanizm rozszerzenia POP3). R. Gellens, C. Newman i L. Lundblade. Listopad 1998. (Format: TXT=36 017 bajtów) (uaktualnia RFC1939) (Status: propozycja standardu) 2476 Message Submission (Zgłaszanie wiadomości). R. Gellens i H. Klensin. Grudzień 1998. (Format: TXT=30 050 bajtów) (Status: propozycja standardu) 2480 Gateways and MIME Security Multiparts (Bramy i odpowiadające za bezpieczeństwo części wiadomości MIME). N. Freed. Styczeń 1999. (Format: TXT=11 751 bajtów) (Status: propozycja standardu) 2487 SMTP Service Extension for Secure SMTP Over TLS (Rozszerzenia usługi SMTP dla potrzeb bezpiecznego SMTP przez TLS). P. Hoffman. Styczeń 1999. (Format: TXT=15 120 bajtów) (Status: propozycja standardu) 2503 MIME Types for Use with the ISO ILL Protocol (Typy MIME używane z protokołem ISO ILL). R. Moulton i M. Needleman. Luty 1999. (Format: TXT=9 078 bajtów) (Status: informacyjny) 2505 Anti-Spam Recommendations for SMTP MTAs (Rekomendacje antyspamowe dla potrzeb SMTP MTA). G. Lindberg. Luty 1999. (Format: TXT=53 597 bajtów) (także BCP0030) (Status: najlepsze obecne procedury) 2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3 (Specyfikacja protokołu -wydajnego zgłaszania i dostarczania poczty (EMSD) -wersja 1.3). M. Banan. Luty 1999. (Format: TXT=153 171 bajtów) (Status: informacyjny) 2554 SMTP Service Extension for Authentication (Rozszerzenia usług SMTP dla potrzeb uwierzytelnienia). J. Meyers. Marzec 1999. (Format: TXT=20 534 bajty) (Status: propozycja standardu) 2557 MIME Encapsulation of Aggregate Documents Such As HTML (MHTML) (Hermetyzacja MIME dokumentów zagregowanych, takich jak HTML). J. Palmę, A. Hopmann i N. Shelness. Marzec 1999. (Format: TXT=61 854 bajty) (zastąpił RFC2110) (Status: propozycja standardu)

450

TCP/IP. SZKOŁA PROGRAMOWANIA

2586 The Audio/L16 MIME (Audio/L16 MIME) 2595 Using TLS with IMAP, POP3, and ACAP (Korzystanie z TLS z IMAP. POP3 i ACAP) 2632 S/MIME Version 3 Certificate Handling (Obsługa certyfikatów S/MIME wersja 3) 2633 S/MIME Version 3 Message Specification (Specyfikacja wiadomości S/MIME wersja 3) 2634 Enhanced Security Service for S/MIME (Rozszerzona usługa bezpieczeństwa dla S/MIME) 2645 On-demand Mail Relay (ODMR) SMTP With Dynamic IP Addresses (Przekaźnik poczty na żądanie (ODMR) w SMTP z dynamicznymi adresami IP) 2646 The Text/Plain Format Parameter (Parametr formatu Text/Plain) 2683 IMAP4 Implementation Recommendations (Rekomendacje implementacji IMAP4)

Rozdział 14. Przekształcanie nazw 752 Universal Host Table (Uniwersalna tabela hostów) 756 NIC Name Server — a Datagram-based Information Utility (Serwer nazw NIC — narzędzie informacyjne oparte na datagramach) 799 Internet Name Domains (Domeny nazw Internetu) 811

Hostname Server (Serwer nazw hostów)

819 Domain Naming Convention for Internet User Applications (Konwencja nazw domen dla aplikacji użytkownika internetowego) 830 Distributed System for Internet Name Service (Rozproszony system dla internetowych usług nazw) 881

Domain Names Plan and Schedule (Nazioy domen: Plan i harmonogram)

882 Domain Names: Concepts and Facilities (Nazwy domen: Koncepcje i ułatwienia) 883 Domain Names: Implementation Specification (Nazwy domen: Specyfikacje implementacji) 897 Domain Name System Implementation Schedule — Revised (Harmonogram implementacji systemu nazio domen — zmieniony) 920 Domain Requirements (Wymagania dotyczące domen)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

921

45 1

Domain Name System Implementation Schedule — Revised (Harmonogram implementacji systemu nazw domen — zmieniony)

953 Hostname Server (Serwer nazw hostów) 973 Domain System Changes and Observations (Zmiany systemu domen i uwagi) 1001 ProtocolStandard for a NetBIOS Service on a TCPAJDP Transport: Concepts and Methods (Standard protokołu dla usługi NetBIOS z transportem TCP/UDP: Koncepcje i metody). NetBIOS Working Group. Defense Advanced Research Projects Agency, Internet Activities Board, End to-End Services Task Force. 01.03.1987. (Format: TXT=158 437 bajtów) (Status: standard) 1002 Protocol Standard for a NetBIOS Service on a TCPAJDP Transport: Detailed Specifications (Standard protokołu dla usługi NetBIOS z transportem TCP/UDP: Szczegółowe specyfikacje). NetBIOS Working Group. Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force. 01.03.1987. (Format: TXT=170 262 bajty) (Status: standard) 1031 MILNET Name Domain Transition (Zmiana domeny nazw MILNET). W. D. Lazear. 01.11.1987. (Format: TXT=20 137 bajtów) (Status: nieznany) 1032 Domain Administrators Guide (Przewodnik administratora domen). M. K. Stahl. 01.11.1987. (Format: TXT=29 454 bajty) (Status: nieznany) 1033 Domain Administrators Operations Guide (Przewodnik działania administratora domen). M. Lottor. 01.11.1987. (Format: TXT=37 263 bajty) (Status: nieznany) 1034 Domain Names — Concepts and Facilities (Naziuy domen — Koncepcje i ułatwienia). P. V. Mockapetris. 01.11.1987. (Format: TXT=129 180 bajtów) (zastąpił RFC0973, RFC0882, RFC0883) (zastąpiony przez RFC1065, RFC2308) (Uaktualniony przez RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308) (Status: standard) 1035 Domain Administrators Guide (Przewodnik administratora domen). M. K. Stal'd. 01.11.1987. (Format: TXT=29 454 bajty) (Status: nieznany) 1036 Domain Administrators Guide (Przewodnik administratora domen). M. Lottor. 01.11.1987. (Format: TXT=37 263 bajty) (Status: nieznany) 1037 Domain Names — Concepts and Facilities (Nazwy domen — Koncepcje i ułatwienia). P. V. Mockapetris. 01.11.1987. (Format: TXT=129 180 bajtów) (zastąpił RFC0973, RFC0882, RFC0883) (zastąpione przez RFC1065, RFC2308) (Uaktualniony przez RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136, RFC2137, RFC2308) (Status: standard)

452

TCP/IP. SZKOŁA PROGRAMOWANIA

1038 Domain Names — Implementation and Specification {Nazwy domen — Implementacje i specyfikacje). P. V. Mockapetris. 01.11.1987. (Format: TXT=125 626 bajtów) (zastąpił RFC0973, RFC0882, RFC0883) (Uaktualniony przez RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136, RFC2137, RFC2308) (Status: standard) 1101 DNS Encoding of Network Names and Other Types (Szyfrowanie DNS nazw sieciowych i innych typów). P. V. Mockapetris. 01.04.1989. (Format: TXT=28 677 bajtów) (Updates RFC1034, RFC1035) (Status: nieznany) 1183 New DNS RR Definitions (Nowe definicje DNS RR). C. F. Everhart, L. A. Mamakos, R. Ullmann i P. V. Mockapetris. 01.10.1990. (Format: TXT=23 788 bajtów) (uaktualnia RFC1034,RFC1035) (Status: eksperymentalny) 1348 DNS NSAP Resource Records (Rekordy zasobów DNS NSAP). B. Manning. Lipiec 1992. (Format: TXT=6 871 bajtów) (Zastąpiony przezRFC1637) (Updates RFC1034, RFC1035) (Uaktualniony przez RFC1637) (Status: eksperymentalny) 1383 An Experiment in DNS-based IP Routing (Eksperyment z routingiem IP opartym na DNS). C. Huitema. Grudzień 1992. (Format: TXT=32 680 bajtów) (Status: eksperymentalny) 1386 The US Domain (Domena US). A. Cooper i J. Postel. Grudzień 1992. (Format: TXT=62 310 bajtów) (Zastąpiony przez RFC1480) (Status: informacyjny) 1394 Relationship of Telex Answerback Codes to Internet Domains (Związek kodów odpowiedzi zwrotnej Telex z domenami internetowymi). P. Robinson. Styczeń 1993. (Format: TXT=43 776 bajtów) (Status: informacyjny) 1464 Using the Domain Name System to Store Arbitrary String Attributes (Wykorzystanie systemu nazw domen do przechowywania arbitralnych atrybutów tekstowych). R. Rosenbaum. Maj 1993. (Format: TXT=7 953 bajty) (Status: eksperymentalny) 1480 The US Domain (Domena US). A. Cooper i J. Postel. Czerwiec 1993. (Format: TXT=100 556 bajtów) (zastąpił RFC1386) (Status: informacyjny) 1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software (Problem bezpieczeństwa i proponowane poprazoki z szeroko stosowanym oprogramowaniem DNS). E. Gavron. Październik 1993. (Format: TXT=9 722 bajty) (Status: informacyjny)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

453

1536 Common DNS Implementation Errors and Suggested Fixes (Powszechne błędy implementacji DNS i sugerowane poprawki). A. Kumar, J. Postel, C. Neuman, P. Danzig i S. Miller. Październik 1993. (Format: TXT=25 476 bajtów) (Status: informacyjny) 1537 Common DNS Operational and Configuration Errors (Powszechne błędy konfiguracji i działania DNS). P. Beertema. Październik 1993. (Format: TXT=19 825 bajtów) (Zastąpiony przez RFC1912) (Status: informacyjny) 1591 Domain Name System Structure and Delegation (Struktura i delegacja systemu nazw domen). J. Postel. Marzec 1994. (Format: TXT=16 481 bajtów) (Status: informacyjny) 1637 DNSAP Resource Records (Rekordy zasobów DNS NSAP). B. Manning i R. Colella. Czerwiec 1994. (Format: TXT=21 768 bajtów) (zastąpił RFC1348) (Zastąpiony przez RFC1706) (uaktualnia RFC1348) (Status: eksperymentalny) 1706 DNS NSAP Resource Records (Rekordy zasobów DNS NSAP). B. Manning i R. Colella. Październik 1994. (Format: TXT=19 721 bajtów) (zastąpił RFC1637) (Status: informacyjny) 1712 DNS Encoding of Graphical Location (Szyfrowanie graficznego położenia io DNS). C. Farrell, M. Schulze, S. Pleitner i D. Baldoni. Listopad 1994. (Format: TXT=13 237 bajtów) 1713 Tools for DNS Debugging (Narzędzia usuwania błędów DNS). A. Romao. Listopad 1994. (Format: TXT=33 500 bajtów) (także FYI10027) (Status: informacyjny) 1794 DNS Support for Load Balancing (Obsługa bilansowania ładunków w DNS). T. Brisco. Kwiecień 1995. (Format: TXT=15 494 bajty) (Status: informacyjny) 1876 A Means for Expressing Location Information in the Domain Name System (Srodlci wyrażenia informacji o położeniu to systemie nazw domen). C. Davis, P. Vixie, T. Goodwin i I. Dickinson. Styczeń 1996. (Format: TXT=29 631 bajtów) (uaktualnia RFC1034, RFC1035) (Status: eksperymentalny) 1912 Common DNS Operational and Configuration Errors (Powszechne błędy działania i konfiguracji w DNS). D. Barr. Luty 1996. (Format: TXT=38 252 bajty) (zastąpił RFC1537) (Status: informacyjny) 1982 Serial Number Arithmatic (Arytmetyka numerów kolejnych). R. Elz i R. Bush. Sierpień 1996. (Format: TXT=14 440 bajtów) (uaktualnia RFC1034, RFC1035) (Status: propozycja standardu)

454

TCP/IP. SZKOŁA PROGRAMOWANIA

1995 Incremental Zone Transfer in DNS (Przyrostowy transfer stref w DNS). M. Ohta. Sierpień 1996. (Format: TXT=16 810 bajtów) (uaktualnia RFC1035) (Status: propozycja standardu) 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Mechanizm szybkiego powiadamiania o zmianach stref— DNS NOTIFY). P. Vixie. Sierpień 1996. (Format: TXT=15 247 bajtów) (uaktualnia RFC1035) (Status: propozycja standardu) 2010 Operational Criteria for Root Name Servers (Kryteria operacyjne dla podstawoioych serwerów nazw). B. Manning i P. Vixie. Październik 1996. (Format: TXT=14 870 bajtów) (Status: informacyjny) 2052 A DNS RR for Specifying the Location of Services (DNS SRV) (DNS RR dla określania lokalizacji usług— DNS SRV). A. Gulbrandensen, P. Vixie. Październik 1996. (Format: TXT19 257 bajtów) (Status: eksperymentalny) 2065 Domain Name System Security Extensions (Rozszerzenia bezpieczeństwa w DNS). D. Eastlake, 3rd Edition. C. Kaufman. Styczeń 1997. (Format: TXT=97 718 bajtów) (uaktualnia RFC1034, RFC1035) (Status: propozycja standardu) 2136 Dynamic Updates in the Domain Name System (DNS UPDATE) (Dynamiczne uaktualnienia w systemie DNS - DNS UPDATE). P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. Kwiecień 1997. (Format: TXT=56 354 bajty) (uaktualnia RFC1035) (Status: propozycja standardu) 2137 Secure Domain Name System Dynamic Update (Dynamiczne uaktualnienie bezpiecznego DNS). D. Eastlake. Kwiecień 1997. (Format: TXT=24 824 bajty) (uaktualnia RFC1035) (Status: propozycja standardu) 2181 Clarification of DNS Specification (Objaśnienie specyfikacji DNS). R. Elz i R. Bush. Lipiec 1997. (Format: TXT=36 989 bajtów) (Uaktualnia RFC1034, RFC1035, RFC1123) (Status: propozycja standardu) 2182 Selection and Operation for Secondary DNS Servers (Wybór i działanie drugorzędnych serwerów DNS). R. Elz, R. Bush, S. Bradner i M. Patton. Lipiec 1997. (Format: TXT=27 456 bajtów) (także BCP0016) (Status: najlepsze obecne procedury) 2219 Use of DNS Aliases for Network Services. M. Hamilton i R. Wright (Wykorzystanie aliasów DNS dla usług sieciowych). Październik 1997. (Format: TXT=17 858 bajtów) (także BCP0017) (Status: najlepsze obecne procedury)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

455

2230 Key Exchange Delegation Record for the DNS (Rekord przekazania wymiany kluczy dla DNS). R. Atkinson. Październik 1997. (Format: TXT=25 563 bajty) (Status: informacyjny) 2240 A Legal Basis for Domain Name Allocation (Podstawy prawne alokacji nazw domen). O. Vaughan. Listopad 1997. (Format: TXT=13 602 bajty) (Zastąpiony przez RFC2352) (Status: informacyjny) 2308 Negative Caching of DNS Queries (DNS NCACHE) (Negatywne buforowanie zapytań DNS). M. Andrews. Marzec 1998. (Format: TXT=41 428 bajtów) (zastąpił RFC1034) (uaktualnia RFC1034, RFC1035) (Status: propozycja standardu) 2317 Classless IN-ADDR.ARPA Delegation (Bezklasowa delegacja do 1N-ADDR.ARDA). H. Eidnes, G. de Groot i P. Vixie. Marzec 1998. (Format: TXT=17 744 bajty) (także BCP0020) (Status: najlepsze obecne procedury) 2517 Building Directories from DNS: Experiences from WWWSeeker (Budoioanie katalogów z DNS: Doświadczenia z WWWSeeker). R. Moats i R. Huber. Luty 1999. (Format: TXT=14 001 bajtów) (Status: informacyjny) 2535 Domain Name System Security Extensions. D. Eastlake (Rozszerzenia bezpieczeństwa DNS). Marzec 1999. (Format: TXT=110 958 bajtów) (uaktualnia RFC2181, RFC1035, RFC1034) (Status: propozycja standardu) 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) (Przechowywanie kluczy Diffiego-Hellmana w DNS). D. Eastlake. Marzec 1999. (Format: TXT=21 049 bajtów) (Status: propozycja standardu) 2540 Detached Domain Name System (DNS) Information (Informacja o odłączonym DNS). D. Eastlake. Marzec 1999. (Format: TXT=12 546 bajtów) (Status: eksperymentalny) 2541 DNS Security Operational Considerations (Rozważania operacyjne na temat bezpieczeństwa DNS). D. Eastlake. Marzec 1999. (Format: TXT=14 498 bajtów) (Status: informacyjny) 2606 Reserved Top-level DNS Names (Zarezerwowane nazwy DNS górnego poziomu) 2671 Extension Mechanisms for DNS (EDNSO)( Mechanizmy rozszerzenia dla DNS — EDNSO) 2672 Non-terminal DNS Name Redirection (Przekierowanie nazw DNS) 2673 Binary Labels in the Domain Name System (Binarne etykiety w DBS)

456

TCP/IP. SZKOŁA PROGRAMOWANIA

Rozdział 15. Protokół przesyłania hipertekstu (HTTP) 1009 Requirements for Internet Gateways (Wymagania dla bram internetowych). R. T. Braden i J. Postel. 01.06.1987. (Format: TXT=128 173 bajty) (Status: historyczny) 1945 Hypertext Transfer Protocol — HTTP/1.0 (Protokół HTTP/1.0). T. Berners-Lee, R. Fielding i H. Frystuk. Maj 1996. (Format: TXT=137 582 bajty) (Status: informacyjny) 2068 Hypertext Transfer Protocol — HTTP/1.1 (Protokół H TTP/l.l). R. Fielding, J. Gettys, J. Mogul, H. Frystyk i T. Berners-Lee. Styczeń 1997. (Format: TXT=378 114 bajtów) (Status: propozycja standardu) 2069 HTTP Authentication: Basic and Digest Access Authentication (Uwierzytelnienie HTTP: Podstaioy i przegląd uwierzytelniania dostępu). J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. Styczeń 1997. (Format: TXT=41 733 bajty) (Status: propozycja standardu) 2109 HTTP State Management Mechanism (Mechanizm zarządzania stanem HTTP). D. Kristol i L. Montulli. Luty 1997. (Format: TXT=43 469 bajtów) (zastąpił RFC1920) (Status: propozycja standardu) 2145 Use and Interpretation of HTTP Version Numbers (Wykorzystanie i interpretacja numerów wersji HTTP). J. C. Mogul, R. Fielding, J. Gettys i H. Frystuk. Maj 1997. (Format: TXT=13 659 bajtów) (Status: informacyjny) 2169 A Trivial Convention for using HTTP in URN Resolution (Trywialna konwencja używania HTTP w określaniu URN). R. Daniel. Czerwiec 1997. (Format: TXT=17 763 bajty) (Status: eksperymentalny) 2227 Simple Hit Metering and Usage Limiting for HTTP (Proste zliczanie trafień i ograniczenie użytkowania w HTTP). J. Mogul i P. Leach. Październik 1997. (Format: TXT=85 127 bajtów) (Status: propozycja standardu) 2295 Transparent Content Negotiation in HTTP (Transparentne negocjacje zawartości w HTTP). K. Holtman i A. Mutz. Marzec 1998. (Format: TXT=125 130 bajtów) (Status: eksperymentalny) 2518 HTTP Extensions for Distributed Authoring — WEBDAV (Rozszerzenia HTTP dla rozproszonego tworzenia). Y. Goland, E. Whitehead, A. Faizi, S. Carter i D. Jensen. Luty 1999. (Format: TXT=202 829 bajtów) (Status: propozycja standardu) 2616 Hypertext Transfer Protocol — HTTP/1.1 (Protokół HTTP/1.1) 2660 The Secure Hypertext Transfer Protocol (Bezpieczny protokół HTTP)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

457

Rozdział 16. Trywialny protokół przesyłania plików (TFTP) 906

Bootstrap Loading Using TFTP (Rozruch za pomocą TFTP)

1782 TFTP Option Extension (Rozszerzenia opcji TFTP). G. Malkin i A. Harkin. Marzec 1995. (Format: TXT=11 508 bajtów) (Zastąpiony przez RFC2347) (uaktualnia RFC1350) 1783 TFTP Blocksize Option (Opcja luielkości bloku TFTP). G. Malkin i A. Harkin. Marzec 1995. (Format: TXT=7 814 bajtów) (Zastąpiony przez RFC2348) (uaktualnia RFC1350) (Uaktualniony przez RFC1350) (Status: propozycja standardu) 1784 TFTP Timeout Interval and Transfer Size Option (Opcje interwału limitu czasu i luielkości transferu TFTP). G. Malkin i A. Harkin. Marzec 1995. (Format: TXT=6 106 bajtów) (Zastąpiony przez RFC2349) (uaktualnia RFC1350) (Status: propozycja standardu) 1785 TFTP Option Negotiation Analysis (Analiza negocjacji opcji TFTP). G. Malkin i A. Harkin. Marzec 1995. (Format: TXT=3 354 bajty) (uaktualnia RFC1350) (Status: informacyjny) 2090 TFTP Multicast Option (Opcja multiemisji TFTP). A. Emberson. Luty 1997. (Format: TXT=11 857 bajtów) (Status: eksperymentalny) 2347 TFTP Option Extension (Rozszerzenia opcji TFTP). G. Malkin i A. Harkin. Maj 1998. (Format: TXT=13 060 bajtów) (zastąpił RFC 1782) (uaktualnia RFC1350) (Status: wersja robocza standardu) 2348 TFTP Blocksize Option (Opcja luielkości bloku TFTP). G. Malkin i A. Harkin. Maj 1998. (Format: TXT=9 515 bajtów) (zastąpił RFC1783) (uaktualnia RFC1350) (Status: wersja robocza standardu) 2349 TFTP Timeout Interval and Transfer Size Option (Opcje interwału limitu czasu i wielkości transferu TFTP). G. Malkin i A. Harkin. Maj 1998. (Format: TXT=7 848 bajtów) (zastąpił RFC1784) (Updates RFC1350) (Status: wersja robocza standardu)

458

TCP/IP. SZKOŁA PROGRAMOWANIA

Rozdział 17. Prosty protokół zarządzaeia siecią (SNMP) 1067 Simple Network Management Protocol (SNMP) (Protokół SNMP). J. D. Case, M. Fedor, M. L. Schoffstall i J. Davin. 01.08.1988. (Format: TXT=69 592 bajty) (Zastąpiony przez RFC1098) (Status: nieznany) 1089 SNMP Over Ethernet (SNMP przez Ethernet). M. L. Schoffstall, C. Davin, M. Fedor i j. D. Case. 01.02.1989. (Format: TXT=4458 bajtów) (Status: nieznany) 1098 Simple Layer Management Protocol (SNMP) (Protokół SNMP). J. D. Case, M. Fedor, M. L. Schoffstall i C. Davin. 01.04.1989. (Format: TXT=71 563 bajty) (Zastąpiony przez RFC1157) (Status: nieznany) 1157 Simple Network Management Protocol (SNMP) (Protokół SNMP). J. D. Case, M. Fedor, M. L. Schoffstall, i C. Davin. 01.05.1990. (Format: TXT=74 894 bajty) (zastąpił RFC1066) (Status: historyczny) 1161 SNMP Over OSI (SNMP przez OSI). M. T. Rose. 01.06.1990. (Format: TXT=16 036 bajtów) (zastąpiony przez RFC1418) (Status: eksperymentalny) 1187 Bulk Table Retrieval for the SNMP (Odzyskiioanie masowych tablic w SNMP). M. T. Rose, K. McCloghrie i J. R. Davin. 01.10.1990. (Format: TXT=27 220 bajtów) (Status: eksperymentalny) 1212 Concise MIB Definitions (Ziuięzłe definicje MIB). M. T. Rose, K. McCloghrie. 01.03.1991. (Format: TXT=43 579 bajtów) (Status: standard) 1215 Convention for Defining Traps to Use With the SNMP (Komoencja definiowania pułapek wykorzystyiuanych w SNMP). M. T. Rose. 01.03.1991. (Format: TXT=19 336 bajtów) (Status: informacyjny) 1227 SNMP MUX Protocol and MIB (Protokół SNMP MUX i MIB). M. T. Rose. 01.05.1991. (Format: TXT=25 868 bajtów) (Status: historyczny) 1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface, Version 2.0 ( SNMP-DRI: Rozproszony interfejs programowy SNMP). G. Carpenter i B. Wijnen. 01.05.1991. (Format: TXT=96 972 bajty) (Zastąpiony przezRFC1592) (Status: eksperymentalny) 1229 Extensions to the Generic-interface MIB (Rozszerzenia podstawowego interfejsu MIB). K. McCloghrie. 01.05.1991. (Format: TXT=36 022 bajty) (Zastąpiony przez RFC1573) (Uaktualniony przez RFC1239) (Status: propozycja standardu)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

459

1239 Reassignment of Experimental MIBs to Standard MIBs (Zmiana przydziału eksperymentalnej bazy MIB do standardu MIB). J. K. Reynolds. 01.06.1991. (Format: TXT=3 656 bajtów) (uaktualnia RFC1229, RFC1230, RFC1231, RFC1232, RFC1233) (Status: propozycja standardu) 1270 SNMP Communication Services (Usługi komunikacyjne SNMP). F. Kastenholz. Oct-Ol-1991. (Format: TXT=26 167 bajtów) (Status: informacyjny) 1283 SNMP Over OSI (SNMP przez OSI). M. Rose. Grudzień 1991. (Foirnat: TXT=16 857 bajtów) (zastąpiony przez RFC1418) (Status: eksperymentalny) 1298 SNMP Over IPX (SNMP przez IPX). R. Wormley, S. Bostock. Luty 1992. (Format: TXT=7 878 bajtów) (Zastąpiony przez RFC1420) (Status: informacyjny) 1303 A Convention for Describing SNMP-based Agents (Konwencja opisu agentów opartych na SNMP). K. McCloghrie i M. Rose. Luty 1992. (Format: TXT=22 915 bajtów) (Także RFC1155, RFC1212, RFC1213, RFC1157) (Status: informacyjny) 1351 SNMP Administrative Model (Model administracyjny SNMP). J. Davin, }. Galvin i K. McCloghrie. Lipiec 1992. (Format: TXT=80 721 bajtów) (Status: propozycja standardu) 1352 SNMP Security Protocols (Protokoły bezpieczeństwa SNMP). J. Galvin, K. McClghrie i J. Davin. Lipiec 1992. (Format: TXT=80 721 bajtów) (Status: propozycja standardu) 1353 Definitions of Managed Objects for Administration of SNMP Parties (Definicje zarządzanych obiektów dla administracji uczestników SNMP). K. McCloghrie, J. Davin i J. Galvin. Lipiec 1992. (Format: TXT=59 556 bajtów) (Status: propozycja standardu) 1369 Implementation Notes and Experience for the Internet Ethernet MIB (Uwagi o implementacji i doświadczeniach z bazami MIB Internet Ethernet). F. Kastenholz. Październik 1992. (Format: TXT=13 921 bajtów) (Status: propozycja standardu) 1418 SNMP Over OSI (SNMP przez OSI). M. Rose. Marzec 1993. (Format: TXT=7 721 bajtów) (zastąpił RFC1161, RFC1283) (Status: propozycja standardu) 1419 SNMP Over AppleTalk (SNMP przez AppleTalk). G. Minshall i M. Ritter. Marzec 1993. (Format: TXT=16 470 bajtów) (Status: propozycja standardu) 1420 SNMP Over IPX (SNMP przez IPX). S. Bostock. Marzec 1993. (Format: TXT=6 762 bajty) (zastąpił RFC1298) (Status: propozycja standardu)

460

TCP/IP. SZKOŁA PROGRAMOWANIA

1441 Introduction to Version 2 of the Internet-standard Network Management Framework (Wprowadzenie do wersji 2 schematu zarządzania siecią w standardzie internetowym). J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Kwiecień 1993. (Format: TXT=25 386 bajtów) (Status: propozycja standardu) 1442 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SMIv2) (Struktura zarządzania informacją dla wersji 2 protokołu SNMP).}. Case, K. McCloghrie, M. Rose i S. Waldbusser. Kwiecień 1993. (Format: TXT=95 779 bajtów) (Zastąpiony przez RFC1902) (Status: propozycja standardu) 1443 Textual Conventions for Version 2 of the Simple Network Management Protocol (SMIv2).( Konwencje tekstowe dla zuersji 2 protokołu SNMP). J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Kwiecień 1993. (Format: TXT=60 947 bajtów) (Zastąpiony przez RFC1903) (Status: propozycja standardu) 1444 Conformance Statements for Version 2 of the Simple Network Management Protocol (SMIv2) (Oświadczenia zgodności dla wersji 2 protokołu SNMP). J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Kwiecień 1993. (Format: TXT=57 744 bajty) (Zastąpiony przez RFC1904) (Status: propozycja standardu) 1445 Administrative Model for Version 2 of the Simple Network Management Protocol (SNMPv2) (Model administracyjny dla wersji 2 protokołu SNMP) 1446 Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2) (Protokoły bezpieczeństioa dla wersji 2 protokołu SNMP). J. Galvin i K. McCloghrie, M. Rose i S. Waldbusser. Kwiecień 1993. (Format: TXT=99 443 bajty) (Status: historyczny) 1448 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) (Działania protokołu dla wersji 2 protokołu SNMP). J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Kwiecień 1993. (Format: TXT=74 224 bajty) (Zastąpiony przez RFC1905) (Status: propozycja standardu) 1449 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) (Mapowanie transportu dla wersji 2 protokołu SNMP). J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Kwiecień 1993. (Format: T X T = 4 1 161 bajtów) (Zastąpiony przez RFC1906) (Status: propozycja standardu)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

461

1452 Coexistence Between Version 1 and Version 2 of the Internet-standard Network Management Framework. (Koegzystencja pomiędzy wersją 1 a wersją 2 schematu zarządzania siecią zv standardzie internetowym). J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Kwiecień 1993. (Format: TXT=32 176 bajtów) (Zastąpiony przez RFC1908) (Status: propozycja standardu) 1503 Algorithms for Automating Administration in SNMPv2 Managers (Algorytmy automatyzacji administracji w menadżerach SNMPv2). K. McCloghrie i M. Rose. Sierpień 1993. (Format: TXT=33 542 bajty) (Status: informacyjny) 1856 The Opstat Client-Server Model for Statistical Retrieval (Model klient-serwer dla wyszukiwania statystycznego). H. Clark. Październik 1995. (Format: TXT=29 954 bajty) (Status: informacyjny) 1901 Introduction for Community-based SNMPv2. SNMPv2 Working Group (Wprowadzenie do SNMPv2 opartego na społeczności. Grupa robocza SNMPv2). J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Styczeń 1996. (Format: TXT=15 903 bajty) (Status: eksperymentalny) 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SMIv2) (Struktura informacji o zarządzaniu dla wersji 2 protokołu SNMP. Grupa robocza SNMPv2). SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Styczeń 1996. (Format: TXT=77 453 bajty) (zastąpił RFC1442) (Status: wersja robocza standardu) 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SMIv2) (Telcstoiue konwencje dla luersji 2 protokołu SNMP. Grupa robocza SNMPvZ). SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Styczeń 1996. (Format: TXT=52 652 bajty) (zastąpił RFC1443) (Status: wersja robocza standardu) 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SMIv2) (Ośioiadczenie zgodności dla wersji 2 protokołu SNMP. Grupa robocza SNMPvZ). SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Styczeń 1996. (Format: TXT=47 083 bajty) (zastąpił RFCE1444) (Status: wersja robocza standardu) 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) (Działania protokołu dla wersji 2 protokołu SNMP. Grupa robocza SNMPvZ). SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose i S. Waldbusser. Styczeń 1996. (Format: TXT=55 526 bajtów) (zastąpił RFC1448) (Status: Wersja robocza standardu) 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) (Mapowanie transportu dla wersji 2 protokołu SNMP. Grupa robocza SNMPv2). SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose

462

TCP/IP. SZKOŁA PROGRAMOWANIA

i S. Waldbusser. Styczeń 1996. (Format: TXT=27 465 bajtów) (zastąpił RFC1449) (Status: Wersja robocza standardu) 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework (Koegzystencja pomiędzy wersją 1 a wersją 2 zasad zarządzania siecią w standardzie internetowym). SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose, i S. Waldbusser. Styczeń 1996. (Format: TXT=21463 bajty) (zastąpił RFC1452) (Status: wersja robocza standardu) 1909 An Administrative Infrastructure for SNMPv2 (Administracyjna infrastruktura dla SNMPvZ). K. McCloghrie. Luty 1996. (Format: TXT=45 773 bajty) (Status: eksperymentalny) 1910 User-based Security Model for SNMPv2 (Model bezpieczeństwa oparty na użytkowniku dla SNMPv2). G. Waters. Luty 1996. (Format: TXT=98 252 bajty) (Status: eksperymentalny) 2011 SNMPv2 Management Information Base for the Internet Protocol Using SMIv2 (Baza informacji o zarządzaniu SNMPvZ dla protokołu IP z wykorzystaniem SMIvZ). K. McCloghrie. Listopad 1996. (Format: T X T = 31168 bajtów) (uaktualnia RFC1213) (Status propozycja standardu) 2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 (Baza informacji o zarządzaniu SNMPvZ dla protokołu TCP z wykorzystaniem SMIvZ). K. McCloghrie. Listopad 1996. (Format: TXT=16 792 bajty) (uaktualnia RFC1213) (Status propozycja standardu) 2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 (Baza informacji o zarządzaniu SNMPvZ dla protokołu UDP z wykorzystaniem SMIvZ). K. McCloghrie. Listopad 1996. (Format: TXT=9 333 bajty) (uaktualnia RFC1213) (Status propozycja standardu) 2039 Applicability for Standards Track MIBs to Management of World Wide Web Servers (Stosowalność standardów MIB do zarządzania serwerami WWW). C. Kalbfleisch. Listopad 1996. (Format: TXT=31 966 bajtów) (Status: informacyjny) 2089 V2ToVl Mapping SNMPv2 Onto SNMPvl Within a Bilingual SNMP Agent (Mapowanie SNMPvZ na SNMPvl). B. Winjnene, D. Levi. Styczeń 1997. (Format: TXT=23 814 bajtów) 2107 Ascend Tunnel Management Protocol — ATMP (Protokół zarządzania tunelem wznoszącym). K. Hamzeh. Luty 1997. (Format: TXT=44 300 bajtów) (Status: informacyjny)

Dodatek A » DOKUMENTY RFC WG ROZDZIAŁÓW

463

2257 Agent Extensibility (AgentX) Protocol Version 1 (Protokół rozszerzalności agenta wersja 1). M. Daniele, B. Wijnen, D. Francisco. Styczeń 1998. (Format: TXT=177 452 bajty) (Status: propozycja standardu) 2261 An Architecture for Describing SNMP Management Frameworks (Architektura opisu schematu zarządzania SNMP). D. Harrington, R. Presuhn, B. Wijnen. Styczeń 1998. (Format: TXT=128 036 bajtów) (zastąpiony przez RFC2271) (Status: propozycja standardu) 2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) (Przetiuarzanie i wysyłka komunikatów w protokole SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. Styczeń 1998. (Format: TXT=88 254 bajty) (Zastąpiony przez RFC2272) (Status: propozycja standardu) 2263 SNMP Applications (Aplikacje SNMP). D. Levi, P. Meyer i B. Stewart. Styczeń 1998. (Format: TXT=143 493 bajty) (Zastąpiony przez RFC2273) (Status: propozycja standardu) 2264 User-based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3) (Model bezpieczeństwa oparty na użytkowniku dla wersji 3 SNMP). U. Blumenthal i B. Wijnen. Styczeń 1998. (Format: TXT=168 759 bajtów) (Zastąpiony przez RFC2274) (Status: propozycja standardu) 2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol(SNMP) (Model sterowania dostępem oparty na luidoku — 1MCM dla protokołu SNMP). B. Wijnen, R. Presuhn i K. McCloghrie. Styczeń 1998. (Format: TXT=77 807 bajtów) (Zastąpiony przez RFC2275) (Status: propozycja standardu) 2271 An Architecture for Describing SNMP Management Frameworks (Architektura opisu schematu zarządzania SNMP). D. Harrington, R. Preesuhn i B. Wijnen. Styczeń 1998. (Format: TXT=128 227 bajtów) (zastąpił RFC2261) (Status: propozycja standardu) 2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) (Przetiuarzanie komunikatów i wysyłka dla protokołu SNMP). J. Case, D. Harrington, R. Preesuhn, B. Wijnen. Styczeń 1998. (Format: TXT=88 445 bajtów) (zastąpił RFC2262) (Status: propozycja standardu) 2273 SNMPv3 Applications (Aplikacje SNMPv3). D. Levi, P. Meyer i B. Stewart. Styczeń 1998. (Format: TXT=143 754 bajty) (zastąpił RFC2263) (Status: propozycja standardu)

464

TCP/IP. SZKOŁA PROGRAMOWANIA

2274 User-based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3) (Model bezpieczeństwa oparty na użytkowniku dla wersji 3 SNMP). U. Blumenthal i B. Wijnen. Styczeń 1998. (Format: TXT=168 950 bajtów) (zastąpił RFC2265) (Status: propozycja standardu) 2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol(SNMP) (Model sterowania dostępem oparty na widoku — VACM dla protokołu SNMP). B. Wijnen, R. Presuhn i K. McCloghrie. Styczeń 1998. (Format: TXT=77 998 bajtów) (zastąpi! RFC2265) (Status: propozycja standardu) 2438 Advancement of MIB Specifications on the IETF Standards Track (Postępy specyfikacji MIB według standardów IETF). M. O'Dell, H. Alvestrand, B. Wijens i S. Bradner. Październik 1998. (Format: TXT=13 633 bajty) (także BCP0027) (Status: najlepsze obecne procedury) 2493 Textual Conventions for MIB Modules Using Performance History Based on 15-minute Intervals (Konwencje tekstowe dla modułów MIB używających historii działania na podstawie 15 minutowych interwalów). K. Tesink, Editor. Styczeń 1999. (Format: TXT=18 749 bajtów) (Status: propozycja standardu) 2570 Introduction to Version 3 of the Internet-standard Network Management Framework (Wprowadzenie do wersji 3 zasad zarządzania siecią w standardzie internetowym). J. Case, R. Mundy, D. Partain i B. Stewart. Kwiecień 1999. (Format: TXT=50 381 bajtów) (Status: informacyjny) 2571 An Architecture for Describing SNMP Management Frameworks (Architektura opisu schematu zarządzania SNMP). B. Wijnen, D. Harrington i R. Presuhn. Kwiecień 1999. (Format: TXT=139 260 bajtów) (zastąpił RFC2271) (Status: propozycja standardu) 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) (Przetwarzanie i ivysylka komunikatów w protokole SNMP). J. Case, D. Harrington, R. Presuhn i B. Wijnen. Kwiecień 1999. (Format: TXT=96 035 bajtów) (zastąpił RFC2272) (Status: wersja robocza standardu) 2573 SNMP Applications (Aplikacje SNMP). D. Levi, P. Meyer, B. Stewart. Kwiecień 1999. (Format: TXT=150 427 bajtów) (zastąpił RFC2273) (Status: wersja robocza standardu) 2574 User-based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3) (Model bezpieczeństwa oparty na użytkowniku — USM — dla wersji 3 SNMP). U. Blumenthal, B. Wijnen. Kwiecień 1999. (Format: TXT=190 755 bajtów) (zastąpił RFC2274) (Status: wersja robocza standardu)

Dodatek A • DOKUMENTY RFC WG ROZDZIAŁÓW

465

2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol(SNMP) (Model sterowania dostępem oparty na widoku — VACM dla protokołu SNMP). B. Wijnen, R. Presuhn i K. McCloghrie. Kwiecień 1999. (Format: TXT=79 642 bajty) (zastąpił RFC22275) (Status: wersja robocza standardu) 2578 Structure of Management Information Version 2 (SMIv2) (Struktura zarządzania informacją dla SMIv2). K. McCloghrie, D. Perkins, J. Schoenwaelder. Kwiecień 1999. (Format: TXT=89 712 bajtów) (zastąpił RFC1902) (także STD0058) (Status: standard) 2579 Textual Conventions for SMIv2 (Konwencje tekstowe SMIv2). K. McCloghrie, D. Perkins, J. Schoenwaelder. Kwiecień 1999. (Format: TXT=59 039 bajtów) (zastąpił RFC1903) (także STD0058) (Status: standard) 2580 Conformance Statements for SMIv2 (Oświadczenia zgodności dla SMIv2). K. McCloghrie, D. Perkins, J. Schoenwaelder. Kwiecień 1999. (Format: TXT=54 253 bajty) (zastąpił RFC1904) (także STD0058) (Status: standard) 2593 Script MIB Extensibility Protocol Version 1.0 (Protokół rozszerzalności skryptu MIB wersja 1.0)

Rozdział 18. Protokoły otwartego przetwarzania sieciowego (ONCP) 1014 XDR: External Data Representation standard (XDR: Zewnętrzny standard reprezentacji danych). Inc. Sun Microsystems. 01.06.1987. (Format: TXT=39 316 bajtów) (Status: nieznany) 1094 NFS: Network File System Protocol specification (NFS: Specyfikacje protokołu sieciowego systemu plikózu). Inc. Sun Microsystems. 01.03.1989. (Format: TXT=51 454 bajty) (także RFC1813) (Status: informacyjny) 1813 NFS Version 3 Protocol Specification (Specyfikacje protokołu NFS wersja 3). B. Callaghan, B. Pawłowski & P. Staubach. Czerwiec 1995. (Format: TXT=229 793 bajty) (także RFC1094) (Status: informacyjny) 2054 WebNFS Client Specification (Specyfikacje klienta WebNFS). B. Callaghan. Październik 1996. (Format: TXT=4 128 bajtów) (Status: informacyjny) 2055 WebNFS Server Specification (Specyfikacje klienta WebNFS). B. Callaghan. Październik 1996. (Format: TXT=20 498 bajtów) (Status: informacyjny)

466

TCP/IP. SZKOŁA PROGRAMOWANIA

2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 (Zagadnienia bezpieczeństwa NFS wersji 2 i wersji 3 oraz wykorzystanie RPCSEC_GSS i Kerberos V5 przez protokół NFS) 2624 NFS Version 4 Design Considerations (Uwarunkowania budowy NFS wersja 4)

SKRÓTY I AKRONIMY A ABR

area border router — router obszaru granicznego

ACK

acknowledgement — potwierdzenie

ANSI

American National Standards Institute — Amerykański Narodowy Instytut Standaryzacyjny

API

application program interface — interfejs programowy aplikacji

ARP

Address Resolution Protocol — Protokół odnajdywania adresu

ARPANET

Advance Research Projects Agency network — sieć Agencji Zaawansowanych Projektów Badawczych

AS

autonomous system — system autonomiczny

ASBR

autonomous system border router — router graniczny systemu autonomicznego

ASCII

American Standard Code for Information Interchange — Amerykański standardowy kod wymiany informacji

ASN.l

Abstract Syntax Notation One — abstrakcyjna notacja składni — jeden

ATM

Asynchronous Transfer Mode — Asynchroniczny tryb transmisji

BDR

backup designated router — router zapasowy

BER

Basic Encoding Rules — podstawowe zasady szyfrowania

468

TCP/IP. SZKOŁA PROGRAMOWANIA

BGP

Border Gateway Protocol — Protokół bram granicznych

BIND

Berkeley Internet Name Domain — internetowa domena nazw Berkeley

BootP

Bootstrap Protocol — Protokół rozruchowy

BPF

Berkeley Packet Filter — Filtr Pakietów Berkeley

BRI

Basic Rate Interface — interfejs o podstawowej przepustowości (interfejs podstawowy ISDN)

BSD

Berkeley Software Distribution — dystrybucja oprogramowania Berkeley

CCITT

Consultative Committee for International Telegraphy and Telephony — Międzynarodowy Komitet Doradczy do spraw Telegrafii i Telefonii.

CIDR

classless interdomain routing — bezklasowy routing międzydomenowy

CIX

Commercial Internet Exchange — organizacja zrzeszająca amerykańskich dostawców internetu

CLNP

Connectionless Network Protocol — bezpołączeniowy protokół sieciowy

CPU

central processing unit — procesor

CSMA/CD

carrier sense multiple access collision detection — wielokrotny dostęp z wykrywaniem nośnej i wykrywaniem kolizji

CRC

cyclic redundancy check — cykliczna kontrola redundancji

CSLIP

compressed SLIP — skompresowany SLIP

CSMA

carrier sense multiple access — wielokrotny dostęp z wykrywaniem nośnej

CSU

channel service unit — jednostka obsługi kanału

CUT

Coordinated Universal Time — skoordynowany czas uniwersalny

DARPA

Defence Advanced Research Project Agency — Agencja Zaawansowanych Projektów Badawczych Departamentu Obrony

D

Dodatek B • SKRÓTY I AKRONIMY

469

DCE

Distributed Computing Enviroment — rozproszone środowisko obliczeniowe

DDN

Defense Data Network — sieć danych Departamentu Obrony

DDR

Dial-on-Demand routing — routing z wdzwanianiem na żądanie

DECNet

Digital Equipment Corporation network — sieć firmy DEC

DEMUX

Demultiplexer — demultiplekser

DF

don't fragment field — pole zakazu fragmentacji (nagłówek IP)

DHCP

Dynamie Host Configuration Protocol — protokół dynamicznej konfiguracji hosta

DLC

Data Link control — sterowanie łącza danych

DLPI

Data Link Provider Interface — interfejs dostawcy łącza danych

DNS

Domain Name System — system nazw domen

DoD

Department of Defense — Departament Obrony (model referencyjny DoD)

DR

designated router — router desygnowany (wyznaczony)

DSAP

Destination Service Access Point — punkt dostępu usług miejsca przeznaczenia

DSU

data service unit — jednostka usług danych

DTP

data transfer process — proces transferu danych

DTS

Distributed Time Service — rozproszone usługi czasowe

DUAL

Diffusing Update Algorithm — algorytm rozproszonego uaktualniania

DVMRP

Distance-vector Multicast Routing Protocol — protokół trasowania wektora odległości z rozsyłaniem grupowym

EBGP

external BGP (router) — zewnętrzny router BGP

EBONE

European IP Backbone — europejski szkielet IP

EOL

end of option list — koniec listy opcji

470

TCP/IP. SZKOŁA PROGRAMOWANIA

EGP

Exterior Gateway Protocol — protokół bram zewnętrznych

EIGRP

Enhanced Interior Gateway Protocol Interface — rozszerzony protokół routingu bram wewnętrznych

EMI

electromagnetic interference — interferencja elektromagnetyczna

FCS

frame check sequence — sekwencja kontroli ramek

FDDI

Fiber Distributed Data Interface — interfejs danych przesyłanych przez światłowód

FIFO

first in, first out — pierwszy na wejściu, pierwszy na wyjściu

FIN

finish flag, TCP header — znacznik końca, nagłówek TCP

FQDN

fully qualified domain-name — w pełni kwalifikowana nazwa domeny, pełna nazwa domeny

FTP

File Transfer Protocol — protokół transferu plików

F

G - H HA

hardware address — adres sprzętowy

HDLC

high-level data link control — wysokopoziomowe sterowanie łączem danych

LAB

Internet Architecture Board — Komisja Architektury Internetu

IAC

interpret as command — interpretuj jako polecenia

LANA

Internet Assigned Number Authority — Organizacja Przyznająca Numery Internetowe

IBGP

internal BGP (router) — wewnętrzny router BGP

ICMP

Internet Control Message Protocol — protokół komunikatów sterujących Internetu

IDRP

Interdomain Routing Protocol — międzydomenowy protokół trasowania

I

Dodatek B • SKRÓTY I AKRO NIM Y

471

IEEE

Institute of Electrical and Electronics Engineers — Instytut Inżynierów Elektryków i Elektroników

IESG

Internet Engineering Steering Group — Internetowa Grupa Nadzorcza ds. Technicznych

IETF

Internet Engineering Task Force — Internetowy Zespół ds. Technicznych

IGMP

Internet Group Management Protocol — internetowy protokół zarządzania grupami

IGP

Interior Gateway Protocol — protokół bramy wewnętrznej

IGRP

Interior Gateway Routing Protocol — protokół routingu bram wewnętrznych

IP

Internet Protocol — protokół internetowy

IPNG

Internet Protocol Next Generation — protokół internetowy nowej generacji

IPX

Internetwork Packet Exchange — internetowa wymiana pakietów

IRTF

Internet Research Task Force — Zespół ds. Badań nad Internetem

ISDN

Integrated Services Digital Network — cyfrowa sieć zintegrowanych usług

IS-IS

Intermediate System to Intermediate System protocol — protokół pomiędzy systemami pośrednimi

ISN

initial sequence number — początkowy numer porządkowy

ISO

International Organization for Standarization — Międzynarodowa Organizacja Standaryzacyjna

ISOC

Internet Society — społeczność internetowa

L LAN

Local Area Network — sieć lokalna

LAPB

Link Access Procedure, Balanced — procedura dostępu łącza (zrównoważona)

LAPD

Link Access Procedure, D channel — procedura dostępu łącza (kanał D)

LBX

low bandwidth X — protokół X dla sieci o niskiej przepustowości

472

TCP/IP. SZKOŁA PROGRAMOWANIA

LCP

link control protocol — protokół sterowania łączem

LFN

long fat network — długa „gruba" sieć (szerokopasmowa, ale z dużym opóźnieniem)

LIFO

last in, first out — ostatni na wejściu, pierwszy na wyjściu

LLC

logical link control — sterowanie łączem logicznym

LSA

Link-state advertisement — rozgłoszenie stanu łącza

LSRR

loose source and record route — trasa z dowolnym źródłem i zapisem

MAC

media access control — sterowanie dostępem do nośnika

MBONE

multicast backbone — sieć szkieletowa z multiemisją

MIB

management information base — baza informacji o zarządzaniu

MILNET

Military Network — sieć wojskowa

MIME

multipurpose Internet mail extensions — uniwersalne rozszerzenia poczty internetowej

MS

message store — pamięć komunikatów

M/S

master/slave — nadrzędny/wtórny

MSL

maximum segment lifetime — maksymalny czas życia segmentu

MSAU

Multi-station Access Units — koncentratory MSAU

MSS

maximum segment size — maksymalna wielkość segmentu

MTA

message transfer agent — agent transferu wiadomości

MTU

maximum transfer unit — maksymalna jednostka transferu

MUX

Multiplexer — multiplekser

NAT

Network Address Translation — tłumaczenie adresów sieciowych

NBMA

non-broadcast multi-access — wielodostęp bez rozgłaszania

NCP

Network Control Protocol — protokół sterowania siecią

M

N

Dodatek B • SKRÓTY I AKRONIM Y

NDN NetBIOS

473

non-delivery notification — powiadomienie o niedostarczeniu Network Basic Input Output System — podstawowy sieciowy system wejścia-wyjścia

NFS

Network File System — sieciowy system plików

NIC

network inteface card — karta interfejsu sieciowego

NIT

network interface tap — rozgałęźnik interfejsu sieciowego

NNTP

Network News Transfer Protocol — sieciowy protokół transferu wiadomości

NOAO

National Optical Astronomy Observatories — Narodowe Obserwatoria Astronomiczne USA

NOP

no operation — brak działania

NSFNET

National Science Foundation network — sieć Narodowej Fundacji Naukowej

NSI

NASA Science Internet — sieć naukowa NASA

NSSA

not so stubby area — obszar nie tak szczątkowy

NTP

Network Time Protocol — sieciowy protokół czasu

NVT

network virtual terminal — wirtualny terminal sieciowy

Opcode

operation code — kod operacji

OSF

Open Software Foundation — Stowarzyszenie Otwartego Oprogramowania

OSI

Open Systems Interconnection — połączenie otwartych systemów (model referencyjny OSI)

OSPF

Open Shortest Path First — otwórz najpierw najkrótszą ścieżkę

PA

protocol address — adres protokołu

PDU

protocol data unit — jednostka danych protokołu

TCP/IP. SZKOŁA PROGRAMOWANIA

PI

protocol interpreter — interpretator protokołu

POSIX

Portable Operating System Interface — przenośny interfejs systemu operacyjnego

PPP

Point-to-Point Protocol — protokół punkt-punkt

PRI

Primary Rate Interface — interfejs pierwotno-grupowy, interfejs pierwotny

PSH

push flag — znacznik (flaga) push w nagłówku TCP

QoS

Quality of Service — j akość usług

RARP

Reverse Address Resolution Protocol — protokół odwrotnego określania adresu

RFC

Request for Comment — prośba o komentarze

RFI

radio frequency interference — interferencje radiowe

RIP

Routing Information Protocol — protokół informacji o routingu

RPC

remote procedure call — zdalne wywołanie procedury

RR

resource record — rekord zasobów

RRQ

read request — żądanie czytania

RST

reset flag — znacznik zerowania w nagłówku TCP

RTO

retransmission timeout — przekroczenie dopuszczalnego czasu retransmisji

RTT

round-trip time — czas obiegu powrotnego

SA

source address — adres źródłowy

SACK

Selective Acknowledgement — wybiórcze potwierdzenie

SAP

service access point — punkt dostępu do usług

Dodatek B • SKRÓTY I AKRONIM Y

475

SDLC

Synchronous Data Link Control — synchroniczne sterowanie łącza danych

SLIP

Serial Line Internet Protocol — protokół internetowy łącza szeregowego

SMI

structure of management information — struktura informacji o zarządzaniu

SMTP

Simple Mail Transfer Protocol — prosty protokół transferu poczty

SNA

System Network Architecture — architektura sieci systemu

SNAP

Subnetwork Access Protocol •— protokół dostępu podsieci

SNMP

Simple Network Management Protocol — prosty protokół zarządzania siecią

SQE

Signal Quality Error — błąd jakości sygnału

SRRT

smooth round trip timer — licznik uśrednionego czasu przebiegu zwrotnego SSAP (source service access point — punkt dostępu usług źródłowych)

SWS

silly window syndrome — syndrom „głupiego okna"

SYN

synchronize sequence numbers flag — znacznik (flaga) synchronizacji numerów kolejnych w nagłówku TCP

TCP

Transmission Control Protocol — protokół sterowania transmisją

TFTP

Trivial File Transfer Protocol — trywialny protokół transmisji plików

TLI

Transport Layer Interface — interfejs warstwy transportowej

ToS

type-of-service — typ usług

TTL

time-to-live — czas życia

TUBA

TCP and UDP with bigger addresses TCP i UDP z większymi adresami

Telnet

Telecommunication Network Protocol — protokół sieci telekomunikacyjnej

476

TCP/IP. SZKOŁA PROGRAMOWANIA

U UA

user agent — agent użytkownika

UDP

User Datagram Protocol — protokół datagramów użytkownika

Ul

user interface — interfejs użytkownika

URG

urgent pointer flag — znacznik (flaga) wskaźnika pilności w nagłówku TCP

UUCP

Unix-to-Unix Copy Protocol — protokół kopiowania UNIX-UNIX

vc

virtual circuit — obwód wirtualny

VLAN

Virtual Local Area Network — wirtualna sieć lokalna

VLSM

Variable Length Subnet Mask — maska podsieci o zmiennej długości

WAN

Wide Area Network — sieć rozległa

WRQ

write request — żądanie zapisu

WWW

World Wide Web — sieć światowa

V

W

X -Z XDR

external data representation — zewnętrzna reprezentacja danych

XID

exchange id, transaction id — identyfikator (ID) wymiany lub transakcji X/Open Transport Layer Interface — interfejs warstwy transportowej X/Open

NUMERY PORTÓW TOP/tJIP Tabela C .l. Lista numerów portów TCP/UDP Numer dziesiętny

Stowo kluczowe

Protokół

Opis

20

FTP-DATA

TCP

transfer plików (domyślna wartość dla danych)

21

FTP

TCP

transfer plików (sterowanie)

23

TELNET

TCP

telnet

25

SMTP

TCP

prosty protokół transferu poczty

37

NTP

TCP

protokół czasu lub czasu sieciowego

49

LOGIN

TCP

protokół logowania hosta

53

DNS

TCP/UDP

usługa nazw domen

63

VIA-Systems-FTP

TCP

VIA-Systems-FTP

67

BOOTPS

UDP

serwer protokołu rozruchowego

68

BOOTPC

UDP

klient protokołu rozruchowego

69

TFTP

UDP

tryw ia lny transfer plików

69

TFTP

TCP

tryw ia lny protokół transferu plików

70

Gopher

TCP

usługa plików Gopher

80

WWW

TCP

usługi W W W

137

NetBIOS-NS

TCP

usługa nazw NetBIOS

139

NetBIOS-DG

TCP

usługa datagram ów NetBIOS

161

SNMP

TCP

prosty protokół zarządzania siecią

161

SNMP

TCP

prosty protokół zarządzania siecią

179

BGP

TCP

protokół bramy granicznej

478

TCP/IP. SZKOŁA PROGRAMOWANIA

m SŁOWNICZEK 100Base-FX — implementacja standardu IEEE 802.3 (Ethernet) o maksymalnej przepustowości 100 Mb/s wykorzystująca wielofunkcyjny kabel światłowodowy. 100Base-T — implementacja standardu IEEE 802.3 (Ethernet) o maksymalnej przepustowości 100 Mb/s wykorzystująca skrętkę dwużyłową (kabel UTP). 100Base-T4 — implementacja standardu IEEE 802.3 (Ethernet) o maksymalnej przepustowości 100 Mb/s wykorzystująca cztery pary skrętki dwużyłowej (kabla UTP) Kategorii 3, 4 lub 5. 100Base-TX — implementacja standardu IEEE 802.3 (Ethernet) o maksymalnej przepustowości 100 Mb/s wykorzystująca dwie pary skrętki dwużyłowej (kabla UTP) wysokiej jakości. Korzystając z tego standardu możemy podłączać urządzenia kompatybilne z AUI. 100Base-X — szybka technologia Ethernet o maksymalnej przepustowości 100 Mb/s, wykorzystująca wielofunkcyjny kabel światłowodowy. Odwołuje się do standardów 100BaseFX i 100BaseTX. 100VG-AnyLAN — technologia Fast Ethernet i Token-Ring o maksymalnej przepustowości 100 Mb/s wykorzystująca skrętkę dwużyłową (kabla UTP) kategorii 3 ,4 lub 5. 10Base2 — implementacja standardu IEEE 802.3 (Ethernet), wykorzystująca cienki kabel koncentryczny (3/8 cali) o maksymalnej odległości 185 m i przepustowości 10 Mb/s (megabitów na sekundę). 10Base5 — implementacja standardu IEEE 802.3 (Ethernet), wykorzystująca cienki kabel koncentryczny (3/8 cali) o maksymalnej odległości 500 m i przepustowości 10 Mb/s (megabitów na sekundę).

480

TCP/IP. SZKOŁA PROGRAMOWANIA

lOBase-T — implementacja standardu IEEE 802.3 (Ethernet) wykorzystująca skrętkę dwużyłową o maksymalnej przepustowości 10 Mb/s. Korzystając z tego standardu możemy podłączać urządzenia kompatybilne z AUI. !Base5 — implementacja standardu IEEE 802.3, wykorzystująca cienki kabel koncentryczny (3/8 cali) o maksymalnej odległości 500 m i przepustowości 1 Mb/s (megabitów na sekundę).

ABR (Area Border Router — router granicy obszaru) — wysyła ogłoszenia międzyobszarowe między bezpośrednio połączonymi obszarami a głównym szkieletem sieci. AC (Access Control — kontrola dostępu) — bajt DLC w sieci IEEE 802.5 Token-Ring zawierający podstawowe informacje ramki oraz wskaźnik (token). access list (lista dostępu) — lista przechowywana przez routery kontrolujące dostęp wielu usług do lub z routera. access method (metoda dostępu) — środki, za pomocą których urządzenia sieciowe uzyskują dostęp do sieci. access server (serwer dostępowy) — procesor łączący urządzenia asynchroniczne do sieci LAN lub WAN poprzez oprogramowanie emulacyjne. ACK (ACRmowledge — potwierdź) — pakiet sieciowy potwierdzający odbiór danych. active monitor — komputer sterujący w sieci Token-Ring. Steruje żetonem (token) i innymi kwestiami związanymi z funkcjonowaniem sieci. Address Resolution Protocol (ARP) — protokół używany w TCP/IP do przełożenia adresu IP na adres sprzętowy. Definiowany w zestawie TCP/IP, może być również definiowany w zestawie Banyan VINES. adres — struktura danych służąca do identyfikacji unikatowego obiektu. adres docelowy (destination address) — część wiadomości wskazująca do kogo jest ona adresowana. adres funkcyjny (functional address) — ograniczony docelowy adres rozgłoszeniowy dla sieci IEEE 802.5 Token-Ring. Poszczególne bity adresu oznaczają atrybuty, jakie powinny posiadać stacje mogące odbierać ramki. Adres podobny do adresu rozgłoszeniowego. adres IP (IP address) — 32-bitowy adres przypisany do hosta poprzez TCP/IP. Nazywany czasem adresem internetowym.

Dodatek D • SŁOW NICZEK

481

adres podsieci (subnet address) — część adresu IP przyporządkowana podsieci poprzez maskę podsieci. adres sieciowy (network address) — adres warstwy sieci odwołujący się do logicznego urządzenia sieciowego; znany również pod nazwą adresu protokołu. adres unicast (unicast adress) — adres pojedynczego urządzenia sieciowego. adres źródłowy (source address) — część wiadomości wskazująca nadawcę. adresy prywatne (private addresses) — zarezerwowane adresy IP, wyłącznie do użytku wewnętrznego. Należą do nich adresy: 10.0.0.0 - 10.255.255.255, 172.16.0.0 -172.31.255.255 oraz 192.168.0.0 - 192.168.255.255. ADSP (Apple Talk Bata-Stream Protocol — protokół strumienia danych Apple Talk) — protokół ustanawiający i utrzymujący komunikację pełnodupleksową pomiędzy dwoma gniazdami AppleTalk. agent — program przetwarzający zapytania i odsyłający odpowiedzi. aktualizacja flash (flash update) — aktualizacja routingu wysłana asynchronicznie w odpowiedzi na zmianę topologii sieci. algorytm — zdefiniowana zasada lub proces przechodzenia od problemu do rozwiązania. algorytm drzewa rozpinającego (spanning-tree algorithm) — algorytm wykorzystywany do tworzenia drzewa rozpinającego. algorytm routingu wektora odległości (distance vector routing algorithm) — klasa algorytmów routingu nakazujących wszystkim routerom wysyłanie niektórych lub wszystkich tablic routingu do routerów sąsiadujących. AMI (Altrenative Mark Inversion) — transmisja pulsacyjna schematu kodującego T l line wykorzystująca przemienną polaryzację. ANSI (American National Standards) — organizacja pomagająca w opracowywaniu standardów komunikacyjnych i handlowych. API (Application Programming Interface — programowy interfejs aplikacji) — interfejs programowy umożliwiający działanie na granicy warstw protokołów. Określa funkcje oraz dane używane przez jeden moduł programu, w celu uzyskania dostępu do drugiego modułu. Apple Talk — zestaw protokołów komunikacyjnych zaprojektowanych przez firmę Apple Computers. architektura (Architecture) — określa sposób w jaki system został zaprojektowany oraz jak jego komponenty łączą się i współpracują ze sobą.

482

TCP/IP. SZKOŁA PROGRAMOWANIA

ARCnet — opracowany przez Datapoint Corporation wariant sieci o architekturze token bus przeznaczony do sieci LAN opartej na komputerach PC. Może obsługiwać do 255 węzłów. Różne wersje pracują z prędkością 1,5 Mb/s, 20 Mb/s i 100 Mb/s. ARPAnet — poprzedniczka Internetu. Sieć ARPAnet została zbudowana przez Agencję Zaawansowanych Projektów Badawczych Departamentu Obrony USA w 1969 roku i miała za zadanie umożliwiać komunikację, nawet w przypadku awarii jej części. AS (Autonomous System — system autonomiczny) — kilka, wspólnie administrowanych sieci z jednolitą koncepcją routingu. ASBR (Autonomous System Boundary Routers — router granicy systemu autonomicznego) — ABR zlokalizowany pomiędzy OSPF systemu autonomicznego a siecią non-OSPF. ASCII (American Standard Code for Information Interchange — standardowy amerykański kod wymiany informacji) — przyporządkowuje kody liczbowe znakom z klawiatury. Kod wykorzystywany w aplikacjach zarówno PC, jak i nie IBM-owych komputerach mainframe. AUI (Attachment Unit Interface — kabel AUI) — kabel łączeniowy nadajnikaodbiornika, używany do podłączenia karty sieciowej umieszczonej wewnątrz komputera do sieci Ethernet (10base5 lub 10Base-F). AutoSPID (Automatic Service Profile Identifier) — cecha adaptera terminala, pobiera informacje SPID z kompatybilnego przełącznika (switch).

B B channel (Bearer channel — kanał B) — jeden z kanałów komunikacyjnych o przepustowości 64 kb/s przenoszący dane na złączach ISDN. bajt (byte) — ciąg ośmiu kolejnych cyfr binarnych BDR (backup designated router — zapasowy router desygnowany) — w OSPF, zapasowy router DR. BECN (Backward Explicit Congestion Notification) — protokół przekazywania ramek (Frame Relay). Szósty bit w drugim oktecie nagłówka Frame Relay. Informuje urządzenie abonenta o zatorze na kierunku powrotnym. bezklasowe protokoły routingu (classless routing protocols) — bezklasowe protokoły routingu, które wysyłają informacje dotyczące długości prefixu. bezpołączeniowo (connectionless) — transfer danych nie wymagający ustanowienia połączenia wirtualnego.

Dodatek D • SŁOW NICZEK

483

BGP (Border Gateway Protocol — protokół bram granicznych) — BGP, opisany w RFC 1771, umożliwia bezpętlowe, trasowanie międzydomenowe pomiędzy systemami autonomicznymi. binarny (Binarny) — system liczbowy wykorzystujący 1 i 0 (l=w ł.; 0=wył.). BIOS (Basic Input/Output System — podstawowy system wejścia/wyjścia) — zestaw procedur sprzętowych wspomagających transfer informacji pomiędzy elementami systemu. Włącznie z pamięcią, dyskami i monitorem. bit — znak binarny używany w binarnym systemie liczbowym. Przyjmuje wartości 0 lub 1. bit parzystości (parity bit) — bit dołączany do wiązki bitów w celu utrzymania nieparzystej lub parzystej liczby bitów, wykorzystywany do wykrycia błędu w przesyłanych danych binarnych. błąd (Error) — protokół XNS dzięki któremu stacja informuje o otrzymaniu oraz odrzuceniu uszkodzonego pakietu. Interpretowany w zestawie XNS PI. BNC (Bayonet NetWork Connector — złącze sieciowe Bayonet) — standardowy kabel koncentryczny; wykorzystywany w sieciach ARC-NET i Thin Ethernet („Tania sieć"). BOOTP (Boot protocol — protokół startowy) — protokół TCP/IP wykorzystywany do pobierania programów rozruchowych dla stacji sieciowych. Interpretowany w zestawie TCP/IP PI. BPDU (Bridge protocol data unit — jednostka danych protokołu mostu) — pakiet protokołu spanning-tree wysyłany w stałych odstępach czasowych w celu wymiany informacji pomiędzy mostami sieci. bps (bits per second — bit na sekundę b/s) — jednostka szybkości przesyłania danych. brama (gateway) — komputer łączący dwie odrębne sieci. Jednakże w terminologii TCP/IP bramka łącząca dwie odrębnie administrowane podsieci, nie koniecznie musi mieć uruchomione te same protokoły sieciowe. bufor (buffer) — program, obszar pamięci RAM lub oddzielne urządzenie do przechowywania danych. Np.: Sniffer NetWork Analyzer wyszukuje serwery buforowe pełniące funkcje tymczasowych miejsc przechowania danych odnalezionych w sieci zanim zostaną one przeanalizowane i zapisane na dysku. buforowanie (caching) — rodzaj kopiowania polegający na wykorzystywaniu informacji zapamiętanych w poprzedniej transakcji do transakcji późniejszych.

484

TCP/IP. SZKOŁA PROGRAMOWANIA

c CA (Certificate Authority — urząd wydawania certyfikatów) — urząd potwierdzający oraz wydający identyfikatory. CCITT (Consultative Committee for International Telegraphy and Telephony) — poprzednia nazwa Międzynarodowego Związku Telekomunikacji (International Telecommunications Union (ITU)) czyli specjalistycznego organu Narodów Zjednoczonych. Opracowuje wiele standardów w zakresie przesyłu danych w sieciach, przełączników telefonicznych, terminali oraz systemów cyfrowych. CHAP (Challenge Handshake Authentication Protocol — protokół uwierzytelnienia wzajemnego połączenia) — protokół bezpieczeństwa obsługiwany równolegle z enkapsulacją PPP w celu zapobiegania nieautoryzowanemu dostępowi. chat script — grupa trzech łańcuchów (ustanowienia, nasłuchu oraz rozłączenia) kontrolujących parametry komunikacyjne urządzeń asynchronicznych. CIDR (Classless Interdomain Routing — bezklasowy routing międzydomenowy) — wiele kolejnych adresów klasy C będących własnością ISP, które zostały przypisane klientom oraz scalone w jeden bardziej znany adres IP. CIR (Committed Information Rate • —■przypisana szybkość informacji) — największa możliwa prędkość przesyłania bitów przez sieć frame relay za pomocą PVC. CIR jest przypisywany w trakcie subskrypcji do usługi frame relay. CLI (Command-Line Interface — interfejs wiersza poleceń) — interfejs umożliwiający użytkownikowi współpracę z systemem operacyjnym poprzez wprowadzanie poleceń oraz argumentów opcjonalnych. CODEC (Coder-Decoder — koder-dekoder) — urządzenie używane często przez PCM do przetwarzania sygnałów analogowych na cyfrowy strumień bitów oraz sygnałów cyfrowych na analogowe. CPU (Central Processing Unit — procesor) — główny procesor urządzenia, np. komputera lub routera. CRC (Cyclic Redundancy Check — cykliczna kontrola nadmiarowa) — ciąg sprawdzający, zazwyczaj w postaci 2 lub 4 bajtów na końcu ramki, wykorzystywany do wykrywania błędów w części ramki zawierającej dane. CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance — metoda wielokrotnego dostępu z nasłuchiwaniem nośnej z detekcją kolizji) — technologia swobodnego dostępu lub kontroli połączenia. Algorytm używany w sieciach LocalTalk do kontroli transmisji.

Dodatek D • SŁOWNICZEK

485

CSU (Channel Service Unit — moduł obsługi kanału) — interfejs dla wspólnych urządzeń transmisyjnych, który zapewnia prawidłowy kształt oraz czas transmisji sygnałów cyfrowych. Często występuje w połączeniu z DSU (Data Service Unit (modułem obsługi danych). cut-trough packet switching — komutowanie pakietu polegające na przesyłaniu strumienia danych przez przełącznik w taki sposób, że przednia krawędź pakietu wychodząc znajduje się w porcie wychodzącym zanim pakiet przejdzie przez port wchodzący. czas odpowiedzi (response time) — czas pomiędzy zgłoszeniem zapytania, a otrzymaniem odpowiedzi. częściowa krata (partial mesh) — sieć, w której urządzenia są zorganizowane w topologii kraty, ale niektóre węzły nie są połączone ze wszystkimi.

D Channel — kanał danych wykorzystywany do przesyłania sygnałów pomiędzy sprzętem przełączającym a sprzętem użytkownika. Kanał ten nie jest przeznaczony do przenoszenia danych użytkownika. DAC (Dual Attachment Concentrator — koncentrator podwójnie przyłączony) — koncentrator oferujący dwa podłączenia do sieci FDDI, zdolny do przystosowania podwójnego pierścienia FDDI oraz innych portów w celu podłączenia innych koncentratorów lub stacji FDDI. DAS (Dual Attachment Station — stacja o podwójnym przyłączeniu) — stacja FDDI oferująca dwa podłączenia do podwójnego pierścienia FDDI z przepływem w drugą stronę. datagram — informacje logicznie pogrupowane przez urządzenie transmisyjne w jednostkę warstwy sieci bez konieczności wcześniejszego ustanawiania łącza wirtualnego. DB-15 — standardowe łącze 15-pinowe wykorzystywane przez urządzenie nadawczo-odbiorcze, kabel połączeniowy oraz stację IEEE 802.3 lub komponenty sieci Ethernet. DB-25 — standardowe łącze 25-pinowe wykorzystywane w komputerach jako porty równoległe (łącze żeńskie w obudowie IBM PC) lub port szeregowy I/O (łącze męskie w obudowie IBM PC). DB-9 — standardowe łącze 9-pinowe wykorzystywane przez komputery do połączenia w sieci Token-Ring (żeńskiego), przez port szeregowy T/O (męski), oraz wyjście RGBI (wykorzystywane również przez LocalTalk).

486

TCP/IP. SZKOŁA PROGRAMOWANIA

DCE (Data Circuit-terminating Equipment — urządzenie komunikacyjne transmisji danych) — nazywany również sprzętem komunikacji danych, w szeregowym łączu komunikacyjnym jest to urządzenie podłączające DTE-sy do linii lub kanału komunikacyj nego. DDP (Datagram Delivery Protocol — protokół dostarczania datagramu) — dodaje usługi do leżącego poniżej protokołu dostępu dzięki włączeniu intersieci połączonej sieci AppleTalk, z pakietami adresowymi odniesionymi do gniazda w węźle. Interpretowany przez zestaw protokołów AppleTalk PT. DDR (Dial-on-Demand-Routing — trasowanie dzwonienia na żądanie) — technologia, dzięki której serwer Cisco może automatycznie inicjować i zamykać sesje komutowane na żądanie stacji transmisyjnej. dedykowana LAN (dedicated LAN) — segment sieci przypisany pojedynczemu urządzeniu. dekapsulacja (decapsulation) — odpakowywanie danych z nagłówka określonego protokołu. DHCP (Dynamie Host Configuration Protocol — protokół dynamicznej konfiguracji hostów) — umożliwia dynamiczną alokację adresów, dzięki czemu adresy mogą być ponownie używane, jeżeli host dłużej ich nie potrzebuje. DIP switch (Dual Inline Package switch — mikroprzełącznik w obudowie podłużnej dwurzędowej) — przełącznik na płycie układu; do przełączenia go potrzebny jest zwykle mały śrubokręt. Ma dwa położenia włącz i wyłącz. Płyta ma najczęściej panele z wieloma przełącznikami DIP, które wykorzystywane są do jej konfigurowania. DISC — rozłączenie. Ramka LLC nie zawierająca danych informująca o przerwaniu połączenia ustanowionego wcześniej przez SABM lub SABME. DLC (Data Link Control — sterowanie łączem danych) — najniższa warstwa protokołów w przesyłanej ramce. Jej pola zawierają zazwyczaj adres źródłowy, adres docelowy oraz czasami informacje dodatkowe. DLCI (Data Link Connection Identifier — identyfikator z łącza danych) — 10-bitowy numer używany przez protokół frame relay do identyfikacji łącza wirtualnego. DM (Disconnected Mode — tryb rozłączenia) — wiadomość LLC potwierdzająca przerwanie poprzednio ustanowionego połączenia. DNS (Domain Name Service — usługa nazw domen) — protokół TCP/IP wykorzystywany do wyszukiwania informacji o źródłach dystrybuowanych pomiędzy różnymi serwerami nazw. Interpretowany w zestawie TCP/IP.

Dodatek D • SŁOW NICZEK

487

domena kolizyjna (Collision domain) — obszar w sieci Ethernet, w którym znajdują się informacje o zniszczonych ramkach. domena pasma (bandwidth domain) — wszystkie urządzenia korzystające z tej samej szerokości pasma. domena routingu (routing domain) — grupa systemów końcowych i pośrednich, pracujących na podstawie tego samego zestawu dostępność (availability) — czas aktywności sieci. DR (Designated Router—router desygnowany) — router OSPF generujący LSA dla sieci wielodostępnej. drzewo rozpinające (spanning tree) — metoda tworzenia wolnej od pętli topologii logicznej rozszerzonej sieci LAN. Formowanie topologii drzewa rozpinającego dla przesyłania wiadomości przez mosty jest oparte o standardowy algorytm drzewa rozpinającego zdefiniowany w IEEE 802.id. DS1 (Digital Signal level 1 — sygnał cyfrowy poziomu 1) — linie T l. Podstawowy sygnał cyfrowy dla transmisji przez urządzenia Tl. Sygnał DS1 składa się z 24 kanałów o przepustowości 64 kB/s (nazywanych DSO, lub sygnałami cyfrowymi poziomu 0), plus kanałem 8 kB/s wykorzystywanym do synchronizacji i sygnalizacji — dla całkowitej przepustowości 1544 kB/s. DSAP (Destination Service Access Point — docelowy punkt dostępu do usług) — LLC SAP dla protokołu, który będzie używ any przez stację docelową w celu odkodowania ramki danych. DSL (Digital Subscriber Line — cyfrowa linia abonencka) — technologia używana pomiędzy klientem a dostawcą usługi korzystająca z zasięgu wysokich częstotliwości w celu zwiększenia przepustowości standardowego okablowania miedzianego. DSO (Digital Signal level 0 — sygnał cyfrowy poziomu 0) — linie Tl. Pojedynczy kanał 64 kB/s w sygnale DS1. Patrz również DS1 i DS3. DSU (Data Service Unit — moduł obsługi danych) — urządzenie podłączające sprzęt terminala do cyfrowych linii komunikacyjnych. Patrz również CSU. DTE (Data Terminal Equipment — urządzenie końcowe transmisji danych) — ogólne określenie wykorzystywane do opisu maszny hosta lub użytkownika końcowego przy szeregowym łączu komunikacyjnym. DUAL (Diffusing Update Algorithm) — algorytm konwergencji wykorzystywany w ulepszonym IGRP zapewniający przeprowadzanie operacji loop-free w trakcie obliczania trasy.

T

488

TCP/IP. SZKOŁA PROGRAMOWANIA

dupleks (Duplex) — rodzaj transmisji danych, pełnoduplekowej (w pełni dwukierunkowej) lub półdupleksowej (połowicznie dwukierunkowej). Transmisji pełnodupleksowa umożliwia jednoczesną komunikację dwukierunkową. Półdupleks oznacza, że tylko jedna strona może nadawać. DVMRP (Distance Vector Multicast Routing Protocol — protokół routingu grupowego wg algorytmu wektora odległości) — protokół routingu datagramów rozgłoszeniowych w sieci.

E E l — cyfrowe łącze transmisyjne o przepustowości 2.048 Mb/s (CCITT wersji Tl). EBCDIC (Extended Binary Coded Decimal Interchange Code — rozszerzony dziesiętny kodowany binarny kod wymiany) — przyporządkowanie kodów liczbowych znakom używanym w komputerach mainframe firmy IBM oraz protokołach komunikacyjnych zdefiniowanych przez IBM. Echo — (1) Protokół zapytania/odpowiedzi XNS używany do zweryfikowania obecności danego hosta. (2) Protokół AppleTalk umożliwiający każdemu węzłowi wysyłanie datagramów do dowolnego innego węzła oraz odbieranie w zamian echa kopii pakietu w celu zweryfikowania obecności tego węzła lub dokonania pomiaru opóźnień. Interpretowany jest w zestawie AppleTalk (3) Protokół wysyłany przez ramkę Net RPC w Banyan VINES. EGP (Exterior Gateway Protocol — protokół bramy zewnętrznej) — protokół TCP/IP używany do wymiany informacji routingu pomiędzy bramkami należącymi do tych samych lub innych systemów. EIA (Electronic Industries Association — stowarzyszenie przemysłu elektronicznego) — organizacja ustalająca standardy dla różnych składowych sprzętu elektronicznego. EIGRP (Extended Interior Gateway Routing Protocol — rozszerzony protokół routingu bramy wewnętrznej) — ulepszona wersja IGRP oraz zestawu protokołów routingu Cisco używanych w sieciach TCP/IP oraz OSI. ekspansja (expansion) — przetwarzanie przez algorytm skompresowanego zestawu danych w celu przywrócenia jego pierwotnego rozmiaru. ELAP — patrz LAP. enkapsulacja, hermetyzacja (Encapsulation ) — przekształcanie pakietu do odpowiedniego formatu poprzez dodanie nagłówków obudowujących właściwą treść.

Dodatek D • SŁOWNICZEK

489

ESF (Extended Superframe Format — rozszerzony format superframe) — Tl. Zmodyfikowany format DS1 wykorzystujący 193 bit do sygnalizowania problemów Unii. SF to typ ramkowania używany w obwodach T l, składający się z 24 ramek po 192 bity każda, ze 193-im bitem zapewniającym odpowiednią synchronizację czasową i inne funkcje. ESF to rozszerzona wersja SF. Ethernet — standard sieciowy CSMA/CD wprowadzony przez firmę Xerox; podobny do (oraz często używany zamiennie) standardu IEEE 802.3. Ethertype — 2-bajtowy kod protokołu wykorzystywany przez kilku producentów, ale niezależny od standardu IEEE 802.3

FC (Frame Control — kontrola ramki) — w sieci Token-Ring bajt DLC zawierający informacje o rodzajach ramek. FCS — patrz sekwencja kontroh ramki (frame check sequence). FDDI (Fiber Distributed Data Interface — interfejs danych rozprowadzanych światłowodem) — standard ANSVISO definiujący typ dostępu do nośnika optycznego dla 100 Mb/s LAN. Obejmuje przekazywanie żetonu w topologii fizycznej podwójnego pierścienia. FE (Framing Error — błąd ramkowania) — błąd pojawiający się z powodu nieprawidłowego ramkowania. w transmisji asynchronicznej powodem jest najczęściej nieprawidłowość w komórce bitu stopu. FECN (Forward Explicit Congestion Notification) — piąty bit drugiego oktetu nagłówka frame relay. Używany do informowania urządzenia abonenta o kongestii na kierunku wychodzącym. FEP (Front-End Processor — procesor czołowy) — znajduje się przed komputerem i odpowiada za usuwanie usterek telekomunikacyjnych, dzięki czemu komputer może skoncentrować się na przetwarzaniu. filtr (filter) — program Sniffer analizuje aplikacje korzystające z wielu rodzajów filtrów, w tym filtrów przechwytywania, które określają ramki odrzucane oraz przepuszczane przez analizator. Sniffer korzysta również z filtrów wyświetlania określających, która z ramek znajdujących się w buforze będzie wyświetlana. Nie wyświetlenie ramki nie są usuwane z pamięci. fragmentacja (fragmentation) — proces dzielenia pakietu na mniejsze jednostki podczas jego transmisji przez sieć, która nie może przesyłać pakietu w jego oryginalnym rozmiarze.

490

TCP/IP. SZKOŁA PROGRAMOWANIA

frame check sequence (FCS — sekwencja kontroli ramki) — 16-bitowe pole w protokołach zorientowanych na bity dodawane na końcu ramki zawierającej informacje o kontroli błędów transmisji. Frame Relay — strumieniowy protokół dostępu używany powszechnie w łączności LAN. FRMR (Frame Reject — odrzucenie ramki) — polecenie lub odpowiedź LLC informujące o odrzuceniu poprzedniej ramki z powodu jej formatu. Ramka FRMR składa się z pięciu bajtów danych wyjaśniających dlaczego poprzednia ramka była nieprawidłowa. FS (Frame Status — stan ramld) — bajt dołączony do ramki w sieci Token-Ring następującej po CRC. Zawiera bity rozpoznania adresu oraz kopii ramki. FTP (File Transfer Protocol — protokół przesyłania plików) — (1) protokół oparty na TCP/IP służący do niezawodnego przesyłania plików. Interpretowany jest w zestawie TCP/IP PI. (2) protokół przesyłany przez ramkę Net RPC w Banyan VINES. G

gniazdo (Socket) — logicznie adresowalna jednostka w węźle, służąca do bardziej dokładnej identyfikacji nadawcy lub odbiorcy. GNS (Get Nearest Server — odszukaj najbliższy serwer) — pakiet zapytania wysyłany przez klienta w sieci IPX w celu zlokalizowania najbliższego aktywnego serwera określonego typu. grupa robocza (workgroup) — kilka stacji roboczych oraz serwerów w LAN zaprojektowanych tak, aby wzajemnie się komunikować i wymieniać dane. GUI (Graphical User Interface — graficzny interfejs użytkownika) — system operacyjny lub środowisko wyświetlające opcje w postaci ikon lub symboli obrazkowych.

H BLC (High-Level Bata Link Control — wysokopoziomowe sterowanie łączem transmisji danych) — protokół połączeniowy wprowadzony przez ISO. Nie obsługuje uwierzytelniania ani kompresji danych. Ponieważ nie potrafi identyfikować typu protokołów przenoszonych wewnątrz pakietu, może jednocześnie przenosić tylko jeden protokół. Implementacje poszczególnych dostawców różnią się. host — komputer w sieci.

Dodatek D • SŁOW NICZEK

491

IARP (Inverse Address Resolution Protocol) — IARP umożliwia stacji frame relay odkrycie adresu protokołu odpowiadającego określonemu adresowi sprzętowemu. ICMP (Internet Control Message Protocol —protokół komunikatów sterujących Internetu) — protokół TCPAP wykorzystywany głównie do zgłaszania błędów w transmisji datagramu. Interpretowany w zestawie TCP/IPID — identyfikator. IEEE (Institute of Electrical and Electronics Engineers, Inc.) — organizacja standaryzująca skupiająca się głównie na warstwach Fizycznej oraz Łącza Danych oraz zarządzaniu siecią LAN. Dokumenty standaryzujące są dostępne pod adresem 345 East 47th Sheet, New York, NY 10017. IETF (Internet Engineering Taskforce — grupa robocza do spraw technicznych sieci Internet) — mała grupa ukierunkowana na standardy, podzielona na konkretne dziedziny TCPAP i Internetu. Każda dziedzina ma niezależnego kierownika i grupy robocze. IGMP (Internet Group Management Protocol — internetowy protokół zarządzania grupami) — wykorzystywany do informowania sąsiadujących routerów rozgłoszeniowych o grupach hostów istniejących w określonych sieciach lokalnych. IGF (Interior Gateway Protocol — protokół bramy wewnętrznej) — protokół internetowy z systemem autonomicznym wykorzystywany do wymiany informacji o routingu. IGRP (Interior Gateway Routing Protocol — protokół routingu bram wewnętrznych) — protokół routingu firmy Cisco zaprojektowany do użytku lokalnego, w przeciwieństwie do protokołu powszechnego. information frame (I-Frame) — rodzaj ramki LLC, HDLC lub SDLC wykorzystywany do wysyłania sekwencji danych, które muszą być potwierdzone. interfejs (Interface) — (1) połączenie pomiędzy dwoma urządzeniami lub systemami (2) połączenie sieciowe w terminologii routingu (3) wspólna granica w terminologii telefonicznej (4) granica pomiędzy sąsiadującymi warstwami modelu OSI. interfejs równoległy (parallel interface) — interfejs umożliwiający transmisję równoległą (lub transmisję symultaniczną bitów tworzących znak lub bajt) poprzez oddzielne kanały lub na innych częstotliwościach tego samego kanału. interfejs S/T (S/T Interface) — w ISDN, łącze pomiędzy interfejsem BRI a urządzeniem NT1.

492

TCP/IP. SZKOŁA PROGRAMOWANIA

interfejs szeregowy (serial interface) — interfejs wymagający transmisji szeregowej lub transferu informacji, w której bity tworzące znak są wysyłane sekwencyjnie. Wykorzystuje tylko jeden kanał transmisyjny. interfejs U (U Interface) — połączenie pomiędzy urządzeniem NT1 a siecią ISD. Internet — największa sieć globalna, łącząca tysiące sieci rozrzuconych po całym świecie. internet — skrót od internetwork (międzysieć), nie należy go mylić z Internetem. interwal czasu życia (keepalive interval) — czas pomiędzy wiadomościami o aktywności wysłanymi przez urządzenie sieciowe. Intranet — wewnętrzna sieć organizacji oparta na technologii Web. IO (Input/Output — wejście/wyjście) — część systemu komputerowego lub czynność przypisana przekazywaniu informacji do lub z jednostki centralnej lub pamięci. IP (Internet Protocol — protokół internetowy) — protokół najniższej warstwy TCP/IP, który odpowiada za przesyłanie typu koniec-koniec oraz dzielenie dużych pakietów. Interpretowany w zestawie TCP/IP PI. Podobny protokół interpretowany jest w Banyan VINES PI. Patrz również IPX i ISO. IPX — internetowa wymiana pakietów. Prosta implementacja Novella protokołu datagramu Internetu firmy Xerox. Interpretowany w zestawie Novell NetWare PI suite. ISB N (Integrated Services Bigital Network — sieć cyfrowa z integracją usług) — technologia telefonii cyfrowej, która umożliwia świadczenie usług przesyłu głosu oraz danych poprzez jeden przewód. ISL (Inter-Switch Link) — firmowy protokół Cisco, który przechowuje informacje VLAN w trakcie, gdy ruch przechodzi między przełącznikami a routerami. ISO (International Standards Organization • —■międzynarodowa organizacja standaryzacyjna) — (1) konsorcjum ustanawiające protokoły sieciowe (2) protokoły standaryzowane wg. grupy. ISP (Internet Service Provider — dostawca usług internetowych) — dostarcza usługi internetowe firmom oraz odbiorcom indywidualnym. ITU-T (International Telecommunications Union Telecommunication Standardization Sector) — międzynarodowe ciało tworzące światowe standardy technologii telekomunikacyjnych.

Dodatek D • SŁOW NICZEK

493

- K

kabel ekranowany (shielded cable) — kabel posiadający warstwę ochronną nałożoną w celu redukcji zakłóceń elektromagnetycznych. kabel światłowodowy (fiber-optic cable) — kabel umożliwiający modulowaną transmisję światła. kanał (channel) — ścieżka komunikacyjna. kanał podłączony (channel attached) — odnosi się do podłączania urządzeń do komputera bezpośrednio przez kanały danych. kanałowy E l (channelized E l) — łącze dostępowe o przepustowości 2.048 Mb/s. kanałowy T l (channelized T l) — łącze dostępowe o przepustowości 1.544 Mb/s. kategorie okablowania (category cabling) — istnieje pięć kategorii okablowania UTP opisanych w standardzie EIA/TIA-586. Kbps (Kilobits per second — Idlobity na sekundę kb/s) — miara szybkości przesyłania danych. Masowe protokoły routingu (classful routing protocols) — klasowe protokoły routingu, które nie wysyłają informacji dotyczące długości prefixu. ldient (Client) — (1) moduł korzystający z usług innego modułu — na przykład, warstwa sesji jest klientem warstwy transportu. (2) Komputer lub stacja robocza, która korzysta z usługi lub aplikacji innego serwera PC lub stacji roboczej. kodowanie typu Manchester (Manchester encoding) — technika kodowania danych wykorzystująca zmianę środkowego bitu czasu do zegarowania oraz oznaczenia daty. kolejka (queue) — (1) uporządkowana lista elementów oczekujących na przetworzenie (2) w routingu zalegle pakiety oczekujące na przesłanie. kolejkowanie według priorytetów (priority queuing) — metoda kolejkowania wykorzystywana do gwarantowania przepustowości poprzez przyporządkowanie przestrzeni w oparciu o protokół, numer portu lub inne kryteria. Kolejkowanie według priorytetów ma cztery poziomy: niski, normalny, średni i wysoki. Obiekt o wysokim poziomie kolejkowania jest wysyłany w pierwszej kolejności. kolejkowanie zwyczajowe (custom queuing) — metoda kolejkowania wykorzystywana w celu zagwarantowania szerokości pasma dla danego przesyłu poprzez przyporządkowanie miejsca w kolejce na podstawie numeru portu, protokołu lub innych kryteriów. kolizja (Collision) — jest to efekt jednoczesnej transmisji dwóch węzłów w sieci Ethernet. Ramki każdego urządzenia zderzają się i niszczą spotykając się w nośniku fizycznym.

494

TCP/IP. SZKOŁA PROGRAMOWANIA

kompresja (Compression) — redukcja szerokości pasma lub ilości bitów potrzebnych do kodowania informacji. komutacja krzemowa (silicom switchimg) — komutacja bazująca na SSE, umożliwiającym przetwarzanie pakietów niezależnie od SSP. Komutacja krzemowa zapewnia wysoką prędkość, dedykowanej komutacji pakietów. komutacja pakietów zapisz-i-przekaż (storę and forward packet switchimg) — technika komutacji w której pakiety są w pełni przetwarzane oraz buforowane przed wysłaniem do określonego portu. Przetwarzanie obejmuje sprawdzenie CRC i adresu docelowego. Mosty i przełączniki korzystające z tej metody weryfikują ramkę przed jej przekazaniem. Jeżeli ramka jest zniszczona, nie jest przekazywana. Urządzenia przekazujące oraz przechowujące odizolowują domeny kolizyjne. komutacja pakietów, przełączanie pakietów (packet switching) — metoda przesyłania w sieci, w której węzły wysyłając pakiety współdzielą ze sobą pasmo. Dane dzielone są na pakiety, każdy ze swoją indywidualnym identyfikatorem oraz adresem docelowym. Pakiety mogą być wysyłane różnymi trasami, a następnie łączone w odpowiedniej kolejności dzięki swoim ID. komutacja procesów, przełączanie procesów (process switching) — działanie zapewniające pełną ocenę trasy i równoważenie obciążenia dla każdego pakietu przez równoległe łącza WAN. w jego skład wchodzi transmisja całej ramki do CPU routera, gdzie jest przepakowywana dla dostarczenia do interfejsu WAN. Router zaś wykonuje wybór trasy dla każdego pakietu. koncentrator (Concemtrator) — centralny punkt podłączenia kilku stacji indywidualnych do pierścienia sieciowego. Występuje w sieciach FDDI. koncentrator (Hub) — jest to centralny punkt okablowania lub przetwarzania w sieci. Często łączy w sobie funkcje wzmacniające (wzmacniaka). kontrola parzystości (parity check) — proces wykrywania uszkodzeń bitów danych podczas transmisji. kontrola przepływu (flow contro!) — mechanizm sprzętowy lub programowy wykorzystywany w komunikacji danych do wyłączania transmisji jeżeli stacja odbierająca nie ma możliwości przechowywania otrzymywanych danych. Odnosi się do różnych metod regulacji przepływu danych podczas komunikowania. Przykładem kontroli przepływu są bufory. kontrola przepływu przesuwanego okna (sliding window flow control) — metoda kontroli przepływu, w której odbiornik daje nadajnikowi prawo do transmisji danych do momentu zapełnienia całego okna. Kiedy do tego dojdzie, nadajnik musi wstrzymać transmisję do momentu ogłoszenia powiększenia jego rozmiarów.

Dodatek D • SŁOW NICZEK

495

konwergencja (Convergence) — szybkość oraz zdolność grupy urządzeń międzysieciowych obsługujących określony protokół routingu do jednoznacznego zidentyfikowania typologii sieci po dokonaniu jej zmiany. krata pełna (full mesh) — sieć, w której urządzenia są zorganizowane w topologii siatki, gdzie każdy węzeł sieci posiada wirtualne lub fizyczne łącze do wszystkich pozostałych węzłów sieciowych. krata, siatka (mesh) — topologia sieciowa, w której urządzenia zorganizowane są w segmenty przystosowane do zarządzania, z wieloma połączeniami nadmiarowymi umieszczonymi strategicznie pomiędzy węzłami. kształtowanie charakterystyk czasowych ruchu (traffic shaping) — użycie kolejek do ograniczenia impulsów ruchu mogących zablokować sieć. Dane są buforowane i dopiero później wysyłane do sieci w regulowanych ilościach, by zapewnić, że ruch mieści się w określonej wartości ruchowej dla danego połączenia.

LAN (Local Area Network — sieć lokalna) — sprzęt oraz oprogramowanie wykorzystywane do łączenia komputerów na ograniczonym obszarze. LANE (LAN Emulation — emulacja LAN) — umożliwia sieci ATM pełnienie funkcji szkieletu LAN. LAP (Link Access Protocol — protokół dostępu do łącza) — protokół warstwy logicznej dla AppleTalk. Występuje w dwóch wariantach: ELAP (dla Ethernet) oraz LLAP (dla sieci LocalTalk). Interpretowany w AppleTalk PI. LAPB (Link Access Protocol Balanced — protokół zrównoważonego dostępu do łącza) — podsieć HDLC. LAPD (Link Access Protocol-D — protokół zrównoważonego dostępu do łącza) — protokół kontrolujący łącze oparty na HDLC związanym z ISDN. LAT (Local Area Transport — transport lokalny) — sieciowy protokół, wirtualnego terminala (klawiatury i ekranu) utworzony przez Digital Equipment Corporation. Interpretowany w zestawie DECnet PI. licznik skoków (hop count) — jednostka miary routingu wykorzystywana do pomiaru odległości pomiędzy punktem źródłowym a docelowym. linia dedykowana (dedicated line) — linia zarezerwowana na stałe dla danego kierunku transmisji. linia dzierżawiona (leased line) — linia telefoniczna dzierżawiona do wyłącznego, nieograniczonego użytku. Używana powszechnie do podłączania zdalnych sieci LAN. To samo co dzierżawione łącze, dedykowane łącze lub dzierżawiony kanał.

496

TCP/IP. SZKOŁA PROGRAMOWANIA

linia telefoniczna (dial-up line) — łącze komunikacyjne ustanowione przez połączenie typu komutowane za pośrednictwem sieci telefonicznej. LLAP — patrz LAE. LLC (Logical Link Control — sterowanie łączem logicznym) — protokół zapewniający kontrolę połączenia. Najbardziej powszechnym protokołem jest IEEE 802.2 i ISO/DIS 8802/2." LMI (Local Management Interface — lokalny interfejs zarządzania) — protokół sygnalizujący dostęp zdefiniowany dla łączy frame relay. LMI przenosi informacje o stanie stałych łączy wirtualnych pomiędzy siecią a urządzeniem abonenckim. Dodatkiem do LMI może być multikasting, adresowanie globalne oraz kontrola przepływu. lokalny pakiet rozpoznawczy (local explorer packet) — pakiet wygenerowany przez system końcowy w sieci SRB w celu odnalezienia hosta podłączonego do pierścienia lokalnego. LSB (Least Significant Bit — najmniej znaczący bit) — ostatni, prawy bit w ciągu bitów liczby bitowej. Ł

ładunek (payload) — część komórki (pakieciku), ramki lub pakietu, zawierająca informacje z warstwy wyższej (danych). łańcuch społeczności (community string) — łańcuch tekstowy działający jak hasło wykorzystywany do identyfikacji wiadomości wysyłanych pomiędzy zarządzanymi stacjami a routerem zawierającym agenta SNMP. łańcuch typu chat (chat string) — sekwencja znaków poleceń/odpowiedzi UNIX pobierana przez urządzenie szeregowe w celu jego kontroli. łącze (Link) — sieciowy kanał komunikacyjny składający się z ścieżki transmisyjnej lub łącza oraz sprzętu pomiędzy nadawcą a odbiorcą. Określenie używane powszechnie w odniesieniu do łącza WAN.

MAC (Medium Access Contro! — kontrola dostępu do nośnika) — warstwa protokołu opisująca ramki zarządzania siecią wysyłane przez 802.5 Token-Ring. Większość ramek MAC jest przekazywana w sposób niewidoczny dla użytkownika przez adapter sieciowy.

Dodatek D • SŁOW NICZEK

497

MAC address (Adres MAC) — standardowy adres warstwy łacza danych przypisany do każdego urządzenia lub portu w sieci LAN. Znany również pod nazwą: adres warstwy MAC, adres sprzętowy lub adres fizyczny. magistrala znaczników (token bus) — rodzaj LAN, w którym wszystkie stacje mogą nasłuchiwać transmisji pozostałych stacji, a zezwolenie na transmisję jest reprezentowane przez znacznik wysyłany od stacji do stacji. magistrala, szyna (bus) — wspólna fizyczna ścieżka sygnałowa składająca się z przewodów lub innych mediów, przez które mogą być przesyłane sygnały pomiędzy poszczególnymi częściami komputera (znana również pod nazwą: autostrada (highway)). MAN (Metropolitan-Area Network — sieć miejska) — sieć obejmująca obszar miejski. mapowanie adresu (address mapping) — technika zapewniająca możliwość współpracy pomiędzy różnymi protokołami poprzez tłumaczenie formatów adresów. maska (wildcard mask) — 32-bitowa wartość, używana w połączeniu z adresem IP do określenia, które bity powinny zostać zignorowane podczas porównywania adresu z innym adresem IP. Maskę podaje się podczas definiowania list dostępu. maska podsieci (subnet mask) — 32-bitowa liczba powiązana z adresem IP; każdy bit maski podsieci wskazuje sposób interpretacji odpowiadającego mu bitu adresu IP. MAU (Multiple Access Unit — jednostka wielodostępu) — jest znana również jako jednostka podłączania do nośnika. Koncentrator lub przekaźnik wykorzystywany do przyłączania stacji połączonych z siecią. MB (megabajt) — około 1 000 000 bajtów. MBps (Megabyte per second — megabajty na sekundę MB/s) — jednostka szybkości przesyłania danych. metryka routingu, miara routingu (routing metric) — metoda, dzięki której algorytm routingu określa, że jedna trasa jest lepsza niż inna. Informacja ta przechowywana jest w tabelach routingu. Metryki zawierają pasmo, koszt komunikacji, opóźnienie, liczbę skoków, obciążenie, MTU, koszt trasy i jej niezawodność. MIC (Media Interface Connector — łącznik interfejsu nośnika) — de facto standardowy łącznik FDDI. międzysieć (Internetwork) — jedna lub więcej sieci z różnymi protokołami oraz podłączonymi urządzeniami.

498

TCP/IP. SZKOŁA PROGRAMOWANIA

mirroring — synchronizacja dwóch dysków na serwerze plików. modem — modulator-demodulator. Urządzenie, które przekształca sygnały analogowe i cyfrowe, w źródle, modem zamienia sygnał, cyfrowy na postać możliwą do przesłania przez urządzenia analogowe, w miejscu docelowym, sygnały analogowe są przywracane do swojej postaci cyfrowej. Modemy umożliwiają transmisję danych po łączach nadających się do transmisji głosu. modem null (Nuli modem) — małe pudełko (częściej kabel) używany do łączenia bezpośrednio dwóch urządzeń, zamiast łączenia ich przez sieć. MOP (Maintenance Operations Protocol — protokół działań serwisowych) — protokół w systemach DECnet służący do zdalnego testowania oraz diagnozowania problemów. most (bridge) — urządzenie używane do łączenia dwóch oddzielnych sieci w jedną. Mosty przekazują pakiety przeznaczone dla drugiej sieci. mostkowanie przeźroczyste (transparent bridging) — schemat mostkowania używany często w sieciach Ethernet, w których mosty przekazują ramki przez jeden skok na raz, na podstawie tabel kojarzących węzły końcowe z portami mostu. możliwość odrzucenia (DE) — siódmy bit drugiego oktetu nagłówka frame relay. Wartość 1 bitu DE oznacza, że ramka może być odrzucona przy przepełnieniu sieci. MSB (Most Significant Bit — najbardziej znaczący bit) — bit o największej wadze liczbie binarnej, oprócz bitu znaku (sign bit). MTBF (Mean Time Between Failure — średni czas pomiędzy awariami) — średni czas pomiędzy awariami urządzenia. MTU (Maximum Transmission Unit — maksymalna jednostka transmisyjna) — maksymalny rozmiar pakietu w bajtach, który może obsłużyć określony interfejs. MTU Discovery ( wyszukiwanie MTU) — funkcja umożliwiająca programowi znalezienie oraz używanie największego rozmiaru ramki, jaki może przemieszczać się przez sieć bez konieczności jej fragmentacji. multikast (Multicast) — (1) wiadomość kierowana do grupy stacji sieciowych lub zespołu sieci (w odróżnieniu do rozgłoszenia). (2) adres docelowy określający podsieć, do której kierowana jest wiadomość. multipleksowanie (multiplexing) — system umożliwiający wielu sygnałom logicznym jednoczesną transmisję przez jeden fizyczny kanał.

Dodatek D • SŁOW NICZEK

499

N(R) (Receive Sequence Number — kolejny numer odbioru) — pole LLC lub HDLC dla ramek informujących o numerze kolejnej spodziewanej ramki; wszystkie ramki przed N(R) zostały już potwierdzone. N(S) (Send Sequence Number — kolejny numer wysyłania) — pole LLC lub HDLC dla ramek informujących o numerze bieżącej ramki połączenia. nadmiarowość (redundancy) — duplikaty urządzeń, połączeń lub usług, które w przypadku wystąpienia błędu mogą wykonywać daną czynność w zastępstwie. nadwyżka (Overhead) — informacja pomocnicza, która nie stanowi istotnej część danych lub działań. nagłówek (header) — początkowy fragment wiadomości zawierający adres docelowy, adres źródłowy, numer wiadomości oraz inne informacje. Nagłówek pomaga odpowiednio skierować wiadomość. Każdy protokół wprowadza swoje indywidualne nagłówki. NAK (Negative Acknowledgment — negatywne potwierdzenie) — odpowiedź wysyłana przez urządzenie odbiorcze, wskazujące, że informacja zawierała błędy. NBMA (Non-Broadcast Multi-Access — wielodostęp bez zastosowania rozgłoszenia) — wielodostępowa sieć, która albo nie obsługuje rozgłoszeń lub w której rozgłoszenia są niewykonalne. NCP (NetWare Core Protocol — sieciowy protokół sterujący) — protokół warstwy Aplikacji w systemach Novell służący do wymiany poleceń oraz danych pomiędzy serwerami plików oraz stacjami roboczymi. Interpretowany w zestawie Novell NetWare PI. NDS (Network Directory Services) — NDS jest aplikacja systemu Novell współpracującą z NCP w celu zarządzania zasobami sieciowymi. NetBEUI (NetBIOS Basic Extended User Interface — rozszerzony interfejs użytkownika NetBIOS) — specyfikacja programowa NetBIOS. NetBIOS (Network Basic Input/Output System — podstawowy sieciowy system wejścia/wyjścia) — (1) protokół wprowadzony przez program PC LAN do obsługi stacji nazywanych symbolicznie oraz arbitralnej wymiany danych (2) Interfejs programowy (API) używany do wysyłania i odbierania wiadomości NetBIOS. Istnieje kilka różnych i niekompatybilnych implementacji NetBIOS, każda z oddzielnym API; na przykład w zestawach IBM oraz Novell. NetWare — system sieciowy oraz jego protokoły zaprojektowane przez firmę Novell, Inc.

500

TCP/IP. SZKOŁA PROGRAMOWANIA

NFS (Network File System — sieciowy system plików) — protokół wprowadzony przez Sun Microsystems w celu składania zapytań oraz udzielania odpowiedzi serwerowi plików sieciowych. niezawodność (reliability) — współczynnik otrzymanych oczekiwanych pakietów keepalive z danego łącza. Jeśli jest on wysoki, łącze jest niezawodne. NLM (NetWare Loadable Module — ladowalny moduł NetWare) — indywidualny program który może zostać załadowany do pamięci i pracować jako część NetWare. NLSP (NetWare Link Services Protocol) — protokół łącza stanu usprawniający wydajność, niezawodność oraz zarządzalność przepływów IPX w większych sieciach typu LAN-WAN. NOS (Network Operating System — sieciowy system operacyjny) — określenie wykorzystywane dla dystrybuowanego systemu plików. NT1 (Network Termination 1 • —•terminal sieciowy 1) — w ISDN, urządzenie będące punktem styku pomiędzy sprzętem klienta a oprzyrządowaniem centralnego biura przełączającego. NTP/SNTP (Network Time Protocol/Simple Network Time Protocol — sieciowy protokół czasu/ prosty sieciowy protokół czasu) — NTP lub SNTP zapewnia mechanizm umożliwiający synchronizację czasu dystrybucji w Internecie. numer liosta (host number) — część adresu IP wskazująca na docelowy węzeł podsieci. NVRAM (Non-Volatile RAM — nieulotna pamięć RAM) — RAM, która zachowuje swoją zawartość nawet po wyłączeniu zasilania.

O obszar (area) — zestaw segmentów sieci wraz przyłączonymi do nich urządzeniami. obszar szczątkowy (stub area) — obszar OSPF zawierający trasy domyślne, wewnątrz- i międzyobszarowe, ale nie zawierający tras zewnętrznych. obwód wirtualny (virtual circuit) — łącze komunikacyjne sprawiające wrażenie łącza dedykowanego typu punkt-punkt. ODI (Open Data-Link Interface — otwarty interfejs łącza danych) — specyfikacja firmy Novell, udostępniająca standaryzowany interfejs dla NIC (kart interfejsów sieciowych), umożliwiająca wielu protokołom korzystanie z pojedynczej karty NIC. odszyfrowanie (decryption) — przekształcanie danych do ich oryginalnej niezakodowanej postaci.

Dodatek D • SŁOW NICZEK

501

ogłaszanie (advertising) — proces rozpowszechniania informacji o usłudze. Wykorzystywany również przez routery do rozpowszechniania informacji o trasach. okienkowanie (Windowing) — metoda kontrolowania ilości informacji przesłanych w trybie koniec — koniec, z wykorzystaniem różnych rozmiarów okien. okno (window) — liczba segmentów danych jaką nadawca może wysłać bez otrzymania potwierdzenia. oktet — ciąg ośmiu bitów; synonim baj tu. opóźnienie (delay) — czas pomiędzy rozpoczęciem transakcji przez nadawcę, a otrzymaniem przez niego pierwszej odpowiedzi. opóźnienie (latency) — (1) opóźnienie pomiędzy złożeniem przez urządzenie zapytania o dostęp do sieci, a momentem kiedy może dokonać transmisji. (2) Czas pomiędzy momentem, w którym urządzenie odbiera ramkę i momeiatem, w którym ramka ta jest przekazywana do portu przeznaczenia. O SI (Open Systems Interconnection — połączenie systemów otwartych) — ogólny model architektury warstwowej dla łączenia systemów. OSPF (Open Shortest Path First — otwórz najpierw najkrótszą ścieżkę) — hierarchiczny protokół routingu IGP typu stanu łącza, zaproponowany jako następca RIP dla społeczności internetowej.

PAD (Packet Assembler Disassembler — asembler/dezasembler pakietów) — urządzenie używane do łączenia prostych urządzeń (talach jak terminale znakowe), które nie obsługują pełnej funkcjonalności określonego protokołu danej sieci. PAD buforuje dane i zajmuje się składaniem ich w pakiety lub rozkładaniem pakietów na dane. pakiet (packet) — jednostka danych składająca się z bajtów. Synonim określenia „datagram". pakiet jednej trasy (single-route packet) — pakiet w sieci SRB, który wykorzystuje tylko jedną ścieżkę w drodze do punktu docelowego. pakiet poszukiwawczy (explorer packet) — paldet wygenerowany przez stację końcową, który próbuje odnaleźć drogę przez sieć SRB. pakiet wykrywający wszystkie trasy (all-routes explorer packet) — pakiet eksplorujący, przechodzący do celu przez całą sieć SRB oraz przez wszystkie możliwe ścieżki.

502

TCP/IP. SZKOŁA PROGRAMOWANIA

panel nakładkowy (patch panel) — urządzenie umożliwiające dokonywanie tymczasowych połączeń pomiędzy linią wchodzącą i wychodzącą. Używany do modyfikacji oraz ponownej konfiguracji systemu komunikacyjnego lub podłączania instrumentów testujących (takich jak program analizujący Sniffer) do określonych linii. pasmo podstawowe (baseband) — technika transmisyjna polegająca na wysyłaniu bitów danych bez korzystania z wysokiej częstotliwości. Cała szerokość pasma przypada na jeden sygnał. PAT (Port Address Translation — przekształcenie adresu portu) — cecha Cisco umożliwiająca przekształcanie adresów prywatnych na zarejestrowane adresy IP, dzięki użyciu numerów portów. PDU (Protocol Data Unit — jednostka danych protokołu) — dane dostarczone jako pojedyncza jednostka pomiędzy procesami równorzędnymi na różnych komputerach. Termin OSI używany do określenia informacji w każdej warstwie modelu OSI. PDV (Path Delay Value — wartość opóźnienia ścieżki) — całkowite opóźnienie w sieci Ethernet. pełny dupleks (full-duplex) — możliwość przesyłania danych w sposób symultaniczny pomiędzy stacją wysyłającą a odbierającą. pętla (LOOP) (Loopback — test pętlą) — protokół Ethernet służący do wysyłania diagnostycznych wiadomości testujących. pierścień (ring) — połączenie co najmniej dwóch stacji w logicznej topologii pierścienia. pilot — pilot sieci jest prototypem wykorzystywanym do demonstrowania podstawowych funkcji wykorzystywanych najczęściej w mniejszych sieciach. Ping — narzędzie TCP/TP dołączane do TCP/IP Distributed Sniffer System. Ping jest narzędziem diagnostycznym, które wysyła echo wiadomości zapytania ICMP na określony adres IP w sieci. podinterfejs (subinterface) — jeden z interfejsów wirtualnych przypisany do pojedynczego interfejsu fizycznego. podsieć (subnet) — termin używany do określenia każdej technologii sieciowej, w której wszystkie przyłączone do niej węzły sprawiają wrażenie łatwej dostępności. Innymi słowy, użytkownik podsieci może komunikować się bezpośrednio z wszystkimi innymi węzłami podsieci.Zestaw podsieci wraz z warstwą sieci lub routingu tworzą razem sieć.

Dodatek D • SŁOW NICZEK

503

podzielony horyzont (split horizon) — zasada routingu polegająca na tym, iż routerowi nie wolno ogłaszać ponownie informacji o sieci, interfejsem przez który otrzymał te informacje. połączenie (circuit) — ścieżka komunikacyjna pomiędzy dwoma lub większą liczbą punktów. połączeniowy, zorientowany połączeniowo (connection-oriented) — transfer danych wymagający ustanowienia połączenia wirtualnego. port — punkt fizycznego dostępu do komputera, multiplekser (krotnica), urządzenie lub sieć w której sygnały mogą być wysyłane lub odbierane. potwierdzenie (acknowledgement) — potwierdzenie wysłania z jednego urządzenia sieciowego do drugiego, potwierdzające zajście określonego zdarzenia. PPP (Point-to-Point Protocol — protokół punkt-punlct) — RFC 1331. PPP jest protokołem poziomu łącza obchodzącym X.25 w celu komunikacji pomiędzy dwoma systemami bezpośrednio połączonymi, z uruchomionymi różnymi protokołami bezpośrednio nad HDLC. pps (Packet Per Second — pakiet na sekundę) — miara przepustowości oraz wydajności sieci oraz urządzeń sieciowych. preambuła (preamble) — ustalony wzór danych przesyłany przed każdą ramką, aby umożliwić odbiorcy synchronizację oraz rozpoznanie początku ramki. PRI (Primary Rate Interface — interfejs najszybszego dostępu) — interfejs ISDN 0 największej szybkości dostępu. procesor czołowy (Front-end processor) — patrz FEP. protokół (protocol) — zestaw reguł, procedur lub konwencji zarządzania formatem oraz pomiarem czasu transmisji danych pomiędzy dwoma urządzeniami. protokół drzewa rozpinającego (spanning-tree protocol) — protokół mostkowania używający algorytmu drzewa rozpinającego, umożliwiając uczącym się mostom dynamiczne obchodzenie pętli w topologii sieciowej, przez utworzenie drzewa rozpinającego. Mosty wymieniają wiadomości BPDU z innymi mostami by wykryć pętle i je usunąć zamykając odpowiednie interfejsy mostu. protokół łącza (link protocol) — zestaw reguł służących do ustawiania łącza danych oraz przepływu danych przez łącze. Dotyczy również formatowania danych. protokół routingu stanu łącza (Link state routing protocol) — znany również pod nazwą algorytmu najkrótszej ścieżki. Przykładami łącza protokołów to NLSP 1 OSPF. Protokoły routingu stanu łącza utrzymują mapy topologii, gwarantują szybkie przekształcanie oraz wysyłają aktualizację tylko wtedy, kiedy zmiany pojawiają się w sieci.

504

TCP/IP. SZKOŁA PROGRAMOWANIA

protokół routingu, protokół trasowania (routing protocol) — protokół wspomagający protokół routowalny za pomocą mechanizmu służącego do udostępniania informacji o trasowaniu. Komunikaty protokołu routingu przesyłane są pomiędzy routerami. Protokół routingu umożliwia routerom komunikowanie się z innymi routerami w celu aktualizacji i utrzymywania tablic tras. Komunikaty protokołu routingu nie przenoszą danych z sieci do sieci. Protokół routingu wykorzystuje protokół routowalny do przekazywania informacji pomiędzy routerami. protokół routowalny (routed protocol) — protokół, który może być rautowany przez router. Protokół routowalny zawiera wystarczającą dla użytkownika ilość informacji adresowych warstwy Sieci, aby dokonać przekierowania z jednej sieci do drugiej. Protokoły routowalne określają format oraz korzystają z pól pakietu. protokół zarządzania siecią (network management protocol) — protokół zarządzający obiektami w NMS wykorzystywany do komunikowania się z agentami urządzeń zarządzanych. prototyp (prototype) — prototyp sieci polega na zaangażowaniu części sieci w celu sprawdzenia czy jej projekt spełnia wymagania wykorzystywane w większych sieciach. Proxy —-jednostka, która występuje w imieniu innej jednostki w celu zwiększenia wydajności. Proxy ARP (Proxy Address Resolution Protocol) — rodzaj protokołu ARP, w którym urządzenie pośredniczące (na przykład router) wysyła odpowiedzi ARP w imieniu węzła końcowego do hosta odpytującego. przechwytywanie (capture) — proces zapisywania danych dotyczących ruchu w sieci prowadzony przez aplikację analityczną Sniffer. Generalnie, analiza ta ma miejsce podczas wyświetlania. Jednakże aplikacja Expert Sniffer może jednocześnie przechwytywać oraz analizować dane o ruchu w sieci. przeglądarka WWW (WWW browser) — hipertekstowa aplikacja klienta oparta na GUI, wykorzystywana do zdobywania dostępu do dokumentów hipertekstowych oraz innych usług znajdujących się na serwerach zdalnych, poprzez WWW oraz Internet. przekształcenie adresu (address resolution) — metoda polegająca na tłumaczeniu różnic występujących pomiędzy komputerowymi schematami adresowania. przełączanie obwodów (circuit switching) — system przełączania, w którym w trakcie rozmowy musi istnieć dedykowana ścieżka komunikacyjna pomiędzy nadawcą a odbiorcą.

Dodatek D • SŁOWNICZEK

505

przełącznik (switch) — urządzenie sieciowe, które filtruje, przekazuje i trasuje zalewowo ramki na podstawie adresu docelowego każdej z nich. (2) Ogólny termin dotyczący urządzeń mechanicznych lub elektronicznych, umożliwiających nawiązanie połączenia na żądanie i zakończenie go, gdy nie jest już potrzebne. przepływ poza obszarem lokalnym (non-local traffic) — wiadomości, które muszą zostać przemieszczone do innego segmentu sieci. przepustowość (throughput) — ilość danych przesiana z powodzeniem pomiędzy węzłami w jednostce czasu, zwykle w sekundach. przesyłanie pakietowe (bursty traffic) — określenie używane w komunikacji danych w odniesieniu do niejednolitego sposobu przesyłania danych. przyleganie, sąsiedztwo (adjacency) — proces tworzenia relacji pomiędzy jednostkami sąsiadującymi. pułapka (trap) — wiadomość wysyłana przez agenta SNMP do NMS, konsoli lub do terminala, wskazująca na zajście istotnego zdarzenia. PUP (PARC Universal Packet — uniwersalny pakiet PARC) — rodzaj pakietu Ethernet wykorzystywanego początkowo w centrum badawczym Xerox Corporation's Palo Alto . Interpretowany w XNS/MS-Net oraz TCP/IP PI, lecz nie uwzględniony w ich diagramach protokołów ponieważ nie jest już używany. PVC (Permanent Virtual Circuit — stały obwód wirtualny lub stałe wirtualne połączenie) — unikalna, predefiniowana ścieżka pomiędzy dwoma punktami końcowymi w sieci. Używana przez frame relay.

QoS (Quality of Service — jakość usługi) — miara wydajności systemu transmisji określająca jej jakość.

RAM (Random Access Memory — pamięć o dostępie swobodnym) — pamięć, która może być odczytywana oraz zapisywana przez mikroprocesor. ramka (frame) — wielobajtowa jednostka danych przesyłanych przez stację. Jest to synonim określenia pakiet. RARP (Reverse Address Resolution Protocol — odwrotny protokół odnajdywania adresów) — protokół w stosie TCP/IP używany do wyszukiwania adresów IP węzłów, na podstawie ich adresów DLC. Interpretowany w zestawie TCP/IP.

506

TCP/IP. SZKOŁA PROGRAMOWANIA

redystrybucja (redistribution) — umożliwienie dystrybucji w wiadomościach uaktualniających dowolnego protokołu routingu, informacji o routingu podanej przez jeden z protokołów routingu. REJ (Reject — odrzucenie) — rodzaj ramki LLC żądającej retransmisji uprzednio wysianej ramki. REM (Ring Error Monitor — monitor błędów pierścienia) — stacja w sieci 802.5 Token-Ring przechowująca komunikaty o błędzie warstwy MAC od innych stacji. rezerwacja pasma (bandwidth reservation) — proces przypisywania szerokości pasma użytkownikom danej sieci w zależności od ważności i wrażliwości na opóźnienia określonych przepływów. RFC (Request For Comment — prośba o komentarze) — koncepcja wykorzystywana przez protokół DoD/TCP w celach rozwojowo-badawczych. RG-58 — charakterystyka 50-omowego kabla koncentrycznego wykorzystywanego w sieciach Cheapernet (cienki Ethernet). RG-59 — charakterystyka 75-omowego kabla koncentrycznego wykorzystywanego w sieciach PC (szerokopasmowych). RG-62 — charakterystyka 93-omowego kabla koncentrycznego wykorzystywanego przez ARCNET. RII (Routing Information Indicator — identyfikator informacji o routingu) — jeżeli pierwszy bit pola adresu źródłowego w ramce Token-Ring ma wartość 1, pole danych rozpoczyna się od informacji routingu. Interpretowany przez aplikację Token-Ring lub Ethernet Sniffer niezależnie od innych PI. RIP (Routing Information Protocol — protokół informacji o routingu) — protokół rodzin XNS oraz TCP/IP wykorzystywany do wymiany informacji trasujących pomiędzy bramkami. Interpretowany w zestawach XNS PT oraz TCP/IP PI. RISC (Reduced Instruction Set Computer — komputer ze zredukowanym zestawem rozkazów) — rodzaj mikroprocesora zaprojektowany tak, aby koncentrować się na szybkim i wydajnym przetwarzaniu relatywnie niewielkich zestawów instrukcji. RJ-45 — charakterystyka 8-przewodowej wtyczki używanej w sieciach lOBASE-T. Podobna, ale szersza od standardowej wtyczki telefonicznej (RJ-11). rlogin (remote login — zdalne logowanie) — program emulacji terminala, oferowany w większości implementacji UNIXa. RMON (Remote Monitoring — zdalne monitorowanie) — baza zarządzania informacjami (MIB). Korzysta z SNMP oraz standardowej MIB w celu zapewnienia

Dodatek D • SŁOW NICZEK

507

współpracy pomiędzy produktami monitorującymi oraz stacjami zarządzającymi wielu różnych producentów. RNR (Receive Not Ready — odbiór nie nastąpił) — polecenie LLC i HDLC lub odpowiedź wskazująca na blokadę transmisji. rodzaj usługi (ToS) — pole w datagramie IP wskazujące jak powinien on być obsługiwany. ROM (Read-Only Memory — pamięć tylko do odczytu) — pamięć która może być odczytywana przez mikroprocesor, ale nie zapisywana. router — sieciowe urządzenie połączeniowe działające w warstwie Sieci (ISO warstwa 3). router domyślny (default router) — router, do którego kierowane są pakiety w przypadku braku ich kolejnego punktu trasy w tabeli trasującej. routing dynamiczny (dynamie routing) — routing automatycznie dostosowujący typologię sieci lub zmiany w ruchu. routingu wg reguł (policy routing) — system routingu przekazujący pakiety do określonego interfejsu w oparciu o reguły skonfigurowane przez użytkownika. rozgłoszenie (broadcast) — (1) Wiadomość skierowana do wszystkich stacji w sieci lub zespole sieciowym. (2) Adres docelowy wszystkich stacji. rozgłoszenie IP (IP multicast) — technika routingu umożliwiająca przesyłanie pakietów IP z jednego źródła do wielu odbiorców lub z wielu źródeł do wielu odbiorców. równoważenie obciążenia (load balancing) — w routingu, możliwość routera do dystrybuowania ruchu przez wszystkie swoje porty sieciowe, które znajdują się w tej samej odległości od adresu docelowego. Pozwala to na zwiększenie przepustowości sieci. RPC (Remote Procedure Call — zdalne wywołanie procedury) — protokół służący do aktywowania funkcji zdalnej stacji oraz pozyskiwania jej wyników. Interpretowany w zestawie Sun PI. Podobny protokół istnieje w systemie Xerox XNS. RPL (Remote Program Load) ■ — protokół używany w systemach IBM w sieciach IEEE 802.5 Token-Ring do pobierania programów inicjujących dla stacji sieciowych. Interpretowany w zestawie IBM PI. RPS (Ring Parameter Server — serwer parametrów pierścienia) — stacja w sieci Token-Ring przechowująca informacje warstwy MAC o konfiguracji LAN, takie jak numery pierścieni lub identyfikatory lokalizacji fizycznej.

508

TCP/IP. SZKOŁA PROGRAMOWANIA

RR (Receive Ready — gotowość do odbioru) — ramka LLC nie zawierająca danych wskazująca gotowość do odbioru danych z innej stacji. RS232 lub RS232C (Recommended Standard 232 — rekomendowany standard 232) — standard EIA definiujący elektryczną charakterystykę sygnałów w kablach połączeniowych DTE oraz DCE. RTMP (Routing Table Maintenance Protocol — protokół utrzymania tablicy routingu) — używany w sieciach AppleTalk w celu umożliwienia routerom międzysieciowym dynamicznego wykrywania tras do różnych sieci. Węzeł nie będący routerem, używający RTMP (RTMP stub) do określania liczby sieci, do których jest podłączony oraz ID węzłów routerów w tej sieci. Interpretowany przez interpretatora protokołów AppleTalk. ruch czuły na opóźnienia (delay-sensitive traffic) — ruch wymagający określonych ram czasowych dostarczania, którego szybkość jest odpowiednio dopasowywana. ruch wrażliwy na szybkość (Rate-sensitive traffic) — obiekty, które gotowe są zrezygnować z terminowości dostawy, na rzecz gwarancji szybkości.

s S lub ramka S (Supervisory Frame — ramka nadzorcza) — rodzaj ramki LLC, HDLC lub SDLC wykorzystywany do kontroli. SABM (Set Asynchronous Balanced Mode — ustawienia zrównoważonego trybu asynchronicznego) — ramka LLC nie zawierająca danych występująca z zapytaniem o ustanowienie połączenia, przez które mogą być przesyłane numerowane ramki informacyjne. SABME (Set Asynchronous Balanced Mode [Extended] — ustawienie zrównoważonego trybu asynchronicznego [rozszerzone]) — SABM z dwoma dodatkowymi bajtami w polu kontrolnym. Używany w LAPB. SAC (Single Attachment Concentrator — koncentrator z pojedynczym mocowaniem) — koncentrator oferujący jeden port S dla przyłączenia do sieci FDDI oraz porty M do przyłączenia stacji lub innych koncentratorów. SAP (Service Access Point — usługowy punkt dostępu) — (1) niewielka liczba ustalona przez grupę standardową lub używana zwyczajowo, definiująca format późniejszych danych LLC, środki demultimpleksowania protokołów alternatywnych obsługiwanych przez LLC. (2) (Service Advertising Protocol — protokół rozgłaszania usług) — używany przez serwery NetWare do rozgłaszania nazw oraz lokalizacji serwerów oraz do wysyłania odpowiedzi do każdej stacji zwracającej się z zapytaniem. SDLC (Synchronous Data Link Control — synchroniczna kontrola łącza danych) — starszy protokół komunikacyjny, który był modelem dla LLC co potwierdzają liczne cechy wspólne.

Dodatek D • SŁOWNICZEK

509

segment — (1) Sekcja sieci ograniczona przez mosty, routery lub przełączniki. (2) w sieci LAN używającej topologii magistrali, segment jest ciągłym obwodem elektrycznym, połączonym często z innymi segmentami za pomocą regeneratorów. (3) Termin używany w specyfikacji TCP do opisania pojedynczej jednostki warstwy transportowej. serwer (Server) — węzeł lub program świadczący usługi dla klientów. sesja (Session) — nazwa protokołu warstwy sesji w wersji ISO, interpretowanego w sestawie ISO PI. sieć (network) ■ — zespół komputerów, drukarek, przełączników, routerów oraz innych urządzeń zdolnych do wzajemnej komunikacji poprzez urządzenia transmisyjne. sieć szczątkowa (stub network) — część międzysieci, do której można uzyskać dostęp poprzez tylko jedną ścieżkę. sieć szkieletowa (Backbone) — sieć szkieletowa jest częścią sieci komunikacyjnej, przez którą przechodzi największy ruch. Jest podstawą konstrukcji całej usługi sieciowej. simpleks (simplex) — możliwość transmisji tylko w jednym kierunku pomiędzy stacją nadającą, a stacją odbiorczą. składanie (reassembly) — składanie z powrotem datagramów IP w punkcie docelowym po tym, jak zostały podzielone na fragmenty. skok (hop) — określenie używane w routingu. Skok jest jednym przesyłem łączem danych. Ścieżka prowadząca do punktu docelowego w sieci jest serią skoków. Każdy skok ma przypisaną wartość, umożliwiając w ten sposób obliczenie najkrótszej ścieżki. skrętka (twisted pair) — nośnik transmisyjny relatywnie wolnej transmisji, składający się z dwóch oddzielonych przewodów skręconych spiralnie. Przewody mogą być ekranowane lub nieekranowane. SLIP (Serial Line Internet Protocol — IP dla linii szeregowych) — standardowy protokół dla transmisji szeregowej punkt-punkt przy użyciu odmiany TCP/IP. SMB (Server Message Block — blok komunikatu serwera) — rodzaj komunikatu używanego przez program IBM PC LAN w celu przygotowania zapytania ze stacji użytkownika do serwera oraz odbierania odpowiedzi. Wiele funkcji podobnych jest do wykonywanych przez aplikacje DOS lub OS/2 uruchamiane na pojedynczych komputerach. SMDS (Switched Multi-Megabit Data Service — usługa komutacji danych wielomegabitowych) — technologia sieciowa WAN oparta na komutacji i datagramach.

510

TCP/IP. SZKOŁA PROGRAMOWANIA

SMT (Station Management — zarządzanie stacją) — zapewnia zarządzanie pierścieniem, połączeniem oraz usługi na rzecz ramek w pierścieniach FDDI. SMTP (Simple Mail Transfer Protocol — prosty protokół przesyłania poczty elektronicznej) — protokół w zestawie TCP/TP służący do niezawodnej wymiany elektronicznych wiadomości pocztowych. Interpretowany w zestawie TCP/TP. SNA (1) (Systems Network Architecture — architektura systemów sieciowych) zestaw protokołów używ any przez IBM do komunikacji sieciowej, głównie z komputerami mainframe. Interpretowany w zestawie IBM PI (2) (Sniffer Network Analyzer) — analizator sieciowy firmy Network General, który przyłączany jest do sieci w celu monitorowania, zapisywania, analizowania oraz interpretowania transmisji sieciowej. Funkcje monitoringu oraz analizy są oddzielne, są to czynności obsługiwane poprzez menu zapewniające wysoki poziom analizy oraz rozwiązywania problemów w skomplikowanych lokalnych oraz rozległych instalacjach sieciowych. SNAP (Subnetwork Access Protocol — protokół dostępowy podsieci) — nazywany czasem protokołem konwergencji dostępu do podsieci. Rozszerzenie IEEE 802.2 LLC umożliwiające stacji posiadanie wielu protokołów warstwy Sied.Protokół określa, że adres DSAP i SSAP muszą mieć postać heksadecymalną AA. Pole następujące po SSAP identyfikuje jeden konkretny protokół. Interpretowany w zestawie TCP/IP PI oraz AppleTalk PI. SNMP (Simple Network Management Protocol — prosty protokół zarządzania siecią) — interpretowany w zestawie TCP/TP PI. SNRM (Set Normal Response Mode — ustaw normalny tryb odpowiedzi) — ustawienie stacji dodatkowej w trybie uniemożliwiającym wysyłanie niechcianych ramek. Stacja podstawowa kontroluje przepływ wszystkich wiadomości. U żyw any w SDLC. SNRME (Set Normal Response Mode [Extended] — ustaw normalny tryb odpowiedzi [rozszerzony]) — SNRM z dwoma dodatkowymi bajtami w polu kontroli. Używany w SDLC. SPF (Shortest Path First — najkrótsza trasa pierwsza) — algorytm routingu obliczający długość trasy, aby określić drzewo rozpinające o najkrótszej ścieżce. SP1D (Service Profile Identifier — identyfikator profilu usługowego) — numer, którego niektórzy dostawcy usług używają do definiowania usług, do których należy określone urządzenie ISDN. społeczność (community) — w SNMP, logiczna grupa zarządzanych urządzeń oraz NMS w tej samej domenie administracyjnej.

Dodatek D • SŁOW NICZEK

511

SPX (Sequential Packet Exchange — sekwencyjna wymiana pakietów) — protokół firmy Novell będący wersją protokołu firmy Xerox nazywanego SPP. Interpretowany w zestawie Novell NetWare PI. SQE (Signal Quality Error — błąd jakości sygnału) — sygnał kolizyjny 802.3/Ethernet otrzymany od pośrednika. SOE Test — sygnał SQE wygenerowany przez pośrednika na końcu przesyłanej ramki w celu sprawdzenia czy obwody są w pełni funkcjonalne (znany również w Ethernet pod nazwą „bicie serca"). SQL (Structured Query Language — strukturalny język zapytań) — wykorzystywany do przetwarzania baz danych. SOL serwer — serwer interpretujący język SQL. SR/TLB (Source-Route Translational Bridging — mostkowanie tłumaczące według trasy źródłowej) — metoda mostkowania, w której stacje tras źródłowych mogą komunikować się z przeźroczystymi mostami za pomocą pośrednich mostów, tłumaczących pomiędzy dwoma protokołami mostkowania. SSAP (Source Service Access Point — punkt dostępowy źródła usługi) — LLC SAP dla protokołu używany przez stację źródłową. SSE (Silicon Switching Engine — mechanizm komutacji krzemowej) — mechanizm routingu i komutacji porównujący nagłówek warstwy łącza danych lub sieci pakietu przychodzącego z krzemową pamięcią podręczną. Określa odpowiednią akcję (routing czy mostkowanie) i przekazuje pakiet do odpowiedniego interfejsu. Może on komutować niezależnie od procesora systemowego. SSP (1) (Silicon Switch Processor — procesor przełącznika krzemowego) — przełącznik krzemowy w routerach serii Cisco 7000, umożliwiający przetwarzanie rozproszone i kontrolę procesorów interfejsów. (2) (switch-to-switch protocol — protokół przełącznik-przełącznik) — protokół określony w standardzie DLSw, którego routery używają do nawiązania połączeń DLSw, lokalizacji zasobów, przekazywania danych i obsługiwania sterowania potokami oraz poprawiania błędów. stos protokołów (protocol stack) — zestaw powiązanych wzajemnie protokołów komunikacyjnych działających wspólnie i kierujących komunikacją we wszystkich siedmiu warstwach modelu odniesienia OSI. STP (Shielded Twisted Pair — skrętka ekranowana) — dwuparowy nośnik używany w wielu implementacjach sieciowych. Patrz również protokół drzewa rozpinającego.

512

TCP/IP. SZKOŁA PROGRAMOWANIA

strefa (Zone) — w sieciach AppleTalk, zestaw jednego lub więcej węzłów znajdujących się w międzysieci. SUA (Stored Upstream Address — przechowywany adres upstream) — adres sieciowy stacji Token-Ring najbliższy aktywny sąsiad w kierunku od klienta do centrali. Instrumenty firmy Texas nazywają go UNA. sumaryzacja tras (route summarization) — konsolidacja rozpropagowanych adresów w tablicy tras. Zmniejsza to liczbę tras w tablicy, przepływ aktualizujący trasy oraz obciążenie routera. SVC (Switched Virtual Circuit — komutowany obwód wirtualny) — obwód wirtualny ustanawiany na żądanie, podobnie jak w przypadku linii telefonicznej lub wywołania X.25. sygnał cyfrowy poziomu 3 (DS3) — linie T3. Technologia transmisji sygnałów cyfrowych z prędkością 44,736 Mb/s. sygnał nawigacyjny (beacon) — pakiet Token-Ring sygnalizujący wystąpienie poważnego błędu w sieci. sygnał taktowania (heartbeat) — w sieci Ethernet, sygnał SQE wygenerowany przez pośrednika na końcu przesyłanej ramki w celu sprawdzenia bezpieczeństwa SQE. Patrz SQE TEST. symptom — nietypowe lub nienormalne wydarzenie w sieci wskazujące na możliwość wystąpienia problemu sieciowego. SYN (Synchronized — zsynchronizowany) (1) zsynchronizowany bit segmentu TCP wskazujący, iż jest to segment SYN. (2) pierwszy segment wysłany przez protokół TCP, używany do zsynchronizowania dwóch końców połączenia w celu przygotowania do otwarcia łącza. Syslog — usługa odbierająca komunikaty od aplikacji hosta lokalnego lub hostów zdalnych skonfigurowanych tak aby wysyłać komunikaty. szerokopasmowy (broadband) — technologia transmisji, za pomocą której wysyłane bity danych kodowane są na sygnał o znacznie wyższej częstotliwości radiowej. Środek transmisyjny może być wykorzystywany przez wiele sygnałów symultanicznych, ponieważ każdy z nich wykorzystuje jedynie część dostępnej szerokości pasma. szerokość pasma (Bandwidth) — ilość danych jaka może zostać przesłana przez określone łącze. szybki Ethernet (Fast Ethernet) — każda technologia 100 Mb/s Ethernet, o szybkości 10 razy większej niż technologia lOBaseT Ethernet.

Dodatek D • SŁOW NICZEK

513

szybkość transmisji w bodach (baud rate) — miara szybkości przesyłania sygnału danych. Określa liczbę elementów sygnałowych przesyłanych w ciągu sekundy, w większości przypadków, przy niskiej prędkości, szybkość transmisji w bodach jest równoznaczna z szybkością mierzoną w bitach na sekundę. szybkość w bitach (bit rate) — szybkość przesyłania bitów, przedstawiana najczęściej w bitach na sekundę (bps). szyfrowanie (Enciyption) — zastosowanie określonego algorytmu przekształcając dane tak, aby zmienić ich postać na nieczytelną dla nieautoryzowanych odbiorców. ściana ogniowa (firewall) — serwer lub router będący buforem pomiędzy dowolnym połączeniem z sieci publicznej do danej sieci prywatnej. Router ściany ogniowej zapewnia ochronę prywatnej sieci.

T l — cyfrowe łącze transmisyjne o przepustowości 1.544 Mb/s. T3 — cyfrowe łącze transmisyjne o przepustowości 44.736 Mb/s. TA (Terminal Adapter — adapter terminala) — zewnętrzne łącze dla komputera lub innego urządzenia. tabela routingu, tabela trasowania (routing table) — tabela przechowywana w routerze lub w innym urządzeniu sieciowym, która zawiera informacje o punktach docelowych w określonych sieciach i, w niektórych przypadkach, 0 metrykach skojarzonych z tymi trasami. TACACS (Terminal Access Controller Access Control System — system kontroli dostępu kontrolera dostępu terminala) — protokół uwierzytelniania udostępniający zdalną autoryzację dostępu i związane z tym usługi, jak prowadzenie dziennika zdarzeń. TCP (Transmission Control Protocol — protokół sterowania transmisją) — strumieniowy, zorientowany na połączenia protokół TCP/IP zapewniający niezawodną komunikację przez używanie danych sekwencyjnych wysyłanych przez IF. Interpretowany w zestawie TCP/IP. TCP/IP (Transmission Control Protocol/Internet Protocol — protokół sterowania transmisją/Protokół internetowy) — zestaw protokołów sieciowych opracowany przez rząd Stanów Zjednoczonych dla sieci ARPANET, wykorzystywany aktualnie przez kilku producentów. Poszczególne protokoły TCP/IP są wymienione w tym słowniczku. Telnet — protokół służący do transmisji danych terminala znakowego (klawiatury 1 ekranu). Interpretowany w zestawie TCP/IP.

514

TCP/IP. SZKOŁA PROGRAMOWANIA

terminal — proste urządzenie, np. komputer, dzięki któremu można wprowadzać lub pobierać dane z sieci. terminator — urządzenie zapewniające opór elektryczny na końcu linii transmisyjnej by pochłaniały sygnały liniowe, zapobiegając odbijaniu się ich i wracaniu do nadających urządzeń. tester komunikacyjny (breakout box) — urządzenie testujące używane do przeglądania sygnałów w RS-232, V.35 lub innych interfejsach. Tester komunikacyjny używany jest do diagnozowania problemów interfejsu. TFTP (Trivial File Transfer Protocol — trywialny protokół przesyłu plików) — protokół zestawu TCP/IP wykorzystywany do wymiany plików pomiędzy stacjami sieciowymi. Interpretowany w zestawie TCP/TP PI. THT (Token Holding Timer — zegar przetrzymywania znacznika) — maksymalny czas potrzebny stacji posiadającej znacznik na zainicjowanie transmisji asynchronicznej. THT jest uruchamiany z wartością odpowiadającą różnicy pomiędzy przybyciem tokena a TTRT (FDDI). Token-Ring — sieć LAN w kształcie pierścienia, w której każda stacja może nasłuchiwać transmisji tylko swojego najbliższego sąsiada. Zezwolenie na transmisję jest przyznawane przez znacznik krążący w sieci. topologia (Topology) — fizyczne ułożenie węzłów sieciowych i nośnika w obrębie struktury sieciowej firmy. topologia drzewa (tree topology) — topologia LAN podobna do topologii magistrali, z wyjątkiem tego, że sieci z topologią drzewa mogą zawierać gałęzie z wieloma węzłami. topologia magistrali (bus topology) — liniowa architektura LAN, w której transmisja ze stacji sieciowych rozpowszechnia łącze danego medium i trafia do wszystkich stacji. topologia pierścienia (ring topology) — topologia sieciowa, składająca się z serii wzmacnialców połączonych jeden do drugiego w jednokierunkowe połączenia, tworzących zamknięte pętle. Każda stacja w sieci łączy się z siecią przez wzmacniak. Pomimo, że logicznie są pierścieniami, topologie pierścieniowe są zwykle zorganizowane w topologię zamkniętej gwiazdy. topologia sieci (network topology) — geografia sieci. Przykłady topologii sieci to pierścień, gwiazda oraz magistrala. transmisja asynchroniczna (asynchronous transmission) — metoda transmisji danych umożliwiająca wysyłanie znaków w sposób przerywany. Odbywa się to dzięki poprzedzeniu każdego znaku bitem startowym, a zakończeniu bitem stopu. Jedna wspólna aplikacja komunikuje się z modemami i drukarkami.

Dodatek D • SŁOW NICZEK

515

transmisja synchroniczna (synchronous transmission) — metoda przesyłania danych, w której informacje przesyłane są w blokach (ramkach) bitów z równym taktowaniem. trasa (route) — ścieżka w międzysieci. trasa domyślna (default route) — wpis w tablicy routingu wykorzystywany do kierowania pakietów w przypadku braku kolejnego punktu trasy w tabeli routingu. trasa statyczna (static route) — trasa skonfigurowana i wpisana bezpośrednio do tabeli routingu. trasowanie (Routing) -— proces znajdowania trasy do hosta docelowego. Routing jest bardzo złożony w dużych sieciach, ponieważ pakiet przechodzi przez wiele węzłów pośrednich na trasie do hosta docelowego. TSR (Terminate and Stay Resident — zakończ i pozostań w pamięci) — program DOS, który po wczytaniu do RAM, pozostaje tam do momentu jego usunięcia lub wyłączenia zasilania. TTL (Time To Live — czas życia) — pole nagłówka IP określające czas ważności pakietu. tunelowanie (Tunneling) — architektura utworzona by udostępnić wirtualne łącze danych pomiędzy dwoma podobnymi sieciami, przez inną sieć.

UA (Unnumbered Acknowledgement — nienumerowane potwierdzenie) — ramka LLC potwierdzająca poprzednie zapytanie SABME lub DISC. UDP (User Batagram Protocol — protokół datagramów użytkownika) — protokół TCP/IP wysyłający ramki danych wymagając by obsługą błędów i retransmisją zajmowały się inne protokoły. Ul (Unnumbered Information — nienumerowana informacja) — ramka typu LLC, HDLC lub SDLC wykorzystywana do wysyłania danych bez kolejnych numerów. UNA (Upstream Neighbor Address) — adres sieciowy stacji Token-Ring najbliższy aktywny sąsiad w kierunku od klienta do centrali. IBM nazwał go SUA. UNI (User to Network Interface — interfejs użytkownik-sieć) — specyfikacja ATM Forum definiująca standardy współpracy dla interfejsów produktów opartych na ATM, ulokowanych w sieci prywatnej i przełącznikach ATM ulokowanych w obrębie publicznych sieci operatorów. unicast — wiadomość wysłana do pojedynczego adresata sieciowego.

516

TCP/IP. SZKOŁA PROGRAMOWANIA

UNIX — popularny przenośny system operacyjny napisany przez AT&T. urządzenie powtarzające, wzmacniak (repeater) — urządzenie regenerujące i propagujące sygnały elektryczne pomiędzy dwoma segmentami sieci. urządzenie zarządzane (managed device) — urządzenie sieciowe, które może być zarządzane przez protokół zarządzania siecią. UTP (Unshielded Twisted-Pair — skrętka nieekranowana) — czteroparowy nośnik używany w wielu rodzajach sieci. uzgodnienie wzajemne (handshaking) — wymiana uprzednio zdefiniowanych sygnałów podczas ustanawiania połączenia pomiędzy dwoma urządzeniami przenoszącymi dane. Komputery muszą dokonać uzgodnienia w trakcie procedury powitania drugiego urządzenia.

V V.24 — standard ITU-T dla interfejsu warstwy fizycznej pomiędzy DTE a DCE. V.25bis — specyfikacja ITU-T opisująca procedury ustanawiania połączenia i jego kończenia przez interfejs DTE-DCE w PSDN. V.32 — standardowy protokół linii szeregowej ITU-T, dla dwukierunkowych transmisji który może zostać poprawnie zweryfikowany. V.32bis — standard ITU-T rozszerzający V.32 do prędkości do 14,4 kb/s. V.34 — standard ITU-T określający protokół linii szeregowej. V.35 -— interfejs szerokopasmowy rekomendowany przez CCITT dla WAN. VC (Virtual Circuit — obwód wirtualny) — logiczny obwód utworzony by zapewnić niezawodną komunikację pomiędzy dwoma urządzeniami sieciowymi. Obwód wirtualny definiowany jest przez parę VPI/VCI, i może być albo stały (PVC) albo komutowany (SVC). Obwodów wirtualnych używa się w technologiach Frame Relay oraz X.25. w ATM, obwód wirtualny nazywa się kanałem wirtualnym. VINES (Virtual Network Software — usługa zintegrowanej sieci wirtualnej) — sieciowy system operacyjny wraz z protokołami utworzony i sprzedawany przez Banyan Systems. Ważniejsze komponenty systemu to StreetTalk oraz Net RPC. VLAN (Virtual LAN — wirtualna LAN) — grupa urządzeń w jednym lub większej liczbie LAN, skonfigurowanych (za pomocą oprogramowania zarządzającego) tak, by mogły się komunikować jakby były podłączone do tego samego kabla, podczas gdy naprawdę są zlokalizowane w różnych segmentach LAN.

Dodatek D • SŁOW NICZEK

517

VLSM (Variable Length Subnet Mask — maska podsieci zmiennej długości) — możliwość określenia różnych masek podsieci dla tego samego numeru sieci w wielu podsieciach. VLSM mogą pomóc zoptymalizować dostępną przestrzeń adresową. VPN (Virtual Private Network — wirtualna sieć prywatna) — umożliwia ruchowi IP bezpieczne przesyłanie przez publiczne sieci TCP/IP za pomocą szyfrowania całego ruchu od jednej sieci do VPN używa tunelowania do szyfrowania wszystkich informacji na poziomie IP. VT (Virtual Terminal — terminal wirtualny) — obiekt będący częścią protokołu warstwy Aplikacji oraz umożliwiający jej współpracę z terminalem w sposób stały i niezależny od specyfiki terminala.

WAN (Wide Area Network — sieć rozległa) — kilka sieci LAN lub stacji i hostów rozmieszczonych na rozległym obszarze, które mogą być podłączane przez wspólnego dostawcę lub linie prywatne. Prędkość transmisji w WAN jest zazwyczaj mniejsza niż w LAN. warstwa aplikacji (application layer) — siódma warstwa modelu referencyjnego OSI, w której aplikacja nasłuchuje żądań i odpowiada na nie. Może to odbywać się w formie emaila, transferu pliku oraz emulacji terminala. warstwa centralna (core layer) — jedna z warstw sieciowych zapewniająca optymalny transport pomiędzy stronami. warstwa dystrybucji (Distribution layer) — w sieciach hierarchicznych warstwa zapewniająca łączność zgodnie z określonymi zasadami. warstwa fizyczna (Physical layer) — pierwsza warstwa modelu referencyjnego OSI. Zajmuje się mechanicznymi i elektrycznymi aspektami ustanawiania łączy pomiędzy systemami. warstwa kontroli trasy (path control layer) — warstwa trzecia modelu architektury SNA. Warstwa ta zarządza usługami sekwencyjnymi związanymi z poprawnym składaniem danych. warstwa łącza danych (Data Link layer) — druga warstwa modelu referencyjnego OSI umożliwiająca dokonywanie niezawodnego przesyłu danych przez łącze fizyczne. warstwa prezentacji (Presentation layer) — szósta warstwa modelu OSI (ISO 8823). Kontroluje format ekranu oraz plików. Kontroluje kody, grafikę oraz zestaw znaków używane w tej warstwie.

518

TCP/IP. SZKOŁA PROGRAMOWANIA

warstwa sesji (Session layer) — piąta warstwa modelu referencyjnego OSI. Warstwa ta ustanawia, zarządza oraz kończy sesje pomiędzy aplikacjami oraz zarządza wymianą danych pomiędzy obiektami warstwy prezentacji. warstwa sieci (network layer) — trzecia warstwa modelu referencyjnego OSI. Zapewnia łączność oraz dobór ścieżki pomiędzy dwoma systemami końcowymi. warstwa transportu (Transport layer) — warstwa 4 modelu odniesienia OSI. Odpowiedzialna za niezawodną komunikację sieciową pomiędzy węzłami końcowymi. Warstwa transportowa zapewnia mechanizmy nawiązywania, utrzymania i kończenia wirtualnych obwodów, wykrywanie błędów i ich poprawianie oraz kontrole przepływu informacji. warunki zaopatrzenia (provisioning) — definiowanie rodzaju WAN, w tym określenie specyfikacji oraz opcji. węzły (nodes) — punkty w sieci gdzie usługa jest świadczona lub używana lub gdzie łączone są kanały komunikacyjne. Termin „Węzeł" używany jest zamiennie z określeniem „stacja robocza". WFQ (Weighted Fair Queuing — sprawiedliwe kolejkowanie z wagami) — metoda kolejkowania preferująca ruch o małej objętości nad ruchem o dużej objętości w celu zagwarantowania satysfakcjonującego czasu odpowiadania często używanym aplikacjom użytkowników. wiadomość podtrzymywania życia (keepalive message) — wiadomość rozsyłana przez urządzenie sieciowe by poinformować inne sieci, że wirtualny obwód pomiędzy nimi nadal jest aktywny. WINS (Windows Internet Naming Service — internetowy serwer nazewniczy Windows) — umożliwia klientom różnych podsieci dynamiczne rejestrowanie oraz przeszukiwanie sieci bez konieczności wysyłania rozgłoszenia. współczynnik błędu (error rate) — w transmisji danych, stosunek ilości przesłanych elementów błędnych do całkowitej liczby przesłanych elementów. WWW (World Wide Web) — duża sieć serwerów internetowych udostępniających dokumenty hipertekstowe i inne usługi dla terminali z pracującymi aplikacjami klienckimi. wykorzystanie (Utilization) — procent całkowitej pojemności segmentu sieci. wyświetlanie (Display) — proces, w którym analizator Sniffer interpretuje informacje dotyczące ruchu podczas przechwytywania, w trakcie wyświetlania analizator odkodowuje warstwy protokołu zawarte w zapisanych ramkach i wyświetla jest w postaci angielskich skrótów.

Dodatek D • SŁOWNICZEK

519

X Window — protokół służący do zarządzania oknami wysokiej rozdzielczości w stacjach roboczych. Opracowany przez MIT, DEC oraz IBM a następnie stopniowo przekazywany konsorcjum producentów i naukowców. X.25 — rekomendacja CCITT definiująca standard interfejsu komunikacyjnego umożliwiającego dostęp do sieci komutacji pakietów. XID (eXchange IDentification — identyfikacja podczas wymiany) — nienumerowana ramka wykorzystywana do prowadzenia negocjacji, które usługi LLC będą wykorzystywane podczas połączenia. XNS (Xerox Network Systems — system sieciowy Xerox) — rodzina protokołów Xerox; zasadniczo protokołów Internet Transport.

zadanie drugoplanowe (Background task) — praca dodatkowa wykonywana równolegle do działania podstawowego, np. wykonywanie obowiązków sieciowych przez serwer (kontrolowanie komunikacji) w trakcie korzystania przez użytkowników ze swoich aplikacji (takich jak edytory tekstu). zalew (Flooding) — technika stosowana przez mosty oraz przełączniki polegająca na tym, iż przepływ otrzymany przez interfejs jest wysyłany z wszystkich interfejsów urządzenia, za wyjątkiem interfejsu pierwotnie wysyłającego daną informację. zapytanie, kwerenda (query) — komunikat będący zapytaniem o wartość zmiennej lub kilku zmiennych. zarządzanie bezpieczeństwem (security management) — jedna z pięciu kategorii zarządzania siecią, zdefiniowana przez ISO w celu zarządzania sieciami OSI. Podsystemy zarządzania bezpieczeństwem są odpowiedzialne za kontrolowanie dostępu do zasobów sieciowych. zarządzanie siecią (network management) — ogólny termin opisujący systemy lub działania mające na celu pomoc w utrzymaniu, charakteryzowaniu i naprawianiu błędów w sieci. zdarzenie (Event) — komunikat sieciowy informujący o nieprawidłowościach w działaniu fizycznych części sieci. zewnętrzny protokół bramy (exterior gateway protocol) — protokół międzysieci używany do wymiany informacji routingu pomiędzy systemami autonomicznymi.

520

TCP/IP. SZKOŁA PROGRAMOWANIA

ZIP (Zone Information Protocol — protokół informacji strefowej) — protokół warstwy sesji AppleTalk, mapujący numery sieci na nazwy stref. ZIP jest używany przez protokół NBP do określenia, które sieci zawierają węzły należące do strefy. Interpretowany w zestawie AppleTalk PI. zmienna trasa statyczna (floating static route) — trasa statyczna, która ma wyższy dystans adminstracyjny niż wartość uzyskiwana dynamicznie, może więc być zastąpiona przez informacje uzyskane dynamicznie. znacznik (token) — niewielka wiadomość wykorzystywana w niektórych sieciach do reprezentowania pozwolenia na transmisję; przekazywany jest od stacji do stacji w ustalonej sekwencji.

m

ODPOWIEDZ! 10 PYTAŃ SPRAWDZAJĄCYCH Rozdział 1. 1. Głównym zadaniem modelu OSI jest zdefiniowanie środowiska komunikacyjne­ go niezależnego od producenta. Umożliwia to nawiązanie łączności pomiędzy różniącymi się oraz podobnymi protokołami, sprzętem, systemami operacyjnymi i architekturami sieci. 2. Warstwa sesji. 3. Mimo, ze cechy te odnoszą się najczęściej do warstwy transportowej, tak na­ prawdę zależy to od protokołu używanego w tej warstwie. Na przykład, jeżeli korzystamy z TCP warunki te będą z pewnością spełnione. Jeżeli natomiast ko­ rzystamy z UDP żaden z tych warunków nie będzie spełniony. 4. Przełączniki i mosty istnieją w drugiej warstwie modelu OSI — łącza danych. Przełączniki i mosty korzystają z warstwy drugiej (adresu MAC), aby podejmować decyzje o przekazywaniu. 5. Warstwa sieciowa. 6. Aplikacji, transportowa, sieciowa, dostępu do sieci. 7. Dwa przykłady to: obliczanie i weryfikacja sumy kontrolnej CRC oraz dostęp do nośnika. 8. UDP.

522

TCP/IP. SZKOŁA PROGRAMOWANIA

Rozdział 2. 1. Klasa A (1 -1 2 7 ), klasa B (128 -191), klasa C (192 - 223), klasa D (224 - 239), klasa E (240 - 247). 2. Maski podsieci określają czy lokalizacja miejsca docelowe jest lokalna, co infor­ muje hosta źródłowego czy może sam przesłać datagram, czy przesłać go za po­ średnictwem bramy. Maska podsieci hosta źródłowego przyrównywana jest do adresu IP hosta docelowego za pomocą bitowego AND w celu ustalenia jaka część adresu definiuje sieć. 3. Adresy warstwy sieci są logiczne i reprezentują 4-bajtowy adres IP hosta war­ stwy 3. Adresy te przypisywane są w sposób manualny lub dynamiczny. 4. 255.255.255.255 to wiadomość rozsyłana do wszystkich węzłów oraz wszystkich sieci. Wykorzystywany do rozgłaszania adres 0.0.0.0 oznacza nieznany host lub sieć, i jest najczęściej używany do określania bramy domyślnej. 127.0.0.1 wyko­ rzystywany jest do wewnętrznego testowania pętli zwrotnej. Następujące adre­ sy prywatne używane są w sieciach firmowych w celu poprawy adresowania IP. Adresy te nie mogą być wykorzystywane w Internecie. Firmy korzystające z tych adresów musza używać NAT aby umożliwić przełożenie ich na adresy zarejestro­ wane, które mogą być wykorzystywane w Internecie: 10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255,192.168.0.0 - 192.168.255.255. 5. 8 bitów. 6.14 podsieci i 14 hostów. 7. 255.255.255.224. 8. 126 podsieci i 510 hostow. 9. 5 bitów, dla maksimum 30 hostow. 10. 10 bitów, dla maksimum 1022 hostow. 1 1 .182 (128+32+ 16+ 4+ 2+ 1). 1 2 .11001001 (128+64+8+1). Binarnym ekwiwalentem 201 jest 11001001, niezależnie czy ma to oznaczać liczbę dziesiętna czy maskę podsieci.

Rozdział 3c 1.

ip

.

2. Echo ICMP (typ 8) oraz odpowiedź (typ 0) 3. Pakuje je jako datagramy, wraz z źródłowymi oraz docelowymi adresami IP warstwy sieciowej. 4. Nagłówek IP składa się minimalnie z 20 bajtów, chyba że występują dodatkowe opcje. Pola nagłówka IP w tych 20 bajtach zawiera informacje nt. wersji, długości

Dodatek E « ODPOWIEDZI DO PYTAŃ SPRAWDZAJĄCYCH

523

nagłówka, rodzaju usługi, długości całkowitej, identyfikacji, flagach, przsunięciu fragmentu, czasie ważności, protokołu, sumy kontrolnej, adresie źródłowym. Inne nagłówki zawierają dane oraz opcje. Pytanie dotyczy pól znajdujących się w nagłówku. Zakładamy, że jest to pole protokołu o wartości 0800. 5. Wykorzystywane są przez aplikacje do określenia poziomu usługi trasującej, którą zamierza użyć router przesyłając datagramy. 6. Pola identyfikacji oraz przesunięcie fragmentu. 7. Typ 3 ICMP jest „celem nieosiągalnym". Jeżeli otrzymujemy tą wiadomość, oznacza to, że poszukiwana sieć docelowa, host lub port są zbyt daleko lub nie są dostępne. 8. Wiadomość ICMP typu 3 oznacza cel nieosiągalny. Wiadomość ta z kodem błę­ du o wartości 4 oznacza, że potrzebna jest fragmentacja, ale ustawiony jest bit zabraniający fragmentacji. 9. Oznacza to, że poszukiwany host jest nieosiągalny. 10. Typ 11; oznacza to, iż czas TTL upłynął (osiągnął wartość 0).

Rozdział 4o 1. ARP wykonuje przekształcenia logicznego adresu warstwy sieciowej na sprzętowy adres łącza danych. Przekształcenie ARP oparte jest na rozgłoszeniu. 2. RARP wykonuje przekształcenie adresu sprzętowego warstwy łącza danych na adres logiczny warstwy sieciowej. RARP wykorzystywany jest przez urządzenia końcowe do pozyskiwanie adresów IP oraz konfigurowania parametrów poprzez serwer RARP. Zapytania i odpowiedzi są rozgłaszane. 3. BootP zastąpił RARP. Podstawowa różnica pomiędzy BootP a RARP to brak możliwości przesyłania zapytań i odpowiedzi RARP przez bramki lub agentów przekazuj ących. 4. Podstawowa różnica pomiędzy protokołem DHCP a BootP to fakt, iż DHCP nie korzysta z tablic odwzorowań. DHCP może obsługiwać dynamiczne oraz statyczne mapowania adresu. 5. W zależności od implementacji, hosty mogą korzystać z trzech mechanizmów w celu usunięcia starych lub nieważnych rekordów z tablicy ARP: upływu czasu, odpytywania monoemisyjnego oraz urządzenia warstwy łącza danych lub wyższej. 6. Proxy ARP umożliwia urządzeniom, takim jak brama, odpowiadanie na zapytania ARP w imieniu zdalnego hosta. 7. Pole Opcode nagłówka określa rodzaj wykonywanej operacji ARP lub RARP. Wartość 1 w polu Opcode oznacza zapytanie ARP, 2 oznacza odpowiedź ARP, 3 zapytanie RARP, a 4 odpowiedź RARP. 8. Jeżeli host chce się komunikować z urządzeniem zdalnym porównuje adres IP hosta docelowego z adresem maski podsieci hosta źródłowego w celu ustalenia

524

TCP/IP- SZKOŁA PROGRAMOWANIA

czy host zdalny znajduje się w segmencie lokalnym. Jeżeli host źródłowy okre­ ślający adresata znajduje się w tej samej podsieci, może „rozgłosić" (wysłać lo­ kalny ARP). W przeciwnym razie musi dokonać „skierowania" (wysłać lokalny ARP w celu przekształcenia adresu sprzętowego bramki) aby móc przekazywać w przyszłości datagramy. 9. DHCP ma osiem rodzajów komunikatów: odkrywanie, oferta, żądanie, ACK, NAK, odmowa, zwolnienie, informacja. 10. Cztery typy komunikatów DHCP obecnych w początkowej czterofazowej pro­ cedurze konfiguracyjnej, zachodzącej między klientem a serwerem DHCP to: odkrywanie, oferta, żądanie, ACK.

R ozdział 5. 1. Poprzez bezpośrednio podłączony interfejs, statycznie, domyślnie lub dynamicznie. 2. Eliminuje cały ruch związany z uaktualnianiem tras (zaleta); jest idealne dla łą­ czy WAN typu „punkt-punkt" i dla sieci wdzwanianych; może zapewniać ścież­ kę zapasową gdy zawodzi łącze podstawowe; w całej sieci (dużej) jest nieprak­ tyczne; ma niezwykle duże koszty administrowania (wada); lepiej sprawdza się w sieciach małych. 3. rozgłaszaniem; trasowaniem klasowym (uaktualnienia nie obejmują maski pod­ sieci); kontrolą uaktualnień przez liczniki czasu; wysyłaniem zawsze całej tabeli, bez względu na zmiany; podatnością na pętle trasowania; najlepszym przysto­ sowaniem do sieci małych i średnich; definiowaniem średnicy sieci przez mak­ symalną odległość; wykorzystywaniem skoków jako jedynj metryki. 4. Trasowania statycznego użyjemy raczej w niewielkich sieciach lub łączach typu punkt-punkt. Jeżeli chcemy zupełnie wyeliminować ruch związany z aktualizacją trasowania, skorzystamy z trasowania statycznego. 5. Trasowanie domyślne zapewnia trasę w przypadku kiedy inną metodą nie może być ona odnaleziona. 6. IGP i EGP. 7. IP RIPvl, IP RIP v2, IGRP, EIGRP i OSPF. 8. IP RIPvl, IP RIP v2 i IGRP. 9. Skoki; IP RIP ma maksymalnie 15 skoków. IGRP ma maksymalnie 255 skoków. 10. Liczenie do nieskończoności, powstrzymywanie, dzielony horyzont, odtrutka. 11. Dzielony horyzont chroni przed pętlami trasowania poprzez zabezpieczenie trasowanych informacji przed ich rozpowszechnieniem przez ten sam interfejs, który je odebrał. 12. Pojemność łącza (szerokość pasma); opóźnienie; niezawodność; obciążenie; MTU. 13. OSPF.

Dodatek E • ODPOWIEDZI DO PYTAŃ SPRAWDZAJĄCYCH

525

R ozdział 6. 1. RIP uważany jest za protokół trasujący IGP oraz trasujący protokół wektorowo-odległościowy. 2. Cechy charakterystyczne RIP to: jest oparty na metodzie rozgłoszeniowej, IGP, najlepiej pracuje w niedużych sieciach, oraz jest to trasujący protokół wektorowo-odległościowy. 3. RIP korzysta z najkrótszej trasy, mierzonej w skokach. 4. Routery co 30 sekund wysyłają swoje rozgłoszenia, zawierające całe tablice tra­ sujące. 5.25. 6. 15. 7. Multiemisja, identyfikacja, VLSM (trasowanie bezklasowe). 8. Wersja 2 jest kompatybilna wstecz z wersją 1, a protokół stanu łącza jest znacznie wydajniejszy. 9. Wady RIPvl to: jest oparty na metodzie rozgłoszeniowej; wysyła całą tablicę nawet w przypadku gdy nie wystąpiły w niej żadne zmiany; spowalnia zbieżność (konwergencję), wskutek okresowości czasomierzy; ogranicza się do maksymalnej odległości wynoszącej 15 skoków; jest podatny na pętle trasowania; przeprowadza trasowanie klasowe, nie obsługuje VLSM. 10. RIP korzysta z liczenia do nieskończoności, powstrzymywania, dzielonego ho­ ryzontu, odtrutki. 11. RIP wykorzystuje czasomierz uaktualniania okresowego, czasomierz nieważności i czasomierz powstrzymywania. 12. OSPF jest uważany za protokół trasujący stanu łącza oraz IGP. 13. Pojemność łącza (szerokość pasma); opóźnienie; niezawodność; obciążenie; MTU. 14. OSPF ma przewagę nad protokołami RIP ponieważ: potrafi konfigurować hie­ rarchiczne (a nie tylko płaskie) domeny trasowania, dzieląc system autonomicz­ ny na wiele obszarów. Dzięki temu zmiany sieciowe są od siebie oddzielane, ruch uaktualniający jest kierowany do różnych obszarów, a obciążenie spowo­ dowane przeliczaniem tabel trasowania maleje; dzięki uaktualnieniom wyzwa­ lanym potrafi szybko przystosowywać się do zmian w intersieci; wysyła tylko zmiany, a nie całą tabelę; obsługuje sieci duże; obsługuje równoważenie obciążenia (load balancing) ruchu za pośrednictwem nadmiarowych ścieżek o kosztach równych i nierównych; uwierzytelnia wymianę informacji z tabel trasowania; obsługuje maski typu VLSM; zamiast rozgłoszeń stosuje multiemisje. 15. Protokół OSPF charakteryzują następujące cechy: multiemisja; szybka zbieżność; uaktualnienia wyzwalane; trasowanie bezklasowe; ToS lub QoS; uwierzytelnianie; trasy o kosztach równych i nierównych; implementacja obszarów pojedynczych lub sąsiadujących;

526

TCP/IP. SZKOŁA PROGRAMOWANIA

16. baza danych przylegania (tj. tabela sąsiadów); baza danych stanu łączy (tj. mapa topologii); baza danych przekazywania (tj. tabela trasowania). 17. Jest to tablica sąsiadów routera. Jeżeli router nie utworzył przylegania ze swoimi sąsiadami, nie mogą oni dokonywać wymiany informacji trasowanych. 18. Jest to kompletna mapa przedstawiająca całą topologię międzysieci. 19. Baza danych przekazywania OSPF jest lokalną tablicą tras, która posiada tablicę „najlepszych tras". 20. OSPF wykorzystuje LSA do tworzenia bazy danych stanu łącza oraz do komu­ nikowania się w obrębie jej obszaru lub poza nim. 21. Zewnątrzobszarowe ogłoszenia OSPF wysyłane są wyłącznie przez routery do innych roterów znajdujących się w określonym obszarze, a ogłoszenia wewnątrzobszarowe wysyłane są przez routery ABR do innych routerów w obsza­ rach podłączonych bezpośrednio. 22. Wyłączony; inicjalizacja; dwukierunkowy; exstart; wymiana; ładowanie; pełne dopasowanie (Fuli). 23. Wewnętrzny; szkieletowy; ABR; ASBR. 24. Typ 0.

25. Hello, opis bazy danych (DD), żądanie stanu łączy, uaktualnienie stanu łączy, potwierdzenie stanu łączy. 26. Pakiety Hello ustanawiają i utrzymują relacje przylegania. 27. Pakiet opisu bazy danych przedstawia zbiorczo zawartość bazy danych. 28. IGRP może używać różnych kombinacji metryk, w tym: szerokości pasma, czasu opóźnienia międzysieci, niezawodności oraz obciążenia. 29. Maksymalna ilość skoków 255 umożliwia obsługiwanie większych sieci. 30. Uaktualniania, nieważności, powstrzymywania, usuwania. 31. Cechy charakterystyczne EGRIP to: zapewnia szybszą zbieżność, natychmiast wysyłając uaktualnienia częściowe; obsługuje VLSM-y, włączając maski podsieci do uaktualnień; obsługuje wiele stosów protokolarnych, w tym TCP/IP, IPX/SPX i AppleTalk; przechowuje w tabelach trasowania ścieżki zapasowe; obsługuje opcje ToS protokołu IP; wykorzystuje metryki oparte na kosztach, podobnie do protokołu IGRP; zachowuje ścieżki zapasowe gdy istnieje wiele tras; korzysta z multiemisji i monoemisji. 32. EIGRP jest uważany za zrównoważony protokół hybrydowy. 33. Zaletą jest umożliwianie firmie korzystania z wielu protokołów, a utrzymywania tylko jednej tablicy trasującej. Wadą jest konieczność używania sprzętu firmy Cisco. 34. Trasa najlepsza nosi nazwę następnika (successor), a druga w kolejności (zapa­ sowa) —•‘ftrożliwego następnika (feasible successor).

Dodatek E • ODPOWIEDZI DO PYTAŃ SPRAWDZAJĄCYCH

527

35. Halo/ACK; uaktualnienia; zapytania (Queries); odpowiedzi; żądania. 36. EGP łączy ze sobą niezależne AS, podczas gdy IGP łączy z niezależnym AS. 37. VLSM, sumaryzacja tras, CIDR. 38. Gdy istnieje wiele punktów wyjścia, łączących z jednym ISP (do podziału obcią­ żenia); gdy istnieje wiele ścieżek do różnych ISP i chciałoby się dyktować sposób przekazywania ruchu tymi łączami; gdy wykorzystywane zasady czy też meto­ dy trasowania są różnorodne bądź wykraczają poza uproszczone stosowanie trasy domyślnej (tzn. potrzebny jest inteligentny wybór ścieżki i specyficzne kryteria); jeśli infrastruktura sieci służy za obszar tranzytowy ruchu sieciowego innej organizacji. 39. W topologii kraty pełnej (Full mesh) konieczne są oddzielne połączenia logiczne TCP między wszystkimi routerami BGP w obrębie tego samego systemu auto­ nomicznego, umożliwiające bramom szybkie stwierdzanie istnienia pętli i ich wycinanie. W topologii kraty częściowej (Partial mesh) nie jest konieczne, aby wszystkie routery utrzymywały między sobą połączenia logiczne. Dzięki temu liczba połączeń TCP jest mniejsza, ale otwiera się możliwość powstawania pętli trasowania. 40. Routery-nadajniki BGP (BGP speaker routers); trasowniki partnerskie (Peer) lub sąsiedzkie (neighbor routers); wewnętrzne routery partnerskie (Internal peer routers); zewnętrzne routery partnerskie (External peer routers). 41. Otrzymane informacje o trasach (tj. uaktualnienia); informacje o trasach prze­ znaczone do ogłoszenia; lokalną tabelę trasowania BGP. 42. TCP. 43. Otwarcie (Open); uaktualnienie utrzymywanie przy życiu.

(Update);

powiadomienie

(Notification);

44. Komunikat otwarcia BGP inicjuje relację partnerską BGP między partnerami wewnętrznymi lub zewnętrznymi. 45. Komunikaty powiadomienia (trzeci rodzaj komunikatu) występują po napotkaniu błędu przez routery BGP. Gdy router wysyła powiadomienie partnerzy zrywają wcześniej ustanowione połączenie TCP. 46. Atrybuty ścieżek. 47. Powszechnie znane obowiązkowe (Well-known mandatory); powszechnie zna­ ne uznaniowe (Well-known discretionary); opcjonalne przechodnie (Optional transitive); opcjonalne nieprzecliodnie (Optional nontransitive). 48. Gdy istnieje wiele ścieżek kierowania ruchu na zewnątrz danego AS, routery w nim zawarte mogą podwyższać wartość LP (Local Preference) dla różnych ścieżek, wskazując w ten sposób trasy preferowane. 49. BGP w.4 obsługuje VLSM, sumaryzację oraz preferencje lokalne, których nie ob­ sługuje BGP w.3. Ponadto, BGP w.4 obsługuje zarówno kratę pełną jak i czę­ ściową, natomiast BGP w.3 tylko pełną.

528

TCP/IP. SZKOŁA PROGRAMOWANIA

Rozdział 7. 1. Steruje komunikacją „od końca do końca" (end-to-end), czyli całościową, mię­ dzy dwoma procesami uruchomionymi na różnych hostach; zapewnia warstwom wyższym usługi połączeniowe oraz bezpołączeniowe; wykorzystuje adresy portów klienta i serwera do identyfikacji procesów uruchomionych na hoscie; segmentuje (dzieli na segmenty) dane aplikacji warstw wyższych. 2. Protokoły połączeniowe mają następujące możliwości: ustanowienie sesji (Session setup); potwierdzenia (Acknowledgements); sekwencjonowanie (Sequencing); sterowanie przepływem (Flow control); komunikaty utrzymywania przy życiu (Keepalives); zerwanie sesji (Session teardown), niezawodna dostawa, spowol­ nienie dostarczenia danych, usuwanie błędów oraz retransmisja danych. 3. Standardowe porty serwera definiują programy powszechnie znane w branży i stały się przyjętą normą ich adresowania. Ich zasięg to 0 - 255. 4. Porty serwera mniej standardowe są portami zarezerwowanymi, które producenci mogą wdrażać w razie potrzeby. Ich zasięg to 254 -1023. 5. Porty klienta są zmienne („eteryczne"), wymyślane na poczekaniu („w locie") za każdym razem, gdy proces klienta się zaczyna i otwiera nowy port. Ich zakres tol024 - 65535. 6. Łączenie gniazd w pary jest terminem opisującym połączenie całościowe dwóch hostów (źródłowego i docelowego), obejmujące zarówno ich adresy IP, jak i porty. 7. UDP zapewnia szybkie, zawodne przesyłanie wiadomości pomiędzy aplikacjami uruchomionymi na zdalnych hostach. TCP zapewnia wolniejszą ale niezawodną dostawę danych. 8. Jest to ostrzeżenie dla hosta wysyłającego aby zwolnił lub wstrzymał transmisję. 9. Muszą wybierać pomiędzy szybkością (UDP) a niezawodnością (TCP). 10. Potwierdzenia i sekwencjonowanie wykorzystywane są przez TCP aby pomagać w utrzymaniu porządku wysyłanych danych oraz aby zapewnić ich dostarczenie.

Rozdział 8. 1. W trakcie działania, protokół TCP steruje komunikacją między procesami w oparciu o następujące działania i cechy: ustanawianie i zrywanie połączenia; zwielokrot­ nianie (Multiplexing); przesył danych; sterowanie przepływem; niezawodność; priorytety i zabezpieczenia. 2. TCP musi ustanowić łącze logiczne lub sesję pomiędzy komunikującymi się portami zanim aplikacje warstwy górnej będą mogły wymieniać określone dane. 3. Zwielokrotnianie umożliwia TCP jednoczesne ustanawianie i utrzymywanie wielu ścieżek komunikacyjnych pomiędzy hostami.

Dodatek E • ODPOWIEDZI DO PYTAŃ SPRAWDZAJĄCYCH

529

4. TCP otrzymuje od aplikacji warstw wyższych strumienie danych (wiadomości), organizuje je w segmenty, które przekazuje w dół, do warstwy sieciowej, gdzie staną się datagramami. 5. Mechanizm okienkowy steruje wejściowym potokiem danych. 6. TCP zapewnia niezawodną dostawę pakietów poprzez potwierdzenia i sekwencjonowanie. 7. Protokoły połączeniowe mają następujące cechy: ustanowienie sesji (Session setup); potwierdzenia (Acknowledgements); sekwencjonowanie (Sequencing); sterowanie przepływem (Flow control); komunikaty utrzymywania przy życiu (Keepalives); zerwanie sesji (Session teardown) 8. Łączenie gniazd w pary opisuje połączenie całościowe dwóch hostów (źródłowego i docelowego), obejmujące zarówno ich adresy IP, jak i porty. 9. Retransmisja danych występuje po tym jak łącze logiczne (połączenie TCP) zostaje ustanowione pomiędzy procesami hostów zdalnych. 10. Nagłówek TCP zawiera pola: port docelowy, numer potwierdzenia, port źródłowy, numer kolejny, przesunięcie danych, flagi, okno, suma kontrolna, wskaźnik pil­ ności i opcje TCP.

Rozdział 9. 1. UDP jest zdefiniowane w RFC 768. 2. Protokół UDP zapewnia aplikacjom uruchomionym na zdalnych hostach szybką, bezpołączeniową ale zawodną dostawę danych. 3. Typ 7 protokołu identyfikuje UDP w nagłówku IP. 4. UDP nie korzysta z sekwencjonowania i potwierdzania do gwarantowania do­ stawy danych. Funkcje te pozostawia innym protokołom. Identyfikuje jedynie port źródłowy i docelowy, wysyła dane i oczekuje, że dotrą one do punktu przeznaczenia. 5. Podczas operacji przesyłania danych protokół UDP zakłada istnienie stabilnej i niezawodnej infrastruktury sieciowej wspomagającej przesyłanie danych. Polega na innych protokołach w kwestii wykrywania i usuwania błędów. 6. UDP nie odpowiada za utrzymywanie połączenia. UDP nie ustanawia połączenia pomiędzy hostami; dlatego nie odpowiada za jego utrzymywanie. 7. UDP daje szybszą dostawę pakietów i mniejsze przeciążenie, niż TCP. 8. UDP korzysta z sumy kontrolnej CRC (Cyclic Redundancy Check) do wynaj­ dywania uszkodzonych ramek w nagłówku UDP, danych warstwy górnej oraz pseudonagłówku IP. 9. Suma kontrolna sprawdza poprawność nagłówka UDP, danych górnej warstwy, oraz pseudonagłówka IP.

530

TCP/IP. SZKOŁA PROGRAMOWANIA

10. Pseudonagłówek UDP zawiera następujące informacje: adres logiczny (warstwy sieciowej) hosta źródłowego; adres logiczny (warstwy sieciowej) hosta docelowego; typ protokołu warstwy transportowej; długość datagramu UDP.

Rozdział 10. 1. Aplikacji, prezentacji i sesji. 2. Zapewnienie dostępu do zasobów oraz usług zdalnego hosta, przesyłu plików (FTP lub TFTP), operacji na plikach oraz drukowania, poczty elektronicznej. 3. FTP oraz TFTP. 4. Zapewnienie wspólnego formatu danych dla różnych platform. 5. Koordynowanie dialogu pomiędzy dwiema aplikacjami. 6. NFS (warstwa aplikacji), XDR (prezentacji) oraz RPC (sesji).

Rozdział 11. 1. Umożliwia użytkownikowi uruchomienie sesji terminala klienta w celu uzyskania dostępu do hosta zdalnego (lub serwera Telnet) poprzez sieci TCP/IP. 2. W momencie rozpoczęcia sesji protokołu Telnet, aplikacja na danym kompute­ rze staje się klientem. Klient ustanawia połączenie TCP z serwerem Telnet (hostem zewnętrznym) korzystając ze standardowego połączenia trzyetapowego TCP, które zostało opisane w rozdziale 8. Klient komunikuje się poprzez połą­ czenie TCP korzystając z klawiatury tak, jakby podłączona była bezpośrednio do terminala zewnętrznego hosta. Serwer korzysta z urządzenia pseudoterminala. Określa ono punkt wejścia systemu operacyjnego, który umożliwia programowi takiemu jak Telnet przesyłanie danych do innych systemów operacyjnych, na takich samych zasadach jakby pochodziły z komputera lokalnego. 3. Wykorzystywane są do negocjowania parametrów pomiędzy klientami a serwerami. 4. Transmisja binarna, echo, zatrzymaj polecenie wykonaj, stan, oznaczenie punktu czasowego, typ terminala, koniec zapisu, rozmiar okna, prędkość terminala, zdalna kontrola przepływu, tryb wierszowy, zmienne środowiska. 5. Wirtualny terminal sieciowy (NVT) — zapewniający standardowy interfejs dla systemów zdalnych, negocjowanie różnych opcji pomiędzy klientem, a serwerem, oraz równorzędne traktowanie terminali oraz przetwarzania. 6. NVT zapewnia, iż komunikacja zachodzi w sposób niewidoczny, a ilość opcji, wykorzystywanych w komunikacji pomiędzy zewnętrznymi klientami i serwe­ rami, jest minimalna. Poprzez utworzenie wirtualnego terminala, zmniejszone zostały różnice pomiędzy urządzeniami komunikacyjnymi i zapewniony został wspólny zestaw poleceń, co sprawiło, iż wszystkie urządzenia komunikacyjne działają na równych zasadach.

Dodatek E ° ODPOWIEDZI DO PYTAŃ SPRAWDZAJĄCYCH

531

7. Do kodowania znaków i przez urządzenia wyświetlające. 8. Każda ze stron może zażądać opcjonalnego parametru. Jeżeli druga strona nie obsługuje danej funkcji lub nie może jej używać, żądanie zostaje odrzucone. Obie strony uzgadniają i korzystają z funkcji, które obsługują, a wszystkie pozostałe opcje utrzymują na minimalnym poziomie wymaganym przez standard NVT. 9. Interpretuj jako polecenie (IAC — Interpret as command). 10. Każda ze stron może wysłać następujące cztery zapytania: WILL — Wysyłający chce uruchomić daną opcję. DO — Wysyłający chce aby odbiorca uruchomił daną opcję. WONT — Wysyłając chce wyłączyć daną opcję. DONT — Wysyłając chce aby odbiorca wyłączył daną opcję. 11. WILL/DO, WILL/DONT, DO/WILL, DO/WONT, WONT/DONT, DONT/WONT.

Rozdział 12. 1. FTP umożliwia zdalnemu lub lokalnemu klientowi i serwerowi wydajne prze­ syłanie plików lub danych korzystając z niezawodnego transportu TCP: Pro­ mowanie wymiany plików (programy komputerowe lub dane), zachęcanie do pośredniego albo wybiórczego korzystania ze zdalnych komputerów, ochrona użytkownika przed mnogością istniejących systemów przechowywania plików wśród hostów, niezawodne oraz wydajne przesyłanie danych. 2. Interfejsu użytkownika — zapewnia interfejs użytkownika oraz kieruje inter­ pretatorem protokołu klienta. PI klienta — interpretator protokołu klienta. Kieruje polecenia do interpretatora protokołu zdalnego serwera oraz kieruje procesem przesyłania danych klienta. PI serwera — interpretator protokołu serwera. Odpowiada na polecenia PI klienta oraz kieruje procesem przesyłania danych serwera. DTP klienta — proces przesyłu danych klienta. Komunikacja pomiędzy procesem przesyłu danych serwera oraz lokalnym systemem plików. DTP serwera — proces przesyłu danych serwera. Komunikacja pomiędzy DTP klienta oraz lokalnym systemem plików. 3. Interpretator protokołu obsługuje polecenia i odpowiedzi. 4. Interpretator serwera nasłuchuje na standardowym porcie 21 w celu kontroli zapytań o połączenie i oczekuje na komunikację klienta. Interpretator protokołu klienta inicjuje połączenie wysyłając zapytanie TCP SYN w formie wiadomości kontrolnej zaadresowanej do docelowego TCP na standardowy port 21. 5. Przez port 20 (dane) i port 21 (kontrola). 6. Reprezentacja danych — Identyfikuje rodzaj wysyłanego pliku, Struktura danych — Określa format przesyłanych danych, Tryb transmisji — Określa jak dane przesyłane są poprzez połączenie.

532

TCP/IP. SZKOŁA PROGRAMOWANIA

7. ASCII (domyślny), EBCDIC, plik obrazu (zwany również binarnym), plik lokalny. 8. FTP reprezentuje struktury danych na trzy różne sposoby: plik (domyślny), zapis, strona. 9. Strumieniowy (domyślny), blokowy, skompresowany. 10. Nonprint, polecenie formatu Telnet, kontrola karetki Fortranu. 11. Tryb strumieniowy ma następujące cechy charakterystyczne: jest trybem domyśl­ nym, dane przesyłane są w strumieniu bajtów oraz umożliwia występowanie struktur rekordów. 12. Interpretatory protokołu klienta i serwera przesyłają polecenia i odpowiadają na nie w postaci łańcuchów NVT ASCII (Telnet) poprzez połączenie kontrolne. Polecenia te można podzielić na trzy kategorie: kontrola dostępu, parametry transferu i usługi. 13. Odpowiedzi FTP występują w postaci numerów trzycyfrowych z towarzyszącą opcjonalnie wiadomością tekstową następującą po ciągu liczbowym. Format odpowiedzi FTP umożliwia zarówno użytkownikowi interaktywnemu, jak i pro­ gramowi, odczytywanie odpowiedzi poprzez opatrzenie ich informacjami wyja­ śniającymi. Odpowiedź FTP gwarantuje synchronizację żądań i działań podczas transferu plików oraz sprawia, że użytkownik zawsze zna stan serwera. 14. Możliwość przesyłania plików przez Internet bez konieczności posiadania in­ dywidualnego konta użytkownika, dzięki anonimowemu FTP. Oznacza to, że nie musimy być oficjalnymi użytkownikami danego systemu aby uzyskać dostęp do oferowanych przez niego plików.

R ozdział 13. 1. Prosty protokół przesyłania poczty elektronicznej (SMTP) zapewnia wymianę poczty elektronicznej pomiędzy nadawcą (klientem) a odbiorcą (serwerem). 2. Użytkownicy mają natychmiastowy dostęp do systemu poczty elektronicznej poprzez UA. Poprzez UA użytkownik tworzy, przekazuje oraz odbiera wiadomości poczty elektronicznej. 3. SMTP ułatwia dostarczania wiadomości pocztowych (agenci transferu wiado­ mości — MTA) pomiędzy aplikacjami pocztowymi klienta i serwera (zwanymi agentami użytkownika). 4. SMTP ma następujące ograniczenia: wiadomość musi zawierać tylko znaki ASCII, maksymalna długość wiersza nie może przekroczyć 1000 znaków, wiadomość nie może przekroczyć określonego rozmiaru maksymalnego. 5. Polecenia SMTP mają pewne podstawowe zasady: każde polecenie SMTP skła­ da się z kodu oraz argumentu polecenia, kod polecenia składa się z czterech znaków alfabetu pisanych wielką lub małą literą, kod oddzielony jest od argu­ mentu jedną lub większą ilością spacji, ponieważ każdy z hostów może posiadać

Dodatek E • ODPOWIEDZI DO PYTAŃ SPRAWDZAJĄCYCH

533

swoje indywidualne reguły adresowania poczty, decydują o tym argumenty ścieżki odwrotnej oraz ścieżki przekazania, sekwencja znaków karetki — nowej linii () kończy również pole argumentu, nawiasy kwadratowe zawierają argumenty opcjonalne. 6. Klienci i serwery SMTP używają trzech cyfr do komunikowania odbioru informacji oraz notyfikowania drugiej strony o wykryciu błędu. 7. Odpowiedź SMTP składa się z trzycyfrowego kodu dla komputera oraz tekstu dla użytkownika. Użytkownik może wykorzystać te informacje do określenia stanu swojej odpowiedzi. 8. Rozszerzenie MIME zapewnia transmisję dla danych poprzednio nie obsługi­ wanych przez pocztę internetową poprzez odkodowanie wiadomości do postaci ASCH, która może być odczytana, w celu utworzenia standardowej wiadomości elektronicznej.

Rozdział 14. 1. Przestrzeń nazw ma następujące problemy: jej rozszerzenie jest trudne, na co wpływa wymagany narzut pracy, jest mało wydajna oraz kosztowna. 2. Serwery podstawowe odczytują informacje z plików znajdujących się na dysku. Serwery wtórne otrzymują informacje od podstawowych. 3. Ponieważ komputery używają liczb (na przykład, adresów IP i adresów MAC) do adresowania, a nie nazw, dlatego metoda taka jak DNS musi istnieć aby do­ konywać przekształcania nazw. 4. Korzysta z systemu hierarchicznego rozpoczynającego się od nazw domen gór­ nego poziomu, przechodząc następnie do bardziej specyficznych nazw niższych poziomów. 5. Buforowanie oznacza przechowywanie informacji w RAM. Serwery nazw prze­ chowują wszystkie zapytania (mapowania) zapisując je na dysku lub buforując w pamięci RAM. W ten sposób serwer zachowuje wszystkie ostatnio przekazy­ wane dane i posiada najnowsze przekształcenia nazw. Buforowanie, poprzez swoją szybkość, obniża również koszty przekształcania nazw nie znajdujących się w zasobach lokalnych. 6. Jeżeli po sprawdzeniu własnego bufora, serwer nie może wciąż udzielić klien­ towi odpowiedzi, sam staje się klientem (występując jako pośrednik hosta źró­ dłowego) i za pośrednictwem odpowiednio sformatowanej wiadomości zadaje serię pytań autorytatywnemu serwerowi. 7. Każda wiadomość składa się z trzech elementów: nazwy domeny, która ma zostać przekształcona, ► klasy lub rodziny protokołów używanych przez nazwę domeny, ►- rodzaju nazwy domeny.

534

TCP/IP. SZKOŁA PROGRAMOWANIA

8. NetBEUI jest typową implementacją protokołu 2 warstwy zaprojektowaną do przesyłania datagramów wewnątrz sieci jednolitej. NetBIOS jest usługą nazewniczą oraz datagramu. 9. Modyfikacje NetBIOS umożliwiają mu funkcjonowanie w warstwie 3 dzięki wykorzystaniu TCP/IP. 10. 37,138 i 139. 11. Rodzaje węzłów NetBIOS: ► B-node (węzeł rozgłoszeniowy) — korzysta z rozgłoszenia, a następnie z pliku LMHost. ► P-node (węzeł punkt-punkt) — korzysta jedynie z serwera NBNS. ► M-node (węzeł mieszany) — klient korzysta najpierw z b-node, p-node, a następnie z pliku LMHost. ► H-node (węzeł hybrydowy) — klient korzysta najpierw z p-node, b-node, a następnie z pliku LMHost. 12. Agentem proxy jest każdy host skonfigurowany do przyjmowania lokalnego rozgłoszenia o przekształcenie, a następnie przekazania go jako datagramu skie­ rowanego do zdalnego serwera WINS.

R ozdział 15. 1. HTTP potrzebny jest do odnalezienia poszukiwanej strony WWW. Protokół HTTP jest wskazywany w pierwszej części URL. 2. HTTP umożliwia komunikację pomiędzy przeglądarką stacji roboczej a serwerem WWW. 3. Przeglądarka działa jak aplikacja i otwiera strony WWW. 4. HTTP pracuje na poziomie aplikacji i odpowiada za ustanawianie łącza komu­ nikacyjnego oraz przekazywanie wiadomości. Nie gwarantuje niezawodności, ani retransmisji danych. 5. HTTP posiada następujące cechy: Zapewnianie transferu dwukierunkowego, korzystanie ze zdolności do negocjowania (capability negotiation), obsługa bu­ forowania, umożliwianie obsługi pośredników, działanie w warstwie aplikacji, zapewnia ustanowienie łącza komunikacyjnego oraz przesyłanie wiadomości; nie gwarantuje niezawodności oraz ponownego przesyłu; serwer nie przechowuje historii sesji HTTP lub naszych zapytań HTTP. 6. HTTP wspomaga buforowanie, co oznacza oszczędności w czasie dzięki temu, że nasza przeglądarka wprowadza do bufora kopię każdej pobranej przez nas strony. Jeżeli chcemy ponownie skorzystać z takiej strony, HTTP sprawia, iż przeglądarka zwraca się z zapytaniem do serwera, o to czy zawartość strony różni się od kopii znajdującej się w buforze.

Dodatek E • ODPOWIEDZI DO PYTAŃ SPRAWDZAJĄCYCH

535

7. Pracuje jako pośredniczący host HTTP występujący w roli klienta lub serwera HTTP dzięki czemu UA i serwer źródłowy mogą wymieniać informacje. Agenci proxy przekazują zapytania od klientów do serwerów. Serwery same również odpowiadają na zapytania jeżeli poszukiwana informacja jest lokalna. 8. Wszystkie urządzenia wzdłuż ścieżki pomiędzy przeglądarką a serwerem mogą być serwerami proxy. 9. Format wiadomości HTTP jest następujący: Wiersz startowy, zwany wierszem zapytania (request line) dla wiadomości przesyłających zapytania oraz wiersz stanu (status line) dla wiadomości zawierających odpowiedzi, nagłówek ogólny, nagłówek wiadomości, jeden pusty wiersz, treść wiadomości. 10. Treść wiadomości jest przeznaczona do odczytania przez użytkownika. 11. Wiadomości nagłówkowe są przeznaczone do odczytania przez przeglądarkę. 12. Wiadomości o błędach wskazują rodzaj wykrytego błędu oraz zaistniały problem z dostawą danych.

Rozdział 16. 1. FTP pracuje na TCP powodując, iż jest on zorientowany połączeniowo; TFTP pracuje na UDP powodując, iż jest on bezpołączeniowy. 2. Jest to prosty i szybki protokół przesyłu, wolny od poważnych narzutów pracy. 3. Szybki, zawodny i bezpołączeniowy transfer plików. 4. Strona wysyłająca (klient TFTP) otwiera różne porty klienta UDP (nazywanym ID TFTP lub transferu), żąda pliku i oczekuje na potwierdzenie każdego bloku, przed wysłaniem kolejnego. Strona odbierająca potwierdza każdy blok po otrzymaniu danych. 5. HTTP korzysta z pięciu rodzajów pakietów: żądanie odczytu (RRQ), żądanie zapisu (ERQ), dane (DATA), potwierdzenie (ACK), błąd (ERROR). Żądanie od­ czytu i żądanie zapisu rozpoczynają zapytanie i określają jaki plik ma zostać przesłany. Pakiety danych przesyłają żądane dane. Pakiet ACK potwierdza od­ biór każdego z bloków (pakietu danych) otrzymanego w trakcie transferu danych. Pakiet błędu potwierdza każdy inny rodzaj pakietu oraz sygnalizuje pojawienie się błędu. 6. Koniec transferu pliku. 7. TFTP korzysta z metody potwierdzania nazwy lock-step, która polega na tym, iż każdy pakiet danych musi zostać potwierdzony zanim kolejny zostanie wysła­ ny. Należy pamiętać, że TFTP przesyła bloki danych pojedynczo, nadając pierwszemu blokowi danych numer jeden.

536

TCP/IP. SZKOŁA PROGRAMOWANIA

8. Trzy wydarzenia generujące pakiety błędu to: ► Host nie może zrealizować żądania (na przykład, nie może zlokalizować pliku). > Host otrzymuje opóźniony lub skopiowany pakiet. B> Utrata przez hosta dostępu do zasobu, takiego jak np. dysk, podczas transferu. 9. Jeżeli klient żąda odczytu, serwer rozpoczyna transfer. Jeżeli klient żąda zapisu, transmisją rozpoczyna klient. 10. Klient TFTP inicjuje połączenie poprzez żądanie odczytu lub zapisu pliku na lub z serwera. Klient dokonuje tego poprzez otwarcie zmiennego portu (TFTP TID) dla odbierającego, standardowego portu 69 serwera TFTP. Klient określa nazwę pliku oraz rodzaj danych w zapytaniu inicjującym. Po wysłaniu zapytania ini­ cjującego, serwer TFTP przyporządkowuje sobie nowy port TID na czas trwania transmisji danych i w ten sposób rozpoczyna się transfer. Jeżeli klient wystąpił z żądaniem odczytu, transfer rozpoczyna serwer; jeżeli klient wystąpił z żądaniem zapisu, to on rozpoczyna transmisję. 11. Opcja rozmiaru bloku umożliwia wymianę większych datagramów. Większe rozmiary bloków zwiększają możliwości przesyłu plików pomiędzy zdalnymi hostami. 12. Serwery TFTP, które umożliwiają prowadzenie negocjacji opcji, dysponują pa­ kietem potwierdzenia opcji (OACK) w celu notyfikowania klienta o możliwości skorzystania z danej opcji. Jeżeli serwer zaakceptuje opcję, informuje o tym klienta i wprowadza ją do pakietu OACK. Jeżeli natomiast nie akceptuje opcji, po prostu ją ignoruje i nie wprowadza jej do ramki OACK. Klienci korzystają tylko z tego na co zezwalają serwery. Klient może żądać wielu opcji podczas procesu negocjacji wymieniając je wszystkie w pakiecie odczytu lub zapisu. Klient wprowadza żądanie opcji do standardowego żądania odczytu lub zapisu, używanego do inicjowania sesji pomiędzy klientem i serwerem. 13. Pakiet OACK jest potwierdzeniem negocjowanej opcji.

Rozdział 17. 1. SGMP. 2. Agenci, menadżerowie i pośrednicy (proxy). 3. Agenci SNMP obsługują programy odpowiadające oraz generujące notyfikacje. 4. Proxy SNMP zapewniają możliwość przesyłania wiadomości pomiędzy agentami i menadżerami. Pełnią one również funkcje pośredników pomiędzy agentami hostów korzystających z różniących się rodzajów SNMP, zapewniając w ten sposób kompatybilność pomiędzy hostami. 5. Jako hosty, menadżerowie SNMP obsługują oprogramowanie (np. OpenView) służące do zdalnej kontroli i monitorowania agentów SNMP. Hosty te stanowią centralny punkt zarządzania, będący jednocześnie interfejsem użytkownika,

Dodatek E • ODPOWIEDZI DO PYTAŃ SPRAWDZAJĄCYCH

537

przekazując polecenia agentom za pośrednictwem SNMP. Menadżerowie to programy generujące polecenia oraz odbiorcy notyfikacji. 6. Pułapka PDU korzysta z innego formatu wiadomości niż pozostałe cztery rodzaje PDU, ponieważ informuje raczej o powstałych zdarzeniach, niż odpowiada na zapytania menadżerów.

R ozdział 18. 1. NFS, RPC i XDR. 2. NFS zapewnia dostęp do informacji poprzez rozproszony system plików w do­ wolnej architekturze sieciowej. 3. XDR tłumaczy i prezentuje dane w taki sposób aby dwa różne systemy operacyjne mogły się wzajemnie komunikować. 4. RPC oferuje protokół oraz niezależny interfejs, które umożliwiają ustanowienie dwukierunkowego łącza komunikacyjnego pomiędzy zdalnymi procesami ko­ munikacyjnymi. RPC rezyduje w warstwie sesji i z tego powodu jest odpowie­ dzialny za ustanowienie sesji pomiędzy dwoma procesami hosta oraz jej utrzy­ mywanie i prowadzenie. 5. Sun Microsystem.

538

TCP/IP. SZKOŁA PROGRAMOWANIA

SKOROWIDZ 100BaseFX, 39 100BaseT4, 39 100BaseTX, 39 lOOBaseX, 39 10Base2, 39 10Base5, 38 lOBaseT, 39

fi A (rekord zasobów), 331 AA, 328 ABR, 175 Accept-Charset, 351 Accept-Encoding, 351 Accept-Language, 351 ACH, 273 ACK, 129,130,234,237,242,246, 360,361 Acknowledgement Number, 234 acknowledgements, 223 address resolution, 105 Address Resolution Protocol, 58 adres DNS, 127 docelowy, 80,90 DSAP, 37 loopback, 56 MAC, 30,244 pętla zwrotna, 56 protokolarny, 114 prywatny, 57 przekaźnik poczty powiązany z nazwą domeny, 324

SAP AA, 36 sprzętowy, 114 URL, 271,343 warstwa druga, 30 źródłowy, 80, 89 adres IP, 51, 53 adresy zarezerwowane, 57 atrybuty adresów, 54 hierarchia, 53 klasa A, 55 klasa B, 56 klasa C, 56,58 klasa D i E, 56 klasy, 53 maska sieci, 58 NAT, 57, 73 NetlD, 54 podział na podsieci, 61 sieci prywatne, 57 tłumaczenie adresów, 73 translacja, 57 adresowanie fizyczne, 30 IP, 51,52 logiczne, 29, 78 MAC, 29, 30 wewnętrzne, 57 Advertising Router, 197 agent proxy WINS, 339 SNMP, 370 transferu wiadomości, 308,310, 311 użytkownika, 308, 310

540

TCP/IP. SZKOŁA PROGRAMOWANIA

Aggregator, 215 agregacja tras, 69 algorytm CRC, 30 DUAL, 202,203 stan łącza, 169 wektor odległości, 145 Allow, 352 Aloha Net, 31 amplifikacja, 41 ANCOUNT, 330 anonimowy FTP, 289, 303 ANSI, 31 ANSI X3T9.5,42 aplikacja, 31 UDP, 263 AppleTalk, 48,150 architektura łącza danych, 31 ARCOUNT, 330 Area ID, 192 AREN, 53,55, 61, 70 ARP, 29, 58,105,107 bufor, 110 DLC, 114 długość adresu protokolarnego, 115 długość adresu sprzętowego, 115 działanie protokołu, 107 HA, 115 Hardware Type, 114 HLen, 115 kod operacji, 115 lokalne rozgłaszanie, 59 nagłówek, 113 niewłaściwie skonfigurowana maska podsieci, 59 odpytywanie monoemisyjne, 111 Opcode, 115 PA, 115,116 PLen, 115 Protocol Type, 114 rozgłaszanie, 59,108 Sender's HA, 115 Sender's PA, 115 skierowanie, 108 Target HA, 115 Target PA, 116 typ protokołu, 114

typ sprzętu, 114 Unicast Poll, 111 upływ czasu, 110 zawiadomienie przez warstwę łącza lub wyższą, 111 ARPA, 35 ARPANET, 290 AS, 144 AS_path, 215 ASBR, 175 ASCII, 280 ASN.l, 368 ATM, 46,48 Atomic_Aggregate, 215 AU, 310 Authentication, 192 Authorization, 351 automount, 381, 383 automounter, 383 auto-polecenie, 384 AuType, 192 awaria sprzętu, 35

B Backup Designated Router, 195 bajt, 51 balanced signaling, 32 bandwidth, 148 baseband, 34 Basic Rate ISDN, 48 baza danych OSPF, 171 BDR, 170,174,181 bezdyskowa stacja robocza, 358 bezklasowy routing międzydomenowy, 69 bezpołączeniowe dostarczanie datagramów, 78 BGP, 29,143,205 Aggregator, 215 AS_path, 215 Atomic_Aggregate, 215 atrybuty ścieżki, 209, 214 działanie, 209 external peer routers, 208 informacje o osiągalności sieci, 207 internal peer routers, 208 kody typów atrybutów ścieżek, 214, 215

SKOROWIDZ

komunikaty otwarcia, 210, 211 komunikaty powiadomienia, 212, 213 komunikaty uaktualnienia, 211,212 komunikaty utrzymywania przy życiu, 209, 213 Local Preference, 215 MED, 216 MultiExit-Descriptor, 215 nagłówek, 209 neighbor routers, 208 Next_Hop, 215 niezawodność, 207 preferencje lokalne, 216 problemy sieciowe, 207 routery, 207 routery partnerskie, 208 routery-nadajniki, 208 speaker routers, 208 tabela routingu, 209 wersja 3, 217 wersja 4,217 wewnętrzne routery partnerskie, 208 wykluczanie pętli routingu, 207 zastosowanie, 206 zewnętrzne routery partnerskie, 208 BIOS, 334 bit, 31 bit repeating, 41 bitowe powtarzanie, 41 bitwise ANDing, 58 blok sterowania transmisją, 238 błędy jakości sygnału, 32 B-node, 337 Boot File Name, 126 BootP, 29 BOOTP, 96,105,106,121 adres IP bramy, 125 adres IP klienta, 124 adres IP serwera, 125 adres sprzętowy klienta, 125 Boot File Name, 126 Client Hardware Address, 125 Client IP Address, 124 datagram monoemisji, 122 Gateway IP Address, 125 Hien, 124 Hops, 124

Htype, 123 inicjowanie klientów, 121 kod operacji, 122 konfiguracja serwera, 122 nagłówek, 122,123 nazwa hostowa serwera, 125 nazwa pliku rozruchowego, 126 obszar specyficzny dla dostawcy, 126 odpowiedź, 126 rozgłaszanie skierowane, 122 Sekundy, 124 Server Host Name, 125 Server IP Address, 125 serwer, 122 skoki, 124 Transaction ID, 124 Vendor-Specific Area, 126 Your IP Address, 125 żądanie, 126 BootPC, 264 BootPS, 264 bootstraping, 101 brama, 61 domyślna, 57,143 BRI, 48 broadcast, 33 bufor ARP, 110 odbiorczy, 256 buforowanie, 344 DNS, 326 c caching, 326 capability negotiation, 344 carbon copy, 310 carriage control, 281 catchall message, 103 Centrum Informacji Sieciowej, 320 chaddr, 138 Checksum, 192, 237,266 choke packet, 255 ciaddr, 137 CIDR, 69,71 cienki kabel koncentryczny, 32 circuit-switched, 44

541

542

TCP/IP. SZKOŁA PROGRAMOWANIA

Classless Inter-Domain Routing, 69 CMIP, 374 CNAME, 331 collisions, 32 Communication Administratively Prohibited by Filtering, 99 Connect, 348 Content-Base, 352 Content-Encoding, 352 Content-Language, 352 Content-Length, 352 Content-Location, 352 Content-MD5, 352 Content-Range, 352 Content-Type, 352 core-distribution-access, 143 count to infinity, 161 CRC, 25, 35, 266 CSMA/CD, 33,34 CUT, 103 cutoff, 99 cykliczna kontrola nadmiarowości, 25, 30 czas Greenwich, 103 czas życia, 88 czasomierze IGRP, 201 RIP, 163 TCP, 253 częściowa krata, 207

D DARPA, 22 Data Offset, 236 datagramy, 261 DD, 196 DDR, 46 Dead Interval, 195 DECNet, 19 default gateway, 57,143 dekompresja, 27, 273 delay, 148 delegacja zarządu domenami DNS, 322 DELETE, 348 demultiplekser, 46 DEMUX, 46 Designated Router, 195

Destination Address, 80 Destination Host Administratively Prohibited, 99 Destination Host Unknown, 98 Destination Network Administratively Prohibited, 98 Destination Network Unknown, 98 Destination Port, 233,265 DF, 84 DHCP, 29,105,106,127 ACK, 130 adres IP bramy, 138 adres IP klienta, 137 adres IP serwera, 138 adres sprzętowy klienta, 138 chaddr, 138 ciaddr, 137 czas trwania dzierżawy, 135 czterofazowa wymiana komunikatów, 130 dwufazowa wymiana komunikatów, 134 dynamiczne przypisywanie adresów, 135 dziedzina, 127 file, 139 flagi, 137 giaddr, 138 Hien, 137 Htype, 137 informacje, 135 komunikaty, 128,129 metody przydzielania danych konfiguracyjnych, 128 nagłówek, 136 NAK, 130 nazwa hostowa serwera, 138 nazwa pliku rozruchowego, 139 odkrywanie, 129 odmowa, 130 oferta, 129 opcje, 139 potwierdzenie, 133 przydzielanie danych konfiguracyjnych, 128 pula adresów IP, 127 siaddr, 138 skoki, 137 sname, 138 twój adres IP, 138

SKOROWIDZ

typy komunikatów, 129 wymiana komunikatów, 129,130 xid, 137 yiaddr, 138 zakres, 127 zwolnienie, 135 żądanie, 129,133 diagnostyka, 90 Dial-on-Demand Routing, 46 dial-up, 46 directly connected interfaces, 142 DIX, 35, 36 DLC, 79,114 długość nagłówka IP, 80 DNS, 127,258,264,272,320, 321,322, 331 A, 331 adres przekaźnika poczty powiązanego z nazwą domeny, 324 ANCOUNT, 330 ARCOUNT, 330 buforowanie, 326 caching, 326 CNAME, 331 delegacja zarządu domenami, 322 dodawanie hosta do strefy, 324 domeny, 325 domeny górnego poziomu, 322 flagi, 328 format wiadomości, 327 hierarchia nazw, 325 HINFO, 331 identyfikatory, 325 mapowanie, 326 mapowanie odwrotne, 326 MINFO, 331 MX, 331 nagłówek odpowiedzi, 330 nagłówek pytań, 330 nazwy domen, 325 nazwy górnej warstwy, 323 NS, 331 NSCOUNT, 330 odpowiedzi, 330 Opcode, 328, 329 przekształcanie nazwy, 326, 331 przestrzeń nazw, 320 PTR, 331

543

QDCOUNT, 330 QR, 327 Rcode, 329 rekordy zasobów, 323, 331 rekursja, 328 rozchodzenie się informacji o nazwach, 324 RR, 323 serwer, 324 serwer autorytatywny, 324, 325 serwer nieautorytatywny, 324 serwer podstawowy, 324 serwer wtórny, 324 SOA, 331 strefy, 323 strefy drugiego poziomu, 323 szukanie adresu, 325 transfer strefowy, 324 tworzenie systemu domen, 325 TXT, 331 typy nazw domen, 330 układ hierarchiczny, 323 wiadomość, 327 zapytania, 326, 330 zapytania iteracyjne, 328 zapytania odwrotne, 326 DoD, 20,22, 222,231 DoD Advanced Research Projects Agency, 22 dokumenty RFC, 47 domeny, 325 górnego poziomu, 322 nazwy, 325 typy nazw, 330 Don't Fragment, 84 dopełnienie, 90 dostarczanie danych, 222 dostawca usług, 71 dostęp z nasłuchiwaniem nośnej z detekcją kolizji, 33 DR, 170,181 drzewo klienta, 381 DSAP, 37 DTP, 291 DUAL, 202,203 dual-ring, 42 dynamiczna konfiguracja hostów, 127 dynamiczne odkrywanie rozmiaru MTU, 84

544

TCP/IP. SZKOŁA PROGRAMOWANIA

dynamiczny NAT, 74 dziedzin DHCP, 127 dzielony horyzont, 147,161 dźwięk, 273

E early token release, 43 EBCDIC, 273,296 echo, 91 echo reply, 91 EGP, 144,145,206 EIGRP, 29,144,149, 202 algorytm DUAL, 202, 203 domena routingu, 202 dopuszczalny spadkobierca, 203 działanie, 202 Hello/ACK, 205 odpowiedzi, 205 pakiety Hello, 203 spadkobierca, 203 trasy, 203 typy pakietów, 205 uaktualnienia, 205 unikanie pętli, 202 zapytania, 205 żądania, 205 eksportowanie, 380 eksportowany system plików, 380 e-mail, 272 EMI, 32, 42 encapsulation, 35 ETag, 352 Ethernet, 31 100BaseFX, 39 100BaseT4, 39 100BaseTX, 39 100BaseX, 39 10Base2, 39 10Base5, 38 lOBaseT, 39 awaria sprzętu, 35 CSMA/CD, 33, 34 dostęp z nasłuchiwaniem nośnej z detekcją kolizji, 33 gigabitowy, 40 IEEE 802.3, 33

kolizje, 34 metoda dostępu do kanału, 34 nadbiornik, 34 odwzorowanie nazw, 35 opóźnienie propagacji, 34 ramki, 35, 36 rozgłaszanie, 33 sygnalizacja niezrównoważona, 33 sygnalizacja zrównoważona, 33 transmisja, 34 wersje, 32 Ethernet_802.2, 36, 37 Ethernet_802.3, 35, 36, 37 Ethernet_II, 32, 35, 36, 37 Ethernet_SNAP, 36, 38 Ethertype, 79 Ether-Type, 37 Expires, 352 ExStart, 180 external Data Representation, 275 F Fast Ethernet, 31, 39 FCS, 25, 30 FDDI, 31,42,184 maksymalna szybkość transmisji, 42 metoda dostępu do kanału, 43 okablowanie, 42 zawijanie pierścienia, 42 file, 139 FIN, 237,249 firewall, 57 flagi IP, 80, 84 ostatni fragment, 86,88 więcej fragmentów, 86, 87, 88 flagi TCP, 236 flow control, 223 format wiadomości DNS, 327 fragmentacja datagramów, 84 frame, 30 Frame Relay, 46,48 From, 351 FTP, 27, 258, 263, 273, 289 ABOR, 300 ACCT, 299 ALLO, 300

SKOROWIDZ

anonimowy dostęp, 303 APPE, 300 ASCn, 295

CDUP, 299 CWD, 299 DELE, 300 DTP, 291 działanie, 302 EBCDIC, 296 HELP, 300 historia, 290 interfejs użytkownika, 293 interpretator protokołu serwera, 291 klient, 291 kody odpowiedzi, 301 kontrola formatu, 296 LIST, 300 minimalizacja opóźnień, 292 MKD, 300 MODE, 299 NLST, 300 NOOP, 300 odpowiedzi, 301 PASS, 299 PASV, 299 PI, 291 polecenia, 298 polecenia parametrów transferu, 299 polecenia serwera, 300 połączenie, 291 PORT, 299 port danych, 293 porty, 291 proces przesyłu danych, 291 przeglądarki internetowe, 291 PWD, 300 QUIT, 299 REIN, 299 reprezentacja danych, 294 REST, 300 RETR, 300 RMD, 300 RNFR, 300 RNTO, 300 serwer, 291 sesja, 291

SITE, 300 SMNT, 299 STAT, 300 STOR, 300 STOU, 300 STRU, 299 struktury danych, 294,297 SYST, 300 transfer plików, 302 tryb blokowy, 298 tryb skompresowany, 298 tryby transmisji, 294, 295,298 TYPE, 299 typy danych, 295 USER, 299 FTP-Data, 258 full mesh, 207 full-duplex, 27, 245, 274

G GE, 40 GET, 348 giaddr, 138 GIF, 273 Gigabit Ethernet, 31,40 gniazda, 28,226,240 łączenie w pary, 29, 245 pary, 228 Gopher, 258 gruby kabel koncentryczny, 32

H HA, 114,115,120,121 half-duplex, 27, 274 Hardware Address, 114 hardware failure, 35 HDLC, 47, 48 HEAD, 348 header, 22 Header Checksum, 80 heartbeat, 32 Hello, 193 Hello Interval, 194 HEMS, 368, 374

545

546

TCP/IP. SZKOŁA PROGRAMOWANIA

hermetyzacja, 35 Cisco, 48 IETF, 48 WAN, 46 hierarchia adresy IP, 53 nazwy DNS, 323, 325 High-level Data Link Control, 47 HINFO, 331 hipertext, 344 HLen, 115,120 H-node, 338 hold down, 147,161 hop count, 89 Hops, 124 Host, 351 host bezdyskowy, 121 Host Precedence Violation, 99 Host Unreachable, 96 HTML, 355 HTTP, 27,271, 343 Accept-Charset, 351 Accept-Encoding, 351 Accept-Language, 351 agent proxy, 345 agent użytkownika, 345 aktualizacja, 350 Allow, 352 Authorization, 351 brama, 345 buforowanie, 344 cechy, 344 ciągi komunikacyjne, 345, 356 Connect, 348 Content-Base, 352 Content-Encoding, 352 Content-Language, 352 Content-Length, 352 Content-Location, 352 Content-MD5, 352 Content-Range, 352 Content-Type, 352 data, 349 DELETE, 348 ETag, 352 Expires, 352 From, 351

GET, 348 HEAD, 348 Host, 351 If-Modified-Sience, 351 If-None-Match, 351 If-Range, 351 If-Unmodified-Since, 351 kodowanie transferu, 350 kody błędów, 353 kody stanu, 353 komponenty, 345 kontrola bufora, 349 Last-Modified, 352 Max-Forwards, 351 nagłówki obiektu, 352 nagłówki odpowiedzi, 352 nagłówki wiadomości, 349, 351 nagłówki zapytania, 351 obiekt, 352 odpowiedzi, 348, 351 OPTIONS, 348 ostrzeżenie, 351 połączenie, 349 POST, 348 pragma, 350 proxy, 345 Proxy-Authorization, 351 przeglądarka, 345 pusty wiersz, 352 PUT, 348 Range, 351 Referer, 351 serwer źródłowy, 345 sesja, 346 stopka, 350 Tracę, 348 trailer, 350 treść wiadomości, 352 tunel, 345 UA, 345, 351 URL, 346 URN, 346 wiadomości, 348 wiadomości o błędzie, 355 wiadomości odpowiedzi, 353 wiersz stanu, 348 wiersz startowy, 348

SKOROWIDZ

wiersz zapytania, 348 zapytania, 348, 351 zasoby, 345, 356 zdolność do negocjowania, 344 żetony metod, 348

I LAB, 49, 368 IAC, 284 IBM 3270,280 ICMP, 29, 59, 77, 90 Communication Administratively Prohibited by Filtering, 99 Destination Host Administratively Prohibited, 99 Destination Host Unknown, 98 Destination Network Administratively Prohibited, 98 Destination Network Unknown, 98 echo, 90, 91, 95 echo reply, 91 Host Precedence Violation, 99 Host Unreachable, 96 Host Unreachable for ToS, 99 kod komunikatów, 92 komunikat ogólny, 103 komunikaty, 90, 91 nagłówki, 91 Network Unreachable, 96 Network Unreachable for ToS, 99 numer kolejny, 93 odbiorca nieosiągalny, 96 odpowiedź echa, 95 odpowiedź informacji, 103 odpowiedź maski adresu, 104 odpowiedź znacznika czasu, 103 ogłaszanie, 101 ping, 94 Port Unreachable, 96 poszukiwanie routera, 101 potrzebna jest fragmentacja, ale ustawiono bit „nie fragmentować", 98 Precedence Cutoff in Effect, 99 problem z parametrami, 103 Protocol Unreachable, 96 przekierowanie, 100

przekroczony czas, 101 rodzaje komunikatów, 92 Source Host Isolated, 98 Source Route Failed, 98 suma kontrolna, 93 tłumienie nadawcy, 100 TTL, 102 typy komunikatów, 94 zawiodła trasa źródłowa, 98 żądanie echa, 95 żądanie informacji, 103 żądanie maski adresu, 104 żądanie znacznika czasu, 103 ID, 80, 83 identyfikacja urządzeń w sieci, 30 identyfikator sieci, 54 IEEE, 31 IEEE 802.3, 31, 32, 33, 35 IEEE 802.3 SNAP, 35 IEEE 802.3u, 39 IEEE 802.5,40 IETF, 49 If-Modified-Sience, 351 If-None-Match, 351 If-Range, 351 If-Unmodified-Since, 351 IGP, 144,206 IGRP, 29,144,145,149,199 czas opóźnienia, 199 czasomierze, 201 liczba skoków, 199, 200 metryki kosztów, 199 metryki złożone, 200 niezawodność, 199 obciążenie, 199 podział obciążenia, 201 routing wielościeżkowy, 201 równoważenie obciążenia, 201 sąsiad, 199 sieć, 200 stabilność sieci, 201 system autonomiczny, 200 szerokość pasma, 199 implied acknowledgement, 234 instrukcje sąsiedzkie, 164 interfejs podłączony bezpośrednio, 142

547

548

TCP/IP. SZKOŁA PROGRAMOWANIA

interferencje elektromagnetyczne, 32, 42 radiowe, 42 Internet, 49 Internet Architecture Board, 49 Internet Engineering Task Force, 49 Internet Protocol, 77 Internet Research Task Force, 49 Internet Service Provider, 71 Internet Society, 49 internetowy serwer nazewniczy Windows, 338 intranet, 49 IP, 48, 77,150,154 adresowanie logiczne, 78 bezpołączeniowe dostarczanie datagramów, 78 datagram, 79 długość całkowita datagramu, 80 długość nagłówka, 80 dopełnienie, 90 Ethertype, 79 flagi, 80, 84 ID, 83 MTU, 84 nagłówek, 79 numer identyfikacyjny, 80, 83 opcje, 90 protokół, 80, 89 przesunięcie fragmentu, 80, 85 suma kontrolna nagłówka, 89 ToS, 80 TTL, 80, 88 typ usługi, 80 wersja, 80 zastosowania, 78 IPNG, 73 IPv4, 73 IPv6,73 IPX, 36,48,150 IPX/SPX, 36 IRTF, 49 ISDN, 46,47,48,164 ISN, 247 ISO, 21,368 ISO's CMIP, 368 ISOC, 49 ISP, 61, 71

J jakość usługi, 170 jazda na barana, 27 jednolite sieci, 334 JPEG, 273

K karta sieciowa, 23 adres MAC, 30 Token-Ring, 40 kategorie portów, 227 keepalives, 209,224 kierowanie, 58 klasy adresów IP, 53 klient bezdyskowy, 121 NFS, 381 klient/serwer, 272 kodowanie, 273 sygnały, 31 kody ASCII, 280 komunikaty ICMP, 92 błędy HTTP, 353 kontrolne NVT, 282 stan HTTP, 353 kolizje, 34 spóźnione, 34 kompresja, 27, 273 komunikacja zewnętrzna, 277 komunikaty DHCP, 128,129 ICMP, 90,91,94 utrzymywanie przy życiu, 224, 255 koncentrator MSAU, 40 koncepcyjny schemat, 21 lconiunkcja bitowa, 58, 60 kontrola przeciążenia, 256 konwersja dane, 273 dwójkowo-dziesiętna, 51

r

SKOROWIDZ

L LAN, 32,38,40 LAN Manager, 335 LAPB, 47,48 LAPD, 47 Last-Modified, 352 late collisions, 34 Length, 265 liczba skoków, 89 liczby dwójkowe, 51 liczenie do nieskończoności, 147 line feed, 281 linear bus, 32 linia analogowa, 46 dedykowana, 44, 45 dzierżawiona, 44,45 ISDN, 46 Link State Advertisement Header, 197 Link State Algorithm, 169 Link State ID, 178,197 LLC2,47 LMHost, 337 load, 148 Local Area Network, 32 Local Preference, 215 Local Procedure Call, 386 lock-step, 360 logical circuit, 239 LOGIN, 258 lokalne rozgłoszenie ARP, 108 lokalne wywołanie procedury, 386 loopback, 56 LPC, 386 LS Advertisements, 198 LS Age, 177 LS Checksum, 178 LS Sequence Number, 178 LS Type, 178,197 LSA, 169,173

Ł łącze danych, 25, 30, 31 architektura, 31 Ethernet, 31

IEEE 802.3, 31 topologie, 31 łącze punkt-punkt, 142 łączenie gniazdy w pary, 29, 245 połączenia, 48 w nadsieci, 69

M MAC, 30, 35 magistrala liniowa, 32 MAIL, 310 maksymalna jednostka transmisji, 84 maksymalny rozmiar ramki, 84 maksymalny rozmiar segmentu, 238 mapowanie, 382 DNS, 326 maska podsieci, 58,65 zmienna długość, 63 maska VLSM, 63,149 Max-Forwards, 351 Maximum Segment Size, 238 MED, 216 menadżer SNMP, 369 Message Transfer Agent, 308 Message Transfer System, 311 metoda dostępu do kanału, 34 Ethernet, 34 FDDI, 43 Token-Ring, 41 metoda routingu, 141 metryka, 160 MIB, 368 Microsoft SMB, 270 MIDI, 273 MIME, 316 MINFO, 331 M-node, 338 model DoD, 22 warstwa aplikacji, 269 model nazewniczy X.400, 310 model referencyjny OSI, 19,20 warstwy, 21,24 modułowa konstrukcja OSI, 23 montowanie, 381 most, 30

549

550

TCP/IP. SZKOŁA PROGRAMOWANIA

mount, 381 MPEG, 273 MS, 310 MSAU, 40 MSS, 238 MTA, 308, 310, 311 MTS, 311 MTU, 84,85,148,200 multicast, 101 multiemisja, 145,170 MultiExit-Descriptor, 215 multilinking, 48 multimedia, 273 multipath routing, 201 multiplekser, 46 MUX, 46 MX, 331

N nadajnik-odbiornik, 34 nadbiornik, 34 nadsieci, 69 nagłówek, 22 ARP, 113 BGP, 209 BOOTP, 122 DHCP, 136 ICMP, 91 IP, 79 LSA, 176 RARP, 119 RIP w.l, 158 RPC, 386 TCP, 232 UDP, 264 najlepsza ścieżka, 145 największa liczba skoków, 147 NAK, 129,130 NAT, 57, 73 dynamiczny, 74 statyczny, 74 tłumaczenie wiele na jeden, 74 tłumaczenie wiele na niewiele, 74 tłumaczenie wzajemnie jednoznaczne, 74 nazwy, 319, 320 DNS, 320 domeny internetowe, 325

NetBIOS, 334 UNC, 336 WINS, 338 NBMA, 184,185 NBNS, 338 NCP, 290 NDN, 311 NetBEUI, 334,335 NetBIOS, 28,274,275, 334,335 autorytatywna odpowiedź, 333 B-node, 337 działanie, 339 H-node, 338 LAN Manager, 335 logiczne API, 335 M-node, 338 nazwy, 334 plik LMHost, 337 P-node, 337 porty, 336 przekształcanie nazwy, 334 TCP/IP, 335 typy węzłów, 337 UNC, 336 węzeł hybrydowy, 337 węzeł mieszany, 337 węzeł punkt-punkt, 337 węzeł rozgloszeniowy, 337 węzły, 337 WINS, 338 zapytania, 334 NetlD, 54 Network Basic Input Output System, 275 Network File System, 275 Network Information Center, 320 Network Interface Card, 23 Network Mask, 194 Network Unreachable, 96 Network Unreachable for ToS, 99 Network Virtual Terminal, 272 Next_Hop, 215 NFS, 274, 275, 378 automatyczne przyłączanie, 381 automount, 381, 383 automounter, 383 auto-polecenie, 384 drzewo klienta, 381

SKOROWIDZ

działanie, 380, 391 eksportowanie, 380 eksportowany system plików, 380 klient, 381 lokalny punkt montowania, 382 mapowanie, 382 montowanie, 381 odmontowanie, 381 odpowiedź RPC, 391 określanie udostępnianych zasobów, 383 plik konfiguracyjny eksportu, 383 połączenie zdalnej struktury plików, 381 procedury serwera, 389 produkty, 380 przyłączanie, 379 punkt montowania, 381 RPC, 385 serwer, 383 uprawnienia, 392 wersje, 378 XDR, 384 NIC, 23, 320 niezawodność, 148, 242 node types, 337 noise, 32 Non-Broadcast Multi-Access, 184 notacja ASN.l, 368 NS, 331 NSCOUNT, 330 NSSA, 176,189 Number of Advertisements, 198 numer kolejny, 234 numer potwierdzenia, 234 NVT, 272,280 kody kontrolne, 282 NVT ASCII, 280

0 OACK, 365 obciążenie, 148 obliczanie maska podsieci, 65 zakres adresowy hostów, 67 obwód logiczny, 239 odbiór ramek, 30 odcinanie, 99

551

odkodowywanie, 273 odkrywanie DHCP, 129 odmontowanie, 381 odmowa DHCP, 130 odnajdywanie adresów IP, 323 odpowiedź echo, 91 FTP, 301 SMTP, 314 odszyfrowywanie, 27 odtrutka, 147,162 odwzorowanie nazw ethernetowych, 35 oferta DHCP, 129 okienkowanie, 234, 257 okno, 237, 256 przesuwne, 242 oktet, 51 ONC, 275, 377 Opcode, 114,115,120, 329 opóźnienie, 148 propagacja, 34 OPTIONS, 348 orgin server, 345 OSI, 222 OSI Reference Model, 20 OSPF, 29,143,144,149,169 ABR, 175 Advertising Router, 178 ASBR, 175 awaria łącza, 170 Backup Designated Router, 195 baza danych, 171 baza danych przekazywania, 172 baza danych przylegania, 171 baza danych stanu łączy, 172 BDR, 174 charakterystyka, 170 DD, 178,196 Dead Interval, 195 Designated Router, 195 dostęp wielokrotny bez rozgłaszania, 184 działanie, 172 działanie w różnych architekturach łącza danych, 184 Ethernet, 184 Hello Interval, 194 ID stanu łączy, 178

552

TCP/IP. SZKOŁA PROGRAMOWANIA

OSPF interwał braku aktywności, 195 interwał powitania, 194 Link State ID, 178 LS Advertisements, 198 LS Age, 177 LS Checksum, 178 LS Sequence Number, 178 LS Type, 178 LSA, 173 łącze wirtualne, 189 maska sieci, 194 multiemisja, 170 nagłówek LSA, 176,197 nagłówki dodatkowe, 192 NBMA, 184,185 Network Mask, 194 NSSA, 176,189 Number of Advertisements, 198 numer kolejny, 196 numer kolejny LS, 178 obszar 0,187 obszar całkowicie szczątkowy, 188 obszar nie tak szczątkowy, 176,189 obszar standardowy, 188 obszar szczątkowy, 188 obszary, 171 ogłoszenia międzyobszarowe, 175 ogłoszenia stanu łączy, 173,198 ogłoszenia wewnątrzobszarowe, 174 ogłoszenia zewnętrzne, 175 opcje, 194 pakiety, 190 pakiety Hello, 193 pakiety Opisu Bazy Danych, 178,195 pakiety potwierdzenia stanu łączy, 198 pakiety uaktualnienia stanu łączy, 197 pakiety żądania stanu łączy, 197 pola pakietu, 190 połączenia punkt-punkt, 185 priorytet routera, 195 przyleganie, 171 QoS, 170 router ABR, 184 router ASBR, 184 router desygnowany, 195 router ogłaszający, 178

router szkieletowy, 183 router wewnętrzny, 183 routing bezldasowy, 170 rozgłaszanie, 184 równoważenie obciążenia, 169,171 sąsiad, 195 sieć złożona z wielu obszarów, 186 stan dwukierunkowy, 180 stan ExStart, 180 stan inicjowania, 179 stan ładowania, 183 stan łączy, 169 stan pełnego dopasowania, 183 stan wymiany, 182 standardowy obszar szczątkowy, 188 stany routera, 178 stub area, 188 suma kontrolna LS, 178 system autonomiczny, 186 szybka zbieżność, 170 Token-Ring, 184 ToS, 170,171 trasy o różnych kosztach, 170 typy obszarów, 187 typy pakietów, 191 typy routerów, 183 uaktualnienia wyzwalane, 170 uwierzytelnianie, 170,192 VLSM, 169,171 zalety, 169 zapasowy router desygnowany, 195 ostatni fragment, 86,88 otwarte przetwarzanie sieciowe, 377

P PA, 114,115,116,120,121 packet framing, 30 Packet Length, 191 packet switching, 29 packet-switched, 44, 231 pakiety, 221 EIGRP, 205 TFTP, 358 tłumienia, 255,256 para gniazd, 29,228,240,245 partial mesh, 207

SKOROWIDZ

pasmo podstawowe, 34 PDU, 371, 373 pełna krata, 207 pętla, 146 zwrotna, 56, 57 PI, 291 PICT, 273 pierścień, 40 podwójny, 42 piggybacking, 27 ping, 91, 94 PLen, 115,120 plik LMHost, 337 P-node, 337 początkowy numer kolejny, 247, 251 poczta elektroniczna, 27, 272, 307 MIME, 316 protokół przesyłania, 272 SMTP, 272,307 podsieci, 58,59, 61 podstawowy serwer nazw, 324 podział na podsieci, 61, 62 podział obciążenia, 201 poison reverse, 147,162 polecenia SMTP, 313, 314 Telnet, 281 polecenia FTP, 299 kontrola dostępu, 299 parametry transferu, 299 serwer, 300 połączenia FTP, 291 komutowane, 46 punkt-punkt, 185 TCP, 239 TFTP, 362 WAN, 44 porozumienie trzyetapowe, 247 Port Unreachable, 96 porty, 28, 226, 477 dobrze znane, 227 docelowy, 233 kategorie, 227 klienckie, 227 NetBIOS, 336 standardowe, 227

TCP, 258 UDP, 263 zarezerwowane, 227 źródłowy, 233 POST, 348 potwierdzenia, 223,250 lock-step, 360 wywnioskowane, 234 powolny Ethernet, 38 powstrzymywanie, 147,161 PPP, 48 Precedence Cutoff in Effect, 99 PRI, 48 Primary Rate ISDN, 48 propagation delay, 34 prośba o echo, 91 Protocol Address, 114 Protocol Unreachable, 96 protokoły, 19 ARP, 58,105,106,107 ATM, 48 bezpołączeniowe, 221,225, 262 BGP, 143, 205 BOOTP, 106,121 bramy graniczne, 153 datagramy użytkownika, 28, 221 DHCP, 106,127 dynamiczna konfiguracja hostów, 127 EGP, 144,145 EIGRP, 149,202 Frame Relay, 48 FTP, 263,273,289 górna warstwa, 269 HDLC, 47,48 hermetyzacja WAN, 46 HTTP, 271, 343 ICMP, 77,90 IGP, 144 IGRP, 145,199 informacje o routingu, 154 internetowe, 77 IP, 77 IPX, 36 ISDN, 48 komunikaty sterujące Internetu, 77, 90 LAPB, 48 NetBEUI, 334

554

TCP/IP. SZKOŁA PROGRAMOWANIA

protokoły NetBIOS, 28, 275, 334 NFS, 275 ONC, 275, 377 OSPF, 143,149,169 połączeniowe, 221, 223 PPP, 48 przesyłanie hipertekstu, 27, 343 przesyłanie plików, 27 RARP, 106,116 RIP, 145,154 RIP w.l, 155 RIP w .2,167 routing, 218 RPC, 385 SDLC, 47 SLIP, 48 SMTP, 272, 307 SNMP, 367 stan łącza, 148 sterowanie transmisją, 28,221 TCP, 28,221,231 Telnet, 272, 277 TFTP, 273, 357 UDP, 28, 221, 225, 261 warstwa aplikacji, 269 warstwa prezentacji, 273 warstwa transportowa, 221 wektor odległości, 146 XDR, 28,274 proxy, 345 Proxy ARP, 111 działanie, 111 etapy działania, 112 proxy SNMP, 371 Proxy-Authorization, 351 przeglądarka HTTP, 345 przekazywanie żetonu, 40,41,43 przekierowanie, 100 ICMP, 59 przekształcanie nazw, 319 DNS, 322, 331 NetBIOS, 334 WINS, 338 przełączanie obwody, 44, 45 pakiety, 29, 44, 46

przełącznik, 30 przestrzeń nazw, 320 przesunięcie dane, 236 fragment, 80,85 przesyłanie dane TCP, 241 hipertekst, 343 poczta elektroniczna, 272 przesyłanie plików, 273, 289 FTP, 289 TFTP, 357 pseudonagłówek TCP, 238 UDP, 266 PSH, 237 PTR, 331 punkt montowania, 381 PUT, 348

Q QDCOUNT, 330 QoS, 149,150,170 QR, 327 QuickTime, 273

R RA, 328 ramka, 26, 30 DIX, 36 Ethernet, 35, 36 Ethernet_802.2, 36, 37 Ethernet_802.3, 35, 36, 37 Ethernet_II, 35, 36, 37 Ethernet_SNAP, 36, 38 Token-Ring, 41 ramkowanie pakietów, 30 Range, 351 RARP, 29,105,116,117 długość adresu protokolarnego, 120 długość adresu sprzętowego, 120 działanie protokołu, 116 HA, 120,121 HLen, 120 kod operacji, 120

SKOROWIDZ

logiczny adres protokolarny, 117 nagłówek, 119 Opcode, 120 PA, 120,121 PLen, 120 typ protokołu, 119 typ sprzętu, 119 wady protokołu, 119 zapytania, 117 Rcode, 329 RCPT, 310 RD, 328 RDR, 270 rdzeń-rozprowadzanie-dostęp, 143 readresator, 22 klient, 270 receive buffer, 256 redirector, 22 Referer, 351 rejestr ARIN, 61 rekordy zasobów, 323, 331 reliability, 148 Remote Procedure Call, 28, 275 repeater, 31 Request For Comments, 47 responder serwera, 270 retransmisja danych, 253 Retransmit Time-Out, 254 RFC, 47 RFC 791, 79 RFI, 42 ring, 40 ring wrap, 42 RIP, 29,144,145,154 cechy, 154 urządzenia, 155 RIP w.l, 149,155 adres IP, 159 awaria łącza, 160 Command, 158 czasomierze, 163 dodanie łącza, 160 dzielony horyzont, 161 filtry uaktualniania tras, 164 host, 155 identyfikator rodziny adresów, 159 implementacje, 161,162

555

komunikaty, 158 liczba skoków, 157 liczenie do nieskończoności, 161 łącza WAN, 164 metryka, 160 nagłówek, 158 obwody tworzone na żądanie, 164 odtrutka, 162 pakiety dla obwodów tworzonych na żądanie, 166 pola nagłówka, 158 polecenia, 159 powstrzymywanie, 161 sterowanie ruchem uaktualniania tras, 164 tabela routingu, 155 uaktualnienia, 156 uaktualnienia wyzwalane, 165 Version, 158 wady protokołu, 160 wybór ścieżki, 156 zapobieganie pętlom, 161 RIP w .2,167 zgodność z protokołem RIP w.l, 168 round-trip, 242 route aggregation, 69 route summarization, 69 router, 29, 90 BGP, 207 desygnowany, 170 granica systemu autonomicznego, 175 OSPF, 183 Router ID, 192 routing, 29,79 algorytm stanu łącza, 169 algorytm wektora odległości, 145 bezklasowy, 149 BGP, 205 domyślny, 143 dynamiczny, 144 dzielony horyzont, 147 EGP, 144,145 EIGRP, 144,149,202 IGP, 144 IGRP, 144,145,199 interfejs podłączony bezpośrednio, 142 IP, 141 klasowy, 149,162

556

TCP/IP. SZKOŁA PROGRAMOWANIA

routing liczenie do nieskończoności, 147 metody, 141 MTU, 148 najlepsza ścieżka, 145 największa liczba skoków, 147 niezawodność, 148 obciążenie, 148 odtrutka, 147 opóźnienie, 148 OSPF, 144,149,169 pętle, 146 połączenia na żądanie, 46 powstrzymywanie, 147 protokoły, 145,153, 218 protokoły hybrydowe, 149 protokoły stanu łącza, 148 protokoły wektora odległości, 146 QoS, 150 RIP, 144,145,154 RIP w.l, 155 RIP w .2,167 split horizon, 147 stan łącza, 144,148 statyczny, 142 szerokość pasma, 148 ToS, 150 trasy lokalne, 142 wektor odległości, 144,145 wielościeżkowy, 201 wybór trasy, 141 routowanie, 58 rozgłaszanie, 33, 57, 58,108,184 ARP, 58, 59 rozruch wstępny, 101 równoważenie obciążenia, 169,171,201 RPC, 28,274,275, 378,385 dane uwierzytelniania, 390 nagłówek, 386 odpowiedź, 391 procedury polecenia mount serwera, 390 procedury seiwera NFS, 389 stan, 391 stan akceptacji, 391 uwierzytelnianie, 390 weryfikacja uwierzytelniania, 390 wiadomość wywołująca, 386 zarejestrowane programy, 387

RR, 323 RRQ, 358, 360 RST, 237 RTO, 254 RtrPri, 195

s SAP, 37 sąsiad, 199 SDLC, 47 segment, 233 segmentacja dane, 226 komunikaty, 28 sekwencja kontroli ramki, 25, 30 sekwencjonowanie, 221,223,234, 250 Sender's PA, 115 Sequence Number, 196, 234 sequencing, 223 service provider, 71 serwer autorytatywny, 324, 325 DNS, 324 nazw domen, 320 NFS, 383 nieautorytatywny, 324 sesja FTP, 291 HTTP, 346 SMTP, 309 Telnet, 277 terminal, 277 session setup, 223 session teardown, 224 SGMP, 368,374 siaddr, 138 sieciowy system plików, 275, 378 NFS, 378 sieć Ethernet, 31 FDDI, 42 HTTP, 271 IGRP, 200 LAN, 32,40 NBMA, 185 podział na podsieci, 61,62

SKOROWIDZ

prywatna, 57 przełączana pakietowo, 231 rozgłaszanie, 184 rozległa, 43 SNA, 47 szkieletowa, 43 telekomunikacyjna, 272 Token-Ring, 40 WAN, 43 wdzwaniana, 142 WWW, 271 X.25,48 Signal Quality Error, 32 składanie datagramów, 86 skrętka, 32 skupianie, 69 sliding window, 242 SLIP, 48 SMB, 270 Smooth Round-Trip Timer, 253 SMTP, 258,272, 307 agent transferu wiadomości, 311 agent użytkownika, 308, 310 AU, 310 DATA, 313 dostarczanie wiadomości, 308 EXPN, 313 format, 311 HELO, 313 HELP, 313 identyfikacja odbiorcy, 308 jednostka dostępu, 310 kody odpowiedzi, 315 kody poleceń, 313 koperta, 311 magazyn wiadomości, 310 MAIL, 313 Mail from, 308 MIME, 316 model nazewniczy X.400,310 MS, 310 MTA, 310,311 MTS, 311 nadawca, 308 nagłówek wiadomości, 312 NDN, 311 NOOP, 313

odpowiedzi, 314 pola nagłówka, 312 polecenia, 313,314 QUIT, 313 RCPT, 308,313 RSET, 313 SAML, 313 SEND, 313 sesja, 309 składniki, 308 SOML, 313 system transferu wiadomości, 311 TURN, 313 UA, 310 VRFY, 313 wiadomości, 311 SNA, 19,47 sname, 138 SNAP, 36 SNMP, 264, 367, 369 agent, 369, 370 baza informacji zarządzania, 368 domena publiczna, 371 elementy, 369 get, 370 implementacja, 368 jednostka danych protokołu, 371, 373 menadżer, 369 MIB, 368 nazwa społeczności, 372 notacja ASN.l, 368 PDU, 373 proxy, 371 public domain, 371 pułapka PDU, 373 set, 370 społeczność, 371 wersje, 372 wiadomości, 371, 372 wiadomości-pułapki, 369 widold MIB, 370 SNMPvl, 371 SOA, 331 socket pair, 29, 240 sockets, 28, 226 Source Host Isolated, 98 Source Port, 233,265

557

558

TCP/IP. SZKOŁA PROGRAMOWANIA

Source Route Failed, 98 split horizon, 147,161 społeczność, 371 spooling, 272 SQE, 32 SQL, 274 SRTT, 253 SRV, 270 SSAP, 37 standardowy obszar szczątkowy, 188 standardy, 47 statyczny NAT, 74 sterowanie przepływ, 223, 241, 255 transmisja, 221 stopka, 25 strefy DNS, 323 strona WWW, 271 struktury danych FTP, 297 struktury pliku FTP, 297 stub area, 188 subnet, 61 subnetting, 62 SubNetwork Access Protocol, 35 suma kontrolna, 30, 237 nagłówek, 80,89 sumaryzacja tras, 69, 70 implementacja, 72 supernetting, 69 surfowanie po sieci, 344 sygnalizacja niezrównoważona, 32,33 zrównoważona, 32, 33 sygnał taktowania, 32 SYN, 237,245 Synchronous Data Link Control, 47 system autonomiczny, 144,154 domen, 325 dwójkowy, 51 nazw domen, 272, 321, 322 transferu wiadomości, 311 Systems Network Architecture, 47 szum, 32 szybki Ethernet, 39 szyfrowanie, 27

ś światłowody, 32, 42

T tabela routingu, 155 tablica przestrzeni nazw, 321 Target HA, 115 Target PA, 116 TC, 328 TCB, 238 TCP, 28,221,231 ACK, 234,237,242,246 Acknowledgement Number, 234 blok sterowania transmisją, 238 bufor odbiorczy, 256 cechy charakterystyczne, 244 czasomierze, 253 Data Offset, 236 Destination Port, 233 długość, 238 dostarczanie danych, 222 FIN, 237,249 flagi, 236 fluktuacja szerokości pasma, 254 gniazda, 240 ISN, 247 komunikaty utrzymywania przy życiu, 224,255 kontrola przeciążenia, 256 łączenie gniazd w pary, 245 maksymalny rozmiar segmentu, 238 MSS, 238 nagłówek, 232,256 niezawodność, 242 numer kolejny, 234 numer potwierdzenia, 234 obsługa ramek uszkodzonych, 242 obwód logiczny, 239 okienkowanie, 234,257 okno, 237,256 okno przesuwne, 242 opcje, 238 pakiet tłumienia, 255, 256 para gniazd, 240 początkowy numer kolejny, 247, 251

SKOROWIDZ

połączenia, 239, 240 porozumienie trzyetapowe, 247 port docelowy, 233 port źródłowy, 233 porty, 240,258 potok komunikacyjny, 238 potwierdzenia, 223, 250 potwierdzenia ACK, 248 potwierdzenie wywnioskowane, 234 priorytety, 242 przesunięcie danych, 236 przesyłanie danych, 241 pseudonaglówek, 238 PSH, 237 retransmisja danych, 242, 253 RST, 237 RTO, 254 sekwencjonowanie, 223,234, 250,252 Sequence Number, 234 Source Port, 233 SRTT, 253 sterowanie przepływem, 223, 241,255 suma kontrolna, 237 SYN, 237,245 TCB, 238 three-way handshake, 247 timeout, 254 ToS, 243 transmisja danych, 241 tryb full-duplex, 245 typ usługi, 243 upływ czasu oczekiwania, 254 URG, 236,237 Urgent Pointer, 237 ustanawianie połączenia, 239 ustanawianie sesji, 223,224,244,246 Window, 237 wskaźnik pilności, 237 wykrywanie ramek zgubionych, 242 zabezpieczenia, 242 zasada działania, 238 zatory, 255 zrywanie połączenia, 239 zrywanie sesji, 224,249 zwielokrotnianie, 238, 240 żądania FIN, 249 żądania SYN, 247, 248

TCP Length, 238 TCP/IP, 47 technologia Internetu, 49 Telnet, 107, 245, 258, 272,277 IAC, 284 kody kontrolne NVT, 281 negocjacja opcji, 283 negocjacja subopcji, 287 NVT, 280 NVT ASCn, 280 opcje protokołu, 284,285 polecenia, 281 return, 280 tryby transmisji, 278 usługi podstawowe, 279 ustanawianie sesji, 277 wirtualny terminal sieciowy, 280 znak nowej linii, 280 TFTP, 121,264,273,357 ACK, 360, 361 błędy, 361 działanie, 362 kody błędów, 362 OACK, 365 pakiety, 358, 359 pakiety błędu, 361 pakiety danych, 360 połączenia, 362 potwierdzanie lock-step, 360 potwierdzenia, 360 rozszerzenia, 364 RRQ, 358, 360 transfer danych, 358, 362 WRQ, 358, 360 żądanie odczytu, 358 żądanie zapisu, 358 thick coaxial, 32 thin coaxial, 32 three-way handshake, 247 TIFF, 273 Time To Live, 80 timeout, 254 tłumaczenie adresy sieciowe, 57, 73 dane, 273

559

560

TCP/IP. SZKOŁA PROGRAMOWANIA

tłumienie nadawcy, 100 Token-Ring, 31, 40 działanie sieci, 41 karta sieciowa, 40 metoda dostępu do kanału, 41 ramki, 41 topologia, 40 topologia łącza danych, 31 magistrala liniowa, 32 pierścień, 40 pierścień podwójny, 42 ToS, 80,149,150,170,243 bity, 80 Total Length, 80 Trace, 348 traceroute, 102 Transaction ID, 124 translacja adresy IP, 57 dane, 27 transmisja danych, 244 Transmission Control Protocol, 221 trasowanie, 79,101,141 trasy, 141 lokalne, 142 statyczne, 142,143 triggered updates, 165 tryb full-duplex, 27 half-duplex, 27 transmisja danych, 278 TTL, 80,88, 89,102 tunel, 345 twisted pair, 32 tworzenie systemu domen, 325 TXT, 331 typ usługi, 80,170,243 typy komunikaty DHCP, 129 komunikaty ICMP, 94 nazwy domen, 330 połączenia WAN, 44

U UA, 308,310,345, 351 uaktualnienia wyzwalane, 165 UDP, 28,154, 221, 225, 261 aplikacje, 263 Checksum, 266 Destination Port, 265 długość, 265 działanie, 262 nagłówek, 264 port docelowy, 265 port źródłowy, 265 porty, 263 pseudonagłówek, 266 Source Port, 265 strumień danych, 262 suma kontrolna, 266 ULPs, 269 unbalanced signaling, 32 UNC, 336 Unicast Poll, 111 Uniform Resource Lokator, 346 Uniform Resource Name, 346 URG, 236,237 Urgent Pointer, 237 URI, 356 URL, 271,343,346 URN, 346,356 User Agents, 308 User Datagram Protocol, 221 usługi nazwy domenowe, 127 warstwa aplikacji, 26, 271 usługodawca internetowy, 61 ustanawianie połączenie TCP, 239 sesja TCP, 223,224,244 sesja Telnet, 277 UUencoded, 316

V Variable Length Subnet Mask, 63 Vendor-Specific Area, 126 VLA-FTP, 258

SKOROWIDZ

VLSM, 63,169 VT100,280 VT200,280

W WAN, 43,142 HDLC, 47 hermetyzacja, 46, 48 interfejs sieci usługodawcy, 47 linia dzierżawiona, 45 model OSI, 43 połączenia, 44 połączenia komutowane, 46 protokoły hermetyzacji, 46,48 przełączanie obwodów, 44, 45 przełączanie pakietów, 44, 46 SDLC, 47 WAN encapsulation, 46 warstwy DoD, 22 warstwy OSI, 21, 22, 24 aplikacji, 25,26,270 fizyczna, 31 łącza danych, 25, 30 prezentacji, 25, 27, 273 sesji, 27,274 sieciowa, 29 transmisja danych, 25 transportowa, 28, 221 wczesne wypuszczanie żetonu, 43 well-known ports, 227 węzły NetBIOS, 337 wiadomości DNS, 327 e-mail, 311 HTTP, 348 SNMP, 371 Wide Area Network, 43 widold MIB, 370 więcej fragmentów, 86, 87, 88 Window, 237 windowing, 234 WINS, 338 agent proxy, 339 NetBIOS, 338

561

wirtualny terminal sieciowy, 272, 280 World Wide Web, 27,271,343 WRQ, 358,360 wskaźnik pilności, 237 wtórnik, 31, 40 WWW, 27,258,271 wykrywanie błędy, 48 kolizje, 32 wymiana komunikatów DHCP, 129 wysyłanie ramek, 30 wzmocnienie, 41

X X Window, 274 X.25, 46, 48,164 X.400, 310 XDR, 28,274,275, 378,384 tryb odbiorczy, 384 zadania, 384 xid, 137

Y yiaddr, 138

Z zakres adresowy podsieci, 65 zakres DHCP, 127 zamiana adresów, 105 adres IP na adres MAC, 58 adres sprzętowy na adres logiczny, 116 zapasowy router desygnowany, 170 zapora sieciowa, 57 zapytania DNS, 326 RARP, 117 zarządzanie siecią, 367 zatory, 255 zawijanie pierścienia, 42 zbiorcze przedstawianie, 69 zdalne wywołanie procedur, 28, 385 zdalny dostęp, 272, 277 zdolność do negocjowania, 344

562

TCP/IP. SZKOŁA PROGRAMOWANIA

znak karetki, 280 zrównoważony protokół hybrydowy, 202 zrywanie połączenie TCP, 239 sesja, 224 sesja TCP, 249 zwielokrotnianie, 238,240 zwolnienie DHCP, 135

ż żądanie DHCP, 129