wydawać się nieco dziwne, dlatego też przy takich informacjach będę
zapisywać oznacznie oryginalności zapisu (<strong>sic/sic!</strong>).
</p>
+ <h1 id="1.14.transportlayer">1.14. Warstwa transportowa</h1>
+ <p>
+ Warstwa transportowa jest odpowiedzialna za komunikację pomiędzy
+ aplikacjami uruchomionymi na różnych komputerach. Wraz z warstwami
+ poniżej odpowiedzialna jest za komunikację sieciową.
+ </p>
+ <h2 id="1.14.1.transportationofdata">1.14.1. Dostarczanie danych</h2>
+ <p>
+ Warstwa transportowa jest odpowiedzialna za takie czynności jak:
+ </p>
+ <ul>
+ <li>Śledzenie indywidualnych połączeń</li>
+ <li>Segmentacje danych i ich ponowne złożenie</li>
+ <li>Dodanie nagłówka informacji do danych, tworząc segment</li>
+ <li>Identyfikacje, separację oraz zarządzanie wieloma połączeniami</li>
+ <li>Wykorzystanie segmentacji oraz multipleksacji do umożliwienia
+ prowadzenia wielu połączeń w tej samej sieci.</li>
+ </ul>
+ <p>
+ Warstwa IP nie ma możliwość bezpośredniego dostarczenia danych w
+ docelowe miejsce. Określają to protokoły warstwy transportowej są one
+ odpowiedzialne za sposób wymiany danych między hostami oraz
+ za spełnienie wymagań wykorzystywanych połączeń. Protokołami wartsty
+ transportowej są <strong>TCP</strong> oraz <strong>UDP</strong>.
+ </p>
+ <p>
+ Protokoł TCP wybierany jest przez aplikacje wymagające niezawodnego
+ połączenia. Funkcjonalnością warstyw transportowej, za które odpowiada
+ protokół TCP to:
+ </p>
+ <ul>
+ <li>Numerowanie oraz śledzenie segmentów danych dostarczanych do
+ określonych hostów oraz określonych aplikacji</li>
+ <li>Potwierdzenie otrzymania danych</li>
+ <li>Retransmisję każego nie potwierdzonego fragmentu danych, po
+ określonyn czasie.</li>
+ <li>Skwencjonowane dane mogą być dostarczane w dowolnej kolejności</li>
+ <li>Dostosowanie wysyłania danych do możliwości odbiorcy.</li>
+ </ul>
+ <p>
+ Protokoł UDP dostacza bardzo podstawowywch funkcji dostarczania danych
+ między określonymi aplikacjiami, przy minimalnym obciążeniu oraz
+ weryfikacji poprawności przesyłanych danych. Cechami, które wyróżniają
+ ten protokoł jest:
+ </p>
+ <ul>
+ <li>Protokoł UDP jest bezpołączeniowy.</li>
+ <li>Protokół UDP uznawany jest protokoł <em>best-effort</em>, ponieważ
+ nie stosuje on potwierdzeń po otrzymaniu danych.</li>
+ </ul>
+ <p>
+ Protokół UDP jest również wykorzystywany dla aplikacji działajacej na
+ zasadzie żądanie-odpowiedź, gdzie ilość danych jest nie wielka, nie
+ ma tam również retransmisji, przez co taka wymiana informacji może
+ zostać bardzo szybko zrealizowana. Przykład: transmisja głosu (VoIP),
+ komunikacja z DNS. Wymagane cechy:
+ </p>
+ <ul>
+ <li>Szybki</li>
+ <li>Minimalne obciążenie</li>
+ <li>Nie wymaga potwierdzeń</li>
+ <li>Nie wysyła retransmisji</li>
+ <li>Dostarcza dane w kolejności w jakiej dotrą do hosta docelowego</li>
+ </ul>
+ <p>
+ Inne aplikacje, którym bardziej zależy na jakość przesyłanych danych
+ wybiorą transmisję opartą na protokole TCP. Przykład: Poczta
+ elektroniczna (protokoły IMAP/SMTP) czy przeglądanie sieci WWW (HTTP).
+ Wymagane cechy:
+ </p>
+ <ul>
+ <li>Rzetelny</li>
+ <li>Wysyła potwierdzenia otrzymania danych</li>
+ <li>Dokonuje retransmisji zagubionych danych</li>
+ <li>Dostarcza dane w kolejności ich wysłania przez hosta źródłowego.</li>
+ </ul>
+ <h2 id="1.14.2.tcpheader">1.14.2. Nagłówek TCP</h2>
+ <p>
+ Podczas ekapsulacji dane z warstwy aplikacji trafiają do wartstwty
+ transportowej. Tutaj surowe dane z aplikacji są zamieniane w segmenty
+ po dodaniu nagłówka wykorzystywane do transmisji protokołu warstwy
+ transportowej. Poniżej znajduje się obraz przedstawiający nagłówek
+ TCP.
+ </p>
+ <!-- Dodać obrazek z nagłówkiem TCP -->
+ <ul>
+ <li><strong>Port źródłowy</strong> - 16-bitowe pole wykorzystywane do
+ identyfikacji aplikacji źródłowej.</li>
+ <li><strong>Port docelowy</strong> - 16-bitowe pole wykorzystywane do
+ identyfikacji aplikacji docelowej.</li>
+ <li><strong>Numer sekwencji</strong> - 32-bitowe pole przechowywujące
+ numer porządkowy dla celu ponownego złożenia informacji w kolejności
+ w jakiej została wysłana.</li>
+ <li><strong>Numer potwierdzenia</strong> - 32-bitowe pole wykorzysywane
+ do wskazania danych, które zostały otrzymane oraz następny bajt
+ oczekiwany od źródła.</li>
+ <li><strong>Długość nagłówka</strong> - 4-bitowe pole bardziej znane
+ jako offset danych, wskazuje długość nagłówka segmentu TCP.</li>
+ <li><strong>Zarezerowane</strong> - 6-bitowe pole pozostawione do
+ poźniejszego wykorzystania.</li>
+ <li><strong>Bity kontrolne</strong> - 6-bitowe pole zawierające flagi
+ oraz kody bitowe, wskazując cel oraz funkcję tego segmentu TCP.</li>
+ <li><strong>Rozmiar okna</strong> - 16-bitowe pole wskazujące liczbę
+ bajtów, która może być potwierdzona za jednym razem.</li>
+ <li><strong>Suma kontrolna</strong> - 16-bitowe pole używane to
+ do ustalenia poprawności segmentu.</li>
+ <li><strong>Ważność</strong> - 16-bitowe pole wykorzystywane do
+ wskazania ważności (istotności) przesyłanych danych.</li>
+ </ul>
+ <h2 id="1.14.3.udpheader">1.14.3. Nagłowek UDP</h2>
+ <p>
+ Segmenty UDP rownież posiadają nagłówki, jednak nie tak rozbudowne
+ jak w przypadku TCP. Dla porównania nagłówek UDP zawiera tylko 4 pola.
+ </p>
+ <!-- Tutaj wstawić obrazek z nagłówkiem UDP -->
+ <ul>
+ <li><strong>Port źródłowy</strong> - 16-bitowe pole wykorzystywane do
+ identyfikacji aplikacji źródłowej.</li>
+ <li><strong>Port docelowy</strong> - 16-bitowe pole wykorzystywane do
+ identyfikacji aplikacji docelowej.</li>
+ <li><strong>Długość nagłówka</strong> - 4-bitowe pole bardziej znane
+ jako offset danych, wskazuje długość nagłówka datagramu UDP.</li>
+ <li><strong>Suma kontrolna</strong> - 16-bitowe pole używane to
+ do ustalenia poprawności datagramu.</li>
+ </ul>
+ <h2 id="1.14.4.portnumbers">1.14.4. Numery portów</h2>
+ <p>
+ Protokoły TCP oraz UDP wykorzystują numery portów do zarządzania
+ działająch w tym samym czasie połączeń. Port źródłowy wskazuje
+ aplikację źródłową na lokalnym hostście natomast port docelowy
+ aplikację docelową na hoście zdalnym.
+ </p>
+ <p>
+ Porty znajdują się wewnątrz segmentów warstwy transportowej, Segmenty
+ natomiast są enkapsulowane w pakiety IP. Kombinacja adresu IP oraz
+ numeru portu nie ważne, z której strony w transmisji nazwany jest
+ <strong>gniazdem</strong>. Gniazda umożliwiają klientom wielkrotne
+ połączenia z tym samym serwerem, czy tą samą usługą.
+ </p>
+ <p>
+ Portów ze względu na rozmiar pola portu docelowego i źródłego ma
+ długość 16-bitów, to bez modyfikacji nagłówków porty mają zakres
+ od <strong>0</strong> do <strong>65535</strong>. Większość portów jest
+ już przydzielona i mozna je podzielić na trzy mniejsze zakresy,
+ </p>
+ <ul>
+ <li><strong>Dobrze znane porty</strong> - zakres:
+ <strong>0 - 1023</strong> - większość znanych nam usług sieciowych,
+ HTTP, FTP czy poczta.</li>
+ <li><strong>Porty zarejestrowane</strong> - zakres:
+ <strong>1023 - 49151</strong> - Porty przydzielone przez IANA dla
+ aplikacji i procesów, znane porty z tego zakresu np.: 2049/TCP NFS
+ czy 3306/TCP serwer baz danych MySQL.</li>
+ <li><strong>Porty prywatne/dynamiczne</strong> - zakres:
+ <strong>49152 - 65535</strong> - Porty do wykorzystywane przez
+ klienta jako port źródłowy.</li>
+ </ul>
+ <p>
+ Nie będę wypisywał tutaj jakiś list. Wszystko jest dostępne w
+ Internecie lub w dystrybucjach Linuksa w pliku <em>/etc/services</em>.
+ </p>
+ <p>
+ Warto odczasu do czasu zwrócić uwagę na to jakie połaczenia są
+ realizowane w naszym systemie w zależności od systemu możemy
+ wykorzystać do tego albo polecenie <strong>netstat</strong> dla
+ MS Windows lub <strong>ss</strong> dla dystrybucji Linuksa.
+ </p>
+ <h2 id="1.14.5.tcpcommunicationproces">1.14.5. Procesy komunikacji TCP</h2>
+ <p>
+ Każdy proces aplikacji serwera jest skonfigurowany w taki sposób, aby
+ korzystać z portów. Dwie aplikacje na tym samym serwerze nie mogą mieć
+ przypisanych tych samych portów. Aktywna aplikacja z przypisanym
+ portem uznaje się za <strong>otwarą</strong>, oznacza to mniej więcej
+ tyle, że jej proces przyjmie dane przekazane do tego portu. Oznacza to
+ również, że każde żądanie od klientów jest akceptowane i dane
+ przekazywane są do procesu aplikacji.
+ </p>
+ <p>
+ Klient nawiązuje połączenie w tzw. schemacie
+ <em>Three-Way-Handshake</em>. W wygląda to mniej więcej w taki sposób
+ </p>
+ <ol>
+ <li>Klient incjalizuje połaczenie w modelu klient-serwer z serwerem
+ wysyłając do niego segment z ustawioną flagą SYN.</li>
+ <li>Serwer odpowiada na próbę inicjalizacji połączenia odsyłając
+ do klienta segment z ustawionymi flagami SYN, ACK.</li>
+ <li>Klient przesyła odpowiedź do serwera z ustawiona flagą ACK i w ten
+ połączenie zostaje nawiązane.</li>
+ </ol>
+ <p>
+ Zamykanie połączeń odbywa się podobny sposób. Jeśli nie ma więcej
+ danych do przesłania, klient wysyła segment z ustawioną flaga FIN.
+ Następnie serwer wysyła dwa segementy jeden z odpowiedzią na wysłaną
+ flage FIN oraz drugi segment z ustawioną flagą FIN wysłaną do klienta.
+ Kiedy klient odbierze taki segment, potwierdza za pomocą flagi ACK,
+ jego odebranie i połącznie zostaje zakończone.
+ </p>
+ <p>
+ Flagi kontrone wykorzystywane do zarządzania połączeniami TCP:
+ </p>
+ <ul>
+ <li><strong>URG</strong> - Wskaźnik ważności pola <em>Urgent</em>.</li>
+ <li><strong>ACK</strong> - Flaga potwierdzająca wykorzystywana
+ normalnej komunikacji, ale również w przy nawiązywaniu i kończeniu
+ połączeń.</li>
+ <li><strong>PSH</strong> - funkcja push</li>
+ <li><strong>RST</strong> - restartuje połączenie kiedy napotkano błąd
+ lub minął czas oczekiwania.</li>
+ <li><strong>SYN</strong> - Synchonizacja numerów sekwencyjnych,
+ flaga wykorzystywana podczas nawiązywania połączenia.</li>
+ <li><strong>FIN</strong> - Wysyłający nie ma więcej danych, używane
+ do zamykania połączeń</li>
+ </ul>
+ <h2 id="1.14.6.tcpreliabilityandfc">1.14.6. Rzetelność i kontrola przepływu transmisji TCP</h2>
+ <p>
+ W przypadku transmisji sieciowej może dojść do zgubienia części danych
+ (pakietu) z róznych przyczny, rownie istotna może być ścieżka jaką
+ poruszają się pakiety do miejsca docelowego, pakiety z tego samego
+ źródła wysłane inną ścieżką mogą dotrzeć do celu poźniej niż inne.
+ Wówczas warstwa transportowa otrzymała dane nie pokolei. Podobnie jest
+ w przypadku utracenia danych, ponieważ muszą one zostać
+ retransmitowane. Jednak zawarty w nagłówkach numer sekwencji pozwoli
+ mechnizmom zawartym w protokole TCP złożyć widomość, tak aby nie
+ różniła się niczym od tej wysłanej przez nadawcę.
+ </p>
+ <p>
+ Ciekawym mechnizmem może być <strong>SACK</strong>. Załóżmy taki
+ przypadek, że mamy ustawione okno na odpowiedź po 10 segemencie, ale
+ protokoł TCP uznał, że 3 i 4 segment są uszkodzone i wymagana jest ich
+ retransmisja. To w normalnym przypadku nadawca dowiedział by się o tym
+ fakcie dopiero po przesłaniu 10 segmentu. No dobrze troche by to
+ opóźniło transmisje, ale mamy już nasz 3 i 4 segment, a to nie koniec
+ ponieważ okno ustawione na 10 segment, to otrzymamy także segmenty od
+ 5 do 10. To jeśli uda się ustalić w SACK czyli
+ <strong>odpowiedź selektywna</strong>. W momecie gdy nadawca dowiaduje,
+ że potrzebna jest retransmisja w dodatkowym polu w segemencie
+ potwierdzenia zwracany jest numer sekwencyjny segmentu, który wymaga
+ retransmisji ale w dodatkowym polu SACK znajdują się te numery
+ sekwencyjne, które odbiorca już ma i uznał je za poprawne.
+ </p>
+ <p>
+ Kontrola przepływu polega na dostosowaniu ilości wysyłanych danych do
+ możliwości odbiorcy. W przypadku protokołu TCP, kontrola przepływu
+ pomoga utrzymać stabliność i rzetelność tego protokołu. W jedym z
+ takich parametrów jest <strong>MSS</strong>, który określa wielkość
+ danych niesionych w pakietach. Standardowo dla Etherenetu jest 1460B.
+ Maksymalne MTU dla ethernetu to 1500B, od tego musimy odjąć 20B dla
+ nagłówka IP oraz 20B dla nagłówka TCP. Wiec pozostaje 1460B na dane z
+ warstwy aplikacji.
+ </p>
+ <p>
+ Protokół TCP ma również dodatkowe mechanizmy dzięki, którym mocno
+ obciażona stacja robocza, nie zostanie zalana segmentami w momencie
+ kiedy nie jest wstanie odpowiedzieć, tym mechnizmem zarządza nadawca i
+ nazywają sie <em>Congestion Avoidance</em> - unikanie zatorów.
+ </p>
+ <h2 id="1.14.7.udpcommunication">1.14.7. Komunikacja z wykorzystaniem protokołu UDP</h2>
+ <p>
+ Protokół UDP nie zestawia połączenia. Ma on również mały narzut,
+ ponieważ jego nagłówek jest mniejszy i nie zarządza on ruchem.
+ </p>
+ <p>
+ UDP nie korzysta z numerów sekwencji tak jak robi to TCP, przez co nie
+ możliwości uprządkowania pakietów w takiej samej kolejności w jakiej
+ zostały wysłane.
+ </p>
+ <p>
+ Serwery korzystające z transmisji UDP wykorzystują dobrze znane lub
+ zarejestrowane porty. Kiedy datagram UDP dotrze do komputera
+ docelowego jest on przekazywany do aplikacji na podstawie przypisanego
+ jej numery portu.
+ </p>
+ <p>
+ Klienci transmisji UDP przypisują sobie porty dynamicznie, przeważnie
+ z tej ostatniej grupy. Następnie ten port oraz port docelowy są
+ używane w nagłówkach datagramów.
+ </p>
+ <h3 id="1.17.pka">Zadanie praktyczne - Packet Tracer</h3>
+ <p>
+ <a href="">Komunikacja TCP i UDP</a>
+ </p>
+ <h2 id="ch15summary">Podsumowanie</h2>
+ <p>
+ W tym rodziale dowiedzieliśmy za co jest odpowiedzialna warstwa
+ transportowa oraz jakie są jej funkcje. Poznaliśmy dwa protokoły
+ tej warstwy - TCP oraz UDP, scharakteryzowaliśmy ich nagłówki.
+ Następnie skupiliśmy się na opisaniu funkcjonalności protokołu TCP, na
+ koniec krótko został przedstawiony protokół UDP.
+ </p>
<h1 id="1.15.applicationlayer">1.15. Warstwa aplikacji</h1>
<p>
W warstwie aplikacji znajdują się elementy komunikacji sieciowej,
projects / mmdev.git / commitdiff