Du har truleg lese at HTTPS opnar ei ny TCP-tilkopling og eit nytt TLS-handtrykk for kvar API-førespurnad, så ein tunnel som held seg oppe i ein time ser billegare ut. Den første halvdelen av det er vanlegvis usant. Ein støtta klient brukar på ny ei etablert tilkopling til mange utvekslingar, og ein måling som byggjer ein ny klient for kvart kall måler livssyklusen i staden for vernet. Resten av denne sida handlar om kva du heller bør måle.

Kva gjenbruk eigentleg krev

Standhaftigheit er ein del av HTTP-modellen og ikkje eit triks: éi tilkopling ber fleire førespurnad-svar-utvekslingar. Tilkoplinga sluttar når ei av sidene lukkar ho, når tenaren legg ned ei ledig eller overbelasta tilkopling, eller når eit hovud eller ei protokollregel seier at tilkoplinga ikkje kan brukast på ny. HTTPS legg den samtalen inn i TLS utan å krevje eit nytt handtrykk for kvar utveksling. Så ein andre førespurnad gjer ikkje om att handtrykket til den første førespurnaden, med mindre noko avslutta tilkoplinga i mellomtida.

Gjenbruk har òg eitt vilkår som applikasjonar lett bryt. Ein klient som planlegg å bruke ei tilkopling på ny, må lese heile svarkroppen, og eit svar som blir forlate på halvvegen er den vanlege måten eit tilkoplingbasseng forsvinn på utan at nokon legg merke til det.

Sjekk den støtta klienten til biblioteket og livssyklusen til tilkoplingbassenget i staden for å gå ut frå at bassengbruk er på eller av. Noter òg den framhandla HTTP-versjonen, for HTTP/2 og HTTP/3 handterer gjenbruk av tilkoplingar annleis enn HTTP/1.1. Behandle den framhandla versjonen som ein del av målinga, ikkje som ei fotnote.

Kvifor samanlikninga målar livssyklus

Å lage ein ny klient for kvar operasjon og samanlikne han med ein tunnel som har vore tilkopla i ein time, samanliknar oppsett av tilkoplinga med ein stabil tilstand. Det er ei legitim måling, og det er ikkje HTTPS mot VPN. To køyringar med same klientkonfigurasjon skildrar åtferda betre enn éi, særleg når den første køyringa varmar opp ein oppløysar eller ein tilkoplingcache.

Hald API-operasjonen, tenaren, kontoen og dataa konstante, elles ber samanlikninga meir enn éin variabel. Avgjer på førehand kvar du plasserer tidtakararen, for oppsett, TLS-forhandling, applikasjonskøyring og svarlvering bidreg ulikt til totalen. Éin tidtakar for den første førespurnaden skildrar oppsettet og seier ingenting om den stabile trafikken du faktisk køyrer. Skriv ned grensene til tidtakararen ved sida av tala.

Skil kaldt oppsett frå varme førespurnader

Mål den første førespurnaden skilt frå dei som følgjer. Legg så til det tenesta verkeleg ser: ledige periodar, bylgjer, samtid, svarstorleik og nye tilkoplingar.

Hald sertifikatvalidering og HTTPS påslått på begge vegane, for å fjerne dei måler ein annan tryggleiksdesign og ikkje ein snøggare. Viss tunnelen endrar ruta eller plasseringa til porten, meld den skilnaden skilt i staden for å tilskrive kvar tidsendring kryptering, sidan veg, tap og kø kan dominere ein liten førespurnad. Køyr kvar veg to gonger over same ruta før du dreg ei slutning. Noter den framhandla protokollen og grensene til tidtakararen saman med begge køyringane.

Planlegg for tilkoplinga som blir lukka

Standhaftig tyder ikkje varig. Ein tenar, ein proxy eller ei nettverksendring kan lukke ei tilkopling i ein ledig periode, og klienten må kome seg etter det gjennom åtferda biblioteket hans støttar. Den attkominga har ein tilstandsmaskin: førespurnaden kan ha fullført på tenaren, eller han kan ha mislukkast før tenaren las han, og ein lukka sokkel fortel ikkje kallaren kva som hende. Ein ikkje-idempotent operasjon på den plassen kan ikkje berre spelast av på ny, for ei gjentaking gjer eit ukjent utfall om til ei dobbel skriving. Her oppfører ein varm tunnel og ei varm tilkopling seg likt, sidan begge kan mislukkast i det augneblinken arbeid er i gang.

Bruk den dokumenterte ordninga for nytt forsøk eller idempotens som tenesta har, i staden for ei løkke som opnar sokkelet på ny. Test attkominga uttrykkeleg ved å lukke ei ledig tilkopling og sjå kva klienten gjer etterpå. Å opne eit sokkel på ny gjer ikkje gjentaking av eit tilstandsendrande kall trygt.

Vel grensa først, juster etterpå

Vel nettverksgrensa ut frå tilgangs- og tillitskrava før du optimerer noko. Ein VPN vernar segmentet mellom jamlike partar, medan endepunkta til applikasjonen og alle klartekstsegment utanfor tunnelen framleis tel. Juster så livssyklusen til tilkoplinga innanfor denne grensa. Slutninga om den billegare tunnelen følgjer berre av trua på at kvar førespurnad gjer om att handtrykket, og det er nettopp den trua som blir prøvd her.

Avsnittet om standhaftigheit i RFC 9112 er referansen for kva gjenbruk faktisk lovar, medrekna vilkåra som avsluttar ei tilkopling. Les det ein gong før du stolar på ei måling som ignorerer dei.

Relaterte artiklar