Varm HTTPS mot ett varmt VPN: jämför samma begärandeväg

Du har antagligen läst att HTTPS öppnar en ny TCP-anslutning och en ny TLS-handskakning för varje API-begäran, så en tunnel som hålls uppe en timme verkar billigare. Den första hälften av det är oftast falsk. En klient som stöds återanvänder en etablerad anslutning för många utbyten, och ett prestandatest som bygger en ny klient vid varje anrop mäter livscykeln i stället för skyddet. Resten av sidan handlar om vad du i stället bör mäta.

Vad återanvändning egentligen kräver

Beständighet är en del av HTTP-modellen och inte ett trick: en anslutning bär flera begäran-svar-utbyten. Anslutningen avslutas när någon av sidorna stänger den, när servern pensionerar en inaktiv eller överbelastad anslutning, eller när ett huvud eller en protokollregel säger att anslutningen inte får återanvändas. HTTPS lägger in det samtalet i TLS utan att kräva en ny handskakning för varje utbyte. Så en andra begäran upprepar inte den första begärans handskakning om inte något avslutade anslutningen däremellan.

Återanvändning har också ett villkor som applikationer lätt bryter. En klient som planerar att återanvända en anslutning måste läsa hela svarskroppen, och ett svar som överges på halva vägen är det vanliga sättet en anslutningspool försvinner utan att någon märker det.

Kontrollera bibliotekets klient som stöds och anslutningspoolens livscykel i stället för att anta att poolning är på eller av. Notera också den förhandlade HTTP-versionen, eftersom HTTP/2 och HTTP/3 hanterar återanvändning av anslutningar annorlunda än HTTP/1.1. Behandla den förhandlade versionen som en del av mätningen, inte som en fotnot.

Varför jämförelsen mäter livscykeln

Att skapa en ny klient för varje operation och jämföra den med en tunnel som varit ansluten i en timme jämför anslutningsuppsättning med ett stabilt tillstånd. Det är ett legitimt test, och det är inte HTTPS mot VPN. Två körningar med samma klientkonfiguration beskriver beteendet bättre än en, särskilt när den första körningen värmer en resolver eller anslutningscache.

Håll API-operationen, servern, kontot och data konstanta, annars bär jämförelsen mer än en variabel. Bestäm i förväg var du lägger timern, eftersom uppsättning, TLS-förhandling, applikationskörning och svarsleverans bidrar olika till totalen. En enda timer för den första begäran karaktäriserar uppsättningen och säger inget om den stabila trafik du faktiskt kör. Skriv ned timerns gränser bredvid siffrorna.

Skilj kall uppsättning från varma begäranden

Mät den första begäran separat från dem som följer. Lägg sedan till vad tjänsten verkligen ser: inaktiva perioder, toppar, samtidighet, svarsstorlek och återanslutningar.

Behåll certifikatvalidering och HTTPS påslagna på båda vägarna, eftersom att ta bort dem mäter en annan säkerhetsdesign i stället för en snabbare. Om tunneln ändrar vägen eller gatewayens placering, rapportera den skillnaden separat i stället för att tillskriva varje tidsändring kryptering, eftersom väg, förlust och kö kan dominera en liten begäran. Kör varje väg två gånger över samma rutt innan du drar en slutsats. Notera det förhandlade protokollet och timerns gränser med båda körningarna.

Räkna med anslutningen som stängs

Beständig betyder inte permanent. En server, en proxy eller en nätverksändring kan stänga en anslutning under en inaktiv period, och klienten måste återhämta sig genom sitt biblioteks stödda beteende. Den återhämtningen har en tillståndsmaskin: begäran kan ha slutförts på servern, eller misslyckats innan servern läste den, och en stängd socket berättar inte för anroparen vilket som hände. En icke-idempotent operation i den positionen kan inte bara spelas upp igen, eftersom en upprepning förvandlar ett okänt utfall till en dubbel skrivning. Här beter sig en varm tunnel och en varm anslutning likadant, eftersom båda kan misslyckas i det ögonblick arbete är i gång.

Använd tjänstens dokumenterade mekanism för omförsök eller idempotens i stället för en loop som öppnar socketen igen. Testa återhämtningen uttryckligen genom att stänga en inaktiv anslutning och se vad klienten gör härnäst. Att öppna en socket igen gör det inte säkert att upprepa ett tillståndsändrande anrop.

Välj gränsen först och justera sedan

Välj nätverksgränsen utifrån åtkomst- och förtroendekraven innan du optimerar något. Ett VPN skyddar segmentet mellan sina parter, medan applikationens slutpunkter och varje klartextsegment utanför tunneln fortfarande spelar roll. Justera sedan anslutningens livscykel inom den gränsen. Slutsatsen om den billigare tunneln följer bara av tron att varje begäran upprepar handskakningen, och det är just den tron som prövas här.

Avsnittet om beständighet i RFC 9112 är referensen för vad återanvändning verkligen lovar, inklusive villkoren som avslutar en anslutning. Läs det en gång innan du litar på ett test som ignorerar dem.