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