HTTPS à chaud contre VPN à chaud : comparez le même chemin de requête

Vous avez probablement lu qu’HTTPS ouvre une nouvelle connexion TCP et un nouveau handshake TLS pour chaque requête API, si bien qu’un tunnel maintenu pendant une heure paraît moins coûteux. La première moitié de cette affirmation est généralement fausse. Un client pris en charge réutilise une connexion établie pour de nombreux échanges, et un benchmark qui construit un nouveau client à chaque appel mesure le cycle de vie plutôt que la protection. Le reste de cette page décrit ce qu’il faut mesurer à la place.

Ce que la réutilisation exige réellement

La persistance fait partie du modèle HTTP et n’est pas un tour de passe-passe : une connexion transporte plusieurs échanges de requête et de réponse. La connexion se termine quand l’une des deux parties la ferme, quand le serveur retire une connexion inactive ou surchargée, ou quand un en-tête ou une règle de protocole indique que la connexion ne peut pas être réutilisée. HTTPS place cette conversation à l’intérieur de TLS sans exiger un nouveau handshake pour chaque échange. Une deuxième requête ne répète donc pas le handshake de la première, sauf si quelque chose a terminé la connexion entre-temps.

La réutilisation a aussi une condition que les applications cassent facilement. Un client qui compte réutiliser une connexion doit lire le corps complet de la réponse, et une réponse abandonnée à mi-chemin est la manière habituelle dont un pool de connexions disparaît sans que personne ne le remarque.

Vérifiez le client pris en charge par la bibliothèque et le cycle de vie du pool de connexions au lieu de supposer que la mise en pool est activée ou désactivée. Notez aussi la version HTTP négociée, car HTTP/2 et HTTP/3 gèrent la réutilisation des connexions différemment de HTTP/1.1. Traitez la version négociée comme une partie de la mesure, pas comme une note de bas de page.

Pourquoi la comparaison mesure le cycle de vie

Créer un client neuf pour chaque opération et le comparer à un tunnel connecté depuis une heure compare l’établissement de la connexion à un régime stable. C’est un benchmark légitime, et ce n’est pas HTTPS contre VPN. Deux exécutions avec la même configuration de client décrivent mieux le comportement qu’une seule, surtout quand la première exécution réchauffe un résolveur ou un cache de connexions.

Gardez constants l’opération API, le serveur, le compte et les données, sinon la comparaison porte plus d’une variable. Décidez à l’avance où vous placez le chronomètre, car l’établissement, la négociation TLS, l’exécution de l’application et la livraison de la réponse contribuent différemment au total. Un seul chronométrage de la première requête caractérise l’établissement et ne dit rien du trafic stable que vous exploitez réellement. Notez les bornes du chronomètre à côté des chiffres.

Séparer l’établissement à froid des requêtes à chaud

Mesurez la première requête séparément de celles qui suivent. Ajoutez ensuite ce que le service voit réellement : périodes d’inactivité, pics, concurrence, taille de la réponse et reconnexions.

Laissez la validation des certificats et HTTPS activés sur les deux chemins, car les retirer mesure une conception de sécurité différente et non plus rapide. Si le tunnel change la route ou l’emplacement de la passerelle, signalez cette différence séparément au lieu d’attribuer chaque variation de temps au chiffrement, car le chemin, la perte et la file d’attente peuvent dominer une petite requête. Exécutez chaque chemin deux fois sur la même route avant de conclure. Notez le protocole négocié et les bornes du chronomètre avec les deux exécutions.

Prévoir la connexion qui se ferme

Persistant ne veut pas dire permanent. Un serveur, un proxy ou un changement de réseau peut fermer une connexion pendant une période d’inactivité, et le client doit se rétablir grâce au comportement pris en charge par sa bibliothèque. Ce rétablissement a une machine à états : la requête a peut-être abouti sur le serveur, ou elle a peut-être échoué avant que le serveur ne la lise, et une socket fermée ne dit pas à l’appelant ce qui s’est produit. Une opération non idempotente à cette place ne peut pas être simplement rejouée, car un rejeu transforme un résultat inconnu en écriture en double. C’est ici qu’un tunnel chaud et une connexion chaude se comportent de la même manière, puisque les deux peuvent échouer au moment où le travail est en cours.

Utilisez le mécanisme documenté de nouvelle tentative ou d’idempotence du service au lieu d’une boucle qui rouvre la socket. Testez le rétablissement explicitement en fermant une connexion inactive et en observant ce que fait le client ensuite. Rouvrir une socket ne rend pas sûre la répétition d’un appel qui modifie l’état.

Choisir d’abord la frontière, puis régler

Choisissez la frontière réseau à partir des exigences d’accès et de confiance avant d’optimiser quoi que ce soit. Un VPN protège le segment entre ses pairs, tandis que les points de terminaison de l’application et tout segment en clair hors du tunnel comptent encore. Réglez ensuite le cycle de vie de la connexion à l’intérieur de cette frontière. La conclusion du tunnel moins coûteux ne découle que de la croyance selon laquelle chaque requête répète le handshake, et c’est précisément cette croyance qui est testée ici.

La section de RFC 9112 sur la persistance est la référence de ce que la réutilisation promet réellement, y compris les conditions qui terminent une connexion. Lisez-la une fois avant de faire confiance à un benchmark qui les ignore.