Warm HTTPS tegen warme VPN: vergelijk hetzelfde aanvraagpad

U hebt waarschijnlijk gelezen dat HTTPS voor elke API-aanvraag een nieuwe TCP-verbinding en een nieuwe TLS-handshake opent, zodat een tunnel die een uur blijft staan goedkoper lijkt. De eerste helft daarvan is meestal onwaar. Een ondersteunde client hergebruikt een bestaande verbinding voor veel uitwisselingen, en een benchmark die per aanroep een nieuwe client bouwt, meet de levenscyclus in plaats van de bescherming. De rest van deze pagina gaat over wat u in plaats daarvan moet meten.

Wat hergebruik echt vereist

Persistentie is deel van het HTTP-model en geen truc: één verbinding draagt meerdere aanvraag-antwoorduitwisselingen. De verbinding eindigt wanneer een van beide partijen haar sluit, wanneer de server een inactieve of overbelaste verbinding buiten gebruik stelt, of wanneer een header of protocolregel zegt dat de verbinding niet hergebruikt mag worden. HTTPS legt dat gesprek binnen TLS zonder voor elke uitwisseling een nieuwe handshake te eisen. Een tweede aanvraag herhaalt dus niet de handshake van de eerste, tenzij iets de verbinding tussendoor heeft beëindigd.

Hergebruik heeft ook één voorwaarde die applicaties gemakkelijk breken. Een client die een verbinding wil hergebruiken, moet de volledige antwoordbody lezen, en een antwoord dat halverwege wordt verlaten is de gebruikelijke manier waarop een verbindingspool verdwijnt zonder dat iemand het merkt.

Controleer de ondersteunde client van de bibliotheek en de levenscyclus van de verbindingspool in plaats van aan te nemen dat pooling aan of uit staat. Noteer ook de onderhandelde HTTP-versie, want HTTP/2 en HTTP/3 gaan anders met verbindingshergebruik om dan HTTP/1.1. Behandel de onderhandelde versie als deel van de meting, niet als voetnoot.

Waarom de vergelijking de levenscyclus meet

Voor elke bewerking een nieuwe client maken en die vergelijken met een tunnel die al een uur verbonden is, vergelijkt het opzetten van de verbinding met een stabiele toestand. Dat is een legitieme benchmark, en het is niet HTTPS tegen VPN. Twee runs met dezelfde clientconfiguratie beschrijven het gedrag beter dan één, vooral wanneer de eerste run een resolver of verbindingscache opwarmt.

Houd de API-bewerking, de server, het account en de gegevens constant, anders draagt de vergelijking meer dan één variabele. Bepaal vooraf waar u de timer plaatst, want opzet, TLS-onderhandeling, uitvoering van de applicatie en levering van het antwoord dragen verschillend bij aan het totaal. Eén timer voor de eerste aanvraag karakteriseert de opzet en zegt niets over het stabiele verkeer dat u werkelijk draait. Schrijf de timergrenzen naast de cijfers.

Koude opzet van warme aanvragen scheiden

Meet de eerste aanvraag apart van de aanvragen die volgen. Voeg daarna toe wat de dienst echt ziet: inactieve perioden, pieken, gelijktijdigheid, antwoordgrootte en herverbindingen.

Laat certificaatvalidatie en HTTPS aan op beide paden, want ze verwijderen meet een ander beveiligingsontwerp in plaats van een sneller. Als de tunnel de route of de locatie van de gateway verandert, meld dat verschil dan apart in plaats van elke timingverandering aan versleuteling toe te schrijven, omdat pad, verlies en wachtrij een kleine aanvraag kunnen domineren. Voer elk pad twee keer over dezelfde route uit voordat u een conclusie trekt. Noteer het onderhandelde protocol en de timergrenzen bij beide runs.

Reken op de verbinding die sluit

Persistent betekent niet permanent. Een server, een proxy of een netwerkwijziging kan een verbinding tijdens een inactieve periode sluiten, en de client moet herstellen via het gedrag dat zijn bibliotheek ondersteunt. Dat herstel heeft een toestandsmachine: de aanvraag is misschien op de server voltooid, of mislukt voordat de server haar las, en een gesloten socket vertelt de aanroeper niet wat er is gebeurd. Een niet-idempotente bewerking op die plek kan niet zomaar opnieuw worden afgespeeld, omdat een herhaling een onbekende uitkomst in een dubbele schrijfactie verandert. Hier gedragen een warme tunnel en een warme verbinding zich hetzelfde, omdat beide kunnen falen op het moment dat er werk onderweg is.

Gebruik het gedocumenteerde mechanisme voor opnieuw proberen of idempotentie van de dienst in plaats van een lus die de socket opnieuw opent. Test het herstel expliciet door een inactieve verbinding te sluiten en te kijken wat de client daarna doet. Een socket opnieuw openen maakt het herhalen van een toestandswijzigende aanroep niet veilig.

Kies eerst de grens en stem dan af

Kies de netwerkgrens op basis van de toegangs- en vertrouwensvereisten voordat u iets optimaliseert. Een VPN beschermt het segment tussen zijn peers, terwijl de eindpunten van de applicatie en elk leesbaar-tekstsegment buiten de tunnel nog steeds tellen. Stem daarna de levenscyclus van de verbinding binnen die grens af. De conclusie van de goedkopere tunnel volgt alleen uit de overtuiging dat elke aanvraag de handshake herhaalt, en die overtuiging is wat hier wordt getest.

De sectie over persistentie in RFC 9112 is de referentie voor wat hergebruik werkelijk belooft, inclusief de voorwaarden die een verbinding beëindigen. Lees hem één keer voordat u een benchmark vertrouwt die ze negeert.