= RD PRZEPUSTOWOŚCI. Dla lepszego zrozumienia zasad doboru szerokości okna wprowadzono współczynnik znormalizowanej przepustowości (S).

Transkrypt

1 WSPÓŁCZYNNIK ZNORMALIZOWANEJ PRZEPUSTOWOŚCI Rozmiar okna oferowanego przez odbiorcę może być kontrolowany przez proces obsługujący odbiór danych, co jednak może wpływać na wydajność TCP. Powszechnie stosowana wielkość buforów to 4096 bajtów (optymalna dla hostów pracujących w sieci Ethernet). Mechanizm ślizgającego okna pozwala na określenie maksymalnej przepustowości w połączeniu TCP, która zależy od szerokości okna (W), czasu propagacji (D) i prędkości transmisji (R). Dla lepszego zrozumienia zasad doboru szerokości okna wprowadzono współczynnik znormalizowanej przepustowości (S). S = 1 4W RD W > RD / 4 W < RD / 4 D jest to czas propagacji pomiędzy źródłem a odbiorcą w połączeniu TCP (czas przesłania i czas potwierdzenia wynosi 2D) W rozmiar okna (w oktetach) R szybkość transmisji (bps)

2 WSPÓŁCZYNNIK ZNORMALIZOWANEJ PRZEPUSTOWOŚCI - CD Gdyby źródło nie było ograniczone szerokością okna to całkowita możliwa transmisja wynosiłaby 2RD bitów (2RD bitów = 2RD/8 bajtów = RD/4 bajtów). W rzeczywistości jednak transmisja źródła jest limitowana do szerokości okna. Zatem jeżeli jest spełniony warunek W>RD/4 to osiągamy maksymalną przepustowość połączenia TCP. Powyższe rozważania są czysto teoretyczne, gdyż w praktyce powinniśmy uwzględnić szereg innych czynników, takich jak: Wiele połączeń może być realizowane na wspólnym interfejsie sieciowym, co sprawia, że założona przepustowość jest pomiędzy kilkoma sesjami. Jedno połączenie TCP może przechodzić przez kilka sieci (dodatkowe opóźnienia wprowadzane przez routery w szczególności w przypadku natłoku). W połączeniu TCP występują różne przepustowości łączy pomiędzy kolejnymi węzłami (mogą powstać zatory na wolniejszych kanałach) Istnieje możliwość zagubienia segmentu, w wyniku czego jest on retransmitowany. Efektem tego jest zmniejszenie rzeczywistej przepustowości.

3 KONTROLA PRZEPŁYWU W TCP Za każdym razem, gdy przesyłany jest segment, TCP uruchamia zegar i czeka na potwierdzenie. Czas podróży kolejnych segmentów może być bardzo różny, a TCP musi się dostosować do zmiennych czasów oczekiwania. Aby obliczyć ten czas TCP odejmuje czas wysłania segmentu od otrzymania potwierdzenia. Wynikiem jest próbka podróży w obie strony. TCP na jej podstawie oblicza RTT (ang. Round Trip Time) jako średnią ważoną i używa nowych próbek czasu do powolnej zmiany jej wartości. Wyliczany jest on według wyrażenia: RTT = (a * Stare_RTT) + ((1-a) * Nowa_Próbka_Czasu) α - waga do oznaczania istotności średniej w stosunku do ostatnio uzyskanej próbki czasu (0< a < 1), wybranie a bliskiej 1 powoduje że średnia nie zależy od krótkotrwałych zmian, dobranie wartości bliskiej 0 sprawia średnia szybko reaguje na zmiany. Czas oczekiwania RTO (ang. Retransmission Time Out) oblicza się z równania: RTO = b * RTT β - współczynnik ważący (zwykle zawiera miedzy 1 a 2) wartość w pobliżu 1 powoduje szybką retransmisję.

4 ALGORYTM KARNA Ze względu na to że TCP używa schematu skumulowanego potwierdzenia, które odnosi się do odebranych danych a nie datagramów, w razie retransmisji utraconego datagramu nadawca nie ma możliwości stwierdzenia, czy potwierdzenie dotyczy pierwotnego, czy retransmitowanego datagramu. Zjawisko to nazwano niejednoznacznością potwierdzenia. Powoduje to że nie można określić dokładnie czasów podróży. Algorytm Karna polega na tym że przy szacowaniu czasu podróży TCP ignoruje próbki które odpowiadają retransmitowanym segmentom, ale wydłuża czas oczekiwania przy każdej retransmisji, aż do momentu gdy segment może zostać poprawnie przesłany. Wydłużenie obliczamy z równania: nowy_rto = γ * RTO Poprzednia wartość RTO Czy była retransmisja? NIE Próbka czasu TAK γ - mnożnik zwykle równy 2 Obliczenia RTO wg. algorytmu J acobsona RTO = poprzednie_rto * γ Nowa wartość RTO

5 ALGORYTM NAGLE`A Algorytm ten umożliwia uniknięcie syndromu głupiego okna który objawia się przesyłaniem w każdym segmencie małej ilości danych, co powoduje duży narzut nagłówków. Obowiązek unikania tego problemu spoczywa na obu stronach połączenia. Dane z aplikacji NIE Czy ilość oktetów = MSS lub 1/4 bufora? NIE Czy przyszło potwierdzenie? NIE Czy upłynął czas t=0,2sek. TAK TAK TAK Wyślij segment Segmenty

6 ALGORYTM NAGLE`A - CD Po stronie odbiorcy: gdy zaoferowano zerowe okno, to przed wysłaniem aktualnej oferty okna należy poczekać, aż stanie się dostępne miejsce równe MSS lub połowie bufora. Można uzyskać to dwoma sposobami: TCP potwierdza natychmiast każdy segment który przybywa, ale nie proponuje zwiększonego okna TCP opóźnia wysłanie potwierdzenia - jednak nie może opóźniać zbyt długo bowiem nadawca może retransmitować niepotwierdzone segmenty. W tym celu standardy ograniczają zwłokę do 0,5 sek Unikanie po stronie nadawcy polega na : Jeżeli program wysyłający generuje dane do przesłania, ale nie przyszło potwierdzenie dostarczenia poprzednich segmentów, dane te są buforowane do chwili osiągnięcia MSS, lecz gdy zostanie odebrane potwierdzenie TCP natychmiast wysyła zgromadzone dane Jeżeli program użytkowy generuje po jednym oktecie naraz, to TCP natychmiast wysyła pierwszy oktet. Jednak do momentu przybycia potwierdzenia, TCP strumień danych będzie umieszczał w buforze. Wobec tego jeżeli program jest szybki w stosunku do sieci, to kolejne segmenty będą zawierały dużą ilość danych. Jeżeli program jest wolny (np. pisanie na klawiaturze) to małe segmenty będą przesyłane bez opóźnień.

7 ZAKOŃCZENIE POŁĄCZENIA TCP Standard TCP dostarcza ściśle określonej specyfikacji i opisu protokołu używanego pomiędzy jednostkami TCP na czwartym poziomie modelu ISO/OSI Opis protokołu zakłada i dopuszcza kilka możliwych opcji implementacyjnych, do których należą : nadawanie (send policy), dostarczanie (deliver policy), przyjmowanie (accept policy), retransmisja (retransmit policy), potwierdzenie (acknowledge policy)

8 DNS - WPROWADZENIE DNS pochodzi z angielskiego Domain Name Service DNS - jest "klejem" łączącym adresy sieciowe z obiektami (komputerami / host'ami) z nazwami jakimi się posługują wszyscy użytkownicy. Nazwy domen zaczynają się od najbardziej szczegółowej czyli hosta i przesuwają się do najbardziej ogólnej, czyli nazwy root. Nazwa domenowa, która zaczyna się od hosta i przechodzi całą drogę do korzenia jest zwana w pełni kwalifikowana nazwą domeny (ang. fully gualified domain name FQDN). Cel stosowanie DNS to zapewnienia odpowiedzi na następujące pytania: W jaki sposób można się z tym host'em skontaktować i gdzie powinna być przechowywana informacja o tym, z jakim adresem sieciowym należy nawiązać połączenie? Jeżeli host zmieni adres (np. z przyczyn technicznych), jak w takim razie inni użytkownicy Internetu będą się mogli o tym dowiedzieć?

9 SYSTEM NAZW DNS hostname.(subdomain).topleveldomain gdzie odpowiednio: - hostname - nazwa host'a (komputera, któremu jest przypisywana nazwa) - subdomain - poddomena (może ich być kilka) - topleveldomain - główna domena Przykład: riad.usk.pk.edu.pl gdzie odpowiednio: - riad - nazwa konkretnego komputera - usk - domena Uczelniana Sieć Komp. - pk - domena Politechnika Krakowska - edu - strefa edukacyjna w Polsce - pl - domena Polska (topleveldomain)

10 ZAPYTANIA DNS Serwer główny nie odpowiada bezpośrednio na zapytanie o adres, natomiast wskazuje lokalnemu serwerowi serwer, który może odpowiedzieć na zapytanie dotyczące domeny gumiak.com. Serwer główny przesyła serwerowi lokalnemu rekord zawierający nazwę odpowiedniego serwera dla domeny gumiak.com oraz rekord adresowy określający adres tego serwera. Następnie lokalny serwer wysyła do serwera domeny gumiak.com zapytanie o adres www. gumiak.com i otrzymuje odpowiedź.

11 ZAPYTANIA DNS - CD Jeżeli ma dojść do komunikacji między dwoma komputerami, program pobiera nazwę host'a i wysyła pytanie do specjalnego serwera (name server) o powiązany z tą nazwą adres sieciowy. Name server zna adresy wszystkich lokalnych komputerów w zdefiniowanej strefie, jaką obsługuje (sieci lokalnej). Name server zna adresy innych name server'ów w Internecie. Jeżeli więc skądś nadchodzi zapytanie (query) o adres komputera po podaniu nazwy tego komputera, name server może: odczytać (resolve) adres lokalnie spytać inne name server'y czy one nie znają adresu komputera, o który pyta komputer-klient.

12 KOMUNIKATY DNS Komunikat DNS ma 12 bajtowy nagłówek stałej długości i cztery pola zmiennej długości.

13 KOMUNIKATY DNS - CD Poszczególne pola komunikatu DNS mają następujące znaczenie: identyfikacja - pole wypełniane przez klienta, tak aby mógł zidentyfikować odpowiedź serwera DNS; parametr - klasyfikuje komunikat QR - typ operacji 0 dla pytania, l dla odpowiedzi Oc - O pytanie standardowe, l pytanie odwrotne, 2 pytanie o status serwera, TC - komunikat skrócony (Prawda/Fałsz), AA - odpowiedź autorytatywna (Prawda/Fałsz), RD - żądana jest rekursja (Prawda/Fałsz), RA - rekursja jest dostępna (Prawda/Fałsz), Zero - zarezerwowane, ma wartość 0, Rc - typ odpowiedzi, 0 bez błędów, 3 błąd nazwy;

14 KOMUNIKATY DNS - CD liczba pytań - 1 lub więcej dla pytania, 0 dla odpowiedzi; liczba odpowiedzi - 0 dla pytania, l lub więcej dla odpowiedzi; liczba autorytetów - 0 dla pytania, l lub więcej dla odpowiedzi; liczba dodatkowych informacji - 0 dla pytania, l lub więcej dla odpowiedzi; pytania - każde pytanie składa się z napisu zawierającego adres internetowy, którego dotyczy pytanie, typu pytania i klasy pytania.

15 KOMUNIKATY DNS - CD 1 A Adres IP, 2 NS Serwer nazw dla domeny (ang. Name setrer), 5 CNAME Nazwa kanoniczna (ang. canonical name), 12 PTR Rekord wskaźnikowy (ang. pointer record), 13 HINFO Informacja o hoście 15 MX Rekord wymiennika poczty (ang. mail exchange), 252 AXFR Żądanie przesłania strefy (ang. Request for zone transfer), 255 ANY Żądanie wszystkich rekordów (ang. reąuestfor all record); Odpowiedź, Autorytety, Dodatkowe informacje - wszystkie działają na tym samym formacie rekordu zasobów

16 KOMUNIKATY DNS - CD Rekord zasobów RR (ang resource record) zawiera następujące składowe: Pole nazwa domeny jest nazwą, do której odnoszą się zawarte w odpowiedzi informacje o zasobach. Pole typ określa jeden z kodów typu stosowanych w RR. Kody te są takie same, jak wartości typów zapytań, Pole klasa jest zwykle wartością 1 dla danych dotyczących sieci Internet. Pole czas życia jest liczbą sekund, określającą czas przechowywania informacji w pamięci podręcznej przez klienta. Zwykle TTL ustawiony jest na 2 dni. Pole długość danych zasobu określa ilość danych w polu dane zasobu. Format tych danych zależy od pola: typ. Jeśli typ jest określony jako 1 (rekord A), to dane zasobów są zapisane w postaci 4- bajtowego adresu IP.

17 DOMENA ODWROTNA DNS Programy komunikacyjne przesyłają dane w postaci pakietów TCP/IP, które mogą zawierać jedynie adresy adres TCP/IP nadawcy. Jednak host - odbiorca chciałby znać także nazwę a nie tylko adres host'a - nadawcy. Potrzebny jest więc mechanizm ponownej translacji z adresu na pełną nazwę komputera (full domain name). Oczywiście można do tego użyć name server'a. Do tego celu stworzono specjalną domenę w sieci Internet, nazwaną.inadress.arpa, która spełnia wyżej wymienione założenie. Wszystkie sieci TCP/IP są ulokowane w tej domenie. Przykład: Adres: Reverse Name: in-addr.arpa Nazwa komputera: galaxy.uci.agh.edu.pl Dzięki tej domenie możliwy jest mechanizm bezbłędnego mapowania (mapping) adresu Internetowego na nazwę host'a, jak również lokalizacji wszystkich gateways w danej sieci lokalnej podłączonej do Internetu.

18 SERWERY DNS ROOT SERVER Zna wszystkie top level domains w sieci Internet. Informacje o host'ach jest zbierana z tych domen poprzez przeprowadzenie zapytania dla komputera z innej strefy (name server query) ROOT SERVER może stwierdzić miarodajnie o istnieniu danego host'a w tej poddomenie. MASTER SERVER Jest "miarodajny" dla całego obszaru bieżącej domeny, prowadzi bazy danych dla całej strefy. Istnieją dwa rodzaje MASTER SERVER'ow: PRIMARY MASTER SERVER oraz SECONDARY MASTER SERVER Może się zdarzyć, że serwer jest zarazem MASTER SERVER'em dla kilku domen dla jednych PRIMARY, dla innych SECONDARY CACHING SERVER Wszystkie serwery (PRIMARY jak i SECONDARY) prowadzą cache'owanie informacji, które otrzymują. Wygasanie określone jest w polu ttl. CACHING SERVER'y nie mają pełnomocnictw dla żadnej strefy, w związku z tym nie zarządzają żadnymi bazami danych. Mogą natomiast odpowiadać poprzez wysyłanie queries (zapytań) do innych serwerów posiadających takie pełnomocnictwa.