Zusammenfassung

  • RFC 817 trennte die öffentlich spezifizierte Protokollschicht vom lokal ausgeführten Softwaremodul. Der Netzvertrag blieb stabil; die interne Schnittlinie durfte IP und TCP entlang von Demultiplexing, Timern und Zustandsbesitz queren.
  • Modulare Isolation schafft Austauschbarkeit, kann aber zusätzliche Pakete, Kopien und Kontextwechsel verursachen. Begrenzte Information über eine Schichtgrenze durfte Arbeit bündeln, ohne die Zuständigkeit für das Protokoll zu verschieben.
  • Der Normalfall und ein gemessener Engpass rechtfertigten Optimierung. Erwartete Segmentfolgen, ACK-getriebene Queue-Löschung und ein lokalisierter Multics-Checksum-Pfad waren Belege; seltene Ausnahmen und reine Diagrammlogik waren es nicht.

Die häufigste Operation stand nicht auf dem Etikett

Wer eine Retransmission Queue entwirft, könnte zuerst die Wiederholung eines verlorenen Segments beschleunigen. RFC 817 wies darauf hin, dass die Queue weit öfter bestätigte Daten verwirft. Die gewöhnliche Operation war das Entfernen, nicht die erneute Übertragung. Eine Datenstruktur, die sich am seltenen Ausnahmefall orientiert, zahlt für ihren Namen mit Zeit im Normalbetrieb.

Ähnlich verhielt es sich mit eintreffenden Segmenten. Meist kam als Nächstes genau die erwartete Sequenznummer. Der Code sollte diesen Pfad zuerst und billig prüfen, statt jeden Empfang durch die vollständige Behandlung ungewöhnlicher Fälle zu schicken. Auch Kopien, die nur eine Modulgrenze bequem machten, waren keine unvermeidbare Eigenschaft des Protokolls.

Diese Beispiele waren keine Sammlung isolierter Mikrotricks. Sie stellten eine Regel für die Implementierungsgrenze auf: Ausführung folgt Häufigkeit, Zustand und messbaren Kosten. Eine Schichtenzeichnung zeigt Dienste und Abhängigkeiten, aber weder den heißen Pfad noch die Verteilung der CPU-Zeit.

Eine saubere IP/TCP-Linie konnte zweimal wecken

Lag IP im Kernel und TCP vollständig in einem Prozess, musste ein eingehendes Datagramm zunächst diesen TCP-Prozess erreichen. Erst nach dem Lesen des Transport-Headers stand fest, welche Verbindung und welcher Benutzerprozess das Paket erhalten sollte. Das System plante den TCP-Prozess ein und danach die Anwendung. Die saubere Trennung hatte aus einer Demultiplexing-Entscheidung zwei Laufzeitübergänge gemacht.

RFC 817 schlug einen funktionalen Schnitt vor. Im Kernel verblieb genug IP- und TCP-Logik, um das endgültige Ziel zu bestimmen. Das Datagramm konnte direkt an dessen Prozess geliefert werden. Weitere Arbeit, besonders Aktionen mit Timern oder Blockieren, lief im geeigneten Prozesskontext weiter.

Die Schnittlinie querte also die Spezifikationsschichten. Sie änderte jedoch kein Bit, das ein entfernter TCP-Peer sah. Der öffentliche Vertrag blieb derselbe. Lokal änderten sich nur Ort und Besitz des Zustands, der ausführende Kontext und die Zahl der Übergänge.

Das Modell ließ sogar einen TCP-Kontext pro Verbindung denkbar werden: eine Variante für hohen Dateidurchsatz, eine andere für niedrige interaktive Verzögerung. RFC 817 nannte den möglichen Einfachheitsgewinn, aber auch die Wartungsgefahr mehrerer Implementierungen. Es kennzeichnete den Ansatz als experimentell und keineswegs allgemein akzeptiert.

Jeder Ausführungsort tauschte Kosten gegen andere Kosten

Ein Protokollprozess vermied manche Kerneländerung und bot eine vertraute Umgebung für komplexe Timer und blockierende Aktionen. Dafür musste jedes Paket auf Scheduling warten. Sollte ein Dienst wie ein lokales Terminal oder Gerät aussehen, führte der Weg womöglich zurück in den Kernel und machte die organisatorische Trennung im Datenpfad wieder kompliziert.

Im Kernel entfiel ein Prozesswechsel, und Geräte ließen sich unmittelbar anbinden. Komplexe Timer-Aktionen passten jedoch schlecht in eine Interrupt-Umgebung. Dort konnte Code gewöhnlich nicht warten, durfte Interrupts nicht lange verdecken und konnte bei hoher Paketlast die Maschine beanspruchen, ohne dass der Scheduler wirksam eingriff. Begrenzter Kernelspeicher und Betriebssystemänderungen erhöhten außerdem die langfristigen Kosten.

Ein eigener Kommunikationsprozessor versprach Spezialisierung und Wiederverwendung. Doch zwischen Host und Frontend blieb eine Schnittstelle für Rahmung, Flusssteuerung, Ereignisse und Ausfälle. Diese Verbindung war selbst protokollartig. Die Grenze wurde physisch verlagert, nicht beseitigt.

Damit war „Kernel oder Prozess?“ keine hinreichende Frage. Entscheidend waren die einzelnen Funktionen: Gerätenähe, Demultiplexing, Timer, Blockieren, Verbindungszustand, Kopieren, Fehlerbehandlung und der konkrete Preis jedes Übergangs.

Ein Telnet-Zeichen stellte drei korrekte Rechnungen

Beim zeichenweisen Telnet löste eine Eingabe mehrere Pflichten aus. TCP schuldete ein ACK, die Empfangsseite womöglich ein Fenster-Update, Telnet oder die Anwendung ein Echo. Steuerzeichen konnten weitere Reaktionen erzeugen. Wenn jede Schicht sofort sendete, entstanden aus einer Eingabe mehrere Pakete.

Keines davon war falsch. Die Komponenten wussten nur nicht, dass der Nachbar gleich ebenfalls Daten erzeugen würde. Pro Paket wiederholten sich Interrupt, Scheduling und Sende- sowie Empfangspfad auf beiden Hosts; in tarifierten Netzen kam die Kommunikationsgebühr hinzu.

Die vorgeschlagene Querinformation blieb klein. TCP konnte erfahren, ob die obere Schicht wahrscheinlich bald antwortete, und das ACK kurz zurückhalten. Beim interaktiven Telnet ließen sich Bestätigung, Fenster und Echo gemeinsam senden. Bei einem einseitigen Dateitransfer verzögerte dieselbe Wartezeit dagegen die nächste Datenlieferung und konnte den Durchsatz senken.

RFC 1122 gab dem delayed ACK später feste Grenzen: nicht länger als eine halbe Sekunde warten und mindestens jedes zweite volle Segment bestätigen. Es übernahm die mögliche Reduktion von drei Segmenten auf eines, warnte aber vor Schäden an RTT-Messung und Paket-Taktung. Die Anwendung durfte einen Hinweis liefern; TCP behielt die Frist und seine Protokollpflicht.

Isolation hatte Nutzen und Miete

Eine sichtbare, stabile Schichtschnittstelle erlaubt Änderungen auf einer Seite, ohne die andere neu zu schreiben. Mehrere Clients können denselben Dienst nutzen, Teams benötigen weniger Gesamtwissen, und unterschiedliche Rechner bleiben kompatibel. Diese Isolation erklärt die Langlebigkeit einer Protokollfamilie.

Die feste Schnittstelle verdeckt zugleich Absicht. Ein reiner Bytestrom kann Blockübertragung zu unpassenden Operationen zwingen. Getrennte Prozesse ohne gemeinsamen Speicher verursachen Kernelkopien. Unabhängige Sendemomente erzeugen mehrere Pakete, obwohl ihre Informationen zusammenpassen.

RFC 817 bezeichnete die Schichtgrenze deshalb als Nutzen und Strafe. Das war kein Freibrief zum Durchbrechen. Die Miete musste gemessen werden: Pakete, Kopien, Weckvorgänge, Suchen, Latenz, Varianten und Reparaturaufwand. Eine Querung war nur vertretbar, wenn eingesparte Arbeit belegt, offengelegte Information begrenzt und der Pfad ohne Optimierung weiterhin korrekt war.

RFC 1958 stellte später Modularität, Leistung und Kosten nebeneinander und bewertete Rückmeldung aus laufenden Implementierungen höher als architektonische Maximen. RFC 3439 verband Komplexität mit Skalierung und Betriebskosten. Weder Reinheit noch Kopplung konnten sich ohne Evidenz selbst rechtfertigen.

Multics durfte schmutzig sein, aber nur an einer Stelle

Auf Multics passten die Acht-Bit-Bytes eines TCP-Segments ungünstig in 36-Bit-Wörter. Eine frühe Checksum-Implementierung benötigte für 576 Byte ungefähr sechs Millisekunden. Sorgfältiger, stark maschinenspezifischer Code senkte den Wert auf unter eine Millisekunde.

RFC 817 nannte diese Technik schmutzig. Zulässig war sie, weil ein extremer Engpass gemessen worden war, die Spezialisierung in einer Funktion blieb und das Ergebnis gegen einen Referenzpfad geprüft werden konnte. Eine lokale Ausnahme war etwas anderes als ein allgemeiner Programmierstil.

Die breitere Leistungslehre war mühsamer: Zeit verschwand verteilt in Checksum, Kopien, Queue-Suche, Scheduling und Zustandsübergängen. Selten gab es ein einzelnes Ungeheuer, dessen Beseitigung alles reparierte. Leistung musste über den ganzen Pfad aufgebaut werden, bevor die Modulkarte starr wurde.

Vertrag und Ausführung brauchten zwei Karten

Der Protokollstapel beantwortete, was Peers miteinander austauschten. Die Implementierungskarte beantwortete, wo ein Host Zeit verbrauchte, Bytes bewegte, Arbeit plante und Fehler begrenzte. Wer beides gleichsetzte, machte aus einer Spezifikationsgrafik ungeprüft einen Scheduler.

RFC 817 verlangte stattdessen Laufzeitevidenz. Pakete pro nützlicher Aktion zählen, Kopien verfolgen, normalen und außergewöhnlichen Verkehr trennen und für jeden Schichthinweis Besitzer, Lebensdauer und Fallback dokumentieren. Gleichzeitig blieb der äußere Vertrag unangetastet, damit eine andere Implementierung eine andere interne Karte wählen konnte.

Die Schicht war real als interoperable Verpflichtung. Ihre Kosten waren ebenso real. Das Modul war lokal und musste deshalb begründen, warum sein Schnitt den Stack querte und wie er wieder entfernt werden konnte.

Quellen