Arrêtez. Arrêtez, tout simplement. HTTPS n’est pas plus rapide que HTTP.

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Oui, Lori a encore passé du temps à lire ce qui se dit sur Internet. Et ce qu’elle y a vu met la petite Lori en colère. Cela fait aussi pleurer l’ancienne conceptrice de tests et rédactrice spécialisée dans les technologies que je suis. Vraiment, je déplore aussi bien les excuses avancées pour justifier de tels tests que le titre trompeur.

J’ai lu pas moins de deux comparaisons artificielles entre « HTTPS » et « HTTP » au cours des deux dernières semaines, qui prétendaient démontrer que le protocole HTTP sécurisé est incontestablement plus rapide que son équivalent en clair, HTTP.

Ah, si seulement c’était vrai.

En fait, l’astuce, c’est que les deux comparaisons (et bien d’autres suivront sans doute) mettent en parallèle le protocole HTTP/2 sécurisé et le protocole HTTP/1.1 non sécurisé. Pour reprendre la comparaison susmentionnée : « Le protocole HTTP/1.1 en clair est comparé au protocole HTTP/2 HTTPS chiffré ».

Comme nous le savons déjà tous, HTTP/2 est intrinsèquement plus rapide (de par sa conception) que HTTP/1.1, et ce pour diverses raisons qui n’ont absolument rien à voir avec la sécurité. Le multiplexage, les en-têtes « intelligents » et un flux binaire se conjuguent pour offrir un protocole plus rapide et plus efficace, tout simplement. S’il est probable que l’ajout d’une couche de sécurité (TLS ou SSL) à HTTP/2 entraîne une légère baisse des performances (les mathématiques le confirment), celle-ci ne suffit pas à les ramener aux niveaux auxquels HTTP/1.1 nous a habitués, même sans sécurisation.

Malheureusement, ces résultats sont présentés comme la preuve irréfutable que HTTPS est plus rapide que HTTP. Ce qui est tout simplement faux. L’argument avancé pour ne pas comparer HTTP/2 sécurisé à HTTP/2 en clair est que les navigateurs refusent de prendre en charge HTTP/2 sans sécurisation, et qu’il est donc impossible d’effectuer un tel test. Un test a donc été monté de toutes pièces pour prétendument illustrer les différences, alors qu’en réalité, il ne démontre rien de tel.

Il est vrai que comparer HTTP/2 sécurisé à HTTP/2 non sécurisé serait pour le moins difficile, voire impossible. Bien que HTTP/2 ait renoncé à exiger exclusivement des connexions sécurisées et autorise les communications en clair, tous les principaux navigateurs ont refusé de prendre en charge les communications en clair et ne prennent jusqu’à présent en charge que HTTP/2 sur TLS/SSL. Même des outils en ligne de commande populaires comme curl refusent d’autoriser les connexions HTTP/2 non sécurisées. HTTPS est donc devenu la norme de fait, même si la spécification ne l’impose pas. Mais cela ne signifie pas que l’on peut comparer les deux, puis tirer de ce test des conclusions totalement absurdes qu’un simple calcul mathématique suffit à réfuter.

Voyons, supposons qu’une page web transférée en clair via HTTP/2 mette exactement 1,2 seconde à se charger. Ajoutons maintenant TLS. L’ajout de TLS (ou de SSL, d’ailleurs) implique davantage de traitement, notamment pour le chiffrement et le déchiffrement des données. Même si cela ne prend que 0,3 seconde, cela signifie tout de même que HTTPS est un tout petit peu plus lent que HTTP. Point final. Les mathématiques le prouvent, et elles sont impartiales. Elles n’ont aucun parti pris, le résultat leur importe peu : elles se contentent de dire « voilà ce qu’il en est ».

Et les mathématiques nous disent que si l’on fait X, puis que l’on y ajoute Y, on obtient Z, et que Z sera toujours supérieur à X ou à Y.

Je comprends la volonté d’inciter les gens à adopter HTTP/2, car il est plus rapide et constitue la première véritable « évolution » de HTTP depuis très longtemps, mais cela prend du temps, surtout lorsque cela nécessite de nombreuses mises à niveau et des modifications de l’infrastructure qui entraîneront des perturbations, puisque toutes les équipes, du développement d’applications à l’exploitation, en passant par les réseaux et la sécurité, devront interrompre leurs activités pour effectuer des tests, déployer, puis tester à nouveau. Sans compter les changements nécessaires pour adapter les applications conçues depuis longtemps autour de HTTP/1.1 et des spécifications de son protocole. HTTP/2 change tout. Et son impact s’étend à l’ensemble du centre de données. Même si les passerelles atténuent les difficultés et les perturbations inhérentes à la migration, tout le monde ne voit pas nécessairement de raison impérieuse de prendre le train de HTTP/2 en marche.

Le gain de performances que constateront les entreprises signifie simplement que HTTP/2 fonctionne comme ses concepteurs l’avaient prévu, avec une vitesse et une efficacité accrues. Cela signifie que les entreprises devraient planifier les mises à niveau des applications et de l’infrastructure réseau nécessaires à la migration vers la nouvelle norme, que celle-ci s’effectue ou non par l’intermédiaire de passerelles HTTP . Cela ne signifie pas que HTTPS est plus rapide que HTTP.

Faire des affirmations manifestement fausses pour créer des titres racoleurs sur des performances prétendument supérieures est tout simplement inacceptable. Oui, vous constaterez presque certainement une amélioration des performances en passant de HTTP/1.1 à HTTP/2, même avec l’activation obligatoire de la sécurité. Mais dans aucun monde régi par la logique et les mathématiques cela ne signifie que HTTPS est plus rapide que HTTP. Si vous souhaitez aider les organisations, aidez-les à comprendre comment passer en douceur de l’ancienne norme à la nouvelle. Fournissez-leur des données pertinentes pour élaborer une analyse de rentabilité leur permettant d’adopter les technologies les plus récentes et les plus performantes. Donnez-leur les moyens de démontrer que l’investissement nécessaire pour passer de HTTP/1.x à HTTP/2 sera rentable à long terme.

Proposez des recommandations et des bonnes pratiques, plutôt que des titres accrocheurs dont l’information essentielle est reléguée au second plan.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie