TCP hálózat működése '12

• Az Internet egy csomagkapcsolt hálózat --> csak a végpontokról van infó, a köztes hálózatról nincs.
• Ha kettőnél több számítógépközpontot kötünk össze, akkor a sávszélesség felosztása problémákba ütközhet. Ennek megoldására és a csomagok célba juttatására született meg a TCP (transmission control protocol - átvitelvezérlő protokoll).

TCP hálózat alapjai

• Alapvető adatátvitel: Egy oktettekből álló folytonos adatfolyam átvitelét látja el, úgy hogy a bájtokat szegmensekre bontja szét.
• Megbízhatóság: A TCP dolga az elveszett, megsérült, megduplázódott, nem helyes sorrendben érkezett csomagok érzékelése, és ezek kiküszöbölése. Ezt úgy éri el, hogy minden egyes kiküldött oktetthez tartozik egy sorszám, és a fogadó oldalnak pozitív megerősítést kell adjon a megérkezett oktettekről. Ha egy bizonyos időn belül nem jön pozitív megerősítés, akkor az adatot újraküldi a küldő oldal. Mindamellet ez a sorszám arra is jó, hogy a fogadó oldal a nem helyes sorrendben jött adatokat helyesen sorba tudja rendezni és észlelje a duplázódásokat. Az adatok sérülésének észrevételére pedig ellenörzőösszeget használ.
• Adatfolyam vezérlés: A TCP egy úgynevezett torlódási ablakot (congestion window - cwnd) használ az adatfolyamvezérlésre.
• Multiplexitás: Mint említettük a TCP folyamat-folyamat közti kommunikációra szolgál, azonban egy hoszton több folyamat is futhat, és több is akarhat párhuzamosan kommunikálni, így a TCP a hoszton ún. portokat használ. A kapcsolat kommunikációnál használt hálózati címe, és a TCP port együtt adják az ún. socket-et és a socketekből álló egyértelmű párokkal azonosítjuk a kapcsolatot. Minden egyes hoszt saját feladata, hogy a feladatok számára portokat biztosítson egy hozzárendeléssel(bind()).
• Kapcsolatok: Lévén a kommunikációt egy nem feltétlenül megbízható alapokra helyezett hálózaton kell lefolytatni, a kapcsolat létrehozásához kézfogási (Handshake) mechanizmusokat kell beépíteni.
• Megelőző biztonság: A TCP szükség esetén gondoskodik helyes default értékek használatáról, és beállításáról. (Pl. kapcsolódó kliens esetén automatikusan kap portot, ha nem adunk meg külön ablakméretet, akkor az OS TCP kezelő része ad meg ilyet, stb.)

Hardver

• Routereknél default kézbesítés: best effort (legjobb tudás szerint) és SORBAN. Spec esetekben (diffuser mód) prioritás feladó, címzett vagy típus alapján.
• A routerek hardveres felépítése a következő: a routernek vannak bemenetei és kimenetei (tipikusan GBPS sávszélességű kapcsolaton).
• A bemenetre érkező csomagok várakozási sorba (queue) kerülnek.
• Maga a router egy sokprocessoros számítógép, ami elvégzi a csomagok továbbítását a következő router (vagy a célgép) felé.
• A továbbítás úgy történik, hogy a router a vele kapcsolatban álló routerektől begyűjt egy irányítási táblázatot (routing table), amely a router körüli közvetlen hálózat topológiájáról tartalmaz információkat és ami alapján a router meg tudja határozni, hogy az adott csomagot melyik kimenetén kell továbbítania.

A TCP protokoll

• Ha egy csomag célbaért, akkor a célgép nyugtázó csomagot (acknowledgement packet - ACK) küld a küldő gép felé. Ennek mérete kicsi, csak fejléc és minimális tartalom (következő küldendő csomag sorszáma). Ha nem érkezik meg meghatározott időn belül, vagy az ACK-k érkezésekor egy sorszám kimarad, újra kell küldeni a hiányzó csomagot.
• Roundtrip time (RTT) - ami alatt a kiküldött csomag ACK-ja visszaérkezik a küldő géphez (teljes körbemenet ideje). Mérése: több csomag küldéséból az utolsó kettő átlaga. Szórás: az átlagos RTT és az aktuálisan beérkezett különbsége. Szofisztikáltabb módszer $\sigma$ a szórás, $T_i$ a legutolsó csomag RTT-je, $\bar{T}$ az átlagos RTT, '-vel a frissített értékeket jelöltem:

$\sigma' = \frac{2}{3} \sigma + \frac{1}{3} \left( T_i - \bar{T} \right)$

$\bar{T}' = \frac{2}{3}T + \frac{1}{3}T_i$

• Csomagvesztés: ha az átlagos RTT után $2\sigma$-val sem jön válasz. Ehhez legalább három sikeres csomagküldés szükséges (a szórás becsléséhez). Mivel a csomagvesztés manapság kicsi (minden 1000-10000-edik csomag veszik csak el), az ACK-k ötös-tízes csomagokban érkeznek, csak azt kell újraküldeni, ami ebből kimarad.

• Csomagvesztés következhet be, ha
  • TTL elfogy
  • Checksum nem stimmel
  • betelik a buffer és nem fér be

Sávszél-tesztelés

Vagy másnéven Slow Start. Sávszél-tesztelés alatt a sávszélesség exponenciálisan növekszik (1 RTT-nyi idő alatt több csomagot is kiküld a rendszer). Ezt addig folytatja, amíg el nem veszik egy csomag. Ekkor a sávszélességet a csomagvesztés előtti utolsó érték felére veszi vissza, majd exponenciális helyett lineáris sávszélesség-növelés kezdődik (és a rendszer átvált torlódás-elkerülő üzemmódba). Ezen módszer segítségével logaritmikus idő alatt megtalálja a rendszer az általa elérhető sávszélességet. A sávszélesség aktuális értéke: $\frac{P}{\bar{T}}w$, ahol P a csomagméret, $\bar{T}$ a roundtrip time, w pedig a kiküldött csomagok száma.

Torlódás-kezelés

Ebben a módban a cwnd-t ACK beérkezése esetén a cwnd aktuális értékének reciprokával megnöveli, és ennek az értéknek mindig az egészrészét tartja kiküldve. Csomagvesztés esetén a cwnd feleződik. (A rendszerben tartott csomagok csökkentését úgy éri el, hogy beérkező ACK esetén sem küld ki új csomagot, amíg több van a rendszerben, mint a cwnd mérete.)

Röviden a cwnd változása egyenletekkel:

$w' = \frac{w}{2}$ csomagvesztés esetén.

$w' = w + \frac{1}{w}$ sikeres csomagkézbesítés esetén.

Makroszkópikus egyenlet a cwnd időbeli változására $\frac{dw}{dt} = \frac{1}{T_{RTT}}$.

A TCP fűrészfogasan fogja követni az elérhető sávszélesség változását.

Ha azonban a sávszélesség nagyon lecsökken, $cwnd < 1$, és $T_{RTT}$ alatt csak egy csomagot (vagy annyit sem) tudok kiküldeni, akkor ez az algoritmus nem működik.

A Karn-féle algoritmus

• Ha a $cwnd < 1$, $T_{RTT}$ múlva küld csak csomagot.
• Ha az elveszett, akkor a következőt $2T_{RTT}$ múlva küldi.
• Folyamatosan duplázza a küldések közötti időt, egészen $32T_{RTT}$-ig.
• Ha ekkor is csomagvesztés lép fel, lehal a TCP.
• Amikor sikeresen kiküldött egy csomagot, visszatér torlódás-kezelő módba.

Egyszerű modell

A hálózatot egy black box-nak tekintjük, tehát a két pont között csak egy "link-et látunk":

d késleltetéssel, p csomagonkénti veszteségi rátával, C sávszélességgel és B buffer-mérettel.

Ez a modell hosszú idejű TCP kapcsolatok szimulálásához jó, mert beáll(hat) valamilyen stacionárius állapotra. (A gyors "burst"-ök nem érzékenyek pl a sávszélességre...)

Megjegyzés: Ezzel szemben a valódi kapcsolatokra inkább az jellemző, hogy vagy nagyon hosszú vagy nagyon rövid a kapcsolat - közepes hosszúak egyre kevesebben vannak ("elefántok és egerek").

$\frac{P}{C} = \tau_0$ időnként megy ki egy csomag (P csomagméret) - érdemes áttérni erre az időegységre, így az egyenletünk:

$\frac{dw}{d\tau} = \frac{1}{T_{RTT}} = \frac{1}{w}$ , $(w=T_{RTT})$ esetén. Ennek megoldása: $w(\tau) = \sqrt{w^2(0)+2\tau}$, tehát gyökösen nő w a csomagvesztés után (ill csomagvesztés után közvetlen kell egy kis idő a növekedés elkezdéséig, amíg visszaér az ACK).

A megoldásból kihozható ($\tau$-kra Poisson-eloszlást feltételezve), hogy az átlagos cnwd:

$<w^2>$ ~ $<\tau>p \approx 1$, tehát $<w>$ ~ $\frac{1}{\sqrt{p}}$, így:

$<w> \approx \frac{k}{\sqrt{p}}$, ahol $k \approx 1,53$ - ami univerzális a hálózatokra (dimenziós okokból kevésbé függ a hálózat tulajdonságaitól)

Ezek után felírható, hogy a TCP sávszélességnek az igénye: $X_{TCP} = \frac{P<w>}{T_{RTT}} = \frac{kP}{\sqrt{p}T_{RTT}}$

Ez történik p valószínűségű csomagvesztés esetén.

• Ha NINCS véletlen csomagvesztés (p=0), akkor az egyre nagyobb cnwd miatta a buffer betelik. Így nem random iteráció lesz, hanem mindig akkor veszik el a csomag, amikor $\tau = B$. (B a buffer mérete.) Csomagvesztéskor így mindig B/2-re áll be a cnwd. Tehát

$\frac{B}{2} = \frac{1}{2} \sqrt{\frac{B^2}{4}+2\tau}$, ahonnan a periódus ideje: $\tau = \frac{3B^2}{8}$

A csomagvesztésre felírható itt, hogy $p = \frac{1}{\tau}$ ~ $\frac{8}{3B^2}$, ahonnan $B$ ~ $\sqrt{\frac{3}{8p}}$. Ezeket felhasználva, megkaphatjuk cnwd várható értékét:

$<w> \approx \frac{3}{4} \sqrt{\frac{3}{8p}}$

A TCP hálózat, mint kaotikus rendszer

• Ha veszünk sok (~20) TCP-t, melyeknek a $cwnd$ trajektóriáit nézzük, akkor azt tapasztalhatjuk, hogy kis perturbációra igen érzékeny a rendszer: Ha perturbáció után vizsgáljuk az eredeti és a perturbált adatsort, akkor azt láthatjuk, hogy rövid időn (szinte) nem változik, viszont egy idő után erősen el fognak térni a rendszerek. Itt az eltávolodást Ljapunov-exponenssel lehet mérni...
• 2 db TCP viselkedését nézve azt tapasztaljuk, hogyha a 2 TCP $cwnd$-it egymás függvényében ábrázoljuk, akkor "különös attraktort" látunk - mely egy tört dimenziós fraktál (box-counting-gal mérhető pl.)
• Már egy TCP is tud kaotikus viselkedést mutatni (megfelelő paraméterezéssel)