PROTOKOŁY TRANSPORTOWE

INTERNETOWE PROTOKOŁY

TRANSPORTOWE

Protokół TCP

Protokół TCP: historia

• TCP (ang. Transmission Conłrol Protocol — protokół sterowania transmisją) zaprojektowany został w celu zapewnienia niezawodnej transmisji strumieni

bajtowych na bazie (zawodnych z natury) międzysieci.

• Protokół TCP został zdefiniowany w RFC 793 (z 1981 roku).

• Równie istotne są poprawki błędów ujęte w RFC 1122, rozszerzenia poprawiające wydajność z RFC 1323,

selektywne potwierdzenia (RFC 2018), mechanizmy kontroli przeciążeń z RFC 2581, specyfikacja zmiany znaczenia wybranych pól nagłówka w RFC 2873,

ulepszenia zegarów retransmisji w RFC 2988, jawne powiadomienia o przeciążeniach z RFC 3168.

Protokół TCP: funkcje

• Ponieważ warstwa IP nie gwarantuje niezawodnego dostarczenia datagramu ani nie daje wskazówek co do szybkości wysyłania datagramów, ustanawianie limitów czasowych odpowiedzi i (w razie potrzeby) powtarzanie transmisji, tak żeby w pełni wykorzystać pojemność sieci bez ryzykowania przeciążeń, leży całkowicie w gestii

TCP.

• Kolejna funkcja TCP — odtworzenie oryginalnego komunikatu poprzez ułożenie jego fragmentów we właściwej kolejności.

• TCP musi zapewnić maksymalną wydajność przy określonej niezawodności, której żąda większość użytkowników i której nie jest w stanie zapewnić IP.

Model usługi TCP: gniazda

• Usługa TCP realizowana jest za pośrednictwem punktów dostępowych, zwanych gniazdami (ang.

sockets).

• Każde gniazdo jest w istocie konkatenacją adresu IP hosta i lokalnego 16-bitowego numeru zwanego

portem.

• Usługa TCP świadczona jest w ramach połączenia, które musi zostać uprzednio nawiązane między gniazdami

obydwu hostów.

• Określone gniazdo może w danej chwili uczestniczyć w kilku połączeniach.

• Określone połączenie jest więc identyfikowane przez parę gniazd i jest to jego jedyna identyfikacja.

Porty TCP

• Porty o numerach mniejszych niż 1024 określane są mianem tzw. portów znanych (ang. well-known

ports) albo zarezerwowanych — ich wykorzystanie

zarezerwowane jest na potrzeby usług

standardowych.

• Lista dobrze znanych portów zarządzana jest centralnie przez organizację Internet Assigned

Numbers Authority, IANA (www.iana.org); w chwili

obecnej na liście tej znajduje się ponad 700 pozycji.

• Reszta portów jest do dowolnego wykorzystania

aplikacji.

Niektóre z „dobrze znanych portów”

Port Protokół Zastosowanie

20, 21 FTP Transfer plików

22 SSH Zdalna powłoka logowania 25 SMTP Poczta elektroniczna (e-mail)

80 HTTP WWW

110 POP3 Zdalny dostęp do poczty elektronicznej 143 IMAP Zdalny dostęp do poczty elektronicznej

443 HTTPS Zabezpieczone połączenie do serwera WWW (HTTP w osłonie SSL/TLS) 543 RTSP Sterowanie odtwarzaniem mediów

631 IPP Usługi wydruku

Model usługi TCP: połączenia

• Wszystkie połączenia TCP są połączeniami

• Są one także połączeniami dwupunktowymi (ang.

point-to-point) – TCP nie obsługuje ani

multicastingu, ani rozgłaszania.

• Dane przesyłane w ramach połączenia TCP

traktowane są jako strumień bajtów, a nie jako strumień komunikatów – granice poszczególnych komunikatów nie są zachowywane podczas

transmisji.

Model usługi TCP: wysłanie danych

• Dane powierzone TCP mogą zostać wysłane

natychmiastowo, mogą też być buforowane w celu jednorazowego wysłania większej porcji.

• W niektórych przypadkach aplikacja powinna otrzymać przeznaczone dla niej dane natychmiast, niezależnie od ich rozmiaru. Do wymuszania wypychania danych do sieci w TCP służy mechanizm ze znacznikiem PUSH w pakietach.

• Mechanizm pilnych danych (ang. urgent data) stosuje się, gdy aplikacja ma do wysłania dane o wysokim

priorytecie, które powinny zostać przetworzone u odbiorcy bezzwłocznie (poza kolejnością). Znacznik URGENT powoduje chwilowe wstrzymanie przez TCP gromadzenia danych do wysłania i natychmiastowe wysłanie „pilnego” pakietu.

Protokół TCP: wielkość segmentu

• Hosty biorące udział w połączeniu TCP wymieniają ze sobą dane w jednostkach zwanych segmentami.

• Wielkość segmentu TCP ograniczona jest co najmniej przez dwa czynniki:

• każdy segment wraz z nagłówkiem TCP nie może przekraczać wielkości 65 515 bajtów jako maksymalnej dla treści

datagramu IP;

• rozmiar segmentu nie może przekraczać maksymalnej jednostki transmisji, MTU.

• Mimo to może się zdarzyć, że pakiety IP będą niosły segmenty TCP pofragmentowane. W takim przypadku mamy do czynienia z degradacją wydajności i innymi problemami. Dlatego w TCP realizuje się wykrywanie MTU ścieżki.

Protokół TCP: protokół okna przesuwnego

• Podstawowym protokołem wykorzystywanym przez encje TCP jest protokół okna przesuwnego z

dynamicznym rozmiarem okna.

• Host wysyłający segment uruchamia jednocześnie stoper.

• Gdy wysłany segment dotrze do hosta docelowego,

jednostka TCP tego ostatniego wysyła zwrotny segment potwierdzający, zawierający następny oczekiwany

numer sekwencyjny i rozmiar pozostałego okna.

• Gdy ów segment potwierdzający nie dotrze w limicie czasowym do hosta wysyłającego, ten wysyła

problematyczny segment ponownie.

Nagłówek segmentu TCP

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Port nadawcy Port odbiorcy

Numer sekwencyjny, SN

Numer potwierdzenia, ACK SN (jeżeli flaga ACK jest ustawiona) Długość

nagłówka

Zarezer wowane

N S

C W

R E C E

U R G

A C K

P S H

R S T

S Y N

F I N

Rozmiar okna

Suma kontrolna Wskaźnik priorytetu (jeżeli flaga URG jest ustawiona)

Opcje (jeżeli długość nagłówka > 5, to pole jest uzupełniane "0") ...

Pola nagłówka TCP

• Numer potwierdzenia zawiera numer sekwencyjny związany z następnym oczekiwanym bajtem, nie z bajtem ostatnio otrzymanym. Jest to tak zwane potwierdzenie zbiorcze, ponieważ podsumowuje

odebrane dane pojedynczym numerem potwierdzenia.

• Pole Długość nagłówka TCP określa rozmiar nagłówka liczony w 32-bitowych słowach.

• Znaczniki CWR i ECE służą do sygnalizowania przeciążeń w ramach mechanizmu jawnych powiadomień ECN

(Explicit Congestion Notification), zgodnie z RFC 3168.

Pola nagłówka TCP (2)

• Ustawienie na 1 znacznika URG oznacza, że zawartość pola Wskaźnik pilności jest istotna – pole to wskazuje przesunięcie bajtowe początku obszaru, w którym

znajdują się pilne dane. Obecnie mechanizm pilnych danych jest stosowany wyjątkowo rzadko.

• Wartość 1 znacznika ACK oznacza, że istotna jest zawartość pola Numer potwierdzenia przy zerowej wartości znacznika zawartość tego pola jest

ignorowana.

• Wartość 1 znacznika PSH identyfikuje dane do natychmiastowego wysłania i natychmiastowego

przekazania ich aplikacji docelowej, bez pośredniego buforowania.

Pola nagłówka TCP (3)

• Ustawienie znacznika RST sygnalizuje konieczność nagłego zresetowania połączenia. Generalnie

otrzymanie segmentu z ustawionym znacznikiem RST zawsze oznacza wystąpienie sytuacji problematycznej.

• Segmenty z ustawionym znacznikiem SYN używane są do nawiązywania połączeń.

• Ustawiony znacznik FIN oznacza polecenie zwolnienia połączenia, a dokładniej – informację, że host nie

zamierza już wysyłać żadnych danych. Mimo wysłania takiego segmentu host gotowy jest w dalszym ciągu na przyjmowanie danych.

Pola nagłówka TCP (4)

• Wartość pola Rozmiar okna określa liczbę bajtów, które mogą zostać wysłane, począwszy od bajta o numerze sekwencyjnym określonym w polu Numer

potwierdzenia.

• Zerowa wartość tego pola jest całkowicie poprawna – oznacza ona, że bajty o numerze sekwencyjnym do (Numer potwierdzenia-1) włącznie zostały odebrane poprawnie, lecz z wysyłaniem następnych host

powinien się chwilowo wstrzymać.

• Pole Sumy kontrolnej zapewnia dodatkową kontrolę poprawności transmisji. Suma ta obliczana jest dla obszaru nagłówka uzupełnionego o pseudonagłówek.

Nawiązywanie połączenia TCP

Zwalnianie połączenia TCP

Model TCP zarządzania połączeniami

• Stany automatu skończonego reprezentującego zarządzanie połączeniami TCP

Stan Znaczenie

CLOSED Brak aktywnych połączeń i nieobsłużonych żądań połączenia.

LISTEN Serwer oczekuje na żądanie połączenia.

SYN RCVD Otrzymano żądanie połączenia; oczekiwanie na ACK.

SYN SENT Aplikacja rozpoczyna nawiązywanie połączenia.

ESTABLISHED Normalny stan transmisji danych.

FIN WAIT 1 Aplikacja sygnalizuje zakończenie wysyłania danych.

FIN WAIT 2 Druga strona zgadza się na zwolnienie połączenia.

TIMED WAIT Oczekiwanie na wygaśnięcie wszystkich pakietów.

CLOSING Obydwie strony próbują jednocześnie zamknąć połączenie.

CLOSE WAIT Druga strona połączenia zainicjowała jego zwalnianie.

LAST ACK Oczekiwanie na potwierdzenie zwolnienia połączenia.

Diagram stanów TCP

Zarządzanie oknem w TCP

Okna przesuwne

• Mimo odebrania ogłoszenia zerowego rozmiaru okna host-nadawca może jednak nadal wysyłać dane:

• Po pierwsze, mogą zostać wysłane dane pilne

• Po drugie, host-nadawca może zażądać od hosta-odbiorcy powtórnego przesłania numeru sekwencyjnego następnego spodziewanego bajta oraz rozmiaru okna, by uniknąć

zakleszczenia (ang. deadlock), gdy zagubiony zostanie segment oznajmiający nadawcy niezerowy rozmiar okna.

• Potwierdzenia powinny być wysyłane dopiero wtedy, kiedy udało się odebrać wszystkie dane aż do

potwierdzanego bajta (a nie w momencie odebrania segmentu, który może być poza kolejnością). To tak zwane potwierdzenie zbiorcze.

Zarządzanie czasem przez TCP

• Do poprawnej pracy protokołu TCP konieczne jest wykorzystywanie wielu zegarów i stoperów:

• Stoper retransmisji (ang. retransmission timeout).

• Stoper przetrwania (ang. persistence timer). Jego zadaniem jest zapobieganie zastojom wywoływanym zagubieniem

komunikatów o rozmiarze okna.

• Stoper żywotności (ang. keepalive timer). W przypadku

dłuższej bezczynności połączenia powoduje on wysłanie do partnera próbnego komunikatu; brak odpowiedzi na ten komunikat powoduje jednostronne zwolnienie połączenia.

• Ostatni z zegarów TCP uruchamiany jest bezpośrednio przed zwolnieniem połączenia, gdy znajduje się ono w stanie TIME WAIT. Jego wartość ustawiana jest na dwukrotność

maksymalnego czasu życia pakietu w sieci.

Prawdopodobieństwo czasów przybywania potwierdzeń

• (a) w warstwie łącza danych, (b) w protokole TCP

Prawdopodobieństwo czasów przybywania potwierdzeń

• Ustalenie granicy zbyt malej – jak wartość T

– spowoduje wzrost niepotrzebnych retransmisji i

„zaśmiecenie” Internetu niepotrzebnymi pakietami.

• Zbyt duża granica (jak T

) spowoduje z kolei spadek efektywności z powodu zbyt długiego oczekiwania na retransmisję pakietów faktycznie zagubionych.

• Co więcej, parametry funkcji gęstości

prawdopodobieństwa podlegać mogą gwałtownym

zmianom w ciągu kilku sekund, głównie z powodu

występowania (i zanikania) przeciążeń.

Zarządzanie czasem przez TCP:

stoper retransmisji

• Dynamiczny algorytm nieustannego adaptowania

wartości granicznej stopera retransmisji do wyników nieustannie wykonywanych pomiarów wydajności sieci (algorytm Jacobsona, 1988).

• Jacobson uwrażliwił czas graniczny retransmisji na

zmiany RTT i równocześnie powiązał je z filtrowaniem odchyleń RTT.

• Dla każdego połączenia utrzymywana jest zmienna SRTT (Smoothed Round-Trip Time) – najlepszy znany dotąd czas wędrówki pakietu do swego punktu

przeznaczenia.

• W momencie wysyłania segmentu zmierzony zostaje czas nadejścia potwierdzenia R.

Zarządzanie czasem przez TCP:

stoper retransmisji

• Wartość zmiennej SRTT zostaje zmodyfikowana:

𝑆𝑅𝑇𝑇 = 𝛼 ∙ 𝑆𝑅𝑇𝑇 + 1 − 𝛼 ∙ 𝑅

• RTTVAR (Round-Trip Time VARiation) odchylenie

𝑅𝑇𝑇𝑉𝐴𝑅 = 𝛽 ∙ 𝑅𝑇𝑇𝑉𝐴𝑅 + 1 − 𝛽 ∙ 𝑆𝑅𝑇𝑇 − 𝑅

• Stoper retransmisji RTO ustawia się wtedy według wzoru:

𝑅𝑇𝑂 = 𝑆𝑅𝑇𝑇 + 4 ∙ 𝑅𝑇𝑇𝑉𝐴𝑅

• Więcej informacji o sposobie obliczania czasu

retransmisji podaje dokument RFC 2988.

Kontrola przeciążeń w TCP

• Warstwa sieciowa wykrywa przeciążenie po wzroście długości kolejek pakietów na routerach i próbuje na to przeciążenie reagować, nawet jeśli reakcja sprowadza się do odrzucania pakietów.

• Właściwym adresatem informacji o przeciążeniu sieci jest warstwa transportowa, która powinna zareagować nań poprzez zmniejszenie szybkości wysyłania danych do sieci.

• Kluczowym elementem kontroli przeciążeń jest wdrożenie zasady sterującej addytywnego

przyspieszania i multiplikatywnego spowalniania transmisji AIMD (Additive Increase Multiplicative Decrease), która pozwala na konwergencję do optymalnego punktu pracy sieci.

Okno przeciążenia oraz okno sterowania przepływem

• W TCP implementowane jest okno przeciążenia (ang.

congestion window), którego rozmiar jest równy liczbie bajtów, jaka może obecnie być transmitowana siecią.

TCP dopasowuje rozmiar okna zgodnie z zasadą AIMD.

• Okno przeciążenia jest utrzymywane obok okna

sterowania przepływem, określającego liczbę bajtów mieszczących się w buforze odbiorcy.

• Oba okna są utrzymywane równocześnie, a liczba bajtów, które nadawca może wysłać do sieci, to mniejszy z rozmiarów obu okien.

• Efektywne okno nadawcze jest kompromisem pomiędzy możliwościami sieci i możliwościami odbiorcy.

Takt potwierdzeń

• Czasy dostarczania potwierdzeń odzwierciedlają przepustowość najwolniejszego łącza w ścieżce.

• Odstępy czasowe potwierdzeń nazywa się interwałem potwierdzeń albo taktem potwierdzeń (ang. ack clock).

• Dzięki taktowi potwierdzeń TCP wygładza ruch sieciowy i zapobiega niepotrzebnemu natłokowi pakietów w

routerach.

Algorytm powolnego rozruchu

• Powolny rozruch sprawdza się w przypadku szerokiego zakresu prędkości łączy i czasów opóźnień RTT, a

prędkość wysyłania dostosowuje do możliwości ścieżki sieciowej na podstawie taktu potwierdzeń.

Algorytm powolnego rozruchu z początkowego okna przeciążenia o rozmiarze 1

Addytywne przyspieszanie od początkowego okna przeciążenia o rozmiarze jednego segmentu

Potwierdzenia powielone i szybka retransmisja

• Nadawca może więc rozpoznać utratę pakietu nie po przekroczeniu czasu retransmisji, ale po

odebraniu potwierdzeń z tymi samymi numerami.

Takie potwierdzenia nazwiemy potwierdzeniami

• Szybka retransmisja (ang. fast retransmission):

kiedy do niej dojdzie, próg powolnego rozruchu jest ustawiany na połowę osiągniętego rozmiaru okna przeciążenia, dokładnie tak jak w przypadku

przekroczenia czasu retransmisji.

Powolny rozruch i przyspieszanie

addytywne w TCP Tahoe

Potwierdzenia wybiórcze SACK

• W potwierdzeniach wybiórczych SACK (Selective ACKnowledgements) podaje się maksymalnie trzy zakresy bajtów już odebranych.

• SACK to informacja czysto doradcza. Opcja SACK jest obecnie stosowana bardzo szeroko; opisuje ją

dokument RFC 2883, a mechanizm kontroli przeciążeń w kontekście potwierdzeń SACK opisuje RFC 3517.

WARSTWA APLIKACJI

DNS – System Nazw

Domen

System Nazw Domenowych

• Adresy IP nie są wygodne do zapamiętywania, poza tym nie zawsze są one do określonych zasobów

przypisywane w sposób permanentny

• Posługiwanie się nazwami mnemonicznymi hostów wymaga obecności mechanizmu dokonującego

konwersji tychże nazw na stosowne adresy IP

• Istotą DNS jest nadanie nazwom mnemonicznym

struktury hierarchicznej opartej na koncepcji domen i zarządzanie nimi w postaci rozproszonego systemu baz danych

• System DNS opisany jest w dokumentach RFC 1034,1035 i 2181

Przestrzeń nazw DNS

• W Internecie najwyższy poziom hierarchii nazw jest zarządzany przez ICANN (ang. Internet Corporation for Assigned Names and Numbers — internetowa

korporacja ds. przydziału nazw i numerów).

• Domeny najwyższego poziomu dzielą się na dwie

kategorie: rodzajowe (ang. generic) i narodowe (ang.

countries).

• W 2010 roku wprowadzono domeny narodowe wykorzystujące znaki diakrytyczne poszczególnych języków.

• Nazwa każdego członu domeny może liczyć co najwyżej 63 znaki; długość całej nazwy domeny ograniczona jest natomiast do 255 znaków.

Przestrzeń nazw DNS

Rodzajowe domeny najwyższego poziomu

Domena Planowane przeznaczenie Data utworzenia Ograniczenia?

com Zastosowania komercyjne 1985 Nie

edu Instytucje edukacyjne 1985 Tak

gov Instytucje rządowe 1985 Tak

int Organizacje międzynarodowe 1988 Tak

mil Wojsko 1985 Tak

net Operatorzy sieci 1985 Nie

org Organizacje niekomercyjne 1985 Nie

aero Transport lotniczy 2001 Tak

biz Zastosowania biznesowe 2001 Nie

coop Kooperatywy 2001 Tak

info Działalność informacyjna 2002 Nie

museum Muzea 2002 Tak

name Osoby prywatne 2002 Nie

pro Profesjonaliści 2002 Tak

cat Katalonia 2005 Tak

jobs Zatrudnienie 2005 Tak

mobi Urządzenia mobilne 2005 Tak

tel Dane kontaktowe 2005 Tak

travel Działalność turystyczna 2005 Tak

xxx Branża erotyczna 2010 Nie

Rekordy zasobów domenowych

• Do każdej domeny mogą być przedzielane rekordy

składają się na bazę danych systemu DNS.

• Podstawową funkcją DNS jest więc w istocie

odwzorowywanie nazw domen na zbiory rekordów zasobów.

• Rekord zasobów składa się z pięciu części:

Nazwa_domeny Czas_życia Klasa Typ Wartość

Najważniejsze typy rekordów zasobowych DNS

Typ Znaczenie Wartość

SOA Początek strefy wpływów Parametry strefy serwera nazw

A Adres IP hosta 32-bitowa liczba całkowita

AAAA Adres IPv6 hosta 128-bitowa liczba całkowita

MX Wymiana poczty Nazwa i priorytet serwera pocztowego domeny

NS Serwer nazw Nazwa serwera DNS dla domeny

CNAME Nazwa kanoniczna Nazwa domeny

PTR Wskaźnik Alias adresu IP

SPF Sender Policy Framework Zasady rozsyłania poczty elektronicznej

SRV Usługa Host, na którym uruchomiono usługę

TXT Tekst Tekst w postaci łańcucha ASCII

niepodlegający interpretacji

Przykład podziału przestrzeni nazw

DNS na strefy

Serwery nazw

• Położenie granicy stref w obrębie strefy pozostaje w gestii jej administratora. Decyzja ta jest zazwyczaj podejmowana w oparciu o liczbę potrzebnych

serwerów DNS i ich pożądane rozmieszczenie.

• Każda ze stref jest skojarzona z jednym lub wieloma

serwerami nazw.

13 głównych (pierwszorzędnych)

serwerów DNS

13 pierwszorzędnych serwerów nazw

Nazwa hosta IP Adresy Zarządca

a.root-servers.net 198.41.0.4, 2001:503:ba3e::2:30 VeriSign, Inc.

b.root-servers.net 192.228.79.201, 2001:500:84::b University of Southern California (ISI) c.root-servers.net 192.33.4.12, 2001:500:2::c Cogent Communications

d.root-servers.net 199.7.91.13, 2001:500:2d::d University of Maryland

e.root-servers.net 192.203.230.10 NASA (Ames Research Center) f.root-servers.net 192.5.5.241, 2001:500:2f::f Internet Systems Consortium, Inc.

g.root-servers.net 192.112.36.4 US Department of Defense (NIC) h.root-servers.net 198.97.190.53, 2001:500:1::53 US Army (Research Lab)

i.root-servers.net 192.36.148.17, 2001:7fe::53 Netnod j.root-servers.net 192.58.128.30, 2001:503:c27::2:30 VeriSign, Inc.

k.root-servers.net 193.0.14.129, 2001:7fd::1 RIPE NCC l.root-servers.net 199.7.83.42, 2001:500:9f::42 ICANN

m.root-servers.net 202.12.27.33, 2001:dc3::35 WIDE Project

Główne serwery DNS: ponad 130

lokacji fizyczne

Rozwiązywanie nazw

• Proces wyszukiwania nazwy i odnajdywania adresu sieciowego to tak zwane rozwiązywanie nazw (ang.

name resolution).

• Rekordem wiarygodnym (ang. authoritative record) nazywamy taki rekord, który pochodzi

bezpośrednio od ciała zarządzającego, a więc jako taki jest zawsze poprawny.

• Rekordom wiarygodnym możemy przeciwstawić

mogą okazać się przeterminowane.

Przykład wyszukiwania nazwy

zdalnej

Mechanizmy odpytań

• Kiedy host wysyła swoje zapytanie do lokalnego serwera nazw, ów serwer nazw obsługuje

rozwiązanie nazwy w imieniu hosta dopóty, dopóki może zwrócić ostateczną odpowiedź; lokalny

serwer nazw nie zwraca odpowiedzi częściowych.

Ten mechanizm nosi nazwę zapytania

• Z drugiej strony, pierwszorzędny serwer nazw (i wszystkie kolejne serwery nazw) nie realizuje zapytań rekurencyjnych i odsyła odpowiedź

częściową. Tu mamy do czynienia z zapytaniem

Protokół DNS

• Protokół transportowy wykorzystywany do wymiany zapytań i odpowiedzi jest UDP, port serwera 53.

• Format komunikatu DNS:

NAGŁÓWEK – (Header)

ZAPYTANIE – (Question) do serwera nazw

ODPOWIEDŹ – (Answer) zawiera rekordy będące odpowiedzią

ZWIERZCHNOŚĆ – (Authority) wskazuje serwery zwierzchnie dla domeny DODATKOWA – (Additional) sekcja informacji dodatkowych

Nagłówek DNS

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

ID

QR OPCODE AA TC RD RA Z RCODE

QDCOUNT ANCOUNT NSCOUNT ARCOUNT

Pola nagłówka DNS

• ID – identyfikator tworzony przez program wysyłający zapytanie

• QR – określa, czy komunikat jest zapytaniem (0) czy odpowiedzią (1)

• OPCODE – określa rodzaj zapytania wysyłanego od klienta

• AA – oznacza, że odpowiedź jest autorytatywna.

• TC – oznacza, że odpowiedź nie zmieściła się w jednym pakiecie UDP i została obcięta.

• RD – oznacza, że klient żąda rekurencji

• RA – bit oznaczający, że serwer obsługuje zapytania rekurencyjne

• Z – zarezerwowane do przyszłego wykorzystania.

• RCODE – kod odpowiedzi.

• QDCOUNT – określa liczbę wpisów w sekcji zapytania

• ANCOUNT – określa liczbę rekordów zasobów w sekcji odpowiedzi

• NSCOUNT – określa liczbę rekordów serwera w sekcji zwierzchności

• ARCOUNT – określa liczbę rekordów zasobów w sekcji dodatkowej

Poczta Elektroniczna

Architektura systemu poczty elektronicznej

• MUA (Mail User Agent) – Program używany przez odbiorcę końcowego do wysyłania, odbierania, filtrowania, czytania, pisania listów itp.

• MTA (Mail Transfer Agent) – Część systemu

pocztowego zajmująca się odbiorem poczty i/lub jej dalszym przekazaniem do innych serwerów

• MDA (Mail Delivery Agent) – Część systemu

pocztowego zajmująca się dostarczaniem poczty do lokalnego użytkownika

Formaty wiadomości

• Format adresu: użytkownik@nazwa-domenowa

• Każda wiadomość składa się z prymitywnej koperty (opisanej jako część systemu SMTP w dokumencie RFC 5321), nagłówka stanowiącego ciąg pewnej liczby pól, pustego wiersza i ciała.

• Użytkownicy mogą definiować własne pola

nagłówka dla użytku prywatnego. Nazwy tych pól rozpoczynają się przedrostkiem X-.

• RFC 5322 nie narzuca żadnych ograniczeń na treść

wiadomości.

Zdefiniowane w RFC 5322 podstawowe pola nagłówka

Pole Zawartość

To: Adresy głównych odbiorców Cc: Adresy odbiorców dodatkowych

Bcc: Adresy odbiorców informowanych w sposób poufny o wysłaniu wiadomości From: Identyfikator osoby tworzącej wiadomość

Sender: Adres osoby wysyłającej wiadomość

Received: Pole dodawane przez każdego agenta transmisji napotykanego na trasie wysłanej wiadomości

Return-Path: Adres zwrotny dla odpowiedzi

Niektóre ze zdefiniowanych w RFC 5322 dodatkowych pól nagłówka

Pole Zawartość

Date: Data i czas wysłania wiadomości

Reply-To: Adres, na który powinna zostać wysłana odpowiedź

Message-Id: Unikalny numer jednoznacznie identyfikujący wiadomość

In-Reply-To: Identyfikator (Message-Id:) wiadomości, dla której niniejsza wiadomość jest odpowiedzią

References: Identyfikatory innych wiadomości powiązanych z niniejszą wiadomością Keywords: Zdefiniowane przez użytkownika pola kluczowe zawarte w treści

wiadomości

Subject: Jednowierszowe streszczenie treści wiadomości

MIME — uniwersalne rozszerzenie poczty internetowej

• MIME – Multipurpose Internet Mail Extension.

• Elastyczność systemu MIME pozwala stosować go również w innych formach komunikacji z treściami o zróżnicowanym typie, na przykład w systemie WWW.

• System MIME opisano w dokumentach RFC 2045–

2047, 4288, 4289 i 2049.

Format wiadomości

Pola nagłówka MIME

Pole Zawartość

MIME-Version: Identyfikator wersji MIME

Content-Description: Nieformalny opis zawartości wiadomości Content-Id: Unikalny identyfikator treści wiadomości

Content-TransferEncoding: Schemat przystosowujący zawartość wiadomości do transmisji sieciowej

Content-Type: Typ i format zawartości wiadomości

Typy i przykładowe podtypy MIME

Typ Podtyp Rodzaj zawartości

text plain, html, xml, css Dane tekstowe w różnych formatach zapisu image gif, jpeg, tiff Dane graficzne (obrazki)

audio basic, mpeg, mp4 Dane dźwiękowe

video mpeg, mp4, quicktime Filmy

model vrml Modele 3D

application octet-stream, pdf, javascript, zip Dane binarne generowane przez aplikacje

message http,rfc822 Wiadomości osadzone

multipart mixed, alternative, paralell, digest Kombinacje różnych typów

Transfer wiadomości

• Przesyłanie poczty w Internecie inicjowane jest przez nawiązanie przez agenta użytkownika

połączenia TCP (na port 25) do serwera poczty elektronicznej.

• SMTP – Simple Mail Transfer Protocol (Protokół Prostego Przesyłania Poczty) RFC 2821

• Protokół niezawodnego przesyłania wiadomości

tekstowych (e-mail) za pomocą prostych komend

tekstowych.

SMTP

Dialog SMTP

Komendy SMTP i ESMTP

• SMTP

• ESMTP

Komenda Opis

DATA przesłanie treści listu

HELO nawiązanie połączenia SMTP HELP wypis dostępnych komend MAIL nadawca listu

NOOP podtrzymywanie połączenia QUIT zakończenie sesji SMTP RCPT odbiorca listu

RSET przerwanie sesji SMTP

VRFY sprawdzenie obecności skrzynki pocztowej o podanej nazwie

Komenda Opis

AUTH autoryzacja

DSN powiadamianie o statusie doręczenia EHLO spis obsługiwanych komend ESMTP

ETRN przesłanie kolejki listów przeznaczonych do podłączającego się serwera PIPELINING potokowe przesyłanie wiadomości

SIZE określenie wielkości przesyłanej wiadomości 8BITMIME wsparcie dla 8bitowego kodowania wiadomości

RESTART wznowienie przesyłania wiadomości przy rozłączeniu sesji

Kody zwrotne SMTP

1xy Wstępna akceptacja komendy Komenda zaakceptowana, ale oczekiwanie na dalszą decyzję użytkownika. Używane tylko w ESMTP

2xy Akceptacja komendy Komenda zaakceptowana, oczekiwanie na następną.

3xy Pośrednia akceptacja komendy Komenda zaakceptowana, ale oczekiwanie na dalszą jej część.

4xy Przejściowe odrzucenie komendy Komenda nie zaakceptowana, tymczasowo 5xy Permanentne odrzucenie komendy Komenda nie zaakceptowana, ostatecznie

Kod Opis

220 Usługa aktywna, oczekiwanie na komendy 250 Akceptacja komendy

354 Oczekiwanie na wprowadzanie treści listu

450 Skrzynka użytkownika zajęta (np. zablokowana przez proces) 452 Skrzynka użytkownika przepełniona

500 Brak takiego polecenia 501 Błąd w składni polecenia

552 Brak miejsca na dysku (serwer)

SMTP – przekazywanie poczty

między MUA, MTA i MDA

Protokoły dostarczania końcowego

• Zadaniem programu pocztowego jest

zaprezentowanie zawartości zdalnej skrzynki

pocztowej, a także umożliwienie manipulowania jej zawartością.

• Dostarczanie końcowe musi się odbywać na

zasadzie pobierania oczekujących wiadomości na

żądanie.

Protokół IMAP

• Jednym z ważniejszych protokołów dostarczania końcowego jest protokół dostępu do wiadomości internetowych, IMAP (Internet Message Access

• Czwarta wersja tego protokołu została zdefiniowana w dokumencie RFC 3501.

• Transport – TCP, port 143.

• Po zalogowaniu klient może wysyłać do serwera

rozliczne polecenia związane z przeglądaniem

wiadomości i folderów oraz zarządzaniem nimi.

Polecenia protokołu IMAP

Polecenie Opis

CAPABILITY Wypis możliwości serwera

STARTTLS Inicjacja bezpiecznego transportu TLS (patrz rozdział 8.)

LOGIN Logowanie do serwera

AUTHENTICATE Logowanie inną metodą

SELECT Wybranie folderu

EXAMINE Wybranie folderu tylko do odczytu CREATE Utworzenie folderu

DELETE Usunięcie folderu RENAME Zmiana nazwy folderu

SUBSCRIBE Dodanie folderu do zestawu folderów aktywnych UNSUBSCRIBE Usunięcie folderu z zestawu folderów aktywnych

LIST Wypis dostępnych folderów

LSUB Wypis aktywnych folderów

Polecenia protokołu IMAP (2)

Polecenie Opis

STATUS Pobranie statusu folderu

APPEND Dodanie wiadomości do folderu CHECK Pobranie punktu kontrolnego folderu FETCH Pobranie wiadomości z folderu

SEARCH Wyszukanie wiadomości w folderze STORE Zmiana znaczników wiadomości

COPY Utworzenie kopii wiadomości we wskazanym folderze EXPUNGE Usunięcie wiadomości oznaczonej do usunięcia

UID Polecenia z unikatowymi identyfikatorami

NOOP Brak operacji

CLOSE Usunięcie oznaczonych wiadomości i zamknięcie folderu LOGOUT Wylogowanie i zamknięcie połączenia

Protokół POP3

• IMAP stanowi rozwinięcie i udoskonalenie

wcześniejszego protokołu dostarczania końcowego, którym był tak zwany protokół urzędu pocztowego, w skrócie POP3 (ang. Post Office Protocol Version 3),

zdefiniowany w RFC 1939.

• POP3 to protokół prostszy, ale też z mniejszą liczbą

funkcji i w typowych zastosowaniach mniej bezpieczny.

• W przypadku POP3 nie mamy wielu możliwości manipulacji wiadomościami po stronie serwera

pocztowego: poczta jest przede wszystkim ściągana na lokalny komputer użytkownika, do jego programu

pocztowego.

• Mimo to POP3 wciąż jest dość szeroko stosowany.

WWW

Przegląd architektury WWW

• Z punktu widzenia użytkownika sieć WWW jest

olbrzymią kolekcją rozmaitych treści w postaci stron WWW (ang. Web pages).

• Każda strona zawierać może łącza (ang. links) do innych stron; kliknięcie łącza spowoduje udostępnienie strony, do której ono prowadzi.

• Koncepcja stron powiązanych łączami nazywa się hipertekstem (ang. hypertext).

• Protokół żądania i odpowiedzi do pobierania stron WWW to prosty protokół tekstowy operujący na połączeniach TCP. Nosi on miano HTTP (HyperText Transfer Protocol).

Architektura sieci WWW

URL, URI oraz URN

• Każda strona posiada identyfikator w postaci jednolitego lokalizatora zasobów, w skrócie URL (ang. Uniform Resource Locator).

• URL składa się z trzech elementów: protokołu dostępowego (określanego też mianem schematu), nazwy DNS maszyny, na której znajduje się strona, oraz ścieżki jednoznacznie

identyfikującej konkretną stronę w zasobach danego serwera.

http://wmii.uwm.edu.pl/~yakovyna

Protokół (http), nazwa DNS serwera (wmii.uwm.edu.pl), ścieżka (~yakovyna).

• Ścieżka zasadniczo reprezentuje hierarchiczną nazwę

wzorowaną na strukturze systemu plików, ale interpretacja ścieżki pozostaje w gestii serwera WWW, który

niekoniecznie musi ją odwzorować na fizyczną strukturę dyskową.

URL, URI oraz URN

• Adresy URL zostały z czasem uogólnione do postaci identyfikatorów URI (Uniform Resource Identifiers).

Niektóre URI mówią, jak zlokalizować zasób: są to znane nam już adresy URL.

• Inne URI podają tylko nazwę zasobu, w oderwaniu od jego konkretnej lokalizacji; takie identyfikatory

nazwiemy URN, czyli nazwami zasobów (Uniform Resource Names).

• Reguły zapisu identyfikatorów URI wymienia dokument RFC 3986, natomiast różne schematy URI są zarządzane przez IANA.

URI => http://wmii.uwm.edu.pl/~yakovyna/Sieci_Dzien_5.pdf URL => http://wmii.uwm.edu.pl

URN => /~yakovyna/Sieci_Dzien_5.pdf

Jak działa przeglądarka

internetowa

HTTP – protokół przesyłu hipertekstu

• HTTP (HyperText Transfer Protocol) – protokół przesyłu hipertekstu, opisany w dokumencie RFC 2616.

• HTTP to prosty protokół typu żądanie-odpowiedź, zazwyczaj transportowany połączeniem TCP.

Określa on komunikaty, które klient może wysyłać do serwera, oraz odpowiedzi serwera do klienta.

• Treść przesyłana jest opatrywana typem MIME.

Połączenia HTTP

• Zwyczajowym sposobem kontaktowania się klienta z serwerem WWW jest ustanowienie połączenia

• Koncepcja połączenia trwałego (ang.persistent

connection). Po jego nawiązaniu można realizować

wiele żądań.

• Możliwa jest także realizacja żądań potokowych

(ang. pipelined requests) – kiedy kolejne żądanie

jest wysyłane, jeszcze zanim odebrano odpowiedź

na poprzednie.

Połączenia HTTP

(a) z osobnymi połączeniami dla żądań,

(b) z trwałym połączeniem dla kompletu żądań,

(c) z żądaniami potokowymi w obrębie pojedynczego połączenia

Metody HTTP

• HTTP: ‹Metoda› ‹URI› HTTP/‹Wersja›

• Każde żądanie HTTP ma postać jednego lub wielu wierszy tekstu, przy czym pierwsze słowo

pierwszego wiersza musi być nazwą metody.

Metoda Przedmiot żądania

GET Pobranie strony WWW

HEAD Pobranie nagłówka strony WWW POST Wystanie danych do strony WWW PUT Wystanie strony WWW na serwer DELETE Usunięcie strony WWW z serwera TRACE Odesłanie otrzymanego żądania

CONNECT Połączenie przez maszynę pośredniczącą (proxy) OPTIONS Opcje dla strony

Metody HTTP

Żądanie ma ciało

Odpowiedź ma ciało

Bezpieczny Idempotent Cacheable

GET NIE TAK TAK TAK TAK

HEAD NIE NIE TAK TAK TAK

POST TAK TAK NIE NIE TAK

PUT TAK TAK NIE TAK NIE

DELETE NIE TAK NIE TAK NIE

CONNECT TAK TAK NIE NIE NIE

OPTIONS OPCJONALNY TAK TAK TAK NIE

TRACE NIE TAK TAK TAK NIE

PATCH TAK TAK NIE NIE TAK

Bezpieczny (Safe) – nie powinien zmieniać stan serwera

Odpowiedzi serwera HTTP

Grupa Znaczenie Przykłady

1xx Informacja 100 = serwer zaakceptował żądanie klienta

2xx Powodzenie 200 = akceptacja, pomyślne zrealizowanie żądania 204 = nie żądano zawartości

3xx Przeadresowanie 301 = żądany zasób znajduje się pod innym adresem 304 = kopia strony w pamięci cache jest nadal aktualna 4xx Błąd klienta 403 = zabroniony dostęp do strony

404 = żądana strona nie istnieje 5xx Błąd serwera 500 = wewnętrzny błąd serwera

503 = spróbuj później

Odpowiedzi serwera HTTP

Nagłówki komunikatów

• Po linii zawierającej żądanie mogą występować kolejne linie zawierające dodatkową informację związaną z żądaniem.

• Linie te nazywane są nagłówkami żądań (ang.

Request headers) i mogą być porównane z

parametrami wywołania procedury.

• Analogicznie odpowiedź serwera może zawierać

Niektóre z nagłówków mogą być obecne zarówno w

żądaniu, jak i w odpowiedzi.

Niektóre nagłówki komunikatów HTTP

Nagłówek Typ Zawartość

User-Agent żądanie Informacja o przeglądarce i systemie operacyjnym Accept żądanie Typy stron, które klient jest w stanie obsłużyć Accept-Charset żądanie Zestaw znaków akceptowalny dla klienta Accept-Encoding żądanie Kodowanie obsługiwane przez klienta Accept-Language żądanie Wersja językowa systemu klienta

If-Modified-Since żądanie Czas do sprawdzenia świeżości strony (pobranie warunkowe)

If-None-Match żądanie Weryfikacja znaczników poprzedniego pobrania (pobranie warunkowe)

Host żądanie Nazwa DNS serwera

Authorization żądanie Lista uwierzytelnień klienta

Referer żądanie Poprzedni URL, z którego pochodzi bieżące żądanie Cookie żądanie Ustawione wcześniej ciasteczka, odsyłane do serwera Set-Cookie odpowiedź Ciasteczko do zapisania u klienta

Server odpowiedź Informacja o serwerze

Content-Encoding odpowiedź Sposób kodowania zawartości (np. gzip)

Niektóre nagłówki komunikatów HTTP

Nagłówek Typ Zawartość

Content-Language odpowiedź Wersja językowa strony Content-Length odpowiedź Długość strony w bajtach Content-Type odpowiedź Typ MIME zawartości strony

Content-Range odpowiedź Identyfikacja fragmentu zawartości strony (pobranie fragmentami)

Last-Modified odpowiedź Data i czas ostatniej modyfikacji strony Expires odpowiedź Termin „ważności” strony

Location odpowiedź Wymuszenie przekazania żądania pod inny adres Accept-Ranges odpowiedź Serwer akceptuje żądania zakresowe (pobieranie

fragmentami)

Date żądanie i odpowiedź Data i czas wysłania komunikatu Range żądanie i odpowiedź Identyfikacja fragmentu strony

Cache-Control żądanie i odpowiedź Dyrektywy sterujące zawartością pamięci podręcznej

ETag żądanie i odpowiedź Dodatkowe znaczniki zawartości strony

Upgrade żądanie i odpowiedź Protokół, na który nadawca żąda przełączenia

Oraz jeszcze są dużo innych protokołów, zasad działania sieci komputerowych i ich

bezpieczeństwo …