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 dwukoń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 Adres hosta Wybrać protokół transportu (TCP, UDP) 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 6-14, a, b (a) Normalny przypadek zakończenia przez potrójny uścisk (b) Zaginiony końcowy ACK
Zakończenie połączenia 6-14, c,d (c) Utrata odpowiedzi (d) Utrata odpowiedzi i powtórzenia ządania rozłączenia.
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 2 16 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 2 32 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 okna przeciąż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 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. 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 10 6 Niedoszacowanie rozwoj sieci IP v6 Szybsze przetwarzanie duży nadmiar nagłówków ATM -?