Warstwa transportowa: TCP i UDP.
TCP
Transmission Control Protocol.
RFC 793.
Oprogramowanie TCP tworzy połączenia (connection) między dwoma procesami z
jednoczesną dwukierunkową transmisją.
Połączenie TCP
TCP łączy dwa punkty końcowe, które są identyfikowane przez parę: nr IP oraz nr
portu. Połączenie identyfikowane jest przez cztery liczby: dwa numery IP oraz
dwa numery portów. Dzięki temu można np. realizować serwery współbieżne
działające z tymi samymi numerami portów (wyjaśnienie na wykładzie).
Pomiędzy procesami wymieniany jest strumień 8-bitowych tzw. oktetów (bajtów).
Stąd mówi się o usłudze strumienia bajtów. W strumieniu nie są umieszczane
automatycznie żadne znaczniki rekordów. Bajty wysyłane są w segmentach (por.
poprzedni wykład), porcjami, ale aplikacja docelowa nie jest w stanie określić
wielkości poszczególnych porcji w źródle.
Ważne cechy TCP:
Partnerzy (komunikujące się procesy) tworzą połączenie z wykorzystaniem
mechanizmu uzgodnienia (uzgadnianie trójfazowe
three-way handshake).
Zamknięcie połączenia odbywa się z wykorzystaniem mechanizmu uzgodnienia,
podczas którego partnerzy wyrażają zgodę na zamkniecie połączenia.
TCP zapewnia sterowanie przepływem. Informuje partnera o tym ile bajtów danych
może od niego przyjąć (okno oferowane
advertized window). Rozmiar okna jest
równy rozmiarowi wolnego miejsca w buforze odbiorcy. Rozmiar ten zmienia się
dynamicznie. Zero oznacza, że nadawca musi zaczekać, aż program użytkowy
odbierze dane z bufora.
Dane dzielone są na fragmenty, które według TCP mają najlepszy do przesłania
rozmiar. Jednostka przesyłania danych nazywa się segmentem.
TCP zapewnia niezawodność połączenia.
Mechanizmy niezawodności:
Potwierdzanie otrzymania segmentów z mechanizmem zegara. Odebrany segment musi
być potwierdzony przez odbiorcę przez wysłanie segmentu potwierdzającego. Jeśli
potwierdzenie nie nadejdzie w odpowiednim czasie, segment zostanie przesłany
powtórnie. Czas oczekiwania zmienia się dynamicznie i zależy od stanu sieci
(obciążenia).
Sumy kontrolne. Jeśli segment zostanie nadesłany z niepoprawna sumą kontrolną,
to jest odrzucany i nie jest przesyłane potwierdzenie odbioru (w nadziei, że
nadawca po odczekaniu odpowiedniego czasu prześle utracony segment jeszcze
raz).
Przywracanie kolejności nadchodzących segmentów. Segmenty mogą nadchodzić w
kolejności innej niż zostały wysłane, oprogramowanie TCP przywraca prawidłową
kolejność przed przekazaniem do aplikacji.
Odrzucanie zdublowanych danych (pakietów). Może się zdarzyć, że pakiet zostanie
przesłany powtórnie, ale pierwszy pakiet nie zaginie i do odbiorcy dotrą dwa.
Wówczas jeden z pakietów należy odrzucić.
Porty
numery.
IANA (Internet Assigned Numbers Authority).
RFC 1700.
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
0..65535.
IANA
1..1023
porty ogólnie znane
1024..49151
zarejestrowane
41152 ..65535
dynamiczne (efemeryczne) lub prywatne.
(W Unix BSD 1..1023 zarezerwowane, 1024-5000 efemeryczne, 5001-65535
nieuprzywilejowane).
Powszechne usługi w implementacjach TCP/IP:
Nazwa Port TCP i UDP RFC
echo 7 862 serwer zwraca wszystko co wysyła klient
discard 9 863 serwer odrzuca wszystko
daytime 13 867 data i czas
chargen 19 864 TCP generuje nieprzerwany ciąg znaków do zakończenia
połączenia, UDP generuje ciąg o losowej długości
time 37 868 czas
liczba sekund od 01-01-1990 UTC
telnet 23
ssh 22
http 80
ftp 21
Segment TCP, nagłówek segmentu.
Enkapsulacja segmentu TCP w datagramie IP.
0 15 16 31
16-bitowy numer portu źródłowego
16-bitowy numer portu docelowego
4-bajtowy numer sekwencji pierwszego oktetu w strumieniu danych.
4-bajtowy numer potwierdzenia
4-bitowa długość nagłówka
Rezerwa (6 bitów)
zera
URG
ACK
PSH
RST
SYN
FIN
16-bitowy rozmiar okna
16 bitowa suma kontrolna TCP
16 bitowy wskaźnik ważności
Opcje (jeśli są)
Dane (jeśli są)
Dodatkowe objaśnienia:
Numer sekwencji. Dla segmentu ze znacznikiem SYN w pole wpisuje się numer
sekwencji początkowej, tzw. ISN (Initial Sequence Number). Pierwszy oktet
danych ma numer ISN+1. ISN jest ustalany na podstawie licznika 32 bitowego
[zakres 0..232-1]. RFC 793 określa, że numer ISN powinien rosnąć co 4
mikrosekundy. W praktycznych implementacjach jest inaczej, np. zwiększanie o
64000 co pół sekundy. Co kilka godzin licznik się zeruje.
Numer potwierdzenia jest ważny tylko przy włączonym znaczniku ACK. Jest to
kolejny numer bajtu, którego spodziewa się wysyłający potwierdzenie.
Długość nagłówka (w protokole pole to jest określone jako przesunięcie danych).
Wielkość nagłówka wyrażona w liczbie bloków 4-bajtowych.
Znaczniki (będą wyjaśniane dokładnie później):
URG
wskaźnik ponaglenia,
ACK
segment potwierdzenia,
PSH
segment "push"
wypchnięcie danych,
RST
zresetowanie połączenia,
SYN
synchronizacja,
FIN
nadawca zakończył przesyłanie danych.
Rozmiar okna. Oznacza liczbę bajtów, które odbiorca chce zaakceptować
(poczynając od bajtu o numerze podanym w polu numer potwierdzenia).
Suma kontrolna. Liczona dla nagłówka i danych, z użyciem pseudonagłówka liczona
tak jak w UDP (wyjaśnienie przy UDP).
Wskaźnik ważności. Dodatnie przesunięcie, które musi być dodane do pola
przesunięcia sekwencyjnego aby uzyskać numer ostatniego bajtu ważnych danych.
Opcje. Rodzaj opcji (bajt), długość opcji (bajt), opcja. Najważniejsza opcja to
MSS
Maximum Segment Size. Może być uzyskana jako MTU (Maximum Transmission
Unit) minus rozmiar nagłówka IP oraz TCP. Dla MSS rodzaj opcji określony jast
liczbą 2, długość opcji wynosi 4 (cały wpis), dwa kolejne bajty to wartość MSS.
Przykładowo dla Ethernetu MTU=1500, stąd MSS=1500
40 = 1460 (40 bajtowy
minimalny rozmiar nagłówków IP i TCP). Wartość domyślna MSS (jeśli nie podany)
wynosi 536. MSS podawany jest w segmencie SYN.
Nawiązywanie i zamykanie połączenia, przesyłanie danych.
klient serwer
Wymiana pakietów przez połączenie TCP, nawiązywanie i zakończenie połączenia.
zwykłe przejście między stanami klienta
zwykła przejście między stanami serwera
SYN / SYN, ACK = odbiór SYN / wysłanie ACK
[ ] - nic
Diagram przejść między stanami połączenia TCP.
Technika opóźnionego potwierdzania.
Specyfika stanu TIME WAIT.
2MSL (Maximum Segment Life). W RFC 793 określony jako 2 minuty, w praktyce od
30 sekund do 2 minut. Spóźnione segmenty są w tym czasie odrzucane. Para
punktów końcowych definiujących połączenie nie może być powtórnie użyta przed
upływem 2MSL.
Czas milczenia
na wypadek awarii hosta po przejściu do TIME WAIT.
Półzamknięcie TCP.
Strona, która zakończyła połączenie i nie nadaje danych może dane odbierać od
partnera TCP. Takie połączenie nazywane jest połączeniem półzamkniętym
(half-close).
Przykład:
rsh komputer sort < plikdanych
Segmenty RST.
Segment RST wysyłany jest przez oprogramowanie implementujące TCP kiedy
nadchodzi segment niepoprawny z punktu widzenia połączenia. W protokole UDP w
przypadku nadejścia datagramu na port, nie będący w użyciu generowany jest
komunikat ICMP o tym, ze port jest nieosiągalny. TCP używa tu segmentów RST
(nie komunikatów ICMP).
Segment RST powoduje przerwanie połączenia (nie jest potwierdzany).
Połączenia półotwarte
jeśli jedna ze stron przerwała połączenie bez
informowania drugiej (np. host uległ awarii). Przykład
wyłączenie komputera z
uruchomionym telnetem.
Jednoczesne otwarcie.
Wymiana czterech segmentów. Nie określa się serwera i klienta.
Jednoczesne zamknięcie.
Skumulowane potwierdzanie.
Segment PSH.
Wysyłanie natychmiastowe segmentu (nawet, jeśli zawierałby jeden bajt danych).
Dane pilne (URG).
Przekazywane do aplikacji poza głównym strumieniem bajtów.
Przekroczenie czasu i retransmisja.
Oparte o RTT (Round Trip Time).
Problem niejednoznaczności potwierdzenia.
Algorytm Karna
adaptacyjny, nie uwzględnia segmentów retransmitowanych przy
liczeniu RTT, ale powiększa czas oczekiwania.
Reakcja na przeciążenie.
Przy przeciążeniu sieci powinien być zwiększany czas oczekiwania. Proste
implementacje tylko retransmitujące segmenty powiększają jeszcze obciążenie w
sieci.
Dozwolone okno = min (proponowane, okno przeciążeniowe).
Algorytm
przy zgubieniu segmentu zmniejsz okno przeciążeniowe o połowę.
W drugą stronę algorytm jest inny
zwiększanie okna przeciążeniowego o jeden
segment.
Małe pakiety i syndrom "głupiego okna".
Po stronie odbiorcy
oferowanie okna co najmniej np. 50% całkowitej pojemności
bufora.
Po stronie nadawcy
przed uzyskaniem potwierdzenia nie wysyłaj, chyba, że
uzbiera się maksymalny rozmiar.
UDP
User Datagram Protocol.
RFC 768.
UDP jest protokołem bezpołączeniowym. Nie realizuje buforowania przychodzących
i wychodzących danych (musi to zapewnić aplikacja).
UDP nie zapewnia niezawodności, nie ma żadnej gwarancji, że datagramy dotrą do
miejsca przeznaczenia.
Aplikacja jest odpowiedzialna za rozmiar wysyłanego datagramu. Jeśli wielkość
przekroczy MTU sieci, wówczas datagram IP jest dzielony (fragmentacja IP).
Datagram UDP
20 bajtów 8 bajtów
Enkapsulacja UDP
Nagłówek UDP.
0 15 16 31
16 bitowy numer portu źródłowego
16 bitowy numer portu docelowego
16 bitowa długość UDP (nagłówek + dane)
16 bitowa suma kontrolna UDP
Dane (jeśli są)
Suma kontrolna.
Algorytm dodaje liczby 16 bitowe, stąd możliwa konieczność uzupełnienia
datagramu o bajt 0. To dodanie występuje tylko w algorytmie wyliczania sumy
kontrolnej. Dodatkowy bajt nie jest przesyłany.
Podobnie 12 bajtowy pseudonagłówek:
Pseudonagłówek:
32 bity adres IP źródła,
32 bity adres IP celu,
8 zer
8 bitów typ protokołu (UDP = 17)
16 bitów długość UDP (powtórzona)
Algorytm jest taki sam jak dla sumy kontrolnej nagłówka IP:
16 bitowe porcje uzupełniane są do 1 (tzn. 1 zamieniane na 0 i odwrotnie), tak
otrzymane słowa są dodawane i wynik jest ponownie uzupełniony do 1.
Zastosowanie UDP: jeśli warstwa aplikacji realizuje niezawodność, dostarczanie
grupowe.
Wyszukiwarka
Podobne podstrony:
inf sc w4inf sc w2inf sc w1inf sc w5Inf i Stat w Bad Nauk 2012 w3PÄ…czki twarogowepca w3inf rak mutgW3, Wiazania atomowePanasonic SC HT1000inf kolo1informatyka II w3nw asd w3inf stos) 4Optymalizacja w3 a pdfOPEL sc 303DROGI w2 w3 tyczeniewięcej podobnych podstron