HTTPS cald față de un VPN cald: comparați aceeași cale de cerere

Ați citit probabil că HTTPS deschide o conexiune TCP nouă și un handshake TLS nou pentru fiecare cerere API, astfel încât un tunel care rămâne activ o oră pare mai ieftin. Prima jumătate a acestei afirmații este de obicei falsă. Un client acceptat refolosește o conexiune deja stabilită pentru multe schimburi, iar un test care construiește un client nou la fiecare apel măsoară ciclul de viață, nu protecția. Restul acestei pagini explică ce să măsurați în schimb.

Ce cere de fapt refolosirea

Persistența face parte din modelul HTTP, nu este un truc: o conexiune transportă mai multe schimburi de cerere și răspuns. Conexiunea se termină când una dintre părți o închide, când serverul retrage o conexiune inactivă sau supraîncărcată, sau când un antet sau o regulă de protocol spune că conexiunea nu poate fi refolosită. HTTPS așază acea conversație în interiorul TLS fără a cere un handshake nou pentru fiecare schimb. Așadar, o a doua cerere nu repetă handshake-ul primei cereri decât dacă ceva a încheiat conexiunea între timp.

Refolosirea are și o condiție pe care aplicațiile o încalcă ușor. Un client care intenționează să refolosească o conexiune trebuie să citească întregul corp al răspunsului, iar un răspuns abandonat la jumătate este modul obișnuit în care un grup de conexiuni dispare fără ca cineva să observe.

Verificați clientul acceptat de bibliotecă și ciclul de viață al grupului de conexiuni în loc să presupuneți că gruparea este activă sau inactivă. Notați și versiunea HTTP negociată, deoarece HTTP/2 și HTTP/3 tratează refolosirea conexiunilor diferit de HTTP/1.1. Tratați versiunea negociată ca parte a măsurării, nu ca notă de subsol.

De ce comparația măsoară ciclul de viață

Crearea unui client nou pentru fiecare operațiune și compararea lui cu un tunel conectat de o oră compară stabilirea conexiunii cu o stare stabilă. Acesta este un test legitim și nu este HTTPS contra VPN. Două rulări cu aceeași configurație de client descriu comportamentul mai bine decât una, mai ales când prima rulare încălzește un rezolvator sau un cache de conexiuni.

Mențineți constante operațiunea API, serverul, contul și datele, altfel comparația poartă mai mult de o variabilă. Decideți dinainte unde plasați cronometrul, deoarece stabilirea, negocierea TLS, execuția aplicației și livrarea răspunsului contribuie diferit la total. Un singur cronometru al primei cereri caracterizează stabilirea și nu spune nimic despre traficul stabil pe care îl rulați efectiv. Notați limitele cronometrului lângă cifre.

Separați stabilirea rece de cererile calde

Măsurați prima cerere separat de cele care urmează. Apoi adăugați ceea ce serviciul vede cu adevărat: perioade de inactivitate, rafale, concurență, dimensiunea răspunsului și reconectări.

Lăsați validarea certificatelor și HTTPS active pe ambele căi, deoarece eliminarea lor măsoară un alt design de securitate, nu unul mai rapid. Dacă tunelul schimbă ruta sau locația gateway-ului, raportați acea diferență separat în loc să atribuiți fiecare schimbare de timp criptării, fiindcă ruta, pierderile și coada pot domina o cerere mică. Rulați fiecare cale de două ori pe aceeași rută înainte de a trage o concluzie. Notați protocolul negociat și limitele cronometrului la ambele rulări.

Planificați pentru conexiunea care se închide

Persistent nu înseamnă permanent. Un server, un proxy sau o schimbare de rețea pot închide o conexiune în timpul unei perioade de inactivitate, iar clientul trebuie să se recupereze prin comportamentul acceptat de biblioteca sa. Acea recuperare are o mașină de stări: cererea poate să se fi finalizat pe server sau poate să fi eșuat înainte ca serverul să o citească, iar un socket închis nu îi spune apelantului care dintre ele s-a întâmplat. O operațiune neidempotentă în acea poziție nu poate fi pur și simplu reluată, deoarece o reluare transformă un rezultat necunoscut într-o scriere duplicată. Aici un tunel cald și o conexiune caldă se comportă la fel, fiindcă ambele pot eșua în momentul în care lucrul este în curs.

Folosiți mecanismul documentat de reîncercare sau de idempotență al serviciului în locul unei bucle care redeschide socketul. Testați recuperarea explicit închizând o conexiune inactivă și observând ce face clientul mai departe. Redeschiderea unui socket nu face sigură repetarea unui apel care schimbă starea.

Alegeți mai întâi granița, apoi reglați

Alegeți granița de rețea pornind de la cerințele de acces și de încredere înainte de a optimiza ceva. Un VPN protejează segmentul dintre partenerii săi, în timp ce punctele finale ale aplicației și orice segment în text clar din afara tunelului contează în continuare. Apoi reglați ciclul de viață al conexiunii în interiorul acelei granițe. Concluzia tunelului mai ieftin decurge doar din convingerea că fiecare cerere repetă handshake-ul, iar această convingere este ceea ce se testează aici.

Secțiunea despre persistență din RFC 9112 este referința pentru ceea ce promite cu adevărat refolosirea, inclusiv condițiile care încheie o conexiune. Citiți-o o dată înainte de a avea încredere într-un test care le ignoră.