Varm HTTPS kontra varm VPN: sammenlign samme anmodningsvej
HTTPS laver ikke håndtryk ved hver API-anmodning, så en varm forbindelse og en varm tunnel er ikke konkurrenter. Sammenlign samme anmodningsmønster, før du vælger.
Du har sikkert læst, at HTTPS åbner en ny TCP-forbindelse og et nyt TLS-håndtryk for hver API-anmodning, så en tunnel, der bliver oppe i en time, ser billigere ud. Den første halvdel af det er som regel forkert. En understøttet klient genbruger en etableret forbindelse til mange udvekslinger, og en benchmark, der bygger en ny klient for hvert kald, måler livscyklus frem for beskyttelse. Resten af denne side handler om, hvad du i stedet skal måle.
Hvad genbrug egentlig kræver
Vedholdenhed er en del af HTTP-modellen og ikke et trick: én forbindelse bærer flere udvekslinger af anmodning og svar. Forbindelsen slutter, når en af siderne lukker den, når serveren pensionerer en ledig eller overbelastet forbindelse, eller når en header- eller protokolregel siger, at forbindelsen ikke kan genbruges. HTTPS lægger den samtale ind i TLS uden at kræve et nyt håndtryk for hver udveksling. Så en anden anmodning gentager ikke den første anmodnings håndtryk, medmindre noget afsluttede forbindelsen indimellem.
Genbrug har også én betingelse, som applikationer let bryder. En klient, der vil genbruge en forbindelse, skal læse hele svarets krop, og et svar, der opgives halvvejs, er den sædvanlige måde, hvorpå en pulje forsvinder, uden at nogen opdager det.
Undersøg bibliotekets understøttede klient og forbindelsespuljens livscyklus i stedet for at antage, at puljen er slået til eller fra. Noter også den forhandlede HTTP-version, fordi HTTP/2 og HTTP/3 håndterer genbrug af forbindelser anderledes end HTTP/1.1. Behandl den forhandlede version som en del af målingen, ikke som en fodnote.
Hvorfor sammenligningen måler livscyklus
At oprette en ny klient for hver operation og sammenligne den med en tunnel, der har været forbundet i en time, sammenligner forbindelsesopsætning med stabil tilstand. Det er en legitim benchmark, og det er ikke HTTPS kontra VPN. To kørsler med samme klientkonfiguration beskriver adfærden bedre end én, især når den første kørsel varmer en resolver eller forbindelsescache op.
Hold API-operationen, serveren, kontoen og dataene konstante, ellers bærer sammenligningen mere end én variabel. Beslut på forhånd, hvor du placerer timeren, fordi opsætning, TLS-forhandling, applikationskørsel og svarslevering bidrager forskelligt til totalen. En enkelt timer for den første anmodning karakteriserer opsætningen og siger intet om den stabile trafik, du faktisk kører. Skriv timerens grænser ned ved siden af tallene.
Adskil kold opsætning fra varme anmodninger
Mål den første anmodning separat fra dem, der følger efter. Tilføj derefter det, tjenesten reelt ser: ledige perioder, udbrud, samtidighed, svarets størrelse og genforbindelser.
Behold certifikatvalidering og HTTPS slået til på begge veje, fordi fjernelse af dem måler et andet sikkerhedsdesign frem for et hurtigere. Hvis tunnelen ændrer ruten eller gatewayens placering, skal du rapportere den forskel separat i stedet for at tilskrive enhver tidsændring kryptering, da rute, tab og kødannelse kan dominere en lille anmodning. Kør hver vej to gange over samme rute, før du drager en konklusion. Noter den forhandlede protokol og timerens grænser sammen med begge kørsler.
Planlæg for forbindelsen, der lukker
Vedvarende betyder ikke permanent. En server, en proxy eller en netværksændring kan lukke en forbindelse i en ledig periode, og klienten skal gendanne via sin biblioteks understøttede adfærd. Den gendannelse har en tilstandsmaskine: anmodningen kan være fuldført på serveren, eller den kan være mislykket, før serveren læste den, og en lukket socket fortæller ikke den kaldende, hvilket der skete. En ikke-idempotent operation på den position kan ikke blot afspilles igen, fordi en gentagelse gør et ukendt udfald til en dobbelt skrivning. Det er her, en varm tunnel og en varm forbindelse opfører sig ens, da begge kan fejle i det øjeblik, arbejdet er i gang.
Brug tjenestens dokumenterede genforsøgs- eller idempotensmekanisme i stedet for en løkke, der genåbner socketten. Test gendannelsen udtrykkeligt ved at lukke en ledig forbindelse og se, hvad klienten gør derefter. At genåbne en socket gør det ikke sikkert at gentage et kald, der ændrer tilstand.
Vælg grænsen først, og juster derefter
Vælg netværksgrænsen ud fra adgangs- og tillidskravene, før du optimerer noget. En VPN beskytter segmentet mellem sine jævnbyrdige, mens applikationens endepunkter og ethvert klartekstsegment uden for tunnelen stadig betyder noget. Juster derefter forbindelsens livscyklus inden for den grænse. Konklusionen om den billigere tunnel følger kun af troen på, at hver anmodning gentager håndtrykket, og det er netop den tro, der prøves her.
RFC 9112's afsnit om vedholdenhed er referencen for, hvad genbrug faktisk lover, inklusive de betingelser, der afslutter en forbindelse. Læs det én gang, før du stoler på en benchmark, der ignorerer dem.