SK Moduł 8
|
|
W module tym zostaną omówione protokoły warstwy transportowej stosu protokołów TCP/IP oraz pojęcia z nimi związane. |
|
W module poświęconym protokołowi IP wspomniane zostało, że jego głównym zadaniem jest przesyłanie pakietów w sposób skuteczny bez względu na nakład potrzebny do działania. Zostało również nadmienione, że kontrolą przesyłania tych pakietów zajmą się protokoły wyższych warstw modelu ISO/OSI.
Warstwa transportowa umożliwia logiczną komunikację pomiędzy aplikacjami, które zostały uruchomione na różnych hostach. Dzięki mechanizmom, które udostępniają protokoły tej warstwy, z punktu widzenia aplikacji komunikacja odbywa się tak jakby hosty były ze sobą bezpośrednio połączone. Oczywiście zadania przesyłania pakietów i ramek są realizowane przez protokoły niższych warstw, tak jak to zostało opisane we wcześniejszych modułach. W praktyce segmenty danych przesyłane są przez wiele pośrednich routerów.
|
|
Komunikację przy pomocy protokołów warstwy transportowej, pomiędzy odległymi hostami, można klasyfikować na różne sposoby.
Jednym z podziałów jest podział na komunikację połączeniową (ang. connection-oriented) oraz bezpołączeniową (ang. connectionless). Komunikacja połączeniowa zakłada, że zanim nastąpi właściwa wymiana informacji następuje etap połączenie (spotkania, nawiązania rozmowy, itd.), Dopiero po nawiązaniu połączenia możliwa jest dalsza komunikacja. Przez analogię do sytuacji z życia codziennego można to przybliżyć jako rozmowę pomiędzy dwoma osobami. Komunikacja bezpołączeniowa nie wymaga ustanawiania połączenia w celu przekazania informacji. Komunikaty są po prostu przesyłane bez sprawdzania, czy dotarły do adresata. Taki sposób komunikacji można porównać do przesyłania tradycyjnej poczty, gdzie zwykle nie wiemy, czy adresat jest w danej chwili w stanie odebrać wiadomość. Innym przykładem może być wysyłanie wiadomości SMS, czy też e-maila. |
|
Innym kryterium podziału jest wiarygodność dostarczenia informacji. Na podstawie tego kryterium dzieli się protokoły na niezawodne/wiarygodne (ang. reliable) oraz zawodne/niewiarygodne (ang. unreliable).
Protokoły niezawodne/wiarygodne zapewniają kontrolę procesu przesyłania i w razie problemów z niedostarczeniem segmentu ponawiają transmisję. W przypadku protokołów zawodnych/niewiarygodnych zagubione segmenty nie są retransmitowane ponownie w wyniku wykrycia błędu, bo nie kontrolują dostarczenia tych segmentów. Ewentualne powtórne wysłanie segmentu jest wynikiem działania wyższych warstw. |
|
Kolejnym kryterium podziału jest tryb komunikacji stanowej (ang. stateful) i bezstanowej (ang. stateless).
W przypadku komunikacji stanowej sesja nawiązana pomiędzy klientem a serwerem jest monitorowana przez serwer. Serwer utrzymuje na bieżąco stan klienta. Wymaga to dodatkowego nakładu. Komunikacja bezstanowa zakłada brak monitorowania przez serwer stanu klienta. Stąd serwer nie zapamiętuje, np. wcześniejszych odpowiedzi na żądania klienta i za każdym razem wysyła pełen zestaw danych. Takie podejście zakłada nawiązywania sesji przy każdym odpytywaniu serwera. Odpowiedzi, które zostaną wygenerowane przez serwer mogą nadchodzić w dowolnej kolejności mogą być również gubione w trakcie przesyłania. Stąd może to być trudne do zinterpretowania jeśli nie jest kontrolowany stan na bieżąco. Zaletą takiego rozwiązania jest mniejszy nakład związany z brakiem monitorowania przez serwer stanu klienta. |
|
W ramach stosu protokołów TCP/IP za transport danych odpowiadają protokoły TCP (ang. Transmission Control Protocol) oraz UDP (ang. User Datagram Protocol). Wykorzystują one protokoły warstw Internetowej i Aplikacji tak jak zostało to przedstawione na rysunku.
Cechą wspólną obu tych protokołów jest: dzielenie danych pochodzących/skierowanych z/do wyższych warstw wysyłanie segmentów z jednego urządzenia końcowego do innego Głównym zadaniem protokołów tej warstwy jest dzielenie danych przychodzących z wyższych warstw modelu na segmenty. Segmenty te następnie przesyłane są do protokołów niższych warstw. Wykorzystanie jednego z tych protokołów przez aplikacje jest zależne od tego czy dana aplikacja potrzebuje sterować przepływem wysyłanych segementów czy też ta funkcjonalność nie jest niezbędna do prawidłowego jej działania. |
|
W warstwie transportowej istnieje mechanizm określania, do której aplikacji adresowane są przesyłane przy pomocy protokołu IP pakiety. Zarówno protokół TCP jak i UDP dysponują niezależnymi numerami, które określają numer portu. Standardowe numery portów zostały określone w dokumencie RFC 1700. Szczegółowa numeracja portów zostanie omówiona w dalszej części wykładu. |
|
W trakcie przesyłanie danych przez sieć mogą być one kierowane do różnych aplikacji. W celu dokładnego rozróżnienia, wprowadzono strukturę programową określaną jako gniazdo (ang. socket).
Gniazdo definiuje zdefiniowane jest przez numer IP interfejsu oraz numer portu protokołu TCP lub UDP. |
|
Protokół UDP został zaprojektowany w celu dostarczania użytkownikowi mechanizmów do przesyłania datagramów pomiędzy programami użytkowymi. Podobnie jak protokół niższej warstwy (IP) nie nawiązuje on połączenia w trakcie wysyłanie danych.
Host wysyłający segment UDP nie uzyskuje informacji zwrotnej o tym, czy dane dotarły do adresata. W samym protokole UDP nie ma również mechanizmów pozwalających na kontrolę przepływu. W związku z tym, w przypadku, gdy host, do którego mają dotrzeć segmenty nie jest w stanie ich obsłużyć, nie ma możliwości przesłać stosownej informacji. Mechanizm taki został zaimplementowany w protokole TCP. Kontrolę przesyłania danych zajmuje się aplikacja korzystająca z TCP. |
|
przez protokoły i aplikacje, które wymagają szybkiego przesyłu. Kontrolą poprawności przesyłania danych w tych protokołach zajmują się wyższe warstwy modelu ISO/OSI.
Do aplikacji wykorzystujących protokół UDP należą aplikacje komunikacji multimedialnej. Wszelkie programy wykorzystujące wideokonferencje, przesyłanie strumieniowe dźwięku wykorzystują szybkość tego protokołu. Innymi standardowymi protokołami sieciowymi korzystającymi z UDP są: DNS oraz TFTP. |
|
Szybkość przesyłania segmentów UDP wynika z niewielkiej liczby pól (8 bajtów) w nagłówku oraz braku kontroli przepływu zaimplementowanej w tym protokole.
Protokół UDP wykorzystuje bardzo prosty format nagłówka, który został przedstawiony na rysunku. Znaczenie poszczególnych pól jest zgodne z ich opisem: port UDP nadawcy port UDP odbiorcy długość komunikatu UDP suma kontrolna UDP - pole to jest opcjonalne i nie wykorzystywane w przypadku aplikacji pracujących w LAN (wtedy wartość tego pola wynosi 0). W przypadku, gdy suma kontrolna jest wyliczana jest to wykonywane podobnie jak w przypadku protokołu IP. Dane w tym przypadku są dzielone na 16 bitowe fragmenty, dla których wyliczane jest uzupełnienie do 1. |
|
Protokół TCP został zaimplementowany przez Vintona Cerfa i Roberta Kahna. Zgodnie z założeniami protokół ten zapewnia wiarygodne przesyłanie danych pomiędzy dwoma hostami. Wykorzystywanych jest do tego kilka mechanizmów, takich jak: sumy kontrolne i numery sekwencyjne. Zagubione pakiety są ponownie retransmitowane.
Protokół TCP umożliwia kontrolę przeciążeń urządzeń znajdujących się pomiędzy komunikującymi się hostami. W przypadku, gdy następuje przeciążenie protokół TCP zmniejsza prędkość nadawania segmentów przez urządzenie nadawcze, Segmenty protokołu TCP są enkapsulowane w pakiety IP i przesyłane przy użyciu tego protokołu. Ze względu na właściwości IP polegające na przesyłaniu w sposób skuteczny pakietów wszelkimi możliwymi drogami, segmenty mogą dotrzeć do adresata w różnej kolejności. Mechanizm porządkowania segmentów umożliwia nadawanie im numerów sekwencyjnych, które następnie ułatwiają złożenie ponowne danych. Cenna właściwością protokołu TCP jest możliwość sterowania przepływem. Dzięki temu w sytuacji, gdy host docelowy lub łącze pozwala na szybszą transmisję następuje przesyłanie kilku segmentów w jednym pakiecie. W sytuacji odwrotnej, tzn. przy przeciążonym adresacie lub ograniczonej przepustowości łącza następuje zwolnienie transmisji poprzez przesyłanie mniejszej liczby segmentów lub pojedynczych segmentów. Protokół TCP dzieli dane pochodzące z wyższych warstw na porcje zwane segmentami. Segmenty te są później enkapsulowane w pakiety IP. Przy okazji dzielenia pakietów i przesyłania ich do niższej warstwy wyznaczana jest maksymalna wielkość segmentu - MSS (ang. Maximal Segment Size) Mechanizmy umożliwiające tego typu działania zostaną omówione szczegółowiej w dalszej części modułu. |
|
Nagłówek protokołu TCP jest o wiele dłuższy od nagłówka UDP i zawiera 20 bajtów przeznaczonych na pola. Część z tych pól ma podobną funkcję jak w przypadku protokołu UDP. Podobnie jak w tym ostatnim występują pola określające numery portów nadawcy i odbiorcy. Występuje również pole sumy kontrolnej. Znaczenie poszczególnych pól zostanie przedstawione poniżej:
Numer portu źródłowego - 16 b - numer portu Numer portu docelowego - 16 b - numer portu Numer sekwencyjny pakietu - 32b - pole określające pozycję strumienia danych przesyłanych w strumieniu Numer sekwencyjny potwierdzenia - 32 b - numer bajtu, który odbiorca spodziewa się otrzymać w następnej kolejności od nadawcy Długość nagłówka - 4b - długość nagłówka wyrażona w 32-bitowych słowach Pole zarezerwowane - 6b Flagi - 6b - pole zawiera bity znacznikowe, które mają następujące znaczenie: URG - flaga oznaczająca, że dane zostały określone jako „pilne” przez warstwę wyższą ACK - oznacza, że wartość w polu numeru sekwencyjnego jest obowiązująca. PSH - odbiorca powinien przesłać natychmiast dane do warstwy wyższej RST - połączenie w stanie zerowania SYN - nawiązanie połączenia i synchronizacja numerów początkowych FIN - zamknięcie połączenia. Koniec strumienia danych u nadawcy Rozmiar okna - 16b - informacja, którą wysyła odbiorca o ilości danych, które może przyjąć od nadawcy. Suma kontrolna - 16b - liczba umożliwiająca sprawdzenie, czy nie została naruszona integralność danych i nagłówka segmentu Ważność - jeśli w polu flagi jest wpisana wartość URG, to pole to określa miejsce, w którym kończą się pilne dane. Opcje (jeśli istnieją) - Pole wykorzystywane do negocjacji wartości MSS pomiędzy klientem a serwerem. Pole rzadko wykorzystywane Wypełnienie - pole służące do wypełnienia długości nagłówka do pełnych 32 bitowych słów. |
|
Przed przesłaniem danych pomiędzy dwoma hostami musi zostać nawiązane połączenie. Często host, który rozpoczyna połączenie nazywany jest klientem, zaś drugi host serwerem. W protokole TCP podobnie jak w trakcie rozmowy telefonicznej następuje na początku proces uzgadniania. Protokół TCP w odróżnieniu od wcześniej przedstawianych stosuje w tym celu mechanizm synchronizacji zwany uzgadnianiem trójetapowym (ang. three way handshake). W skład tego procesu wchodzą następujące fazy:
1) Klient inicjuje połączenie poprzez wysłanie segmentu z ustawioną flagą w SYN (=1). Ustawiona wartość pola SYN=1 oznacza, że hosty nie zostały jeszcze zsynchronizowane i segment ten jest żądaniem nawiązania połączenia. Jednocześnie wysyłany jest w tym samym segmencie numer sekwencyjny pakietu o wartości ‘x’ oraz rozmiar okna, który jest informacją dla serwera jakiej wielkości bufor został zarezerwowany (po stronie klienta) na segmenty przesyłane z serwera. |
|
2) Serwer odbiera pakiet. Po analizie flagi rozpoznaje, że jest to próba nawiązania połączenia. Serwer rejestruje zatem numer sekwencyjny ‘x’, przydziela dla tego połączenia bufory i zmienne stanu. Odpowiedź będzie zawierała oprócz ustawionego bitu flagi SYN również ustawiony bit flagi ACK. Ustawione bity flag sygnalizują, że będzie to początek konwersji zwrotnej. Serwer wysyła swój własny numer ‘y’ w polu numer sekwencyjny oraz w polu numer sekwencyjny potwierdzenia wysyła wartość ‘x+1’. Wartość wpisana w to ostatnie pole informuje klienta, którą następną porcję bajtów oczekuje serwer. Dodatkowo serwer wysyła rozmiar okna. Wielkość ta informuje klienta o rozmiarze bufora, który został zarezerwowany po stronie serwera na segmenty, które będą przesyłane od klienta. |
|
3) Klient odbiera segment inicjalizuje po swojej stronie bufor na segmenty pochodzące od serwera i na zmienne stanu tego połączenia. W ramach potwierdzenia odebrania segmentu od serwera wysyła pakiet z ustawioną wartością flagi ACK, wyzerowaną wartością pola SYN oraz w w polu następny numer sekwencyjny wpisywana jest wartość ‘y+1’. Oznacza to, że połączenie zostało nawiązane i teraz klient oczekuje od serwera porcji bajtów od numeru ‘y+1’. Wartość SYN=0 oznacza, że połączenie zostało nawiązane i nastąpiła synchronizacja.
Po nawiązania we wszystkich przesyłanych segmentach jest ustawiona flaga ACK, która potwierdza fakt otrzymania porcji danych określonej w polu numer sekwencyjny. Mechanizm nawiązywania połączenia TCP bywa również nadużywany przez szkodliwe programy genrujące ataki typu DoS (ang. Denial of Service). Szczegóły tego typu działalności zostaną krótko omówione w dalszej części modułu. |
|
W trakcie nawiązywania połączenia ustalane są parametry odpowiedzialne za zapewnienie jakości usług - QoS (ang. Quality of Service). Proces ten określany jest jako negocjacja opcji. Poszczególne parametry mają następujące znaczenie:
- Opóźnienie nawiązania połączenia (ang. connection establishment delay) - czas pomiędzy wysłaniem segmentu z ustawioną flagą SYN a otrzymaniem potwierdzenia w postaci segmentu z ustawionymi flagami SYN+ACK. Im krótszy czas tym lepsza jakość usługi. - Prawdopodobieństwo niepowodzenia nawiązania połączenia (ang. connection establishment failure probability) - prawdopodobieństwo, że nie uda się nawiązać połączenia w trakcie dopuszczalnego maksymalnego czasu opóźnienia nawiązania połączenia. Przepustowość (ang. throughput) - liczba danych przesłanych w ciągu sekundy. Parametr mierzony oddzielnie dla każdego kierunku transmisji Opóźnienie przejścia (ang. transit delay) - czas potrzebny do przesłania segmentu pomiędzy nadawcą a adresatem. Czas ten jest określany dla obu kieunków transmisji. Stopa błędów (ang. residual error rate) - stosunek liczby utraconych lub zniekształconych segmentów do całkowitej liczby przesłanych segmentów w jednostce czasu. Prawdopodobieństwo niepowodzenia przesyłu (ang. transfer failure probability) - prawdopodobieństwo, że założone parametry: przepustowość, stopa błędów, opóźnienie przejścia nie zostaną uzyskane w trakcie obserwacji. |
|
Opóźnienie zwolnienia połączenia (ang. connection release delay) - czas pomiędzy wysłaniem segmentu zwalniajacego połączenia, a faktycznym zwolnieniem tego połączenia
Prawdopodobieństwo niepowodzenia zwolnienia połączenia (ang. connection release failure probability) - prawdopodobieństwo, że połączenie nie zostanie zwolnione w określonym czasie Ochrona (ang. protection) - ochrona przed przechwyceniem danych przez osoby trzecie Priorytet (ang. priority) - możliwość obsługi połączeń o wysokim priorytecie Odpornosc (ang. resilience) - prawdopodobieństwo przerwania połączenia w wyniku przeciążenia lub problemów wewnętrznych. |
|
W trakcie nawiązywania połączenia TCP ustalane są również zmienne stanu, które określają podstawowe parametry połączenia. Część z nich została przedstawiona na slajdzie.
Zmienna dopuszczalna liczba niepotwierdzonych segmentów określa maksymalną liczbę segmentów, które mogą być wysłane przez host bez uzyskania potwierdzenia, że zostały odebrane przez adresata. Zmienna maksymalny ruch sieciowy określa jaki może zostać wysłany przez połączenie TCP. |
|
|
|
Po nawiązaniu połączeniu i wykonaniu procesu synchronizacji następuje przesyłanie segmentów danych. Teoretycznie połączenie TCP jest połączeniem symetrycznym, które może pracować w trybie full-duplexu. W praktyce jednak, dane są przesyłane w jednym kierunku, natomiast w drugą stronę tylko potwierdzenia braku błędów.
Jak widać na przedstawionym rysunku dane mogą być transmitowane segmentami i po każdym przesłanym segmencie następuje wysłanie segmentu z potwierdzenie poprawnej transmisji. Ze względu na fakt, że dane z warstwy aplikacji zajmują zwykle więcej niż jeden segment i zostały podzielone w warstwie transportowej na większą liczbę segmentów, takie przesyłanie i oczekiwanie na potwierdzenie nie będzie efektywne. W celu poprawy efektywności stosuje się w tym celu mechanizm buforowania i przesuwanego okna (ang. sliding window). Sposoby te zostaną przedstawione na kolejnych slajdach. |
|
W trakcie nawiązywania połączenia TCP ustalane są wielkości buforów do przechowywania segmentów TCP zarówno po stronie klienta jak i serwera. Oba hosty będą miały oddzielnie zaimplementowane bufory. Dzięki temu, że wielkość ich została ustalona w procesie inicjacji warstwa transportowa wie w jaki sposób należy sterować przepływem danych. |
|
Przy pojedynczym wysyłaniu segmentów otrzymanie każdego z nich musi zostać potwierdzone przez adresata. Do tego czasu nadawca czeka z wysłaniem kolejnych segmentów. Nie jest to efektywne pod względem czasu potrzebnego na przesłanie wszystkich danych.
W celu poprawienia transmisji został zaproponowany algorytm przesuwanego okna (ang. sliding window). Zamiast wysyłać pojedyncze segmenty i czekać na potwierdzenie otrzymania każdego z nich przed wysłaniem następnego, host wysyła tyle segmentów ile wynosi parametr długość okna przesłany przez odległy komputer. Następnie czeka na potwierdzenie otrzymania przez host docelowy otrzymania przesłanych segmentów. Host, do którego były adresowane przesyłane segmenty odpowiada wysłaniem segmentu pozwalającego na dalszą transmisję. Szczegółowo mechanizm przesuwanego okna zostanie omówiony na następnym slajdzie.
|
