Ethernet hálózatban TCP nyugtázásról szeretnék kérdezni. Ismeri valaki ennek mélységeit?
Így szól a nyugtázásról írt rész:
Kérdéseim a következőek:
A fogadó fél mikor nyugtáz? Látszólag akkor, mikor az ablakméret nullára csökken. De szerintem ez nem törvényszerű. Milyen szabály van erre?
A küldő amikor küldi a visszamaradó 2 K -t honnan tudja a vevő, hogy nincs több fogadni valója és nyugtázhat?
Forrás el szeretne küldeni, 6 KB-nyi adatot a célállomásnak, ezért kapcsolatot kezdeményez vele.
A kapcsolat létrejön, majd a fogadó fél elküldi az ablakméretét (WIN=4096). Ezután a forrásállomás elküld 4 KB-nyi adatot, 1 KB-os szegmensekben.
A fogadó fél megkapja és nyugtázza a szegmenseket, majd értesíti a másik állomást, hogy ne küldjön többet, a puffere megtelt (ACK=4096, WIN=0).
A forrásalkalmazás elküld 2 KB adatot. Mivel az ablakméret 0, meg kell várnia, amíg a vevő feldolgozza a korábbi adatokat. Ha ezalatt új csomagot küld, azt a fogadó egyszerűen eldobja, és nem küld róla nyugtát (Feladó blokkolva).
Amint a vevő feldolgozta az adatok egy részét, értesítést küld a forrásnak egy új ablakmérettel (ACK=4096, WIN=2048). Ezután újra megkezdődhet az adatátvitel.
A küldő továbbítja a maradék 2 KB adatot, majd várja a nyugtát.
Vevő nyugtázza a beérkezett adatokat és elküldi az aktuális ablakméretét (ACK=6144, WIN=1024). Miután a küldő állomás megkapja a nyugtát, kezdeményezi a kapcsolat lezárását, mivel nincs több küldésre váró adata.
válasza:Én ezt sokkal egyszerűbben tanultam.
Feladó küld (most egységjelölés nélkül) 1 adatot.
A vevő ha megkapta azt az 1 adatot, akkor küldi róla a nyugtát, hogy 1 adatot kapott.
Utána feladó küld 2-t, ha azt is megkapja, akkor visszaküldi a nyugtát 2-ről, hogy megkapta.
Utána feladó küld 3-at, 4-et, 5-öt, a vevő folyamatosan küldi vissza a nyugtát, hogy megkapja ezeket.
Küld feladó 6-ot, a vevő meg nem kap meg csak 5-öt, amiről visszaküldi a nyugtát, ami nem stimmel a feladónál, így visszavált 5-re, mert annyi még biztosan átment.
Így működik a torrent is. Ezért van az, hogy ha elindítasz egy letöltést, nem egyből maxon jön, hanem szakaszosan növekszik a letöltés sebessége, mert ablakozással meghatározza a maximális veszteségmentes adattovábbítási sebességet.
válasza:Képzeld ezt úgy, hogy van 2 ember, téglákat pakolnak:
"A" ember felvesz 1 téglát, elvisz 1 téglát "B"-nek, "B" elveszi tőle
"A" felvesz 2 téglát, elvisz 2 téglát "B"-nek, "B" elveszi tőle
"A" felvesz 3 téglát, elvisz 3 téglát "B"-nek, "B" elvesz tőle 3-at, de 1-et elejt, ezzel küld egy jelzést "A"-nak, hogy 3-at már nem bír el
Nem túl pontos a példa, de így lehet a legjobban értelmezni.
Ha "A"-nál adódik hiba, akkor azt "A" fogja tudni, ha "B"-nél adódik hiba, azt "B" fogja tudni, és az alapján küldi a további adatot, vagy a nyugtát.
Köszönöm a válaszokat.
Nem írtam a kérdésben, de a mellékelt magyarázatot a magyar wikipédiából másoltam be.
A folyamatot lényegében én is így tudtam, csak azt veszem észre, hogy bármely interneten fellelhető magyarázat lazán kezeli azt, hogy pontosan mikor dönt a a vevő a nyugta küldéséről. Ráadásul van ott egy kép is a wikipédia oldalán, ami aztán csak némileg van szinkronnal a magyarázattal.
Valóban van az általad említett visszaigazolásos technika.
voip.netlab.uky.edu/~fei/teaching/cs571/slides/15.tcpreno.pdf
De sajnos nekem az ACK küldésének időzítése egyikből sem derül ki.
A link hosszú lenne, de ha valaki meg akarja keresni ez a címe:
Transmission Control Protocol
válasza:Jó lenne tudni, hogy mi lenne a cél a kérdéssel, mert így általánosságban nehéz nyilatkozni a dologról, nem sok ember van itt, aki ennyire ért hozzá.
G.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!