Dawidowicz
Paweł
PROTOKOŁY
WARSTWY
TRANSPORTOWEJ
W warstwie transportowej w stosie protokołów TCP/IP
może działać:
protokół połączeniowy TCP
protokół bezpołączeniowy UDP
PROTOKOŁY WARSTWY
TRANSPORTOWEJ
Strumieniowy protokół komunikacji między dwoma
komputerami.
TCP jest protokołem działającym w trybie klient-
serwer. Serwer oczekuje na nawiązanie połączenia na
określonym porcie. Klient inicjuje połączenie do
serwera.
W przeciwieństwie do UDP, TCP gwarantuje wyższym
warstwom komunikacyjnym dostarczenie wszystkich
pakietów w całości, z zachowaniem kolejności i bez
duplikatów. Zapewnia to wiarygodne połączenie
kosztem większego narzutu w postaci nagłówka i
większej liczby przesyłanych pakietów.
PROTOKÓŁ TCP
Charakterystyczny dla TCP jest moment nawiązania
połączenia, nazywany three-way handshake. Host
inicjujący połączenie wysyła pakiet zawierający
segment TCP z ustawioną fl agą SYN (synchronize). Host
odbierający połączenie, jeśli zechce je obsłużyć, odsyła
pakiet z ustawionymi fl agami SYN i ACK (acknowledge –
potwierdzenie). Inicjujący host powinien teraz wysłać
pierwszą porcję danych, ustawiając już tylko fl agę ACK
(i gasząc SYN). Jeśli host odbierający połączenie nie
chce lub nie może odebrać połączenia, powinien
odpowiedzieć pakietem z ustawioną fl agą RST (reset).
NAWIĄZYWANIE POŁĄCZENIA
W celu weryfi kacji wysyłki i odbioru TCP
wykorzystuje sumy kontrolne i numery sekwencyjne
pakietów. Odbiorca potwierdza otrzymanie pakietów o
określonych numerach sekwencyjnych ustawiając fl agę
ACK. Brakujące pakiety są retransmitowane. Host
odbierający pakiety TCP defragmentuje je i porządkuje
je według numerów sekwencyjnych tak, by przekazać
wyższym warstwom modelu OSI pełen złożony segment.
TRANSMISJA DANYCH
Prawidłowe zakończenie połączenia może być
zainicjowane przez dowolną stronę. Polega ono na
wysłaniu pakietu z ustawioną fl agą FIN (fi nished).
Pakiet taki wymaga potwierdzenia fl agą ACK.
Najczęściej po otrzymaniu pakietu z fl agą FIN, druga
strona również kończy komunikację wysyłając pakiet z
fl agami FIN i ACK. Pakiet taki również wymaga
potwierdzenia przez przesłanie ACK.
Dopuszcza się również awaryjne przerwanie
połączenia poprzez przesłanie pakietu z fl agą RST
(reset). Pakiet taki nie wymaga potwierdzenia.
ZAKOŃCZENIE POŁĄCZENIA
NAGŁÓWEK TCP
NAGŁÓWEK TCP
Port nadawcy – 16-bitowy numer identyfikujący port
nadawcy.
Port odbiorcy – 16-bitowy numer identyfikujący port
odbiorcy.
Numer sekwencyjny – 32-bitowy identyfikator
określający miejsce pakietu danych w pliku przed
fragmentacją (dzięki niemu, można „poskładać” plik z
poszczególnych pakietów).
Numer potwierdzenia – 32-bitowy numer będący
potwierdzeniem otrzymania pakietu przez odbiorcę, co
pozwala na synchronizację nadawanie-potwierdzenie.
Długość nagłówka – 4-bitowa liczba, która oznacza
liczbę 32-bitowych wierszy nagłówka, co jest niezbędne
przy określaniu miejsca rozpoczęcia danych. Dlatego
też nagłówek może mieć tylko taką długość, która jest
wielokrotnością 32 bitów.
NAGŁÓWEK TCP
Zarezerwowane – 4-bitowy ciąg zer, zarezerwowany dla
ewentualnego przyszłego użytku.
Flagi 8-bitowa informacja/polecenie dotyczące bieżącego
pakietu. Poszczególne flagi oznaczają:
CWR – (ang. Congestion Window Reduced) flaga
potwierdzająca odebranie powiadomienia przez nadawcę,
umożliwia odbiorcy zaprzestanie wysyłania echa.
ECE – (ang. ECN-Echo) flaga ustawiana przez odbiorcę w
momencie otrzymania pakietu z ustawioną flagą CE
URG – informuje o istotności pola „Priorytet”
ACK – informuje o istotności pola „Numer potwierdzenia”
PSH – wymusza przesłanie pakietu
RST – resetuje połączenie (wymagane ponowne uzgodnienie
sekwencji)
SYN – synchronizuje kolejne numery sekwencyjne
FIN – oznacza zakończenie przekazu danych
NAGŁÓWEK TCP
Szerokość okna – 16-bitowa informacja o tym, ile
danych może aktualnie przyjąć odbiorca. Wartość 0
wskazuje na oczekiwanie na segment z innym numerem
tego pola. Jest to mechanizm zabezpieczający komputer
nadawcy przed zbyt dużym napływem danych.
Suma kontrolna – 16-bitowa liczba, będąca wynikiem
działań na bitach całego pakietu, pozwalająca na
sprawdzenie tego pakietu pod względem poprawności
danych.
Wskaźnik priorytetu – jeżeli flaga URG jest włączona,
informuje o ważności pakietu.
Opcje – czyli ewentualne dodatkowe informacje i
polecenia:
0 – koniec listy opcji
1 – brak działania
2 – ustawia maksymalna długość segmentu
Aplikacje, w których zalety TCP przeważają nad
wadami (większy koszt związany z utrzymaniem sesji
TCP przez stos sieciowy), to m.in. programy używające
protokołów warstwy aplikacji: HTTP, SSH, FTP czy
SMTP/POP3 i IMAP4.
ZASTOSOWANIE PROTOKOŁU
TCP
User Datagram Protocol (protokół pakietów
użytkownika)
Jest to protokół bezpołączeniowy, więc nie ma
narzutu na nawiązywanie połączenia i śledzenie sesji
(w przeciwieństwie do TCP). Nie ma też mechanizmów
kontroli przepływu i retransmisji. Korzyścią płynącą z
takiego uproszczenia budowy jest większa szybkość
transmisji danych i brak dodatkowych zadań, którymi
musi zajmować się host posługujący się tym
protokołem. Z tych względów UDP jest często używany
w takich zastosowaniach jak wideokonferencje,
strumienie dźwięku w Internecie i gry sieciowe, gdzie
dane muszą być przesyłane możliwie szybko, a
poprawianiem błędów zajmują się inne warstwy modelu
OSI. Przykładem może być VoIP.
PROTOKÓŁ UDP
UDP udostępnia mechanizm identyfi kacji różnych
punktów końcowych (np. pracujących aplikacji, usług
czy serwisów) na jednym hoście dzięki portom. UDP
zajmuje się dostarczaniem pojedynczych pakietów,
udostępnionych przez IP, na którym się opiera. Kolejną
cechą odróżniającą UDP od TCP jest możliwość
transmisji do kilku adresów docelowych na raz (tzw.
multicast).
Pakiety UDP, zwane też datagramami, zawierają
oprócz nagłówków niższego poziomu nagłówek UDP.
Składa się on z pól zawierających sumę kontrolną,
długość pakietu oraz porty: źródłowy i docelowy.
PROTOKÓŁ UDP
NAGŁÓWEK UDP
Port nadawcy - identyfi kuje port, z którego została
wysłana wiadomość, kiedy znaczący to wskazuje port
wysyłającego procesu i może zostać przyjęty 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
używane przyjmuje wartość zero.
Port odbiorcy - identyfi kuje port odbiorcy i jest polem
wymaganym.
PROTOKÓŁ UDP
Długość - 16-bitowe pola specyfi kują 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 użyte do
sprawdzania poprawności nagłówka oraz danych. Pole
jest opcjonalne. Ponieważ IP nie wylicza sumy
kontrolnej dla danych, suma kontrolna UDP jest jedyną
gwarancją, że dane nie zostały uszkodzone.
PROTOKÓŁ UDP
Dawidowicz
Paweł
PROTOKOŁY
WARSTWY
APLIKACJI
Przesyłania plików
TFTP
FTP
NFS
Email:
SMTP
IMAP
Zdalne logowanie
TELNET
SSH
rLoggin
Zarządzanie siecią
SNMP
Zarzadzanie nazwami
DNS
PROTOKOŁY WARSTWY
APLIKACJI
FTP - File Transfer Protocol (Protokół Transferu
Plików) -protokół typu klient-serwer, który umożliwia
przesyłanie plików z serwera i na serwer.
HTTP - Hypertext Transfer Protocol – protokół
przesyłania dokumentów hipertekstowych) to protokół
sieci WWW.
SMTP - Simple Mail Transfer Protocol – protokół
komunikacyjny opisujący sposób przekazywania
poczty elektronicznej.
PROTOKOŁY WARSTWY
APLIKACJI
POP3 - Post Offi ce Protocol version – protokół
internetowy pozwalający na odbiór poczty elektronicznej.
IMAP - Internet Message Access Protocol – protokół
pocztowy zaprojektowany jako następca POP3. W
przeciwieństwie do POP3, który umożliwia jedynie
pobieranie i kasowanie poczty, IMAP pozwala na
zarządzanie wieloma folderami pocztowymi oraz
pobieranie i operowanie na listach znajdujących się na
zdalnym serwerze.
DNS - Domain Name System – to system serwerów,
protokół komunikacyjny oraz usługa zapewniająca
zamianę adresów znanych użytkownikom Internetu na
adresy zrozumiałe dla urządzeń tworzących sieć
komputerową
PROTOKOŁY WARSTWY
APLIKACJI