Legjobb válasz
Az RST / ACK a TCP-munkamenet befejezésére szolgál. A csomag ismeri a stream előző csomagjának átvételét, majd lezárja ugyanezt a munkamenetet egy RST (Reset) csomaggal, amelyet a legvégére küldünk, hogy tudassa vele, hogy a kapcsolat zárva van. Ez teljesen normális viselkedés (bár a legtöbb esetben nem \_előnyös\_ viselkedés), mivel a TCP munkamenet létrehozása és lebontása is többlépcsős folyamat, de a FIN csomag kecsesebb lezárást jelentene.
Válasz
Úgy fogom fel, hogy az ACK-ra gondol az Átviteli vezérlő protokollban (TCP). A TCP fontos, tulajdonképpen az egyik legfontosabb jellemzője az adatok helyességének biztosításának képessége és a kapcsolat állapotának fenntartása. Mindkét célt teljesíti az Acknowledgement (ACK) rendszer.
Figyelem: A következő bejegyzés rengeteg egyszerűsítéssel jár. Ennek alapja a 9 évvel ezelőtti előadásjegyzeteim, valamint az RFC 793 gyors átolvasása. Kérjük, javítson ki, ha tévedek.
A TCP háromutas kézfogási folyamata a következőkből áll:
- A kezdeményező SYN-t küld a címzettnek.
- A címzett visszaküldi a SYN / ACK-t a kezdeményezőnek.
- A kezdeményező ACK .
Az ACK-t is szokták használni ack csomagok, amelyeket megfelelően fogadtak. Ez lehetővé teszi, hogy sok csomag egyszerre „repüljön”. Az ACK-t arra használjuk, hogy megerősítsük, hogy egy csomag érkezett, és a feladónak (az ACK-t fogadó személynek) el kell kezdenie az ACK-számban megjelenített adatok küldését.
Ha nem érkezik meg ACK, akkor az adatok idegesítés után neheztel. Ez az időtúllépés értéke beállítható az operációs rendszerben. Ennek ellenére meglehetősen a motorháztető alatt van, és befolyásolja az A LOT hálózati minőségét, ezért csak akkor javasoljuk, ha valóban konkrét oka van rá.
Sok egyszerűsítés történt. Remélem, mégis megkapja az általános elképzelést.
(A képek részben az én tulajdonomban vannak. Ikon az MS Visio stenciltől. Én alkottam a képet.)
Megjegyzés: Nem ez az első válasz erre a „közeli” kérdésre. Ha hasznosnak találja a válaszomat, kérem, szavazzon inkább Mr. Wardra (aki időben válaszolt).