Zusammenfassung

  • RFC 675 hielt fest, dass unabhängig gewählte Portkennungen kollidieren konnten; die Adresse des TCP gab dem Socket-Namen Reichweite über verbundene Netze hinweg.
  • Eine Verbindung bestand aus dem Paar der Socket-Namen an ihren Enden. Ein lokaler Socket konnte deshalb an mehreren unterschiedlichen Verbindungen teilnehmen.
  • Spätere Spezifikationen verorteten Hostadressierung und Protokollauswahl in IP, Prozessports dagegen im Transport. Die Texte belegen keine allgemeine Einführung zu einem bestimmten Zeitpunkt.

Der Port war kein weltweiter Empfängername

Ein Port musste nicht weltweit eindeutig sein. Er musste Prozesse innerhalb des Systems unterscheiden, das ihn auswertete. RFC 675 aus dem Dezember 1974 benannte diese Grenze ausdrücklich: Betriebssysteme, TCPs und Nutzer wählten Portkennungen unabhängig voneinander, sodass Werte übereinstimmen konnten. Das Problem war nicht zwingend die gewählte Zahl, sondern der Versuch, mit einem lokalen Namen etwas außerhalb seines Geltungsbereichs zu bezeichnen.

Man stelle sich zwei getrennte TCPs vor, die denselben Wert verwenden. Die Zahl allein sagt nicht, welches TCP gemeint ist oder in welches der verbundenen Netze eine Nachricht gehört. RFC 675 verknüpfte deshalb die Internetadresse, die ein TCP identifizierte, mit der Portkennung. Der so gebildete Socket-Name sollte im gesamten Verbund der verbundenen Netze eindeutig sein. Die Spezifikation ergänzte also den fehlenden Geltungsbereich, statt so zu tun, als sei jeder lokale Port weltweit einmalig. RFC 675, Abschnitt 2.7

IP-Adresse und Transportport wurden getrennt behandelt

Die TCP-Spezifikation von 1980 beschrieb Ports innerhalb jedes Hosts. Zusammen mit den Netzwerk- und Hostadressen aus der Internet-Kommunikationsschicht bildeten sie einen Socket. Das Socket-Paar bestimmte weiterhin eine Verbindung, und ein Socket konnte in mehreren Verbindungen vorkommen. RFC 761 sagt außerdem, dass jeder Host seine Port-Prozess-Zuordnung selbst handhabt. RFC 761, Abschnitte 1.4 und 2.7

Die dazugehörige IP-Spezifikation verortete Hostadressierung und Protokollauswahl im Internet-Header: Adressen identifizierten Quell- und Zielhost, ein Protokollfeld das nächsthöhere Protokoll. RFC 791 behielt dieses getrennte Feld bei; das Glossar von RFC 793 definierte einen TCP-Socket als Internetadresse plus TCP-Port. Zusammengenommen ordnen die Texte Netzwerkerreichbarkeit und Weitergabe an das nächste Protokoll IP zu, die Prozessauswahl dagegen dem Transport. RFC 760, Abschnitte 1.1 und 3.1 · RFC 791, Abschnitt 3.1 · RFC 793, Abschnitt 3.1 und Glossar

UDP zeigt dieselbe Trennung in einem anderen Transportprotokoll. Seine Spezifikation definiert Quell- und Zielportfelder; die UDP/IP-Schnittstelle bezieht Internetadressen und Protokollfeld aus dem IP-Header. Ein Port ist deshalb nur im Kontext von Adresse und Transport sinnvoll. Er ist keine universelle Zahl, die eine Anwendung über alle Netze und Protokolle hinweg benennt. RFC 768, „Fields“ und „IP Interface“

Erst das Gegenüber machte die Verbindung eindeutig

„Socket“ und „Verbindung“ werden leicht gleichgesetzt. RFC 675 hält sie auseinander: Eine Verbindung wird durch das Paar der Socket-Namen an ihren Enden vollständig bestimmt. Derselbe lokale Socket kann an vielen Verbindungen mit unterschiedlichen fremden Sockets teilnehmen; die Verbindung kann Daten in beide Richtungen tragen. Der lokale Name muss daher nicht für ein einziges dauerhaftes Gespräch reserviert werden. Erst der Name des Gegenübers vervollständigt die Verbindung.

Das Paar erklärt, warum sich ein lokaler Port wiederverwenden lässt, ohne Verbindungen zusammenfallen zu lassen. Ein Dienst kann mit verschiedenen Gegenstellen kommunizieren; deren jeweilige Endpunktpaare bleiben verschieden. Der RFC beschreibt eine Protokollschnittstelle. Er behauptet nicht, ein Socket authentifiziere eine Person, belege den Eigentümer eines Rechners oder bleibe dauerhaft zugeordnet.

Auch die praktische Zuständigkeit ist erkennbar. Die Spezifikation benennt den Endpunkt; der einzelne Host bindet seine Ports an lokale Prozesse. Einen Endpunkt über Netze hinweg zu benennen und lokal den Empfängerprozess auszuwählen, sind verbundene, aber getrennte Entscheidungen.

Der Name markierte eine Schichtgrenze

Der Socket aus RFC 675 löste ein Koordinationsproblem, ohne eine weltweite Portvergabestelle zu verlangen. Er ergänzte eine lokal nützliche Zahl um den Adressbereich, der den Endpunkt außerhalb seines TCP unterscheidbar machte. Spätere Spezifikationen machten die Aufgabenteilung expliziter: IP identifizierte Hosts und das nächste Protokoll, Transportports wählten Prozesse, und das Paar der Endpunktnamen beschrieb eine Verbindung.

Das ist eine Geschichte der in Spezifikationen festgelegten Grenzen, kein Beleg für einen einheitlichen Umstellungstag oder eine flächendeckende Einführung. Die RFCs zeigen, wo die Felder liegen und woraus ein Verbindungsname besteht. Sie zeigen nicht, welches Netz welche Fassung einsetzte oder wie ein bestimmtes Betriebssystem sie intern darstellte. Die belegbare Lehre ist enger: Ein Port bezeichnet einen lokalen Dienst nur in seinem Kontext; die Reichweite einer Verbindung entsteht aus beiden Enden und ihren Netzwerkadressen.

Quellen und Grenzen

Die Primärquellen sind RFC 675, RFC 760, RFC 761, RFC 768, RFC 791 und RFC 793. Sie belegen Wortlaut und Terminologie der Spezifikationen, nicht Einführung, Einsatzchronologie, Authentifizierung, dauerhafte Rechneridentität oder heutiges Betriebsverhalten.