A szállítói réteg (transport layer) szolgáltatásai Kapcsolat nélküli vagy kapcsolat orientált (connectionless/connection oriented) Gondoljunk az ISO/OSI ülés rétegére Megbízható vagy nem megbízható (reliable/unreliable) „Best effort” vagy „Quality of Service” Hibafelügyelet Torlódás felügyelet (congestion control) vagy torlódás felügyelet nélkül Lehetőség több végpontra egy végrendszeren (host) Demultiplexálás Több interakciós modell támogatása Byte-áram, üzenetek, „Remote Procedure Call“
Számítógépes Hálózatok 2013 10. Szállítói réteg – TCP, Tahoe, Reno, AIMD, hatékonyság, fairness
Hálózatok, 2013
1
Lukovszki Tamás
Multiplexálás a szállítói rétegben
2
Lukovszki Tamás
Szállítói réteg (transport layer)
A hálózati réteg az adatokat kontroll nélkül továbbítja a szállítói rétegnek A szállítói rétegnek az adatokat különböző felhasználásokhoz kell hozzárendelni: pl. Web, Mail, FTP, ssh, ... TCP/UDP ezt port-szám alapján teszi pl. port 80 a Web-szerverhez
Hálózatok, 2013
Hálózatok, 2013
TCP (transmission control protocol) Megbízható adatfolyamot hoz létre két végpont között A felhasználói réteg adatáramát csomagokra osztja A másik oldal a csomagok fogadásától nyugtákat küld (Acknowledgment) UDP (user datagram protocol) Egyszerű nem megbízható szolgáltatás csomagok küldésére Az inputot egy datagrammá alakítja A felhasználói réteg határozza meg a csomag méretét A csomagokat a hálózati réteg által küldi Routing nincs: végpont-végpont protokollok
3
Lukovszki Tamás
Hálózatok, 2013
4
Lukovszki Tamás
Adatok burkolása
TCP-fejléc (I) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
„Checksum“ Fejléchez és adatokhoz Fejléchossz (data offset) A változó hosszúságú opciómező miatt
Hálózatok, 2013
5
TCP-Fejléc (II) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opció-mező pl. MSS (maximum segement size): A fogadó megadja a kívánt csomagméretet Tekintet nélkül az IP MTU-ra (max. transmission unit) Fragmentálás lehetséges az IP által Hálózatok, 2013
7
Lukovszki Tamás
FLAGS (függetlenül felhasználhatók) URG: sürgős (urgent) ACK: nyugta (acknowledgment) Aktiviálja a nyugta számot PSH: Push Gyors adattovábbítás a felhasználói rétegnek RST: Reset A válasz hiba esetén: connection reset by peer SYN:Synchronize Kapcsolatfelépítés és a kezdő sorszám megadása FIN: Finished
Hálózatok, 2013
Küldő-Port + Cél-Port-Nr. Megenged több TCPkapcsolatot IP-címenként Sorszám Minden adatbyte meg van számozva modulo 232 = a szegmens első bytejának a száma Nyugta szám Az ACK-Flag által aktivivált Az első még nem feldolgozott adatbyte száma = utolsó sorozatszám + utolsó adatmennyiség
6
Lukovszki Tamás
TCP (I) TCP (Transmission Control Protocol) egy kapcsolatorientált megbízható szolgáltatás bidirekcionális byte-folyamokhoz TCP Kapcsolatorientált Két résztvevő. Egy egy résztvevő socket által azonosított: socket: IP-cím és port TCP-kapcsolat egyértelműen azonosított egy socketpár által Nincs broadcast sem multicast Kapcsolatfelépítés és lezárás szükséges Amíg egy kapcsolat nincs (rendesen) lezárva, addig aktív
(Egy) adatfolyam befejezése
Lukovszki Tamás
Hálózatok, 2013
8
Lukovszki Tamás
TCP (II)
TCP (III)
TCP egy kapcsolatorientált megbízható szolgáltatás bidirekcionális bytefolyamokhoz
TCP egy kapcsolatorientált megbízható szolgáltatás bidirekcionális bytefolyamokhoz
TCP megbízható
TCP egy szolgáltatás bidirekcionális byte-folyamokhoz
Minden adatcsomag megérkezését nyugtázza (acknowledgment) A nem nyugtázott adatcsomagokat újraküldi “Checksum” a fejléchez és csomaghoz TCP számozza a csomagokat és sorbarendezi a fogadónál Törli a duplikált csomagokat
Hálózatok, 2013
9
Lukovszki Tamás
Kapcsolatfelépítés
Hálózatok, 2013
10
Lukovszki Tamás
Kapcsolat lezárása
SYN: seq.nr.: j
server
Fogadó
Küldő
Félig lezárás (half-close) A küldő jelzi a kapcsolat befejezését egy FINszegmensben és vár annak nyugtájára Az ellenkező irányban továbbra is lehet küldeni
Rendszerint Client-Server-kapcsolat Ekkor felépítés 3 TCP-csomaggal (=3 szegmens) Az első SYN-szegmensben az MSS (maximum segment size) is átvitelre kerül client
Az adatok két egymással ellentétes irányú byte-sorozatként (=8 bit) kerülnek átvitelre A tartalom nem interpretálódik Az adatcsomagok időbeli viselkedése megváltozhat: átvitel sebessége növekedhet, csökkenhet, más késés, más sorrendben is megérkezhetnek Megpróbálja az adatcsomagokat időben egymáshoz közel kiszállítani Megpróbálja az átviteli közeget hatékonyan használni = kevés csomag
FIN: seq.nr.: m ACK: ack.nr.: m+1
B
A FIN: seq.nr.: m
SYN: seq.nr.: k
Két félig lezárás lezárja a TCPkapcsolatot
ACK: ack.nr.: j+1
ACK: ack.nr.: m+1 FIN: seq.nr.: n
ACK: ack.nr.: k+1 ACK: ack.nr.: n+1
Hálózatok, 2013
11
Lukovszki Tamás
Hálózatok, 2013
12
Lukovszki Tamás
Nyugták (acknowledgement -- ACK)
TCP állapot átmeneti diagramm (Start)
CLOSED Connect/SYN
„Hello!“ Seq.nr. 17
Hátizsák technika „piggybacking“ A nyugták (ACK) az ellenkező irány adatszegmensein „utaznak“
Listen/„bla bla“ Seq.nr. 91 ACK: 17+6=23
„Ez“ Seq.nr. 154
(Step 1 of the 3-way handshake)
LISTEN
Send/SYN RST/SYN/SYN + ACK
SYN_RCVD
Egy nyugta több adatszegmenst is nyugtázhat Ha nincs küldeni való adat, késleteti az ACK-kat
Close/-
SYN/SYN + ACK (Step 2 of the 3-way handshake)
„World“ Seq.nr. 23 ACK: 91+7=98
Close/-
SYN_SENT
SYN + ACK/ACK (Step 2 of the 3-way handshake) ESTABLISHED (Passive close)
ACK/-
„lesz“ Seq.nr. 156 „az“ Seq.nr. 160
Close/FIN (Active close)
ACK: 162
Close/FIN
FIN/ACK
FIN_WAIT_1 ACK/FIN_WAIT_2
CLOSE_WAIT AC
FIN/ACK K
+
FI N
FIN/ACK
/A C
Close/FIN CLOSING
K
LAST_ACK
ACK/(Timeout/) TIME_WAIT
ACK/ACK CLOSED (Go back to start)
Hálózatok, 2013
13
Lukovszki Tamás
Exponenciális visszavétel (exponential backoff)
Hálózatok, 2013
15
ACK: 17+6=23
? „World“ Seq.nr. 23
?
4s
„World“ Seq.nr. 23
?
Fogadó
2s
1s
„World“ Seq.nr. 23
„World“ Seq.nr. 23
8s
14
Lukovszki Tamás
A Round Trip Time (RTT) becslése
„Hello!“ Seq.nr. 17
Küldő
Retransmission Timout (RTO) szabályozza az időközt a küldés és egy duplikátum újraküldése között, ha egy nyugta kimarad Mikor nem kerül nyugtázásra egy TCP-csomag? Ha a nyugta lényegesen több időt vesz igénybe, mint az átlagos „round trip time” (RTT) 1. Probléma: RTT mérése 2. Probléma: Csak a nyugta jön túl későn Küldő Vár az RTO-nak megfelő ideig Ha nem érkezett nyugta, újraküldi a csomagot és növeli RTO ← 2 RTO (RTO = 64 másodpercig) RTO újraszámolása, ha a csomagok nyugtázódnak
Hálózatok, 2013
?
„World“ Seq.nr. 23
Lukovszki Tamás
A TCP-csomag nem nyugtázottnak számít, ha a nyugta „lényegesen” tovább tart, mint az RTO RTT nem számítható on-line (csak visszatekintve) RTT erősen ingadozik Ezért: Retransmission Timeout Value nagyvonalú becsléssel: RFC 793: (M := utoljára mért RTT) R ← α R + (1- α) M, ahol α = 0,9 RTO ← β R, ahol β = 2 Jacobson 88: a becslés nem elég robosztus, ezért A ← A + g (M - A) , ahol g = 1/8 D ← D + h (|M - A| - D) , ahol h = 1/4 RTO ← A + 4D Többszörösen elküldött csomagoknál nem aktualizálunk Hálózatok, 2013
16
Lukovszki Tamás
TCP – Nagle algoritmusa
Csúszó Ablakok (sliding windows)
Hogyan biztosíthatjuk, hogy kis csomagok időben egymáshoz közel kerüljenek kiszállításra és hogy sok adat esetén nagy csomagok előnyben részesüljenek? Nagle algoritmusa: Kis csomagok nem kerülnek addig küldésre, amig nyugták hiányoznak egy csomag kicsi, ha az adathossz < MSS Ha a korábban küldött csomag nyugtája megérkezik, küldi a következőt Tulajdonsága Önmagát ütemező: Gyors kapcsolat = sok kis csomag
Adatátráta szabályozása ablak segítségével A fogadó meghatározza az ablak méretet (wnd) az ACK-szegmensek TCP-fejlécében Ha a fogadó fogadási puffere tele van, akkor wnd=0 -t küld Máskülönben a fogadó wnd>0 -t küld A küldőnek be kell tartani: Az elküldött nem nyugtázott adatcsomagok száma ≤ ablak mérete A fogadó által megadott ablak méret
1
2
3
4
5
6
7
8
9
Még elküldhető
Elküldött és nyugtázott
Elküldött és nem nyugtázott Hálózatok, 2013
17
Lukovszki Tamás
Lassú Start (slow start)
Hálózatok, 2013
10
Csak akkor küldhető, ha az ablak mérete megváltozik
18
Lukovszki Tamás
Torlódás elkerülés (congestion avoidance) TCP Tahoe ACK: szegmens 1
Jacobson 88: Paraméter: cwnd és ssthresh (= slow-start-küszöb, slow start threshold)
szegmens 2 szegmens 3 ACK: szegmens 3
szegmens 4 szegmens 5 szegmens 6 szegmens 7
1. Kapcsolatfelépítés:
Fogadó
Küldő
A küldőnek nem szabad a fogadó által felajánlott ablakméretet azonnal kihasználni Második ablak: Congestion-ablak (cwnd: congestion window) A küldő választja Az ablak amiben küld: min {wnd,cwnd} Kezdetben: cwnd ← MSS Minden csomagnál a megkapott nyugta után nő cwnd ← cwnd + MSS (azaz megduplázódik minden RTT után) Addig, amíg egyszer egy nyugta kimarad
szegmens 1
cwnd ← MSS
2. Csomagvesztésnél, azaz nyugta ideje > RTO: multiplicatively decreasing cwnd ← MSS
ssthresh ←
ACK: szegmens 5
3. Nyugta jön a szegmenshez és cwnd ≤ ssthresh: slow start
ACK: szegmens 7
cwnd ← cwnd + MSS
szegmens 8 szegmens 9 szegmens 10
4. Nyugta jön a szegmenshez és cwnd > ssthresh: additively increasing
…
Slow start = exponenciális növekedés
ssthresh ← 65535
cwnd ← cwnd + MSS
(hisztórikus elnevezés: korábban még aggresszívebb sémák) Hálózatok, 2013
19
Lukovszki Tamás
Hálózatok, 2013
20
Lukovszki Tamás
TCP Tahoe
Fast Retransmit és Fast Recovery TCP Tahoe [Jacobson 1988]: Ha csak egy csomag veszik el, akkor a csomagot újraküldi + a fennmaradó ablakot és egyidejűleg slow start Fast retransmit ha ugyanazon csomaghoz 3 nyugta-duplikátum (azaz 4 azonos nyugta) érkezik (triple duplicate ACK), újraküldi az elveszet csomagot, egyidejűleg slow start TCP Reno [Stevens 1994] Fast retransmit után: ssthresh ← max( min(wnd,cwnd)/2, 2 MSS ) cwnd ← ssthresh + 3 MMS Fast recovery a fast retransmit után Miden további nyugta után növeli a rátát: cwnd ← cwnd + MMS Congestion avoidance: amikor új adat nyugtája megérkezik (ujraküldés ACK-ja) : cwnd ← ssthresh
Hálózatok, 2013
21
Lukovszki Tamás
Torlódás elkerülési elv: AIMD
Hálózatok, 2013
22
Lukovszki Tamás
Példa: TCP Reno „in aktion”
A TCP a „fast recovery” mechanizmussal lényegében a következőképp viselkedik: x: csomagok száma per RTT
Fast Retransmit
Fast Recovery
Kapcsolatfelépítés: x←1
Csomagvesztésnél, MD: multiplicative decreasing x ← x/2
Nyugtázott szegmenseknél, AD: additive increasing
Additively Increase
x ← x +1
Hálózatok, 2013
23
Slow Start Lukovszki Tamás
Hálózatok, 2013
Multiplicatively Decrease 24
Lukovszki Tamás
Additive Increase Multiplicative Decrease (AIMD): Fairness és Hatékonyság Knie
Könyök
Klippe
Billenő
A hálózati terhelés az átvitellel és a válasziővel kölcsönösen hat egymásra. Az átvitel maximális, ha a terhelés a hálózat kapacitását majdnem eléri.
Átvitel
Durchsatz
Ha a terhelés tovább nő, túlcsordulnak a pufferek, csomagok vesznek el, újra kell küldeni, drasztikusan nő a válaszidő. Ezt a toródást congestion-nak nevezzük.
Last Terhelés
Ezért a maximális terhelés helyett, ajánlatos a hálózat terhelését a könyök közelében beállítani. Itt a válaszidő csak lassan emelkedik, míg az adatátvitel már a maximum közelében van.
Válaszidő
Egy jó torlódáselkerülési (congestion avoidance) stratégia a hálózat terkelését a könyök közlében tartja: hatékonyság. Emellett fontos, hogy minden résztvevőt egyforma rátával szolgáljunk ki: fairness.
Anwortzeit
Terhelés Last Hálózatok, 2013
25
Lukovszki Tamás
