protokoły transportowe

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
• 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
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 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 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 – 106
• Niedoszacowanie rozwoj sieci
• IP v6 –
• Szybsze przetwarzanie
• „duży” nadmiar nagłówków
• ATM - ?