Megbízható adatátvitel

A TCP egy megbízható adatátviteli szolgáltatást biztosít az IP megbízhatatlan legjobb szándékú szolgáltatása felett. A TCP garantálja, hogy a vev˝onél a pufferb˝ol kiolvasott adatfolyam hibamentes, hiánytalan, duplikáció mentes és sorrendhelyes, azaz a fogadott bájtfolyam tökéletesen megegyezik

a kiküldött bájtfolyammal. A TCP megbízható adatátvitelének mélyebb megértéséhez két lépésre bontjuk a m˝uködési folyamatot. El˝oször egy egyszer˝usített TCP küld˝ot vizsgálunk meg, amely csak id˝ozítést használ az elveszett csomagokból adódó hiba kezelésére, majd megnézzük a duplikált nyugták kezelését is.

A TCP küld˝o adat továbbításához és újraküldéséhez három f˝o esemény kapcsolódik:

• adat fogadása az alkalmazástól: a TCP fogadja az adatot az alkalmazástól, majd azt beágyazza egy szegmensbe és továbbítja az IP-nek. Minden szegmens tartalmaz egy szekvencia számot, amely a bájtfolyam els˝o bájtjára mutat a szegmensben. Továbbá ha nincs futó id˝ozít˝o más szegmensre, akkor az IP-nek történ˝o átadáskor elindítja az id˝ozít˝ot, és kiszámítja az aggregált id˝otúllépési mutatót (TimeoutInterval).

• id˝otúllépés: id˝otúllépés esetén a TCP újraküldi azt a szegmenst, amely kiváltotta az id˝otúllépést, és újraindítja az id˝ozít˝ot.

• nyugta fogadása: nyugta beérkeztekor a TCP összehasonlítja a nyugta számot (y) a legrégebben kiküldött nyugtázatlan szegmens szekvencia számával (SendBase). Mivel összesít˝o nyugtákkal dolgozik a TCP, így a nyugta számmal több szegmens is nyugtázásra kerül.y>SendBase esetén több korábban kiküldött nyugtázatlan szegmens is visszaigazoltnak tekintend˝o. Ekkor a szekvencia szám frissítésre kerül, a legutolsó még nem nyugtázott csomag szekvencia számára állítódik.

A 4.24 ábrán láthatóak az újraküldés esetei. A bal oldali esetben az elveszett nyugta okozta újraküldést szemléltetjük, míg a jobb oldalon láthatón az id˝otúllépésb˝ol adódó újraküldést.

elveszett ACK

4.24: Újraküldés elveszett nyugta és korai id˝otúllépés miatt¹

Az id˝otúllépés által kiváltott újraküldés egyik problémája, hogy az id˝otúllépési periódus nagy is lehet. Egy szegmens elvesztésével a hosszú id˝otúllépési periódus miatt a küld˝o csak nagy késleltetéssel tud újraküldeni, amellyel a vev˝o oldalon is megnövekszik a késleltetés.

Szerencsére a küld˝o képes detektálni csomagvesztést az id˝ozít˝o lejárta el˝ott is, mégpedig, ha duplikált nyugtát kap. A 1 táblázat összefoglalja anyugta generálásának eseteit, amely az RFC 1122-ben és az RFC 2581-ben definiáltak.

Mivel a küld˝o sok szegmenst küld egymás után, így egy szegmens elvesztésével sok duplikált ACK jelenne meg. Ha egy TCP küld˝o három duplikált nyugtát kap, az azt jelenti, hogy a háromszor nyugtázott szegmenst követ˝o szegmensek elvesztek. A három duplikált nyugta esetén a TCP egy gyors újraküldést (RFC 5681) indít a szegmensre vonatkozóan, miel˝ott az id˝ozít˝oje lejárna. Ezt az

Vev˝onél bekövetkezett esemény Vev˝o TCP lépés Sorrendhelyes szegmens érkezik, és az összes

eddig beérkezett szegmens nyugtázva lett.

A nyugta késleltetése. Legfeljebb 500 milliszekundumot vár a következ˝o szegmensre.

Ha nincs következ˝o, akkor kiküldi a nyugtát.

Sorrendhelyes szegmens érkezik, de egy szegmens nyugtája még nem lett elküldve.

Azonnal egy összesített nyugtát küld mindkét szegmensre.

Egy olyan szegmens érkezik, melynek szekvencia száma nagyobb, mint a várt (lyuk keletkezik).

Azonnal duplikált nyugta kiküldése, ezzel jelezve a várt szekvencia számmal ellátott szegmenst.

Olyan szegmens érkezik, amely részben vagy egészben kitölti a lyukat.

Ha a lyuk alsó részét tölti ki, akkor azonnali nyugta küldés.

1: TCP nyugta el˝oállítási ajánlások (RFC 5681) esetet szemlélteti a 4.25 ábra.

tripla duplikált ACK

4.25: Gyors újraküldés: a hiányzó szegmens újraküldése, miel˝ott az id˝ozít˝o lejár¹

Folyamvezérlés

A cs˝oszervezés˝u protokolloknál használtunk el˝oször puffereket (gyorstárakat), amellyel sikeresen megoldottuk a nem megfelel˝o sorrendben érkez˝o csomagok újraküldésének problémáját. Ez a puffer mindkét résztvev˝onél létezik, és az elvárt m˝uködés szerint az alkalmazások innen olvassák be az adatokat, de nem garantálható, hogy a szegmensek érkezésének sorrendjében kerül a pufferb˝ol ki az adat. Ha az alkalmazás relatív lassan dolgozza fel az adatokat, akkor egy nagy sebesség˝u küld˝o esetén a vev˝o puffere könnyen túlcsordulhat.

Ezen probléma megoldására kínál a TCP egy ún. folyamvezérlési szolgáltatást, amellyel megakadályozható a fogadó fél pufferének túlcsordulása. A folyamvezérlés tulajdonképpen egy sebesség egyeztet˝o szolgáltatás, amellyel összeegyeztethet˝o a küld˝o küldési sebessége és a vev˝o feldolgozási képessége. A TCP egy vev˝o ablak változót tart fenn a küld˝onél, amely megmondja a küld˝onek, hogy a vev˝onél a puffer mekkora része szabad.

Mivel a TCP kétirányú adatforgalmat von maga után, így mindkét résztvev˝onél ismert a másik vev˝o ablaka. Vizsgáljuk meg az alábbi példát!

Tegyük fel, hogy A egy nagy fájlt küld B számára TCP kapcsolat felett. B allokál egyRcvBuffer

méret˝u puffert a kapcsolathoz, amelyb˝ol a processzus folyamatosan olvassa az adatokat. Bevezetünk két változót, LastByteReadjelölje az adatfolyam utoljára kiolvasott bájtját a B pufferéb˝ol, és LastByteRcvdaz utolsó pufferba betöltött (megérkezett) bájtot. Mivel a TCP nem engedi túlcsordulni B pufferét, ezért igaz az alábbi egyenl˝otlenség.

LastByteRcvd−LastByteRead≤RcvBu f f er (4.6)

A vev˝oablakot jelöljerwnd, amely az alábbi módon számítható:

rwnd=RcvBu f f er−(LastByteRcvd−LastByteRead) (4.7) Mivel a puffer szabad területe folyamatosan változik, ígyrwnddinamikus. Hogyan szabályozza B az A küld˝o által kiküldött bájt folyamot?

A vev˝o minden visszaküldött szegmensben elküldi az aktuálisrwndértéket, ezzel tájékoztatva a küld˝ot a puffer jelenlegi helyzetér˝ol. Kezdetben azrwndértékeRcvBufferértékével egyenl˝o.

Kapcsolatkezelés

Fontos A megbízható adatátvitel megvalósításához a TCP kapcsolat mindkét résztvev˝ojének szinkronizálnia kell állapotát a másikkal.

A korábbiakban felvázolthárom lépéses kézfogást (three-way handshake) vesszük gorcs˝o alá.

Ahogy azt már említettük, a kapcsolat létrejöttekor kiküldött szegmensek speciálisak. A három lépés három TCP szegmenst jelent, amelyek az alábbi struktúrával és mez˝o értékekkel bírnak.

1. lépés:A kliens-oldali TCP kiküld egy szegmenst a szerver-oldali TCP felé. A kiküldött szegmens nem tartalmaz alkalmazás rétegbeli adatot, azonban a flag bitek közül a SYN beállításra kerül 1-es értékkel. Ezért az 1. lépésben összeállított szegmenstSYNszegmensnek is nevezik.

Ezen túl a kliens véletlenszer˝uen választ egy iniciális szekvencia számot, amelyet bele is helyez a kezd˝o TCP SYN szegmensbe. A szegmens beágyazásra kerül egy IP datagramba, és elküldésre kerül a szerver felé.

2. lépés: A szerverhez beérkez˝o IP datagramból kibontásra kerül a TCP SYN szegmens, allokálásra kerül a TCP puffer, és visszaküld egy olyan szegmenst, amellyel a kapcsolódást engedélyezi a szerver a kliensnek. Ebben a szegmensben sincs alkalmazás adat, viszont ez is tartalmaz speciális értékeket és flag-eket. Els˝oként a SYN és ACK flag bitek kerülnek beállításra (1-es érték), valamint a nyugta mez˝oje a TCP fejlécnek (acknowledgement number) 1-gyel nagyobb értéket kap, mint a kliens által választott szekvencia szám. Végül, a szerver is választ egy szekvencia számot véletlenszer˝uen. Ezt a szegmenstSYNACKszegmensnek szokták nevezni.

3. lépés:A SYNACK szegmens fogadásával a kliens elismeri a kapcsolódás jogát, és allokálja a puffert és a változókat a kapcsolathoz. A kliens ilyenkor visszaküld egy nyugtát a szerver felé, amellyel elfogadja a kapcsolódási jogot. A szegmensben kizárólag az ACK flag bit kerül beállításra (1-es érték), a SYN ilyenkor 0-t kap. Ezt a szegmenst nevezikACKszegmensnek is.

A 4.26 ábra szemlélteti a három lépéses kézfogást és annak lépéseit.

A nyitás áttekintése után nézzük meg a kapcsolat zárását! A kliens alkalmazás processzus le szeretné zárni a kapcsolatot, és kibocsát egy zárás parancsot. Ezzel a kliens TCP egy speciális szegmenst küld ki, amelyben aFINflag bit kap 1-es értéket. Ha a szerver egy ilyen szegments kap, akkor a kapcsolat lezárást nyugtázza (ACK), majd ˝o is küld egy beállított FIN bittel ellátott szegmenst a kliensnek. A kliens szintén küld egy nyugtát a szervernek, amelyet követ˝oen minden foglalt er˝oforrás felszabadul.

SYNbit=1, Seq=x iniciális szekvencia szám választása (x),

TCP SYN üzenet kiküldése

(ez a szegmens már tartalmazhat alkalmazás adatot is)

Kliens

SYNbit=1, Seq=x

SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1

iniciális szekvencia szám választása (y),

TCP SYNACK üzenet kiküldése, SYN visszaigazolása

ACKnum=y+1

ACK fogadása (y+1)

Szerver

4.26: TCP három lépéses kézfogás¹ 4.6 A torlódásvezérlés alapjai

A következ˝okben megvitatjuk a torlódásvezérlést alapjait, amelynek célja, hogy egy általános képet kapjunk a problémáról és annak velejáróiról. A téma fontosságát az is érzékelteti, hogy a hálózati problémát top 10-es listájában is helyet kap.

Ámbár hasonló a problémák eredete, fontos, hogy a torlódásvezérlés nem összekeverend˝o a folyamvezérléssel! Egy hálózatban torlódás egyszer˝uen abból adódik, ha túl sok küld˝o túl sok adatot bocsát ki, de azt a hálózat nem nem tudja kezelni. A torlódás következménye lehet csomagvesztés, például a forgalomirányítók pufferei betelnek, és az extra csomagokat el kell dobnia, vagy hosszú késleltetések, például a forgalomirányítók puffereiben sorakoznak az csomagok. Els˝o körben csak a problémára és annak megértésére fókuszálunk néhány eseten keresztül.

1. eset: Vegyük a legegyszer˝ubb példát, amelyet a 4.27 ábra is szemléltet! Két küld˝o (A, B) és két vev˝o (C, D) van, ahol a vev˝oket és a küld˝oket egy forgalomirányító köt össze (egy ugrás). Az A hosztnál futó alkalmazás küldési rátájaλin bájt/másodperc. A szállítási rétegbeli protokollunk legyen egyszer˝u, nincs hibadetektálás, újraküldés, folyamvezérlés és torlódásvezérlés sem. Figyelmen kívül hagyva az alsóbb réteg által hozzáadott információk méretét az A számítógép λin bájt/másodperccel forgalmaz. Az egyszer˝uség végett a B gép is hasonló paraméterekkel dolgozik, szinténλinbájt/másodperc forgalmazással. Az adatok a túl oldalra egy közös, osztott vonalon keresztül haladnak, amelynek kapacitása R. A router rendelkezik pufferrel, amelyben sorakozhatnak a csomagok, de tegyük fel, hogy ennek a kapacitása végtelen.

A 4.28 ábra grafikonjai szemléltetik, hogy az átereszt˝oképesség és a késleltetés hogyan változik a forgalom nagyságának növelésével. Ha a küldési ráta 0 ésR/2 közötti, akkor az átereszt˝o képesség a fogadónál egyenl˝o a küldési sebességgel, minden véges késleltetéssel érkezik meg. Ha bármely küld˝o fél küldési sebességeR/2 felé megy, az átereszt˝oképesség nem változik, továbbra isR/2 marad, hiszen a vonal kapacitása nem enged többet, viszont a késleltetés egyre csak n˝o és n˝o, tart a végtelen felé.

2. eset: A második forgatókönyv szerint ugyancsak két küld˝onk (A és B) és két fogadónk (C és D) van, azonban a router puffere ezúttal véges. Ennek következménye, hogy ha a puffer megtelik, akkor a többi érkez˝o csomag nem fér be, így azok eldobásra kerülnek. Ezen kívül minden kapcsolatról feltételezzük, hogy megbízható, azaz, ha egy csomagot eldob a router, akkor újraküldés történik (id˝ozít˝o használatával). Mivel az újraküldés engedélyezett, így a küldési sebességet nagy figyelemmel kell kezelnünk. Az eredeti adatküldést továbbra isλin bájt/másodperccel történik, azonban az újraküldéseket is beleszámítva ezλ_in ≥λinbájt/másodpercet jelent. A teljesítmény

A gép

eredeti adat:  _in

B gépgép

végetelen, megos ztott, kimeneti buffer

átviteli kapactitás:  _out

4.27: Két kapcsolat megosztott végtelen pufferrel¹ R/2

R/2



out



_in ^R/2

késleltetés



_in

4.28: Az átereszt˝oképesség és a késleltetés alakulása a forgalom növelésével¹

nagyban függ az újraküldést˝ol, ezért bontsuk három felé a szcenáriónkat (4.29 ábra)!

a) Tekintsük azt a valótlan(!) esetet, amikor a küld˝o (A) meg tudja jósolni, hogy a forgalomirányító puffere szabad vagy sem. Csak akkor forgalmaz, ha a puffer üres. Ebben az esetben adatvesztés nem történik, és teljesül aλ_in =λin egyenl˝oség. Ilyenkor az átereszt˝oképességet tekintetében a teljesítmény ideális. Fontos megjegyezni, hogy a küldési sebesség itt sem lehetR/2-nél magasabb, mivel a csomagvesztést kizártuk.

b) A küld˝o újraküld, ha a csomag elveszett. Tegyük fel, hogy a teljes forgalmazási ráta (eredeti adat + újraküldés)λ_in =R/2. Ebben az esetben a vev˝o terheléseR/3 értéken van, hiszen az újraküldésekre is kell sávszélességet biztosítani, de aszimptotikusanR/2 a sávszélesség még mindig.

c) Végül vegyük azt az esetet, amikor az id˝ozít˝o túl hamar lejár, és a küld˝o azel˝ott újraküldi csomagot, miel˝ott az elveszett volna. Ilyenkor az eredeti csomag és az újraküldött is megérkezhet a vev˝ohöz. Természetesen, a vev˝o az újraküldött csomagot eldobja, azonban az újraküldés "pazarolta" a forgalomirányító kapacitását. Ha minden csomagot kétszer küldünk el, akkor az átereszt˝oképesség aszimptotikusan eléri azR/4 sebességet, míg a terhelés közelíti azR/2 értéket.

3. eset: Végül tekintsük azt az esetet, amikor négy küld˝o van, több ugrásos utak, ahogy a 4.30 ábrán is látható. Minden hoszt megbízható adatátvitelt garantál id˝otúllépés és újraküldés mechanizmusával. Minden számítógépλinbájt/másodperccel forgalmaz, és minden forgalomirányító Rbájt/másodperc kapacitással bír. Ahogy az ábrán is látható a kapcsolatok osztoznak a forgalomirányítókon:

az A-C kapcsolat R1-et és R2-t használja, a B-D kapcsolat R2-t és R3-at, a C-A R3-at és R4-et, a D-B pedig R4-et és R1-et.

Extrém kicsi λin érték esetén a a túlcsordulás ritka, valamint az átereszt˝oképesség és a kihasználtság közel egyforma. Aλinkismérték˝u növelésével a torlódás mértéke nem növekszik, de

R/2

4.29: 2. eset teljesítménye véges pufferekkel

A gép

4.30: Négy küld˝o, forgalomirányítók véges pufferrel és több ugrásos utakkal¹ az átereszt˝oképesség és kihasználtság párhuzamosa n˝o.

Amennyiben viszont λin (és λ_in ) értéke jelent˝osen nagyobb, akkor az átereszt˝oképesség a forgalomirányítóknál lecsökken és közelíti a 0-t, miközben a kihasználtság tovább növekszik, hiszen a kialakuló torlódás következtében a kés˝obb érkez˝o csomagok eldobásra kerülnek. Ennek a jelenségnek a grafikonja a 4.31 ábrán látható.

C/2

C/2



out



_in^{’ C/2}

4.31: 3. eset teljesítménye véges pufferekkel és több ugrásos utakkal¹

Ezzel látható a torlódás másik ára, azaz amikor egy csomagot eldobnak az addig igénybevett továbbító kapacitás feleslegessé válik.

4.7 TCP torlódásvezérlés

Visszakanyarodva a TCP-hez, megvizsgáljuk a torlódásvezérlés mechanizmusát.

Fontos Mivel az IP nem szolgáltat explicit információt a hálózatban kialakuló esetleges torlódásról, ezért a TCP-nekvég-végtorlódásvezérlést kell alkalmaznia.

A TCP megközelítésmódja az, hogy az érzékelt hálózati torlódás alapján próbálja növelni az küldési sebességet. Ha kis torlódást érzékel, akkor növeli a sebességet, ha nagy torlódást érzékel, akkor csökkenti.

A küldési sebesség meghatározásához a TCP fenntart egy változót, amely atorlódási ablakot jelöli (cwnd). Az itt tárolt érték határozza meg a küldési sebességet, konkrétan a küld˝o nyugtázatlan szegmenseinek a száma nem haladhatja meg az ütközési ablak és a vev˝o ablak minimumát.

LastByteSent−LastByteAcked≤min{cwnd,rwnd} (4.8)

A torlódásvezérlésre koncentrálva vizsgáljuk meg az alábbi feltételezést! Legyen a TCP vev˝o pufferének a mérete olyan nagy, hogy a vev˝o ablak megszorítás figyelmen kívül hagyható. Ennél fogva (az el˝oz˝o formulából is látszik) a küld˝onél a nyugtázatlan szegmensek számát a torlódási ablak határozza meg (cwnd). Mivel a nyugtázatlan adatra adtunk egy fels˝o korlátot, így ez indirekt módon korlátozza a küld˝o küldési sebességét is. Ahhoz, hogy ezt belássuk, a csomagvesztés és az átviteli késleltetés elhanyagolható. Így nagyjából minden RTT elején a küld˝ocwndbájtot tud küldeni, és RTT végén kap visszaigazolást is az adatokra. Így a küld˝o küldési sebességecwnd/RT T bájt/másodperc.

Ezek tudatában azonban még mindig felmerül a kérdés, hogy a TCP hogyan határozza meg a küldési sebességet? Erre ad választ a TCPtorlódásvezérlés algoritmus, melyet el˝oszörVan Jacobsonírt le 1988-ban, majd az RFC 5681-ben szabványosítottak. Az algoritmusháromf˝o komponensb˝ol áll:

1. lassú indulás 2. torlódás elkerülés 3. gyors helyreállás

4.7.1 Torlódásvezérlés algoritmus Lassú indulás

Egy TCP kapcsolat indításakor a cwnd értéke 1 MSS. Így az iniciális küldési sebesség körül-belül MSS/RTT. Például, ha MSS=500 bájt és RTT=200 ms, akkor az induló küldési sebesség körül-belül 20 kbps. A TCP számára elérhet˝o legmagasabb sávszélességnek természetesen nagyobbnak kell lennie, mint MSS/RTT, és ezt szeretné a lehet˝o leggyorsabban elérni. Éppen ezért a cwnd értékét minden visszaigazolt szegmens után megnöveli 1 MSS-sel, így a második küldéskor már két MSS méret˝u szegmenst küld ki. A kiküldött két szegmensre 1-1 visszaigazolás érkezik, így visszaigazolásonként újabb 1-1 MSS-sel növeli a küldési sebességet, ahogy azt a mellékelt 4.32 ábra is mutatja. Ezért kijelenthetjük, hogy a lassú indulás valójában exponenciális sebesség növekedést jelent.

Mikor kell megállni a sebesség növelésével?

Ha csomagvesztés történik (pl.: torlódás miatt), akkor a TCP küld˝o visszaállítja cwnd értékét 1 MSS-re, és újraindítja a lassú indulás komponensét az algoritmusnak. A cwnd értékén túl beállításra kerül egy második állapotváltozó, azssthresh("slow start threshold"), amely az ütközés detektálásakor használt cwnd érték felére lesz beállítva. Ez garantálja azt, hogy a lassú indulás folyamata újból ne jusson el az ütközés pontjáig a túl nagy küldési sebesség miatt. Ily módon cwnd újbóli növelése az ssthresh értékig megengedett. Ha ezt az értékek elérte cwnd, akkor az algoritmus átlép atorlódás elkerülés fázisába.

Torlódás elkerülés

Ebben a fázisbancwndértéke körül-belül fele akkora, mint a torlódás bekövetkeztekor. Így ahelyett, hogy az aktuáliscwndértéket megkétszerezzük, inkább csak növeljük mindig 1 MSS-sel minden RTT után. Azonban felmerül a kérdés, hogy ez a lineáris növekedés meddig tarthat? A következ˝o

A gép

RTT

idő

B gép

idő 4.32: TCP lassú indulás¹

csomag vesztésig, amelyet egyháromszorosan duplikált nyugta igazol. Ilyenkor a ssthresh értékét frissítjük azoncwndérték felére, amelyet a háromszorosan duplikált nyugta pillanatában tároltunk,cwnd-t pedig visszaállítjuk a felére. Ezzel átlépünk agyors helyreállásfázisba.

Gyors helyreállás

Ebben a fázisbancwnd értékét 1 MSS-sel növeljük minden duplikált nyugta esetén. Amikor a hiányzó szegmensr˝ol megérkezik a nyugta a küld˝ohöz, az algoritmus visszalép a 2-es fázisba (torlódás elkerülés). Id˝otúllépés esetén visszalépünk a lassú indulás lépéshez, éscwndértéke ismét 1-r˝ol indul.

A gyors helyreállás ajánlás a TCP-nél, nem szükségszer˝u komponens. A TCP korai verziójánál, a TCP Tahoe-nál a torlódási ablak mindig visszaállításra került 1 MSS-re, ezzel visszalépve a lassú indulás fázisába, függetlenül hogy az adatvesztést háromszorosan duplikált nyugta vagy id˝otúllépés okozta. Az újabb, TCP Reno implementáció már tartalmazza gyors helyreállás komponenst. A 4.33 ábrán látható diagram szemlélteti a TCP különböz˝o verzióinak m˝uködését.

A lassú indulástól eltekintve a TCP torlódásvezérlés voltaképp a torlódási ablak lineáris növekedéséb˝ol (cwnd növelése 1 MSS-sel minden RTT után), majd annak lefelezéséb˝ol áll.

Ezt szokták nevezni a torlódásvezérlés "additív növekedés, multiplikatív csökkenés" (AIMD) formájának is. Ez a "f˝urészfog" viselkedés, mely látható a 4.34 ábrán is, igazából a sávszélesség próbálgatását jelenti. A következ˝o rövid fejezet azonban rávilágít arra, hogy ennek miért és mikor van jelent˝osége.

4.7.2 TCP igazságosság

A TCP célja az igazságosság, mely szerint haKTCP kapcsolat ugyanaz azRsávszélesség˝u vonalat használja, akkor mindegyiknekR/Ksávszélességet kell biztosítani (4.35 ábra).

Ha feltételezzük, hogy a vonalon csak TCP kapcsolatok vannak, akkor a torlódásvezérlés következtében ez valóban kivitelezhet˝o, és ezzel a küldési sebesség is korlátozható. UDP esetében azonban más a helyzet, ott nincs torlódásvezérlés. Az UDP-t használó protokollok nem szeretnék, ha a torlódásvezérlés lefojtaná a rendelkezésükre álló sávszélességet. Például a multimédia alkalmazások leggyakrabban így m˝uködnek, ugyanakkor ezek tolerálják is a csomagvesztést.

0 2 4 6 8 10 12 14 16

0 1 2 3 4 5 6 7 8

Ütközési ablak (szegmensekben)

Átviteli körök

8 9 10 11 12 13 14 15

Átviteli körök

ssthresh TCP Tahoe TCP Reno

4.33: TCP torlódási ablak evolúciója (Tahoe és Reno)¹

W

W/2

Ü tk ö zé si a b la k

Idő

4.34: Additív növekedés, multiplikatív csökkenés (AIMD) jelenség¹

Azonban, ha az UDP még igazságos is volna, akkor sem oldódna meg teljesen a sávszélesség megosztásának a problémája, hiszen vannak olyan TCP feletti alkalmazások, amelyek párhuzamos kapcsolatokat nyithatnak. Ilyen elven m˝uködnek a Web böngész˝ok is. Példaként vegyünk 9 kliens-szerver alkalmazást, amelyek mindegyike TCP felett kommunikál egy R sávszélesség˝u vonalon. Ha megnyílik egy 10. alkalmazás, akkor minden alkalmazás küldési sebessége lekorlátozódik R/10-re. De, ha egy új alkalmazás 11 párhuzamos TCP kapcsolatot használ, akkor az új alkalmazás egy igazságtalan allokációval él, ami nagyobb, mintR/2.

4.7.3 Explicit torlódás értesítés (ECN)

Ahogy azt a TCP bevezetésekor tárgyaltuk, egy megbízható protokollt helyezünk a megbízhatatlan IP-re. Mivel az IP nem ad explicit visszajelzést a TCP-nek a hálózati torlódásról, ezért ez az ˝o feladata erre következtetni a csomagvesztésekb˝ol. Azonban készült egy olyan kiegészítés az IP-hez és a TCP-hez, amellyel a hálózat explicit jelezheti a küld˝onek és a fogadónak, ha torlódás van.

Az IP csomag fejlécében a ToS mez˝ot (2 bit) használhatja a forgalomirányító a torlódás jelzésére.

Az IP csomag fejlécében a ToS mez˝ot (2 bit) használhatja a forgalomirányító a torlódás jelzésére.

In document Számítógép hálózatok programozóknak (Pldal 91-0)