Zusammenfassung

  • Ein kumulatives ACK verspricht, dass alle Bytes vor seiner Nummer eingetroffen sind. Eine frühe Lücke hält diese Grenze fest, selbst wenn spätere Segmente bereits warten.
  • SACK meldet nach Aushandlung die Grenzen nicht zusammenhängender Blöcke. Die Bedeutung des normalen ACKs und die Entscheidung über Wiederholungen bleiben unverändert.
  • Der Bericht ist klein und widerruflich. Der Sender behält seine Daten, folgt der Überlastungsregel und wartet auf kumulative Bestätigung, bevor er seine Verpflichtung beendet.

Sieben Ankünfte hinter einer einzigen Lücke

Der Empfänger erwartet Byte 5000. Dieses Segment fehlt, die sieben folgenden kommen an und bilden den Bereich 5500 bis 9000. Die ACK-Nummer bleibt 5000. Sie behauptet nicht, dass dahinter nichts liege; sie verweigert nur eine lückenlose Bestätigung.

Für den zuverlässigen Strom ist das genau richtig. Für die Reparatur ist die Zahl mehrdeutig. Der Sender weiß nicht, ob nur ein Segment fehlt oder weitere Daten verschwunden sind. Alles erneut zu senden verschwendet Kapazität. Pro Umlaufzeit jeweils nur die nächste Lücke zu entdecken, bestraft lange Pfade.

RFC 793 definierte ACK X als Bestätigung aller Oktette unterhalb von X und als Hinweis auf das nächste erwartete Byte. Diese starke Zusage erlaubt später das Freigeben von Puffern. Sie kann aber keine teilweise vorhandenen Daten über eine Lücke hinweg zertifizieren.

Ein RFC ohne gemeinsame Implementierung

RFC 1072 schlug 1988 zwei Optionen vor. SACK-Permitted im SYN sollte die Fähigkeit aushandeln; danach konnte der Empfänger nicht zusammenhängende, bereits gepufferte Blöcke melden. Unbekannte Optionen ließen den kumulativen Grundmechanismus bestehen.

Die damalige Form wurde nicht im Internet eingeführt. RFC 2018 nennt Uneinigkeit über das Zusammenspiel mit Window Scaling. Ein veröffentlichter Entwurf war damit noch keine betriebliche Übereinstimmung. Router und Hosts wurden nicht durch das Datum des Dokuments kompatibel.

Die Fassung von 1996 behielt die SYN-Aushandlung und verwendete vollständige 32-Bit-Grenzen. Links steht das erste vorhandene Byte, rechts die Nummer unmittelbar nach dem letzten. ACK 5000 kann deshalb neben SACK [5500, 9000) stehen. Das eine schließt den durchgehenden Bereich, das andere beschreibt die Insel dahinter.

Eine begrenzte Karte der Empfangswarteschlange

Für TCP-Optionen bleiben vierzig Byte. SACK benötigt zwei Byte für Typ und Länge sowie acht je Block. Allein passen höchstens vier Blöcke hinein; zusammen mit Zeitstempeln meist drei. Eine stark zerteilte Warteschlange enthält mehr Zustand, als ein ACK übertragen kann.

Darum steht der vom neuesten Segment veränderte Block zuerst. Frühere Blöcke werden wiederholt, weil auch ACKs verloren gehen. Der Sender vereinigt mehrere kleine Berichte zu einem eigenen Bild.

Das gemeinsame Format legt keine Speicherverwaltung offen und schreibt keine interne Datenstruktur vor. Es normiert nur zwei Sequenzgrenzen. Unterschiedliche Systeme können kooperieren, ohne ihre gesamte Ausführung zu vereinheitlichen.

Ein Hinweis ist keine endgültige Quittung

SACK ist laut RFC 2018 advisory. Der Empfänger darf zuvor gemeldete Daten später verwerfen; das heißt reneging. Der Sender kann einen solchen Bereich bei gewöhnlicher Wiederherstellung überspringen, darf seine Kopie jedoch erst löschen, wenn das kumulative ACK darüber hinausgeht.

Nach einem Timeout muss er frühere SACK-Markierungen möglicherweise verwerfen und wieder an der linken Kante sichern. Der Rückfall trennt eine vorläufige Beobachtung von einem unwiderruflichen Empfangsnachweis.

Auch die Handlung bleibt lokal beim Sender. Er führt die Wiederholungswarteschlange, verbindet Blöcke und wählt das nächste Segment. RFC 6675 beschrieb später dafür ein senderseitiges Scoreboard und eine konservative Schätzung der noch im Netz befindlichen Bytes. Der Empfänger liefert Sicht, nicht Steuerung.

Genauere Information schafft kein größeres Senderecht

SACK ersetzt keine Überlastungsregel. RFC 2018 verlangt, die bestehenden Verfahren zu erhalten: Ein einzelnes ACK für umsortierte Daten beweist keinen Verlust, die Wiederherstellung bleibt begrenzt, und das Congestion Window muss auf passende Signale reagieren.

Damit liegt die Grenze zur Geschichte des Kollapses von 1986 offen. Überlastungssteuerung bestimmt, wie viel gesendet werden darf. SACK bestimmt genauer, welche Bytes diesen knappen Platz nutzen sollten. Eine bessere Schadenskarte verbreitert keinen Engpass.

D-SACK ergänzte im Jahr 2000 Berichte über Duplikate. Der Sender kann daraus Umsortierung, verlorene ACKs, Replikation oder einen zu frühen Timer vermuten. RFC 2883 schreibt keine einzige Reaktion vor und warnt, dass der Empfänger nicht unbedingt wahrheitsgemäß berichtet. Mehr Diagnose wurde nicht zu mehr Befehlsgewalt.

Quellen und Beweisgrenzen

Die kumulative Bedeutung steht in RFC 793, der frühe Vorschlag in RFC 1072, die überarbeitete Form in RFC 2018. RFC 2883 definiert D-SACK, RFC 5681 bewahrt die Überlastungsgrenze, RFC 6247 dokumentiert den historischen Status des alten Entwurfs und RFC 6675 die konservative Wiederherstellung.

Die Texte belegen Format, Pflichten und bekannte Grenzen. Sie beweisen weder einen weltweiten Einführungstag noch denselben Leistungsgewinn auf jedem Pfad. Ein SACK-Block lokalisiert den Verlust nicht und authentifiziert den Empfänger nicht.