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
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ć
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
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
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
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
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
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
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
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
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
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
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
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)
Nagłówek UDP
Wymagana Lektura
Stallings rozdział 17
RFC
