CISCO Accessible Theme Strona 1
Zmień język na English | Szukaj | Słownik
Indeks kursu:
4 Warstwa transportowa modelu OSI Wybierz
CCNA Exploration - Podstawy sieci komputerowych
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.
Wyświetl multimedia.
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 z
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
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 2
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óz
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.
Wyświetl multimedia.
Strona 2:
Separacja strumieni komunikacji
Wyobraz
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óz
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óz
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.
Wyświetl multimedia.
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 .
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 3
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.
Wyświetl multimedia.
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 z
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 .
Wyświetl multimedia.
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 z
ródło może wysłać do hosta docelowego.
Podczas omawiania protokołów, usługi te zostaną omówione bardziej szczegółowo.
Wyświetl multimedia.
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,
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 4
potwierdzanie odbioru danych,
retransmisja niepotwierdzonych danych.
Narzuca to wymóg, aby procesy warstwy transportowej w z
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.
Wyświetl multimedia.
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.
Wyświetl multimedia.
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 5
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 z
ródłowego i numer portu docelowego. Numer portu z
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 odpowiedz
. 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 z
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 odpowiedz
, 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 z
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.
Wyświetl multimedia.
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 z
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ądz
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.
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 6
Odsyłacze
Aktualna lista numerów portów znajduje się pod adresem http://www.iana.org/assignments/port-numbers.
Wyświetl multimedia.
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.
Wyświetl multimedia.
4.1.6 Segmentacja i scalanie - dziel i rzÄ…dz

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.
Wyświetl multimedia.
Strona 2:
W tym ćwiczeniu spojrzymy w głąb pakietów i zobaczymy jak DNS i HTTP używają numerów portów.
Kliknij ikonę Packet Tracer, aby uruchomić ćwiczenie w symulatorze Packet Tracer
Wyświetl multimedia.
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.
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 7
Po ustanowieniu sesji host docelowy wysyła do z
ródła potwierdzenia odebranych segmentów. Potwierdzenia te stanowią podstawę niezawodności
w sesji TCP . Jeśli z
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 z
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.
Wyświetl multimedia.
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.
Wyświetl multimedia.
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.
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 8
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.
Wyświetl multimedia.
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.
Wyświetl multimedia.
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).
Wyświetl multimedia.
Strona 3:
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 9
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 .
Wyświetl multimedia.
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 z
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.
Wyświetl multimedia.
Strona 2:
W tym ćwiczeniu prześledzisz trójetapowe uzgadnianie TCP (3-way handshake) podczas ustanawiania sesji oraz proces kończenia sesji TCP.
Wiele protokołów warstwy aplikacji używa TCP i zobrazowanie ustanawiania i kończenia sesji w programie Packet Tracer pomoże ugruntować
TwojÄ… wiedzÄ™ .
Kliknij na ikonę Packet Tracer, aby uruchomić ćwiczenie w symulatorze Packet Tracer.
Wyświetl multimedia.
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
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 10
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óz
niejszego przetworzenia. Po otrzymaniu brakujących segmentów dane zostają
niezwłocznie przetworzone.
Wyświetl multimedia.
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)
y
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 .
Wyświetl multimedia.
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.
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 11
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.
Wyświetl multimedia.
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óz
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.
Wyświetl multimedia.
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 .
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 12
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.
Odsyłacze
Szczegóły o różnych możliwościach zarządzania przeciążeniami przez protokół TCP znajdują się w dokumencie RFC 2581 .
http://www.ietf.org/rfc/rfc2581.txt
Wyświetl multimedia.
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óz
nień z powodu wykrywania każdej utraty
danych i ich każdorazowej retransmisji. Te opóz
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.
Mały narzut informacji kontrolnych w protokole UDP czyni go wielce pożądanym w takich aplikacjach.
Wyświetl multimedia.
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.
Wyświetl multimedia.
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 13
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.
Wyświetl multimedia.
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 z
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 z
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 z
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 odpowiedz
serwera do klienta będą zamienione miejscami.
Wyświetl multimedia.
Strona 2:
W tym ćwiczeniu badane jest w jaki sposób DNS używa protokołu UDP.
Kliknij na ikonę Packet Tracer, aby uruchomić ćwiczenie w symulatorze Packet Tracer
Wyświetl multimedia.
4.5 Ćwiczenia laboratoryjne
4.5.1 Badanie komunikacji przy użyciu protokołów TCP i UDP za pomocą narzędzia Netstat
Strona 1:
W tym laboratorium na komputerze pełniącym rolę klienta użyjesz komendy netstat (network statistics utility) z różnymi opcjami, w celu
przeanalizowania i zrozumienia stanów protokołów warstwy transportowej modelu TCP/IP.
Kliknij na ikonę laboratorium, aby uzyskać więcej informacji.
Wyświetl multimedia.
4.5.2 TCP i UDP, protokoły warstwy transportowej modelu TCP/IP
Strona 1:
W laboratorium tym wykorzystasz aplikację Wireshark do przechwycenia i zlokalizowania pól w nagłówku segmentu TCP oraz komunikacji
zachodzącej podczas sesji FTP, a także nagłówka datagramu UDP podczas transmisji za pomocą protokołu TFTP.
Kliknij na ikonę laboratorium, aby uzyskać więcej informacji.
Wyświetl multimedia.
4.5.3 Badanie protokołów warstwy transportowej i aplikacji
Strona 1:
WW tym laboratorium wykorzystasz aplikację Wireshark do monitorowania i przeanalizowania komunikacji między klientem a serwerem,
zachodzącej przy użyciu protokołów FTP i HTTP.
Kliknij na ikonę laboratorium, aby uzyskać więcej informacji.
Wyświetl multimedia.
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 14
Strona 2:
W tym laboratorium wykorzystasz tryb symulacji w aplikacji Packet Tracer, aby przechwycić i przeanalizować żądanie strony WWW z
wykorzystaniem adresu URL.
Kliknij na ikonę laboratorium, aby uzyskać więcej informacji.
Wyświetl multimedia.
4.6 Podsumowanie rozdziału
4.6.1 Podsumowanie i powtórka
Strona 1:
Warstwa transportowa odpowiada na potrzeby pojawiające się podczas przesyłania danych w sieci wykonując:
Podział danych otrzymanych z aplikacji na segmenty
Dodanie nagłówka w celu oznaczenia i zarządzania każdym segmentem
Scalenie odebranych segmentów w dane przy użyciu informacji zawartych w nagłówku
Przekazanie scalonych danych do odpowiedniej aplikacji
Protokoły UDP i TCP są podstawowymi protokołami warstwy transportowej.
Datagramy protokołu UDP i segmenty protokołu TCP zawierają w nagłówku (poprzedzającym dane) numery portów z
ródłowych i docelowych. Te
numery portów pozwalają na skierowanie danych do odpowiedniej aplikacji na adresacie.
Protokół TCP nie wysyła danych dopóki nie ustali, że adresat jest gotowy do ich odbioru. Protokół TCP zarządza przepływem danych i ponawia
wysyłkę każdego segmentu, którego odbiór nie zostanie potwierdzony. Protokół TCP w celu zapewnienia niezawodności dostarczenia danych
używa mechanizmu uzgadniania, parametrów czasowych , potwierdzeń oraz przesuwnego okna. To zapewnienie niezawodności ma z kolei wpływ
na zwiększenie obciążenia sieci z powodu większych rozmiarów nagłówków oraz przesyłania większej ilości informacji kontrolnych ,
zarządzających komunikacją między klientem i serwerem.
W przypadku, gdy aplikacja potrzebuje dostarczyć dane przez sieć szybko oraz przepustowość sieci nie jest wystarczająca dla przesyłania
dodatkowych informacji kontrolnych między klientem i serwerem, programiści w warstwie transportowej wybiorą raczej protokół UDP.
Spowodowane to jest tym , że protokół UDP nie śledzi przebiegającej komunikacji, nie potwierdza otrzymania datagramów przez adresata i
również nie ponawia wysłania utraconych datagramów - po prostu przekazuje dane jak tylko je scali do warstwy aplikacji. Jednakże, to
niekoniecznie oznacza, że ten sposób komunikacji nie jest godny zaufania. W warstwie aplikacji, jeśli tylko będzie to konieczne, mogą zostać
zastosowane protokoły i usługi, które odpowiednio obsłużą zagubione lub otrzymane w złej kolejności datagramy.
Wybór protokołu w warstwie transportowej zależy od twórcy aplikacji i dokonywany jest tak, aby spełnić wymagania użytkownika. Oczywiście przy
wyborze brane jest również pod uwagę to, że pozostałe warstwy modeli komunikacji w sieciach odgrywają swoje role oraz jaki wpływ będzie miał
ten wybór na wydajność.
Wyświetl multimedia.
Strona 2:
Wyświetl multimedia.
Strona 3:
W tym ćwiczeniu obserwujesz dokładnie procesy interakcje między DNS, HTTP, UDP i TCP, które zachodzą, kiedy za każdym razem chcesz
obejrzeć stronę WWW w Internecie.
Instrukcje do ćwiczenia integrującego umiejętności w symulatorze Packet Tacer (PDF)
Kliknij na ikonę Packet Tracer, aby uruchomić ćwiczenie w symulatorze Packet Tracer
Wyświetl multimedia.
Strona 4:
Aby nauczyć się więcej
Pytania do przemyślenia
Przedstaw wymagania aplikacji, które mogą mieć wpływ na dokonanie wyboru protokołu UDP lub TCP przez twórcę programu.
W przypadku, gdy aplikacja wymaga niezawodności dostarczenia danych, uzasadnij kiedy (pod jakimi warunkami) można użyć protokołu UDP.
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48
CISCO Accessible Theme Strona 15
Odsyłacze
Wprowadzenie do sieci rozległych
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Intro-to-Internet.html
Wyświetl multimedia.
4.7 Quiz do rozdziału
4.7.1 Quiz do rozdziału
Strona 1:
Wyświetl multimedia.
Następny
Poprzedni
Do góry
All contents are Copyright © 2007-2008 Cisco Systems, Inc. All rights reserved. | Proces tÅ‚umaczenia wspierany przez NextiraOne. O kursie
Element obsługiwany przez wtyczkę
http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:48