TCP protokoll működése

 ( cassis | 2006. május 30., kedd - 14:24 )

Sziasztok!

Az Ethernet TCP fejét vizsgálgattam részletesen, és a WIN mértettel kapcsolatosan merültek fel kérdéseim, melyeket megosztanék veletek.

A következő vizsgálatot végeztem el protkoll analizátrorral:

Szerverrel kapcsolatot létesített egy kliens.

A kézfogás:
1. kliens kezdeményez (SYN bit beáll stb) TCP fejlécében WIN méret 8192 byte lett.
2. server válasza erre egy ACK, fejlécben WIN 17520 byte lett (ez éppen 12 szegmens méret).
3. kliens befejezi a kézfogást a saját ablakát átállítja 8760 byte ra. (6 szegmensméret)

Adatátvitel (kliens küld)
(5 byte -os adattal, PSH = 1 re állításával (ez annyit tesz: vevő ne várja ablakának megteltét, azonnal adja át a pufferbe beérkező adatokat az alkalmazásnak):
1. kliens adatot küld 5 byte ot. WIN 8760 byte maradt.
2. Server nyugtájában WIN 17515 byte lett. (=17520-5) (szerintem azért, mert a TCP kernel szinten fut, és a nyugta magasabb prioritású mint a szerver recv metódusa, amely a vezérlést csak a nyugtázás után kapja meg, így nyugtáig a vételi puffer még nem ürült ki)
3. szerver feldolgozta a beérkező 5 byte ot és válaszol a kliensnek szintén 5 byte al. WIN=17515 byte maradt. (nem tudom milyért mivel már a vételi puffer kiürült visszaállhatott volna 17520 ra, de nem tette. Talán azért, mert adási puffere ennyit csökkent /épp 5 öt/ és egyébként adási és vételpuffer együtt mozog. Most feltételelezem, hogy a TCP keretfejlécben a WIN ablakban a vételi puffer kerül feltüntetésre.)
4. kliens nyugtázott, vételi puffere még nincs kiüritve WIN=8755 byte (8760-5)

Kapcsolat zárása:
1. Kliens meghívja a CloseSocket fv. -t. Ebben a keretben WIN=8755 byte volt.
2. szerver nyugtája erre: WIN=17515 byte
3. szerver küldi a FIN jelket. Ebben a keretben WIN=17515 byte
4. kliens nyugtázza FIN -t. ebben a keretben WIN=8755 byte

KÉRDÉSEK:
1. Tud valaki segíteni abban, hogy a kezdeti WIN értékek mitől függenek?
2. Hol látni azt, hogy az adó és a vevő megeggyezik egymással a WIN méretben? (akár a fenti példában is, már a kézfogáskor 17520 kontra 8760, igaz a kliens valamit mégis állított 8192 ŕ 8760. Az már csak hab a tortán, hogy miként kezdhette 8192 vel, és mi tett lehetővé, hogy feljebb tudjon menni? Nem max. al kezd?)
3. Ha több TCP keret is elküldésre kerül mitől függ az, hogy mikor nyugtáz a vevő? (nem a saját vételi pufferének megteltekor ugye?)
5. A kapcsolat bontásakor milyért nem áll vissza a bufferméret, mikor már azok kiürültek??? Egy új kapcsolatnál innen indulunk? (Ezt próbalhattam volna, de sajna nem tettem)
6. miként lehett az, hogy a kapcsolat kezdeményezésekor a kliens WIN je 8192 byte. Ez nem egész számú többszöröse szegmens max méretének (1460 byte összahangban az ETHERNET II MTU val) így milyen TCP keretek képzelhetőek el?

Tudna valaki egy kicsit elmélyedni a kérdésben?

ÜDV
:
Cassis

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

3. Ez amt te mondasz ez az ablakméret. Az ablak mérete azt jelenti, hogy hány csomagot visz át mielőtt nyugtáz. Az ablak méretében a két fél közösen egyezik meg általában, ha jóltudom a kapcsolat sebességének a függvényében. Ha a vonal terhelté válik akkor váltanak kissebb ablak méretre. Tehát az ablak mérete dinamikus.
Tegyük fel, hogy az ablak mérete 10. Akkor minden 10. csomag után a vevő küld egy nyugtát, hogy megkapta a 10-et is jöhet a 11.
Én így tudom, ha nem jó majd kijavítják az okosak :)