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.
W praktyce routery, których zadaniem jest przesyłanie pakietów sprawdzają tylko nagłówki warstwy sieciowej (L3) i nie przetwarzają pól związanych z wysyłanymi segmentami.
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.
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.
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.
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 segmentów czy też ta funkcjonalność nie jest niezbędna do prawidłowego jej działania.
Gniazdo definiuje zdefiniowane jest przez numer IP interfejsu oraz numer portu protokołu TCP lub UDP.
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.
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.
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 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ą ponowne złożenie danych.
Cenną 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.
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.
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.
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.
- 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.
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 Odporność (ang. resilience) - prawdopodobieństwo przerwania połączenia w wyniku przeciążenia lub problemów wewnętrznych.
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.
Jak widać na przedstawionym rysunku dane mogą być transmitowane segmentami i po każdym przesłanym segmencie następuje wysłanie segmentu z potwierdzeniem 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 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.
I tak jak dotrze do nadawcy potwierdzenie o dotarciu pierwszego segmentu do adresata, to okno zostanie przesunięte o jedną pozycję w prawo. Po przesunięciu okna w prawo o jedną pozycję wysyłany jest kolejny segment, w tym przypadku 9. Podobnie będzie się realizowała procedura dla pozostałych segmentów.
Gdyby się okazało, że nadeszły potwierdzenia otrzymania segmentów 2, 4,5,6,7,8,9, a nie nadeszło potwierdzenie otrzymania segmentu 3, to okno zostanie przesunięte tylko do początku segmentu 3. Wbudowane mechanizmy kontroli przesyłu zadbają o retransmisję zagubionego okna po upływie określonego czasu. Dla każdego niepotwierdzonego segmentu utrzymywany jest osobny zegar. Po upływie określonego czasu ponawiana jest transmisja zagubionego segmentu.
Podobne okno jest również zaimplementowane w protokole TCP po stronie odbiorcy.
segmenty na lewo od okna - to te, które zostały już przesłane. segmenty wewnątrz okna - to te, które są przesyłane i oczekuje się na potwierdzenie ich przesłania. segmenty na prawo od okna - to te, które dopiero będą wysyłane.
Inny przypadek zmniejszenia rozmiaru okna hosta nadającego ma miejsce, gdy z powodu przeciążenia sieci część pakietów nie dociera na czas do adresata. Nadawca kontroluje czas, który upłynął od wysłania segmentu do otrzymania potwierdzenia, że segment ten dotarł do adresata. Po przekroczeniu czasu segment jest wysyłany ponownie. Przy dużej liczbie retransmisji nadawca automatycznie zmniejsza rozmiar okna do wielkości okna przeciążenia (ang. congestion window). Mechanizm ten określany jest jako kontrola przeciążeń i działa następująco: w przypadku utraty segmentu wielkość okna jest redukowana o połowę. przy dalszych stratach rozmiar okna jest zmniejszany wykładniczo. gdy straty nadal występują przesyłane są tylko pojedyncze segmenty, a czas oczekiwania przed ponowną transmisją jest podwajany.
Algorytm ten polega na zwiększaniu rozmiaru okna o jeden segment po każdym otrzymanym potwierdzeniu przesłania poprzedniego okna. Algorytm ten jest stosowany po nawiązaniu połączenia oraz po wystąpieniu przeciążenia dla istniejącej sesji.
Atak taki polega na zalewaniu (ang. flooding) serwera specjalnie spreparowanym segmentami w celu nawiązania połączenia. Jest to wykonywane przez jeden host (lub grupę hostów). Wysyłane masowo pakiety zawierają segment z ustawionym bitem SYN, ale adres IP źródła jest generowany automatycznie (nie jest to adres hosta wysyłającego pakiety). Serwer próbuje odpowiedzieć na te żądania wysyłając segmenty SYN,ACK i czekając na potwierdzenie od fałszywego klienta. W ten sposób wyczerpuje jednocześnie zasoby przeznaczone dla prawdziwych klientów.
Jednym ze sposobów zmniejszenia uciążliwości takiego typu działalności intruzów jest zmniejszenie czasu oczekiwanie na potwierdzenie i zwiększenie długości bufora przeznaczonego na kolejką połączeń.