Protokoły Warstwy transportowej Funkcjonowanie TCP iudp oparte jest na usługach zapewnianych przez protokół IP. IP zapewnia bezpołczeniow usług przesyłania datagramów midzy maszynami. Przy uyciu TCP lub UDP dane s przesyłane pomidzy procesami/programami. Do identyfikacji procesów słu tzw. porty TCP (ang. Transmission Control Protocol - Protokół Sterowania Transmisji) strumieniowy protokół komunikacji midzy dwoma komputerami. Został stworzony przez Vintona Cerfa i Roberta Kahna. Jest on czci wikszej całoci okrelanej jako stos TCP/IP. W modelu OSI TCP odpowiada warstwie Transportowej. TCP zapewnia wiarygodne połczenie dla wyszych warstw komunikacyjnych przy pomocy sum kontrolnych numerów sekwencyjnych pakietów weryfikacji wysyłki i odbioru. Brakujce pakiety s obsługiwane przez dania retransmisji. Host odbierajcy pakiety TCP porzdkuje je według numerów sekwencyjnych tak, by przekaza wyszym warstwom modelu OSI pełen, złoony segment. Chocia protokół definiuje pakiet TCP, to z punktu widzenia wyszej warstwy oprogramowania, dane płynce połczeniem TCP naley traktowa jako cig oktetów. W szczególnoci jednemu wywołaniu funkcji API (np. send()) nie musi odpowiada wysłanie jednego pakietu. Dane z jednego wywołania mog zosta podzielone na kilka pakietów dane z kilku wywoła mog zosta połczone i wysłane jako jeden pakiet (dziki uyciu algorytmu Nagle'a). Równie funkcje odbierajce dane (recv()) w praktyce odbieraj nie konkretne pakiety, ale zawarto bufora stosu TCP/IP, wypełnianego sukcesywnie danymi z przychodzcych pakietów. Nagłówek TCP
Zawarto pól: port ródłowy (16 bitów) i pole port docelowy (16 bitów) zawieraj numery portów procesów aplikacyjnych korzystajcych z usług TCP. Kombinacja tych numerów z adresami sieciowymi okrela par gniazd tworzcych połczenie protokołu TCP. numer sekwencyjny (32 bity) zawiera numer sekwencyjny pierwszego bajtu danych w segmencie. Ta warto okrela pozycj segmentu w strumieniu bajtów. Podczas ustanawiania połczenia, i jeli bit syn w polu znaczniki jest ustawiony na 1, to w tym polu zawarty jest inicjujcy numer sekwencyjny ins, od którego rozpoczyna si numeracj bajtów w połczeniu. Zatem pierwszy wysłany bajt ma numer ins + 1. numer potwierdzenia (32 bity) zawiera numer sekwencyjny nastpnego oczekiwanego bajtu po stronie odbiorczej. Jednoczenie jest to potwierdzenie poprawnego odbioru bajtów o numerach sekwencyjnych mniejszych od zawartego w tym polu. Potwierdzenia mówi nadawcy ile bajtów danych zostało ju poprawnie odebranych. długo nagłówka (4 bity) okrela liczb 32 - bitowych słów w nagłówku segmentu TCP. Tym samym okrelone zostaje miejsce, w którym rozpoczynaj si dane. Pole to ma tak okrelone znaczenie tylko wtedy, gdy bit ack równy jest 1. rezerwa (6 bitów) jest przeznaczone dla przyszłych zastosowa. Zawiera same zera. znaczniki składa si z szeciu bitów sterujcych, które ustawione na 2 maj nastpujce znaczenie: o UGR - wskazuje na wano pola wskanik pilnoci, o ACK - wskazuje na wano pola numer potwierdzania, o PSH - wskazuje na działanie funkcji wymuszajcej wysyłanie segmentu, o RST - wyzerowanie połczenia, o SYN - wskazuje, e w polu numer sekwencyjny umieszczony jest inicjujcy numer sekwencyjny INS. Jest on przeznaczony do synchronizacji numerów sekwencyjnych w fazie ustanowienia połczenia. o FIN - wskazuje, e nadawca nie ma nic wicej do nadania - sygnał koca danych. okno (16 bitów) okrela liczb bajtów jak moe jeszcze zaakceptowa odbiorczy moduł TCP. suma kontrolna jest 16 - bitowym jedynkowym uzupełnieniem jedynkowo uzupełnionej sumy wszystkich 16 - bitowych słów w segmencie. Ta suma obejmuje zarówno nagłówek jak i dane segmentu. wskanik pilnoci (16 bitów) jest interpretowane tylko wtedy, gdy bit UGR jest równy 1. Pole to zawiera numer sekwencyjny bajtu nastpujcego po pilnych danych. opcje ma długo zmienn bdc wielokrotnoci 8 bitów. Zawiera ono numery opcji - kady numer zapisany w jednym bajcie. Dla protokołu TCP zdefiniowano trzy opcje: o 0 - koniec listy opcji, o 1 - brak działania, o 2 - maksymalna długo segmentu.
wypełnienie uzupełnia nagłówek do wielokrotnoci 32 bitów Przebieg transmisji Nawizania połczenia, nazywany ang. three-way handshake. Host inicjujcy połczenie wysyła pakiet zawierajcy segment TCP z ustawion flag SYN (synchronize) i z proponowanym numerem INS w polu numer sekwencyjny. Host odbierajcy połczenie, jeli zechce je obsłuy, odsyła pakiet z ustawionymi flagami SYN i ACK (acknowledge potwierdzenie) a w polu numer sekwencyjny podaje numer INS, z którym rozpocznie działanie. Inicjujcy host wysyła pierwsz porcj danych, ustawiajc ju tylko flag ACK (gaszc SYN). Jeli host odbierajcy połczenie nie chce lub nie moe odebra połczenia, powinien odpowiedzie pakietem z ustawion flag RST (Reset). Dla zapewnienia niezawodnej transmisji TCP wykorzystuje sekwencyjn numeracj bajtów oraz mechanizm pozytywnych potwierdze z retransmisj. Numer sekwencyjny przypisany do kadego przesyłanego bajtu danych pozwala na jego jednoznaczn identyfikacj, a take jest uywany w mechanizmie przesyłania potwierdze. Poniewa kolejne bajty s numerowane poczwszy od INS, a zatem numer pierwszego bajtu wysłanego w połczeniu wirtualnym wynosi INS+1 (zazwyczaj INS=0). Nadawczy moduł TCP dokonuje retransmisji danych do czasu, a otrzyma potwierdzenie poprawnego ich przyjcia przez odbiorczy moduł TCP. Rozpoczcie retransmisji uwarunkowane jest przekroczeniem wczeniej ustalonego czasu oczekiwania na nadejcie potwierdzenia. Po stronie odbiorczej poprawno odbioru danych sprawdzana jest przy uyciu pola suma kontrolna znajdujcego si w nagłówku segmentu. Jeeli dane s akceptowane to moduł TCP wysyła zwrotnie pozytywne potwierdzenie. Jest ono zawarte w polu numer potwierdzenia. Wszystkie bajty danych o numerach sekwencyjnych mniejszych od wartoci zawarte w tym polu zostały odebrane poprawnie. W sytuacji, gdy dane zostały odebrane poprawnie, a nadawczy moduł TCP retransmitował je np. z powodu zaginicia segmentu z pozytywnym potwierdzeniem, odbiorczy moduł TCP ma moliwo odrzucenia nadmiarowych danych (duplikatów). Prawidłowe zakoczenie połczenia polega na wysłaniu flagi FIN. Algorytm Nagle'a jest metod poprawienia efektywnoci sieci TCP/IP za pomoc zmniejszenia liczby pakietów koniecznych do przesłania. Dokument Congestion Control in IP/TCP Internetworks (RFC 896) opisuje "problem małych pakietów", czyli sytuacj, w której aplikacja wysyła dane w małych porcjach, czsto po jednym bajcie. Poniewa pakiet TCP ma 40 bajtowy nagłówek, w efekcie przesyłany jest 41-bajtowy pakiet z jednym bajtem uytecznej informacji, co jest niepotrzebnym narzutem. Taka sytuacja ma miejsce np. w trakcie sesji protokołu Telnet, kiedy kade nacinicie klawisza generuje jeden bajt danych, który jest natychmiast wysyłany. Algorytm Nagle'a polega na łczeniu kilku krótkich komunikatów i wysyła je w jednym pakiecie. W szczególnoci, dopóki na ostatnio wysłany pakiet nie otrzymano potwierdzenia, wysyłajcy powinien buforowa wychodzce komunikaty do momentu, a zbierze si ilo warta wysłania w kolejnym pakiecie. Algorytm Nagle'a niepoprawnie współpracuje z opónionym potwierdzeniem TCP, wprowadzonym niemal w tym samym czasie. Gdy oba te algorytmy s włczone, wykonanie dwóch kolejnych operacji wysłania i nastpujcej po nich operacji czytania, moe skutkowa opónieniem do 500 ms, tzw. "ACK delay". Z tego powodu implementacje TCP umoliwiaj wyłczenie algorytmu Nagle'a, zazwyczaj jest to opcja NO_DELAY. Pierwsz znaczc aplikacj, w której zaobserwowano ten problem był X Window System.
UDP (ang. User Datagram Protocol - Protokół Datagramów Uytkownika) jeden z podstawowych protokołów internetowych. Umieszcza si go w warstwie czwartej (transportu) modelu OSI. Jest to protokół bezpołczeniowy, wic nie ma narzutu na nawizywanie połczenia i ledzenie sesji (w przeciwiestwie do TCP). Nie ma te mechanizmów kontroli przepływu i retransmisji. Korzyci płync z takiego uproszczenia budowy jest wiksza szybko transmisji danych i brak dodatkowych zada, którymi musi zajmowa si host posługujcy si tym protokołem. Z tych wzgldów UDP jest czsto uywany w takich zastosowaniach jak wideokonferencje, strumienie dwiku w Internecie i gry sieciowe, gdzie dane musz by przesyłane moliwie szybko, a poprawianiem błdów zajmuj si inne warstwy modelu OSI. Innym przykładem moe by protokół DNS lub VoIP. UDP udostpnia mechanizm identyfikacji rónych punktów kocowych (np. pracujcych aplikacji, usług czy serwisów) na jednym hocie dziki portom (porównaj: socket). UDP zajmuje si dostarczaniem pojedynczych pakietów, udostpnionych przez IP, na którym si opiera. Kolejn cech odróniajc UDP od TCP jest moliwo transmisji do kilku adresów docelowych na raz (tzw. multicast). Nagłówek UDP Pola nagłówka: Port nadawcy identyfikuje port, z którego została wysłana wiadomo, kiedy znaczcy to wskazuje port wysyłajcego procesu i moe zosta przyjty jako port, do którego powinna zosta zwrócona wiadomo zwrotna w przypadku braku innej informacji. Port nadawcy jest polem opcjonalnym. Gdy pole to nie jest uywane przyjmuje warto zero. Port odbiorcy identyfikuje port odbiorcy i jest polem wymaganym. Długo 16-bitowe pola specyfikuj długo w bajtach całego datagramu: nagłówek i dane. Minimalna długo to 8 bajtów i jest to długo nagłówka. Wielko pola ustala teoretyczny limit 65,527 bajtów, dla danych przenoszonych przez pojedynczy datagram UDP. Suma kontrolna 16 bitowe pole, które jest uyte do sprawdzania poprawnoci nagłówka oraz danych. Pole jest opcjonalne. Poniewa IP nie wylicza sumy kontrolnej dla danych, sum kontrolna UDP jest jedyn gwarancj, e dane nie zostały uszkodzone.
Lista niektórych standardowych usług: 20 FTP - dane 21 FTP 22 SSH 23 Telnet 25 SMTP 53 DNS 70 Gopher 80 HTTP 109 POP2 110 POP3 119 NNTP 137 NetBios - serwer nazw 143 IMAP 161 SNMP 162 SNMP - komunikaty Trap 179 BGP 443 HTTPS 995 POP3S (POP3 z uyciem SSL) Nr portów w TCP i UDP zapisywane s na dwóch bajtach (szesnastu bitach), wic kady adres IP moe mie przypisanych 65536 rónych zakocze. Z przyczyn historycznych, porty 0-1023 zarezerwowane s dla dobrze znanych usług sieciowych - dla aplikacji uytkownika przydziela si porty od 1024.