Mainit na HTTPS laban sa mainit na VPN: ihambing ang parehong rutang hinihiling

Malamang nabasa mo na nagbubukas ang HTTPS ng bagong koneksyong TCP at bagong handshake ng TLS para sa bawat kahilingang API, kaya ang tunel na nananatiling bukas nang isang oras ay mukhang mas mura. Ang unang kalahati niyan ay karaniwang mali. Ang sinusuportahang kliyente ay gumagamit muli ng naitatag na koneksyon para sa maraming palitan, at ang benchmark na gumagawa ng bagong kliyente sa bawat tawag ay sumusukat sa siklo ng buhay at hindi sa proteksyon. Ang natitirang bahagi ng pahinang ito ay tungkol sa kung ano ang dapat sukatin sa halip.

Ano ang tunay na kailangan ng muling paggamit

Ang pagtitiyaga ay bahagi ng modelong HTTP at hindi isang trick: ang isang koneksyon ay nagdadala ng maraming palitan ng kahilingan at tugon. Nagtatapos ang koneksyon kapag isinara ito ng alinmang panig, kapag inalis ng server ang isang koneksyong walang gawain o sobra ang karga, o kapag sinabi ng header o tuntunin ng protocol na hindi na magagamit muli ang koneksyon. Inilalagay ng HTTPS ang usapang iyon sa loob ng TLS nang hindi humihingi ng bagong handshake sa bawat palitan. Kaya ang ikalawang kahilingan ay hindi inuulit ang handshake ng unang kahilingan maliban kung may nagtapos sa koneksyon sa pagitan.

Ang muling paggamit ay may isa ring kundisyon na madaling sirain ng mga aplikasyon. Ang kliyenteng nagbabalak gamitin muli ang koneksyon ay dapat basahin ang buong katawan ng tugon, at ang tugon na iniiwan sa kalagitnaan ang karaniwang paraan kung paano nawawala ang pool ng koneksyon nang walang nakakapansin.

Suriin ang sinusuportahang kliyente ng aklatan at ang siklo ng buhay ng pool ng koneksyon sa halip na ipagpalagay na naka-on o naka-off ang pooling. Itala rin ang napagkasunduang bersyon ng HTTP, dahil ang HTTP/2 at HTTP/3 ay iba ang paghawak sa muling paggamit ng koneksyon kaysa sa HTTP/1.1. Ituring ang napagkasunduang bersyon bilang bahagi ng pagsukat, hindi bilang talababa.

Bakit sinusukat ng paghahambing ang siklo ng buhay

Ang paggawa ng bagong kliyente para sa bawat operasyon at paghahambing nito sa tunel na nakakonekta nang isang oras ay naghahambing ng pagtatatag ng koneksyon sa matatag na kalagayan. Iyon ay lehitimong benchmark, at hindi ito HTTPS laban sa VPN. Ang dalawang pagtakbo na may parehong konfigurasyon ng kliyente ay mas mahusay na naglalarawan ng pag-uugali kaysa sa isa, lalo na kapag ang unang pagtakbo ay nagpapainit ng resolver o cache ng koneksyon.

Panatilihing pare-pareho ang operasyong API, ang server, ang account at ang datos, kung hindi ay may dalang higit sa isang baryabol ang paghahambing. Magpasya nang maaga kung saan mo ilalagay ang timer, dahil ang pagtatatag, negosasyon ng TLS, pagpapatupad ng aplikasyon at paghahatid ng tugon ay may iba't ibang ambag sa kabuuan. Ang isang timer ng unang kahilingan ay naglalarawan ng pagtatatag at walang sinasabi tungkol sa matatag na trapiko na aktwal mong pinapatakbo. Isulat ang mga hangganan ng timer sa tabi ng mga bilang.

Ihiwalay ang malamig na pagtatatag sa maiinit na kahilingan

Sukatin ang unang kahilingan nang hiwalay sa mga sumusunod. Pagkatapos ay idagdag ang aktwal na nakikita ng serbisyo: mga panahong walang gawain, pagsabog, sabay-sabay, laki ng tugon at mga muling pagkonekta.

Iwanang bukas ang pagpapatunay ng sertipiko at HTTPS sa dalawang landas, dahil ang pag-alis sa mga ito ay sumusukat ng ibang disenyo ng seguridad at hindi ng mas mabilis. Kung binabago ng tunel ang ruta o ang lokasyon ng gateway, iulat ang pagkakaibang iyon nang hiwalay sa halip na iugnay ang bawat pagbabago ng oras sa encryption, dahil ang landas, pagkawala at pila ay maaaring mangibabaw sa maliit na kahilingan. Patakbuhin ang bawat landas nang dalawang beses sa parehong ruta bago magbigay ng konklusyon. Itala ang napagkasunduang protocol at ang mga hangganan ng timer sa dalawang pagtakbo.

Magplano para sa koneksyong nagsasara

Ang matiyaga ay hindi nangangahulugang permanente. Maaaring isara ng server, proxy o pagbabago ng network ang isang koneksyon sa panahong walang gawain, at kailangang bumangon ng kliyente sa pamamagitan ng pag-uugaling sinusuportahan ng kanyang aklatan. Ang pagbangon na iyon ay may state machine: maaaring natapos na ang kahilingan sa server, o maaaring nabigo ito bago pa ito basahin ng server, at ang saradong socket ay hindi nagsasabi sa tumatawag kung alin ang nangyari. Ang operasyong hindi idempotent sa ganoong kalagayan ay hindi basta maaaring i-replay, dahil ang replay ay ginagawang dobleng pagsulat ang hindi alam na resulta. Dito nag-uugali nang pareho ang mainit na tunel at mainit na koneksyon, dahil pareho silang maaaring mabigo sa sandaling may gawaing nagaganap.

Gamitin ang dokumentadong mekanismo ng muling pagsubok o idempotency ng serbisyo sa halip na loop na muling nagbubukas ng socket. Subukan nang tahasan ang pagbangon: isara ang koneksyong walang gawain at panoorin ang susunod na gagawin ng kliyente. Ang muling pagbukas ng socket ay hindi ginagawang ligtas ang pag-uulit ng tawag na nagbabago ng kalagayan.

Piliin muna ang hangganan, pagkatapos ay iakma

Piliin ang hangganan ng network mula sa mga pangangailangan ng access at pagtitiwala bago i-optimize ang anuman. Pinoprotektahan ng VPN ang segment sa pagitan ng mga kapantay nito, habang ang mga endpoint ng aplikasyon at anumang segment ng plaintext sa labas ng tunel ay mahalaga pa rin. Pagkatapos ay iakma ang siklo ng buhay ng koneksyon sa loob ng hangganang iyon. Ang konklusyon ng mas murang tunel ay sumusunod lamang mula sa paniniwalang inuulit ng bawat kahilingan ang handshake, at iyon ang paniniwalang sinusubok dito.

Ang seksyon ng pagtitiyaga sa RFC 9112 ang sanggunian para sa aktwal na ipinapangako ng muling paggamit, kasama ang mga kundisyong nagtatapos sa koneksyon. Basahin ito nang isang beses bago magtiwala sa benchmark na binabalewala ang mga iyon.