Szállítási réteg3-1 3. Fejezet Szállítási réteg Computer Networking: A Top Down Approach 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007.

Az előadások a következő témára: "Szállítási réteg3-1 3. Fejezet Szállítási réteg Computer Networking: A Top Down Approach 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007."— Előadás másolata:

1 Szállítási réteg3-1 3. Fejezet Szállítási réteg Computer Networking: A Top Down Approach 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007. A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:  If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)  If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright 1996-2007 J.F Kurose and K.W. Ross, All Rights Reserved

2 Szállítási réteg3-2 3. Fejezet: Szállítási réteg Célunk: r megérteni a szállítási réteg szolgáltatásainak alapjait: m Multiplexelés – demultiplexelés m megbízható adatszállítás m áramlás-ellenőrzés m zsúfoltság-ellenőrzés r tanuljunk az internetes szállítási rétegről: m UDP: összeköttetés-mentes szállítás m TCP: összeköttetés alapú szállítás m TCP zsúfoltság-ellenőrzés

3 Szállítási réteg3-3 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

4 Szállítási réteg3-4 Szállítási szolgáltatások és protokollok application transport network data link physical application transport network data link physical logikai száll. végpontok között r logikai kommunikáció biztosítása különböző hoszton futó alk. folyamatok között r szállítási protokollok végrendszereken futnak m küldő oldal: az alk. üzeneteket szegmensekre osztja és átadja a hálózati rétegnek m fogadó oldal: üzenetekké rakja össze a szegmenseket, átadja az alk. rétegnek r Több szállítási protokoll áll az alkalmazások rendelkezésére m Internet: TCP és UDP

5 Szállítási réteg3-5 A szállítási és a hálózati réteg r hálózati réteg: logikai kommunikáció hosztok között r szállítási réteg: logikai kommunikáció folyamatok között m a hálózati réteg szolgáltatásaira alapul, kiegészíti ezeket Háztartás analógia: 12 gyermek küld levelet 12 gyermeknek r folyamatok = gyerekek r alk. üzenetek = a levelek borítékokban r hosztok = házak r szállítási protokoll = Ann és Bill r hálózati-réteg protokoll = postahivatal

6 Szállítási réteg3-6 Internetes szállításiréteg protokollok 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 network data link physical application transport network data link physical logikai száll. végpontok között r megbízható, sorrendben küld (TCP) m zsúfoltságellenőrzés m áramlásvezérlés m kapcsolat beállítása r megbízhatatlan, nem garantál sorrendet: UDP r nincsenek: m késési garanciák m sávszélesség garanciák

7 Szállítási réteg3-7 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

8 Szállítási réteg3-8 Multiplexelés/demultiplexelés alkalmazás szállítás hálózat kapcsolat fizikai P1 alkalmazás szállítás hálózat kapcsolat fizikai alkalmazás szállítás hálózat kapcsolat fizikai P2 P3 P4 P1 hoszt 1 hoszt 2 hoszt 3 = folyamat= socket a fogadott szegmenseket a megfelelő a socketnek küldi Demultiplexelés a fogadó hoszton: összegyűjti az adatokat a socketektől, fejlécet fűz hozzájuk a demultiplexeléshez szükséges információval Multiplexelés a küldő hoszton:

9 Szállítási réteg3-9 Hogy működik a demultiplexelés r a hoszt megkapja az IP datagramokat m minden datagramban megvan a forrás és a cél IP címe m minden datagram egy szállításiréteg szegmenst tartalmaz m minden szegmensben megvan a forrás és a cél portszáma (specifikus alkalmazásoknak jól meghatározott port- számai vannak) r a hoszt az IP cím és a port száma segítségével irányítja a szegmenst a megfelelő sockethez forrás port #cél port # 32 bit adat (üzenet) más fejléc mezők TCP/UDP szegmens formátuma

10 Szállítási réteg3-10 Összeköttetésmentes demultiplexelés r socketek létrehozása port számmal : DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); r egy UDP socket-et egy ( cél IP cím, cél port szám) pár azonosít r UDP szegmens fogadásakor a hoszt: m ellenőrzi a port számát m az UDP szegmenst a megfelelő portszámmal rendelkező sockethez irányítja r olyan IP datagramok, melyeknek különböző a forrás IP címük és/vagy port számuk, ugyanarra a socketre irányíthatóak

11 Szállítási réteg3-11 Összeköttetésmentes demultiplexelés (folyt.) DatagramSocket serverSocket = new DatagramSocket(6428); kliens IP:B P3 kliens IP: A P1 P3 szerver IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 SP: 6428 DP: 5775 SP: 5775 DP: 6428 SP a „visszatérési címet” adja meg

12 Szállítási réteg3-12 Összeköttetés-alapú demultiplex r TCP socket azonosítása: m forrás IP cím m forrás port szám m cél IP cím m cél port szám r a fogadó hoszt felhasználja mind a négy értéket ahhoz, hogy a megfelelő sockethez irányítsa a szegmenst r a szerver hoszt egyszerre több TCP socketet is létrehozhat: m minden socket az előbbi 4 adattal azonosítható r a webszerverek minden kliensnek különböző socketet hoznak létre m nem-perszisztens HTTP minden kérésre más socketet használ

13 Szállítási réteg3-13 Összeköttetés-alapú demultiplex (folyt.) kliens IP:B P1 kliens IP: A P1 P2 P4 szerver IP: C SP: 9157 DP: 80 SP: 9157 DP: 80 P5 P6 P3 D-IP:C S-IP: A D-IP:C S-IP: B SP: 5775 DP: 80 D-IP:C S-IP: B

14 Szállítási réteg3-14 Összeköttetés-alapú demultiplex: szálak használata kliens IP:B P1 kliens IP: A P1 P2 szerver IP: C SP: 9157 DP: 80 SP: 9157 DP: 80 P4 P3 D-IP:C S-IP: A D-IP:C S-IP: B SP: 5775 DP: 80 D-IP:C S-IP: B

15 Szállítási réteg3-15 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

16 Szállítási réteg3-16 UDP: User Datagram Protocol [RFC 768] r egyszerű internet szállítási protokoll r a „legjobb teljesítmény” érdekében az UDP szegmensek: m elveszlődhetnek m soronkívül érkezhetnek az alkalmazáshoz r összeköttetés-mentes: m nincs kézfogás az UDP küldő és fogadó között m mindegyik UDP szegmenst a többitől függetlenül kezeli Miért létezik UDP? r nincs kapcsolat-termetés (ami késést okozhat) r egyszerű: nincs kapcsolat állapot a küldőnél vagy fogadónál r kicsi a szegmens fejléce r nincs zsúfoltság-ellenőrzés (az UDP tetszőleges tempóban közvetíthet)

17 Szállítási réteg3-17 UDP bővebben r gyakran használják multimedia-streaming alkalmazásoknál m adatvesztés toleráns m sebességre érzékeny r más alkalmazások m DNS m SNMP r megbízható átvitel UDP-n keresztül: az alk. réteg kell megoldja m alkalmazás-specifikus hibajavítás! forrás port #cél port # 32 bit Adat (üzenet) UDP szegmens formátuma hossz checksum UDP szegmens hossza a fejléccel együtt, byte-ban

18 Szállítási réteg3-18 UDP checksum Küldő: r a szegmens tartalmát 16- bites egészekként kezeli r checksum: a szegmens tartalma 1-es komplemens összegének (inverz kód) 1-es komplemense r a checksum éréket a küldő az UDP checksum mezőbe helyezi Fogadó: r kiszámítja a fogadott szegmens checksum-ját r ellenőrzi, hogy a kiszámított checksum megegyezik-e a checksum mező értékével: m NEM - hiba m IGEN – nem érzékel hibát. Lehetnek mégis hibák? Bővebben később…. Cél: „hibák” felfedezése (pl. bit hibák) a szegmensben

19 Szállítási réteg3-19 Internet „checksum” példa r megjegyzés m 1-es komplemens (inverzkód) összeadásnál az átvitel bitet hozzá kell adni az eredményhez m előny – nem kell különbséget tenni „little endian” és „big endian” ábrázolásmód között m részletek: http://www.netfor2.com/udpsum.htm r példa: két 16 bites egész inverzkódú összeadása és checksum 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 kifutó bit összeg checksum

20 Szállítási réteg3-20 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

21 Szállítási réteg3-21 A megbízható adatszállítás alapjai r fontos alkalmazásokban, szállításoknál, kapcsolati rétegekben r 10 legfontosabb hálózati téma között! r a megbízhatatlan csatorna jellemzői meghatározzák a megbízható adatszállítási protokoll komplexitását (rdt)

22 Szállítási réteg3-22 A megbízható adatszállítás alapjai r fontos alkalmazásokban, szállításoknál, kapcsolati rétegekben r 10 legfontosabb hálózati téma között! r a megbízhatatlan csatorna jellemzői meghatározzák a megbízható adatszállítási protokoll komplexitását (rdt)

23 Szállítási réteg3-23 A megbízható adatszállítás alapjai r fontos alkalmazásokban, szállításoknál, kapcsolati rétegekben r 10 legfontosabb hálózati téma között! r a megbízhatatlan csatorna jellemzői meghatározzák a megbízható adatszállítási protokoll komplexitását (rdt)

24 Szállítási réteg3-24 Megbízható adatszállítás: küldő oldal fogadó oldal rdt_send(): (pl., alk. hívja meg). A fogadó felső rétegéhez küldi az adatot udt_send(): az rdt hívja meg, a csomagot a fogadóhoz küldi át, a megbízhatalan csatornán rdt_rcv(): egy csomag érkezése hívja meg deliver_data(): az rdt hívja meg, adatot továbbít a felsőbb rétegnek

25 Szállítási réteg3-25 Megbízható adatszállítás: A továbbiakban: r lépésenként dolgozunk ki egy megbízható adatátviteli protokollt a küldő és a fogadó fél számára (rdt) r csak az egyirányú adatszállítást vesszük figyelembe m az információcsere kétirányú r véges automatákat (VA) (Finite State Machine) használunk a küldő/fogadó meghatározására 1. áll. 2. áll. esemény, ami kiváltja az állapotváltást állapotváltáshoz kapcsolt tevékenység állapot: a következő esemény egyértelműen meghatározza a következő állapotot esemény tevékenység

26 Szállítási réteg3-26 Rdt1.0: megbízható adatszállítás megbízható csatornán keresztül r az átviteli csatorna teljesen megbízható m nincsenek bithibák m nincs csomagvesztés r külön VA a küldő és fogadó számára: m a küldő az átviteli csatornába küldi az adatot m a fogadó, az adatot az átviteli csatornából olvassa ki Hívásra várakozás fenteről packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Hívásra várakozás lentről rdt_rcv(packet) küldő fogadó

27 Szállítási réteg3-27 Rdt2.0: bit-hibás csatorna r az átviteli csatorna felcserélhet a csomagban biteket m az UDP checksum felfedezi a hibákat r kérdés: hogy javíthatjuk ki a hibákat? m nyugták (acknowledgements - ACKs): a fogadó szól a küldőnek, hogy a csomag hibátlanul megérkezett m negatív nyugták (NAKs): a fogadó szól a küldőnek, hogy a csomag hibásan érkezett m NAK érkezése esetén a küldő újraküldi a csomagot  új mechanizmusok az rdt2.0-ban : m hibák detektálása m a fogadó válaszol: ellenőrzési üzenetek (ACK,NAK) fogadó -> küldő

28 Szállítási réteg3-28 rdt2.0: VA specifikáció Hívásra vár fentről snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) ACK-t v. NAK-t vár Hívásra vár lentről küldő fogadó rdt_send(data) 

29 Szállítási réteg3-29 rdt2.0: hibamentes forgatókönyv Hívásra vár fentről snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) ACK-t v. NAK-t vár Hívásra vár lentről rdt_send(data) 

30 Szállítási réteg3-30 rdt2.0: hiba forgatókönyv Hívásra vár fentről snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) ACK-t v. NAK-t vár Hívásra vár lentről rdt_send(data) 

31 Szállítási réteg3-31 rdt2.0 –ben végzetes hiba! Mi történik, ha az ACK/NAK hibás? r A küldő nem tudja, hogy mi történt a fogadónál! r nem küldheti újra: fellép a másolat veszélye Másolatok kezelése: r a küldő hozzáad egy szekvencia számot (sequence number) minden csomaghoz r a küldő újraküldi a csomagot, ha az ACK/NAK hibás r a fogadó nem küldi tovább a másolatot a küldő csomagot küld, és várja a fogadó válaszát állj és várj

32 Szállítási réteg3-32 rdt2.1: küldő, kezeli a hibás ACK/NAK-t Várja a 0 hívást fentről sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) Várja az ACK v. NAK 0-át udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Várja az 1 hívást fentről Várja az ACK v. NAK 1-et  

33 Szállítási réteg3-33 rdt2.1: fogadó, kezeli a hibás ACK/NAK-t Várja a 0-t lentről sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Várja az 1-et lentről rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)

34 Szállítási réteg3-34 rdt2.1: elemzés Küldő: r hozzáad szekv #-ot a csomaghoz r Két szekv. # (0,1) elegendő. Miért? r Ellenőrzi, hogy az ACK/NAK hibás vagy nem r kétszer annyi állapot m az állapot kell megjegyezze, hogy az aktuális csomagnak 0 vagy 1 a szekv. #-a Fogadó: r kell ellenőrizze, hogy a csomagnak van már másolata vagy nem m az állapot adja meg, hogy 0 vagy 1 a várt csomag szekv. # r megjegyzés: a fogadó nem tudhatja hogy az utoljára küldött ACK/NAK-ja megérkezett vagy nem a küldőhöz

35 Szállítási réteg3-35 rdt2.2: NAK-nélküli protokoll r ugyanaz a funkciója, mint az rdt2.1-nek, de csak ACK-okat használ r NAK helyett a fogadó ACK-t küld az utoljára fogadott csomagra m a fogadó belefoglalja a csomag szekv #-át az ACK-ba r dupla ACK-nak a küldőnél ugyanaz a hatása, mint a NAK-nak: újraküldi a csomagot

36 Szállítási réteg3-36 rdt2.2: küldő, fogadó részek Várja a 0-t fentről sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) Várja az ACK 0-t küldő FSM rész Várja a 0-t lentről rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt) fogadó FSM rész 

37 Szállítási réteg3-37 rdt3.0: hibás és adatvesztéses csatornák Új feltételezés: az átviteli csatornák el is veszíthetnek csomagokat (adat vagy ACK) m checksum, szekv. #, ACK, újraküldések segítenek, de nem elegendőek Megközelítés: a küldő „elfogadható” ideig vár az ACK-ra r újraküld, ha ez idő alatt nem érkezett ACK r ha a csomag (vagy ACK) csak késik (nem veszett el): m másolatot küld, de a szekv # bevezetése megoldja ezt a problémát m a fogadó meg kell adja a nyugtázott csomag szekv # -át r szükség van visszaszámláló timer-re

38 Szállítási réteg3-38 rdt3.0 küldő sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) várja az ACK 0-t rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) Várja az 1-est fentről sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer udt_send(sndpkt) start_timer timeout udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) várja a 0-t fentről várja az ACK 1- et  rdt_rcv(rcvpkt)   

39 Szállítási réteg3-39 rdt3.0 működése

40 Szállítási réteg3-40 rdt3.0 működése

41 Szállítási réteg3-41 Az rdt3.0 hatásfoka r rdt3.0 működik, de gyenge a hatásfoka r pl: 1 Gbps-os kapcsolat, 15 ms késés, 1KB csomag: T küldési = 8kb/pkt 10**9 b/s = 8  s/pkt m U küldő : használat – idő, amikor a küldő foglalt m 1KB csomag minden 30 ms -> 33kB/s –os átvitel 1 Gbps kapcsolaton m a hálózati protokoll akadályozza a fizikai erőforrások kihasználását! L (csomag hossza bit-ben) R (sávszélesség, bps) =

42 Szállítási réteg3-42 rdt3.0: állj-és-várj művelet csom. első bitje elküldve, t = 0 küldőfogadó RTT csom. utolsó bitje elküldve, t = L / R csom. első bit megérkezik csom. utolsó bit megérkezik, ACK küldés ACK megérkezik, köv. csomag küldése, t = RTT + L / R

43 Szállítási réteg3-43 Csővezetékes protokollok Csővezeték: engedélyezi több, „utazó”, még- igazolandó csomag küldését m a szekvenciaszámok intervallumát növelni kell m pufferezés a küldőnél és/vagy a fogadónál r Csővezetékes protokollok: go-Back-N, szelektív ismétlés

44 Szállítási réteg3-44 Csővezeték: jobb kihasználás csom. első bitje elküldve, t = 0 küldőfogadó RTT utolsó bit elküldve, t = L / R első bit megérkezik utolsó bit megérkezik, ACK küldése ACK megérkezik, következő csomag küldése, t = RTT + L / R 2. csomag utolsó bitje megérkezik, ACK 3. csomag megérkezik, ACK 3x jobb kihasználás!

45 Szállítási réteg3-45 Go-Back-N Küldő: r k-bites szekv # a csomag fejlécében r „ablak”: max N egymást követő még nem igazolt csomag küldése engedélyezett r ACK(n): bizonyos szekv #-ig, az összes csomagot igazolja - „kumulatív ACK” r timer minden csomag számára r timeout(n): újraküldi az n-edik csomagot és az összes magasabb szekv #-ú csomagot az ablakból

46 Szállítási réteg3-46 GBN: küldő kibővített VA Vár start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) timeout rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt) 

47 Szállítási réteg3-47 GBN: fogadó kibővített VA csak-ACK: a legnagyobb szekv #-ú, hibátlanul fogadott, sorrendben érkezett csomagot nyugtázza m létrejöhetnek dupla ACK-ok  csak az expectedseqnum -ot kell megjegyezni r soron kívül érkező csomag: m nem tárolja -> nincs fogadó puffer! m a legnagyobb szekv #-ú csomagot újra nyugtázza Vár udt_send(sndpkt) default rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) 

48 Szállítási réteg3-48 GBN működése

49 Szállítási réteg3-49 Szelektív ismétlés (Selective Repeat ) r a fogadó külön igazol minden hibátlanul fogadott csomagot m szükség esetén tárolja a csomagokat (puffer), későbbi sorrendhelyes továbbítás a felső réteghez r a küldő csak azokat a csomagokat küldi újra, melyekre nem kapot ACK-t m küldő timer minden egyes nem nyugtázott csomaghoz r küldő ablak m N egymásután következő szekv # m korlátozza a már elküldött de még nem nyugtázott csomagok számát

50 Szállítási réteg3-50 Szelektív ism.: küldő, fogadó ablakok

51 Szállítási réteg3-51 Szelektív ismétlés fentről kapott adatok: r ha a következő rendelkezésre álló szekv # az ablakban van, a csomagot elküldi timeout(n): r újraküldi az n-edik csomagot, timer újraindítása ACK(n) [küldőalap,küldőalap+N]-ben: r fogadottnak jegyzi meg az n- edik csomagot r ha n a legkisebb még nem nyugtázott csomag, átállítja az ablak alapját a köv. nem nyugtázott szekv #-ra küldő n-edik csomag [fogadóalap, fogadóalap+N-1]-ben r elküldi ACK(n) r soron kívüli: puffer r sorrendben: továbbküldi, átállítja az ablakot a köv. még nem fogadott csomagra n-edik csomag [fogadóalap- N,fogadóalap-1]-ben r ACK(n) különben: r nem veszi tudomásul fogadó

52 Szállítási réteg3-52 Szelektív ismétlés működése

53 Szállítási réteg3-53 Szelektív ismétlés dilémmája Pl: r szekv #-ok: 0, 1, 2, 3 r ablak nagysága=3 r a fogadó nem lát különbséget a két forgatókönyv között! r a másolatot új adatként menti el K: mi az összefüggés a szekv # nagysága és az ablak mérete között?

54 Szállítási réteg3-54 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

55 Szállítási réteg3-55 TCP: áttekintés RFC-k: 793, 1122, 1323, 2018, 2581 r full duplex adat: m kétirányú adatáramlás ugyanazon a kapcsolaton m MSS: maximális szegmens méret r összeköttetés alapú: m kézfogás (vezérlő- üzenet váltás), küldő és fogadó állapotának inicializálása az adatcsere előtt r áramlásvezérelt: m a küldő nem terheli túl a fogadót r pontok közötti: m egy küldő, egy fogadó r megbízható, sorrendhelyes byte stream : m nincs „üzenet határ” r csővezetékes: m a TCP zsúfoltság és áramlás ellenőrzés szabályozza az ablak méretét r küldő & fogadó pufferek

56 Szállítási réteg3-56 TCP szegmens szerkezete forrás port # címzés port # 32 bit adat (vált. hossz.) szekv szám igazolási szám Fogadó ablak Urg adat pointer checksum F SR PAU fejléc hossz üres Opciók (vált. hossz.) URG: sürgös adat (ált. nem használt) ACK: ACK # érvényes PSH: push adatot (ált. nem használt) RST, SYN, FIN: kapcsolat létreh. (beállítás, parancsok) hány byte-ot akar fogadni adat byte- okban számolva (nem szegmensek!) Internet checksum (mint az UDP esetében)

57 Szállítási réteg3-57 TCP szekv. #-ok és ACK-k Szekv. #-ok: m A szegmens első byte-jának a száma ACK: m A másik oldalról várt byte szekv #-a m kumulatív ACK K: hogyan kezeli a fogadó a soron kívüli szegmenseket? m V: a TCP spec nem írja elő, az implementálótól függ A Hoszt B Hoszt Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 Felh. típus ‘C’ host ACKs receipt of echoed ‘C’ hoszt ACKs receipt of ‘C’, echoes back ‘C’ time egyszerű telnet példa

58 Szállítási réteg3-58 TCP Round Trip Time (Oda-vissza idő) és Timeout (megszakítási idő) K: hogy állítsuk be a TCP megszakítási idejét? r Nagyobbra, mint az RTT m viszont az RTT változik r túl kicsi: idő előtti megszakítás m szükségtelen újraküldések r túl nagy: lassan reagál a szegmensvesztésre K: RTT becslése?  SampleRTT : mért az idő a szegmens küldésétől a nyugta érkezéséig m nem veszi tudomásul az újraküldéseket  SampleRTT változni fog, nagy ingadozások, finomabb becslés szükséges  több mérésből kell átlagot számolni, nem csak a jelenlegi SampleRTT- ből

59 Szállítási réteg3-59 TCP Round Trip Time és Timeout EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT r exponenciálisan súlyozott átlag r a régi minták befolyása exponenciálisan, gyorsan csökken  általában:  = 0.125

60 Szállítási réteg3-60 Példa RTT becslésre:

61 Szállítási réteg3-61 TCP Round Trip Time és Timeout Timeout beállítása  EstimtedRTT + „biztonsági szél”  Nagy váltakozás az EstimatedRTT- ben -> nagyobb biztonsági szél r előszőr becslést kell adni, hogy mennyire váltakozik a SampleRTT az EstimatedRTT-től: TimeoutInterval = EstimatedRTT + 4*DevRTT DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT| (általában,  = 0.25) utána kell megadni a timeout intervallumot:

62 Szállítási réteg3-62 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

63 Szállítási réteg3-63 TCP megbízható adatszállítás r TCP létrehoz egy rdt szolgáltatást az IP-k megbízhatatlan szolgáltatásán r szegmensek csővezetékes küldése r kumulatív ACK-k r a TCP egyetlen újraküldési timert használ r Az újraküldéseket: m timeout események m megduplázott ACK-k irányítják r Előszőr figyelembe kell venni az egyerűsített TCP küldőt: m nem kell tudomásul venni a megduplázott ACK-kat m valamint az áramlási, és zsúfoltsági vezérlőket

64 Szállítási réteg3-64 TCP szállítási események: Alkalmazásoktól fogadott adat: r szegmens léterhozása szekv #-al r szekv # az adat első byte-jának a száma r stopperóra elindítása (stopperóra = legrégebbi igazolatlan szegmens)  határidő intervallum: TimeOutInterval timeout: r újraküldeni azt a szegmenst, amely a timeout-ot okozta r stopperóra újraindítása Ack megérkezett: r Ha az igazolások nem igazolták eddig az igazolatlan szegmenseket m megjegyezni, hogy mit kell igazolni m stopperóra indítása, ha szükséges

65 Szállítási réteg3-65 TCP küldő (egyszerűsí tett) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ Megjegyzés: SendBase-1: utolsó kumulatívan igazolt byte Pl: SendBase-1 = 71; y= 73, fogadónak 73+ kell ; y > SendBase, az új adat igazolva lesz

66 Szállítási réteg3-66 TCP: újraküldés forgatókönyvek A Hoszt Seq=100, 20 bytes data ACK=100 idő korai timeout B Hoszt Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=92 timeout ACK=120 A Hoszt Seq=92, 8 bytes data ACK=100 vesztés timeout elveszlődött ACK B Hoszt X Seq=92, 8 bytes data ACK=100 idő Seq=92 timeout SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100

67 Szállítási réteg3-67 TCP példa újraküldésre (folyt.) A Hoszt Seq=92, 8 bytes data ACK=100 vesztés timeout kumulatív ACK példa B Hoszt X Seq=100, 20 bytes data ACK=120 idő SendBase = 120

68 Szállítási réteg3-68 TCP ACK generation [RFC 1122, RFC 2581] Esemény a fogadónál Hibátlan szegmens érkezése az elvárt szekv #-al. Minden adat igazolva volt eddig a szekv # -ig Hibátlan szegmens érkezése az elvárt szekv #-al. Egy másik szegmens ACK-ra vár Hibátlan szegmens érkezése az elvártnál nagyobb szekv #-al Hézag detektálva Olyan szegmens érkezése, amely részben vagy teljesen betőlti a hézagot TCP fogadó művelet Késői ACK. Vár max 500ms a követ- kező szegmensre. Ha nem érkezik egy újabb szegmens, send ACK Azonnal elküldi az egyszerű kumulatív ACK-t, igazolja mindkét hibátlan szegmenset Azonnal elküldi a megduplázott ACK-t, utalva a köv szekv #-ra. Azonnal elküldi az ACK-t, feltételezve, hogy a szegmens a hézag elején kezdődik

69 Szállítási réteg3-69 Gyors újraküldés r A timeout idő gyakran túl nagy: m nagy késés az elveszett szegmens újraküldése előtt r Elvesztett szegmensek detektálása duplázott ACK-kon keresztül. m a küldő gyakran túl sok szegmenset küld újra m ha a szegmens elvész, több duplázott ACK jön létre. r Ha a küldő 3 ACK-t kap ugyanarra az adatra, feltételezi, hogy adatvesztés történt: m gyors újraküldés: újraküldi a szegmenset mielőtt az idő lejár

70 Szállítási réteg3-70 esemény: ACK megérkezett, ACK mező értéke y if (y > SendBase) { SendBase = y if (vannak igazolatlan szeletek) stopperóra indítása } else { növeli az y-ra érkezett ACK-k számát if (ha az érték = 3) { újraküldi az y szekv. számú szeletet } Gyors újraküldési algoritmus: megduplázott ACK már igazolt szegmensre gyors újraküldés

71 Szállítási réteg3-71 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

72 Szállítási réteg3-72 TCP áramlásvezérlés r a TCP kapcsolat fogadó oldalának van egy fogadó puffere: r sebesség-beállítási szolgáltatás: a küldési/fogadási sebbesség arányának a beállítását biztosítja r alk. folyamat lehet, hogy lassan olvassa az adatot a pufferből A küldő nem fogja a fogadó pufferét túlterhelni, túl sok adattal valamint túl nagy küldési sebsség miatt áramlásvezérlés

73 Szállítási réteg3-73 TCP áramlásvezérlés: müködése (Feltételzzük, hogy a fogadó eldobja a hibás szegmenseket)  helyet szabadít fel a pufferben = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]  A fogadó meghirdeti a szabad helyet belefoglalva az RcvWindow értékét a szegmensbe  A küldő átállítja az igazolatlan adat nagyságát RcvWindow - ra m ez garancia arra, hogy a fogadó puffert nem terheli túl

74 Szállítási réteg3-74 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

75 Szállítási réteg3-75 TCP kapcsolat kezelése Ismétlés: a TCP küldő és fogadó létrehozza a „kapcsolatot” adatszegmens csere előtt r TCP változók létrehozása: m szekv. #-ok  pufferek, áramlásvezérlés info (pl. RcvWindow ) r kliens: kapcsolat inicializáló Socket clientSocket = new Socket("hostname","port number"); r szerver: kapcsolatot fogadja Socket connectionSocket = welcomeSocket.accept(); Kézfogás: 1. lépés: a kliens hoszt küld TCP SYN szegmenset a szerverhez m meghatározza a szekv #-ot m nincs adat 2. lépés: a szerver hoszt fogadja a SYN-t, válaszol SYNACK szegmenssel m a szerver létrehozza a puffereket m meghat. a szerver kezdeti szekv. #-át 3. lépés: a kliens megkapja a SYNACK-et, ACK szegmenssel válaszol, amely tartalmazhatja az adatot

76 Szállítási réteg3-76 TCP kapcsolat kezelése (folyt.) Kacpsolat zárása: a kliens zárja a socketet: clientSocket.close(); 1. lépés: a kliens TCP FIN vezérlő szegmenst küld a szerverhez 2 lépés: szerver fogadja a FIN-t, válaszol ACK-val. Zárja a kapcsolatot, elküldi a FIN-t. kliens FIN szerver ACK FIN zár zárva időzített várakozás

77 Szállítási réteg3-77 TCP kapcsolat kezelése (folyt.) 3. lépés: kliens fogadja a FIN-t, ACK-t válaszol. m Belép az “időzített várakozásba” – ACK-t fog válaszolni a fogadott FIN-ekre 4. lépés: szerver, fogadja az ACK-t. Kapcsolat vége. Megjegyzés: kis módosításokkal, párhuzamos FIN is kezelhető. kliens FIN szerver ACK FIN zár zárt időzített várakozás zárt

78 Szállítási réteg3-78 TCP kapcsolat kezelése (folyt.) TCP kliens életciklusa TCP szerver életciklusa

79 Szállítási réteg3-79 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

80 Szállítási réteg3-80 A zsúfoltság ellenőrzés alapjai zsúfoltság: r „túl sokan küldenek, túl sok adatot, túl gyorsan, a hálózat nem képes kezelni” r más, mint az áramlásvezérlés! r megnyilvánulások: m elveszett csomagok (puffer túlcsordulás a rutereknél) m nagy késések (sorakozás a ruter pufferekben) r egy fontos probléma!

81 Szállítási réteg3-81 Okok/költségek: 1. forgatókönyv r két küldő, két fogadó r egy ruter, végtelen pufferek r nincs újraküldés r jelölések: m in – közvetítési sebesség m out – érkezési sebesség m C – ruter áteresztő kapacitása r nagy késések zsúf. esetén r maximális elérhető áteresztő képesség végtelen kimeneti kapcsolat pufferek A Hoszt in : eredeti adat B Hoszt out

82 Szállítási réteg3-82 Okok/költségek: 2. forgatókönyv r egy ruter, véges pufferek r elveszett csomagok újraküldése véges osztott kimeneti kapcsolat pufferek A Hoszt in : eredeti adat B Hoszt out ' in : eredeti adat, + újraküldött adat

83 Szállítási réteg3-83 Okok/költségek: 2. forgatókönyv r mindig: r „tökéletes” újraküldés csak adatvesztés esetén: r a késő (el nem veszett) csomagok újraküldése miatt esetenként nagyobb, mint ideális esetben in out = in out > in a zsúfoltság „költségei” : r több a munka r szükségtelen újraküldések: a kapcsolat a csomag többszörös másolatát hordozza

84 Szállítási réteg3-84 Okok/költségek: 3. forgatókönyv r négy küldő r több ruter egy útvonalon r timeout/újraküldés in Q: Mi történik, ha és nőnek? in véges osztott kimeneti kapcsolat pufferek A Hoszt in : eredeti adat B Hoszt out ' in : eredeti adat, + újraküldött adat

85 Szállítási réteg3-85 Okok/költségek: 3. forgatókönyv A zsúfoltság egy újabb „költsége” : r ha egy csomag elvész, minden rá fordított „upstream” közvetítési kapacitás is hiába volt! HostAHostA HostBHostB o u t

86 Szállítási réteg3-86 A zsúfoltsági vezérlés megközelítése végponti zsúf. vezérlés: r nincs explicit visszajelzés a hálózattól r a zsúfoltságot a végrendszer a csomagvesztések, késések révén érzékeli r a TCP által alkalmazott megközelítés hálózat által felügyelt zsúf. vezérlés: r a ruterek visszacsatolást biztosítanak a végrendszereknek m külön bit jelzi a zsúf.-ot (SNA, DECbit, TCP/IP ECN, ATM) m expliciten jelzett közvetítési sebesség Két lehetséges megközelítés:

87 Szállítási réteg3-87 Esetelemzés: ATM ABR zsúf. vez. ABR: available bit rate (rendelkezésre álló bit rate): r „rugalmas szolgáltatás” r ha a küldő útvonala „alulterhelt”: m a küldő a teljes sávszélességet használhatja r ha a küldő útvonala zsúfolt: m a küldőt lassítja a legkisebb garantált átviteli sebességre RM resource management (erőforrás kezelés) cellák: r A küldő fél küldi az adatcellák között r a biteket az útvonalon levő switch- ek állítják, „hálózat-vezérelés” m NI bit: no increase (ne növelj) – enyhe zsúfoltság m CI bit: congestion indication (zsúf. jelzés) r az RM cellákat a fogadó érintetlenül visszaküldi a küldőnek

88 Szállítási réteg3-88 Esetelemzés : ATM ABR zsúf. vez. r két-byte ER (explicit rate) mező az RM cellában m a zsúfolt switch csökkenti az ER értékét a cellában m értéke az útvonalon levő switch-ek legkisebb „elviselhető” kapacitása r EFCI bit : 1-re állítva a zsúf. kapcsolóban m Ha az RM cella előtti adat cella EFCI bitje be van állítva, akkor a küldő átállítja a CI bitet a visszatérített RM cellában

89 Szállítási réteg3-89 3. Fejezet: vázlat r 3.1 A szállítási réteg szolgáltatásai r 3.2 Multiplexelés és demultiplexelés r 3.3 Összeköttetés- mentes szállítás: UDP r 3.4 A megbízható adatszállítás alapelvei r 3.5 Összeköttetés-alapú szállítás: TCP m szegmens szerkezete m megbízható adatszállítás m áramlás-ellenőrzés m kapcsolatkezelés r 3.6 A zsúfoltság- ellenőrzés alapelvei r 3.7 TCP zsúfoltság- ellenőrzés

90 Szállítási réteg3-90 TCP zsúfoltság-ellenőrzés: additív növelés, multiplikatív csökkentés idő Ablak mérete Fűrészfog viselkedés: a sávszélesség vizsgálata r Megközelítés: növeljük a közvetítési sebességet (ablakméret) vizsgálva az elérhető sávszélességet, amíg adatvesztés lép fel  additív növelés: növeljük a CongWin -t 1 MSS-el RTT-nként amíg adatvesztést észlelünk  multiplikatív csökkentés: a CongWin felezése adatvesztés után

91 Szállítási réteg3-91 TCP zsúfoltság-ellenőrzés: részletek r végpontok közti vezérlés (nincs hálózati felügyelet) r a küldő korlátozza a közvetítési sebességet: LastByteSent-LastByteAcked  CongWin r Durván közelítve,  a CongWin dinamkus érték, az érzékelt hálózati zsúfoltság függvénye Hogyan érzékeli a küldő a zsúfoltságot? r adatvesztés = timeout vagy 3 megduplázott ACK  a TCP küldő csökkenti a sebességet ( CongWin ) adatvesztés után három mechanizmus: m AIMD m lassú start m konzervatív timeout események után rate = CongWin RTT Bytes/sec

92 Szállítási réteg3-92 TCP lassú indulás  A kapcsolat elején, CongWin = 1 MSS m pl: MSS = 500 byte & RTT = 200 msec m kezdeti sebesség = 20 kbps r A rendelkezésre álló sávszélesség lehet >> MSS/RTT m kívánatos minél gyorsabban minél nagyobb sebességet elérni r A kapcsolat elején, exponenciálisan nő a sebesség az első adatvesztésig

93 Szállítási réteg3-93 TCP Lassú indulás (folyt.) r A kapcsolat elején, exponenciálisan nő a sebesség az első adatvesztésig:  CongWin megduplázódik minden RTT-n  növeli a CongWin -t minden egyes fogadott ACK után r összefoglalás: a kezdeti sebesség kicsi, de exponecniálisan nő A Hoszt egy szegmens RTT B Hoszt idő két szegmens négy szegmens

94 Szállítási réteg3-94 Finomítás K: Mikor legyen az exponenciális növekedésből líneáris? A: Amikor a CongWin eléri timeout előtti értékének az felét Implementáció: r Változó küszöb r Adatvesztéskor a küszöböt az adatvesztés előtti CongWin felére állítja

95 Szállítási réteg3-95 Finomítás r 3 ismételt ACK után:  CongWin / 2 m az ablak lineárisan nő r De timeout után :  CongWin 1 MSS-re állítódik; m az ablak exponenciálisan nő m egy küszöbértéktől (threshold) ismét lineárisan nő 3 dup ACK jelzi, hogy a hálózat képes szegmenseket szállítani timeout „aggasztóbb” helyzet Filozófia:

96 Szállítási réteg3-96 Összefoglaló: TCP zsúfoltság ellenőrzés  Amikor CongWin < Threshold, a küldő lassú- start fázisban, az ablak exponenciálisan nő.  Amikor CongWin > Threshold, a küldő zsúfoltságot megelőző fázisban, az ablak lineárisan nő.  3 ACK esetén, Threshold = CongWin/2 és CongWin = Threshold.  Timeout esetén, Threshold = CongWin/2 és CongWin = 1 MSS.

97 Szállítási réteg3-97 Méltányosság: ha K TCP kapcsolat osztozik egy R sávszélességű szűk-keresztmetszeten, mindegyik sebessége R/K kéne legyen TCP kapcsolat 1 szűkkeresztmetszet ruter kapacitás R TCP kapcsolat 2 TCP méltányossága

98 Szállítási réteg3-98 Miért méltányos a TCP? Két versengő kapcsolat: r additív növelés 1-es hajlásszöget eredményez növekedés esetén r multiplikatív csökkentés egyformán, mindenütt R R egyforma sávszélesség megosztás Kapcsolat 1 Kapcsolat 2 zsúf. elkerülése: additív növelés vesztés: ablak csökkentése 2 tényezővel zsúf. elkerülése: additív növelés vesztés: ablak csökkentése 2 tényezővel

99 Szállítási réteg3-99 Méltányosság (folyt.) Méltányosság és UDP r Multimedia alk-ok gyakran nem használnak TCP-t m nem akarják a sebesség visszafogását r inkább UDP-t használ: m audio/video konstans sebességgel, csomagvesztés toleráns Méltányosság és párhuzamos TCP kapcsolatok r Az alkalmazások bármikor nyithatnak több párhuzamos kapcsolatot két hoszt között. r Webböngészők ezt teszik r pl: kapcsolat sávszélessége R, már van 9 kapcsolat; m alk kér 1 TCP-t, sebesség = R/10 m új alk kér 11 TCP-t, kap R/2-t!

100 Szállítási réteg3-100 Késés megbecsülése Q: mennyi ideig tart egy objektum megérkezése, a kérés elküldésétől? Ha eltekintünk a zsúfoltságtól, a késést befolyásolják a: r TCP kapcsolat létrehozása r adatszállítási késés r lassú start Jelölés, feltételezések: r egy R sebességű kapcsolatot a kliens és szerver között r S: MSS (bit) r O: objktum mérete (bit) r nincs újraküldés (nincs vesztés, nincs hiba) Ablak mérete: r előszőr fix zsúf. ablak, W szegmensek r majd dinamikus ablak, lassú start

101 Szállítási réteg3-101 Fix zsúf. ablak (1) Első eset: WS/R > RTT + S/R: ACK az ablak első szegmensére megérkezik, mielőtt megtelne e küldő ablak késés = 2RTT + O/R

102 Szállítási réteg3-102 Fix zsúf. ablak (2) Második eset: r WS/R < RTT + S/R: várja az ACK-t miután megtelt a kükdő ablak késés = 2RTT + O/R + (K-1)[S/R + RTT - WS/R]

103 Szállítási réteg3-103 TCP késés: lassú start (1) Feltételezzük, hogy az ablak a lassú startnak megfelelően nő A késés egy objektumra: P az a szám, ahányszor a TCP várakozik a szerveren: -Q az a szám, ahányszor a szerver várakozna, ha az objektum végtelen - K azon ablakok száma melyek lefedik az objektumot.

104 Szállítási réteg3-104 TCP késési mintázás: lassú start (2) Pl: O/S = 15 szelet K = 4 ablak Q = 2 P = min{K-1,Q} = 2 Szerver munkanélküli P=2 Késési komponensek: 2 RTT kapcsolat létrehozására O/R objektum küldésére Szerver „munkanélküli”: P = min{K-1,Q} -szor

105 Szállítási réteg3-105 TCP késési mintázás (3)

106 Szállítási réteg3-106 TCP késési mintázás: (4) Q kiszámítása, szerver várakozások száma végtelen méretű obj. miatt K = azon ablakok száma, melyek fedik az objektumot K kiszámítása?

107 Szállítási réteg3-107 HTTP mintázás r Feltételzzük, hogy a weboldalak a köv. állnak: m 1 alap HTML oldal (O bit méretű) m M kép (O bit méretűek egyenként) r Nem-perszisztens HTTP: m M+1 TCP kapcsolatok m Válaszidő (Response time) = (M+1)O/R + (M+1)2RTT + lézengési idő r Perszisztens HTTP: m 2 RTT, alap HTML fájl kérése és fogadásáért m 1 RTT, M képek kérése és fogadásáért m Válaszidő = (M+1)O/R + 3RTT + lézengési idő r Nem-perszisztens HTTP, X párhuzamos kapcsolatokkal m Feltételezzük, h. M/X integer. m 1 TCP kapcsolat az alap fájlért m M/X párhuzamos kapcsolatok halmaza a képekért. m Válaszidő = (M+1)O/R + (M/X + 1)2RTT + lézengési idő

108 Szállítási réteg3-108 HTTP Válaszidő (másodpercekben) RTT = 100 msec, O = 5 Kbytes, M=10 and X=5 alacsony sávszélességre, a kapcsolatot & válaszidőt a szállítási idő uralja. Perszisztens kapcsolatok csak kissé javulnak párhuzamos kapcsolatokon keresztül.

109 Szállítási réteg3-109 HTTP Válaszidő (másodpercekben) RTT =1 sec, O = 5 Kbytes, M=10 and X=5 Nagyobb RTT-re, a válaszidőt a TCP létesítés uralja valamint a lassú start késések. Perszisztens kapcsolatok nagyot javítanak: főleg a nagy késésű sávszélességi hálózatokban.

110 Szállítási réteg3-110 3. Fejezet: Tartalom r Szállítási réteg szolgáltatásainak az alapelvei: m multiplexelés, demultiplexelés m megbízható adatszállítás m áramlásvezérlés m zsúfoltság ellenőrzés r azonnaliság és implementáció az interneten m UDP m TCP Következik: r elhagyjuk a hálózat „peremét” (alkalmazások, szállítási rétegek) r belevágunk a hálózat „magjába”