4 Warstwa transportowa modelu OSI

4.0 Wprowadzenie

4.0.1 Wprowadzenie

Strona 1:

Sieci komputerowe oraz Internet wspomagają rozwój relacji międzyludzkich dostarczając niezawodnych usług komunikacyjnych - zarówno lokalnie jak i wokół całego globu. Wykorzystując jedno urządzenie ludzie mogą korzystać z wielu usług (np. poczta elektroniczna, przeglądanie stron WWW czy komunikatory) do wysyłania i odbierania różnych informacji. Aplikacje takie jak np. klienci poczty elektronicznej, przeglądarki stron i komunikatory pozwalają ludziom używać komputerów i sieci do wysyłania wiadomości i poszukiwania informacji.

Dane z każdej z tych aplikacji są pakowane, transportowane i dostarczane do odpowiednich usług serwera lub aplikacji na docelowym urządzeniu. Procesy opisane w warstwie transportowej OSI przyjmują dane z warstwy aplikacji i przygotowują je do adresowania w warstwie sieci. Warstwa transportowa jest odpowiedzialna za całość transferu danych pomiędzy aplikacjami.

W tym rozdziale poznamy rolę warstwy transportowej w procesie enkapsulacji danych i przygotowaniu ich dla warstwy sieci. Warstwa transportowa obejmuje również następujące funkcje:

• Umożliwia jednoczesną komunikację poprzez sieć wielu aplikacjom uruchomionym na tym samym urządzeniu.

• Zapewnia (jeśli jest to wymagane), że wszystkie dane są dostarczone w sposób niezawodny, w dobrej kolejności i do odpowiedniej aplikacji.

• Używa mechanizmów obsługi błędów.

Cele nauczania

Po zakończeniu tego rozdziału będziesz potrafił:

• Wyjaśnić konieczność istnienia warstwy transportowej.

• Zidentyfikować rolę warstwy transportowej jako warstwy zapewniającej przesyłanie danych pomiędzy aplikacjami.

• Opisać role dwóch protokołów warstwy transportowej TCP/IP: TCP i UDP.

• Wyjaśnić najważniejsze funkcje warstwy transportowej, w tym: niezawodność, numerację portów oraz segmentację.

• Wyjaśnić w jaki sposób TCP i UDP obsługują kluczowe funkcje.

• Wskazać, kiedy odpowiedniejsze jest użycie protokołu TCP a kiedy UDP. Podać przykłady aplikacji, które używają każdego z tych protokołów.

4.1 Rola warstwy transportowej

4.1.1 Cele warstwy transportowej

Strona 1:

Warstwa transportowa zapewnia segmentację danych i konieczną kontrolę nad składaniem poszczególnych części w różne strumienie komunikacyjne. Dokonuje ona tego poprzez:

• śledzenie indywidualnej komunikacji pomiędzy aplikacjami na źródłowym i docelowym hoście,

• segmentację danych i odpowiednie oznaczanie każdego fragmentu,

• łączenie podzielonych segmentów w strumienie danych,

• identyfikację różnych aplikacji.

Śledzenie indywidualnych konwersacji

Każdy host może mieć uruchomionych wiele aplikacji komunikujących się za pomocą sieci. Każda z tych aplikacji będzie komunikować się z jedną lub kilkoma aplikacjami na zdalnych hostach. Warstwa transportowa umożliwia istnienie wielu strumieni komunikacyjnych pomiędzy tymi aplikacjami.

Segmentowanie danych

Każda aplikacja tworzy strumienie danych do przesłania. Dane te muszą zostać przygotowane do wysłania poprzez medium w możliwych do zarządzania częściach. Warstwa transportowa określa sposób segmentacji danych pochodzących z warstwy aplikacji oraz enkapsulację wymaganą dla każdej porcji danych. Każda porcja danych wymaga dodania w warstwie transportowej odpowiedniego nagłówka, dzięki któremu wiadomo z jakim strumieniem komunikacji jest ona związana.

Scalanie segmentów

Host odbiorczy kieruje każdy kawałek z docierających do niego danych do odpowiedniej swojej aplikacji. Dodatkowo, te pojedyncze kawałki danych muszą zostać scalone w kompletny strumień danych, który teraz może zostać użyty przez warstwę aplikacji. Protokoły w warstwie transportowej opisują, w jaki sposób informacja z nagłówka tej warstwy jest użyta do scalenia kawałków danych w strumienie przekazywane do warstwy aplikacji.

Identyfikowanie aplikacji

W celu przekazania strumieni danych do właściwych aplikacji, warstwa transportowa musi każdą z tych aplikacji odpowiednio zidentyfikować. By tego dokonać, warstwa transportowa przydziela aplikacji identyfikator. W TCP/IP taki identyfikator to numer portu. Każdemu procesowi lub programowi, który chce skorzystać z dostępu do sieci przypisany zostaje unikalny numer portu. Ten numer portu zostanie użyty w nagłówku warstwy transportowej w celu wskazania, do której aplikacji należy ten fragment.

Warstwa transportowa służy także jako łącznik pomiędzy warstwą aplikacji a warstwą leżącą poniżej, odpowiedzialną za transmisję w sieci. Ta warstwa przyjmuje dane należące do różnych konwersacji i przekazuje je w dół do kolejnych warstw już jako porcje danych, które mogą zostać przesłane za pomocą medium.

Oznacza to, iż aplikacje nie muszą znać szczegółów dotyczących działania sieci. Aplikacje generują dane przeznaczone dla drugiej strony konwersacji. Dokonują tego bez zwracania uwagi na typ hosta docelowego, medium, ścieżkę po których będą przepływać dane, ewentualne przeciążenia na łączu ani rozmiar sieci.

Oprócz tego, niższe warstwy nie wiedzą nawet o ilości różnych aplikacji, których dane przesyłają. Ich zadaniem jest dostarczenie danych do odpowiedniego urządzenia. To warstwa transportowa zajmie się teraz rozdziałem porcji danych, przed dostarczeniem ich do odpowiednich aplikacji.

Różnorodność wymagań

Ze względu na różnorodność wymagań poszczególnych aplikacji, istnieją różne protokoły warstwy aplikacji. Dla prawidłowego działania niektórych aplikacji, segmenty muszą docierać w bardzo specyficznie określonej kolejności. W niektórych przypadkach, wszystkie dane muszą zostać odebrane w komplecie, by były zdatne do dalszego użytku. Za to w innych, aplikacja może tolerować utratę części transmitowanych danych.

W dzisiejszych konwergentnych sieciach, aplikacje z różnymi potrzebami transportowymi korzystać mogą z tej samej sieci. Różne protokoły warstwy transportowej mają różne zasady, pozwalając urządzeniom obsługiwać te różnorodne wymagania.

Niektóre protokoły udostępniają jedynie podstawowe funkcje, pozwalając na efektywne dostarczanie porcji danych do aplikacji. Taki typ protokołów przydaje się szczególnie aplikacjom, które są wrażliwe na opóźnienia.

Inne protokoły warstwy transportowej definiują procesy dostarczające dodatkowych możliwości, jak niezawodne dostarczanie danych do aplikacji. Te dodatkowe funkcje zapewniają co prawda poprawniejszą komunikację pomiędzy aplikacjami, lecz jednocześnie wnoszą dodatkowy narzut i mają większe wymagania co do sieci.

Strona 2:

Separacja strumieni komunikacji

Wyobraźmy sobie komputer podłączony do sieci, który jednocześnie odbiera i wysyła pocztę elektroniczną, obsługuje komunikatory internetowe, ściąga zawartość stron WWW oraz obsługuje rozmowę telefonii VoIP. Każda z tych aplikacji wysyła i odbiera dane z sieci w tym samym momencie. Jednakże dane z rozmowy telefonicznej nie są kierowane do przeglądarki stron, a tekst z komunikatora nie pojawia się w e-mailu.

Co więcej, użytkownik wymaga by e-mail i strona WWW zostały odebrane i przedstawione w całości, inaczej będą bezużyteczne. Niewielkie opóźnienia są w pełni akceptowalne, ważna jest kompletność odbieranych danych.

Z drugiej strony, zagubienie drobnych fragmentów telefonicznej konwersacji może nawet zostać niezauważone. Jeśli nawet, to można przecież domyślić się brakującego fragmentu z kontekstu rozmowy lub poprosić swego rozmówcę o powtórzenie zdania. Wydaje się to lepszym rozwiązaniem niż wprowadzanie dodatkowych opóźnień jakie wnosiłaby ewentualna retransmisja zagubionych segmentów. W powyższym przykładzie to użytkownik, a nie sieć, zarządza retransmisją brakującej informacji.

Strona 3:

Jak wyjaśniono w poprzednim rozdziale, przesył niektórych typów danych, np. video, jako jeden ciągły strumień komunikacyjny, mógłby zupełnie uniemożliwić dokonywanie innych transmisji odbywających się w tym samym czasie. Utrudnione byłoby także naprawianie błędów czy retransmisja uszkodzonych danych.

Dzielenie danych na mniejsze części, które są przesyłane pomiędzy hostami, pozwala wielu aplikacjom na równoczesną pracę w sieci (multipleksacja).

Segmentacja danych, w odniesieniu do protokołów warstwy transportowej, umożliwia jednoczesne otrzymywanie i wysyłanie danych w przypadku korzystania z kilku aplikacji jednocześnie (na jednym komputerze). Bez segmentacji tylko jedna aplikacja, np. video mogłaby odbierać dane. Nie możliwe byłoby w międzyczasie odbieranie e-maili, rozmawianie przez komunikator, czy przeglądanie stron WWW.

W warstwie transportowej, każdy taki zestaw danych płynących pomiędzy aplikacjami nazywa się konwersacją.

By zidentyfikować każdy segment danych, warstwa transportowa dodaje nagłówek zawierający dane binarne. Ten nagłówek zawiera pola bitów. To wartości w tych polach pozwalają różnym protokołom transportowym wykonywać różne funkcje.

4.1.2 Sterowanie konwersacjami

Strona 1:

Głównymi funkcjami spełnianymi przez wszystkie protokoły warstwy transportowej są:

Segmentacja i scalanie - większość sieci ma określone maksymalne ilości danych, które mogą być umieszczane w jednym segmencie (PDU warstwy transportowej). Na hoście źródłowym warstwa transportowa dzieli dane otrzymane od aplikacji na bloki o odpowiednim rozmiarze. Na hoście docelowym następuje proces odwrotny, a zatem warstwa transportowa scala dane przed przekazaniem ich do odpowiedniej aplikacji lub usługi.

Mulitpleksowanie komunikacji - każdy host w sieci może mieć uruchomionych jednocześnie wiele aplikacji. Każda z tych aplikacji czy usług ma przyporządkowany adres nazywany portem, aby warstwa aplikacji mogła ustalić do kogo skierować otrzymane dane.

W uzupełnieniu podstawowych funkcji segmentacji i scalania danych, niektóre protokoły transportowe zapewniają następujące funkcje:

• Konwersacja zorientowana połączeniowo.

• Niezawodność dostarczania danych.

• Dostarczanie w odpowiedniej kolejności.

• Kontrola przepływu.

Strona 2:

Ustanawianie sesji

Warstwa transportowa w celu zapewnienia usługi zorientowanej połączeniowo nawiązuje sesję pomiędzy aplikacjami. Takie nawiązywanie sesji przygotowuje obie strony konwersacji zanim jakiekolwiek dane zostaną przesłane. W takiej sesji łatwo jest zarządzać przepływem danych pomiędzy aplikacjami.

Niezawodność dostarczania danych

Ze względu na różne czynniki możliwe jest, że podczas transmisji w sieci porcja danych ulegnie uszkodzeniu lub całkowitemu zagubieniu. Warstwa transportowa może zapewnić, że wszystkie kawałki zostaną prawidłowo dostarczone, dokonując retransmisji brakujących lub uszkodzonych fragmentów.

Dostarczanie w odpowiedniej kolejności

W związku z tym, że w sieci dwa różne fragmenty tej samej transmisji mogą zostać transportowane różnymi drogami, różnić się mogą czasy transmisji. Fragmenty danych mogą dotrzeć zatem w złej kolejności. Dzięki numerowaniu i sekwencjonowaniu warstwa transportowa może zapewnić, że dane zostaną scalone w odpowiedniej kolejności.

Kontrola przepływu

Hosty sieciowe mają ograniczone zasoby, takie jak pamięć czy przepustowość. Kiedy warstwa transportowa zauważa, że te zasoby są na wyczerpaniu może za pomocą pewnych protokołów zażądać, by wysyłająca aplikacja zmniejszyła prędkość nadawania. Dzieje się to poprzez regulację ilości danych jakie źródło może wysłać do hosta docelowego.

Podczas omawiania protokołów, usługi te zostaną omówione bardziej szczegółowo.

4.1.3 Zapewnienie niezawodnej komunikacji

Strona 1:

Jako główną funkcję warstwy transportowej wskazane zostało zarządzanie danymi konwersacji pomiędzy hostami. Różne aplikacje mają różne wymagania w stosunku do swoich danych. W związku z tym, aby spełnić te zróżnicowane wymagania powstały różne protokoły transportowe.

Jeden z protokołów warstwy transportowej może zapewnić niezawodne dostarczanie danych. W terminologii dotyczącej sieci, niezawodność lub gwarantowanie dostarczania danych oznacza zapewnienie, że każdy wysłany segment dotrze do odbiorcy. W warstwie transportowej występują następujące podstawowe operacje związane z zapewnianiem dostarczania:

• śledzenie transmitowanych danych,

• potwierdzanie odbioru danych,

• retransmisja niepotwierdzonych danych.

Narzuca to wymóg, aby procesy warstwy transportowej w źródle śledziły każdą porcję danych każdej konwersacji i retransmitowały dane, które nie zostały potwierdzone przez host docelowy. Jednocześnie warstwa transportowa hosta odbierającego także musi śledzić odbierane dane i na bieżąco potwierdzać ich odbiór.

Procesy te wnoszą dodatkowy narzut na zasoby sieciowe ze względu na konieczność wysyłania potwierdzeń, śledzenia transmisji oraz dokonywania retransmisji. Zatem w celu zapewnienia poprawnego sposobu działania tych procesów wymagane jest zwiększenie ilości danych kontrolnych wymienianych pomiędzy hostami. Dane sterujące zawarte są w nagłówku warstwy 4.

Powyższe rozumowanie pokazuje jak konieczność uzyskania gwarancji wpływa na dodatkowe obciążenie sieci. Zatem twórcy aplikacji muszą wybrać, który protokół transportowy będzie bardziej przydatny dla ich aplikacji. W warstwie transportowej, są protokoły stosujące zarówno metody gwarantowanego dostarczania danych jak i dostarczania niepewnego (ang. best-effort). W kontekście sieciowym dostarczanie nazywane niepewnym lub "przy użyciu dostępnych środków" (ang. best-effort) odbywa się, gdy protokół nie wysyła potwierdzenia dostarczenia.

Określanie potrzeby pewności dostarczania

Aplikacje takie jak bazy danych, strony WWW i e-mail wymagają, by wszystkie wysłane dane dotarły do celu w stanie nienaruszonym, inaczej stają się bezużyteczne. Jakikolwiek brakujący fragment mógłby spowodować, że zmieni się sens przesyłanej wiadomości lub stanie się ona nieczytelna. Tym samym aplikacje te zostały zaprojektowane, by używać protokołu transportowego, który jest w stanie zagwarantować taką nienaruszalność. Oznacza to, iż dla tych aplikacji wymagany jest dodatkowy narzut w sieci.

Inne aplikacje mogą być bardziej tolerancyjne dla straty małych ilości danych. Dla przykładu, jeśli jeden lub dwa segmenty transmisji video nie dotrą do celu, spowoduje to jedynie niewielkie zakłócenie w transmisji. Może ono wyglądać na niewielkie zakłócenie obrazu, ale może nawet pozostać zupełnie niezauważone przez odbiorcę.

Wprowadzanie dodatkowego narzutu w celu zapewnienia gwarancji odniosłoby odwrotny skutek dla takich aplikacji. Obraz w transmisji video mógłby zostać mocno zakłócony lub zatrzymany, gdyby host odbierający musiałby czekać na retransmisję zagubionych danych. Lepiej, by aplikacja tworzyła obraz w miarę możliwości najlepszy z segmentów jakie w ogóle docierają, niż by zajmowała się gwarancjami dostarczania. Jeśli z jakichś powodów wymagana jest niezawodność, aplikacje te mogą same prowadzić kontrolę błędów lub żądać retransmisji danych.

4.1.4 TCP i UDP

Strona 1:

Dwa najpopularniejsze protokoły warstwy transportowej modelu TCP/IP to TCP (ang. Transmission Control Protocol) i UDP (ang. User Datagram Protocol). Oba te protokoły są w stanie zarządzać wieloma równoczesnymi transmisjami. Różnią się zestawem funkcji jakie mogą dostarczyć aplikacjom.

Protokół UDP

UDP jest prostym, bezpołączeniowym protokołem, opisanym w RFC 768. Jego zaletą jest niewielki narzut dodawany do dostarczanych danych. Porcje danych UDP są nazywane datagramami. Datagramy te wysyłane są za pomocą tego protokołu "przy użyciu dostępnych środków" (ang. best-effort).

Aplikacje, które używają protokołu UDP to m.in.:

• system nazw domenowych DNS (ang. Domain Name System),

• aplikacje przesyłające strumienie Video,

• transmisja głosu przez sieć IP (VoIP).

Protokół TCP

TCP jest zorientowanym-połączeniowo protokołem, opisanym w RFC 793. TCP wprowadza pewien dodatkowy narzut, ze względu na większą liczbę realizowanych funkcji. Dodatkowe funkcje TCP to dostaczanie we właściwej kolejności, niezawodne dostarczanie i kontrola przepływu. Każdy segment TCP dodaje aż 20 dodatkowych bajtów w nagłówku, gdzie datagram UDP dodaje tylko 8 dodatkowych bajtów. Dla porównania przeanalizuj zamieszczony schemat.

Aplikacje wykorzystujące protokół TCP to:

• przeglądarki stron WWW,

• e-mail,

• programy do przesyłania plików.

4.1.5 Adresacja portów

Strona 1:

Identyfikacja konwersacji

Przypomnijmy sobie poprzedni przykład z komputerem równocześnie odbierającym i wysyłającym pocztę elektroniczną, obsługującym komunikator, ściągającym stronę WWW i obsługującym rozmowę VoIP.

Dzięki usługom TCP i UDP hosty są w stanie śledzić na bieżąco te aplikacje. By rozróżniać segmenty i datagramy każdej z aplikacji, zarówno TCP jak i UDP mają w nagłówkach pola, dzięki którym można jednoznacznie zidentyfikować te aplikacje. Te unikalne identyfikatory to numery portów.

W nagłówku każdego segmentu czy datagramu, znajduje się numer portu źródłowego i numer portu docelowego. Numer portu źródłowego jest powiązany z aplikacją, która wysłała te dane. Port docelowy wskazuje do jakiej aplikacji mają trafić dane na hoście docelowym.

Numery portów mogą być przypisane na różne sposoby, w zależności czy dana wiadomość to zapytanie czy odpowiedź. Serwery posiadają statyczne numery portów przypisane do aplikacji, z kolei klienci dynamicznie wybierają porty dla każdej konwersacji.

Kiedy aplikacja kliencka wysyła żądanie do aplikacji serwera, port docelowy w nagłówku to numer portu jaki przypisany jest na serwerze do tej właśnie nasłuchującej aplikacji (tzw. demona). Oprogramowanie klienckie musi wiedzieć jaki numer portu przypisany jest procesowi serwerowemu na zdalnym hoście. Docelowy numer portu może być skonfigurowany domyślnie lub zostać zmieniony przez administratora systemu. Dla przykładu, kiedy przeglądarka WWW wysyła zapytanie do serwera, używa TCP i portu o numerze 80, chyba że inny port został wprowadzony przez użytkownika. Port 80 protokołu TCP jest domyślnym portem przypisanym aplikacjom WWW. Wiele aplikacji ma przypisane domyślne numery portów.

Port źródłowy w nagłówku segmentu lub datagramu jest wybierany losowo. Klient może wybrać dowolny numer portu pod warunkiem, że nie pokrywa się on z innym portem używanym w systemie. Ten port staje się niejako zwrotnym adresem dla aplikacji klienckiej. Warstwa transportowa śledzi na bieżąco ten port i aplikację, która go zainicjowała, więc kiedy do hosta dotrze odpowiedź, zostanie ona przekazana do właściwej aplikacji. Numer portu aplikacji klienckiej będzie użyty jako numer portu docelowego w odpowiedzi nadchodzącej od serwera.

Połączenie numeru portu i adresu IP jednoznacznie identyfikuje konkretny proces na konkretnym urządzeniu. Taka kombinacja zwana jest gniazdem (ang. socket). Czasem zdarza się, że terminy numer portu i gniazdo używane są wymiennie. W tym kursie określenie gniazdo odnosić się będzie do pary: adres IP i numer portu. Para gniazd składająca się ze źródłowych i docelowych adresów IP i numerów portów identyfikuje jednoznacznie konkretną konwersację pomiędzy hostami.

Dla przykładu, zapytanie HTTP wysyłane do serwera WWW (port 80) uruchomionego na hoście o adresie IPv4: 192.168.1.20, będzie skierowane do gniazda 192.168.1.20:80.

Jeśli teraz przeglądarka WWW jest uruchomiona na hoście 192.168.100.48 a dynamicznie przypisany temu zapytaniu port to 49152, gniazdo dla tej strony to: 192.168.100.48:49152.

Strona 2:

Organizacja IANA (ang. Internet Assigned Numbers Authority) przydziela usługom domyślne numery portów. IANA jest ciałem standaryzacyjnym odpowiedzialnym za nazwy domenowe domen pierwszego rzędu, koordynuje przydzielanie adresów IP i numerów autonomicznych oraz nazwami i numerami portów.

Istnieją następujące typy numerów portów:

Dobrze znane porty (numery od 0 do 1023) - te numery są zarezerwowane dla usług i aplikacji. Są one powszechnie używane dla aplikacji takich jak serwery WWW (HTTP), serwery poczty elektronicznej (POP3/SMTP) i serwery telnet. Przez zdefiniowanie tych "dobrze znanych portów" dla aplikacji serwerowych, aplikacje klienckie mogą być zaprogramowane do żądania komunikacji z usługą oczekującą na tych portach.

Zarejestrowane porty (numery od 1024 do 49151) - te numery są zarezerwowane dla aplikacji i procesów użytkownika. Są to przede wszystkim porty używane przez aplikacje i usługi tworzone na małą skalę. Te bardziej powszechne, otrzymują numery z dobrze znanych portów. Kiedy nie są używane jako zasoby serwera, porty te mogą być używane jako dynamicznie wybierane przez klienta jako port źródłowy.

Dynamiczne lub prywatne numery portów numery (od 49152 do 65535) - znane również pod nazwą "ephemeral ports", to numery portów, które są dynamicznie losowane przez aplikacje klienckie podczas inicjowania połączeń. Nie jest powszechnie stosowanym rozwiązaniem, aby aplikacja kliencka łączyła się z usługą serwerową używając portów z zakresu dynamicznych bądź prywatnych.

Używanie obu protokołów TCP i UDP

Niektóre aplikacje mogą używać obu protokołów TCP i UDP. Dla przykładu, niewielki narzut UDP pozwala serwerowi DNS bardzo szybko obsługiwać wiele zapytań klientów. Czasami jednak, przesyłanie informacji może wymagać pewności dostarczania jaką daje właśnie TCP. W tym przypadku dobrze znany port 53 używany jest przez oba protokoły.

Strona 3:

Czasem potrzebna jest informacja na temat aktywnych połączeń TCP. Netstat to ważne narzędzie sieciowe umożliwiające ich zweryfikowanie. Netstat wyświetla używane protokoły, lokalne adresy i numery portów, zdalne adresy i numery portów oraz status każdego połączenia.

Nieznane połączenia TCP mogą okazać się naruszeniem bezpieczeństwa. Takie dziwne informacje mogą wskazywać, że ktoś lub coś jest połączone z naszym hostem. Dodatkowo, niepotrzebne połączenia TCP zajmują zasoby systemowe, mogąc wpłynąć na wydajność hosta. Właśnie netstat powinien zostać użyty do sprawdzenia otwartych połączeń na hoście kiedy wydajność wydaje się obniżona.

Komenda netstat posiada ponadto wiele ciekawych opcji.

4.1.6 Segmentacja i scalanie - dziel i rządź

Strona 1:

Poprzedni rozdział pokazał jak przez różne protokoły tworzone są porcje danych (PDU) w kierunku od aplikacji aż do ich transmisji przez medium. Na hoście docelowym proces ten przebiega odwrotnie i dane z medium transmisyjnego przekazywane są do aplikacji.

Niektóre aplikacje transmitują duże ilości danych - w niektórych przypadkach, wiele gigabajtów. Wysyłanie takiej ilości w jednym kawałku byłoby bardzo niepraktyczne. Transmisja takiego wielkiego kawałka zatrzymałaby inne transmisje w sieci na długi czas. Mogłoby okazać się nawet, że taka transmisja trwałaby kilka godzin lub dni. Dodatkowo, gdyby zdarzył się jakiś niewielki błąd, całość danych musiałaby zostać retransmitowana. Urządzenia sieciowe nie mają zwykle zbyt dużych buforów, by mogły obsługiwać większe porcje danych. Limit ten zwykle określany jest przez używaną technologię sieciową związaną bezpośrednio z wykorzystywanym medium.

Dzielenie danych aplikacji na kawałki pozwala na to, że dane mogą być transmitowane z limitami określonymi przez medium i że dane z różnych aplikacji mogą być multipleksowane w medium.

TCP i UDP dokonują segmentacji w różny sposób.

W TCP nagłówek każdego segmentu zawiera numer sekwencyjny. Numery sekwencyjne umożliwiają warstwie transportowej na hoście docelowym scalić segmenty w kolejności w jakiej zostały wysłane. Dzięki temu aplikacja docelowa otrzymuje dane dokładnie w takiej kolejności w jakiej zostały wysłane.

Pomimo tego, że UDP także rozróżnia konwersacje pomiędzy aplikacjami, nie interesuje się kolejnością datagramów, czy ustanawianiem połączenia. W nagłówku UDP nie ma numeru sekwencyjnego. UDP jest prostszym protokołem, generuje mniejszy narzut niż TCP, dzięki czemu dane przesyłane są szybciej.

Informacja może docierać w innej kolejności niż została wysłana, gdyż pakiety mogą biec różnymi drogami. Aplikacja używająca UDP musi tolerować fakt, że dane mogą nie docierać w kolejności, w jakiej były wysyłane.

4.2 Protokół TCP - komunikacja niezawodna

4.2.1 TCP - tworzenie niezawodnej konwersacji

Strona 1:

Kluczową różnicą pomiędzy TCP i UDP jest niezawodność. Niezawodność komunikacji TCP dokonywana jest przez zorientowane połączeniowo sesje. Zanim host będzie mógł wysłać dane przy pomocy TCP, warstwa transportowa inicjuje proces tworzenia połączenia z hostem docelowym. Połączenie to umożliwia śledzenie sesji lub strumienia komunikacyjnego pomiędzy hostami. Dzięki temu procesowi obie strony są świadome komunikacji i są do niej odpowiednio przygotowane. Konwersacja TCP wymaga ustanowienia sesji pomiędzy hostami w obu kierunkach.

Po ustanowieniu sesji host docelowy wysyła do źródła potwierdzenia odebranych segmentów. Potwierdzenia te stanowią podstawę niezawodności w sesji TCP. Jeśli źródło otrzyma potwierdzenie, to wie że dane zostały prawidłowo dostarczone i można przestać monitorować dostarczone dane. Jeśli zaś host źródłowy takiego potwierdzenia w określonym czasie nie otrzyma, będzie musiał retransmitować dane.

Część dodatkowego narzutu wynikającego z użycia TCP, to ruch sieciowy generowany przez potwierdzenia i retransmisje. Ustanawianie sesji tworzy dodatkowy narzut w postaci segmentów wymienianych podczas tego procesu. Prócz tego hosty muszą na bieżąco śledzić stan sesji, oczekiwać na potwierdzenia segmentów i dokonywać ewentualnych retransmisji.

Niezawodność uzyskiwana jest poprzez użycie specyficznych pól w nagłówku segmentu TCP, tak jak pokazano na schemacie. Pola te zostaną opisane w dalszej części rozdziału.

4.2.2 Procesy TCP na serwerze

Strona 1:

Jak omówiono w poprzednim rozdziale, procesy aplikacji uruchamiane są na serwerach. Procesy te czekają, aż klient zainicjuje komunikację żądając informacji lub innych usług.

Każda aplikacja uruchomiona na serwerze skonfigurowana jest do używania danego portu domyślnie lub przez administratora systemu. Pojedynczy serwer nie może mieć dwóch usług przypisanych do tego samego portu w ramach tego samego protokołu warstwy transportowej. Host, na którym uruchomiono zarówno serwer WWW oraz FTP, nie może przypisać obu tym usługom tego samego portu (np. port 8080 TCP). Kiedy aplikacja serwera jest aktywna i ma przypisany określony port, port ten określa się jako "otwarty" na serwerze. Oznacza to, że warstwa transportowa akceptuje i przetwarza segmenty skierowane do tego portu. Każde nadchodzące poprawnie zaadresowane żądanie do gniazda (adres IP:numer portu) jest akceptowane, a dane przekazywane są do odpowiedniej aplikacji serwera. Na serwerze (rozumianym jako system komputerowy, na którym uruchomione są aplikacje serwerowe) może być wiele równolegle otwartych portów, po jednym dla każdej aplikacji serwerowej. Powszechnie stosowane jest rozwiązanie, że na jednym serwerze uruchomionych jest jednocześnie kilka usług (aplikacji serwerowych), np. usługa HTTP i usługa FTP.

Jednym ze sposobów zwiększenia bezpieczeństwa serwera jest ograniczenie dostępu do serwera tylko na odpowiednie porty, skonfigurowane dla usług i aplikacji, które mają być dostępne dla autoryzowanych użytkowników.

Na schemacie pokazano typową numerację portów w komunikacji typu klient/serwer przy użyciu protokołu TCP.

4.2.3 Nawiązanie i zakończenie połączenia TCP

Strona 1:

Zanim dane mogą zostać przesłane w komunikacji między hostami przy użyciu protokołu TCP, musi być ustanowione między nimi połączenie. Natomiast kiedy transmisja danych zostanie zakończona, sesje połączeniowe są zamykane, a ustanowione na początku połączenie kończone. Mechanizmy nawiązania połączenia i mechanizm sesji zapewniają niezawodność komunikacji przy użyciu protokołu TCP.

Poszczególne etapy występujące przy nawiązywaniu i kończeniu połączenia przy użyciu protokołu TCP można zaobserować na zamieszczonym schemacie.

Host podczas sesji śledzi wysyłane segmenty danych i porównuje je z danymi otrzymanymi przez adresata, używając informacji zawartych w nagłówku TCP.

Każde połączenie składa się z dwóch jednokierunkowych strumieni komunikacyjnych, zwanych sesjami. Aby nawiązać połączenie, host używa uzgadniania trójetapowego (ang. three-way handshake). Bity kontrolne w nagłówku TCP wskazują postęp procesu i jego bieżący stan. Uzgadnianie trójetapowe (ang. three-way handshake):

• ustala czy urządzenie jest obecne w sieci;

• sprawdza, czy urządzenie docelowe (serwer) ma aktywną usługę i akceptuje połączenia na porcie, który urządzenie inicjujące połączenie (klient) chce użyć podczas sesji;

• informuje urządzenie docelowe (serwer), że urządzenie inicjujące połączenie (klient) zamierza ustanowić sesję na porcie o tym numerze.

W połączeniu TCP host odgrywający rolę klienta inicjuje sesję z serwerem. Trzy etapy podczas ustanawiania połączenia to:

1. Klient (host inicjujący połączenie) wysyła segment (SYN) zawierający początkową wartość synchronizacyjną (numer początkowy ISN), co służy jako żądanie skierowane do serwera rozpoczęcia sesji komunikacyjnej.

2. Serwer odpowiada, wysyłając segment (SYN, ACK), zawierający wartość potwierdzenia (która jest równa przysłanej przez host wartości synchronizacyjnej powiększonej o 1) oraz wysyła swoją własną wartość synchronizacyjną (swój własny numer początkowy ISN). Wartość potwierdzenia jest zawsze większa od numeru sekwencyjnego ponieważ oznacza ona numer następnego spodziewanego bajtu (oktetu). Ta wartość potwierdzenia umożliwia klientowi dopasowanie odpowiedzi do numeru segmentu wysłanego do serwera.

3. Inicjujący połączenie klient odpowiada potwierdzeniem o wartości równej numerowi sekwencyjnemu serwera powiększonemu o 1. To kończy proces nawiązywania połączenia.

Aby zrozumieć technikę uzgadniania trójetapowego, ważnym jest prześledzenie różnych wartości flag, które hosty wymieniają między sobą. W segmencie TCP jest 6 jednobitowych pól (flag), które zawierają informacje kontrolne używane podczas zarządzania komunikacją TCP. Tymi polami są:

URG- flaga, która wskazuje na ważność pola "Pilny" (ang. Urgent) w nagłówku TCP;

ACK - flaga, która oznacza ważność pola "Potwierdzenie" (ang. Acknowledgment) w nagłówku TCP;

PSH - flaga, która oznacza wykorzystanie funkcji PUSH;

RST - flaga, która używana jest do kończenia połączenia;

SYN - flaga, która wskazuje na Synchronizację numerów sekwencyjnych;

FIN - flaga, która wskazuje koniec danych od nadawcy.

W segmencie pola te są nazywane flagami, znacznikami lub wprost bitami, ponieważ ich wielkość wynosi 1 bit, a więc mogą przyjmować 2 wartości: 1 lub 0. Kiedy wartość któregoś z powyższych bitów (flag) jest równa 1 oznacza to, że segment zawiera kontrolną informację, na którą wskazuje to pole.

Używając 4 etapowego procesu, flagi są wymieniane celem zakończenia połączenia TCP.

4.2.4 Uzgadnianie trójetapowe TCP

Strona 1:

Używając zrzutów ekranów programu Wireshark możesz prześledzić sposób przebiegu uzgadniania trójetapowego.

Etap 1

Klient TCP rozpoczyna uzgadnianie trójetapowe przez wysłanie segmentu z flagą SYN (ang. Synchronize Sequence Number, Synchronizuj Numer Sekwencyjny) o wartości 1 wskazującą, że ten segment zawiera w nagłówku wartość początkową numeru sekwencyjnego. Ta początkowa wartość numeru sekwencyjnego, oznaczana skrótem ISN (ang. Initial Sequence Number, Początkowy Numer Sekwencyjny), jest generowana losowo i zostaje użyta do rozpoczęcia śledzenia przepływu danych od klienta do serwera w tej nawiązywanej sesji. Wartość ISN w nagłówku każdego kolejnego segmentu jest zwiększana o 1 dla każdego wysłanego bajtu podczas trwania konwersacji między klientem i serwerem.

Na schemacie widać ustawioną wartość flagi SYN i wygenerowany numer sekwencyjny.

Flaga kontrolna SYN jest ustawiona (jej wartość wynosi 1, w zapisie binarnym ta część ramki ma postać 00000010, gdzie od prawej 0 oznacza bit ACK, 1 oznacza bit SYN) i wygenerowany numer sekwencyjny jest równy 0. Pomimo, że analizator pokazuje wartości dziesiętne numerów sekwencyjnych oraz potwierdzeń w rzeczywistości są to 32 bitowe liczby binarne. Bieżące wartości znajdujące się w nagłówku segmentu możemy określić przez odczytanie panelu bajtów pakietu (dolnej części okna WireShark'a, ang. Packet Bytes pane). W dolnej części okna programu WireShark możesz zaobserować bajty w postaci szesnastkowej.

Strona 2:

Etap 2

Serwer musi potwierdzić otrzymanie segmentu SYN od klienta w celu ustanowienia sesji od klienta do serwera. Aby to wykonać, serwer w odpowiedzi wysyła do klienta segment z ustawioną flagą ACK wskazującą, że zawiera on ważny numer potwierdzenia. Widząc ustawioną wartość flagi ACK, klient rozpoznaje ten segment jako potwierdzenie otrzymania od niego (klienta TCP) przez serwer segmentu z ustawionym bitem SYN.

Wartość pola potwierdzenia (ACK) jest równa synchronizującej wartości początkowej (ISN) powiększonej o 1. Otrzymanie tego potwierdzenia ustanawia sesję od klienta do serwera. Flaga potwierdzenia (ACK) pozostaje ustawiona podczas trwania sesji. Pamiętaj, że wymiana danych między klientem i serwerem to w rzeczywistości dwie jednokierunkowe sesje: jedna od klienta do serwera, a druga od serwera do klienta. W tym drugim kroku uzgadniania trójetapowego serwer musi zainicjować połączenie od serwera do klienta. Aby rozpocząć tę sesję serwer używa flagi SYN w ten sam sposób jak użył jej klient podczas nawiązywania z nim sesji. Ustawia on flagę SYN w nagłówku, aby ustanowić sesję od serwera do klienta. Ustawiona wartość flagi SYN wskazuje, że w nagłówku znajduje się początkowa wartość numeru sekwencyjnego (wygenerowana przez serwer). Ta wartość będzie użyta do śledzenia przepływu danych w kierunku od serwera do klienta.

Zamieszczony schemat pokazuje, że ustawione są wartości flag kontrolnych ACK i SYN oraz pokazane są wartości numeru sekwencyjnego (wartość 0) i potwierdzenia (wartość 1).

Strona 3:

Etap 3

Na końcu trójetapowego uzgadniania klient odpowiada segmentem zawierającym potwierdzenie (ACK), który jest odpowiedzią na segement synchornizujący TCP wysłany przez serwer. W tym segmencie nie ma danych użytkownika. Wartość w polu potwierdzenia jest o 1 większa od wartości początkowego numeru sekwencyjnego otrzymanego od serwera. Od momentu ustanowienia obu sesji pomiędzy klientem i serwerem wszystkie pozostałe segementy wymieniane w tej komunikacji mają ustawioną flagę ACK.

Na schemacie pokazano ustawioną flagę ACK oraz wartości numeru sekwencyjnego i potwierdzenia.

Bezpieczeństwo komunikacji w sieci możemy zapewnić poprzez:

• odmowę ustanowienia sesji TCP,

• zezwolenie ustanowienia sesji dla określonych usług (serwisów),

• zezwolenie na ruch tylko w ramach ustanowionych już sesji.

Bezpieczeństwo to może być wprowadzone dla wszystkich lub wybranych sesji TCP.

4.2.5 Zakończenie sesji TCP

Strona 1:

Aby zakończyć połączenie, w nagłówku segmentu musi być ustawiona flaga FIN. W celu zakończenia każdej jednokierunkowej sesji TCP, używane jest podwójne uzgadnianie, składające się z segmentów FIN oraz ACK. Tak więc, aby zakończyć pojedynczą konwersację TCP, dla obu sesji (klient -> serwer oraz serwer -> klient) potrzebne są dwa takie uzgadniania (czyli wymiana czterech segmentów po dwa na każde uzgodnienie). Zauważ: W opisie terminy klient i serwer są użyte dla uproszczenia sytuacji, ale proces zakończenia komunikacji między hostami może być zainicjowany przez każdego z nich:

1. Kiedy klient nie ma więcej danych do przesłania, wysyła segment z ustawioną flagą FIN.

2. Aby potwierdzić otrzymanie segmentu z ustawioną flagą FIN, serwer wysyła segment z ustawioną flagą ACK, co kończy połączenie od klienta do serwera.

3. W celu zakończenia sesji od serwera do klienta serwer wysyła segment z ustawioną flagą FIN do klienta.

4. Aby potwierdzić otrzymanie segmentu z ustawioną flagą FIN od serwera, klient odpowiada segmentem z ustawioną flagą ACK.

Kiedy po stronie klienta nie ma więcej danych do przesłania ustawia on flagę FIN w nagłówku segmentu. Następnie po stronie serwera wysyłany jest segment z ustawioną flagą ACK z użyciem numeru potwierdzenia, który potwierdza, że wszystkie dane zostały otrzymane. Kiedy wszystkie segmenty zostaną potwierdzone, sesja jest zakończona.

Sesja w odwrotnym kierunku zamykana jest przy użyciu takiego samego procesu. Host odbierający informuje, że nie ma więcej danych do przesłania przez wysłanie segmentu do źródła z ustawioną flagą FIN. Potwierdzenie otrzymane w odpowiedzi oznacza, że wszystkie dane zostały otrzymane i w związku z tym sesja jest zamykana.

Jak widać na schemacie flagi FIN i ACK są ustawione w nagłówku, tym samym zamykając sesję HTTP.

Możliwe jest również zakończenie sesji za pomocą uzgadniania trójetapowego. Kiedy klient nie ma więcej danych do przesłania, wysyła do serwera segment z ustawioną flagą FIN. Jeśli serwer również nie ma więcej danych do przesłania, odpowiada segmentem z ustawionymi flagami FIN oraz ACK, łącząc dwa etapy w jeden. Klient odpowiada segmentem z ustawioną flagą ACK.

4.3 Zarządzanie sesjami TCP

4.3.1 Scalanie segmentów TCP

Strona 1:

Ustalanie kolejności segmentów odebranych zgodnie z kolejnością ich nadawania

Kiedy usługi przesyłają dane za pomocą TCP, segmenty mogą dotrzeć do hosta w innej kolejności niż były nadawane. Aby odbiorca właściwie zrozumiał nadawaną wiadomość, dane w odebranych segmentach są scalane w kolejności w jakiej były wysyłane. Do tego celu używane są numery sekwencyjne znajdujące się w nagłówku każdego segmentu.

Podczas nawiązywania sesji ustalany jest początkowy (inicjujący) numer sekwencyjny ISN. Ten inicjujący numer ISN przedstawia początkową wartość dla nawiązywanej sesji, w której dane będą przesyłane do docelowej aplikacji. W miarę przesyłania danych podczas sesji numer sekwencyjny zwiększany jest o liczbę bajtów, które zostały wysłane. To śledzenie bajtów danych umożliwia unikalną identyfikację i potwierdzenie każdego segmentu. Zaginione segmenty mogą być zidentyfikowane.

Na schemacie pokazane jest w jaki sposób numery sekwencyjne segmentów zapewniają niezawodność transmisji przez wskazanie jaka jest kolejność odebranych segmentów.

Odbierający proces TCP umieszcza dane z segmentu w buforze odbiorczym. Segmenty są ustawiane w kolejności zgodnej z numerami sekwencyjnymi i następnie przekazywane do warstwy aplikacji. Jeśli odebrane zostaną segmenty, których numery sekwencyjne nie zachowują ciągłości, są one zatrzymywane (w buforze) w celu późniejszego przetworzenia. Po otrzymaniu brakujących segmentów dane zostają niezwłocznie przetworzone.

4.3.2 Potwierdzenie TCP z mechanizmem przesuwnego okna

Strona 1:

Potwierdzenie otrzymania segmentów

Jedną z funkcji TCP jest zapewnienie, że każdy segment osiągnie swój cel. Usługi korzystające z TCP działające na adresacie, potwierdzają otrzymanie danych aplikacji, która je wysłała.

Numery, sekwencyjny i potwierdzenia, które znajdują się w nagłówku segmentu, używane są do potwierdzenia otrzymania bajtów danych zawartych w segmentach. Numer sekwencyjny to względna wartość (wskazująca ile bajtów danych zostało przesłanych w tej sesji) powiększona o 1 (co stanowi numer pierwszego bajtu w bieżącym segmencie). TCP używa (w segmentach wysyłanych z powrotem do nadawcy) numeru potwierdzenia celem wskazania następnego bajtu w tej sesji, który spodziewa się otrzymać adresat. Nazywane jest to przewidywanym potwierdzeniem (ang. expectational acknowledgment)

Źródło informowane jest, że odbiorca otrzymał wszystkie bajty danych, aż do podanej wartości, ale z jej wyłączeniem (tzn. bez bajtu o podanym numerze). Oczekuje się, że nadawca wysyłając kolejny segment, użyje numeru sekwencyjnego równego numerowi potwierdzenia.

Pamiętaj, że każde połączenie składa się z dwóch jednokierunkowych sesji. Numery sekwencyjne i potwierdzenia są wymieniane w obu kierunkach.

W przykładzie przedstawionym na schemacie host z lewej strony wysyła dane do hosta po prawej stronie. Wysyłany jest segment zawierający 10 bajtów danych dla tej sesji z numerem sekwencyjnym w nagłówku wynoszącym 1.

Odbiorca po prawej otrzymuje segment (warstwa 4) i ustala, że numer sekwencyjny wynosi 1, a segment zawiera 10 bajtów danych. Odsyła więc segment do hosta po lewej z potwierdzeniem otrzymania tych danych. W tym odsyłanym segmencie wartość potwierdzenia ustawiana jest na 11, aby wskazać numer następnego bajtu, który host po prawej spodziewa się otrzymać w tej sesji.

Kiedy host po lewej otrzyma to potwierdzenie, może wysłać następny segment z danymi, rozpoczynając od bajtu numer 11.

Patrząc na ten przykład, gdyby nadawca musiał czekać na potwierdzenie każdego z 10 wysłanych bajtów sieć byłaby przeciążona dużą ilością potwierdzeń. Aby temu zapobiec wiele segmentów z danymi może zostać wysłanych zanim adresat potwierdzi ich otrzymanie pojedynczym segmentem TCP. To potwierdzenie zawiera numer, który jest obliczony z uwzględnieniem wszystkich otrzymanych w międzyczasie bajtów.

Na przykład, zaczynając z numerem sekwencyjnym równym 2000, jeśli host docelowy otrzyma 10 segmentów każdy zawierający po 1000 bajtów danych, w potwierdzeniu wysłanym do nadawcy tej partii danych numer potwierdzenia wyniesie 12001.

Ilość danych, którą nadawca może wysłać zanim musi otrzymać potwierdzenie nazywana jest rozmiarem okna (ang. window size). Rozmiar okna jest polem w nagłówku TCP, które umożliwia zarządzanie utraconymi danymi i kontrolą przepływu.

4.3.3 Retransmisja TCP

Strona 1:

Zarządzanie utraconymi segmentami

Bez względu na to jak dobrze została zaprojektowana sieć, zawsze pojawi się sporadyczna utrata przesyłanych danych. Dlatego też TCP dostarcza metod zarządzania utraconymi segmentami. Zawarty jest w nich mechanizm retransmisji segmentów z niepotwierdzonymi danymi.

Usługa TCP na hoście docelowym zwykle potwierdza ciągłą partię danych. Jeśli brakuje jednego lub więcej segmentów, to potwierdzane są tylko te dane w segmencie, które poprzedzają pierwszy brakujący fragment.

Na przykład, jeśli adresat otrzymał segmenty z numerami sekwencyjnymi od 1500 do 3000 i od 3400 do 3500, to numer potwierdzenia wyniesie 3001. Oczywiście dlatego, że segemnty z numerami sekwencyjnymi od 3001 do 3999 nie zostały odebrane.

Kiedy nadawca nie otrzyma potwierdzenia w określonym czasie powróci do numeru sekwencyjnego, który miał ostatnio potwierdzony i wyśle ponownie wszystkie dane, zaczynając od bajtu o tym numerze.

Proces retransmisji nie jest zdefiniowany w dokumentach RFC, ale jest pozostawiony do rozwiązania w poszczególnych implementacjach protokołu TCP.

Dla typowej implementacji protokołu TCP host może wysyłać segment, umieszczając równocześnie jego kopię w kolejce retransmisyjnej i uruchamiając zegar. Kiedy potwierdzenie otrzymania danych z wysłanego segmentu jest odebrane, kopia segmentu umieszczona w kolejce retransmisyjnej jest z niej usuwana. Jeśli potwierdzenie nie zostanie otrzymane przed upływem określonego czasu oczekiwania, segment jest retransmitowany.

Animacja pokazuje retransmisję utraconych segmentów.

Obecnie, hosty mogą również wykorzystać opcjonalną cechę zwaną selektywnymi potwierdzeniami (ang. Selective Acknowledgements). Jeśli oba hosty komunikujace się ze sobą wspierają selektywne potwierdzenia, możliwym się staje dla odbiorcy potwierdzanie bajtów w nieciągłych segmentach i po otrzymaniu takiego potwierdzenia, nadawca będzie potrzebował retransmitować tylko brakujące dane.

4.3.4 Kontrola przeciążenia w protokole TCP - minimalizacja utraty segmentów

Strona 1:

Kontrola przepływu

Protokół TCP zapewnia również mechanizm kontroli przepływu (ang. flow control). Kontrola przepływu wspiera mechanizm zapewnienia niezawdoności transmisji TCP przez dostosowanie tempa przepływu danych między dwoma usługami w sesji. Jeśli nadawca dowiaduje się, że określona ilość danych zawarta w segmencie została otrzymana, może kontynuować nadawanie ze zwiększoną ilością danych dla tej sesji.

Parametr ten określa wartość rozmiaru okna w nagłówku segmentu TCP, która mówi jaka ilość danych może być wysłana bez potwierdzenia lub inaczej, po wysłaniu której należy poczekać na potwierdzenie od odbiorcy. Początkowy rozmiar okna jest ustalany podczas nawiązywania sesji w uzgadnianiu trójetapowym (3-way handshake).

Mechanizm kontroli zwrotnej TCP dostosowuje efektywne tempo przesyłania danych do maksymalnego poziomu, który sieć oraz adresat mogą obsłużyć bez utraty danych. Protokół TCP usiłuje zarządzać tempem przesyłu tak, aby całe wysłane dane zostały odebrane i aby ilość retransmisji była zminimalizowana.

Schemat przedstawia w uproszczony sposób rozmiar okna i numery potwierdzeń. W tym przykładzie w prezentowanej sesji początkowy rozmiar okna został ustalony na 3000 bajtów. Kiedy nadawca wysłał 3000 bajtów, musi poczekać na potwierdzenie otrzymania tych 3000 bajtów zanim w tej sesji wyśle kolejne segmenty.

Jak tylko nadawca otrzyma potwierdzenie od odbiorcy, może wysyłać kolejne 3000 bajtów.

Podczas przerwy w transmisji, polegającej na oczekiwaniu na potwierdzenie, w tej sesji nadawca nie będzie nadawał żadnych dodatkowych segementów. W okresach przeciążenia sieci lub zajętości zasobów hosta odbierającego, opóźnienia mogą wydłużać się. Jeśli długość tego okresu przestoju będzie rosła, efektywne tempo transmisji danych dla tej sesji będzie malało. Spowolnienie tempa przesyłania danych pomoże zlikwidować problem przestojów występujący u nadawcy.

Strona 2:

Zmniejszanie rozmiaru okna

Innym sposobem kontroli przepływu danych jest użycie dynamicznego rozmiaru okna. Kiedy sieć jest przeciążona i zdarzają się częste retransmisje, protokół TCP może zmniejszyć rozmiar okna, aby spowodować konieczność częstszego potwierdzania otrzymanych segmentów. To w efekcie wywołuje zmniejszenie tempa przesyłu danych, gdyż nadawca musi częściej czekać na potwierdzenie ich dostarczenia.

W komunikacji TCP to host odbierający wysyła rozmiar okna wskazujący ilość bajtów, które jest gotów odebrać w jednej partii danej sesji. Jeśli host odbierający potrzebuje zmniejszyć ilość przesyłanych danych z powodu ograniczenia buforu odbioru, może wysłać zmniejszony rozmiar okna do nadawcy w segmencie potwierdzającym (z ustawionym bitem ACK).

Jak pokazano na schemacie, jeśli odbiorca jest przeciążony, może odpowiedzieć do nadawcy segmentem ze zmniejszonym rozmiarem okna. W przedstawionej sytuacja mamy do czynienia z utratą jednego z segmentów. Odbiorca zmienił wartość pola "rozmiar okna" w nagłówku TCP w tej sesji z 3000 do 1500. To powoduje, że nadawca zmniejsza rozmiar okna do 1500.

Po jakimś czasie transmisji bez utraty danych oraz przeciążenia zasobów, odbiorca rozpocznie zwiększanie wartości rozmiaru okna. Działanie to ogranicza obciążenie sieci z powodu zmniejszenia ilości potwierdzeń, które muszą być wysłane. Rozmiar okna będzie rósł, aż do wartości, przy której nastąpi utrata danych, co spowoduje ponowne zmniejszenie wartości rozmiaru okna.

To dynamiczne zwiększanie i zmniejszanie rozmiaru okna jest procesem ciągłym w komunikacji przy użyciu protokołu TCP i pozwala osiągnąć wartość optymalną dla każdej sesji. W bardzo wydajnych sieciach, w których nie ma utraty danych rozmiar okna może stać się bardzo duży. W sieciach o bardzo obciążonych łączach rozmiar okna pozostanie mały.

4.4 Protokół UDP - komunikacja z małym narzutem informacji kontrolnych

4.4.1 UDP - mały narzut informacji kontrolnych a niezawodność dostarczenia

Strona 1:

Protokół UDP jest prostym protokołem, który zapewnia podstawowe funkcje warstwy transportowej. Ma on mniejszą ilość informacji kontrolnych niż TCP gdyż nie jest zorientowany połączeniowo, co oznacza, że nie zapewnia wyszukanych mechanizmów retransmisji, porządkowania odebranych danych czy kontroli przepływu.

Jednak nie oznacza to, że aplikacje używające protokołu UDP są zawsze zawodne. Zatem mechanizmy te nie są zapewnione przez warstwę transportową i jeśli są konieczne muszą być zaimplementowane gdzieś indziej.

Całkowita wielkość ruchu przy użyciu protokołu UDP w typowej sieci jest często relatywnie niska. Do głównych aplikacji oraz protokołów warstwy aplikacji korzystających z tego protokołu zaliczamy:

• protokół DNS (ang. Domain Name System, system nazw domenowych),

• protokół SNMP (ang. Simple Network Management Protocol),

• protokół DHCP (ang. Dynamic Host Configuration Protocol),

• protokół RIP (ang. Routing Information Protocol),

• protokół TFTP (ang. Trivial File Transfer Protocol),

• gry online.

Niektóre aplikacje, jak np. gry online lub komunikacja głosowa przez sieć IP (VoIP), mogą tolerować utratę pewnej części danych. Gdyby użyć w ich przypadku komunikacji przy użyciu protokołu TCP można by było doświadczyć bardzo dużych opóźnień z powodu wykrywania każdej utraty danych i ich każdorazowej retransmisji. Te opóźnienia byłyby bardziej szkodliwe dla tych aplikacji niż sama utrata części danych. Niektóre aplikacje, takie jak DNS, po prostu ponowią żądanie jeśli nie otrzymają odpowiedzi, a więc nie potrzebują protokołu TCP, żeby zagwarantować dostarczenie danych.

4.4.2 Scalanie datagramów UDP

Strona 1:

Ponieważ protokół UDP nie jest połączeniowy, sesje nie są nawiązywane przed rozpoczęciem transmisji między hostami, jak to ma miejsce w przypadku użycia protokołu TCP. Mówi się, że protokół UDP jest protokołem transakcyjnym. Innymi słowy, kiedy aplikacja ma dane do wysłania, po prostu je wysyła.

Wiele aplikacji używających protokół UDP wysyła małe ilości danych, które mogą pomieścić się w jednym segmencie. Jednak są również aplikacje, które wysyłają większe ilości danych, które muszą być podzielone na kilka segmentów. Jednostka danych protokołu (UDP) nazywana jest datagramem, chociaż terminy segment i datagram czasami używane są zamiennie przy opisywaniu jednostki danych protokołów warstwy transportowej.

Kiedy kilka datagramów jest wysyłanych do odbiorcy, mogą one być przesyłane różnymi ścieżkami i przybyć do odbiorcy w niewłaściwej kolejności. Protokół UDP nie znakuje segmentów przy użyciu numerów sekwencyjnych tak jak robi to TCP. Stąd protokół UDP nie ma możliwości uporządkowania odebranych datagramów według kolejności ich nadawania. Popatrz na schemat.

Z tego powodu protokół UDP po prostu scala dane w kolejności ich otrzymania i przekazuje do aplikacji. Jeśli kolejność danych jest ważna dla aplikacji, musi ona sama zidentyfikować właściwą ich kolejność i sposób ich przetworzenia.

4.4.3 Aplikacje serwerowe korzystające z protokołu UDP i ich żądania

Strona 1:

Tak jak w aplikacjach wykorzystujących protokół TCP, aplikacje serwerowe wykorzystujące protokół UDP mają przypisane tzw. dobrze znane (ang. Well Known) lub zaresjestrowane (ang. Registered) numery portów. Kiedy aplikacje lub usługi są uruchomione, akceptują nadchodzące dane adresowane do przyporządkowanych im portów. Kiedy protokół UDP otrzymuje datagram adresowany do jednego z tych portów, to na jego podstawie przekazuje odebrane dane do odpowiedniej aplikacji.

4.4.4 Procesy zachodzące na kliencie wykorzystującym protokół UDP

Strona 1:

Tak jak w przypadku protokołu TCP, komunikacja typu klient/serwer jest inicjowana przez aplikację po stronie klienta, która to żąda jakichś danych od jakiejś usługi serwera. Aplikacja klienta, wykorzystującego protokół UDP, losowo wybiera numer portu z zakresu portów dynamicznych i używa tego numeru jako portu źródłowego dla tej komunikacji. Docelowy port będzie zwykle z grupy dobrze znanych lub zarejestrowanych portów, który z kolei przyporządkowany jest usłudze na serwerze.

Losowe numery portów zwiększają bezpieczeństwo. Gdybyśmy mieli przewidywalne porty źródłowe, intruz (włamywacz) mógłby łatwiej uzyskać dostęp do klienta poprzez połączenie z nim na numer portu, który najprawdopodobniej byłby użyty i otwarty (na kliencie) dla komunikacji z serwerem.

Z powodu braku sesji w połączeniach z wykorzystaniem protokołu UDP, po przygotowaniu danych do wysłania i określeniu portów nadawcy i adresata, protokół UDP formatuje dane a następnie przekazuje je do warstwy sieciowej w celu zaadresowania i wysłania.

Pamiętaj, kiedy klient ustali numery portów źródłowego i docelowego, te same numery portów użyte zostaną w odpowiedzi serwera. Z tym zastrzeżeniem, że numery tych portów w nagłówku datagramu stanowiącego odpowiedź serwera do klienta będą zamienione miejscami.

14

---