Protokoły w sieciach teleinformatycznych, Sieci komputerowe administracja

Socha Łukasz

Majcherkiewicz Marcin

Moryl Grzegorz

Elektronika i telekomunikacja, II rok, gr. IV

Protokoły w sieciach teleinformatycznych

wersja HTML http://student.uci.agh.edu.pl/~fenix

1. Wstęp

W procesach komunikacyjnych niezbędne są procedury zwane protokołami, które umożliwiają prawidłowy przebieg tych procesów - bez błędów lub przerw. W sieciach teleinformatycznych wszystkie operacje są kontrolowane właśnie przez protokoły, które „rezydują” wewnątrz nadajników i odbiorników podłączonych do sieci.

Protokół jest regułą, niezbędnikiem w procesie wzajemnej komunikacji, na którą muszą się zgodzić użytkownicy. Zawiłość i stopień skomplikowania protokołu jest zależny min. od błędów wprowadzanych do sieci przez interferencje i zniekształcenia. Wszystkie informacje transmitowane w systemach telekomunikacyjnych są narażone na błędy i jakieś mechanizmy muszą temu przeciwdziałać.

Można posłużyć się przykładem rozmawiających ludzi. W czasie rozmowy przyjmują nawzajem pewną konwencję, która daje każdemu uczestnikowi możliwość mówienia oraz słuchania - w momencie gdy wypowiada się inna osoba. Sieć teleinformatyczna musi umożliwiać właśnie taką konwersację między użytkownikami. W telekomunikacji taka konwencja nazywa się właśnie protokołem.

Podstawowym zadaniem protokołu jest identyfikacja procesu, z którym chce się komunikować proces bazowy. Aby było to możliwe konieczne jest podanie sposobu określania właściwego adresata, sposobu rozpoczynania i kończenia transmisji, a także sposobu przesyłania danych.

Ludzki mózg jest szczególnie doskonały w rozumieniu zniekształconej mowy, np. rozważając typową linię telefoniczną, ale bardziej istotne jest jak szybko potrafi zaadoptować się do nieprzewidywalnych sytuacji, np. załamania psychicznego rozmówcy. Procesory, które magazynują protokoły w sieci są znacznie mniej elastyczne, dlatego prawidłowa odpowiedź na każde możliwe zdarzenie, znane lub jeszcze nieznane, musi być predefiniowana w dobrze opracowanym protokole.

Niestety, w czasie gdy protokoły mogą być używane do zmniejszenia problemów z uszkodzonymi pakietami danych w sieci, to jeszcze powodują znaczący problem niedopasowania. Nie ma jednego protokołu, są ich dziesiątki. Nie jest możliwe wzajemne ich współpracowanie, dopóki nie będzie dostarczony jakiś interfejs ich wzajemnego przekazywania. Ten interfejs jest rdzeniem sieci. Różne typy interfejsów mogą być używane do łączenia różnych protokołów, niezależnie od ich aktualnych różnic funkcjonalnych oraz sposobów implementacji.

2. Standaryzacja protokołów

Relacje pomiędzy formalnymi organizacjami tworzącymi standardy w systemach telekomunikacyjnych i informatycznych rozwijały się dość powoli, i polegały głównie na wymianie ich własnych standardów. Schematyczna reprezentacja współczesnych powiązań pomiędzy organizacjami pokazana jest na rys. 1.

0x08 graphic

International Organization for Standardization (ISO) jest organizacją odpowiedzialną za koordynowanie produkcji standardów użytkowych z wielu dziedzin życia. Ta organizacja jest także aktywna na polu usług informatycznych (Technical Committee - TC97) i jest odpowiedzialna min. za standard OSI/RM i wiele innych.

TC97 jest wspierana przez regionalne organizacje i reprezentowana przez narodowe organizacje standaryzacyjne. W Wielkiej Brytanii to jest British Standards Institution (BSI). Inne organizacje wspierające to np. European Computer Manufacturers Association (ECMA).

United Nations (UN) jest ciałem któremu podlega International Telecomunications Union (ITU). ITU składa się z różnych podorganizacji, trzy z nich to International Radio Consultative Committee (CCIR), CCITT oraz World Administrative Radio Conference (WARC). CCIR jest odpowiedzialna za rezerwacje wspólnych standardów wyposażenia telekomunikacyjnego pomiędzy dostawcami, podczas gdy CCITT zajmuje się zaleceniami w sprawach sieci teleinformatycznych, sieci telefonicznych, standardów cyfrowych i terminali. WARC zajmuje się rezerwacją pasma radiowego dla poszczególnych operatorów na świecie, zapewniając ich wzajemną kompatybilność i bezkolizyjność.

CCITT jest przedstawicielem ISO (oraz vice versa), dla państwowych operatorów jak PTTs oraz prywatnych firm, jak AT&T. Wynikiem tych międzynarodowych powiązań są setki mniejszych organizacji zajmujących się specjalnymi dziedzinami telekomunikacji, jak np. IEEE. W Europie organizacja zwana Central European Commision (CEC) staje się bardziej powszechna jeśli chodzi o standardy unifikacyjne w Europie, skutkiem tego są zalecenia CEN/CENELEC. Większość szczegółowych badań standaryzacyjnych w Europie jest kontrolowanych przez European Telecomunications Standards Institute (ETSI), która to dostarcza informacje do do CEC i utrzymuje kontakty z innymi organizacjami standaryzacyjnymi w spokrewnionych dziedzinach.

Na jednym z ostatnich forum ITU, zaanonsowano zmiany odnośnie nazw i odpowiedzialności dla CCITT i CCIR. Zakres działalności tych organizacji pozostał z grubsza bez zmian, ale zmieniono ich nazwy. CCITT nazywa się obecnie ITU-T a CCIR ITU-R. Określono także schemat działania tych organizacji na kolejne kilka lat.

Wiele szczegółowych analiz i standardów było i jest opracowywanych w małych grupach badawczych składających się z indywidualnych prac pod kierunkiem profesjonalnych organizacji. Trzy z wielu ważnych organizacji zajmujących się przekazywaniem danych w sieciach teleinformatycznych to Institute of Electrical and Electronics Engineers (IEEE)- odpowiedzialny za standardy w sieciach LAN, US National Institute of Standards and Technology (NIST) oraz Electronic Industries Association (EIA) - np. zajmujący się standardem RS-232. Prace tych instytucji są zazwyczaj prezentowane formalnym organizacjom standaryzacyjnym, które tworzą szkic standardu międzynarodowego, który z kolei otwiera proces jego formalnej ratyfikacji.

3. Typy protokołów

Obecnie używanych jest wiele typów protokołów i generalnie mogą być one sklasyfikowane na podstawie ich funkcji. Najbardziej ogólna klasyfikacja mogłaby wyglądać np. tak:

protokoły typu „master/slave” oraz „peer-to-peer”- typ master/slave wymaga, żeby jedna strona węzła telekomunikacyjnego działała jako kontroler. To wymaga odpowiedniego kontrolowania połączenia telekomunikacyjnego i transferu danych pomiędzy węzłami. Typ peer-to-peer nie wymaga żadnego kontrolera, więc węzły komunikacyjne mogą transmitować informacje kiedy sobie tego życzą.
protokoły typu bezpołączeniowego („connectionless”), zorientowane połączeniowo oraz „send-and-pray” i „remote procedural call”- RPC - te protokoły odzwierciedlają sposoby na które informacja może być przekazywana między użytkownikami, uwzględniając różnice wynikające z różnych stopni niezawodności przekazu informacji.
synchroniczne i asynchroniczne protokoły - w asynchronicznych protokołach dane są przekazywane bit po bicie, ze zmiennym opóźnieniem pomiędzy przekazem każdego bitu. W synchronicznych protokołach mamy do czynienia z ciągłym wysyłaniem strumienia bitów z częstotliwością zależną od fizycznego typu sieci. W obu systemach nadajniki i odbiorniki są asynchroniczne względem siebie, ponieważ nie ma wspólnego zegara taktującego.
warstwowe i monolityczne protokoły - nowoczesne architektury protokołów używają warstwowania do konstrukcji pełnych systemów. Warstwowanie jest procesem, w którym poszczególne protokoły są tj. poukładane w stosy i tak są transportowane do wspólnego celu, oraz różne stosy są używane przez różne serwisy telekomunikacyjne. Monolityczne podejście jest efektywne w pojedynczej warstwie.
ciężkie i lekkie protokoły - protokoły które dostarczają bardzo szeroki zakres funkcji są zazwyczaj nazywane „ciężkimi”, stosownie do dużych nakładów czasowych potrzebnych do ich przetworzenia przez system. Przeciwnie „lekkie” protokoły- nie wymagają dużo czasu potrzebnego do ich przetworzenia, ale również są mniej funkcjonalne od poprzednich.

To było bardzo ogólne scharakteryzowanie typów protokołów, jednak bez dokładnego odwołania się do poszczególnych nazw protokołów lub ich standardów nie można znaleźć jakiejś wspólnej terminologii pozwalającej jednoznacznie opisać protkół.

3.1. Transfer danych z użyciem protokołów

Dane zawsze będą podatne na uszkodzenia czy zniekształcenia w trakcie ich fizycznego przesyłania. Liczba błędów na sekundę będzie zależna od jakości kanału przesyłowego i otaczającego środowiska. Sieci o dużej niezawodności, takie w których prawdopodobieństwo wystąpienia błędu jest na poziomie 10^-9 i niższej, zazwyczaj używają systemów wykrywania błędów kierowanych specjalnymi algorytmami określanymi jako „wsteczna korekcja błędów” - BEC (ang. Backward Error Correction). W przypadku, gdy poziom błędów jest wysoki, wyższy niż 10^-5, wówczas jakaś forma „bieżącej korekcji błędów” - FEC (ang. Forward Error Correction) jest używana do korekcji danych bez uciekania się do retransmisji danych.

Protokół jest odpowiedzialny za retransmisje danych. Retransmisja może być spowodowana otrzymaniem negatywnego potwierdzenia odbioru (NAK) z odbiornika, albo upłynięciem limitu czasu oczekiwania na potwierdzenie. Protokoły używane do retransmisji danych zależą od jakości kanału przesyłowego, ale można je próbować sklasyfikować jako:

protokoły „stop-and-wait” - w tym typie protokołu każdy kolejny pakiet może być wysłany dopiero w przypadku otrzymania potwierdzenia prawidłowego odbioru poprzedniego pakietu. Jeżeli potwierdzenie odbioru jest negatywne (NAK)- tak jest w przypadku uszkodzenia wysyłanych danych- lub jeśli upłynął limit czasu, inicjator połączenia retransmituje poprzedni pakiet i nie jest upoważniony do wysłania kolejnego, dopóki odbiorca nie dostarczy potwierdzenia prawidłowego odbioru. Schemat działania tego typu protokołów przedstawia rys. 2. Na rysunku pakiety 1 i 2 zostały przesłane pomyślnie- otrzymano pozytywne potwierdzenie odbioru. Pakiet 3 uległ uszkodzeniu, więc zwrotny sygnał NAK zmusza inicjatora połączenia do retransmisji tego pakietu. Druga próba zakończyła się sukcesem. Warto zauważyć, że tylko jeden błędnie przesłany pakiet wstrzymuje wysyłanie kolejnych, ten protokół nie należy więc do szybkich.

0x08 graphic

protokoły „go-and-back” - są pewną formą protokołów „przesuwnych okien” (sliding window protocol- SWP), inicjator połączenia transmituje wszystkie dane pasujące do przyjętego rozmiaru okna. Rozmiar okna jest maksymalną liczbą możliwych wysłanych pakietów, zanim dotrze potwierdzenie odbioru. Po wysłaniu całego okna, inicjator czeka na potwierdzenie, zanim następne „okno” zostanie wysłane. W przypadku otrzymania negatywnego potwierdzenia odbioru (NAK) jakiegoś pakietu, jest on retransmitowany i wszystkie kolejne aż do ostatniego w danym oknie. Schemat działania tego protokołu przedstawiony jest na rys. 3. Pakiety od 1 do 3 zostały pomyślnie dostarczone, inicjator wysyła więc dalsze pakiety - 4, 5, 6, 7. Jednak 5 pakiet został uszkodzony, więc zwrotny sygnał NAK nakazuje retransmisje pakietów 5, 6 i 7. Można zauważyć, że pakiety 6 i 7 mogły zostać poprawnie przesłane już w pierwszej próbie, jednak protokół ten nie uwzględnia tej możliwości.
protokoły selektywnego powtarzania- jest to modyfikacja protokołów „stop-and-wait”, w których retransmitowane są tylko te pakiety, które uległy uszkodzeniu.

0x08 graphic

4. Model warstwowy protokołów

Model warstwowy (rys. 4), w którym każda warstwa posługuje się własnym protokołem znacznie upraszcza projektowanie niezwykle skomplikowanego procesu komunikacji sieciowej. Muszą jednak jasno zostać zdefiniowane zasady współpracy tych protokołów. Warstwowy model OSI stanowi przykład takiego opisu, będąc w istocie "protokołem komunikacji między protokołami".

Model OSI stworzony został przez organizację International Organization for Standardization (ISO). Jest on zbiorem zasad komunikowania się urządzeń sieciowych. Podzielony jest na siedem warstw, z których każda zbudowana jest na bazie warstwy poprzedniej. Model ten nie określa fizycznej budowy poszczególnych warstw, a koncentruje się na sposobach ich współpracy. Takie podejście do problemu sprawia, że każda warstwa może być implementowana przez producenta na swój sposób, a urządzenia sieciowe od różnych dostawców będą poprawnie współpracować. Poszczególne warstwy sieci stanowią niezależne całości i chociaż nie potrafią wykonywać żadnych widocznych zadań w odosobnieniu od pozostałych warstw, to z programistycznego punktu widzenia są one odrębnymi poziomami.

Komunikacja pomiędzy komputerami odbywa się na poziomie odpowiadających sobie warstw i dla każdej z nich powinien zostać stworzony własny protokół komunikacyjny. W rzeczywistej sieci komputerowej komunikacja odbywa wyłącznie się na poziomie warstwy fizycznej. W tym celu informacja każdorazowo przekazywana jest do sąsiedniej niższej warstwy aż do dotarcia do warstwy fizycznej.
Tak więc pomiędzy wszystkimi warstwami z wyjątkiem fizycznej istnieje komunikacja wirtualna, możliwa dzięki istnieniu połączenia fizycznego.

0x08 graphic

4.1 Zadania warstw

Warstwa fizyczna - odpowiada za transmisje sygnałów w sieci. Realizuje ona konwersje bitów informacji na sygnały, które będą przesyłane w kanale z uwzględnieniem maksymalizacji niezawodności przesyłu. W warstwie fizycznej określa się parametry amplitudowe i czasowe przesyłanego sygnału, fizyczny kształt i rozmiar łączy, znaczenie ich poszczególnych zestyków i wartości napięć na nich występujących, sposoby nawiązywania połączenia i jego rozłączania po zakończeniu transmisji.

Warstwa łącza danych - odpowiedzialna jest za odbiór i konwersję strumienia bitów pochodzących z urządzeń transmisyjnych w taki sposób, aby nie zawierały one błędów. Warstwa ta postrzega dane jako grupy bitów zwane ramkami. Warstwa łącza danych tworzy i rozpoznaje granice ramki. Ramka tworzona jest przez dołączenie do jej początku i końca grupy specjalnych bitów. Kolejnym zadaniem warstwy jest eliminacja zakłóceń, powstałych w trakcie transmisji informacji po kanale łączności. Ramki, które zostały przekazane niepoprawnie, są przesyłane ponownie. Ponadto warstwa łącza danych zapewnia synchronizację szybkości przesyłania danych oraz umożliwia ich przesyłanie w obu kierunkach.
Warstwa sieciowa - steruje działaniem podsieci transportowej. Jej podstawowe zadania to przesyłanie danych pomiędzy węzłami sieci wraz z wyznaczaniem trasy przesyłu, określanie charakterystyk sprzęgu węzeł-komputer obliczeniowy, łączenie bloków informacji w ramki na czas ich przesyłania a następnie stosowny ich podział. W najprostszym przypadku określanie drogi transmisji pakietu informacji odbywa się w oparciu o stałe tablice opisane w sieci. Istnieje również możliwość dynamicznego określania trasy na bazie bieżących obciążeń linii łączności. Stosując drugie rozwiązanie mamy możliwość uniknięcia przeciążeń sieci na trasach, na których pokrywają się drogi wielu pakietów.
Warstwa transportowa - podstawową funkcją tej warstwy jest obsługa danych przyjmowanych z warstwy sesji. Obejmuje ona opcjonalne dzielenie danych na mniejsze jednostki, przekazywanie zblokowanych danych warstwie sieciowej, otwieranie połączenia stosownego typu i prędkości, realizacja przesyłania danych, zamykanie połączenia. Ponadto mechanizmy wbudowane w warstwę transportową pozwalają rozdzielać logicznie szybkie kanały łączności pomiędzy kilka połączeń sieciowych. Możliwe jest także udostępnianie jednego połączenia kilku warstwom sieciowym, co może obniżyć koszty eksploatacji sieci. Celem postawionym przy projektowaniu warstwy transportowej jest zapewnienie pełnej jej niezależności od zmian konstrukcyjnych sprzętu.
Warstwa sesji - określenie parametrów sprzężenia użytkowników realizowane jest za pośrednictwem warstwy sesji. Po nawiązaniu stosownego połączenia warstwa sesji pełni szereg funkcji zarządzających, związanych m. in. Z taryfikacją usług w sieci. W celu otwarcia połączenia pomiędzy komputerami (sesji łączności) poza podaniem stosownych adresów warstwa sprawdza, czy obie warstwy (nadawcy i odbiorcy) mogą otworzyć połączenie. Następnie obie komunikujące się strony muszą wybrać opcje obowiązujące w czasie trwania sesji. Dotyczy to na przykład rodzaju połączenia (simpleks, dupleks) i reakcji warstwy na zerwanie połączenia (rezygnacja, ponowne odtworzenie). Przy projektowaniu warstwy zwraca się uwagę na zapewnienie bezpieczeństwa przesyłanych danych. Przykładowo, jeżeli zostanie przerwane połączenie, którego zadaniem była aktualizacja bazy danych, to w rezultacie tego zawartość bazy może okazać się niespójna. Warstwa sesji musi przeciwdziałać takim sytuacjom.
Warstwa prezentacji - jej zadaniem jest obsługa formatów danych. Odpowiada ona więc za kodowanie i dekodowanie zestawów znaków oraz wybór algorytmów, które do tego będą użyte. Przykładową funkcją realizowaną przez warstwę jest kompresja przesyłanych danych, pozwalająca na zwiększenie szybkości transmisji informacji. Ponadto warstwa udostępnia mechanizmy kodowania danych w celu ich utajniania oraz konwersję kodów w celu zapewnienia ich mobilności.
Warstwa aplikacji - zapewnia programom użytkowym usługi komunikacyjne. Określa ona formaty wymienianych danych i opisuje reakcje systemu na podstawowe operacje komunikacyjne. Warstwa stara się stworzyć wrażenie przezroczystości sieci. Jest to szczególnie ważne w przypadku obsługi rozproszonych baz danych, w których użytkownik nie powinien wiedzieć, gdzie zlokalizowane są wykorzystywane przez niego dane lub gdzie realizowany jest jego proces obliczeniowy.

5. Przegląd ważniejszych protokołów

Istnieje wiele źródeł, dzięki którym formowane były i są w dalszym ciągu nowe standardy protokołów. Protokoły tworzono z myślą o różnych zastosowaniach, różni mieli być też użytkownicy. Można pokusić się o bardzo ogólne podzielenie tych typowych protokołów.

5.1. Protokoły prywatne

Wielu z głównych producentów systemów komputerowych stworzyło swoje własne protokoły. Wydaje się, że musi minąć wiele lat, zanim te protokoły zostaną zastąpione jakimiś ogólnymi standardami. Kilka typowych protokołów należących do tej klasy:

SNA - jest to architektura systemów komunikacyjnych firmy IBM. Jest to jedna z oryginalnych architektur protokołów, która niezbyt chętnie chce się podporządkować strukturze OSI/RM

DECnet IV- architektura Digital's Phase IV, jest ostatnią która różni się od standardów OSI (Phase V jest już w pełni dostosowana)
ICL - do niedawna architektura ICL nie była dostosowana do modelu OSI, ale niedawno została zmodernizowana i obecnie jest w pełni zgodna. Architektura ta częściowo bazuje na produktach C03 i OSLAN
AppleTalk - architektura komunikacji używana we wszystkich produktach firmy Apple
Novell NetWare - jest to bardzo ważny sieciowy system operacyjny, do niedawna dominujący na rynku. Kilka ostatnich udoskonaleń rozszerzyło jego możliwości na zgodność z systemami SNA i AppleTalk
Xerox Network System (XNS) - jest to architektura komunikacyjna firmy Xerox. System Novell NetWare wywodzi się właśnie z tej architektury.

5.2. Protokoły publiczne

Organizacje standaryzacyjne wciąż kontynuują prace nad modelem OSI/RM (a warto wiedzieć że prace te zaczęto już kilkanaście lat temu). Wymogi OSI/RM nie podają specyficznych wymagań, ale definiują urządzenia sieciowe, których funkcje muszą być zgodne co do protokołów i formatu wymienianych danych pomiędzy siedmioma warstwami modelu OSI/RM. Powstaje pytanie, co stanie się na rynku telekomunikacyjnym i wśród użytkowników sieci do czasu pełnego opracowania modelu OSI. W tym momencie protokoły publiczne mogą być dość ważne. TCP/IP i wszystkie protokoły wchodzące w jego skład jak np. File Transfer Protocol (FTP) są już zaadoptowane przez wielu użytkowników i producentów, co w przyszłości może być krokiem ku pełnej zgodności modelu OSI/RM.

6. Protokół TCP/IP

6.1. TCP/IP a model OSI

Protokół TCP/IP ma również strukturę warstwową (rys. 5) i ma do niego zastosowanie większość filozofii modelu OSI. Warstwy TCP/IP różnią się jednak od warstw OSI.

Protokoły TCP i IP ustalają zasady komunikacji - opisują szczegóły formatu komunikatów, sposób odpowiadania na otrzymany komunikat, określają jak komputer ma obsługiwać pojawiające się błędy lub inne nienormalne sytuacje.
Umożliwiają one rozpatrywanie zagadnień dotyczących komunikacji niezależnie od sprzętu sieciowego.

Zapewniają szereg popularnych usług dostępnych dla użytkowników:

poczta elektroniczna
przesyłanie plików
praca zdalna

6.2. Zadania warstw w TCP/IP

Warstwa programów użytkowych - na najwyższym poziomie użytkownicy wywołują programy użytkowe, które mają dostęp do usług TCP/IP. Programy użytkowe współpracują z jednym z protokołów na poziomie warstwy transportowej i wysyłają lub odbierają dane w postaci pojedynczych komunikatów lub strumienia bajtów.
Warstwa transportowa - jej podstawowym zadaniem jest zapewnienie komunikacji między jednym programem użytkownika a drugim. Warstwa ta może regulować przepływ informacji. Może też zapewnić pewność przesyłania. W tym celu organizuje wysyłanie przez odbiorcę potwierdzenia otrzymania oraz ponowne wysyłanie utraconych pakietów przez nadawcę.
Warstwa intersieci - odpowiada za obsługę komunikacji jednej maszyny z drugą. Przyjmuje ona pakiety z warstwy transportowej razem z informacjami identyfikującymi maszynę - odbiorcę, kapsułkuje pakiet w datagramie IP, wypełnia jego nagłówek, sprawdza czy wysłać datagram wprost do odbiorcy czy też do routera i przekazuje datagram do interfejsu sieciowego. Warstwa ta zajmuje się także datagramami przychodzącymi, sprawdzając ich poprawność i stwierdzając czy należy je przesłać dalej czy też przetwarzać na miejscu.
Warstwa interfejsu sieciowego - odbiera datagramy IP i przesyła je przez daną sieć.

0x08 graphic

6.3. Adresy IP

Adres IP jest 32-bitową liczbą całkowitą zawierającą informacje o tym do jakiej sieci włączony jest dany komputer, oraz jednoznaczny adres w tej sieci.
Zapisywany jest on w postaci czterech liczb dziesiętnych oddzielonych kropkami, przy czym każda liczba dziesiętna odpowiada 8 bitom adresu IP.
Np. 32-bitowy adres 10000000 00001010 00000010 00011110 jest zapisany jako 128.10.2.30
Adresy IP podzielone są na klasy.
Klasa adresu IP określona jest przez najstarsze bity, przy czym do zidentyfikowania jednej z trzech zasadniczych klas (A, B, C) wystarczą dwa pierwsze bity.
Taki mechanizm adresowania wykorzystują routery, które używają adresu sieci do wyznaczania trasy pakietów.

6.3.1. Klasy adresów IP

Obserwując najstarsze bity adresu można stwierdzić do jakiej klasy należy dany adres, w efekcie można stwierdzić ile bitów będzie adresowało sieć, ile zaś sam komputer.

Adresów klasy A jest niewiele (2⁷=128), ale w każdej z sieci tej klasy może być aż 65535 maszyn.

Klasa B to 2¹⁴ sieci i 2¹⁶ komputerów.

W klasie C sieć adresowana jest za pomocą 21 bitów - daje to 2²¹ sieci, ale w każdej z nich może być co najwyżej 2⁸=256 maszyn.

Adres klasy D ma specjalne znaczenie - jest używany w sytuacji gdy ma miejsce jednoczesna transmisja do większej liczby urządzeń.

Adresy zamiast w postaci bitowej, zwykle zapisuje się w postaci czterech liczb dziesiętnych. Wówczas podział na klasy wygląda następująco:

Klasa	Najniższy adres	Najwyższy adres
A	0.1.0.0	126.0.0.0
B	128.0.0.0	191.255.0.0
C	192.0.1.0	223.255.255.0
D	224.0.0.0	239.255.255.255
E	240.0.0.0	247.255.255.255

6.3.2. Przydzielanie adresów sieciowych

W celu zapewnienia jednoznaczności identyfikatorów sieci, wszystkie adresy przydzielane są przez jedną organizację. Zajmuje się tym Internet Network Information Center (INTERNIC). Przydziela ona adresy sieci, zaś adresy maszyn administrator może przydzielać bez potrzeby kontaktowania się z organizacją. Organizacja ta przydziela adresy tym instytucjom, które są lub będą przyłączone do ogólnoświatowej sieci INTERNET. Każda instytucja może sama wziąć odpowiedzialność za ustalenie adresu IP, jeśli nie jest połączona ze światem zewnętrznym. Nie jest to jednak dobre rozwiązanie, gdyż w przyszłości może uniemożliwić współpracę między sieciami i sprawiać trudności przy wymianie oprogramowania z innymi ośrodkami.

6.4. Protokół ARP i RARP

6.4.1. Protokół odwzorowania adresów (ARP)

W schemacie adresowania TCP/IP każdy komputer ma przypisany 32-bitowy adres jednoznacznie identyfikujący go w sieci. Jednak dwie maszyny mogą się komunikować tylko wtedy kiedy znają nawzajem swoje adresy fizyczne. Zachodzi więc potrzeba przekształcenia adresu IP na adres fizyczny tak aby informacja mogła być poprawnie przesyłana.

Problem ten przedstawimy na przykładzie sieci ethernet, w której mamy do czynienia z długim 48-bitowym adresem fizycznym przypisanym w trakcie procesu produkcyjnego urządzeń sieciowych. W efekcie podczas wymiany karty sieciowej w komputerze, zmienia się adres fizyczny maszyny. Ponadto nie ma sposobu na zakodowanie 48-bitowego adresu ethernetowego w 32-bitowym adresie IP.
Przekształcenia adresu IP na adres fizyczny dokonuje protokół odwzorowania adresów ARP (Address Resolution Protocol), który zapewnia dynamiczne odwzorowanie i nie wymaga przechowywania tablicy przekształcania adresowego.

Gdy komputer A chce odwzorować adres IP komputera B, wówczas rozgłasza specjalny pakiet, w którym prosi komputer o podanym adresie IP, aby dał odpowiedź zawierającą jego adres fizyczny. Wszystkie komputery w sieci otrzymują tę prośbę, ale tylko komputer B rozpoznając swój adres IP wysyła odpowiedź która zawiera jego adres fizyczny. Gdy komputer A otrzyma odpowiedź, przy użyciu otrzymanego adresu fizycznego przesyła pakiet bezpośrednio do przeznaczenia, czyli do komputera B.

6.4.2. Odwzorowanie adresów i pamięć podręczna

Przedstawiony sposób odwzorowywania adresów ma jednak wady, jest zbyt kosztowny aby go używać za każdym razem gdy jakaś maszyna chce przesłać pakiet do innej: przy rozgłaszaniu każda maszyna w sieci musi taki pakiet przetworzyć.

W celu zredukowania kosztów komunikacji komputery używające protokołu ARP przechowują w pamięci podręcznej ostatnio uzyskane powiązania adresu IP z adresem fizycznym, w związku z tym nie muszą ciągle korzystać z protokołu ARP.

Ponadto komputer A wysyłając prośbę o adres fizyczny komputera C od razu dowiązuje informację o swoim adresie fizycznym. Ponieważ prośba ta dociera do wszystkich komputerów w sieci, mogą one umieścić w swoich pamięciach podręcznych informację o adresie fizycznym komputera A.

Jeśli w komputerze zostanie zmieniony adres fizyczny (np. w wyniku zmiany karty sieciowej), to może on bez zapytania o jego adres fizyczny rozgłosić go do innych komputerów, tak aby uaktualniły informacje w swoich pamięciach podręcznych.

6.4.3. Protokół odwrotnego odwzorowania adresów (RARP)

Adres IP jest zwykle przechowywany w pamięci zewnętrznej komputera, skąd jest pobierany w trakcie ładowania systemu operacyjnego.

Więc jak maszyna nie wyposażona w dysk twardy określa swój adres IP?

Odpowiedź: w sposób przypominający uzyskiwanie adresu fizycznego.
protokół odwrotnego odwzorowania adresów RARP (Reverse Address Resolution Protocol) umożliwia uzyskiwanie adresu IP na podstawie znajomości własnego adresu fizycznego (pobranego z interfejsu sieciowego).

Komputery bez dysku twardego pobierają adres IP z maszyny uprawnionej do świadczenia usług RARP, po przesłaniu zapytania z własnym adresem fizycznym.

Komputer A rozgłasza zapytanie o swój adres IP do wszystkich komputerów wraz ze swoim adresem fizycznym, wskazując siebie jako odbiorcę. Zapytanie dociera do wszystkich komputerów w sieci, ale przetwarzają je i udzielają odpowiedzi tylko maszyny uprawnione do świadczenia usług RARP. Maszyny takie nazywa się serwerami RARP. Protokołu RARP można używać jedynie wtedy, gdy w sieci jest co najmniej jeden serwer RARP. Jeśli jest ich więcej nadawca otrzyma odpowiedź od wszystkich serwerów, mimo że wystarczy odpowiedź od jednego.

6.5. Internet protokol IP

Zasadniczo sieć TCP/IP udostępnia trzy zbiory usług (rys. 7).

Najbardziej podstawowa usługa - przenoszenie pakietów bez użycia połączenia nosi nazwę Internet Protocol, a zwykle oznacza się skrótem IP.

Usługa ta jest zdefiniowana jako zawodny (ang. unreliable) system przenoszenia pakietów bez użycia połączenia, tzn. nie ma gwarancji, że przenoszenie zakończy się sukcesem. Każdy pakiet obsługiwany jest niezależnie od innych.
Pakiety z jednego ciągu, wysyłanego z danego komputera do drugiego, mogą podróżować różnymi ścieżkami, niektóre z nich mogą zostać zgubione, inne natomiast dotrą bez problemów.

Pakiet może zostać zagubiony, zduplikowany, zatrzymany, lub dostarczony z błędem, a system nie sprawdzi, że coś takiego zaszło, a także nie powiadomi o tym ani nadawcy, ani odbiorcy.

0x08 graphic

Protokół IP zawiera trzy definicje:

Definicję podstawowej jednostki przesyłanych danych, używanej w sieciach TCP/IP. Określa ona dokładny format wszystkich danych przesyłanych przez sieć.
Definicję operacji trasowania, wykonywanej przez oprogramowanie IP, polegającej na wybieraniu trasy, którą będą przesyłane dane.
Zawiera zbiór reguł, które służą do realizacji zawodnego przenoszenia pakietów. Reguły te opisują, w jaki sposób węzły i routery powinny przetwarzać pakiety, jak i kiedy powinny być generowane komunikaty o błędach oraz kiedy pakiety mogą być porzucane.

6.5.1. Datagram IP

Podstawowa jednostka przesyłanych danych nazywana jest datagramem.
Datagram podzielony jest na nagłówek i dane.

Nagłówek datagramu zawiera adres nadawcy i odbiorcy oraz pole typu, które identyfikuje zawartość datagramu.

Datagram przypomina ramkę sieci fizycznej. Różnica polega na tym, że nagłówek ramki zawiera adresy fizyczne, zaś nagłówek datagramu adresy IP.

Ponieważ przetwarzaniem datagramów zajmują się programy, zawartość i format datagramów nie są uwarunkowane sprzętowo.

Pole wersja (4-bitowe) - zawiera informację o wersji protokołu IP, która była używana przy tworzeniu datagramu. Informacja ta jest wykorzystywana do sprawdzania, czy nadawca, odbiorca i wszystkie routery zgadzają się na format datagramu.
Oprogramowanie IP zawsze sprawdza pole wersji w celu upewnienia się, czy jego format zgadza się ze spodziewanym. Obecna wersja protokołu IP to 4.
Pole długość nagłówka (4-bitowe) - zawiera informację o długości nagłówka mierzoną w 32-bitowych słowach.

Pola opcje IP i uzupełnienie najczęściej nie są wypełnione. Ponieważ długość pozostałych pól nagłówka jest stała, więc nagłówek najczęściej ma długość równą 5 (słów 32-bitowych).
Pole długość całkowita (16-bitowe) zawiera, mierzoną w bajtach, długość całego datagramu IP. Rozmiar pola danych można uzyskać przez odjęcie długości nagłówka od długości całkowitej. Ponieważ pole długość całkowita ma 16 bitów długości, maksymalny możliwy rozmiar datagramu IP wynosi 2¹⁶-1 czyli 65535 bajtów.
Pole typ obsługi (8-bitowe) określa sposób w jaki powinien być obsłużony datagram. Składa się ono z pięciu podpól: Podpole pierwszeństwo (3-bitowe) zawiera informację o stopniu ważności datagramu, od 0 (normalny stopień ważności) do 7 (sterowanie siecią). Umożliwia to nadawcy wskazanie jak ważny jest dany datagram. Bity O, S, P określają rodzaj przesyłania, którego wymaga datagram. Ustawienie bitu O - oznacza prośbę o krótkie czasy oczekiwania, S - o przesyłanie szybkimi łączami, P - o dużą pewność przesyłanych danych. Ponieważ nie ma pewności, że trasa o wskazanych parametrach będzie dostępna, informacje te należy traktować tylko jako podpowiedź dla algorytmów trasowania; jednocześnie wskazanie wszystkich trzech sposobów obsługi na raz, zwykle nie ma sensu. W praktyce większość oprogramowania węzłów i routerów ignoruje pole typ obsługi.

Pole czas życia TTL (ang. Time To Live) określa jak długo, w sekundach, datagram może pozostawać w systemie sieci. Ten limit czasowy wynosi zwykle od 15 do 30 sekund. Wymogiem protokołu TCP/IP jest aby każdy router podczas przetwarzania nagłówka datagramu zmniejszał wartość pola CZAS ŻYCIA co najmniej o 1, nawet jeśli rzeczywiste przetwarzanie trwało krócej.
Jeśli jednak router jest przeciążony i czas przetwarzania jest dłuższy wówczas wartość pola czas życia zmniejsza się o czas faktycznego pozostawania datagramu wewnątrz routera. Gdy wartość pola maleje do zera router porzuca datagram i wysyła do nadawcy komunikat o błędzie. Mechanizm ten zapobiega podróżowaniu datagramów w sieci w nieskończoność, np. gdy tablice tras są nieaktualne, a routery wyznaczają datagramom trasy w kółko.

Inne pola nagłówka

Pole protokół zawiera numer identyfikacyjny protokołu transportowego, dla którego pakiet jest przeznaczony. Numery poszczególnych protokołów transportowych określone są przez Internet Network Information Center (INTERNIC). Najbardziej popularnymi są: ICMP oznaczony numerem 1 oraz TCP oznaczony numerem 6. Pełna lista protokołów obejmuje ok. 50 pozycji i jest dostępna w kilku dokumentach RFC.

Pole suma kontrolna nagłówka służy do sprawdzenia sensowności nagłówka. Obejmuje tylko nagłówek IP i nie dotyczy w żadnym stopniu danych. Zawiera bitową negację sumy obliczonej jako suma kolejnych 16-bitowych półsłów nagłówka.
Obliczenie sumy kontrolnej bezpośrednio po otrzymaniu pakietu oraz porównanie jej z wartością zapisaną w niniejszym polu pozwala wykryć większość przekłamań, lecz nie wszystkie: np. nie jest wykrywane zagubienie zerowego półsłowa.
Sumy kontrolne protokołów TCP i UDP obejmują cały pakiet więc przemycenie tego typu błędu jest praktycznie niemożliwe.

Pola adresów

Pola adres IP nadawcy i adres IP odbiorcy zawierają 32-bitowe adresy IP pierwotnego nadawcy i końcowego odbiorcy. (Z wyjątkiem sytuacji gdy datagram zawiera opcje wyznaczania trasy przez nadawcę)

Pole opcje IP ma zmienną długość. Pole uzupełnienie zależy od wybranych opcji. Zawiera ono zerowe bity, które mogą być potrzebne do zapewnienia, że nagłówek ma długość, która jest wielokrotnością 32 bitów (ponieważ pole długość nagłówka zawiera wartość mierzoną w jednostkach 32-bitowych). Pole opcje IP nie występuje w każdym datagramie - pierwotnym zastosowaniem opcji było ułatwienie testowania i usuwania błędów. Długość pola opcje zmienia się w zależności od tego jakie opcje są wybrane. Niektóre z nich mają długość 1 bajta, inne mają długość zmienną. Każda opcja składa się kodu opcji długości 1 bajta po którym może się pojawić ciąg bajtów tej opcji. Pole opcje składa się z trzech części (rys.). 1 bitowy znacznik kopiuj określa, że opcje maja być przekopiowane do wszystkich fragmentów (wartość 1), bądź tylko do pierwszego (wartość 0). Bity klasa opcji określają ogólną klasę opcji:

Klasa opcji	Znaczenie
0	Kontrola datagramów lub sieci
1	Zarezerwowane do przyszłego użytku
2	Poprawianie błędów i pomiary
3	Zarezerwowane do przyszłego użytku

*Klasa opcji*	*Numer opcji*	*Długość*	*Opis*
0	0	-	Koniec listy opcji. Używana gdy opcje nie kończą się wraz z końcem nagłówka.
0	1	-	Bez przypisanej funkcji - wypełnienie
0	2	11	Tajność - używana do zastosowań wojskowych
0	3	zmienna	Swobodne trasowanie wg nadawcy - używana do prowadzenia datagramu określoną ścieżką.
0	7	zmienna	Zapisuj trasę - używana do śledzenia trasy.
0	9	zmienna	Rygorystyczne trasowanie wg nadawcy - używana do ścisłego prowadzenia datagramu.
2	4	zmienna	Intersieciowy datownik - używana do zapisywania czasów wzdłuż ścieżki.

6.6. Routery

Routery łączą sieci fizyczne w intersieć. Każdy router ma fizyczne połączenie z jedną lub więcej sieciami, natomiast zwykły komputer ma zwykle połączenie tylko z jedną siecią fizyczną.
W systemie z wymianą pakietów trasowanie (ang. routing) oznacza proces wyboru ścieżki, po której będą przesyłane pakiety, a router to komputer, który dokonuje tego wyboru.
Wybór optymalnej trasy pakietu jest złożonym problemem, rozwiązywanym na wiele sposobów.
Idealne oprogramowanie trasujące powinno przy wyznaczaniu tras korzystać z takich informacji, jak obciążenie sieci, długość datagramu, czy zawarty w nagłówku datagramu typ obsługi. Jednak przeważająca część oprogramowania trasującego jest znacznie mniej wyrafinowana i wybiera trasy na podstawie ustalonych informacji o najkrótszych ścieżkach.
Rolę routera może pełnić także zwykły komputer z wieloma przyłączeniami do sieci.

6.7. Koleje życia datagramu

Prześledzimy teraz losy datagramu przy przesyłaniu do pomiędzy maszynami, co pozwoli lepiej zrozumieć jak IP radzi sobie z tym problemem.

Gdy aplikacja ma zamiar wysłać datagram w sieć, wykonuje kilka prostych kroków. Najpierw konstruuje datagram zgodnie z wymogami lokalnej implementacji IP. Zostaje obliczona suma kontrolna dla danych i skonstruowany nagłówek IP. Następnie pierwszy węzeł na drodze wędrówki datagramu określić musi etap następny - inną maszynę w sieci lub router, gdy dane muszą się z sieci wydostać. Jeżeli dane są szczególnie cenne, w nagłówku IP zostaną ustawione odpowiednie opcje. Na koniec datagram jest "posyłany w sieć".

Każdy router otrzymujący datagram wykonuje na nim serię testów. Gdy warstwa sieciowa zdejmie z niego swój nagłówek, warstwa IP weryfikuje sumę kontrolną datagramu. W razie niezgodności datagram jest odrzucany i do węzła-nadawcy kierowany jest komunikat o błędzie. Następnie pole TTL jest odpowiednio zmniejszone i sprawdzane. Jeśli limit czasu jest przekroczony sygnalizowany jest błąd. Po określeniu następnego węzła (na podstawie adresu docelowego) zostaje zapisana nowa wartość TTL i nowa suma kontrolna. Jeżeli konieczna jest fragmentacja, jest on dzielony na mniejsze datagramy i każdy z nich opatrywany jest nagłówkiem IP. W końcu datagram przekazywany jest z powrotem do warstwy sieciowej. Gdy datagram dotrze do celu zostaje scalony, zdejmowany jest nagłówek IP, odtworzony jest oryginalny komunikat i przesyłany w stronę wyższych warstw.

6.8. Kapsułkowanie i fragmentacja

6.8.1. Kapsułkowanie

Datagramy przemieszczając się od jednej maszyny do drugiej muszą być przenoszone przez sieć fizyczną. Kapsułkowaniem nazywamy rozwiązanie, w którym jeden datagram przenoszony jest przez jedną ramkę sieciową. Datagram zachowuje się wówczas jak każdy inny komunikat przesyłany z jednej maszyny do innej, tzn. podróżuje w części ramki sieciowej przeznaczonej na dane.

6.8.2. Fragmentacja

W idealnym przypadku cały datagram mieści się w jednej ramce fizycznej. Nie zawsze jednak jest to możliwe. Dzieje się tak dlatego, że datagram może przemieszczać się przez różne sieci fizyczne. Każda z nich ma ustaloną górną granicę ilości danych, które mogą być przesłane w jednej ramce.
Ten parametr sieci nosi nazwę maksymalnej jednostki transmisyjnej danej sieci (ang. Maximum Transfer Unit - MTU). Ograniczenie wielkości datagramów, tak aby pasowały do najmniejszego MTU, byłoby nieefektywne w przypadku przechodzenia przez sieci, które mogą przenosić większe ramki. Jeśli datagram nie mieści się w ramce fizycznej jest dzielony na mniejsze kawałki zwane fragmentami, a proces ten nazywa się fragmentacją. Gdy takie pofragmentowane datagramy dotrą do odbiorcy podlegają procesowi odwrotnemu czyli defragmentacji.

Każdy z fragmentów zawiera nagłówek, w którym jest powielona większość zawartości nagłówka pierwotnego datagramu (z wyjątkiem pola znaczniki, które wskazuje, że jest to fragment).

6.8.3. Kontrola Fragmentacji

Trzy pola nagłówka identyfikacja, znaczniki, przesunięcie fragmentu służą kontroli procesów fragmentacji i składania datagramów. Pole identyfikacja (16-bitowe) zawiera liczbę całkowitą jednoznacznie identyfikującą datagram. Identyfikator jest niezbędny, gdyż zapobiega wymieszaniu się fragmentów pochodzących od różnych datagramów - wszystkie kawałki będące częściami tego samego datagramu posiadają ten sam identyfikator. Pole znaczniki (3-bitowe) służy do kontroli fragmentacji. Pierwszy z trzech bitów jest nie używany, nadanie drugiemu wartości 1 oznacza bezwzględny zakaz fragmentacji. Jeśli datagram nie może być przesłany w całości, zostaje odrzucony i sygnalizowany jest błąd. Ostatni z bitów znaczników umożliwia identyfikację ostatniego kawałka datagramu - ma w nim wartość 0, w pozostałych przypadkach 1. Pole przesunięcie fragmentu (13-bitowe) zawiera informację, w którym miejscu datagramu umiejscowione są informacje przesyłane w tym kawałku. Jest ono mierzone w jednostkach 64-bajtowych. Umożliwia to poprawne scalenie datagramu - nie istnieje nic w rodzaju kolejnego numeru kawałka w datagramie.

6.9. Protokół ICMP

Oprogramowanie Internet Protocol realizuje zawodne przenoszenie pakietów bez użycia połączenia. Datagram wędruje od nadawcy przez różne sieci i routery aż do końcowego odbiorcy. Jeżeli router nie potrafi ani wyznaczyć trasy ani dostarczyć datagramu, albo gdy wykrywa sytuacje mającą wpływ na możliwość dostarczenia datagramu np. Przeciążenie sieci, wyłączenie maszyny docelowej, wyczerpanie się licznika czasu życia datagramu to musi poinformować pierwotnego nadawcę, aby podjął działania w celu uniknięcia skutków tej sytuacji.

Protokół komunikatów kontrolnych internetu ICMP (ang. Internet Control Message Protocol) powstał aby umożliwić routerom oznajmianie o błędach oraz udostępnianie informacji o niespodziewanych sytuacjach. Chociaż protokół ICMP powstał, aby umożliwić routerom wysyłanie komunikatów to każda maszyna może wysyłać komunikaty ICMP do dowolnej innej. Protokół ICMP jest traktowany jako wymagana część IP i musi być realizowany przez każdą implementację IP.

Z technicznego punktu widzenia ICMP jest mechanizmem powiadamiania o błędach.
Gdy datagram powoduje błąd, ICMP może jedynie powiadomić pierwotnego nadawcę o przyczynie. Nadawca musi otrzymaną informację przekazać danemu programowi użytkownika, albo podjąć inne działanie mające na celu uporanie się z tym problemem. Każdy komunikat ICMP ma własny format, ale wszystkie zaczynają się trzema takimi samymi polami:

8-bitowe pole typ komunikatu identyfikuje komunikat,
8-bitowe pole kod daje dalsze informacje na temat rodzaju komunikatu,
Pole suma kontrolna (obliczane podobnie jak suma IP, ale suma kontrolna ICMP odnosi się tylko do komunikatu ICMP).

Oprócz tego komunikaty ICMP oznajmiające o błędach zawsze zawierają nagłówek i pierwsze 64 bity danych datagramu, z którym były problemy.

6.9.1. Dostarczanie komunikatów ICMP

Komunikaty ICMP wymagają dwóch poziomów kapsułkowania.
Każdy komunikat ICMP podróżuje przez intersieć w części datagramu IP przeznaczonej na dane, a ten przemieszcza się przez sieć fizyczną w części dla danych ramki.
Chociaż komunikaty ICMP są kapsułkowane i przenoszone przy użyciu IP, nie są protokołem wyższego rzędu lecz wymaganą częścią IP.

6.9.2. Określanie ostatecznego adresata

System operacyjny większości komputerów zapewnia wielozadaniowość.
Omówiony mechanizm adresowania i przesyłania datagramów nie rozróżnia użytkowników ani programów użytkowych, do których jest skierowany taki datagram. Zachodzi więc potrzeba rozszerzenia zestawu protokołów o mechanizm, który pozwoli rozróżniać adresy w obrębie pojedynczego komputera.

Adresowanie wprost do konkretnego procesu z wielu powodów nie byłoby dobrym rozwiązaniem; np. ponieważ procesy tworzone i likwidowane są dynamicznie, nadawca ma więc zbyt mało informacji aby wskazać proces na innej maszynie, przeładowanie systemu operacyjnego powoduje zmianę wszystkich procesów itp. W miejsce tego wprowadzono abstrakcyjne punkty docelowe zwane portami protokołów.
Każdy port jest identyfikowany za pomocą dodatniej liczby całkowitej. Lokalny system operacyjny zapewnia procesom określenie dostępu do portów. Nadawca musi znać adres IP odbiorcy i numer docelowego portu protokołu na maszynie odbiorcy, komunikat musi ponadto zawierać numer portu nadawcy tak aby proces odbierający komunikat mógł wysłać odpowiedź do nadawcy.

6.10. Protokół UDP

W zestawie protokołów TCP/IP protokół datagramów użytkownika UDP (ang. User Datagram Protocol), zapewnia porty protokołów używane do rozróżniania programów wykonywanych na pojedynczej maszynie.

Oprócz wysyłanych danych, każdy komunikat zawiera numer portu odbiorcy i numer portu nadawcy, dzięki czemu oprogramowanie UDP odbiorcy może dostarczyć komunikat do właściwego adresata. Do przesyłania komunikatów między maszynami UDP używa podstawowego protokołu IP i ma tę samą niepewną, bezpołączeniową semantykę dostarczania datagramów co IP - nie używa potwierdzeń w celu upewnienia się, o dotarciu komunikatów i nie zapewnia kontroli szybkości przesyłania danych między maszynami. Z tego powodu komunikaty UDP mogą być gubione, duplikowane lub przychodzić w innej kolejności niż były wysłane, ponadto pakiety mogą przychodzić szybciej niż odbiorca może je przetworzyć. Program użytkowy korzystający z UDP musi na siebie wziąć odpowiedzialność za rozwiązanie problemów niezawodności.

Ponieważ sieci lokalne dają dużą niezawodność i małe opóźnienia wiele programów opartych na UDP dobrze pracuje w sieciach lokalnych, ale może zawodzić w większych intersieciach TCP/IP.

6.10.1. Format komunikatów UDP

Komunikat UDP nazywa się datagramem użytkownika.

Nagłówek datagramu użytkownika składa się z czterech 16-bitowych pól:

Pola port nadawcy i port odbiorcy zawierają 16-bitowe numery portów UDP używane do odnajdywania procesów oczekujących na dany datagram. Pole port nadawcy jest opcjonalne.
Pole długość zawiera wartość odpowiadającą liczbie bajtów datagramu UDP wliczając nagłówek i dane. Minimalna więc wartość tego pola wynosi więc 8, czyli jest długością samego nagłówka.
Pole suma kontrolna jest opcjonalne. Ponieważ jednak IP nie wylicza sum kontrolnych dla danych, suma kontrolna UDP jest jedyną gwarancją, że dane nie zostały uszkodzone.

6.10.2. Kapsułkowanie UDP

Datagram UDP jest przed wysłaniem w sieć, kapsułkowany w datagram IP.

Nagłówek IP identyfikuje maszynę źródłową i docelową, UDP - identyfikuje porty nadawcy i odbiorcy. U odbiorcy pakiet dociera do najniższej warstwy oprogramowania sieciowego i wędruje ku coraz wyższym warstwom. Każda z nich usuwa jeden nagłówek, oczekujący proces otrzymuje więc komunikat bez nagłówków.
Warto zwrócić uwagę, że datagram UDP otrzymany od IP na maszynie docelowej jest identyczny z tym, który UDP przekazało do IP na maszynie źródłowej.

6.11. Multipleksowanie i demultipleksowanie

Protokoły komunikacyjne wykorzystują metody multipleksowania i demultipleksowania na poziomach wszystkich warstw. Przy wysyłaniu komputer nadawcy dołącza do danych dodatkowe bity, które wskazują typ komunikatu, program, który go nadał oraz używane protokoły. Wszystkie komunikaty są umieszczane w przeznaczonych do przesyłania ramkach sieciowych i łączone w strumień pakietów. U odbiorcy zaś te informacje są używane do sterowania przetwarzaniem.
Multipleksowanie i demultipleksowanie pojawia się w prawie wszystkich warstwach protokołów. Przykładowo, gdy interfejs sieciowy zdemultipleksuje ramki i prześle te z nich, które zawierają datagramy IP do modułu IP, oprogramowanie IP wydobędzie z nich datagramy i dalej je zdemultipleksuje w warstwie IP. Aby zdecydować, w jaki sposób obsłużyć datagram, oprogramowanie sprawdza nagłówek datagramu i wybiera na podstawie typu datagramu odpowiednie procedury.

Przykład demultipleksowania w warstwie IP: oprogramowanie IP wybiera odpowiednia procedurę obsługi na podstawie znajdującego się w nagłówku datagramu pola typu protokołu.

Oprogramowanie UDP musi przyjmować datagramy UDP pochodzące od wielu programów użytkowych i przekazywać je warstwie IP w celu przesłania, a także odbierać datagramy UDP nadchodzące od warstwy IP i przekazywać odpowiednim programom użytkowym. Aby to zrealizować musi multipleksować datagramy UDP tak aby datagramy pochodzące z różnych portów mogły być przekazane do warstwy IP i demultipleksować datagramy przychodzące z warstwy IP tak by skierować je do właściwego portu. Rozróżnienie następuje przy pomocy pola port UDP nadawcy i odbiorcy.

6.12. Transmission Control Protocol

Do tej pory opisaliśmy usługi zawodnego dostarczania pakietów, bez użycia połączenia, co stanowi podstawę protokołu IP. IP nie troszczy się tak naprawdę o dostarczenie datagramu do adresata, lecz w przypadku odrzucenia datagramu sygnalizuje ten fakt jako błąd maszynie-nadawcy i uznaje sprawę za załatwioną.

Używanie zawodnego dostarczania bez użycia połączenia do przesyłania dużych porcji danych jest więc nużące i wymaga od programistów, aby wbudowywali do każdego programu użytkowego wykrywanie i korekcję błędów.
Teraz zajmiemy się przesyłaniem niezawodnymi strumieniami TCP (ang. Transmission Control Protocol), które istotnie zwiększa funkcjonalność omawianych do tej pory protokołów, biorąc odpowiedzialność za wiarygodne dostarczenie datagramu. Okupione jest to jednak skomplikowaniem protokołu. Protokół TCP będąc drugą najważniejszą usługą w sieci, wraz z IP dał nazwę całej rodzinie protokołów TCP/IP.

Pomimo związku z protokołem IP - TCP jest protokołem w pełni niezależnym i może zostać zaadaptowany do wykorzystania z innymi systemami dostarczania.
Możliwe jest używanie go zarówno w pojedynczej sieci takiej jak ethernet jak i w skomplikowanej intersieci.

6.12.1. Własności usługi niezawodnego dostarczania

TCP organizuje dwukierunkową współpracę między warstwą IP, a warstwami wyższymi, uwzględniając przy tym wszystkie aspekty priorytetów i bezpieczeństwa. Musi prawidłowo obsłużyć niespodziewane zakończenie aplikacji, do której właśnie wędruje datagram, musi również bezpiecznie izolować warstwy wyższe - w szczególności aplikacje użytkownika - od skutków awarii w warstwie protokołu IP. Scentralizowanie wszystkich tych aspektów w jednej warstwie umożliwia znaczną oszczędność nakładów na projektowanie oprogramowania.

TCP rezyduje w modelu warstwowym powyżej warstwy IP. Warstwa ta jest jednak obecna tylko w tych węzłach sieci, w których odbywa się rzeczywiste przetwarzanie datagramów przez aplikacje, tak więc nie posiadają warstwy TCP na przykład routery, gdyż warstwy powyżej IP nie miałyby tam nic do roboty.

6.12.2. Kanał wirtualny TCP

Rozpatrując TCP z punktu widzenia funkcjonalności można potraktować jego pracę jako ustanowienie kanału wirtualnego realizującego komunikację między "końcówkami" - tak wygląda to z punktu widzenia aplikacji użytkownika.

Rzeczywisty przepływ oczywiście odbywa się poprzez warstwę IP i warstwy niższe.

0x08 graphic

6.12.3 Realizacja niezawodnego połączenia

Aby zagwarantować, że dane przesyłane z jednej maszyny do drugiej nie są ani tracone, ani duplikowane używa się podstawowej metody znanej jako pozytywne potwierdzanie z retransmisją. Metoda ta wymaga, aby odbiorca komunikował się z nadawcą, wysyłając mu w momencie otrzymania danych komunikat potwierdzenia (ACK). Nadawca zapisuje sobie informację o każdym wysłanym pakiecie i przed wysłaniem następnego czeka na potwierdzenie. Oprócz tego nadawca uruchamia zegar w momencie wysyłania pakietu i wysyła ten pakiet ponownie, gdy minie odpowiedni czas, a potwierdzenie nie nadejdzie.

Po wysłaniu pakietu nadawca włącza zegar. Gdy mija określony czas, w czasie którego powinno nadejść potwierdzenie ACK nadawca przyjmuje, że pakiet został zagubiony i wysyła go ponownie.

6.12.4. Idea przesuwających się okien

To rozwiązanie sprawia, że przesyłanie strumieniami jest efektywniejsze. Chodzi o przesuwające się okna (ang. sliding window). Jak wiemy w celu uzyskania niezawodności nadawca wysyła pakiet, a przed wysłaniem następnego oczekuje na potwierdzenie odebrania.

Dane w danym momencie płyną tylko w jednym kierunku i to nawet wtedy, kiedy sieć umożliwia jednoczesną komunikację w obu kierunkach. Ponadto sieć nie będzie używana, kiedy maszyny będą zwlekać z odpowiedziami np. podczas wyliczania sum kontrolnych. Takie rozwiązanie powoduje znaczne marnowanie przepustowości sieci.
Technika przesuwającego się okna lepiej wykorzystuje przepustowość sieci, gdyż umożliwia wysyłanie wielu pakietów przed otrzymaniem potwierdzenia. W rozwiązaniu tym umieszcza się na ciągu pakietów ustalonego rozmiaru okna i przesłanie wszystkich pakietów, które znajdują się w jego obrębie. Mówimy, że pakiet jest niepotwierdzony, jeżeli został wysłany, a nie nadeszło dla niego potwierdzenie. Liczba pakietów niepotwierdzonych w danej chwili jest wyznaczona przez rozmiar okna.
Dla protokołu z przesuwającym się oknem, którego rozmiar jest np. równy 8, nadawca ma możliwość wysłania przed otrzymaniem potwierdzenia do 8 pakietów. Gdy nadawca odbierze potwierdzenie dla pierwszego pakietu, okno przesuwa się i zostaje wysłany następny pakiet. Okno przesuwa się dalej gdy przychodzą kolejne potwierdzenia.

Pakiet dziewiąty może zostać wysłany gdy przyszło potwierdzenie dotyczące pierwszego pakietu. Retransmitowane są tylko te pakiety, dla których nie było potwierdzenia. Oczywiście protokół musi pamiętać, które pakiety zostały potwierdzone i utrzymuje oddzielny zegar dla każdego nie potwierdzonego pakietu. Gdy pakiet zostanie zgubiony lub zostaje przekroczony czas nadawca wysyła ten pakiet jeszcze raz. Poprawa uzyskiwana przy protokołach z przesuwającymi się oknami zależy od rozmiaru okna i szybkości, z jaką sieć akceptuje pakiety.
Gdy rozmiar okna wynosi 1, protokół z przesuwającym się oknem jest tym samym, co nasz zwykły protokół z potwierdzaniem. Zwiększając rozmiar okna, możemy w ogóle wyeliminować momenty nieaktywności sieci. Oznacza to, że w sytuacji stabilnej nadawca może przesyłać pakiety tak szybko, jak szybko sieć może je przesyłać.

Istotne jest, że nadawca może przesłać wszystkie pakiety z okna bez oczekiwania na potwierdzenie.

6.12.5 Segment TCP

Mianem segmentu określa się jednostkową porcję danych przesyłanych między oprogramowaniem TCP na różnych maszynach.

Pola port nadawcy i port odbiorcy zawierają numery portów TCP, które identyfikują programy użytkowe na końcach połączenia.

Pole numer porządkowy wyznacza pozycję danych segmentu w strumieniu bajtów nadawcy.
Pole numer potwierdzenia wyznacza numer oktetu, który nadawca spodziewa się otrzymać w następnej kolejności. Zwróćmy uwagę, że numer porządkowy odnosi się do strumienia płynącego w tym samym kierunku co segment, zaś numer

potwierdzenia odnosi się do strumieni płynących w kierunku przeciwnym.
Pole długość nagłówka zawiera liczbę całkowitą, która określa długość nagłówka segmentu mierzoną w wielokrotnościach 32 bitów. Jest ono konieczne gdyż pole opcje ma zmienną długość.

Pole zarezerwowane jest pozostawione do wykorzystania w przyszłości.
Ponieważ niektóre segmenty mogą przenosić tylko potwierdzenia, inne dane, inne zaś zawierają prośby o ustanowienie lub zamknięcie połączenia - pole bity kodu zawiera informację o przeznaczeniu zawartości segmentu.

Przy każdym wysłaniu segmentu oprogramowanie TCP proponuje ile danych może przyjąć, umieszczając rozmiar swojego bufora w polu okno.

6.12.6 Porty i połączenia

Protokół TCP umożliwia wielu działającym na jednej maszynie programom użytkowym jednoczesne komunikowanie się oraz rozdziela między programy użytkowe przybywające pakiety TCP. Podobnie jak UDP, TCP używa numerów portów protokołu do identyfikacji w ramach maszyny końcowego odbiorcy. Każdy z portów ma przypisaną małą liczbę całkowitą, która jest używana do jego identyfikacji.
Porty TCP są jednak bardziej złożone, gdyż dany numer nie odpowiada bezpośrednio pojedynczemu obiektowi. TCP działa wykorzystując połączenia, w których obiektami są obwody wirtualne a nie poszczególne porty. Tak więc podstawowym pojęciem TCP jest pojęcie połączenia, a nie portu. Połączenia są identyfikowane przez parę punktów końcowych.
TCP definiuje punkt końcowy jako parę liczb całkowitych (węzeł, port), gdzie węzeł oznacza adres IP węzła, a port jest portem TCP w tym węźle.

Np. punkt końcowy (128.10.2.3, 25) oznacza port 25 maszyny o adresie IP 128.10.2.3. W efekcie może istnieć połączenie np. pomiędzy: (18.26.0.36, 1069) oraz (128.10.2.3, 25), w tym samym czasie może też istnieć (128.9.0.32, 1184) oraz (128.10.2.3, 25).

W związku z tym, że TCP identyfikuje połączenie za pomocą pary punktów końcowych, dany numer portu może być przypisany do wielu połączeń na danej maszynie.

7. Podsumowanie

Protokoły są tj. narzędziami do wpuszczania danych w sieć teleinformatyczną, a zatem zawierają reguły i instrukcje dotyczące transmisji danych w realnym środowisku. Podsumowując:

protokoły są regułami używanymi do transmitowania i odbierania danych, aby umożliwić realną komunikację między środowiskiem aplikacji,
istnieje różnica między protokołem i usługą. Usługa to coś co użytkownik chce wydobyć z sieci, zaś protokół jest narzędziem systemu teleinformatycznego niezbędnym do udostępnienia tej usługi,
niemożliwe jest skonstruowanie systemu telekomunikacyjnego który pracowałby bez zakłóceń. Dlatego realne systemy potrzebują protokołów do zabezpieczenia się w jakimś stopniu przed błędami powstałymi w trakcie przekazywania informacji.
istnieją dwa główne rodzaje usług: bezpołączeniowe, będące tj. analogią systemów pocztowych i zorientowane połączeniowo, będące analogią systemów telefonicznych,
większość architektur protokołów używa hierarchicznych systemów warstwowych.
komunikacja między użytkownikami wymaga używania przez nich tego samego protokołu lub istnienia jakiegoś przekaźnika który jest w stanie odczytać różne protokoły i odpowiednio je przetłumaczyć.

Trudno spekulować nad tym, co w przyszłości będzie standardem, jakie nowe protokoły wejdą w życie. Już dziś istnieje ich wielkie bogactwo. Najprawdopodobniej ludzie będą dążyć do jakiegoś ujednolicenia działających obecnie protokołów, może powstanie jeden wspólny standard. Bo czymże by była „globalna wioska” bez jednolitego standardu komunikacji wewnątrz niej?...

Bibliografia:

Colin Smythe „Internetworking - Designing the Right Architectures”

D.W.Davies, D.L.Barber „Sieci teleinformatyczne”

A.W.Butrimenko „Projektowanie i eksploatacje sieci kompuerowych”

oraz materiały zgromadzone w sieci Internet.

Spis treści

Rozdział: strona:

1.			Wstęp	1
2.			Standaryzacja protokołów	1
3.			Typy protokołów	4
	3.1.		Transfer danych z użyciem protokołów	5
4.			Model warstwowy protokołów	7
	4.1.		Zadania warstw	9
5.			Przegląd ważniejszych protokołów	10
	5.1.		Protokoły prywatne	10
	5.2.		Protokoły publiczne	11
6.			Protokół TCP/IP	11
	6.1.		TCP/IP a model OSI	11
	6.2.		Zadania warstw w TCP/IP	11
	6.3.		Adresy IP	12
		6.3.1.	Klasy adresów IP	13
		6.3.2.	Przydzielanie adresów sieciowych	13
	6.4.		Protokół ARP i RARP	14
		6.4.1.	Protokół odwzorowania adresów (ARP)	14
		6.4.2.	Odwzorowanie adresów i pamięć podręczna	14
		6.4.3.	Protokół odwrotnego odwzorowania adresów (RARP)	15
	6.5.		Internet Protokol IP	15
		6.5.1.	Datagram IP	16
	6.6.		Routery	18
	6.7.		Koleje życia datagramu	18
	6.8.		Kapsułkowanie i fragmentacja	19
		6.8.1.	Kapsułkowanie	19
		6.8.2.	Fragmentacja	19
		6.8.3.	Kontrola fragmentacji	19
	6.9.		Protokół ICMP	20
		6.9.1.	Dostarczanie komunikatów ICMP	20
		6.9.2.	Określenie ostatecznego adresata	21
	6.10.		Protokół UDP	21
		6.10.1.	Format komunikatów UDP	21
		6.10.2.	Kapsułkowanie UDP	22
	6.11.		Multipleksowanie i demultipleksowanie	22
	6.12.		Transmission Control Protocol (TCP)	23
		6.12.1.	Własności usługi niezawodnego dostarczania	23
		6.12.2.	Kanał wirtualny TCP	23
		6.12.3.	Realizacja niezawodnego połączenia	24
		6.12.4.	Idea przesuwających się okien	25
		6.12.5.	Segment TCP	25
		6.12.6.	Porty i połączenia	26
7.			Podsumowanie	26

United

Nations

ITU

WARC

CCIR

(ITU-R)

CCITT

(ITU-T)

ITU

ECMA

CEC

ETSI

National

Standards

Bodies

Telecommsbodies

(PTTs)

BSI

ANSI

Mercury

AT&T etc

NIST

IEEE

EIA

...

Rys.1 Związki między organizacjami standaryzacyjnymi

Rys. 2. Protokół Stop-and-wait

Respondent

Inicjator

Potwierdzenie

Brak potwierdzenia

Potwierdzenie

Narastanie czasu

Rys. 3. Protokół Go-back-n

Respondent

Inicjator

Potwierdzenie 6

Potwierdzenie 5

Brak potwierdzenia 4

Potwierdzenie 3

Potwierdzenie 2

Potwierdzenie 1

Czas

Warstwa danych

Warstwa sieciowa

Protokół warstwy sesji

Warstwa transportowa

Protokół warstwy sesji

Warstwa sesji

Protokół warstwy prezentacji

Warstwa prezentacji

Protokół warstwy aplikacji

Warstwa aplikacji

TCP/IP

OSI

Rys. 4. Model warstwowy

Protokół warstwy fizycznej

Protokół warstwy danych

Protokół warstwy sieciowej

Komputer 2

Komputer 1

Bit

Ramka

Pakiet

Wiadomość

Wymieniana jednostka informacji

Warstwa fizyczna

Warstwa aplikacji

Programy użytkowe

Warstwa prezentacji

Warstwa sesji

Warstwa transportowa

Warstwa sieciowa

Warstwa łącza danych

Warstwa fizyczna

Transport

Intersieć

Interfejs sieciowy

Sprzęt

Obiekty przesyłane między warstwami w modelu

TCP/IP

Komunikaty i strumienie

Pakiety

Datagramy IP

Ramka sieci fizycznej

Rys. 5. TCP/IP a model OSI

Sieć (7 bitów)

Komputer (24 bity)

Sieć (14 bitów)

Komputer (16 bitów)

Sieć (21 bitów)

Komputer (8 bitów)

Adres grupowy (28 bitów)

Zarezerwowane na przyszłość

Rys. 6. Klasy adresów IP

Usługi programów użytkowych

Usługi niezawodnego przesyłania

Usługi bezpołączeniowego przesyłania pakietów

Rys. 7. Usługi w sieciach TCP/IP

Warstwa aplikacji

Warstwa prezentacji

Warstwa sesji

Warstwa TCP

Warstwa IP

Warstwa połączeniowa

Warstwa fizyczna

Warstwa połączeniowa

Warstwa IP

Warstwa TCP

Warstwa sesji

Warstwa prezentacji

Warstwa aplikacji

Warstwa fizyczna

Warstwa połączeniowa

Warstwa IP

Warstwa fizyczna

Warstwa połączeniowa

Warstwa IP

Podsieć

Maszyna

wysyłająca

Maszyna

odbierająca

Komunikacja końcowa (wirtualna)

Rys. 8. Komunikacja wirtualna w protokole TCP