połączeniowe mechanizmy protokołu transportuzskl.p.lodz.pl/~lipkap/psk/tcp_2005.pdf ·...
TRANSCRIPT
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
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
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
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
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
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ć
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
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
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
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
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 - ?