Varma HTTPS kontraŭ varma VPN: komparu la saman petvojon

Vi verŝajne legis, ke HTTPS malfermas novan TCP-konekton kaj freŝan TLS-manpremon por ĉiu API-peto, do tunelo, kiu restas malfermita dum horo, ŝajnas pli malmultekosta. La unua duono de tio kutime malveras. Subtenata kliento reuzas establitajn konektojn por multaj interŝanĝoj, kaj mezuro, kiu konstruas novan klienton por ĉiu alvoko, mezuras vivociklon anstataŭ protekton. La cetero de ĉi tiu paĝo priskribas, kion mezuri anstataŭe.

Kion reuzado vere postulas

Daŭreco estas parto de la HTTP-modelo, ne artifiko: unu konekto portas plurajn peto-respondajn interŝanĝojn. La konekto finiĝas kiam unu flanko fermas ĝin, kiam la servilo retiras senageman aŭ troŝarĝitan konekton, aŭ kiam kaplinio aŭ protokola regulo diras, ke la konekto ne povas esti reuzata. HTTPS enmetas tiun konversacion ene de TLS sen postuli novan manpremon por ĉiu interŝanĝo. Do dua peto ne ripetas la manpremon de la unua peto, krom se io finis la konekton intertempe.

Reuzado havas ankaŭ unu kondiĉon, kiun aplikaĵoj facile rompas. Kliento, kiu planas reuzi konekton, devas legi la kompletan respondkorpon, kaj respondo forlasita duonvoje estas la kutima maniero, kiel naĝejo de konektoj malaperas sen ke iu rimarkas.

Kontrolu la subtenatan klienton de la biblioteko kaj la vivociklon de la konekta naĝejo, anstataŭ supozi, ke grupiĝo estas ŝaltita aŭ malŝaltita. Notu ankaŭ la intertraktitan HTTP-version, ĉar HTTP/2 kaj HTTP/3 traktas reuzadon de konektoj alie ol HTTP/1.1. Traktu la intertraktitan version kiel parton de la mezuro, ne kiel piednoton.

Kial la komparo mezuras vivociklon

Krei freŝan klienton por ĉiu operacio kaj kompari ĝin kun tunelo, kiu estas konektita jam dum horo, komparas konektan starigon kun stabila stato. Tio estas legitima mezuro, kaj ĝi ne estas HTTPS kontraŭ VPN. Du riveloj kun la sama klienta agordo priskribas la konduton pli bone ol unu, precipe kiam la unua rivelado varmigas solvilon aŭ konektan kaŝmemoron.

Tenu la API-operacion, la servilon, la konton kaj la datumojn konstantaj, alie la komparo portas pli ol unu variablon. Decidu anticipe, kie vi metas la tempomezurilon, ĉar starigo, TLS-intertraktado, aplikaĵa plenumo kaj responda livero kontribuas malsame al la sumo. Unu tempomezurilo de la unua peto karakterizas la starigon kaj diras nenion pri la stabila trafiko, kiun vi efektive funkciigas. Skribu la tempomezurajn limojn apud la nombroj.

Apartigu malvarman starigon de varmaj petoj

Mezuru la unuan peton aparte de la sekvaj. Poste aldonu tion, kion la servo efektive vidas: senagemaj periodoj, eksplodoj, samtemo, respondgrando kaj rekonektoj.

Tenu atestilan validigon kaj HTTPS ŝaltitaj sur ambaŭ vojoj, ĉar forigi ilin mezuras alian sekurecan dezajnon, ne pli rapidan. Se la tunelo ŝanĝas la itineron aŭ la lokon de la enirejo, raportu tiun diferencon aparte anstataŭ atribui ĉiun tempŝanĝon al ĉifrado, ĉar vojo, perdo kaj atendovico povas superregi malgrandan peton. Rulu ĉiun vojon dufoje sur la sama itinero antaŭ ol konkludi. Notu la intertraktitan protokolon kaj la tempomezurajn limojn kun ambaŭ riveloj.

Planu por la konekto, kiu fermiĝas

Daŭra ne signifas porĉiama. Servilo, prokuro aŭ reta ŝanĝo povas fermi konekton dum senagema periodo, kaj la kliento devas resaniĝi per la subtenata konduto de sia biblioteko. Tiu resaniĝo havas statan maŝinon: la peto eble finiĝis sur la servilo, aŭ ĝi malsukcesis antaŭ ol la servilo legis ĝin, kaj fermita soketo ne diras al la alvokanto, kio okazis. Ne-idempotenta operacio en tiu pozicio ne povas esti simple reludita, ĉar reludo transformas nekonatan rezulton en duoblan skribon. Ĉi tie varma tunelo kaj varma konekto kondutas same, ĉar ambaŭ povas malsukcesi en la momento, kiam laboro estas survoje.

Uzu la dokumentitan ripetan aŭ idempotentan mekanismon de la servo anstataŭ buklo, kiu remalfermas la soketon. Testu la resaniĝon eksplicite fermante senageman konekton kaj observante, kion la kliento faras poste. Remalfermi soketon ne igas sekura ripeton de statoŝanĝa alvoko.

Elektu la limon unue, poste agordu

Elektu la retlimon el la aliraj kaj fido-postuloj antaŭ ol optimumigi ion ajn. VPN protektas la segmenton inter siaj samtavolanoj, dum la aplikaĵaj finpunktoj kaj ajna klarteksta segmento ekster la tunelo ankoraŭ gravas. Poste agordu la konektan vivociklon ene de tiu limo. La konkludo pri pli malmultekosta tunelo sekvas nur el la kredo, ke ĉiu peto ripetas la manpremon, kaj ĝuste tiu kredo estas testata ĉi tie.

La sekcio pri daŭreco en RFC 9112 estas la referenco por tio, kion reuzado efektive promesas, inkluzive de la kondiĉoj, kiuj finas konekton. Legu ĝin unufoje antaŭ ol fidi mezuron, kiu ignoras ilin.