Schichten des frühen Webs: Wie BBN und die Network Working Group die ARPANET-Protokolle entwickelten

Im Jahr 1969 lieferte Bolt, Beranek and Newman angepasste Honeywell-Minicomputer, bekannt als Interface Message Processors, um an jedem Standort in den Vereinigten Staaten als Netzwerk-Gateways für bis zu vier Host-Rechner zu dienen. Diese robusten Einheiten übernahmen die Aufgabe, rohe Datenpakete zwischen den Standorten zu leiten. Die Verbindung heterogener Mainframes unterschiedlicher Hersteller erforderte jedoch ein völlig neues Regelwerk für die Software. BBN wartete zwar die Hardware und die interne Gateway-Software, überließ das Erstellen von Host-zu-Host-Kommunikationsstandards jedoch den Informatikern und Doktoranden, die die Host-Rechner an den jeweiligen angeschlossenen Institutionen bedienten.

Arbeitsteilung am Nullpunkt des Netzwerks

Um diese Arbeitsteilung zu bewältigen, schlossen sich junge Forscher und Host-Ingenieure zur Network Working Group zusammen. Dieser organisatorischen Trennung zufolge entstand naturgemäß eine geschichtete Netzwerkarchitektur. BBN konzentrierte sich auf das zugrunde liegende Nachrichtenübermittlungssystem, während die Network Working Group höherwertige Protokolle entwarf, um Daten für Anwendungen aufzubereiten. Durch die Isolation des physischen Gateway-Routings von der anwendungsbezogenen Logik auf Host-Ebene etablierte das Team einen modularen Ansatz, bei dem obere Protokollschichten direkt auf den unteren liefen – der strukturelle Grundstein für moderne Netzwerk-Stacks.

BBN-Report 1822 und das Stop-and-Wait-Limit

BBN dokumentierte die grundlegende Level-1-Schnittstelle zwischen Hosts und Gateways in einer technischen Spezifikation namens BBN Report 1822. Unter diesem Protokoll übertrugen Host-Rechner Nachrichten mit einer maximalen Länge von 8.095 Bits, denen ein Header mit der Zieladresse und einer zugewiesenen Link-Nummer vorangestellt war. Der Datenfluss wurde auf Level 1 streng über einen Stop-and-Wait-Mechanismus geregelt. Ein Host konnte jeweils nur eine Nachricht über einen Link senden und musste weitere Übertragungen aussetzen, bis das empfangende Gateway ein Signal vom Typ Request for Next Message zurücksandte.

Level-2-Sockets und die Steuerung über Link 0

Höherwertige Kommunikation erforderte eine präzisere Steuerung, als einfache Link-Nummern bieten konnten. Im RFC 9 skizziert und im RFC 54 formalisiert, führte das Host-Host-Protokoll auf Level 2 Software-Konstrukte namens Sockets ein. Sockets wurden nach Geschlecht unterschieden: Gerade Nummern repräsentierten Lese-Sockets zum Empfangen von Daten, während ungerade Nummern Schreib-Sockets zum Senden darstellten. Um diese unidirektionalen Kanäle zu verwalten, reservierten die Hosts den Link 0 ausschließlich für das Senden von Steuerbefehlen. Über den Link 0 tauschten die verbundenen Hosts Steuernachrichten aus, um individuelle Kommunikationspfade zu öffnen, deren Datenrate anzupassen und sie zu schließen, ohne die eigentlichen Nutzdaten zu beeinträchtigen.

Der Verbindungs-Tanz und der missverstandene Kernel

Da Level-2-Sockets nur einseitige Verbindungen herstellten, benötigten interaktive Anwendungen einen Level-3-Standard namens Initial Connection Protocol. Vor dem Start einer Telnet-Sitzung führte das Initial Connection Protocol einen mehrstufigen Austausch durch: Ein Client kontaktierte den bekannten Socket eines Servers, erhielt eine neue Socket-Zuweisung, schloss den temporären Link und öffnete gepaarte Lese- und Schreibkanäle. Im Kern jedes Hosts saß das Network Control Program, der Stack auf Kernel-Ebene, der fälschlicherweise oft als Protokoll statt als Software in Erinnerung geblieben ist. Zusammen bewiesen diese geschichteten Experimente, dass unterschiedliche Computerarchitekturen stabile, bidirektionale Sitzungen über eine gemeinsame Netzwerkinfrastruktur aushandeln konnten.

Das Verankern der frühen ARPANET-Experimente in einer Protokollschichtung – der Trennung niedrigerer Routing-Hardware von höherer Host-Software – lieferte die praktischen Erkenntnisse, die für die Verfeinerung der Paketvermittlung erforderlich waren. Obwohl moderne Netzwerke IMP-Link-Nummern und Stop-and-Wait-Beschränkungen durch flexible TCP/IP-Abstraktionen ersetzten, etablierte diese frühe Architektur das Modell unabhängiger, geschichteter Protokolle, das noch heute die globale Internetkommunikation stützt.

KI-generierte redaktionelle Illustration; kein Dokumentarfoto.

Quelle: 0b10 0b10 How the ARPANET Protocols Worked