William Stallings Transmisja Danych w Sieciach Komputerowych

Transkrypt

William Stallings Transmisja Danych w Sieciach Komputerowych
William Stallings
Transmisja Danych w
Sieciach Komputerowych
Rozdział 17
Protokoły Transportu
Połączeniowe Mechanizmy
Protokołu Transportu
Połączenie logiczne
Zestawienie połączenia
Zerwanie połączenia
Niezawodne
Np. TCP
1
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
2
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
3
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
4
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
Zobacz rozdział 7 dla zasad operacji
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
5
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
6
Alokacja Kredytu
Perspektywy Nadania i Odbioru
7
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
8
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
9
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ę
10
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
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
11
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
12
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
13
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
14
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
15
Dwustronny
„Uścisk”
Stary
Segment
Danych
Dwustronny „Uścisk”:
Przestarzały Segment SYN
16
Potrójny
„Uścisk”
Diagram
Stanów
Potrójny
„Uścisk”
Przykłady
17
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
18
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
19
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
20
Obiekty Przekazywane do IP
TCP przekazuje parę parametrów do IP
Kolejność
Normalne/niskie opóźnienie
Normalna/wysoka przepustowość
Normalna/wysoka niezawodność
Bezpieczeństwo
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
21
Mechanizmy TCP (2)
Transfer danych
Logiczny strumień oktetów (bajtów)
Oktety numerowane modulo 223
Kontrola strumienia poprzez przypisywanie kredytu w
postaci ilości oktetów
Dane buforowane u nadawcy i odbiorcy
Mechanizmy TCP (3)
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
22
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
23
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
24
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
25
Kontrola Przeciążeń
RFC 1122, Wymagania dla hostów
internetowych
Zarządzanie licznikiem retransmisji
Oszacuj czas dwustronnej transmisji (RTT) poprzez
obserwację tendencji opóźnień
Ustawić czas licznika na trochę powyżej
oszacowanego
Prosta średnia
Średnia wykładnicza
Oszacowanie wariancji RTT (algorytm Jacobsona)
Korzystanie z
Wykładniczego
Uśredniania
26
Wyliczenie
RTO metodą
Jacobsona
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
27
Algorytm Karn’a
Jeśli segment jest retransmitowany, otrzymany
ACK może być:
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
Obliczać korekcję kiedy zachodzi retransmisja
Używać korekcji RTO dopóki nie nadejdzie ACK
za segment nie retransmitowany
Zarządzanie Oknem
„Wolny start”
awnd = MIN[kredyt, cwnd]
Zacząć połączenie z cwnd=1
Zwiększać cwnd za każdym ACK, do jakiegoś max
Dynamiczne dopasowywanie okna w czasie przeciążenia
Kiedy licznik się wyzeruje
Ustawić górną granicę „wolnego startu” do połowy obecnego
okna przeciążenia (cwnd)
⌧ssthresh=cwnd/2
Ustawić cwnd = 1 i „wolny 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
28
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)
np. Zarządzanie siecią (Rozdział 19)
Użycie UDP
Wewnętrzne zbieranie danych
Zewnętrzne szerzenie (rozgłaszanie) danych
Żądanie-odpowiedź
Aplikacje czasu rzeczywistego (real-time)
29
Nagłówek UDP
Wymagana Lektura
Stallings rozdział 17
RFC
30