ACK

Kurz: Ein Bestätigungsflag in TCP, das signalisiert, dass ein Paket (oder eine bestimmte Sequenznummer) erfolgreich empfangen wurde.

Genauer: ACK-Pakete sind die Grundlage für die Zuverlässigkeit von TCP: Bleibt eine erwartete Bestätigung aus, geht der Sender davon aus, dass das Paket verloren ging, und sendet es erneut. Das dritte Paket im Three-Way-Handshake ist ein reines ACK, das den Verbindungsaufbau abschließt.

Im Detail

Kumulative Bestätigung statt Paket-für-Paket-Quittung

Technisch ist ACK kein eigenständiges Paket, sondern ein einzelnes Flag-Bit im TCP-Header, das zusammen mit einer 32-Bit-Acknowledgment-Nummer gesendet wird. Diese Nummer sagt dem Sender exakt, welches Byte als Nächstes erwartet wird — nicht “Paket 5 kam an”, sondern “ich habe alles bis einschließlich Byte 4000 empfangen, schick mir Byte 4001”. Das erlaubt kumulative Bestätigungen: Kommen die Segmente mit den Bytes 1000–2000, 2000–3000 und 3000–4000 beim Empfänger an, reicht ein einziges ACK mit der Nummer 4001, um alle drei auf einmal zu bestätigen — es muss nicht für jedes einzelne Segment eine eigene Antwort verschickt werden. Das spart bei stabilen Verbindungen erheblich Overhead, hat aber einen Nachteil: Fehlt mittendrin ein Segment (z. B. Bytes 2000–3000 gehen verloren), kann der Empfänger nur bis zur letzten lückenlosen Stelle bestätigen (2001), selbst wenn die späteren Segmente schon angekommen sind. Moderne TCP-Implementierungen lösen das über die Erweiterung “Selective Acknowledgment” (SACK), die zusätzlich mitteilt, welche späteren Blöcke bereits vorliegen, damit der Sender nur die wirkliche Lücke erneut senden muss statt der kompletten restlichen Daten.

Timeout, Fast Retransmit und Duplicate ACKs

Bleibt eine erwartete Bestätigung länger als der Retransmission Timeout (RTO) aus, geht TCP von einem verlorenen Paket aus und sendet es erneut — der RTO wird dabei dynamisch an die gemessene Round-Trip-Time (RTT) angepasst, üblicherweise als gleitender Mittelwert plus ein Vielfaches der beobachteten Schwankung, damit das System sowohl in schnellen lokalen Netzen (RTT im Millisekundenbereich) als auch über hohe Latenz-Strecken (Satellitenverbindungen, interkontinentale Leitungen) sinnvoll reagiert und weder zu früh noch zu spät erneut sendet. Ein Sonderfall sind “Duplicate ACKs”: Kommt beim Empfänger ein Segment außer der Reihe an (z. B. Segment 3 fehlt, aber Segment 4 trifft ein), bestätigt der Empfänger weiterhin die letzte lückenlose Position — mehrfach mit derselben Nummer. Empfängt der Sender dreimal hintereinander dieselbe Bestätigungsnummer, interpretiert er das als starkes Signal für einen gezielten Paketverlust (nicht für allgemeine Überlastung) und leitet die Neuübertragung sofort ein (Fast Retransmit), statt auf den vollen Timeout zu warten — das beschleunigt die Fehlerkorrektur in der Praxis erheblich.

Rolle im Verbindungslebenszyklus

Im Three-Way-Handshake taucht ACK zweimal auf: einmal kombiniert mit SYN-ACK im zweiten Paket, einmal als reines ACK im dritten Paket, das die Verbindung offiziell in den Zustand “ESTABLISHED” versetzt. Auch der Verbindungsabbau läuft über ACKs ab (als Teil der FIN/ACK-Sequenz, bei der beide Seiten ihr Ende der Verbindung unabhängig voneinander schließen) — ACK begleitet also praktisch den gesamten Lebenszyklus einer TCP-Verbindung, nicht nur den Aufbau. Interessant ist, dass fast jedes TCP-Segment, das nach dem Handshake verschickt wird, gleichzeitig ACK-Flag gesetzt hat UND Nutzdaten trägt (“Piggybacking”) — reine, datenlose ACK-Pakete kommen vor allem dann vor, wenn eine Seite nur empfängt, aber selbst nichts zu senden hat.

Debugging in der Praxis

In Paketmitschnitten (z. B. mit Wireshark) sind auffällig viele Duplicate ACKs oder wiederholte Retransmissions ein direktes Signal für Paketverlust auf der Strecke — häufig verursacht durch überlastete Router, fehlerhafte Kabel oder ein instabiles WLAN. Ein sogenannter “ACK-Storm” (massenhaft ACKs in kurzer Zeit, oft ohne zugehörige Nutzdaten) kann außerdem ein Hinweis auf eine Fehlkonfiguration oder sogar einen Denial-of-Service-Versuch sein, bei dem gefälschte Pakete gegenseitige Bestätigungsschleifen zwischen zwei Systemen auslösen. Im Gegensatz dazu kennt UDP das ACK-Konzept gar nicht — wer Zuverlässigkeit auf UDP-Basis braucht (z. B. bei manchen Video-Streaming- oder Gaming-Protokollen), muss eine eigene, oft schlankere Bestätigungslogik auf Anwendungsebene selbst implementieren.

Siehe auch: SYN, SYN-ACK, Three-Way-Handshake