HTTPS calent contra VPN calenta: compareu la mateixa ruta de sol·licitud

Probablement heu llegit que HTTPS obre una connexió TCP nova i un handshake TLS nou per a cada sol·licitud d’API, de manera que un túnel que es manté obert una hora sembla més barat. La primera meitat d’això sol ser falsa. Un client compatible reutilitza una connexió establerta per a molts intercanvis, i una prova que crea un client nou a cada crida mesura el cicle de vida, no la protecció. La resta d’aquesta pàgina tracta de què cal mesurar en lloc d’això.

Què exigeix realment la reutilització

La persistència és part del model HTTP, no un truc: una connexió transporta diversos intercanvis de sol·licitud i resposta. La connexió acaba quan qualsevol de les dues parts la tanca, quan el servidor retira una connexió inactiva o sobrecarregada, o quan una capçalera o una regla de protocol diu que la connexió no es pot reutilitzar. HTTPS col·loca aquesta conversa dins de TLS sense exigir un handshake nou per a cada intercanvi. Així, una segona sol·licitud no repeteix el handshake de la primera tret que alguna cosa hagi acabat la connexió entremig.

La reutilització també té una condició que les aplicacions trenquen fàcilment. Un client que vol reutilitzar una connexió ha de llegir el cos complet de la resposta, i una resposta abandonada a mig camí és la manera habitual que el conjunt de connexions desaparegui sense que ningú se n’adoni.

Comproveu el client compatible i el cicle de vida del conjunt de connexions de la biblioteca en lloc de suposar que la reutilització està activada o desactivada. Anoteu també la versió HTTP negociada, perquè HTTP/2 i HTTP/3 gestionen la reutilització de connexions de manera diferent d’HTTP/1.1. Tracteu la versió negociada com a part del mesurament, no com a nota a peu de pàgina.

Per què la comparació mesura el cicle de vida

Crear un client nou per a cada operació i comparar-lo amb un túnel connectat des de fa una hora compara la configuració de la connexió amb l’estat estacionari. Això és una prova legítima, i no és HTTPS contra VPN. Dues execucions amb la mateixa configuració de client descriuen millor el comportament que una, sobretot quan la primera execució escalfa un resolutor o una memòria cau de connexions.

Mantingueu constants l’operació d’API, el servidor, el compte i les dades, o la comparació porta més d’una variable. Decidiu per endavant on situeu el cronòmetre, perquè la configuració, la negociació TLS, l’execució de l’aplicació i el lliurament de la resposta contribueixen de manera diferent al total. Un sol cronòmetre per a la primera sol·licitud caracteritza la configuració i no diu res sobre el trànsit estable que realment executeu. Anoteu els límits del cronòmetre al costat de les xifres.

Separeu la configuració freda de les sol·licituds calentes

Mesureu la primera sol·licitud per separat de les que la segueixen. Després afegiu què veu realment el servei: períodes d’inactivitat, pics, concurrència, mida de la resposta i reconnexions.

Mantingueu la validació de certificats i HTTPS activats en tots dos camins, perquè treure’ls mesura un disseny de seguretat diferent, no un de més ràpid. Si el túnel canvia la ruta o la ubicació de la passarel·la, informeu d’aquesta diferència per separat en lloc d’atribuir cada canvi de temps al xifratge, ja que el camí, la pèrdua i la cua poden dominar una sol·licitud petita. Executeu cada camí dues vegades per la mateixa ruta abans de treure una conclusió. Anoteu el protocol negociat i els límits del cronòmetre amb totes dues execucions.

Planifiqueu la connexió que es tanca

Persistent no vol dir permanent. Un servidor, un proxy o un canvi de xarxa poden tancar una connexió durant un període d’inactivitat, i el client s’ha de recuperar amb el comportament que admet la seva biblioteca. Aquesta recuperació té una màquina d’estats: la sol·licitud pot haver-se completat al servidor, o pot haver fallat abans que el servidor la llegís, i un sòcol tancat no diu al cridador què ha passat. Una operació no idempotent en aquesta posició no es pot simplement reproduir, perquè una repetició converteix un resultat desconegut en una escriptura duplicada. Aquí és on un túnel calent i una connexió calenta es comporten igual, perquè tots dos poden fallar en el moment en què hi ha feina en curs.

Utilitzeu el mecanisme de reintent o d’idempotència documentat del servei en lloc d’un bucle que reobri el sòcol. Proveu la recuperació explícitament: tanqueu una connexió inactiva i observeu què fa el client després. Reobrir un sòcol no fa segur repetir una crida que canvia l’estat.

Trieu primer la frontera i després ajusteu

Trieu la frontera de xarxa a partir dels requisits d’accés i confiança abans d’optimitzar res. Una VPN protegeix el segment entre els seus iguals, mentre que els punts finals de l’aplicació i qualsevol segment en text clar fora del túnel encara importen. Ajusteu després el cicle de vida de la connexió dins d’aquesta frontera. La conclusió del túnel més barat només es desprèn de la creença que cada sol·licitud repeteix el handshake, i aquesta creença és el que es posa a prova aquí.

La secció de persistència de RFC 9112 és la referència del que la reutilització promet realment, incloses les condicions que acaben una connexió. Llegiu-la una vegada abans de confiar en una prova que les ignora.