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ć
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
Zobacz rozdział 7 dla zasad operacji
Działa dobrze na stosunkowo niezawodnej sieci
⌧Nieodebranie ACK jest tratowane jako sygnał kontroli strumienia danych
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ąć
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
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ć
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
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
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
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
