Warmes HTTPS gegen warmes VPN: denselben Anfragepfad vergleichen

Sie haben wahrscheinlich gelesen, dass HTTPS für jede API-Anfrage eine neue TCP-Verbindung und einen frischen TLS-Handshake öffnet, sodass ein Tunnel, der eine Stunde lang besteht, günstiger wirkt. Die erste Hälfte davon ist meist falsch. Ein unterstützter Client verwendet eine bestehende Verbindung für viele Austausche wieder, und ein Benchmark, der pro Aufruf einen neuen Client baut, misst den Lebenszyklus statt den Schutz. Der Rest dieser Seite beschreibt, was Sie stattdessen messen sollten.

Was Wiederverwendung wirklich verlangt

Persistenz ist Teil des HTTP-Modells und kein Trick: Eine Verbindung trägt mehrere Anfrage-Antwort-Austausche. Die Verbindung endet, wenn eine der beiden Seiten sie schließt, wenn der Server eine untätige oder überlastete Verbindung zurückzieht oder wenn eine Kopfzeile oder Protokollregel besagt, dass die Verbindung nicht wiederverwendet werden darf. HTTPS legt dieses Gespräch in TLS, ohne für jeden Austausch einen neuen Handshake zu verlangen. Eine zweite Anfrage wiederholt also nicht den Handshake der ersten, es sei denn, etwas hat die Verbindung dazwischen beendet.

Die Wiederverwendung hat auch eine Bedingung, die Anwendungen leicht brechen. Ein Client, der eine Verbindung wiederverwenden will, muss den vollständigen Antwortkörper lesen, und eine zur Hälfte verworfene Antwort ist der übliche Weg, auf dem ein Verbindungspool verschwindet, ohne dass es jemand bemerkt.

Prüfen Sie den unterstützten Client der Bibliothek und den Lebenszyklus des Verbindungspools, statt anzunehmen, dass Pooling an oder aus ist. Notieren Sie auch die ausgehandelte HTTP-Version, denn HTTP/2 und HTTP/3 behandeln die Wiederverwendung von Verbindungen anders als HTTP/1.1. Behandeln Sie die ausgehandelte Version als Teil der Messung und nicht als Fußnote.

Warum der Vergleich den Lebenszyklus misst

Für jeden Vorgang einen frischen Client zu erzeugen und ihn mit einem Tunnel zu vergleichen, der seit einer Stunde verbunden ist, vergleicht den Verbindungsaufbau mit dem stationären Zustand. Das ist ein legitimer Benchmark und nicht HTTPS gegen VPN. Zwei Läufe mit derselben Clientkonfiguration beschreiben das Verhalten besser als einer, besonders wenn der erste Lauf einen Resolver oder Verbindungscache aufwärmt.

Halten Sie den API-Vorgang, den Server, das Konto und die Daten konstant, sonst trägt der Vergleich mehr als eine Variable. Legen Sie vorab fest, wo Sie die Zeitmessung ansetzen, denn Aufbau, TLS-Aushandlung, Anwendungsausführung und Antwortauslieferung tragen unterschiedlich zur Summe bei. Eine einzelne Messung der ersten Anfrage beschreibt den Aufbau und sagt nichts über den stetigen Verkehr, den Sie tatsächlich fahren. Schreiben Sie die Messgrenzen neben die Zahlen.

Kalten Aufbau von warmen Anfragen trennen

Messen Sie die erste Anfrage getrennt von den folgenden. Ergänzen Sie dann, was der Dienst wirklich sieht: Leerlaufphasen, Lastspitzen, Parallelität, Antwortgröße und Neuverbindungen.

Lassen Sie Zertifikatsprüfung und HTTPS auf beiden Pfaden aktiv, denn ihr Entfernen misst ein anderes Sicherheitsdesign statt ein schnelleres. Wenn der Tunnel die Route oder den Standort des Gateways ändert, melden Sie diesen Unterschied separat, statt jede Zeitänderung der Verschlüsselung zuzuschreiben, denn Pfad, Verlust und Warteschlange können eine kleine Anfrage dominieren. Führen Sie jeden Pfad zweimal über dieselbe Route aus, bevor Sie eine Schlussfolgerung ziehen. Notieren Sie das ausgehandelte Protokoll und die Messgrenzen bei beiden Läufen.

Für die Verbindung planen, die schließt

Persistent bedeutet nicht dauerhaft. Ein Server, ein Proxy oder eine Netzwerkänderung kann eine Verbindung während einer Leerlaufphase schließen, und der Client muss sich über das unterstützte Verhalten seiner Bibliothek erholen. Diese Erholung hat einen Zustandsautomaten: Die Anfrage kann auf dem Server abgeschlossen worden sein, oder sie ist fehlgeschlagen, bevor der Server sie gelesen hat, und ein geschlossener Socket sagt dem Aufrufer nicht, was passiert ist. Ein nicht idempotenter Vorgang an dieser Stelle lässt sich nicht einfach wiederholen, weil eine Wiederholung ein unbekanntes Ergebnis in einen doppelten Schreibvorgang verwandelt. Hier verhalten sich ein warmer Tunnel und eine warme Verbindung gleich, denn beide können scheitern, während Arbeit unterwegs ist.

Nutzen Sie den dokumentierten Wiederholungs- oder Idempotenzmechanismus des Dienstes statt einer Schleife, die den Socket neu öffnet. Testen Sie die Erholung ausdrücklich, indem Sie eine untätige Verbindung schließen und beobachten, was der Client als Nächstes tut. Ein Socket neu zu öffnen macht die Wiederholung eines zustandsändernden Aufrufs nicht sicher.

Erst die Grenze wählen, dann abstimmen

Wählen Sie die Netzwerkgrenze aus den Zugriffs- und Vertrauensanforderungen, bevor Sie irgendetwas optimieren. Ein VPN schützt das Segment zwischen seinen Peers, während die Anwendungsendpunkte und jedes Klartextsegment außerhalb des Tunnels weiterhin zählen. Stellen Sie dann den Verbindungslebenszyklus innerhalb dieser Grenze ein. Die Schlussfolgerung vom günstigeren Tunnel folgt nur aus der Annahme, dass jede Anfrage den Handshake wiederholt, und genau diese Annahme wird hier geprüft.

Der Abschnitt zur Persistenz in RFC 9112 ist die Referenz dafür, was Wiederverwendung tatsächlich verspricht, einschließlich der Bedingungen, die eine Verbindung beenden. Lesen Sie ihn einmal, bevor Sie einem Benchmark trauen, der sie ignoriert.