Zusammenfassung

  • RFC 1144 ließ Kompressor und Dekompressor den vorigen IPv4/TCP-Header halten; Verbindungskennung und Deltas konnten vierzig Oktette durch wenige Link-Oktette darstellen.
  • Der Standardheader blieb erhalten: Vor dem Verlassen des engen Abschnitts stellte der Dekompressor das gewöhnliche IP-Paket wieder her.
  • Ein verlorenes Delta ließ die Erinnerungen auseinanderlaufen. Prüfsummenfehler, Toss-Zustand und ein unkomprimierter Neuaufbau gehörten deshalb zur Korrektheit.

Vierzig Oktette für einen Tastendruck

RFC 1144 betrachtete 1990 serielle Leitungen von 300 bis 19.200 bit/s. Der minimale IPv4/TCP-Header war vierzig Oktette lang. Ein Zeichen erzeugte ein 41-Oktett-Paket, sein Echo ein zweites. Die damalige Rechnung verlangte schon etwa 4.000 bit/s, um 82 Oktette innerhalb von 200 Millisekunden zu serialisieren.

Große Übertragungen verteilen die Fixkosten auf viel Nutzlast. Ein Dialog tut das nicht. Zudem kann ein bereits sendendes Großpaket das kurze Echo in der Warteschlange festhalten. Die Zielgröße war damit nicht nur Leitungseffizienz, sondern menschlich wahrnehmbare Antwortzeit.

Bedeutung wurde in Zustand verlegt

Van Jacobson erklärte die Felder nicht für überflüssig. Ihre Werte wiederholten sich jedoch innerhalb einer TCP-Verbindung. Adressen und Ports blieben stabil; Sequenz, Bestätigung, Fenster und IP Identification änderten sich oft nach erkennbaren Regeln.

Beide Linkenden speicherten den letzten Header aktiver Gespräche. Eine kleine CID wählte den Eintrag. UNCOMPRESSED_TCP setzte oder erneuerte den vollständigen Kontext. COMPRESSED_TCP enthielt danach Änderungsmaske, kompakte Differenzen und nicht sicher ableitbare Werte. Der Empfänger baute daraus vor der Weitergabe wieder den normalen IPv4/TCP-Header.

Die Kurzform blieb zwischen benachbarten Systemen. TCP-Endpunkte mussten die Optimierung eines Zwischenlinks weder erkennen noch unterstützen. Verschwunden war die Wiederholung auf diesem Draht, nicht das End-to-End-Format.

Verhalten war das Wörterbuch

Eine Sequenznummer steigt häufig um die zuletzt gesendete Datenmenge; ACK folgt empfangenen Bytes; IP Identification bewegt sich oft in kleinen Schritten. RFC 1144 codierte solche Deltas kurz und reservierte Spezialfälle für interaktive Echos und einseitigen Massentransfer.

Ebenso wichtig waren die Ausgänge: IP-Fragmente, SYN, FIN, RST, fehlendes ACK, geänderte Headerlänge, unerwartete Optionen und unregelmäßige Übergänge gingen unkomprimiert. Der Algorithmus war zuverlässig, weil er seinen Vorhersagebereich begrenzte.

Für die im RFC genannten Spuren lag der mittlere komprimierte Header bei ungefähr drei Oktetten. Das ist kein Versprechen für alle Netze. Entscheidend ist, dass zeitliche Regelmäßigkeit die Ersparnis schuf, nicht ein angeblich bedeutungsloser Teil des Protokolls.

Ein Verlust erzeugte zwei Vergangenheiten

Ein Delta funktioniert nur auf derselben Basis. Geht ein komprimierter Frame verloren, kann der Kompressor seinen gespeicherten Header bereits fortschreiben, während der Dekompressor zurückbleibt. Das nächste Delta rekonstruiert dann zwei verschiedene Pakete.

RFC 1144 nutzte TCPs vorhandene Kontrolle. Falsch rekonstruierte Sequenz- oder ACK-Werte ließen typischerweise die TCP-Prüfsumme scheitern. Der Dekompressor ging in den Toss-Zustand, verwarf weitere komprimierte Frames und wartete auf einen vollständigen Kontext. TCP-Retransmits und Duplicate ACKs halfen, diese Erneuerung ohne eigenen Reparaturdialog auszulösen.

Die Prüfsumme authentifiziert nicht und beseitigt nicht jedes Risiko. Sie begrenzt aber eine falsche Annahme. Sobald gesendete Evidenz durch gemeinsame Erinnerung ersetzt wird, braucht diese Erinnerung ein erkennbares Ende und einen definierten Neustart.

Spätere Protokolle machten Kontext sichtbar

RFC 2507 verallgemeinerte 1999 das Modell: Ein Full Header errichtet Kontext, folgende Pakete verweisen darauf und liefern Änderungen. Generationen und periodische Updates schützten Nicht-TCP-Flüsse; Header Requests, No-Delta-Reparatur und Reordering-Regeln erweiterten TCP.

Kontext ist endlich. Bei vielen Flüssen kann CID thrashing Einträge verdrängen, bevor sie Nutzen bringen; vollständige Header kehren ständig zurück. Welche Gespräche Erinnerung behalten, wird zur Ressourcenentscheidung.

RFC 4413 ordnete Felder später nach tatsächlichem Verhalten: statisch, ableitbar, vorhersagbar oder unregelmäßig. Das ROHC-Framework und sein TCP-Profil beschrieben Initialisierung, Zustände, Feedback, Refresh und CRC für verlust- und reorderanfällige Links genauer. Sie sind keine drahtkompatible Fortsetzung von RFC 1144, sondern eine spätere Antwort auf dieselbe Schuld gemeinsamer Erinnerung.

Quellen und Grenzen

Der geschlossene Satz umfasst RFC 1144, RFC 2507, RFC 4413, RFC 4995 und RFC 6846. Er belegt Mechanismen und veröffentlichte Beispiele, nicht heutige Verbreitung, Herstellerdefaults, universellen Gewinn oder stets drei Oktette.