Jakość usług w sieciach z protokołem IP

Jakość usług w sieciach z protokołem IP

1. Wstęp

Powszechnie zauważalna staje się tendencja zmiany oblicza protokołu IP. Zmiany te prowadzą Internet w stronę silnie skomercjalizowanej sieci globalnej. Wśród dynamicznie rozwijających się usług internetowych wyróżnić możemy: telefonię IP, usługi bankowe (home banking), edukacyjne (home education), transmisję sygnałów radiowych i telewizyjnych (Internet broadcasting) oraz wideo na żądanie (video on demand). Nowo wprowadzone aplikacje wymagające utrzymania wartości parametrów jakościowych na określonym poziomie to aplikacje transmitujące dźwięk i obraz w czasie rzeczywistym oraz aplikacje przesyłające dane, dla których dostarczenia wymagane jest małe opóźnienie. Komercjalizacja niesie ze sobą konieczność wdrożenia mechanizmów umożliwiających zróżnicowanie obsługi pakietów w zależności od potrzeb. Czynnik ekonomiczny w przypadku budowy nowych sieci IP należy uznać za decydujący, ponieważ rozwój infrastruktury sieci wymaga ogromnych inwestycji.

Obecna generacja sieci Internet bazuje na protokole IPv4 (Internet Protocol) i realizuje przekaz pakietów na zasadzie best-effort, co nie zapewnia żadnej jakości obsługi. Oznacza to, że sposób obsługi pakietów zależy od obecnie istniejących warunków ruchowych, nie zależy natomiast od rodzaju aplikacji generujących pakiety. Dodatkowo sieć nie realizuje żadnej polityki przyjmowania lub odrzucania nowych połączeń, zaś sterowanie liczbą pakietów napływających do sieci jest przeniesione do użytkownika.

Pojawia się potrzeba stworzenia zintegrowanej sieci, która umożliwiłaby przesyłanie pakietów pochodzących z aplikacji o różnych wymaganiach jakości obsługi QoS (Quality of Service), gdyż dotychczasowy sposób obsługi stał się niewystarczający. Zapewnienie wielousługowego charakteru sieci IP i stworzenie sieci QoS IP wymaga wprowadzenia zróżnicowanych usług sieciowych, podobnie jak ma to miejsce w sieci ATM (Asynchronous Transfer Mode). Usługi te powinny różnić się pomiędzy sobą takimi parametrami jak: dostępne pasmo, maksymalne opóźnienie, zmienność opóźnienia, poziom strat pakietów, stopa błędów. Żądany poziom obsługi może być zapewniony poprzez działania w wielu płaszczyznach. Mają na niego wpływ: ruting, algorytmy szeregowania i zarządzania kolejkami w węzłach, funkcje przyjmowania nowych zgłoszeń i sterowania ruchem.

Aby sprostać tym wymaganiom organizacja IETF (Internet Engineering Task Force) zaproponowała techniki – IntServ (Integrated Services), DiffServ (Differentiated Services) mające na celu poprawę jakości obsługi w sieci Internet oraz standard MPLS (Multi Protocol Label Switching) umożliwiający usprawnienie transportu pakietów IP w warstwach 2 i 3. Pierwsza z nich oparta jest o model rezerwacji zasobów i dzięki wprowadzeniu protokołu RSVP (Resorce Reservation Protocol) umożliwia zestawianie w sieci połączeń o wymaganych parametrach jakościowych. Wiąże się to jednak ze znacznym skomplikowaniem architektury węzłów. Alternatywnym rozwiązaniem jest architektura DiffServ, znacznie uproszczona w stosunku do architektury IntServ. Zamiast traktować każde połączenie w sieci oddzielnie, agreguje ona strumienie danych w odpowiednie dla nich klasy. Dopiero klasom przypisany jest określony poziom jakości obsługi.

Zaproponowana przez IETF technika MPLS to zupełnie nowe podejście do komutacji pakietów. Istotą tej techniki jest dołączanie do każdego pakietu krótkiej etykiety w urządzeniu – ruterze brzegowym domeny MPLS. Wewnątrz domeny MPLS dołączone do pakietów etykiety służą do podejmowania decyzji, dokąd kierować pakiet. Mimo, iż MPLS zawiera pewne mechanizmy QoS, to jednak głównym zadaniem tej techniki jest poprawa skalowalności sieci IP dzięki ulepszonej inżynierii obsługi ruchu.

Celem pracy jest przedstawienie i analiza standardów wspierających jakość usług w sieciach IP. Przedstawiono najistotniejsze cechy modeli IntServ, DiffServ oraz MPLS pod względem zapewnienia jakości usług w relacji od końca do końca (end-to-end). Nieco uwagi poświęcono możliwościom praktycznego zastosowania tych technik w różnych obszarach sieci oraz zagadnieniom ich współpracy.

Decydujące znaczenie w ocenie wydajności działania mechanizmów zapewniających odpowiednią jakość usług QoS mają pomiary w istniejącej sieci. W pracy zaprezentowano koncepcję systemu pomiarowego służącego do monitorowania parametrów QoS realizowanych usług sieciowych jako istotny element utrzymania sieci. W pracy zawarto opis wzajemnych relacji pomiędzy Dostawcą Usług a Klientem; punktów pomiarowych; metryk QoS; metodologii pomiarowej oraz prezentacji wyników pomiarowych.

2. Protokół TCP/IP

Zestaw protokołów TCP/IP pozwala na komunikowanie się komputerów różnej mocy obliczeniowej, pochodzących od różnych producentów i pracujących pod kontrolą różnych systemów operacyjnych. Jest to zdumiewające zjawisko, ponieważ wykorzystanie TCP/IP znacznie przekroczyło zakładany na początku zakres zastosowań. To, co pod koniec lat 60 rozpoczęto jako finansowany przez rząd projekt badawczy zmierzający do opracowania sieci pakietowej, w latach 90 zmieniło się w powszechnie używaną formę sieci łączącej miliony komputerów. Jest to naprawdę system otwarty, ponieważ zestaw protokołów i jego kolejne implementacje są w prawie niezmienionej formie powszechnie dostępne w sieci, bezpłatnie lub za niewielką opłatą. Podstawą tego, co powszechnie nazywane jest światowym Internetem lub po prostu Internetem, jest globalna sieć WAN (Wide Area Network), w której pracują miliony komputerów.

2.1. Warstwy sieci

Protokoły sieciowe opracowywane są zwykle z uwzględnieniem warstwowego modelu sieci, w którym kolejne warstwy odpowiedzialne są za różne aspekty komunikacji. Zestaw protokołów, taki jak TCP/IP, jest kombinacją różnych protokołów działających w kilku warstwach. Zestaw protokołów TCP/IP rozważa się zwykle jako system czterowarstwowy, jak pokazano na rysunku 2.1. [1].

Rysunek 2.1. Cztery warstwy protokołów TCP/IP

Każda z tych warstw odpowiedzialna jest, za co innego:

  • Warstwa łącza, nazywana czasami warstwą łącza danych lub warstwą dostępu do sieci, zawiera zwykle programy obsługi urządzeń wchodzące w skład systemu operacyjnego i odpowiadające im karty interfejsów sieciowych w komputerze. Razem tworzą one zestaw obsługujący wszystkie sprzętowe szczegóły związane z fizycznym dołączeniem komputera do kabla sieciowego (lub innych mediów, jakie zostały użyte do budowy sieci komputerowej).

  • Warstwa sieci nazywana czasami warstwą Internetu obsługuje ruch pakietów w sieci. W tym miejscu następuje na przykład ruting pakietów. W zestawie protokołów TCP/IP warstwę tę tworzą: IP (Internet Protocol), ICMP (Internet Control Message Protocol) i IGMP (Internet Group Management Protocol).

  • Warstwa transportowa zapewnia przepływ danych pomiędzy dwoma hostami, obsługując znajdującą się nad nią warstwę aplikacji. W skład TCP/IP wchodzą dwa całkowicie różne protokoły warstwy transportowej: TCP (Transmission Control Protocol) i UDP (User Datagram Protocol). Protokół TCP zapewnia niezawodny przepływ danych pomiędzy dwoma hostami. Zajmuje się takimi funkcjami, jak dzielenie danych przekazywanych mu przez aplikacje na kawałki wielkości odpowiadającej warstwie sieci znajdującej się poniżej. Ponadto potwierdza on odebranie pakietów, określa czasy pozwalające hostowi, z którym następuje wymiana danych, na potwierdzenie ich odbioru i tak dalej. Ponieważ warstwa transportowa zapewnia niezawodny przepływ danych, warstwa aplikacji nie musi już się tym zajmować. Z drugiej strony, protokół UDP umożliwia znacznie prostsze usługi dla warstwy aplikacji. Przesyła między hostami pakiety danych, zwane datagramami, nie gwarantując jednak, że dotrą one do punktu przeznaczenia. W tym przypadku, jeśli żądany jest jakiś poziom niezawodności przesyłania danych, to musi go zapewnić warstwa aplikacji.

  • Warstwa aplikacji obsługuje funkcje związane z określoną aplikacją korzystającą z sieci. Istnieje wiele aplikacji TCP/IP, które dostępne są w prawie każdej implementacji:

    • Telnet pozwalający na zdalne zalogowanie się do systemu,

    • FTP (File Transfer Protocol) protokół transmisji plików,

    • SMTP (Simple Mail Transfer Protocol) protokół obsługujący pocztę elektroniczną,

    • SNMP (Simple Network Management Protocol) protokół zarządzania siecią.

2.2. Skład TCP/IP

W zestawie protokołów TCP/IP jest wiele innych protokołów poza tymi, które występują w nazwie. Na rysunku 2.2. przedstawiono kilka innych protokołów wchodzących w skład TCP/IP [1].

TCP (Transmission Control Protocol) i UDP (User Datagram Protocol) są dwoma dominującymi protokołami warstwy transportowej. Obydwa używają IP jako protokołu warstwy sieci. TCP zapewnia niezawodne usługi warstwy transportowej, chociaż posługuje się IP, który nie gwarantuje niezawodności. UDP wysyła i odbiera datagramy przekazywane z aplikacji. Datagram jest jednostką informacji (tzn. określoną przez wysyłającego liczbą bajtów informacji), która przesyłana jest od nadawcy do odbiorcy. Jednakże w przeciwieństwie do TCP, UDP nie jest usługą niezawodną. Nie ma żadnej gwarancji, że wysłany datagram kiedykolwiek dotrze do celu.

Rysunek 2.2. Różne protokoły wchodzące w skład TCP/IP z podziałem na warstwy, w których pracują

IP jest podstawowym protokołem warstwy sieci. Używany jest on zarówno przez TCP, jak i przez UDP. Każdy segment danych TCP i UDP, który przysyłany jest przez sieć, musi przejść przez warstwę IP zarówno w systemach końcowych, jak i w ruterach pośrednich. Na rysunku 2.2. pokazana jest również aplikacja mająca bezpośredni dostęp do IP. Jest to rozwiązanie możliwe do zrealizowania, choć rzadko stosowane.

ICMP jest protokołem dodatkowym dla IP. Używany jest przez warstwę IP do wymiany komunikatów o błędach i innych ważnych informacji z warstwą IP na innym hoście lub ruterze. Choć ICMP używany jest głównie przez IP, to możliwe jest posługiwanie się nim z poziomu aplikacji (programy diagnostyczne Ping i Traceroute).

Protokół IGMP (Internet Group Management Protocol) jest używany przy multicastingu: wysyłaniu datagramów UDP do wielu hostów równocześnie.

ARP (Address Resolution Protocol) i RARP (Reverse Address Resolution Protocol) są specjalizowanymi protokołami, używanymi tylko z niektórymi rodzajami interfejsów sieciowych (takimi jak Ethernet i token ring), zapewniającymi konwersję pomiędzy adresami warstwy IP a adresami interfejsu sieciowego.

2.3. Protokół IP (Internet Protocol)

IP jest podstawowym protokołem w zestawie TCP/IP. Wszystkie dane z TCP, UDP, ICMP i IGMP przesyłane są przez datagramy IP rysunek 2.3. IP świadczy zawodne, bezpołączeniowe usługi dostarczania pakietów.

Poprzez słowo zawodne (unreliable) rozumiemy to, że nie ma żadnej gwarancji na pomyślne dostarczenie datagramu IP do punktu przeznaczenia. IP stara się jedynie dobrze przesłać datagramy. Kiedy jednak coś się nie uda, na przykład wystąpi przepełnienie buforów rutera, IP uruchamia bardzo prosty algorytm obsługi błędów: usuwa datagram i próbuje wysłać do źródła wiadomość ICMP. Wszelkie wymagane mechanizmy niezawodności transmisji muszą być zapewnia ne przez wyższe warstwy (np. TCP).

Określenie bezpołączeniowy oznacza, że IP nie zachowuje żadnej informacji o datagramach, które zostały przesłane pomyślnie. Każdy datagram obsługiwany jest niezależnie od pozostałych. Oznacza to również, że datagramy IP mogą docierać do punktu przeznaczenia w innej kolejności niż zostały wysłane. Jeśli nadawca wysyła dwa kolejne datagramy (najpierw A, potem B) do tego samego punktu przeznaczenia, każdy z nich rutowany jest niezależnie i może być przesłany inną trasą, w wyniku czego B może dotrzeć przed A.

2.3.1. Nagłówek IPv4

Obecnie używaną wersją protokołu jest wersja 4, dlatego czasem IP nazywany jest IPv4. Oficjalną specyfikacją IP jest dokument [4]. Na rysunku 2.3. pokazano format datagramu IP. Typowym rozmiarem nagłówka IP jest 20 bajtów, chyba, że umieszczone są w nim dodatkowe opcje.

Rysunek 2.3. Datagram IPv4 z uwzględnieniem pól tworzących nagłówek IP

Przedstawienie cech, możliwości i sposobu działania protokołu IP najłatwiej przedstawić omawiając kolejno znaczenie i zastosowanie poszczególnych elementów struktury danych, jaką stanowi nagłówek protokołu.

Adres źródłowy i docelowy

Wszystkie urządzenia pracujące wewnątrz sieci IP identyfikowane są poprzez unikatowy 32 bitowy adres IP. Wysyłając datagram nadawca umieszcza we właściwych polach adresy IP: swój i odbiorcy oraz dysponując wiedzą z tabeli rutingu wysyła datagram do rutera najwłaściwszego z punktu widzenia lokalizacji adresu odbiorcy. W przypadku sieci lokalnej typu ethernet datagram o adresie docelowym IP „lokalnym” dla danej sieci jest wysyłany bezpośrednio do żądanego komputera, zaś datagramy o innych adresach docelowych są kierowane do rutera – bramki. Zawartość obu pól adresowych nie jest zmieniana w trakcie przesyłania informacji. Sprawia to, że kolejny router wie, kto jest nadawcą informacji oraz gdzie powinna ona dotrzeć, lecz nieznana jest mu dotychczasowa trasa pakietu w sieci (adresy ruterów, które przesyłały datagram). W ten sposób informacja o sposobie dobierania trasy jest silnie rozproszona. Pole adres źródłowy nie odgrywa w procesie dostarczania datagramu istotnej roli, wykorzystywane jest dopiero przez odbiorcę do identyfikowania nadawcy wiadomości.

Czas życia datagramu (TTL)

Ponieważ jak opisano powyżej proces wybierania trasy datagramu zależy w dużej mierze od sprawności działania wszystkich węzłów pośredniczących, możliwe jest, że w sytuacjach awaryjnych pakiet będzie krążył pomiędzy ruterami bardzo długo, lub wręcz trasa jego przesyłania zostanie zapętlona. Pole TTL (Time-To-Live) zapobiega takiej sytuacji – jego zawartość jest wstępnie inicjowana przez nadawcę i dekrementowana przez każdy z węzłów, który przesyła datagram. Gdy jego wartość wyniesie 0, datagram zostaje usunięty, a do nadawcy wysyłany jest komunikat ICMP o błędzie.

Protokół przesyłający dane

Immanentną cechą enkapsulacji danych przez protokoły warstwowe jest fakt, iż najważniejszym zadaniem protokołu warstwy niższej jest dostarczanie danych dla warstwy wyższej. Choć powszechnie używa się akronimu TCP/IP, protokół sieciowy IP, oprócz danych warstwy TCP przenosi również dane protokołu transportowego UDP oraz dane sygnalizacyjne protokołów ICMP i IGMP (które uznane są za element protokołu IP choć stanowią de facto warstwę wyższą). Aby rozróżnić rodzaj przesyłanych w datagramie informacji nadawca umieszcza w tym polu nagłówka liczbę reprezentującą zestandaryzowane oznaczenie protokołu przesyłanych informacji. Pole to może zostać również użyte przez rutery do traktowania z wyższym priorytetem wiadomości sygnalizacyjnych ICMP.

Suma kontrolna nagłówka

Pole to zabezpiecza integralność informacji przesyłanych tylko w nagłówku datagramu. Z reguły jednak warstwy łącza danych (np. MAC w ethernecie, PPP w połączeniu modemowym) sprawdzają poprawność całej przesyłanej informacji, dodatkowo zaś dane mogą być jeszcze zabezpieczane przed przekłamaniem przez warstwy wyższe.

Identyfikacja

Pole to jest unikalnym numerem, który identyfikuje w sposób jednoznaczny datagram wysyłany z danego hosta. Szesnastobitowa wartość tego pola (65 536 możliwości) w połączeniu z mechanizmem TTL gwarantują, że w danej chwili w sieci nie będą nigdy istniały dwa identyczne pakiety.

Wersja protokołu

Pole to oznacza wprost numer używanego protokołu IP obecnie używana wersja to 4, w przyszłości zastąpi ją IPv6.

Długość nagłówka

Liczba 32-bitowych słów umieszczonych w nagłówku wraz z opcjami tworzy długość nagłówka. Typowa (minimalna) długość nagłówka wynosi 5. Liczba ta informuje komputer odbierający, kiedy ma zakończyć czytanie nagłówka i rozpocząć czytanie danych.

Całkowita długość pakietu

Wielkość ta, pomniejszona o rozmiar nagłówka wyznacza rozmiar pola danych enkanpsulowanych przez datagram. Jego teoretyczny rozmiar sięga, co prawda wartości 64kB, jednak w praktyce ze względu na ograniczenia interfejsów fizycznych długość datagramu nigdy nie przekracza wartości tzw. MTU (Maximum Transmission Unit), zaś w wielu przypadkach ze względu na różnice w wielkości największego dopuszczalnego pakietu konieczna jest segmentacja datagramu (podział na kilka pakietów).

Typ usługi TOS

W założeniach, protokół IP posiadać miał pewne elementy mechanizmów sterowania przepływem, których celem jest zapewnienie gradacji poziomu jakości usługi sieciowej (QoS). W tym celu pole TOS zawiera 3 bitowy wskaźnik priorytetu przesyłania pakietu oraz trzy flagi zalecanego doboru trasy, które mogą być używane do określania parametrów pierwszeństwa, opóźnienia, przepustowości i niezawodności tego pakietu. Niestety, obecne implementacje nie używają żadnego z tych pól (tzn. pola te są z reguły ustawiane, lecz elementy komutacyjne sieci – rutery ignorują je). Ponieważ transmitowanie informacji przez sieć odbywa się na poziomie sieciowym, utracono w ten sposób możliwość efektywnego i zestandardyzowanego sterowania przepływem na poziomie IP. Istniejące rozwiązania posługują się na ogół informacjami zasięgniętymi z nagłówka TCP w celu rozpoznania rodzaju przesyłanej usługi.

Znaczniki

Pole zawiera 3 bity. Pierwszy jest zawsze zerem. Drugi bit określa czy można (wartość 1), czy też nie można (wartość 0) fragmentować datagram. Natomiast ostatni bit służy do identyfikacji ostatniego fragmentu składającego się na pierwotny datagram. Wartość 0 określa ostatni, a wartość 1 oznacza kolejny fragment.

Przesunięcie fragmentacji

Pole to zawiera 13 bitów, wskazuje, którą częścią całości pierwotnego datagramu jest dany fragment. Poszczególne fragmenty mają pola danych o długości będącej wielokrotnością 8 bitów. Wyjątkiem jest ostatni fragment, którego długość wynika z długości pierwotnego datagramu. W polu tym podaje się o ile zawartość fragmentu jest przesunięta w stosunku do początku pola danych pierwotnego datagramu.

Opcje

To pole nagłówka o zmiennej długości w zamierzeniach autorów umożliwiało uzyskanie między innymi następujących funkcji:

  • ograniczenia dotyczące bezpieczeństwa;

  • zapisu trasy podróży przez sieć;

  • zapisu czasu wyjścia datagramu z danego węzła sieci (router);

  • ustalenie swobodnej trasy rutowania – lista węzłów przez które datagram musi przejść (pomiędzy nimi droga może być wybierana dowolnie);

  • ustalenie dokładnej trasy rutowania – datagram nie może przejść inną drogą niż wskazaną na liście.

Możliwości pola opcje otwierają pewną drogę do wsparcia zastosowań wymagających utrzymywania w miarę stałych i powtarzalnych parametrów opóźnień i przepustowości sieci. W praktyce jednak ze względu na powszechne ignorowanie tej opcji przez rutery oraz zbyt małą dopuszczalną długość tego pola w stosunku do ilości punktów przeskoku na typowej trasie połączenia internetowego, nie można wpływać na sposób przesyłania informacji.

2.3.2. Nagłówek IPv6

Proponowany protokół IPv6 zachowuje wiele cech, które przyczyniły się do sukcesu IPv4. W rzeczywistości konstruktorzy scharakteryzowali IPv6 jako IPv4 z kilkoma modyfikacjami.

Jak widać na rysunku 2.4. datagram IP ma nagłówek podstawowy o ustalonym rozmiarze, po którym następuje zero lub więcej nagłówków dodatkowych poprzedzających dane [38].

Rysunek 2.4. Ogólna postać datagramu IPv6 z wieloma nagłówkami

Format nagłówka podstawowego

Pomimo tego, że nagłówek podstawowy IPv6 musi obsługiwać większe adresy, to zawiera on mniej informacji niż nagłówek datagramu IPv4. Opcje i niektóre z ustalonych pól, które pojawiają się w nagłówku datagramu IPv4, zostały w IPv6 przeniesione do nagłówków dodatkowych. W ogólności zmiany w nagłówku datagramu odpowiadają zmianom w samym protokole [38]:

  • wyrównywanie do 32-bitów zostało zmienione na wyrównywanie do 64-bitów,

  • pole długości nagłówka zostało wyeliminowane, a pole długości datagramu zastąpiono polem długość zawartości,

  • rozmiar pól adresów nadawcy i odbiorcy został zwiększony do 16 oktetów,

  • informacje o fragmentacji zostały przeniesione z pól stałych w nagłówku podstawowym do nagłówka dodatkowego,

  • pole czas życia zostało zastąpione polem liczba etapów,

  • pole typ obsługi zastąpiono polem etykiety potoku,

  • pole protokół zostało zastąpione polem, które określa typ następnego nagłówka.

Na rysunku 2.5. są pokazane zawartość i format nagłówka podstawowego IPv6. Kilka pól tego nagłówka odpowiada bezpośrednio polom w nagłówku IPv4. Tak jak w IPv4, początkowe 4-bitowe pole wersja służy do określenia wersji protokołu w datagramie IPv6, zawiera ono zawsze 6. Podobnie jak w IPv4 pola adres nadawcy i adres odbiorcy zawierają adresy wysyłającego i odbierającego. Jednak w IPv6 na każdy z tych adresów zużywa się 16 oktetów. Pole liczba etapów odpowiada polu czas życia w IPv4. Inaczej niż IPv4, które traktuje czas życia jak kombinację liczby etapów oraz maksymalnego czasu podróży, IPv6 interpretuje tę wartość jako ścisłe ograniczenie maksymalnej liczby etapów, jaką może datagram wykonać zanim zostanie usunięty.

Rysunek 2.5. Format 40-oktetowego nagłówka podstawowego IPv6. Każdy datagram IPv6 rozpoczyna się od takiego nagłówka

IPv6 używa nowego sposobu specyfikacji długości datagramu. Po pierwsze, ponieważ rozmiar nagłówka podstawowego wynosi 40 oktetów, nie zawiera on pola odpowiedzialnego za długość nagłówka. Po drugie w IPv6 pole długości datagramu jest zastąpione 16-bitowym polem długość zawartości, które służy do określenia liczby oktetów przenoszonych w datagramie, nie licząc oktetów nagłówka. Dzięki temu datagram może zawierać 64 kilo-otetów danych.

IPv6 oferuje nowy mechanizm, który umożliwia rezerwację zasobów i pozwala ruterowi na wiązanie każdego datagramu z podaną rezerwacją zasobów. Wykorzystywane jest do tego pojęcie potoku oznaczające ścieżkę poprzez intersieć, na której pośrednie rutery gwarantują określoną jakość obsługi. Przykładowo dwa programy, które chcą przesyłać obrazy mogą ustanowić potok, w ramach, którego są gwarantowane określona przepustowość i opóźnienie. Alternatywnie usługodawca sieciowy może wymagać od swojego klienta, aby ten określił potrzebną mu jakość usługi, a następnie używać potoków do ograniczania ruchu generowanego przez dany komputer czy program użytkowy.

Pole etykieta potoku w nagłówku podstawowym zawiera informacje, których rutery używają do wiązania datagramu z odpowiednim potokiem informacji oraz priorytetem. Pole to jest podzielone na dwa podpola, które widać na rysunku 2.6.

Rysunek 2.6. Dwa podpola pola ”etykieta potoku”. Każdy datagram IPv6 zawiera etykietę potoku, która może być używana do wiązania datagramu z określonym rodzajem obsługi

W etykiecie potoku 4-bitowe pole klasa ruchu służy do określenia, jaką klasą ma podróżować datagram. Wartości od 0 do 7 są używane do określania wrażliwości na czasy dla ruchu kontrolowanego potokami, a wartości od 8 do 15 określają priorytet ruchu poza nimi. Pozostałe 24 bity zawierają identyfikator potoku.

Podsumowując, datagram IPv6 zaczyna się od 40-oktetowego nagłówka podstawowego, który zawiera pola adresów nadawcy i odbiorcy, maksymalnej liczby etapów, etykiety potoku oraz typu następnego nagłówka. Wobec tego datagram IPv6 oprócz danych musi zawierać, co najmniej 40 oktetów.

2.4. Protokół TCP (Transmission Control Protocol)

TCP jest protokołem działającym w warstwie transportowej, wykorzystując warstwę sieci IP dostarcza usług aplikacjom. Obecna wersja TCP jest oficjalnie zdefiniowana w RFC 793 [3], od tego czasu dodano wiele rozszerzeń, które udokumentowano w odpowiednich dokumentach RFC.

TCP zapewnia zorientowaną połączeniowo, niezawodną obsługę ciągów przesyłanych bajtów. Połączeniowość oznacza, że dwie aplikacje używające tego protokołu muszą przed rozpoczęciem wymiany danych nawiązać ze sobą połączenie [1].

Protokół TCP zapewnia niezawodność poprzez:

  • Dane przekazywane przez aplikację są dzielone na fragmenty, które według TCP mają najlepszy do przesłania rozmiar. Jest to podejście całkowicie inne niż w UDP, w którym datagram generowany był na podstawie przekazanego przez aplikację komunikatu. Jednostka informacji przekazywana przez TCP do IP nazywana jest segmentem.

  • Kiedy TCP wysyła segment, to jednocześnie uruchamia zegar, który rozpoczyna oczekiwanie na potwierdzenie odebrania segmentu przez drugą stronę. Jeśli potwierdzenie nie nadejdzie w określonym czasie, segment wysyłany jest powtórnie.

  • Kiedy TCP odbiera dane nadesłane przez drugą stronę połączenia, wysyła wtedy potwierdzenie odbioru. Potwierdzenie to nie jest wysyłane natychmiast, tylko po odczekaniu zwykle kilku sekund.

  • TCP posługuje się sumami kontrolnymi nagłówka datagramu i danych. Jest to suma typu end-to-end, której zadaniem jest wykrycie każdej modyfikacji danych w czasie ich przesyłania. Jeśli segment zostanie nadesłany z niepoprawną sumą kontrolną, TCP odrzuca go i nie potwierdza odbioru. (Spodziewa się, że wysyłający prześle go po raz kolejny, po odczekaniu założonego czasu).

  • Ponieważ segmenty TCP są przesyłane jako datagramy IP, które mogą być nadsyłane w dowolnej kolejności, to segmenty TCP również mogą nadchodzić w innej kolejności niż zostały wysłane. Strona odbierająca segmenty TCP porządkuje je, jeśli zachodzi taka konieczność, i przekazuje do aplikacji.

  • Ponieważ datagramy IP mogą być powielane, odbiorca TCP musi umieć odrzucić zdublowane dane.

  • Ponadto TCP zapewnia kontrolę przepływu. Każdy z końców połączenia TCP ma przestrzeń buforową o skończonej wielkości. Strona odbierająca TCP pozwala stronie nadającej na wysłanie tylko takiej ilości danych, która może być umieszczona w buforze odbiorcy. Taki mechanizm zapobiega przeładowaniu bufora w hoście wolnym przez datagramy wysyłane z hosta szybszego.

2.4.1. Nagłówek TCP

Dane TCP umieszczane są w datagramach IP w sposób pokazany na rysunku 2.7.

Rysunek 2.7. Enkapsulacja danych TCP w datagramie IP

Rysunek 2.8. Format nagłówka TCP

Znaczenie poszczególnych pól jest następujące[3]:

Numer portu źródłowego, docelowego

Pola te identyfikują aplikacje wysyłającą i odbierającą dane. Te dwie wielkości wraz adresami IP źródła i przeznaczenia umieszczonymi w nagłówku IP, jednoznacznie identyfikują każde połączenie. Kombinacja IP i numeru portu jest czasem nazywana gniazdem.

Numer sekwencyjny

Pole to zwiera numer sekwencyjny pierwszego bajtu danych w segmencie. Ta wartość określa pozycję segmentu w strumieniu bajtów. Podczas ustanawiania połączenia, jeśli bit SYN w polu znaczniki jest ustawiony na 1, w tym polu zawarty jest inicjujący numer sekwencyjny INS, od którego rozpoczyna numerację bajtów w połączeniu. Zatem pierwszy wysyłany bajt ma numer INS+1.

Numer potwierdzenia

Zawiera numer sekwencyjny następnego oczekiwanego bajtu po stronie odbiorczej. Jednocześnie jest to potwierdzenie poprawnego odbioru bajtów o numerach sekwencyjnych mniejszych od zawartego w tym polu. Potwierdzenia mówią nadawcy, ile bajtów danych zostało już poprawnie odebranych.

Długość nagłówka

Określa liczbę 32 bitowych słów w nagłówku segmentu TCP. Tym samym określone zostaje miejsce, w którym rozpoczynają się dane. Pole to ma określone znaczenie tylko wtedy, gdy bit ACK=1.

Bity znaczników

Pole to zawiera 6 flag 1 – bitowych :

  • URG – wskaźnik ważności pola wskaźnika przynaglającego;

  • ACK – wskaźnik ważności pola numer potwierdzenia;

  • PSH – odbiorca powinien jak najszybciej przesłać dane do aplikacji;

  • RST – restart połączenia;

  • SYN – synchronizacja numerów sekwencyjnych w celu inicjalizacji połączenia;

  • FIN – zakończenie wysyłania danych.

Rozmiar okna

Określa liczbę bajtów, jaką może jeszcze zaakceptować odbiorczy moduł TCP.

Suma kontrolna

Pole to jest 16 bitowym jedynkowym uzupełnieniem jedynkowo uzupełnionej sumy wszystkich 16 bitowych słów w segmencie. Ta suma kontrolna obejmuje zarówno nagłówek jak i dane.

Wskaźnik ważności

Brany pod uwagę przy ustawieniu bitu URG. Pole to zawiera numer sekwencyjny bajtu następującego po pilnych danych.

Opcje

Pole to ma długość zmienną będącą wielokrotnością 8 bitów. Dla protokołu TCP zdefiniowano trzy opcje: 0 – koniec listy opcji, 1 – brak działania, 2 – maksymalna długość segmentu.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *