Warstwa transportu. Mapa wykładu

Transkrypt

1 Warstwa transportu 1 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 1

2 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 network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical 3 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 4 2

3 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 network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical 5 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 6 3

4 Multipleksacja/demultipleksacja Demultipleksacja u odbiorcy przekazywanie otrzymanych segmentów do właściwych gniazd Multipleksacja u nadawcy zbieranie danych z wielu gniazd, dodanie nagłówka (używanego później przy demultipleksacji) = gniazdo = proces aplikacji P3 P1 P1 aplikacji P2 P4 aplikacji transportu sieci łącza transportu sieci łącza transportu sieci łącza fizyczna fizyczna host 1 host 2 host 3 fizyczna 7 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 32 bity port nadawcy port odbiorcy inne pola nagłówka dane aplikacji (komunikat) format segmentu TCP/UDP 8 4

5 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 9 Demultipleksacja bezpołączeniowa (c.d.) DatagramSocket gniazdoserwera = new DatagramSocket(6428); P2 P3 P1 P1 PN: 6428 PO: 9157 PN: 6428 PO: 5775 PN: 9157 PN: 5775 klient IP: A PO: 6428 serwer IP: C PO: 6428 klient IP:B Port nadawcy (PN) jest adresem zwrotnym. 10 5

6 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 11 Demultipleksacja połączeniowa (c.d) P1 P4 P5 P6 P2 P1 P3 PN: 5775 PO: 80 IP-N: B IP-O: C PN: 9157 PN: 9157 klient IP: A PO: 80 IP-N: A IP-O: C serwer IP: C PO: 80 IP-N: B IP-O: C klient IP: B 12 6

7 Demultipleksacja połączeniowa i serwer wielowątkowy P1 P4 P2 P1 P3 PN: 5775 PO: 80 IP-N: B IP-O:C PN: 9157 PN: 9157 klient IP: A PO: 80 IP-N: A IP-O: C serwer IP: C PO: 80 IP-N: B IP-O: C klient IP: B 13 Porty komunikacyjne Numer przydzielony przez system: 0 po wywołaniu bind system wybiera numer portu (znaleźć go można po wywołaniu getsockname()) Porty zarezerwowane: Porty dobrze znane: (/etc/services) Porty zwyczajowo zarezerwowane dla Unixa BSD: Przydzielane przez rresvport: Porty wolne

8 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 15 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 16 8

9 Więcej o UDP Długość segmentu UDP w bajtach Często używane do (z nagłówkiem) 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 długość 32 bity Dane aplikacji (komunikat) port odbiorcy suma kontrolna Format segmentu UDP 17 Suma kontrolna UDP Cel: odkrycie błędów (n.p., odwróconych bitów) w przesłanym segmencie 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. 18 9

10 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 zawinięcie suma suma kontrolna na chwilę wracamy do Warstwy aplikacji 20 10

11 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 21 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 punkt widzenia programisty UDP udostępnia zawodną komunikację ciągów bajtów ( datagramów ) pomiędzy klientem i serwerem UDP: wysyłane informacje mogą być gubione lub otrzymywane w innym porządku 22 11

12 sendpacket receivepacket infromuser Interakcja klient/serwer: UDP Serwer (działa na hostid) Klient tworzy gniazdo, port=x, dla nadchodzących połączeń : serversocket = DatagramSocket(x) czyta komunikat z serversocket tworzy gniazdo, clientsocket = DatagramSocket() Tworzy, adresuje (hostid, port=x), wysyła datagram z komunikatem przez clientsocket wysyła odpowiedź serversocket podając adres i port klienta czyta odpowiedź z clientsocket zamyka clientsocket 23 Przykład: Klient w Javie (UDP) klawiatura monitor Proces klienta Wyjście: wysyła pakiet (przez TCP, wysyłał strumień bajtów ) strumien wejsciowy pakiet UDP pakiet UDP Wejście: odbiera pakiet (przez TCP odbierał strumień bajtów ) gniazdo clientsocket UDP klienta gniazdo UDP do sieci z sieci 24 12

13 Przykład: klient w Javie (UDP) Tworzy strumień wejściowy Tworzy gniazdo klienta Tłumaczy nazwę na adres IP używając DNS 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(); 25 Przykład: klient w Javie (UDP), c.d. Tworzy datagram z danymi do wysłania, długością, adresem IP, portem Wysyła datagram do serwera Czyta datagram z serwera } 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(); } 26 13

14 Przykład: serwer w Javie (UDP) import java.io.*; import java.net.*; Tworzy gniazdo UDP na porcie 9876 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]; Tworzy miejsce na otrzymany datagram Odbiera datagram while(true) { DatagramPacket receivepacket = new DatagramPacket(receiveData, receivedata.length); serversocket.receive(receivepacket); 27 Przykład: serwer w Javie (UDP), c.d. Pobiera adres IP, numer portu, nadawcy pakietu String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivepacket.getaddress(); int port = receivepacket.getport(); String capitalizedsentence = sentence.touppercase(); Tworzy datagram do wysłania do klienta Wysyła datagram przez gniazdo } } senddata = capitalizedsentence.getbytes(); DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, port); serversocket.send(sendpacket); } Koniec pętli "while", powrót i oczekiwanie na następny datagram 28 14

15 wracamy do Warstwy transportu 29 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 30 15

16 Zasady niezawodnej komunikacji danych Ważne w warstwie aplikacji, transportu i łącza Jeden z najważniejszych tematów w dziedzinie sieci! warstwa wyższa Proces nadawcy dane Proces odbiorcy dane warstwa niezawodna kanał niezawodny npk_send() dane deliver_data() dane Niezawodny protokół transportowy (nadawca) zpk_send() pakiet Niezawodny protokół transportowy (odbiorca) npk_recv() pakiet warstwa niższa a) udostępniana usługa kanał zawodny b) implementacja usługi charakterystyka zawodnego kanału określa złożoność niezawodnego protokołu komunikacji (npk) 31 Niezawodna komunikacja (npk) 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 npk_send dane dane deliver_data warstwa niezawodna Niezawodny protokół transportowy (nadawca) Niezawodny protokół transportowy (odbiorca) zpk_send pakiet pakiet npk_recv warstwa niższa nadawca zpk_send(): wywoływany przez npk. Wysyła pakiet przez zawodny kanał do odbiorcy kanał zawodny odbiorca npk_rcv(): wywoływany przez niższą warstwę, gdy pakiet zostanie odebrany po stronie odbiorcy 32 16

17 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 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 stan 1 zdarzenie (lub brak: ) czynności (lub brak: ) stan 2 33 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 npk_send(data) packet = make_pkt(data) zpk_send(packet) Czekaj na wywołanie z dołu npk_rcv(packet) extract (packet,data) deliver_data(data) nadawca odbiorca 34 17

18 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 35 npk2.0: specyfikacja AS npk_send(data) snkpkt = make_pkt(data, checksum) zpk_send(sndpkt) Czekaj na wywołanie z góry npk_rcv(rcvpkt) && isack(rcvpkt) nadawca Czekaj na ACK lub NAK npk_rcv(rcvpkt) && isnak(rcvpkt) zpk_send(sndpkt ) odbiorca npk_rcv(rcvpkt) && corrupt(rcvpkt) zpk_send(nak) Czekaj na wywołanie z dołu npk_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) zpk_send(ack) 36 18

19 npk2.0: działanie bez błędów npk_send(data) snkpkt = make_pkt(data, checksum) zpk_send(sndpkt) Czekaj na wywołanie z góry npk_rcv(rcvpkt) && isack(rcvpkt) Czekaj na ACK lub NAK npk_rcv(rcvpkt) && isnak(rcvpkt) zpk_send(sndpkt ) npk_rcv(rcvpkt) && corrupt(rcvpkt) zpk_send(nak) Czekaj na wywołanie z dołu npk_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) zpk_send(ack) 37 npk2.0: działanie z błędami npk_send(data) snkpkt = make_pkt(data, checksum) zpk_send(sndpkt) Czekaj na wywołanie z góry npk_rcv(rcvpkt) && isack(rcvpkt) Czekaj na ACK lub NAK npk_rcv(rcvpkt) && isnak(rcvpkt) zpk_send(sndpkt ) npk_rcv(rcvpkt) && corrupt(rcvpkt) zpk_send(nak) Czekaj na wywołanie z dołu npk_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) zpk_send(ack) 38 19

20 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 wstrzymaj i czekaj Nadawca wysyła jeden pakiet, potem czeka na odpowiedź odbiorcy 39 npk2.1: nadawca, obsługuje błędne ACK/NAK npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) zpk_send(sndpkt) sndpkt = make_pkt(0, data, checksum) zpk_send(sndpkt) Czekaj na wywołanie z góry numer=0 Czekaj na ACK lub NAK numer=1 npk_send(data) Czekaj na ACK lub NAK numer=0 Czekaj na wywołanie z góry numer=1 npk_send(data) sndpkt = make_pkt(1, data, checksum) zpk_send(sndpkt) npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) zpk_send(sndpkt) npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) 40 20

21 npk2.1: odbiorca, obsługuje błędne ACK/NAK npk_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) zpk_send(sndpkt) npk_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) 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) Czekaj na wyw. z dołu numer=0 Czekaj na wyw. z dołu numer=1 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) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) zpk_send(sndpkt) npk_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) zpk_send(sndpkt) 41 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ę 42 21

22 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 43 npk2.2: fragmenty nadawcy, odbiorcy npk_rcv(rcvpkt) && (corrupt(rcvpkt) has_seq1(rcvpkt)) zpk_send(sndpkt) npk_send(data) sndpkt = make_pkt(0, data, checksum) zpk_send(sndpkt) Czekaj na wywołanie z góry numer=0 Czekaj na wywołanie z dołu fragment AS nadawcy fragment AS odbiorcy Czekaj na ACK numer=0 numer=0 npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack1, chksum) zpk_send(sndpkt) npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) zpk_send(sndpkt) npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) 44 22

23 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 45 npk3.0 nadawca npk_rcv(rcvpkt) npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout zpk_send(sndpkt) start_timer npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) ) Czekaj na wywołanie z góry numer=0 Czekaj na ACK numer=1 npk_send(data) sndpkt = make_pkt(0, data, checksum) zpk_send(sndpkt) start_timer npk_send(data) Czekaj na ACK numer=0 Czekaj na wywołanie z góry numer=1 sndpkt = make_pkt(1, data, checksum) zpk_send(sndpkt) start_timer npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) timeout zpk_send(sndpkt) start_timer npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer npk_rcv(rcvpkt) 46 23

24 npk3.0 w działaniu nadawca odbiorca nadawca odbiorca pkt 0 wyślij pkt 0 odbierz pkt 0 wyślij pkt 0 pkt 0 odbierz pkt 0 odbierz ACK 0 wyślij pkt 1 ACK 0 pkt 1 wyślij ACK 0 odbierz ACK 0 wyślij pkt 1 ACK 0 pkt 1 (strata) wyślij ACK 0 ACK 1 odbierz pkt 1 wyślij ACK 1 timeout, retransmituj odbierz ACK 1 wyślij pkt 0 pkt 0 ACK 0 odbierz pkt 0 wyślij ACK 0 pkt 1 odbierz ACK 1 wyślij pkt 0 pkt 1 ACK 1 pkt 0 odbierz pkt 1 wyślij ACK 1 ACK 0 odbierz pkt 2 wyślij ACK 0 działanie bez strat działanie ze stratą pakietu 47 npk3.0 w działaniu nadawca odbiorca nadawca odbiorca wyślij pkt 0 pkt 0 odbierz pkt 0 wyślij pkt 0 pkt 0 odbierz pkt 0 odbierz ACK 0 wyślij pkt 1 ACK 0 timeout, retransmituj (strata) pkt 1 pkt 1 odbierz ACK 1 wyślij pkt 2 pkt 1 ACK 1 pkt 2 ACK 2 działanie ze stratą ACK wyślij ACK 0 ACK 1 odbierz pkt 1 wyślij ACK 1 odbierz pkt 1 wyślij ACK 1 odbierz pkt 2 wyślij ACK 2 odbierz ACK 0 wyślij pkt 1 ACK 0 timeout, retransmituj pkt 1 ACK 1 odbierz ACK 1 wyślij pkt 2 ACK 1 ACK 0 pkt 1 pkt 1 pkt 0 wyślij ACK 0 odbierz pkt 1 wyślij ACK 1 Nic się nie za wczesny timeout dzieje! odbierz pkt 1 wykryj duplikat wyślij ACK 1 odbierz pkt 0 wyślij ACK

25 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 = L (rozmiar pakietu w b) R (przepustowość, b/s) = 8kb/pkt 10 9 b/s = 8 mikros. W nadawcy = L / R RTT + L / R = = microsec 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! 49 npk3.0: działanie wyślij i czekaj pierwszy bit pakietu wysłany, t =0 ostatni bit pakietu wysłany, t = L / R nadawca odbiorca RTT pierwszy bit odebrany ostatni bit odebrany, wyślij ACK ACK odebrane, wyślij następny pakiet, t = RTT + L / R W nadawcy = L / R RTT + L / R = = microsec 50 25

26 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 51 Wysyłanie grupowe: zwiększone wykorzystanie nadawca pierwszy bit pakietu wysłany, t =0 ostatni bit pakietu wysłany, t = L / R odbiorca RTT ACK odebrane, wyślij następny pakiet, t = RTT + L / R pierwszy bit odebrany ostatni bit odebrany, wyślij ACK ostatni bit 2giego pakietu odebrany, wyślij ACK ostatni bit 3ciego pakietu odebrany, wyślij ACK W nadawcy = 3 * L / R RTT + L / R = Trzykrotnie zwiększone wykorzystanie! = microsecon 52 26

27 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 początek okna (pocz_okn) następny numer sekwencyjny (nast_num) już potwierdzony gotowy, nie wysłany wysłany, nie potwierdzony nie gotowy rozmiar okna: N 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 53 WN: rozszerzony AS nadawcy pocz_okn=1 nast_num=1 npk_rcv(rcvpkt) && corrupt(rcvpkt) 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) Czekaj npk_rcv(rcvpkt) && notcorrupt(rcvpkt) timeout start_timer zpk_send(sndpkt[pocz_okn]) zpk_send(sndpkt[pocz_okn+1]) zpk_send(sndpkt[nast_num-1]) pocz_okn = numer_ack(rcvpkt) + 1 If (pocz_okn == nast_num) stop_timer else start_timer 54 27

28 WN: rozszerzony AS odbiorcy default zpk_send(sndpkt) expectedseqnum=1 Czekaj sndpkt = make_pkt(expectedseqnum,ack,chksum) npk_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ack,chksum) zpk_send(sndpkt) expectedseqnum++ 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 55 WN w działaniu N = 4 pierwsze okno przesuwanie okna po ACK nadawca odbierz ACK 0 wyślij pkt 4 ACK 0 odbiorca wyślij pkt 0 pkt 0 wyślij pkt 1 pkt 1 odbierz pkt 0 wyślij ACK 0 wyślij pkt 2 pkt 2 odbierz pkt 1 wyślij ACK (strata) 1 wyślij pkt pkt 3 3 czekaj odbierz ACK 1 ACK 1 pkt 4 odbierz pkt 3 i odrzuć go! wyślij ACK 1 odbierz pkt4 i odrzuć go! wyślij ACK 1 retransmisje timeout pkt 2 wyślij pkt 2 wyślij pkt 3 wyślij pkt 4 wyślij pkt 5 pkt 2 pkt 3 pkt 4 pkt 5 wyślij pkt 5 pkt 5 odbierz pkt5 i odrzuć go! wyślij ACK 1 odbierz pkt 2 wyślij ACK 2 odbierz pkt 3 wyślij ACK

29 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 57 SP: okna nadawcy i odbiorcy początek okna (pocz_okna ) następny numer sekwencyjny (nast_num) nadawca już potwierdzony gotowy, nie wysłany rozmiar okna: N rozmiar okna: N odbiorca wysłany, nie potwierdzony potwierdzony, w buforze oczekiwany, nie otrzymany nie używany gotowy do odebrania nie używany 58 29

30 SP: nadawca i odbiorca nadawca 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 odbiorca 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 59 SP w działaniu wysłany pkt wysłany pkt wysłany pkt wysłany pkt3, pełne okno odebr. ACK0, wysł. pkt odebr. ACK1, wysł. pkt timeout, retransmisja pkt odebr. ACK3, nic nie wysłane (strata) odebr. pkt0, przekazany, wysł. ACK odebr. pkt1, przekazany, wysł. ACK odebr. pkt3, buforowany, wysł. ACK odebr. pkt4, buforowany, wysł. ACK odebr. pkt5, buforowany, wysł. ACK odebr. pkt2, przekazane pkt2, pkt3, pkt4, pkt5, wysł. ACK

31 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 62 TCP: Przegląd RFC: 793, 1122, 1323, 2018, 2581 gniazdo 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 aplikacja pisze dane TCP bufor nadawcy segment aplikacja czyta dane TCP bufor odbiorcy 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 gniazdo 63 31

32 Struktura segmentu TCP 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) Internetowa suma kontrolna (jak w UDP) 32 bity port nadawcy # port odbiorcy # dług. nagł. nie używ. numer sekwencyjny numer potwierdzenia U A P R S F suma kontrolna Okno odbiorcy Wsk. na pilne dane Opcje (zmienna długość) dane aplikacji (zmienna długość) licząc według bajtów danych (nie segmentów!) ilość bajtów, jakie przyjmie odbiorca 64 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 Użytkownik wpisuje C Host A host A potwierdza odbiór C otrzymanego od hosta B Host B prosty scenariusz telnet Host B potwierdza C, wysyła z powrotem C czas 65 32

33 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 66 TCP: czas powrotu (RTT) i timeout EstymowaneRTT = (1- )*EstymowaneRTT + *MierzoneRTT Wykładnicza średnia ruchoma wpływ starych pomiarów maleje wykładniczo typowa wartość parametru: =

34 RTT (milliseconds) Przykład estymacji RTT: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr time (seconnds) SampleRTT Estimated RTT 68 TCP: czas powrotu (RTT) i timeout 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: Ustalanie wielkości timeout: BłądRTT = (1- )*BłądRTT + * MierzoneRTT - EstymowaneRTT (zwykle, = 0.25) Timeout = EstymowaneRTT + 4*BłądRTT 69 34

35 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 70 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 71 35

36 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 72 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 */ Nadawca TCP (uproszczony) 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 73 36

37 timeout timeout numeru 92 timeout timeout numeru 92 TCP: scenariusze retransmisji Host A Host B Host A Host B X strata Pocz_Okna = 100 Pocz_Okna = 120 Pocz_Okna = 100 czas scenariusz ze stratą ACK Pocz_Okna = 120 czas za wczesny timeout 74 TCP: scenariusze retransmisji (c.d.) Host A Host B X strata Pocz_Okna = 120 czas Skumulowany ACK 75 37

38 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 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 Odbiór segmentu, który całkiem lub częściowo wypełnia lukę. Jeśli segment leży na początku luki, wyślij natychmiast ACK. 76 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 77 38

39 Algorytm szybkich retransmisji: 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; } duplikat ACK dla już potwierdzonego segmentu szybka retransmisja 78 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 79 39

40 Kontrola przepływu TCP odbiorca TCP ma bufor odbiorcy: Okno odbiorcy TCP Dane od warstwy IP Wolne miejsce Dane TCP w buforze Dane do warstwy aplikacji Bufor TCP usługa dopasowania prędkości: dopasuje prędkość wysyłania do prędkości odbioru danych przez aplikację 80 Jak działa kontrola przepływu TCP Okno odbiorcy TCP Dane od warstwy IP Wolne miejsce Dane TCP w buforze Dane do warstwy aplikacji Bufor 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 81 40

41 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 82 Zarządzanie połączeniem TCP Przypomnienie: Nadawca i odbiorca TCP, tworzą połączenie zanim wymienią dane inicjalizacja zmiennych TCP: numery sekwencyjne bufory, informacja kontroli przepływu (rozmiar bufora) klient: nawiązuje połączenie Socket clientsocket = new Socket("hostname","port number"); serwer: odbiera połączenie Socket connectionsocket = welcomesocket.accept(); Trzykrotny uścisk dłoni: Krok 1: host klienta wysyła segment SYN do serwera podaje początkowy numer sekwencyjny bez danych Krok 2: host serwera odbiera SYN, odpowiada segmentem SYNACK serwer alokuje bufory określa początkowy numer Krok 3: klient odbiera SYNACK, odpowiada segmentem ACK, który może zawierać dane 83 41

42 timeout timeout Zarządzanie połączeniem TCP (c.d..) Zamykanie połączenia: klient zamyka gniazdo: clientsocket.close(); Krok 1: Host klienta wysyła segment TCP FIN do serwera zamnknij gniazdo klient serwer zamknij gniazdo Krok 2: serwer odbiera FIN, odpowiada segmentem ACK. Zamyka połączenie, wysyła FIN. połączenie zamknięte połączenie zamknięte 84 Zarządzanie połączeniem TCP (c.d.) Krok 3: klient odbiera FIN, odpowiada segmentem ACK. Rozpoczyna oczekiwaniebędzie odpowiadał ACK na otrzymane FIN. Krok 4: serwer odbiera ACK. Połączenie zamknięte. zamknij gniazdo klient serwer zamknij gniazdo Uwaga: z małymi zmianami, obsługuje jednoczesne FIN. połączenie zamknięte połączenie zamknięte 85 42

43 Zarządzanie połączeniem TCP (c.d..) minęło 30s ZAMKNIĘTE aplikacja klienta otwiera połączenie wyślij SYN CZEKAJ odebrano FIN wyślij ACK FIN-CZEKAJ 2 odebrano ACK Cykl życia klienta TCP FIN-CZEKAJ 1 WYSŁANY SYN odebrano SYN-ACK wyślij ACK POŁĄCZONY aplikacja klienta zamyka połączenie wyślij FIN odebrano ACK ZAMKNIĘTE Cykl życia serwera TCP aplikacja serwera tworzy gniazdo czekające wyślij FIN Odebrano FIN wyślij ACK OSTATNI ACK ZAMKNIJ CZEKAJ POŁĄCZONY SŁUCHANIE odebrano SYN wyślij SYN-ACK ODEBRANY SYN odebrano ACK 86 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 87 43

44 opóźnienie Zasady kontroli przeciążenia Przeciążenie: nieformalnie: za wiele źródeł wysyła za wiele danych za szybko, żeby sieć mogła je obsłużyć różni się od kontroli przepływu! objawy przeciążenia: zgubione pakiety (przepełnienie buforów w ruterach) duże (i zmienne) opóźnienia (kolejkowanie w buforach ruterów) jeden z głównych problemów sieci! konsekwencja braku kontroli dostępu do sieci 88 Przyczyny/koszty przeciążenia: scenariusz 1 dwóch nadawców, dwóch odbiorców jeden ruter, nieskończone bufory bez retransmisji Host B Host A l in : orginalne dane nieskończony bufor łącza wyjściowego l out duże opóźnienia przy przeciążeniu maksymalna dostępna przepustowość 89 44

45 Przyczyny/koszty przeciążenia: scenariusz 2 jeden ruter, skończone bufory retransmisje straconych pakietów Host B Host A l in : oryginalne dane l' in : oryginalne dane plus retransmisje skończone, współdzielone bufory łącza wyjściowego l out 90 Przyczyny/koszty przeciążenia: scenariusz 2 zawsze: (goodput) doskonałe retransmisje tylko po stracie: retransmisje opóźnionych (nie straconych) pakietów zwiększa l (w porównaniu z doskonałymi) dla tego samego goodput l in out 91 45

46 Przyczyny/koszty przeciążenia: scenariusz 3 czterech nadawców dłuższe ścieżki timeout/retransmisje l in Host A l in : oryginalne dane l' in : oryginalne dane plus retransmisje skończone, współdzielone bufory łącza wyjściowego l out Host B 92 Przyczyny/koszty przeciążenia: scenariusz 3 H os t A l o u t H os t B 93 46

47 Metody kontroli przeciążenia Dwa rodzaje metod kontroli przeciążenia: Kontrola przeciążenia typu koniec-koniec: brak bezpośredniej informacji zwrotnej od warstwy sieci przeciążenie jest obserwowane na podstawie strat i opóźnień w systemach końcowych tą metodą posługuje się TCP Kontrola przeciążenia z pomocą sieci: rutery udostępniają informację zwrotną systemom końcowym pojedynczy bit wskazuje na przeciążenie (SNA, DECbit, TCP/IP ECN, ATM) podawana jest dokładna prędkość, z jaką system końcowy powinien wysyłać 94 Studium przypadku: kontrola przeciążeń w usłudze ABR sieci ATM ABR: available bit rate: usługa elastyczna jeśli ścieżka nadawcy jest niedociążona : nadawca powinien używać dostępną przepustowość jeśli ścieżka nadawcy jest przeciążona: nadawca jest ograniczany do minimalnej gwarantowanej przepustowości Komórki RM (resource management): wysyłane przez nadawcę, przeplatane z komórkami danych bity w komórce RM ustawiane przez przełączniki sieci ( z pomocą sieci ) bit NI: nie zwiększaj szybkości (lekkie przeciążenie) bit CI: wskazuje na przeciążenie komórki RM zwracane są do nadawcy przez odbiorcę bez zmian 95 47

48 Studium przypadku: kontrola przeciążeń w usłudze ABR sieci ATM nadawca komórki RM komórki danych odbiorca dwubajtowe pole ER (explicit rate) w komórce RM przeciążony switch może zmniejszyć wartość ER w komórce z tego powodu, nadawca ma minimalną dostępną przepustowość na ścieżce bit EFCI w komórkach danych: ustawiany na 1 przez przeciążony switch jeśli komórka danych poprzedzająca komórkę RM ma ustawiony bit EFCI, odbiorca ustawia bit CI w zwróconej komórce RM 96 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 97 48

49 Kontrola przeciążenia w TCP metoda koniec-koniec (bez pomocy sieci) nadawca ogranicza prędkość transmisji: OstatniWysłanyBajt- OstatniPotwierdzonyBajt RozmiarOkna Z grubsza, RozmiarOkna jest zmienny, funkcja obserwowanego przeciążenia sieci Jak nadawca obserwuje przeciążenie? strata = timeout lub 3 zduplikowane ACK nadawca TCP zmniejsza prędkość (RozmiarOkna) po stracie trzy mechanizmy: AIMD powolny start konserwatywne po zdarzeniu timeout 98 Mechanizm AIMD w TCP multiplikatywne zmniejszanie: dziel RozmiarOkna przez dwa po stracie 24 Kb rozmiar okna przeciazenia addytywne zwiększanie: dodawaj 1 do RozmiarOkna jeżeli nie było stratyzmiar segmentu po każdym RTT bez straty: badanie sieci 16 Kb 8 Kb czas Długotrwałe połączenie TCP 99 49

50 RTT Powolny start TCP Po nawiązaniu połączenia, RozmiarOkna = 1 segment Przykład: Segment = 500 b oraz RTT = 200 ms początkowa prędkość = 2.5 kb/s dostępna przepustowość >> rozmiarsegmentu/rtt pożądane jest szybkie przyśpieszenie komunikacji 10 Powolny start TCP (c.d.) Po nawiązaniu połączenia, zwiększaj prędkość wykładniczo do pierwszej straty: podwajaj RozmiarOkna co RTT osiągane przez zwiększanie RozmiarOkna po otrzymaniu ACK Podsumowanie: początkowo, prędkość jest mała, ale szybko przyśpiesza Host A Host B czas 10 50

51 Rozmiar Okna Udoskonalenie powolnego startu Po 3 zduplikowanych ACK: RozmiarOkna dzielimy przez dwa okno zwiększane liniowo Ale: po zdarzeniu timeout: RozmiarOkna ustawiany na 1 segment; okno z początku zwiększane wykładniczo do pewnej wielkości, potem zwiększane liniowo 10 Udoskonalenia (c.d.) Pytanie: Kiedy przestać zwiększać okno wykładniczo, a zacząć zwiększać liniowo? Odpowiedź: Gdy RozmiarOkna osiągnie połowę swojej wartości z przed zdarzenia timeout. Próg Implementacja: Zmienny Próg Czas mierzony w RTT Próg Po stracie, Próg jest ustalany na 1/2 wartości RozmiarOkna tuż przed stratą 10 51

52 Podsumowanie: kontrola przeciążenia TCP Gdy RozmiarOkna poniżej wartości Próg, nadawca w stanie powolnego startu, okno rośnie wykładniczo. Gdy RozmiarOkna powyżej wartości Próg, nadawca w stanie unikania przeciążenia, okno rośnie liniowo. Po trzech zduplikowanych ACK, Próg = RozmiarOkna/2 oraz RozmiarOkna = Próg. Po zdarzeniu timeout, Próg = RozmiarOkna/2 oraz RozmiarOkna = 1 segment. 10 Podsumowanie: kontrola przeciążenia TCP Zdarzenie Stan Akcja nadawcy TCP Komentarz Odebranie ACK za niepotwierdzone dane Odebranie ACK za niepotwierdzone dane Strata zaobserwowana przez 3 zduplikowane ACK Powolny Start (PS) Unikanie Przeciążenia (UP) RozmiarOkna = RozmiarOkna + 1 segment, If (RozmiarOkna > Próg) stan = Unikanie Przeciążenia RozmiarOkna = RozmiarOkna + (1 segment / RozmiarOkna) PS lub UP Próg = RozmiarOkna / 2, RozmiarOkna = Próg, Stan = Unikanie Przeciążenia Timeout PS lub UP Próg = RozmiarOkna/2, RozmiarOkna = 1 segment, Stan = Powolny Start Zduplikowany ACK PS lub UP Zwiększ licznik ACK dla potwierdzonego segmentu Po upływie RTT, RozmiarOkna się podwaja Liniowy wzrost RozmiarOkna o 1 segment po upływie RTT Szybka poprawa przez multiplikatywne zmniejszanie. RozmiarOkna nie będzie mniejszy niż 1 segment. Wchodzimy w Powolny Start RozmiarOkna ani Próg nie zmieniają się

53 Podsumowanie warstwy transportu mechanizmy usług warstwy transportu: multipleksacja, demultipleksacja niezawodna komunikacja kontrola przepływu kontrola przeciążenia w Internecie: UDP TCP Co dalej: opuszczamy brzeg sieci (warstwy aplikacji i transportu) wchodzimy w szkielet sieci 10 Przepustowość TCP Jaka jest średnia przepustowość TCP jako funkcja rozmiaru okna oraz RTT? Ignorujemy powolny start Niech W będzie rozmiarem okna w chwili straty. Gdy okno ma rozmiar W, przepustowość jest W/RTT Zaraz po stracie, okno zmniejszane do W/2, przepustowość jest W/2RTT. Średnia przepustowość: ¾ W/RTT 10 53

54 Przyszłość TCP Przykład: segment 1500 bajtów, RTT 100ms, chcemy przepustowość 10 Gb/s Potrzeba rozmiaru okna W = segmentów Przepustowość jako funkcja częstości strat L: 1.22 segment RTT L L = Bardzo wyśrubowana! Potrzeba nowych wersji TCP dla bardzo szybkich sieci! 10 Sprawiedliwość TCP Sprawiedliwy cel: jeśli K połączeń TCP dzieli to samo łącze o przepustowości R będące wąskim gardłem, każde połączenie powinno mieć średnią przepustowość R/K Połączenie TCP 1 Połączenie TCP 2 ruter będący wąskim gardłem: przepustowość R 10 54

55 Dlaczego TCP jest sprawiedliwe? Dwa konkurujące połączenia: addytywne zwiększanie daje nachylenie 1, gdy rośnie przepustowość multiplikatywne zmniejszanie zmniejsza przepustowość proporcjonalnie R równe udziały przepustowości strata: zmniejsz okno dwukrotnie unikanie przeciążenia: liniowy wzrost R Przepustowość połączenia 1 11 Więcej o sprawiedliwości Sprawiedliwość i UDP Komunikacja strumieniowa nie używa TCP nie chce zmieniać prędkości nadawania zgodnie z kontrolą przeciążeń W zamian używa UDP: śle audio/wideo ze stałą prędkością, toleruje straty pakietów Obszar badań: Komunikacja strumieniowa "TCP friendly" Sprawiedliwość i równoległe połączenia TCP nic nie powstrzyma aplikacji przed nawiązaniem równoległych połączeń pomiędzy 2 hostami. Robią tak przeglądarki WWW Przykład: łącze o przepustowości R obsługuje 9 połączeń; nowa aplikacja prosi o 1 połączenie TCP, dostaje przepustowość R/10 nowa aplikacja prosi o 11 połączeń TCP, dostaje przepustowość R/2!