Połączeniowe Mechanizmy Protokołu Transportuzskl.p.lodz.pl/~lipkap/PSK/tcp_2005.pdf ·...

72
Polączeniowe Mechanizmy Protokolu Transportu Polączenie logiczne Zestawienie polączenia Zerwanie polączenia Niezawodne Np. TCP

Transcript of Połączeniowe Mechanizmy Protokołu Transportuzskl.p.lodz.pl/~lipkap/PSK/tcp_2005.pdf ·...

Połączeniowe Mechanizmy

Protokołu Transportu

�Połączenie logiczne�Zestawienie połączenia�Zerwanie połączenia�Niezawodne�Np. TCP

Niezawodna, Uporządkowana

Usługa Sieciowa

�Przyjmijmy dowolną długość wiadomości�Przyjmijmy właściwie 100% pewność dostarczenia przez sieć�np. niezawodna sieć pakietowa oparta na X.25�np. frame relay przy użyciu kontrolnego protokołu LAPF

�np. IEEE 802.3 przy użyciu usługi połączeniowej LLC

�Usługa transportu jest protokołem dwu-końcowym (end-to-end) pomiędzy dwoma systemami w tej samej sieci

Zagadnienia w Prostym

Protokole Transportu

�Adresowanie�Multipleksowanie�Kontrola strumienia danych�Zestawianie i zrywanie połączenia

Adresowanie

� Docelowy użytkownik określony przez :�Identyfikacja użytkownika

⌧Zwykle host, port• Nazywana gniazdem (socket) w TCP

⌧Port reprezentuje konkretną usługę transportu (TS) użytkownika

�Identyfikacja jednostki transportu⌧Zwykle tylko jedna na jednego hosta⌧Jeśli więcej niż jedna to zwykle jedna danego typu

• Wybrać protokół transportu (TCP, UDP)

�Adres hosta⌧Podłączona karta sieciowa⌧W internecie adres IP

�Numer sieci

Szukanie Adresów

�Cztery metody�Adres znany od razu

⌧np. zestaw danych karty sieciowej

�Dobrze znane adresy�Serwer nazw�Wysyłanie żądania procesu na dobrze znany adres

Multipleksowanie

�Wielu użytkowników używa tego samego protokołu transportu

�Użytkownicy identyfikowani przez numer portu bądź punkt dostępu do usługi (SAP)

�Multipleksować można także usługi sieciowe�np. multipleksowanie jednego wirtualnego połączenia X.25 do kilku użytkowników protokołu transportu⌧X.25 obciąża za czas korzystania z wirtualnego połączenia

Kontrola Strumienia Danych

�Dłuższe opóźnienie pomiędzy jednostkami transportu niż właściwy czas przesłania�Opóźnienie w wymianie informacji o kontroli strumienia

�Różne wartości opóźnień�Trudno używać pola odliczania (timeout)

�Strumień musi być kontrolowany, ponieważ:�Odbiorca może nie nadążać�Jednostka transportu po stronie odbiorcy może nie nadążać

�Kończy się wypełnieniem bufora

Jak radzić sobie z

wymaganiami strumienia (1)

�Nic nie robić�Segmenty które zalewają odbiorcę są odrzucane�Nadawca nie otrzyma ACK i powtórzy transmisję

⌧Dalsze zwiększenie napływu danych

�Odrzucenie kolejnych segmentów�Niezręczne�Multipleksowane połączenia są kontrolowane na jednym, zagregowanym strumieniu

Jak radzić sobie z

wymaganiami strumienia(2)

�Używać protokołu przesuwającego okna o stałym rozmiarze�Analogicznie do protokołów warstwy liniowej�Działa dobrze na stosunkowo niezawodnej sieci

⌧Nieodebranie ACK jest tratowane jako sygnał kontroli strumienia danych

�Nie działa dobrze na nieefektywnej sieci⌧Nie można rozróżnić pomiędzy zgubionym segmentem, a kontrolą strumienia

�Użyć schemat kredytu

Schemat Kredytu

�Większa kontrola w niezawodnych sieciach�Bardziej efektywna w zawodnych sieciach�Rozszczepia kontrolę strumienia i ACK

�Można wysłać ACK z pozwoleniem na dalszy strumień danych bądź bez

�Każdy oktet ma numer sekwencyjny�Każdy segment ma zawarty w nagłówku numer sekwencyjny, numer ACK i wielkość okna

Użycie Pól w Nagłówku

�Kiedy wysyłamy segment, numer sekwencyjny to numer pierwszego oktetu w tym segmencie

�ACK zawiera AN=i, W=j (numer ACK, rozmiar okna)

�Wszystkie oktety do SN=i-1 są potwierdzone�Następny jest spodziewany oktet i

�Zezwolenie na wysłanie dodatkowego okna W=j oktetów�i.e. Oktety do i+j-1

Alokacja Kredytu

Perspektywy Nadania i Odbioru

Zestawianie i zrywanie

połączenia

�Zezwolić by każdy koniec połączenia wiedział o drugim końcu

�Negocjacja opcjonalnych parametrów�Pociąga za sobą przypisanie zasobów jednostek transportu

�Przez wzajemne przypisanie

Diagram Stanu Połączenia

Zestawianie Połączenia

Nie Słucha

�Odrzucić z RST (Reset)�Zakolejkować żądanie dopóki odpowiednia komenda otwarcia nie zostanie wysłana

�Zasygnalizować użytkownikowi pilne żądanie�May replace passive open with accept

Zrywanie Połączenia

�Oba lub jeden koniec�Przez obustronne porozumienie�Nagłe zerwanie�Lub grzeczne odłączenie

�Stan oczekiwania zamknięcia musi przyjmować dane dopóki FIN nie zostanie odebrane

Zakończenie połączenia

Gwałtowne zerwanie ze stratą danych

Zakończenie połączenia

Problem dwóch armii

Strona Zrywająca

�Użytkownik wysyła żądanie zamknięcia sesji (Close)

�Jednostka transportu wysyła FIN, żądając zakończenia połączenia

�Połączenie ustawione w trybie FIN WAIT �Kontynuowanie odbierania i wysyłania danych�Powstrzymanie się od wysyłania danych

�Kiedy otrzyma FIN, jednostka transportu informuje użytkownika i zamyka sesję

Strona nie Zrywająca

�FIN otrzymany�Poinformowanie użytkownika o umieszczeniu połączenia w stanie CLOSE WAIT �Kontynuacja wysyłania danych od użytkownika

�Użytkownik wydaje komendę CLOSE�Jednostka transportu wysyła FIN�Połączenie rozłączone�Wszystkie pozostałe dane są wysyłane przez obie strony

�Obie strony zgadzają się na zamknięcie sesji

Zakończenie połączenia

(a) Normalny przypadek zakończenia przez potrójny uścisk (b) Zaginiony końcowy ACK

6-14, a, b

Zakończenie połączenia

(c) Utrata odpowiedzi(d) Utrata odpowiedzi i powtórzenia ządania rozłączenia.

6-14, c,d

Niepewna Usługa Sieciowa

�Np.�Internet poprzez IP, �frame relay poprzez LAPF�IEEE 802.3 poprzez niepotwierdzane, bezpołączeniowe LLC

�Segmenty mogą zaginąć�Segmenty mogą dojść nie w kolejności

Problemy

�Kolejność dostarczenia�Strategia retransmisji�Wykrywanie duplikatów�Kontrola strumienia danych�Zestawianie połączenia�Zrywanie połączenia�Odzyskiwanie połączenia po awarii

Kolejność Dostarczania Danych

�Segmenty mogą dojść nie w kolejności�Numerowanie segmentów sekwencyjnie�TCP numeruje każdy oktet sekwencyjnie�Segmenty są numerowane numerem pierwszego oktetu w danym segmencie

Strategia Retransmisji

�Segmenty uszkodzone w czasie transmisji�Segmenty nie dotarły�Nadawca nie wie o defekcie�Odbiorca musi potwierdzić poprawny odbiór�Używanie kumulacyjnego potwierdzania�Ograniczony czas oczekiwania na ACK inicjuje retransmisje

Wartość Licznika

� Stały licznik�Oparty na zrozumienia zachowania sieci�Nie przystosowuje się do zmieniających się realiów�Zbyt krótki powoduje zbyt częste retransmisje�Zbyt długi i odpowiedź na zagubione segmenty wolna�Powinien być trochę dłuższy niż czas transmisji w obie strony

� Schemat adaptacyjny�Może nie potwierdzić od razu�Może nie odróżnić potwierdzenia segmentu oryginalnego i

retransmitowanego�Warunki mogą zmienić się nagle

Wykrywanie Duplikatów

� Jeśli ACK zaginął segment jest wysyłany ponownie� Odbiorca musi rozpoznawać duplikaty� Duplikat otrzymany przed zerwaniem połączenia

�Odbiorca uznaje ACK za zagubiony i wysyła ACK znów�Nadawca nie może się zagubić w mnogości potwierdzeń�Przestrzeń numerów sekwencyjnych wystarczająco duża, by nie

powtórzyć się podczas „czasu życia” segmentu

� Duplikat otrzymany po zerwaniu połączenia

Niewłaściwa

Detekcja

Duplikatu

Kontrola Strumienia Danych

�Przypisanie kredytu�Problem jeśli AN=i, W=0 okno zamknięcia�Wyślij AN=i, W=j by otworzyć, ale segment zostaje zagubiony

�Nadawca myśli, że okno zamknięte, a odbiorca że otwarte

�Używanie licznika okna�Jeśli się wyzeruje, wysłać cokolwiek

�Może być retransmisja poprzedniego segmentu

Zestawianie Połączenia

� Dwustronne „uściśnięcie dłoni”�A wysyła SYN, B odpowiada wysyłając SYN�Zagubiony SYN obsługiwany przez retransmisję

⌧Może doprowadzić do duplikatów SYN

�Ignorowanie duplikatów SYN jeśli już połączony

� Zagubione lub opóźnione segmenty mogą powodować problemy z połączeniem�Segment ze starych połączeń�Zacząć numerowanie segmentów za poprzednim ostatnim

⌧Używać SYN i⌧Trzeba potwierdzić by załączyć i⌧Potrójne „uściśnięcie dłoni

Dwustronny

„Uścisk”

Stary

Segment

Danych

Dwustronny „Uścisk”:

Przestarzały Segment SYN

Potrójny

„Uścisk”

Diagram

Stanów

Potrójny

„Uścisk”

Przykłady

Zrywanie Połączenia

� Jednostka w stanie CLOSE WAIT wysyła ostatni segment danych i zaraz potem FIN

� FIN dociera przed danymi� Odbiorca akceptuje FIN

�Zamyka połączenie�Traci ostatni segment danych

� Kojarzenie numeru sekwencyjnego z FIN� Odbiorca czeka na wszystkie segmenty przed numerem

sekwencyjnym FIN� Strata segmentów i przestarzałych segmentów

�Trzeba wyraźnie ACK FIN

Łagodne Zerwanie

�Wysłanie FIN i, odebranie AN i�Otrzymanie FIN j, wysłanie AN j�Poczekać dwukrotny maksymalny czas życia segmentu

Odzyskiwanie Połączenia po

Awarii

� Po awarii wszystkie informacje o stanie giną� Połączenie jest połowicznie otwarte

�Strona która nie uległa awarii myśli że wciąż jest połączona

� Zamykanie połączenia używając licznika�Czekać na ACK przez (time out) * (ilość retransmisji)�Kiedy się wyzeruje zamknąć połączenie i poinformować

użytkownika

�Wysłanie RST i w odpowiedni na jakikolwiek segment i� Użytkownik musi sam zdecydować czy łączyć się

ponownie�Problemy z zagubionymi danymi i duplikatami

TCP & UDP

�Transmission Control Protocol (TCP)�Zorientowany połączeniowo�RFC 793

�User Datagram Protocol (UDP)�Bezpołączeniowy�RFC 768

Usługi TCP

� Pewna komunikacja pomiędzy dwoma procesami na różnych hostach

� Przez różnorodne pewne i niepewne sieci i intersieci� Dwa rodzaje usługi

�„Wypchnięcie” (push) strumienia danych⌧Użytkownik TCP może wymagać przesłania wszystkich danych aż do flagi push

⌧Odbiorca będzie wysyłał w ten sam sposób⌧Nie trzeba czekać na zapełnienie bufora

�Pilny sygnał danych⌧Wskazuje na nadchodzący strumień pilnych danych⌧Użytkownik decyduje jak się z nim obchodzić

Nagłówek TCP

Nagłówek segmentu TCP (2)

Pseudonagłówek zawarty w obliczeniach sumy kontrolnej TCP

Obiekty przekazywane do IP

�TCP przekazuje parę parametrów do IP�Kolejność�Normalne/niskie opóźnienie�Normalna/wysoka przepustowość�Normalna/wysoka niezawodność�Bezpieczeństwo

� Co robi warstwa IP w praktyce ?

Nagłówek TCP – pola cd.� Data offset – inaczej długość nagłówka TCP – w wierszach 32 bitowych� Wskaźnik pilności – wskazuje miejsce w segmencie ( o ustawionym bicie

URG) gdzie kończą się pilne dane� Opcje:

�MSS – Maximum segment size ( 536 oktetów danych) – minimum z dwóch propozycji – obecnie bardziej zaawansowane algorytmy

�Skala okna ( RFC 1323) – w 64 KB jednostkach - mnożone przez 216

⌧Sieci gigabitowe, pojemność łącza�Selective Repeat – zamiast Go-Back-N, NAK, też SACK.�Znacznik czasu – opcja stosowana w szybkich sieciach

⌧zabezpiecza też przed „inkarnacją” starych segmentów lub ich duplikatów no nowego połączenia –

⌧do tego służy głównie zakładane przez implementacje TCP wartości MSL ( maximum segment lifetime)

⌧Pierwsze MSL = 2 minuty !!!! , czas „przekręcenia licznika” dla łącza 45 Mbps – 12 minut , ale dla 2,4 Gbps - 12 sekund

⌧Time_wait (czekanie na spóźnionych) – licznik czasu zamknięcia połączenia = 2*MSL ( było na diagramie stanów )

Mechanizmy TCP (1)

� Zestawianie połączenia�Potrójny „uścisk dłoni”�Pomiędzy parą portów�Jeden port może łączyć się z wieloma odbiorcami

� Transfer danych�Logiczny strumień oktetów (bajtów), a nie wiadomości

(segmentów)�Oktety numerowane modulo 232

�Kontrola strumienia poprzez przypisywanie kredytu od odbiorcy w postaci ilości oktetów

�Dane buforowane u nadawcy i odbiorcy

Mechanizmy TCP (2)

�Zrywanie połączenia�Łagodne zamknięcie sesji�Użytkownik TCP wysyła komendę CLOSE�Jednostka transportu ustawia flagę FIN w ostatnim wysyłanym segmencie

�Nagłe zerwanie poprzez komendę ABORT⌧Jednostka porzuca próby wysyłania i odbioru danych⌧Segment RST wysyłany

Opcje Polityki Implementacji

�Wyślij�Dostarcz�Zaakceptuj�Retransmituj�Potwierdź

Wyślij

�Jeśli bez push lub close jednostka TCP nadaje wg własnego uznania

�Dane buforowane w buforze transmisji�Można tworzyć segment z paczki danych�Można oczekiwać na konkretną ilość danych

Dostarcz

�W przypadku braku push, dostarcz dane wg uznania

�Można dostarczać w kolejności otrzymywania segmentów

�Można buforować dane z więcej niż jednego segmentu

Akceptuj

�Segmenty mogą nie dotrzeć w kolejności�W kolejności

�Akceptuj segmenty tylko w kolejności�Odrzuć segmenty nie w kolejności

�W oknach�Akceptuj wszystkie segmenty w zasięgu okna odbioru

Retransmituj

�TCP trzyma kolejkę segmentów wysłanych ale nie potwierdzonych

�TCP retransmituje jeśli nie potwierdzone w przeciągu danego czasu�Tylko pierwszy�Całą paczkę (zawartość okna)�Indywidualnie

Potwierdzenie

� Natychmiastowe� Kumulacyjne� Liczniki czasu

�Czas retransmisji�Czas ponowne połączenia ( reconnection)�Czas okna ( window) –maksymalny czas miedzy segmentami

ACK/kredyt�Retransmisji SYN – ponowna próba nawiązania połączenia�Licznik bezustanny – zamyka połączenie po braku potwierdzeń

segmentów�Licznik nieaktywności – zamyka połączenie gdy nie ma

segmentów z obu stron

Kontrola Przeciążeń

� RFC 1122, Wymagania dla hostów internetowych� Zarządzanie licznikiem retransmisji (RTO –

retransmission timeout)�Oszacuj czas dwustronnej transmisji (RTT) poprzez obserwację

tendencji opóźnień�Ustawić czas licznika na trochę powyżej oszacowanego�Prosta średnia dla RTT�Średnia wykładnicza dla RTT�Oszacowanie wariancji RTT (algorytm Jacobsona)

⌧RTT_new=a*RTT_old + (1-a)*RTT_przybyłe, a=7/8 ⌧RTO=b*RTT , b=2⌧Odchylenie D=aD_old + (1-a)*|RTT-RTT_przybyłe|⌧RTO= RTT + 4 * D⌧ Co z potwierdzeniami duplikatów – trudności w określeniu RTT , i co robić z czasem retransmisji ? Rozwiązuje to Karn -

Zarządzanie zegarami w TCP

(a) Gęstość prawdopodobieństwa czasów przybycia Ack w warstwei liniowej ( LAN)

(b) jw. dla TCP (sieć rozległa – Internet)

Wykładnicze Korekcje RTO

�Ponieważ licznik jest funkcją przeciążenia(odrzucony pakiet lub długi RTT), utrzymywanie RTO na tym samym poziomie jest nieuzasadnione

�RTO jest zwiększane z każdym retransmitowanym segmentem

�RTO = q*RTO�Z reguły q=2

�Binarna korekcja wykładnicza�Karn w TCP/IP, w niepewnych sieciach radiowych

Algorytm Karn’a

�Jeśli segment jest retransmitowany, otrzymany ACK może być uznany:�Za pierwszą kopię segmentu

⌧RTT dłuższy niż spodziewany

�Za drugą kopię�Nie ma sposobu by je odróżnić

�Nie mierzyć RTT dla retransmitowanych segmentów�Obliczać korekcję kiedy zachodzi retransmisja�Używać korekcji RTO ( wykładniczej) dopóki nie nadejdzie ACK za segment nie retransmitowany

Zarządzanie Oknem

� „Powolny start”⌧Okno dozwolone = MIN[kredyt, cwnd]⌧Zacząć połączenie z cwnd=1 (cwnd – okno przeciążeniowe)⌧Zwiększać cwnd za każdym ACK, do jakiegoś max⌧To znaczy, że start jest szybki – bo wykładniczy – 1,2,4,8, etc.⌧Pierwotnie zwany „soft start” ☺

� Dynamiczne dopasowywanie okna w czasie przeciążenia⌧Kiedy licznik się wyzeruje⌧Ustawić górną granicę „powolnego startu” do połowy obecnego oknaprzeciążenia (cwnd)

• ssthresh=cwnd/2⌧Ustawić cwnd = 1 i „powolny start” dopóki cwnd=ssthresh

• Zwiększać cwnd o 1 dla każdego otrzymanego ACK⌧Dla cwnd >=ssthresh, zwiększyć cwnd o 1 dla każdego mierzonego RTT –stan unikania przeciążenia

� Dlaczego TCP w ten sposób kontroluje przeciążenia ?⌧Przepełnienie buforów jako prawdopodobna przyczyną utraty segmentów

Okno kredytowe w TCP

Zarządzanie oknem w TCP.

TCP Kontrola przeciążeń

Przykład algorytmu unikania przeciążeń w Internecie (powolny start)

Polityka transmisji w TCP

Syndrom „głupiego okna”

Zapobieganiu syndromu

„głupiego okna”

� Rozwiązanie Clark’a�Wysyłać update okna – po osiągnięciu MSS, lub połowa buforu

(co mniejsze)�Po stronie nadawcy – też nie wysyłać zbyt małych segmentów

� Aplikacje typu telnet �Wysłanie jednego znaku, ACK, update okna po przesłaniu

danych do aplikacji, echo znaku�Łącznie 4 segmenty ( 162 bajty IP i TCP)�Swoboda po stronie nadawcy i odbiorcy

⌧Opoźnianie wysyłania ACK i aktualizacji okna⌧Algorytm Nagle’a

• Po stronie nadawcy – wysłanie pierwszego bajtu i dalej buforowanie aż do otrzymania potwierdzenia

• Stosowany szeroko, ale w X- windows lepiej nie używać – ruchy myszy

� Oba rozwiązania mogą pracować razem �Nadawca nie wysyła małych segmentów ( Nagle), a odbiorca ich

nie żąda ( Clark)

UDP

�User datagram protocol�RFC 768�Bezpołączeniowa usługa dla procedur poziomu aplikacji�Niepewna�Dostarczenie i kontrola duplikatów nie gwarantowana

�Zmniejszona redundancja(overhead)�Zastosowanie wzrasta

�Dlaczego ?

Użycie UDP

�Wewnętrzne zbieranie danych�tftp

�Zewnętrzne szerzenie (rozgłaszanie) danych�RIP

�Żądanie-odpowiedź�DNS

�Aplikacje czasu rzeczywistego (real-time)�RTP

�Tunelowanie�L2TP, ISAKMP

Nagłówek UDP

Dobrze znane portyDobrze znane portyDobrze znane portyDobrze znane porty� Porty UDP

� 7 – echo� 11 – systat� 19 – chargen� 53 – nameserver ( DNS)� 69 – tftp� 123 – NTP – network time protocol

� Porty TCP

� 20 – ftp –data� 21 – ftp � 23 – telnet� 22 – ssh� 25 – smtp� 53 –DNS

Porty TCP cd.Porty TCP cd.Porty TCP cd.Porty TCP cd.

� 79 – finger� 80 – http� 110 – POP� 139 – Netbios SSN� 143 - IMAP

� /etc/services� telnet host port� Pasywne i aktywne otwarcie połączeń TCP

� Porty do 1023 i wyżej do ... ?� Interfejs gniazd ( socket)� Co się dzieje jeśli brak otwarcia pasywnego ?

� ICMP , RST w TCP (czasami)

Real-Time Transport Protocol

(a) Pozycja RTP w stosie protokołów ( warstw) (b) Zagnieżdzenia pakietów

Nagłówek RTP

Nagłówek RTP

Inne protokoły transportowe

• Problemy TCP w sieciach zawodnych (bezprzewodowych)• Pośredni TCP ( i-TCP), indirect, split

• Dzieli połączenie TCP – narusza semantykę end-to-end ( a NAT ?)• Snoop TCP ( podsłuchujący)

• Buforowanie, eliminacja duplikatów potwierdzeń• Nadal End-to-End,

• Opcje SACK • Protokół UDP – nie rozwiązuje tych problemów

• Przeniesienie do warstwy aplikacji

• Transakcyjny TCP – T/TCP • Skrócenie procedury uruchamiania aplikacji typu żądanie – odpowiedź• Efektywność bliska UDP, ale niezawodność w warstwie transportowej

• SCTP – Stream Control Transmission Protocol• Strumień wielu ( multihoming) pakietów (chunks)• Możliwości bezsekwencyjnego dostarczania, potwierdzenia SACK

Wydajność sieci• Zagadnienie sieci gigabitowych

• Czas transmisji pakietu• Czas propagacji i RTT• Pojemność• Wielkość okna

• update okna odbiorcy• opcje okna w TCP

• Mechanizmy potwierdzania• Go-Back-N , SACK

• Przetwarzanie pakietów w węzłach, u nadawcy i odbiorcy• Implementacje• Rozwój sieci i komputerów – przepustowość vs. moc obliczeniowa

• 56 kbs vs 5 Gbs – 106

• Niedoszacowanie rozwoj sieci• IP v6 –

• Szybsze przetwarzanie• „duży” nadmiar nagłówków

• ATM - ?