Zusammenfassung

  • RFC 2391 stellte einen Serverpool hinter eine virtuelle Adresse und machte die Wahl für eine neue Sitzung zu Übersetzungszustand für alle folgenden Pakete.
  • Round Robin, Sitzungszahl, Verkehr, Gewichte, Routenkosten und Lebensprüfungen waren Entscheidungshilfen, keine Belege für echte Anwendungskapazität.
  • Ein toter Host konnte von neuen Zuweisungen ausgeschlossen werden, ohne seine laufenden Sitzungen zu retten; Vermeidung und Failover waren verschieden.

Die Adresse wurde zum Eingang einer Entscheidung

Für den Client sollte sich nichts ändern. Er kannte eine Dienstadresse und schickte seine Pakete dorthin. Hinter diesem stabilen Bild durfte der Betreiber mehrere Maschinen hinzufügen, ersetzen oder entfernen. RFC 2391 verband dafür die Adressübersetzung aus RFC 1631 mit Verfahren zur Lastverteilung.

Der LSNAT sah eine neue Sitzung, wählte einen Poolteilnehmer und leitete sie um. Die virtuelle Serveradresse konnte eine einzelne Maschine oder eine Gruppe bezeichnen. Auch einzelne Dienste ließen sich in die Verteilung aufnehmen, ohne alle Anwendungen eines Hosts gleich zu behandeln.

Die Einfachheit an den Enden verschob Bedeutung in die Mitte. Die Adresse nannte nicht länger die ausführende Maschine. Sie nannte den Ort, an dem Poolkonfiguration und lokale Auswahlpolitik entschieden, wer verantwortlich wurde.

Damit gehört das Thema nicht zur Anycast-Erzählung von RFC 1546. Dort kann Routing dieselbe Dienstadresse zu verschiedenen Instanzen führen. RFC 2391 setzte einen zustandsbehafteten Übersetzer ein. Seine historische Besonderheit war die gespeicherte Zuordnung nach der ersten Auswahl.

Aus einer Wahl wurde eine Bindung

Der RFC beschrieb drei Phasen. Beim Session Binding wurde eine eingehende Sitzung einer Serveradresse zugeordnet. Diese Zuordnung legte die Übersetzungsparameter aller späteren Datagramme fest. Bei Lookup und Translation wurde jedes Paket anhand der Sitzung gefunden und verändert. Beim Unbinding endete die Verantwortung des Servers.

Auf dem Hinweg konnten Zieladresse und Port zum realen Server werden. Auf dem Rückweg wurden Quellfelder so verändert, dass der Client weiterhin die virtuelle Adresse sah. Prüfsummen mussten der Änderung folgen. Die sichtbare Kontinuität entstand, weil der LSNAT dieselbe Tabelle immer wieder anwendete.

Anfragen und Antworten mussten denselben Übersetzer passieren. Ein asymmetrischer Rückweg umging die passende Umschreibung. Ein Ersatzgerät ohne Tabelle kannte zwar die virtuelle Adresse, aber weder den gewählten Server noch die Portzuordnung.

RFC 2391 formulierte die Grenze ausdrücklich: Eine einem Host zugewiesene Sitzung konnte vor ihrem Ende nicht auf einen anderen Host wechseln. Der Algorithmus verteilte neue Anfänge. Er übertrug weder Transportzustand noch Anwendungskontext oder halbfertige Arbeit.

Last war das, was der Selektor zählen konnte

Round Robin sah überhaupt keine Last. Es verteilte Ankünfte gleichmäßig und setzte voraus, dass Sitzungen ähnlich teuer und Maschinen ähnlich leistungsfähig waren.

„Wenigste Sitzungen“ nutzte die Bindungstabelle als Messgerät. Eine ruhende Dauerverbindung und eine rechenintensive Anfrage blieben jedoch jeweils ein Eintrag. Die Zählung stimmte, ihre Bedeutung konnte falsch sein.

Paket- oder Bytezahlen beschrieben Verkehr am LSNAT. Der RFC nannte sie nur eine Annäherung an Systemlast. Eine kleine Anfrage kann viel Rechenarbeit auslösen; ein großer Datenstrom kann effizient aus einem Cache kommen.

Gewichte brachten Betreiberwissen in die Formel. Sitzungstypen und Server erhielten angenommene Kosten und Kapazitäten. Das machte Voraussetzungen sichtbar und anpassbar, verwandelte Schätzungen aber nicht in Echtzeitbeobachtung.

Server konnten ihre Kapazität auch aktiv melden. Dann entstanden neue Grenzen: Messzeitpunkt, Übertragungsverzögerung, gemeinsame Semantik und veraltete Werte. RFC 2391 erkannte an, dass genaue Kenntnis freier entfernter Ressourcen in Echtzeit schwer zu erreichen war.

Der Selektor besaß also ein Entscheidungsmodell. Er besaß nicht die objektive Kapazität und schon gar keinen Beleg für den Erfolg der nächsten Anwendungstransaktion.

Eine bekannte Route reservierte nichts

Bei verteilten Servern durfte der Selektor Routenkosten berücksichtigen und sie mit Sitzungslast oder Verkehr verbinden. Wurde ein Host durch einen Netzfehler unerreichbar, konnte sein Kostenwert unendlich werden; neue Sitzungen gingen dann nicht mehr dorthin.

Die Routinginformation sagte, welchen Weg das Kontrollsystem kannte. Sie reservierte keine Bandbreite, CPU, Speicherkapazität oder Anwendungswarteschlange. Erreichbarkeit und Dienstbereitschaft blieben getrennt.

Das grenzt den Artikel von RFC 2386 ab. Dort ging es darum, dass eine QoS-Ressourcenkarte weder Aufnahme noch Reservierung noch Lieferung beweist. Hier folgt auf ein unvollständiges Last- oder Routensignal eine dauerhafte Sitzungsauswahl. Der eigene Mechanismus von RFC 2391 ist die Bindung.

Die Belegkette lautete: virtuelle Adresse, Poolmitgliedschaft, beobachtetes Signal, Auswahlregel, Bindung, beidseitige Übersetzung, Serverantwort und Anwendungsergebnis. Kein früher Glied durfte das letzte ersetzen.

Tote Hosts verschwanden nur aus künftigen Entscheidungen

Ein stiller Server durfte nicht weiter neue Sitzungen erhalten. RFC 2391 schlug heuristische Prüfungen vor: regelmäßige Pings oder die Beobachtung, ob ein Host nach einer neuen Zuweisung Datagramme zurücksendet. Blieb die Reaktion einige Sekunden aus, konnte er als tot gelten und aus weiteren Zuweisungen fallen.

Auch die Rückkehr war ein Versuch. Nach einer Pause konnten wieder neue Sitzungen zugewiesen und Antwortzeiten beobachtet werden. „Lebend“ war ein lokales, zeitabhängiges Urteil, keine dauerhaft registrierte Eigenschaft.

Ein Ping belegte nicht, dass die Anwendung samt Abhängigkeiten bereit war. Eine ausgebliebene Antwort erklärte nicht eindeutig, ob Host, Weg, Dienst oder Anfrage schuld war. Der Betreiber musste handeln, durfte das Signal aber nicht überdehnen.

Aus zwei Aussagen des RFC folgt eine wichtige, ausdrücklich als Schlussfolgerung zu behandelnde Grenze. Die Erkennung stoppt neue Zuweisungen. Bereits zugewiesene Sitzungen können nicht vor ihrem Ende wechseln. Die Maßnahme verhindert daher weitere schlechte Wahlen, migriert aber keine bestehende Unterhaltung.

Ein Pool konnte verfügbar bleiben, während alle an den ausgefallenen Teilnehmer gebundenen Nutzer ihre Sitzung verloren. Freie Kapazität war eine Antwort für die Zukunft, nicht für Zustand, der nie kopiert worden war.

RFC 3022 zeigte später dasselbe Problem beim Ausfall des NAT selbst: Umgeleitete Flows konnten brechen, wenn Ersatzgeräte Konfiguration und Sitzungszustand nicht teilten. RFC 3234 unterschied Failover mit Zustandskopie von Restart. Ein laufendes Ersatzgerät war noch keine Fortsetzung.

Auch das Ende war nur eine lokale Deutung

Bindings mussten freigegeben werden. TCP bot FIN und RST, doch Neustarts oder Paketverlust konnten das Signal verbergen. UDP hatte kein allgemeines Sitzungsende. Langes legitimes Schweigen und ein verschwundener Peer sahen gleich aus.

Idle-Timeouts machten aus Schweigen eine Entscheidung. Zu kurz löschten sie gültigen Zustand. Zu lang hielten sie tote Einträge und verbrauchten Tabellen- oder Portressourcen. RFC 2663 stellte später klar, dass die NAT-Sitzung nicht mit der Anwendungssitzung übereinstimmen muss und sich Ruhe allgemein nicht sicher vom Ende unterscheiden lässt.

RFC 4787 standardisierte Mindestwerte und Erneuerungsverhalten für UDP-Mappings, dokumentierte aber zugleich große Unterschiede. Eine gemeinsame Untergrenze verbesserte Kompatibilität, nicht das Wissen um die Anwendung.

Unbinding war deshalb keine belanglose Bereinigung. Es entschied, wann alte Identität ihre Gültigkeit verlor und wann knappe Ressourcen wiederverwendet wurden. Der Mittelknoten interpretierte Anfang und Ende der Beziehung.

LS-NAPT bezahlte Topologiefreiheit mit mehr Abhängigkeit

Im Grundmodell lag der Pool hinter einem Rand, den beide Richtungen sicher passierten. LS-NAPT schrieb beide Seiten so um, dass Client- und Serverpakete zum Übersetzer zurückmussten. Server konnten freier verteilt und Zugangsverbindungen erweitert werden.

Der Preis war mehr Übersetzung und Komplexität. Die beschriebene Variante war auf TCP und UDP begrenzt. Der verfügbare Client-Portbereich beschränkte gleichzeitige Sitzungen. Eine räumliche Grenze wurde in Tabellen-, Port- und Verarbeitungsgrenzen verwandelt.

Das war der grundlegende NAT-Tausch. RFC 1631 lobte die Einführung ohne Endsystemänderung und benannte zugleich den Verlust der Ende-zu-Ende-Bedeutung der IP-Adresse sowie zusätzlichen Netzzustand. LSNAT nutzte genau diese Eigenschaft für Serverwahl.

RFC 7098 nannte später das Festhalten einer Sitzung an einem Server „Persistence“. Der Begriff passt. Er darf nur nicht als Migration gelesen werden: Eine Wahl stabil zu halten heißt nicht, sie im Fehlerfall austauschen zu können.

Acht Wirklichkeitsschichten hinter einem grünen Symbol

Die virtuelle Adresse belegte den Eingang. Die Poolkonfiguration belegte Kandidaten. Die Metrik belegte eine begrenzte Beobachtung. Die Politik belegte die Regel. Die Bindung belegte die Auswahl. Übersetzte Pakete belegten den Pfad. Die Serverantwort belegte einen Teil laufenden Verhaltens. Erst das Anwendungsergebnis belegte die gewünschte Wirkung.

Jede Schicht hatte einen anderen Eigentümer. Betreiber kontrollierten Mitgliedschaft und Politik. Der Selektor interpretierte Messwerte. Der LSNAT besaß die Zuordnung. Der Server kannte seine Ressourcen. Endpunkte sahen das Ergebnis. Keine Instanz konnte ehrlich für alle anderen unterschreiben.

Heng Lus Notizen trennen Koordinationsdokumente und Register von laufender Realität. Eine minimale Anfangsspezifikation soll lokale Entscheidungen, Implementierung und freiwillige Annahme ermöglichen, nicht ersetzen. RFC 2391 zeigt diese Ordnung: gemeinsame Übersetzungsregeln, lokale Auswahl und Beweis durch tatsächlich laufende Pakete.

Der freie Ersatzserver war vorhanden. Für eine bereits gebundene Sitzung blieb er dennoch außerhalb des Mechanismus. Lastverteilung hatte Anfänge austauschbar gemacht, nicht Geschichten.

Quellen