komunikaty dns

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).
 1
S =  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)
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.
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ę.
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:
Poprzednia
wartość RTO
Próbka czasu
Czy była
retransmisja?
nowy_RTO = γ * RTO
γ - mnożnik zwykle równy 2
TAK
NIE
Obliczenia RTO
wg. algorytmu
J acobsona
Nowa wartość
RTO
RTO =
poprzednie_RTO * γ
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.
NIE
Dane z aplikacji
Czy ilość oktetów =
MSS lub 1/4 bufora?
TAK
Wyślij segment
Segmenty
NIE
Czy przyszło
potwierdzenie?
TAK
NIE
Czy upłynął czas
t=0,2sek.
TAK
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ń.
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)
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ć?
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)
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ź.
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.
KOMUNIKATY DNS
Komunikat DNS ma 12 bajtowy nagłówek stałej długości i cztery pola
zmiennej długości.
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;
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.
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
252
255
AXFR
ANY
Rekord wymiennika poczty (ang. mail exchange),
Żądanie przesłania strefy (ang. Request for zone transfer),
Żądanie wszystkich rekordów (ang. reąuestfor all record);
Odpowiedź, Autorytety, Dodatkowe informacje - wszystkie działają
na tym samym formacie rekordu zasobów
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 4bajtowego adresu IP .
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:
149.156.96.9
Reverse Name: 9.96.156.149.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.
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.