logo

TCP újraküldés

A TCP újraküldés az elveszett vagy megsérült csomagok újraküldését jelenti a hálózaton keresztül. Itt az újraküldés egy olyan mechanizmus, amelyet olyan protokollok használnak, mint pl TCP megbízható kommunikáció biztosítására. Itt a megbízható kommunikáció azt jelenti, hogy a protokoll akkor is garantálja a csomag kézbesítését, ha az adatcsomag elveszett vagy megsérült.

java concat karakterláncok

A hálózatok megbízhatatlanok, és nem garantálják az elveszett vagy sérült csomagok késleltetését vagy újraküldését. Az a hálózat, amely a sérült vagy elveszett csomagok nyugtázását és újraküldését használja, megbízhatóságot kínál.

Újraadási mechanizmus

Itt az újraküldés azt jelenti, hogy az adatcsomagok elvesztek, ami a nyugtázás hiányához vezet. A nyugtázásnak ez a hiánya időzítőt vált ki, ami az adatcsomagok újraküldéséhez vezet. Itt az időzítő azt jelenti, hogy ha az időzítő lejárta előtt nem érkezik nyugtázás, akkor az adatcsomag újraküldésre kerül.

Tekintsük az újraadás következő forgatókönyveit.

1. forgatókönyv: Amikor az adatcsomag elveszett vagy hibás.

TCP újraküldés

Ebben a forgatókönyvben a csomag elküldésre kerül a fogadónak, de az időkorláton belül nem érkezik nyugtázás. Amikor az időkorlát lejár, a csomag újra elküldésre kerül. A csomag újraküldésekor a nyugtázás érkezik. A nyugtázás megérkezése után az újraküldés nem történik meg.

2. forgatókönyv: Amikor a csomag érkezett, de a nyugtázás elveszett.

TCP újraküldés

Ebben a forgatókönyvben a csomagot a másik oldalon fogadják, de a nyugtázás elveszik, azaz a küldő oldalon nem érkezik meg az ACK. Az időkorlát lejárta után a csomag újraküldésre kerül. A másik oldalon két példány található a csomagokból; bár a csomag megfelelően érkezett, a nyugtázás nem érkezik meg, így a küldő újraküldi a csomagot. Ebben az esetben az újraküldés elkerülhető lett volna, de az ACK elvesztése miatt a csomag újraküldésre kerül.

3. forgatókönyv: Amikor bekövetkezik a korai időtúllépés.

TCP újraküldés

Ebben a forgatókönyvben a csomag elküldésre kerül, de a nyugtázás késése vagy az időtúllépés miatt a tényleges időtúllépés előtt a csomag újraküldésre kerül. Ebben az esetben a csomag szükségtelenül újra el lett küldve a nyugtázás késése miatt, vagy az időtúllépés a tényleges időtúllépésnél korábban lett beállítva.

A fenti forgatókönyvekben az első forgatókönyv nem kerülhető el, de a másik két forgatókönyv elkerülhető. Lássuk, hogyan kerülhetjük el ezeket a helyzeteket.

Meddig várjon a feladó?

A feladó beállítja az ACK időkorlátját. Az időkorlát kétféle lehet:

    Túl rövid:Ha az időtúllépési idő túl rövid, az újraküldések kárba vesznek.Túl hosszú:Ha az időtúllépési időszak túl hosszú, akkor a csomag elvesztésekor túlzott késés következik be.

A fenti két helyzet leküzdése érdekében TCP beállítja az időtúllépést az RTT (round trip time) függvényében, ahol az oda-vissza út az az idő, amely ahhoz szükséges, hogy a csomag eljusson a forrástól a célig, majd ismét visszatérjen.

Hogyan szerezhetjük meg az RTT-t?

Az RTT a hálózat jellemzőitől függően változhat, azaz ha a hálózat túlterhelt, az azt jelenti, hogy az RTT nagyon magas. Megbecsülhetjük az RTT-t az ACK-ek egyszerű megfigyelésével.

Lássuk, hogyan mérhetjük az RTT-t.

Használjuk a eredeti algoritmus az RTT mérésére.

1. lépés: Először megmérjük a MintaRTT minden szegmenshez vagy ACK párhoz. Amikor a feladó elküldi a csomagot, akkor ismerjük az időzítőt, amelynél a csomag elküldésre került, és azt is, hogy milyen időzítővel érkezik a nyugtázás. Számítsa ki a kettő közötti időt, és ez lesz a MintaRTT .

string of int

2. lépés: Nem csak egy mintát veszünk. Folytatjuk a különböző minták vételét és kiszámítjuk ezeknek a mintáknak a súlyozott átlagát, és ez lesz az EstRTT (Estimated RTT).

ahol α+ β = 1

α 0,8 és 0,9 között van

β 0,1 és 0,2 között van

3. lépés: Az időtúllépés beállítása EstRTT alapján történik.

időtúllépés = 2 * EstRTT.

Az időtúllépés a becsült RTT kétszeresére van beállítva. Így kerül kiszámításra a tényleges időtúllépési tényező.

Hiba ebben a megközelítésben

Hiba van az eredeti algoritmusban. Tekintsünk két forgatókönyvet.

mylivericket

1. forgatókönyv.

TCP újraküldés

A fenti diagram azt mutatja, hogy a feladó küldi el az adatokat, ami állítólag eredeti átvitel. Az időkorláton belül nem érkezik visszaigazolás. Tehát a feladó újraküldi az adatokat. Az adatok újraküldése után érkezik a nyugtázás. Tételezzük fel, hogy a nyugtázás az eredeti átvitelhez érkezik, nem az újraküldéshez. Mivel megkapjuk az eredeti átvitel visszaigazolását, így MintaRTT az eredeti átvitel időpontja és a nyugtázás beérkezésének időpontja között kerül kiszámításra. De valójában a MintaRTT az újraküldés és a nyugtázás időpontja között kellett volna lennie.

2. forgatókönyv.

TCP újraküldés

A fenti diagramon látható, hogy a feladó az eredeti adatcsomagot küldi, amelyre a visszaigazolást is megkapjuk. De a visszaigazolás az adatok újraküldése után érkezik meg. Ha feltételezzük, hogy a nyugtázás az újraküldéshez tartozik, akkor MintaRTT az újraküldés és a nyugtázás időpontja között kerül kiszámításra.

A fenti két forgatókönyv esetében kétértelmű, hogy nem tudni, hogy a nyugtázás az eredeti átvitelre vagy az újraküldésre vonatkozik-e.

A fenti algoritmus következtetése.

  • Itt az ACK nem az átvitel nyugtázását jelenti, hanem valójában az adatok fogadását.
  • Ha figyelembe vesszük az első forgatókönyvet, akkor az újraküldés az elveszett csomagra történik. Ebben az esetben azt feltételezzük, hogy az ACK az eredeti átvitelhez tartozik, ami miatt a SampleRTT nagyon nagynak tűnik.
  • Ha figyelembe vesszük a második forgatókönyvet, akkor két azonos csomag kerül elküldésre, így ebben az esetben kettősség lép fel. Ebben az esetben azt feltételezzük, hogy az ACK az újraküldéshez tartozik, ami miatt a SampleRTT nagyon kicsi lesz.

A fenti problémák megoldására egyszerű megoldást ad a Karn/Partridge algoritmus. Ez az algoritmus egy egyszerű megoldást adott, amely összegyűjti az egyszerre elküldött mintákat, és nem veszi figyelembe a mintákat az újraküldés időpontjában a becsült RTT kiszámításához.

Karn/Partridge algoritmus

A fenti két forgatókönyvben újraküldés történik, és a minta RTT-t vettük figyelembe. Ez az algoritmus azonban nem veszi figyelembe a minta RTT-t az újraküldés során. Amióta az újraadás megtörtént, ami azt jelenti, hogy ebben az oda-vissza időben történik valami, vagy torlódás léphet fel a hálózatban. A probléma megoldása érdekében ez az algoritmus megduplázza az időtúllépést minden újraküldés után. Ezt az algoritmust a TCP hálózatban valósítják meg.

Korlátozás

Nem veszi figyelembe az RTT eltérését.

Java kód példák
    Ha a szórás kicsi, az EstimatedRTT pontosnak bizonyul. Ha a szórás nagy, az EstimatedRTT nem pontos.

A fenti korlátozás leküzdésére kifejlesztették a Jacobson/Karels algoritmust, amely bevezeti a varianciatényezőt az RTT-be.

Jacobson/Karels algoritmus

Ezt az algoritmust a korlátozások leküzdésére fejlesztették ki Karn/Partridge algoritmus. Kiszámítja a SampleRTT és az EstimatedRTT közötti különbséget, és a különbség alapján növeli az RTT-t.

Az átlagos RTT számításai

  • Először kiszámítjuk a különbségi tényezőt.

Diff = SampleRTT - EstimatedRTT

  • Most kiszámítjuk az EstimatedRTT-t, amelyet ugyanúgy számítunk ki, mint fent.

EstRTT = EstRTT + (δ*Különbség)

  • Most kiszámítjuk a különbségi tényező átlagát.

Fejl. = Fejl. + δ ( |Különbség| - Fejl.)

Itt a Dev egy eltérési tényező, a δ pedig egy 0 és 1 közötti tényező Dev a -tól való eltérés becslése EstRTT .

  • Figyelembe vesszük az eltérést az időtúllépési érték kiszámításakor.
Időtúllépés = µ * EstRTT + ɸ * Fejl

Ahol, µ =1 és ɸ =4

konvertáljon egy java objektumot json-ba

Gyors újraküldés

Az időkorláton alapuló újraküldési stratégia nem hatékony. A TCP egy csúszóablakos protokoll, így minden alkalommal, amikor az újraküldés megtörténik, az elveszett csomagtól kezdi el küldeni.

TCP újraküldés

Tegyük fel, hogy továbbítom a 0, 1, 2 és 3 csomagokat. Mivel a 0. és az 1. csomag a másik oldalon érkezik, a 2. csomag elveszett a hálózatban. Megkaptam a 0. és az 1. csomag nyugtáját, ezért küldök még két csomagot, azaz a 4. és az 5. csomagot. A 3., 4. és 5. csomag elküldésekor az 1. csomag nyugtáját kapom TCP nyugtázásként. kumulatívak, tehát a sorrendben kapott csomagig nyugtázza. Nem kaptam meg a 2., 3., 4. és 5. csomag nyugtázását az időtúllépési időn belül, ezért újraküldöm a 2., 3., 4. és 5. csomagokat. Mivel a 2. csomag elveszett, de más csomagok, azaz a 3., 4. ,5 vétele a másik oldalon történik, az időtúllépési mechanizmus miatt továbbra is újraküldik.

Hogyan lehet megszüntetni ezt az időtúllépési hatástalanságot?

A jobb megoldás tolóablak alatt:

Tegyük fel, hogy n csomag elveszett, de az n+1, n+2 és így tovább csomagok megérkeztek. A vevő folyamatosan fogadja a csomagokat és küldi az ACK csomagokat, mondván, hogy a vevő még mindig az n-edik csomagra vár. A vevő ismételt vagy ismétlődő nyugtákat küld. A fenti esetben az 1. csomag ACK-jét háromszor küldjük el, mivel a 2. csomag elveszett. Ez a duplikált ACK csomag azt jelzi, hogy az n-edik csomag hiányzik, de a későbbi csomagok vétele megtörtént.

A fenti helyzet a következő módokon oldható meg:

  • A feladó a „duplikált ACK-t” az n-edik csomag elvesztésére utaló korai utalásként veheti fel, hogy a feladó a lehető leghamarabb elvégezhesse az újraküldést, azaz a küldő ne várjon az időtúllépésig.
  • A küldő gyors átviteli stratégiát valósíthat meg TCP-ben. A gyors átviteli stratégiában a küldőnek a háromszoros ismétlődő ACK-t triggernek kell tekintenie, és újra kell küldenie.

A TCP három ismétlődő ACK-t használ triggerként, majd újraküldést hajt végre. A fenti esetben, amikor az 1. csomag három ACK-je érkezik, akkor a feladónak el kell küldenie az elveszett csomagot, azaz a 2. csomagot anélkül, hogy megvárná az időtúllépési periódus beálltát.