Topel HTTPS proti toplemu VPN: primerjajte isto pot zahteve
HTTPS ne izvede rokovanja pri vsaki zahtevi API, zato topla povezava in topel tunel nista tekmeca. Pred izbiro primerjajte isti vzorec zahtev.
Verjetno ste prebrali, da HTTPS za vsako zahtevo API odpre novo povezavo TCP in novo rokovanje TLS, zato se tunel, ki ostane odprt eno uro, zdi cenejši. Prva polovica te trditve je običajno napačna. Podprt odjemalec znova uporabi že vzpostavljeno povezavo za mnoge izmenjave, meritev, ki pri vsakem klicu zgradi novega odjemalca, pa meri življenjski cikel in ne zaščite. Preostanek te strani opisuje, kaj meriti namesto tega.
Kaj ponovna uporaba v resnici zahteva
Trajnost je del modela HTTP in ne trik: ena povezava nosi več izmenjav zahteve in odgovora. Povezava se konča, ko jo ena od strani zapre, ko strežnik umakne nedejavno ali preobremenjeno povezavo, ali ko glava ali pravilo protokola pove, da povezave ni mogoče znova uporabiti. HTTPS to pogovor vstavi v TLS, ne da bi za vsako izmenjavo zahteval novo rokovanje. Zato druga zahteva ne ponovi rokovanja prve zahteve, razen če je nekaj vmes končalo povezavo.
Ponovna uporaba ima tudi en pogoj, ki ga aplikacije zlahka prelomijo. Odjemalec, ki namerava povezavo znova uporabiti, mora prebrati celotno telo odgovora, odgovor, opuščen na pol poti, pa je običajen način, kako se sklop povezav izgubi, ne da bi kdo opazil.
Preverite podprtega odjemalca knjižnice in življenjski cikel sklopa povezav, namesto da domnevate, da je združevanje vklopljeno ali izklopljeno. Zapišite tudi dogovorjeno različico HTTP, ker HTTP/2 in HTTP/3 obravnavata ponovno uporabo povezav drugače kot HTTP/1.1. Dogovorjeno različico obravnavajte kot del meritve, ne kot opombo.
Zakaj primerjava meri življenjski cikel
Ustvarjanje novega odjemalca za vsako operacijo in njegova primerjava s tunelom, ki je povezan že eno uro, primerja vzpostavitev povezave z ustaljenim stanjem. To je legitimna meritev in ni HTTPS proti VPN. Dva zagona z enako konfiguracijo odjemalca opisujeta vedenje bolje kot eden, zlasti ko prvi zagon ogreje razreševalnik ali predpomnilnik povezav.
Držite operacijo API, strežnik, račun in podatke nespremenjene, sicer primerjava nosi več kot eno spremenljivko. Vnaprej se odločite, kam postavite merilnik časa, ker vzpostavitev, pogajanja TLS, izvajanje aplikacije in dostava odgovora prispevajo k skupnemu času različno. En sam merilnik prve zahteve opiše vzpostavitev in ne pove ničesar o ustaljenem prometu, ki ga dejansko vozite. Zapišite meje merilnika poleg številk.
Ločite hladno vzpostavitev od toplih zahtev
Merite prvo zahtevo ločeno od tistih, ki ji sledijo. Nato dodajte, kar storitev v resnici vidi: obdobja mirovanja, sunke, sočasnost, velikost odgovora in ponovne povezave.
Pustite preverjanje potrdil in HTTPS vklopljeno na obeh poteh, ker njuna odstranitev meri drugačno varnostno zasnovo in ne hitrejše. Če tunel spremeni pot ali lokacijo prehoda, to razliko sporočite ločeno, namesto da bi vsako spremembo časa pripisali šifriranju, saj lahko pot, izgube in čakalna vrsta prevladajo pri majhni zahtevi. Pred sklepanjem zaženite vsako pot dvakrat po isti poti. Zapišite dogovorjeni protokol in meje merilnika pri obeh zagonih.
Računajte na povezavo, ki se zapre
Trajno ne pomeni večno. Strežnik, posrednik ali sprememba omrežja lahko med obdobjem mirovanja zapre povezavo, odjemalec pa si mora opomoči z vedenjem, ki ga njegova knjižnica podpira. Ta obnovitev ima končni avtomat: zahteva se je morda na strežniku dokončala ali pa je spodletela, preden jo je strežnik prebral, in zaprta vtičnica klicatelju ne pove, kaj se je zgodilo. Neidempotentne operacije na tem mestu ni mogoče preprosto predvajati znova, ker ponovitev neznan izid spremeni v dvojni zapis. Tu se topel tunel in topla povezava obnašata enako, ker lahko oba spodletita v trenutku, ko je delo v teku.
Uporabite dokumentirani mehanizem za ponovni poskus ali idempotentnost storitve, namesto zanke, ki znova odpre vtičnico. Obnovitev preizkusite izrecno: zaprite nedejavno povezavo in opazujte, kaj odjemalec stori nato. Ponovno odpiranje vtičnice ne naredi ponovitve klica, ki spreminja stanje, varne.
Najprej izberite mejo, nato prilagodite
Izberite omrežno mejo glede na zahteve dostopa in zaupanja, preden kar koli optimizirate. VPN ščiti segment med svojimi vrstniki, medtem ko končne točke aplikacije in vsak segment v čistem besedilu zunaj tunela še vedno štejejo. Nato prilagodite življenjski cikel povezave znotraj te meje. Sklep o cenejšem tunelu izhaja samo iz prepričanja, da vsaka zahteva ponovi rokovanje, in prav to prepričanje se tu preizkuša.
Razdelek RFC 9112 o trajnosti je referenca za to, kar ponovna uporaba v resnici obljublja, vključno s pogoji, ki končajo povezavo. Preberite ga enkrat, preden zaupate meritvi, ki jih ignorira.