Warstwa transportu

55  Download (0)

Full text

(1)

3-1

Warstwa transportu

3-2

Mapa wykładu

Usługi warstwy transportu

Multipleksacja i demultipleksacja

Transport

bezpołączeniowy: UDP

Zasady niezawodnej komunikacji danych

Transport połączeniowy:

TCP

struktura segmentu

niezawodna komunikacja

kontrola przepływu

zarządzanie połączeniem

Mechanizmy kontroli przeciążenia

Kontrola przeciążenia w

TCP

(2)

3-3

Usługi i protokoły warstwy transportu

logiczna komunikacja pomiędzy procesami aplikacji działającymi na różnych hostach

protokoły transportowe działają na systemach końcowych

nadawca: dzieli komunikat aplikacji na segmenty, przekazuje segmenty do warstwy sieci

odbiorca: łączy segmenty w komunikat, który przekazuje do warstwy aplikacji

więcej niż jeden protokół transportowy

Internet: TCP oraz UDP ale może też być SAP (NetWare)

application transport network data link physical

application transport network data link physical network data link physical

network data link physical network

data link physical network data link physical network

data link physical

3-4

Warstwy transportu i sieci

warstwa sieci: logiczna komunikacja pomiędzy hostami

warstwa transportu:

logiczna komunikacja pomiędzy procesami

korzysta z oraz

uzupełnia usługi warstwy sieci

Analogia:

pracownicy firmy zamawiają pizzę

procesy = pracownicy

komunikaty = pizze

hosty = firma i pizzeria

protokół transportowy = zamawiający pracownik

protokół sieci =

doręczyciel pizzy

(3)

3-5

Protokoły transportowe Internetu

niezawodna, uporządkowana komunikacja (TCP)

kontrola przeciążenia

kontrola przepływu

tworzenie połączenia

zawodna, nieuporządkowana komunikacja (UDP)

proste rozszerzenie usługi

“best-effort” IP

niedostępne usługi:

gwarancje maksymalnego opóźnienia

gwarancje minimalnej przepustowości

application transport network data link physical

application transport network data link physical network data link physical

network data link physical network

data link physical network data link physical network

data link physical

3-6

Mapa wykładu

Usługi warstwy transportu

Multipleksacja i demultipleksacja

Transport

bezpołączeniowy: UDP

Zasady niezawodnej komunikacji danych

Transport połączeniowy:

TCP

struktura segmentu

niezawodna komunikacja

kontrola przepływu

zarządzanie połączeniem

Mechanizmy kontroli przeciążenia

Kontrola przeciążenia w

TCP

(4)

3-7

Multipleksacja/demultipleksacja

aplikacji transportu

sieci łącza fizyczna

P1 aplikacji

transportu sieci łącza fizyczna aplikacji

transportu sieci łącza fizyczna

P3 P1 P2 P4

host 1 host 2 host 3

= proces

= gniazdo

przekazywanie otrzymanych segmentów do właściwych gniazd Demultipleksacja u odbiorcy

zbieranie danych z wielu gniazd, dodanie nagłówka (używanego później przy demultipleksacji)

Multipleksacja u nadawcy

3-8

Jak działa demultipleksacja

host otrzymuje pakiety IP

każdy pakiet ma adres IP nadawcy, adres IP

odbiorcy

każdy pakiet zawiera jeden segment warstwy transportu

każdy segment ma port nadawcy i odbiorcy (pamiętać: powszechnie znane numery portów dla określonych aplikacji)

host używa adresu IP i portu żeby skierować segment do odpowiedniego gniazda

port nadawcy port odbiorcy 32 bity

dane aplikacji (komunikat) inne pola nagłówka

format segmentu TCP/UDP

(5)

3-9

Demultipleksacja bezpołączeniowa

Gniazda są tworzone przez podanie numeru portu:

DatagramSocket mojeGniazdo1 = new DatagramSocket(99111);

DatagramSocket mojeGniazdo2 = new DatagramSocket(99222);

Gniazdo UDP jest

identyfikowane przez parę:

(

adres IP odbiorcy, port odbiorcy)

Kiedy host otrzymuje segment UDP:

sprawdza port odbiorcy w segmencie

kieruje segment UDP do gniazda z odpowiednim numerem portu

Datagramy IP z

różnymi adresami IP lub portami nadawcy są kierowane do tego samego gniazda

3- 10

Demultipleksacja bezpołączeniowa (c.d.)

DatagramSocket gniazdoSerwera = new DatagramSocket(6428);

klient IP:B P2

klient IP: A

P1 P1 P3

serwer IP: C PN: 6428

PO: 9157

PN: 9157 PO: 6428

PN: 6428 PO: 5775

PN: 5775 PO: 6428

Port nadawcy (PN) jest „adresem zwrotnym”.

(6)

3- 11

Demultipleksacja połączeniowa

Gniazdo TCP jest określane przez cztery wartości:

adres IP nadawcy

port nadawcy

adres IP odbiorcy

port odbiorcy

Host odbierający używa wszystkich 4 wartości, żeby skierować segment do

właściwego gniazda

Uwaga: host sprawdza także 5 wartość: protokół

Host serwera może obsługiwać wiele gniazd TCP jednocześnie:

każde gniazdo ma inne 4 wartości

Serwery WWW mają oddzielne gniazda dla każdego klienta

HTTP z nietrwałymi połączeniami wymaga oddzielnego gniazda dla każdego żądania

3-

Demultipleksacja połączeniowa (c.d)

klient IP: B P1

klient IP: A

P2 P1 P4

serwer IP: C PN: 9157

PO: 80

PN: 9157 PO: 80

P5 P6 P3

IP-O: C IP-N: A

IP-O: C

IP-N: B PN: 5775

PO: 80

IP-O: C IP-N: B

(7)

3- 13

Demultipleksacja połączeniowa i serwer wielowątkowy

klient IP: B P1

klient IP: A

P2 P1

serwer IP: C PN: 9157

PO: 80

PN: 9157 PO: 80

P4 P3

IP-O: C IP-N: A

IP-O: C

IP-N: B PN: 5775

PO: 80

IP-O:C IP-N: B

3- 14

Porty komunikacyjne

Numer przydzielony przez system: 0

po wywołaniu bind system wybiera numer portu 1024- 5000 (znaleźć go można po wywołaniu getsockname())

Porty zarezerwowane: 1-1023

Porty dobrze znane: 1-255 (/etc/services)

Porty zwyczajowo zarezerwowane dla Unixa BSD: 256- 511

Przydzielane przez rresvport: 512-1023

Porty wolne 1024-65535

(8)

3- 15

Mapa wykładu

Usługi warstwy transportu

Multipleksacja i demultipleksacja

Transport

bezpołączeniowy: UDP

Zasady niezawodnej komunikacji danych

Transport połączeniowy:

TCP

struktura segmentu

niezawodna komunikacja

kontrola przepływu

zarządzanie połączeniem

Mechanizmy kontroli przeciążenia

Kontrola przeciążenia w TCP

3-

UDP: User Datagram Protocol [RFC 768]

“bez bajerów”, “odchudzony”

protokół transportowy Internetu

usługa typu “best effort”, segmenty UDP mogą zostać:

zgubione

dostarczone do aplikacji w zmienionej kolejności

bezpołączeniowy:

nie ma inicjalizacji między nadawcą i odbiorcą UDP

każdy segment UDP jest obsługiwany niezależnie od innych

Czemu istnieje UDP?

nie ma inicjalizacji połączenia (co może zwiększać opóźnienie)

prosty: nie ma stanu połączenia u nadawcy ani odbiorcy

mały nagłówek segmentu

nie ma kontroli

przeciążenia: UDP może słać dane tak szybko, jak chce

(9)

3- 17

Więcej o UDP

Często używane do

komunikacji strumieniowej

tolerującej straty

wrażliwej na opóźnienia

Inne zastosowania UDP

DNS

SNMP

niezawodna komunikacja po UDP: dodać niezawodność w warstwie aplikacji

Praca domowa

port nadawcy port odbiorcy 32 bity

Dane aplikacji (komunikat)

Format segmentu UDP długość suma kontrolna Długość segmentu

UDP w bajtach (z nagłówkiem)

3- 18

Suma kontrolna UDP

Nadawca:

traktuje zawartość segmentu jako ciąg 16- bitowych liczb całkowitych

suma kontrolna:

dodawanie (i potem negacja sumy) zawartości segmentu

nadawca wpisuje wartość sumy kontrolnej do odpowiedniego pola nagłówka UDP

Odbiorca:

oblicza sumę kontrolną odebranego segmentu

sprawdza, czy obliczona suma kontrolna jest równa tej, która jest w nagłówku:

NIE – wykryto błąd

TAK – Nie wykryto błędu.

Ale może błąd jest i tak?

Wrócimy do tego ….

Cel: odkrycie „błędów” (n.p., odwróconych bitów) w

przesłanym segmencie

(10)

3- 19

Przykład sumy kontrolnej

Uwaga

Dodając liczby, reszta z dodawania najbardziej znaczących bitów musi zostać dodana do wyniku (zawinięta, przeniesiona na początek)

Przykład: suma kontrolna dwóch liczb 16-bitowych

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 zawinięcie

suma suma kontrolna

3-

… na chwilę wracamy

Warstwy aplikacji do

(11)

21

Mapa wykładu

2.1 Zasady budowy protokołów w. aplikacji

2.2 WWW i HTTP

2.3 DNS

2.4 Programowanie przy użyciu gniazd TCP

2.5 Programowanie przy użyciu gniazd UDP

2.6 Poczta elektroniczna

SMTP, POP3, IMAP

2.7 FTP

2.8 Dystrybucja zawartości

Schowki Internetowe

Sieci dystrybucji zawartości

2.9 Dzielenie plików P2P

22

Programowanie gniazd UDP

UDP: brak “połączenia” pomiędzy klientem i serwerem

brak inicjalizacji połączenia

nadawca nadaje każdemu pakietowi adres IP i port odbiorcy

serwer musi pobrać adres IP, port nadawcy z otrzymanego pakietu

UDP: wysyłane informacje mogą być gubione lub otrzymywane w innym porządku

punkt widzenia programisty UDP udostępnia zawodną komunikację ciągów bajtów

(“datagramów”) pomiędzy klientem i serwerem

(12)

23

Interakcja klient/serwer: UDP

zamyka clientSocket

Serwer

(działa na hostid)

czyta odpowiedź z clientSocket tworzy gniazdo, clientSocket = DatagramSocket()

Klient

Tworzy, adresuje (hostid, port=x), wysyła datagram z komunikatem przez clientSocket

tworzy gniazdo, port=x, dla nadchodzących połączeń : serverSocket = DatagramSocket(x)

czyta komunikat z serverSocket

wysyła odpowiedź serverSocket podając adres i port klienta

24

Przykład: Klient w Javie (UDP)

sendPacket

do sieci z sieci

receivePacket

inFromUser

klawiatura monitor

clientSocket pakiet

UDP strumien

wejsciowy

pakiet UDP

gniazdo UDP

Wyjście: wysyła pakiet (przez TCP, wysyłał “strumień bajtów”)

Wejście: odbiera pakiet (przez TCP odbierał “strumień bajtów”)

Proces klienta

gniazdo UDP klienta

(13)

25

Przykład: klient w Javie (UDP)

import java.io.*;

import java.net.*;

class UDPClient {

public static void main(String args[]) throws Exception {

BufferedReader inFromUser =

new BufferedReader(new InputStreamReader(System.in));

DatagramSocket clientSocket = new DatagramSocket();

InetAddress IPAddress = InetAddress.getByName("hostname");

byte[] sendData = new byte[1024];

byte[] receiveData = new byte[1024];

String sentence = inFromUser.readLine();

sendData = sentence.getBytes();

Tworzy strumień wejściowy Tworzy gniazdo

klienta Tłumaczy nazwę

na adres IP używając DNS

26

Przykład: klient w Javie (UDP), c.d.

DatagramPacket sendPacket =

new DatagramPacket(sendData, sendData.length, IPAddress, 9876);

clientSocket.send(sendPacket);

DatagramPacket receivePacket =

new DatagramPacket(receiveData, receiveData.length);

clientSocket.receive(receivePacket);

String modifiedSentence =

new String(receivePacket.getData());

System.out.println("FROM SERVER:" + modifiedSentence);

clientSocket.close();

} }

Tworzy datagram z danymi do wysłania, długością, adresem IP, portem Wysyła datagram

do serwera Czyta datagram z serwera

(14)

27

Przykład: serwer w Javie (UDP)

import java.io.*;

import java.net.*;

class UDPServer {

public static void main(String args[]) throws Exception {

DatagramSocket serverSocket = new DatagramSocket(9876);

byte[] receiveData = new byte[1024];

byte[] sendData = new byte[1024];

while(true) {

DatagramPacket receivePacket =

new DatagramPacket(receiveData, receiveData.length);

serverSocket.receive(receivePacket);

Tworzy gniazdo UDP na porcie 9876

Tworzy miejsce na otrzymany datagram Odbiera datagram

28

Przykład: serwer w Javie (UDP), c.d.

String sentence = new String(receivePacket.getData());

InetAddress IPAddress = receivePacket.getAddress();

int port = receivePacket.getPort();

String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes();

DatagramPacket sendPacket =

new DatagramPacket(sendData, sendData.length, IPAddress, port);

serverSocket.send(sendPacket);

} } }

Pobiera adres IP, numer portu, nadawcy pakietu

Wysyła datagram przez gniazdo

Koniec pętli "while", powrót i oczekiwanie na następny datagram Tworzy datagram

do wysłania do klienta

(15)

3- 29

… wracamy do

Warstwy transportu

3- 30

Mapa wykładu

Usługi warstwy transportu

Multipleksacja i demultipleksacja

Transport

bezpołączeniowy: UDP

Zasady niezawodnej komunikacji danych

Transport połączeniowy:

TCP

struktura segmentu

niezawodna komunikacja

kontrola przepływu

zarządzanie połączeniem

Mechanizmy kontroli przeciążenia

Kontrola przeciążenia w

TCP

(16)

3- 31

Zasady niezawodnej komunikacji danych

Ważne w warstwie aplikacji, transportu i łącza

Jeden z najważniejszych tematów w dziedzinie sieci!

charakterystyka zawodnego kanału określa złożoność niezawodnego protokołu komunikacji (npk)

warstwa wyższa

warstwa niższa warstwa niezawodna

Proces

nadawcy Proces odbiorcy kanał niezawodny

dane dane

kanał zawodny

pakiet pakiet

Niezawodny protokół transportowy

(nadawca) npk_send()

zpk_send() npk_recv() Niezawodny

protokół transportowy

(odbiorca) deliver_data()

dane dane

a) udostępniana usługa

b) implementacja usługi

3-

Niezawodna komunikacja (npk)

warstwa niższa warstwa niezawodna

kanał zawodny pakiet pakiet

npk_send ()

zpk_send ()

npk_recv ()

Niezawodny protokół transportowy

(odbiorca)

deliver_data ()

dane dane

Niezawodny protokół transportowy

(nadawca)

nadawca odbiorca

npk_send(): wywoływany przez wyższą warstwę.

Przekazuje dane do przesłania do odbiorcy

deliver_data():

wywoływany przez npk.

Przekazuje dane do wyższej warstwy

zpk_send(): wywoływany przez npk. Wysyła pakiet

przez zawodny kanał do odbiorcy

npk_rcv(): wywoływany przez niższą warstwę, gdy pakiet zostanie odebrany po

stronie odbiorcy

(17)

3- 33

Niezawodna komunikacja: początki

Co zrobimy:

stopniowo zaprojektujemy nadawcę i odbiorcę niezawodnego protokołu komunikacji (npk)

komunikacja danych tylko w jedną stronę

ale dane kontrolne w obie strony!

użyjemy automatów skończonych (AS) do specyfikacji nadawcy, odbiorcy

stan

1 stan

2 zdarzenie powodujące zmianę stanu czynności wykonywane przy zmianie stanu stan: w określonym

“stanie”, następny stan jest jednoznacznie określony przez następne zdarzenie

zdarzenie (lub brak: ) czynności (lub brak: )

3- 34

Npk1.0: niezawodna komunikacja przez niezawodny kanał

używany kanał jest w pełni niezawodny

nie ma błędów bitowych

pakiety nie są tracone

oddzielne AS dla nadawcy, odbiorcy:

nadawca wysyła dane przez kanał

odbiorca odbiera dane z kanału

Czekaj na wywołanie

z góry packet = make_pkt(data) zpk_send(packet) npk_send(data)

extract (packet,data) deliver_data(data) npk_rcv(packet)

nadawca odbiorca

Czekaj na wywołanie z dołu

(18)

3- 35

Npk2.0: kanał z błędami bitowymi

kanał może zmieniać bity w pakiecie

suma kontrolna pozwala rozpoznać błędy bitowe

pytanie: jak naprawić błąd:

potwierdzenia (ang. acknowledgement, ACKs): odbiorca zawiadamia nadawcę, że pakiet jest dotarł bez błędu

negatywne potwierdzenia (NAKs): odbiorca zawiadamia nadawcę, że pakiet ma błędy

nadawca retransmituje pakiet po otrzymaniu NAK

nowe mechanizmy w npk2.0:

rozpoznawanie błędów

informacja zwrotna od odbiorcy: komunikaty kontrolne (ACK,NAK) odbiorca->nadawca

3-

npk2.0: specyfikacja AS

snkpkt = make_pkt(data, checksum) zpk_send(sndpkt)

extract(rcvpkt,data) deliver_data(data)

zpk_send(ACK) npk_rcv(rcvpkt) &&

notcorrupt(rcvpkt) npk_rcv(rcvpkt) && isACK(rcvpkt)

zpk_send(sndpkt )

npk_rcv(rcvpkt) &&

isNAK(rcvpkt)

zpk_send(NAK) npk_rcv(rcvpkt) &&

corrupt(rcvpkt) Czekaj na

ACK lub NAK

Czekaj na wywołanie z dołu

nadawca

odbiorca

npk_send(data)

Czekaj na wywołanie

z góry

(19)

3- 37

npk2.0: działanie bez błędów

Czekaj na wywołanie

z góry

snkpkt = make_pkt(data, checksum) zpk_send(sndpkt)

extract(rcvpkt,data) deliver_data(data)

zpk_send(ACK) npk_rcv(rcvpkt) &&

notcorrupt(rcvpkt) npk_rcv(rcvpkt) && isACK(rcvpkt)

zpk_send(sndpkt )

npk_rcv(rcvpkt) &&

isNAK(rcvpkt)

zpk_send(NAK) npk_rcv(rcvpkt) &&

corrupt(rcvpkt)

Czekaj na ACK lub

NAK

Czekaj na wywołanie z dołu

npk_send(data)

3- 38

npk2.0: działanie z błędami

Czekaj na wywołanie

z góry

snkpkt = make_pkt(data, checksum) zpk_send(sndpkt)

extract(rcvpkt,data) deliver_data(data)

zpk_send(ACK) npk_rcv(rcvpkt) &&

notcorrupt(rcvpkt) npk_rcv(rcvpkt) && isACK(rcvpkt)

zpk_send(sndpkt )

npk_rcv(rcvpkt) &&

isNAK(rcvpkt)

zpk_send(NAK) npk_rcv(rcvpkt) &&

corrupt(rcvpkt)

Czekaj na ACK lub

NAK

Czekaj na wywołanie z dołu

npk_send(data)

(20)

3- 39

npk2.0 ma fatalny błąd!

Co się stanie, gdy

ACK/NAK będzie miał błąd?

nadawca nie wie, co się stało u odbiorcy!

nie można po prostu zawsze retransmitować: możliwe jest wysłanie pakietu podwójnie (duplikatu).

Obsługa duplikatów:

nadawca dodaje numer

sekwencyjny do każdego pakietu

nadawca retransmituje aktualny pakiet, jeśli ACK/NAK ma błąd

odbiorca wyrzuca (nie

przekazuje wyżej) zduplikowane pakiety

Nadawca wysyła jeden pakiet, potem czeka na odpowiedź

odbiorcy wstrzymaj i czekaj

3-

npk2.1: nadawca, obsługuje błędne ACK/NAK

Czekaj na wywołanie z góry

sndpkt = make_pkt(0, data, checksum) zpk_send(sndpkt)

npk_send(data)

Czekaj na ACK lub

NAK zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isNAK(rcvpkt) )

sndpkt = make_pkt(1, data, checksum) zpk_send(sndpkt)

npk_send(data)

npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt)

zpk_send(sndpkt) npk_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isNAK(rcvpkt) ) npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt)

Czekaj na wywołanie z góry Czekaj na

ACK lub NAK

numer=0 numer=0

numer=1 numer=1

(21)

3- 41

npk2.1: odbiorca, obsługuje błędne ACK/NAK

Czekaj na wyw.

z dołu

sndpkt = make_pkt(NAK, chksum) zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

not corrupt(rcvpkt) &&

has_seq0(rcvpkt)

npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum)

zpk_send(sndpkt) npk_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq0(rcvpkt) extract(rcvpkt,data)

deliver_data(data) sndpkt = make_pkt(ACK, chksum)

zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

(corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum) zpk_send(sndpkt) npk_rcv(rcvpkt) &&

not corrupt(rcvpkt) &&

has_seq1(rcvpkt) npk_rcv(rcvpkt) &&

(corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum) zpk_send(sndpkt) sndpkt = make_pkt(NAK, chksum)

zpk_send(sndpkt)

numer=0

Czekaj na wyw.

z dołu numer=1

3- 42

npk2.1: dyskusja

Nadawca:

Dodaje numer sekwencyjny do pakietu

Dwa numery (0,1) wystarczą.

Dlaczego?

musi sprawdzać, czy ACK/NAK jest poprawny

dwa razy więcej stanów (niż w npk2.0)

stan musi “pamiętać” aktualny numer sekwencyjny (0 lub 1)

Odbiorca:

musi sprawdzać, czy odebrany pakiet jest duplikatem

stan wskazuje, czy oczekuje numeru sekwencyjnego 0, czy 1

uwaga: odbiorca może nie wiedzieć czy ostatni

ACK/NAK został poprawnie

odebrany przez nadawcę

(22)

3- 43

npk2.2: protokół bez negatywnych potwierdzeń (NAK)

ta sama funkcjonalność co w npk2.1, używając tylko zwykłych potwierdzeń (ACK)

zamiast NAK, odbiorca wysyła ACK za ostatni poprawnie odebrany pakiet

odbiorca musi dodać numer sekwencyjny pakietu, który jest potwierdzany

powtórne ACK u nadawcy powoduje tę samą czynność co NAK: retransmisję ostatnio wysłanego pakietu

3-

npk2.2: fragmenty nadawcy, odbiorcy

Czekaj na wywołanie z góry

sndpkt = make_pkt(0, data, checksum) zpk_send(sndpkt)

npk_send(data)

zpk_send(sndpkt) npk_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt,0)

Czekaj na ACK

fragment AS nadawcy

Czekaj na wywołanie z dołu

npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data) deliver_data(data)

sndpkt = make_pkt(ACK1, chksum) npk_rcv(rcvpkt) &&

(corrupt(rcvpkt) ||

has_seq1(rcvpkt)) zpk_send(sndpkt)

fragment AS odbiorcy

numer=0 numer=0

numer=0

(23)

3- 45

npk3.0: kanał z błędami oraz stratami

Nowe założenie:

używany kanał może gubić pakiety (z danymi lub ACK)

suma kontrolna, numery sekwencyjne,

potwierdzenia, retransmisje będą pomocne, ale nie wystarczą

Podejście: nadawca czeka przez “rozsądny” czas na potwierdzenie ACK

retransmituje, jeśli nie otrzyma ACK w tym czasie

jeśli pakiet (lub ACK) jest tylko opóźniony, ale nie stracony:

retransmisja będzie duplikatem, ale za pomocą numerów sekwencyjnych już to obsługujemy

odbiorca musi określić numer sekwencyjny pakietu, który jest potwierdzany

wymagany jest licznik czasu

3- 46

npk3.0 nadawca

sndpkt = make_pkt(0, data, checksum) zpk_send(sndpkt)

start_timer npk_send(data)

Czekaj na ACK

npk_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

Czekaj na wywołanie

z góry

sndpkt = make_pkt(1, data, checksum) zpk_send(sndpkt)

start_timer npk_send(data)

npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt,0)

npk_rcv(rcvpkt)

&&

( corrupt(rcvpkt) ||

isACK(rcvpkt,0) ) npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt,1)

stop_timer stop_timer

zpk_send(sndpkt) start_timer timeout

zpk_send(sndpkt) start_timer timeout

npk_rcv(rcvpkt)

Czekaj na wywołanie

z góry

npk_rcv(rcvpkt)

numer=0 numer=0

numer=1 numer=1

Czekaj na ACK

(24)

3- 47

npk3.0 w działaniu

nadawca odbiorca

działanie bez strat

pkt0

pkt1

pkt0

ACK0

ACK1

ACK0

wyślij pkt0

odbierz pkt0

wyślij ACK0

odbierz ACK0

wyślij pkt1

odbierz ACK1

wyślij pkt0

odbierz pkt1

wyślij ACK1

odbierz pkt0

wyślij ACK0

nadawca odbiorca

działanie ze stratą pakietu

pkt0

pkt1

pkt0

ACK0

ACK1

ACK0

wyślij pkt0

odbierz pkt0

wyślij ACK0

odbierz ACK0

wyślij pkt1

odbierz ACK1

wyślij pkt0

odbierz pkt1

wyślij ACK1

odbierz pkt2

wyślij ACK0

pkt1

(strata) timeout, retransmituj

pkt1

3-

npk3.0 w działaniu

timeout, retransmituj pkt1

nadawca odbiorca

działanie ze stratą ACK

pkt0

pkt1

pkt2

ACK0

ACK1

ACK2

wyślij pkt0

odbierz pkt0

wyślij ACK0

odbierz ACK0

wyślij pkt1

odbierz ACK1

wyślij pkt2

odbierz pkt1

wyślij ACK1

odbierz pkt2

wyślij ACK2

pkt1

(strata)

ACK1 odbierz pkt1

wyślij ACK1

timeout, retransmituj pkt1

nadawca odbiorca

za wczesny timeout

pkt0

pkt1

pkt0 ACK0

ACK1

ACK0 wyślij pkt0

odbierz pkt0 wyślij ACK0

odbierz ACK0

wyślij pkt1

odbierz ACK1

wyślij pkt2

odbierz pkt1

wykryj duplikat wyślij ACK1

odbierz pkt0

wyślij ACK0

pkt1

ACK1

odbierz pkt1

wyślij ACK1

Nic się nie dzieje!

(25)

3- 49

Wydajność npk3.0

npk3.0 działa, ale wydajność ma bardzo kiepską

przykład: link 1 Gb/s, opóźnienie k-k 15 ms, pakiet 1KB:

T transmisji = 8kb/pkt

109 b/s = 8 mikros.

W nadawcy: wykorzystanie – procent czasu, w jakim nadawca nadaje

pakiet rozmiaru 1KB co 30 ms -> przepustowość 33kB/s przez łącze 1 Gb/s

protokół ogranicza wykorzystanie fizycznych zasobów łącza!

W nadawcy = .008

30.008 = 0.00027 microsec onds

L / R RTT + L / R = L (rozmiar pakietu w b)

R (przepustowość, b/s) =

3- 50

npk3.0: działanie wyślij i czekaj

pierwszy bit pakietu wysłany, t =0

nadawca odbiorca

RTT

ostatni bit pakietu wysłany, t = L / R

pierwszy bit odebrany ostatni bit odebrany, wyślij ACK

ACK odebrane, wyślij następny pakiet, t = RTT + L / R

W nadawcy = .008

30.008 = 0.00027 microsec onds

L / R RTT + L / R =

(26)

3- 51

Protokoły "wysyłające grupowo"

Wysyłanie grupowe: nadawca wysyła wiele pakietów bez czekania na potwierdzenie

trzeba zwiększyć zakres numerów sekwencyjnych

trzeba mieć bufor u nadawcy i/lub odbiorcy

Dwa podstawowe rodzaje protokołów wysyłania grupowego: wróć o N, selektywne powtarzanie

3-

Wysyłanie grupowe: zwiększone wykorzystanie

nadawca odbiorca

RTT

ACK odebrane, wyślij następny pakiet, t = RTT + L / R

ostatni bit 2giego pakietu odebrany, wyślij ACK

ostatni bit 3ciego pakietu odebrany, wyślij ACK

W nadawcy = .024

30.008 = 0.0008 microsecon ds

3 * L / R RTT + L / R =

Trzykrotnie zwiększone wykorzystanie!

pierwszy bit pakietu wysłany, t =0 ostatni bit pakietu

wysłany, t = L / R

pierwszy bit odebrany ostatni bit odebrany, wyślij ACK

(27)

3- 53

Wróć o N (WN)

Nadawca:

k bitów na numer sekwencyjny w nagłówku pakietu

wysyła “okno” co najwyżej N kolejnych, niepotwierdzonych pakietów

ACK(n): potwierdza wszystkie pakiety aż do (i łącznie z) pakietem o numerze sekwencyjnym n - “skumulowany ACK”

może otrzymywać duplikaty potwierdzeń (patrz odbiorca)

potrzebny jest zegar – jeden dla całego okna

timeout: retransmisja wszystkich niepotwierdzonych pakietów w oknie, czyli od pocz_okn do nast_num

rozmiar okna: N początek okna

(pocz_okn) następny numer sekwencyjny

(nast_num) już

potwierdzony

wysłany, nie potwierdzony

gotowy, nie wysłany

nie gotowy

3- 54

WN: rozszerzony AS nadawcy

Czekaj start_timer

zpk_send(sndpkt[pocz_okn]) zpk_send(sndpkt[pocz_okn+1])

zpk_send(sndpkt[nast_num-1]) timeout

npk_send(dane)

if (nast_num < pocz_okn+N) {

sndpkt[nast_num] = make_pkt(nast_num, dane, suma_kontr) zpk_send(sndpkt[nast_num])

if (pocz_okn == nast_num) start_timer nast_num++

} else refuse_data(dane)

pocz_okn = numer_ACK(rcvpkt) + 1 If (pocz_okn == nast_num)

stop_timer else start_timer npk_rcv(rcvpkt) &&

notcorrupt(rcvpkt) pocz_okn=1

nast_num=1

npk_rcv(rcvpkt) && corrupt(rcvpkt)

(28)

3- 55

WN: rozszerzony AS odbiorcy

tylko ACK: zawsze wysyła ACK dla ostatniego poprawnie odebranego pakietu spośród pakietów odebranych w kolejności

może generować zduplikowane ACK

trzeba pamiętać tylko expectedseqnum

pakiety nie w kolejności:

są wyrzucane -> nie ma buforowania u odbiorcy!

Wysyłane jest ponownie ACK z numerem sekwencyjnym ostatniego pakiety odebranego w kolejności

Czekaj zpk_send(sndpkt)

default

npk_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data) deliver_data(data)

sndpkt = make_pkt(expectedseqnum,ACK,chksum) zpk_send(sndpkt)

expectedseqnum++

expectedseqnum=1 sndpkt =

make_pkt(expectedseqnum,ACK,chksum)

3-

WN w działaniu N = 4

nadawca odbiorca

pkt0

ACK0

wyślij pkt0

odbierz pkt0

wyślij ACK0

odbierz ACK0

wyślij pkt4

pkt1

wyślij pkt1

pkt2 wyślij pkt2

(strata) odbierz pkt1

wyślij ACK1

pkt3

wyślij pkt3

czekaj

ACK1

odbierz pkt3 i odrzuć go!

wyślij ACK1 pkt4 odbierz pkt4

i odrzuć go!

wyślij ACK1

odbierz ACK1

wyślij pkt5 pkt5

odbierz pkt5 i odrzuć go!

wyślij ACK1

timeout pkt2 wyślij pkt2

wyślij pkt3

wyślij pkt4

wyślij pkt5

pkt2

pkt3

pkt4

pkt5

odbierz pkt2 wyślij ACK2

odbierz pkt3

wyślij ACK3 pierwsze

okno

przesuwanie okna po ACK

retransmisje

(29)

3- 57

Selektywne powtarzanie (SP)

odbiorca selektywnie potwierdza poprawnie odebrane pakiety

buforuje pakiety, gdy potrzeba, w celu uporządkowania przed przekazaniem warstwie wyższej

nadawca retransmituje tylko pakiety, dla których nie odebrał ACK

nadawca ma zegar dla każdego niepotwierdzonego, wysłanego pakietu.

okno nadawcy

N kolejnych numerów sekwencyjnych

określa, jakie pakiety mogą być wysłane bez potwierdzenia

3- 58

SP: okna nadawcy i odbiorcy

rozmiar okna: N

początek okna

(pocz_okna

)

następny numer sekwencyjny

(nast_num)

już

potwierdzony

wysłany, nie potwierdzony

gotowy, nie wysłany

nie używany

rozmiar okna: N

potwierdzony, w buforze

oczekiwany, nie otrzymany

gotowy do odebrania

nie używany nadawca

odbiorca

(30)

3- 59

SP: nadawca i odbiorca

dane od wyższej warstwy:

jeśli w oknie jest wolny numer sekwencyjny, wyślij pakiet timeout(n):

retransmituj pakiet n, ustaw ponownie zegar

ACK(n) pakietu w oknie:

zaznacz pakiet jako odebrany i wyłącz zegar

jeśli n jest początkiem okna, przesuń okno do następnego niepotwierdzonego pakietu

nadawca

pakiet n z okna

wyślij ACK(n)

nie w kolejności: do bufora

w kolejności: przekaż (także przekaż uporządkowane pakiety z

bufora), przesuń okno do następnego nieodebranego

pakietu

pakiet n z N pakietów przed oknem

potwierdź ACK(n) wszystkie inne pakiety:

ignoruj

odbiorca

3-60

SP w działaniu

0 1 2 3 4 5 6 7 8 9 wysłany pkt0

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9

(strata)

wysłany pkt1

wysłany pkt2

wysłany pkt3, pełne okno

odebr. ACK0, wysł. pkt4

odebr. ACK1, wysł. pkt5

odebr. ACK3, nic nie wysłane timeout, retransmisja pkt2

odebr. pkt0, przekazany, wysł. ACK0

odebr. pkt1, przekazany, wysł. ACK1

odebr. pkt3, buforowany, wysł. ACK3

odebr. pkt4, buforowany, wysł. ACK4

odebr. pkt5, buforowany, wysł. ACK5

odebr. pkt2, przekazane pkt2, pkt3, pkt4, pkt5,

wysł. ACK3

(31)

3- 62

Mapa wykładu

Usługi warstwy transportu

Multipleksacja i demultipleksacja

Transport

bezpołączeniowy: UDP

Zasady niezawodnej komunikacji danych

Transport połączeniowy:

TCP

struktura segmentu

niezawodna komunikacja

kontrola przepływu

zarządzanie połączeniem

Mechanizmy kontroli przeciążenia

Kontrola przeciążenia w TCP

3- 63

TCP: Przegląd

RFC: 793, 1122, 1323, 2018, 2581

komunikacja "full duplex":

dwukierunkowy przepływ danych na tym samym połączeniu

MRS: maksymalny rozmiar segmentu

połączeniowe:

inicjalizacja (wymiana komunikatów kontrolnych) połączenia przed

komunikacją danych

kontrola przepływu:

nadawca nie "zaleje"

odbiorcy

koniec-koniec:

jeden nadawca, jeden odbiorca

niezawodny, uporządkowany strumień bajtów:

nie ma “granic komunikatów”

wysyłający grupowo:

kontrola przeciążeń i przepływu TCP określają rozmiar okna

bufory u nadawcy i odbiorcy

gniazdo

bufor nadawcy TCP TCP

bufor odbiorcy gniazdo segment

aplikacja

pisze dane aplikacja

czyta dane

(32)

3- 64

Struktura segmentu TCP

port nadawcy # port odbiorcy # 32 bity

dane aplikacji (zmienna długość) numer sekwencyjny numer potwierdzenia

Okno odbiorcy Wsk. na pilne dane suma kontrolna

U A P R S F

dług.

nagł. nie używ.

Opcje (zmienna długość) URG: pilne dane

(zwykle nie używane) ACK: numer ACK

używane

PSH: wypchnij dane

RST, SYN, FIN:

zarządzanie połączeniem (polecenia nawiązania i zamknięcia)

ilość bajtów, jakie przyjmie

odbiorca licząc według bajtów danych (nie segmentów!)

Internetowa

suma kontrolna (jak w UDP)

3-

TCP: numery sekwencyjne i potwierdzenia

Numery sekwencyjne:

numer w "strumieniu bajtów" pierwszego bajtu danych segmentu

Potwierdzenia:

numer sekwencyjny następnego bajtu oczekiwanego od drugiej strony

kumulatywny ACK Pytanie: jak odbiorca traktuje

segmenty nie w kolejności

O: specyfikacja TCP tego nie określa: decyduje implementacja

Host A Host B

Użytkownik wpisuje

‘C’

host A potwierdza

odbiór

‘C’

otrzymanego od hosta B

Host B potwierdza

‘C’, wysyła z powrotem

‘C’

czas prosty scenariusz telnet

(33)

3- 66

TCP: czas powrotu (RTT) i timeout

Pytanie: jak ustalić timeout dla TCP?

dłuższe niż RTT

ale RTT jest zmienne

za krótki: za wczesny timeout

niepotrzebne retransmisje

za długi: wolna reakcja na stratę segmentu

Pytanie: jak estymować RTT?

MierzoneRTT: czas zmierzony od wysłania segmentu do odbioru ACK

ignorujemy retransmisje

MierzoneRTT będzie zmienne, chcemy mieć "gładsze"

estymowane RTT

średnia z wielu ostatnich pomiarów, nie tylko aktualnego MierzoneRTT

3- 67

EstymowaneRTT = (1- )*EstymowaneRTT + *MierzoneRTT

Wykładnicza średnia ruchoma

wpływ starych pomiarów maleje wykładniczo

typowa wartość parametru:  = 0.125

TCP: czas powrotu (RTT) i timeout

(34)

3- 68

Przykład estymacji RTT:

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100 150 200 250 300 350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT (milliseconds)

SampleRTT Estimated RTT

3-

Ustawianie timeout

EstymowaneRTT dodać “margines błędu”

im większa zmienność MierzoneRTT, tym większy margines błędu

najpierw ocenić, o ile MierzoneRTT jest oddalone od EstymowaneRTT:

Timeout = EstymowaneRTT + 4*BłądRTT BłądRTT = (1-)*BłądRTT +

*|MierzoneRTT - EstymowaneRTT|

(zwykle,  = 0.25) Ustalanie wielkości timeout:

TCP: czas powrotu (RTT) i timeout

(35)

3- 70

Mapa wykładu

Usługi warstwy transportu

Multipleksacja i demultipleksacja

Transport

bezpołączeniowy: UDP

Zasady niezawodnej komunikacji danych

Transport połączeniowy:

TCP

struktura segmentu

niezawodna komunikacja

kontrola przepływu

zarządzanie połączeniem

Mechanizmy kontroli przeciążenia

Kontrola przeciążenia w TCP

3- 71

Niezawodna komunikacja TCP

TCP tworzy usługę NPK na zawodnej

komunikacji IP

Wysyłanie grupowe segmentów

Kumulowane potwierdzenia

TCP używa

pojedynczego zegara do retransmisji

Retransmisje są powodowane przez:

zdarzenia timeout

duplikaty ACK

Na razie rozważymy prostszego nadawcę TCP:

ignoruje duplikaty ACK

ignoruje kontrolę przeciążenia i przepływu

(36)

3- 72

Zdarzenia nadawcy TCP:

Dane od aplikacji:

Utwórz segment z numerem sekwencyjnym

numer sekwencyjny to numer w strumieniu bajtów pierwszego bajtu danych segmentu

włącz zegar, jeśli jest wyłączony (zegar działa dla najstarszego niepotwierdzonego segmentu)

oblicz czas oczekiwania:

Timeout

Timeout:

retransmituj segment, który spowodował timeout

ponownie włącz zegar Odbiór ACK:

Jeśli potwierdza niepotwierdzone segmenty:

potwierdź odpowiednie segmenty

włącz zegar, jeśli są brakujące segmenty

3-

Nadawca TCP

(uproszczony)

Nast_Num = 1 Pocz_Okna = 1 loop (forever) {

switch( zdarzenie ) {

zdarzenie: Dane od aplikacji

stwórz segment z numerem Nast_Num;

if ( zegar wyłączony ) włącz zegar;

przekaż segment do warstwy IP;

Nast_Num = Nast_Num + length( dane );

zdarzenie: Timeout

retransmituje niepotwierdzony segment o najniższym numerze sekwencyjnym;

włącz zegar;

zdarzenie: Odbiór ACK potwierdzającego pakiet y if ( y > Pocz_Okna )

{

Pocz_Okna = y;

if ( są niepotwierdzone segmenty w oknie ) włącz zegar;

} }

} /* end of loop forever */

Komentarz:

• Pocz_Okna - 1: ostatni potwierdzony bajt Przykład:

Pocz_Okna

- 1 = 71;

y= 73, więc odbiorca chce bajty powyżej 73;

y > Pocz_Okna, więc nowe dane zostały potwierdzone

(37)

3- 74

TCP: scenariusze retransmisji

Host A

czas

za wczesny timeout

Host B

timeout numeru 92

Host A

strata

timeout

scenariusz ze stratą ACK

Host B

X

czas

timeout numeru 92

Pocz_Okna

= 100

Pocz_Okna

= 120

Pocz_Okna

= 120 Pocz_Okna

= 100

3- 75

TCP: scenariusze retransmisji (c.d.)

Host A

strata

timeout

Skumulowany ACK

Host B

X

czas

Pocz_Okna

= 120

(38)

3- 76

Wysyłanie ACK w TCP [RFC 1122, RFC 2581]

Zdarzenie u odbiorcy TCP

Odbiór segmentu o oczekiwanym numerze w kolejności. Wszystkie poprzednie dane już potwierdzone Odbiór segmentu o oczekiwanym numerze w kolejności. Jeden inny

segment nie był potwierdzony Odbiór segmentu nie w kolejności

o za wysokim numerze. Wykrycie luki w danych

Odbiór segmentu, który całkiem lub częściowo wypełnia lukę.

Akcja odbiorcy TCP

Opóźnione ACK. Czekaj do 500 ms na następny segment. Jeśli go nie ma,

wyślij ACK.

Wyślij natychmiast skumulowane ACK, potwierdzające oba segmenty.

Wyślij natychmiast duplikat ACK, w którym podany jest numer oczekiwanego bajtu

Jeśli segment leży na początku luki, wyślij natychmiast ACK.

3-77

Szybkie retransmisje

Okres oczekiwania na timeout jest długi:

długie czekanie na retransmisje

Rozpoznaj stracone segmenty przez duplikaty ACK.

Nadawca często wysyła segmenty jeden tuż po drugim

Jeśli segment zginie, może być wiele duplikatów ACK.

Jeśli nadawca otrzyma 3 duplikaty ACK dla tych samych danych, zakłada, że następny segment po

potwierdzonych danych zginął:

szybkie retransmisje:

wyślij segment zanim nastąpi timeout

(39)

3- 78

zdarzenie: Odbiór ACK potwierdzającego pakiet y if ( y > Pocz_Okna )

{

Pocz_Okna = y;

if ( są niepotwierdzone segmenty w oknie ) włącz zegar;

} else

{

zwiększ licznik duplikatów ACK dla y;

if ( licznik duplikatów ACK dla y == 3 ) retransmituj segment y;

}

Algorytm szybkich retransmisji:

duplikat ACK dla już

potwierdzonego segmentu szybka retransmisja

3- 79

Mapa wykładu

Usługi warstwy transportu

Multipleksacja i demultipleksacja

Transport

bezpołączeniowy: UDP

Zasady niezawodnej komunikacji danych

Transport połączeniowy:

TCP

struktura segmentu

niezawodna komunikacja

kontrola przepływu

zarządzanie połączeniem

Mechanizmy kontroli przeciążenia

Kontrola przeciążenia w

TCP

(40)

3- 80

Kontrola przepływu TCP

odbiorca TCP ma bufor odbiorcy:

usługa dopasowania prędkości: dopasuje prędkość wysyłania do prędkości odbioru danych przez aplikację

Dane od warstwy IP

Dane do warstwy aplikacji Wolne

miejsce

Dane TCP w buforze Okno

odbiorcy TCP

Bufor TCP

3-

Jak działa kontrola przepływu TCP

Załóżmy, że odbiorca wyrzuca segmenty nie w kolejności.

Odbiorca ogłasza wolne miejsce umieszczając jego wielkość w segmentach ACK

Odbiorca ogranicza rozmiar okna do wolnego miejsca

gwarantuje, że bufor nie zostanie przepełniony Dane od

warstwy IP

Dane do warstwy aplikacji Wolne

miejsce

Dane TCP w buforze Okno odbiorcy TCP

Bufor TCP

Figure

Updating...

References

Related subjects :