Große Downloads gegen das VPN: den Pfad bei der Anfrage wählen

„Schicke die großen Downloads am VPN vorbei und halte die kleinen Antworten darauf“ klingt nach einer Routingpolitik, ist aber keine. Ein Router entscheidet mit Informationen, die in diesem Moment verfügbar sind: Adressen, Ports, Protokoll, Firewall-Markierungen, ein identifizierter Fluss. Die endgültige Größe einer Antwort gehört nicht zu dieser Menge, denn sie ist noch nicht angekommen, und wenn der Router die Bytes messen könnte, trägt er sie bereits. Wer nach Aufgabe steuern will, muss die Entscheidung an einen Punkt verlegen, der die Aufgabe kennt, und die Checkliste unten zeigt, ob Ihr Entwurf einen solchen Punkt hat.

Warum ein Router eine Antwort nicht messen kann

In dem Moment, in dem ein Paket eine Route braucht, hat der Router höchstens die ersten paar Pakete eines Flusses gesehen. Er kann sagen, wer mit wem spricht, über welches Protokoll, mit welcher Markierung und wie viele Bytes bisher geflossen sind. Bisherige Bytes beschreiben die Vergangenheit. Die Größe der Antwort ist eine Eigenschaft einer Antwort, die noch nicht erzeugt wurde, und bei gestückelten oder gestreamten Antworten ist sie vielleicht nie im Voraus bekannt.

Selbst die eigenen Metadaten des Protokolls sind schwächer, als sie aussehen. HTTP erlaubt Antworten, deren Länge nicht vor dem Body angekündigt wird, und eine einzige Nutzeraktion kann viele Anfragen erzeugen, deren gemeinsame Kosten keiner einzelnen Header-Größe ähneln. Einen Header als Größe einer Aufgabe zu behandeln, ist ein Modellierungsfehler, bevor es ein Routingfehler ist.

Prüfung 1: gibt es einen Entscheidungspunkt, der einen Pfad wählen kann?

Benennen Sie die Komponente, die die Wahl trifft und nennen Sie dann, was sie im Moment der Wahl weiß. Ein Updater, der von einer dokumentierten Hostliste lädt, kennt seinen Zweck, bevor die Übertragung beginnt. Ein Downloaddienst, der Metadaten prüft und dann die Anfrage öffnet, kennt die Aufgabe, bevor die Verbindung existiert. Ein kooperierender Proxy kann Richtlinien auf Anfrageebene anwenden oder die Antwort cachen, ohne vorzugeben, ein Router zu sein.

Lautet die Antwort „das Gateway“, ist die Checkliste bereits gescheitert. Ein Gateway kann bekannte Flüsse nach Ziel, Markierung oder Client-Segment klassifizieren und sie vom ersten Paket an über einen definierten Pfad senden, was für einen genehmigten Updater oft ausreicht und für eine unbekannte Antwortgröße nie.

Prüfung 2: was sagen Ihnen die Metadaten tatsächlich?

Anwendungsbewusste Steuerung ist nur so gut wie die Felder, die sie liest. Die Regeln zur Antwortlänge in HTTP-Semantik erlauben Fälle, in denen die Länge am Anfang nicht verfügbar ist, und Inhaltkodierungen machen die übertragene Bytezahl ohnehin von der Repräsentationsgröße verschieden. Eine Politik, die den Pfad wechselt, wenn ein Header eine Schwelle überschreitet, verhält sich daher inkonsistent, und zwar meist genau bei den großen Übertragungen, die sie abfangen sollte.

Was Anwendungsmetadaten tragen können, ist eine Entscheidung über eine Aufgabe: dieser Workflow ist eine Massensynchronisierung, dieser ist interaktiv, dieser ist ein Software-Update aus bekannter Quelle. Das ist eine Politik in Begriffen der Absicht, und sie ist stabil genug, um getestet zu werden. „Diese Antwort wird größer als vierzig Megabyte“ ist keine solche Politik.

Prüfung 3: existiert der Fluss bereits?

Routing kann sich für einen Fluss ändern, ohne die Identität der Verbindung zu ändern, und dieser Unterschied lohnt sich, sauber zu halten. Eine TCP-Verbindung wird durch ihre Endpunktadressen und Ports identifiziert, und die Pakete können einen anderen Pfad nehmen, wenn sich die Routingtabelle darunter ändert. Was sich nicht unsichtbar ändern kann, ist der Zustand der Netzwerkadressübersetzung: Verkehr auf einen anderen Ausgang zu verlagern ändert meist das öffentliche Quelltupel, und die Gegenseite sieht einen anderen Peer ohne passenden Zustand.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Die praktische Regel ist also, dass ein Wechsel mitten in der Verbindung von einem Ausgang zum anderen eine neue Beziehung ist, keine Migration. Wenn der Entwurf verlangt, dass dieselbe Verbindung weiterläuft, musste die Entscheidung vor dem ersten SYN fallen, und keine später hinzugefügte Paketregel kann sie sauber rekonstruieren.

Prüfung 4: ist die eigentliche Anforderung Latenz und nicht der Ausgang?

Sehr viele Anfragen, „Massenverkehr woanders hinzuschicken“, sind eigentlich Beschwerden darüber, dass eine große Übertragung interaktive Arbeit langsam wirken lässt. Das ist ein Planungsproblem, und es hat eine Planungsantwort: faires Queuing oder eine unterstützte Bandbreitenpolitik auf dem vorhandenen Pfad hindert einen Massenfluss daran, einer Chatnachricht die Ressourcen zu entziehen, ohne einen von beiden zu verschieben.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Das Symptom so anzugehen, lässt die Ausgangsentscheidung dort, wo die Sicherheitsrichtlinie sie hingestellt hat, und es ist mit einem Befehl umkehrbar. Den Ausgang für eine ganze Klasse von Verkehr zu ändern, ist eine Richtlinienänderung mit Folgen für Authentifizierung, Protokollierung und Zugriffsregeln, also sollte es nicht das erste Werkzeug bei einer Latenzbeschwerde sein.

Wenn die Anforderung wirklich ein anderer Internetausgang ist, sagen Sie es mit diesen Worten und setzen Sie es an einer unterstützten Grenze um: eine neue Verbindung aus einem genehmigten Workflow oder eine Anwendung, die ihre eigene Anfrage über einen gewählten Ausgang öffnet. Halten Sie dann fest, welche Aufgaben welchen Ausgang nutzen, damit die nächste Person es nicht aus einer Routingtabelle ableiten muss.

Behalten Sie die Checkliste im Änderungsdatensatz: den Entscheidungspunkt, das Feld oder die Aufgabe, die ihn antreibt, ob der Fluss bereits existiert und ob das gemessene Symptom Latenz oder Ausgang war. Vier Fragen, und eine Politik, die alle vier beantwortet, ist eine, die Sie betreiben können, statt sie zu verteidigen.