Arrêt. Arrête tout simplement. HTTPS n'est pas plus rapide que HTTP.
Oui, Lori a recommencé à lire Internet. Et ce qu'elle a vu met bébé Lori en colère. Cela fait également pleurer cet ancien concepteur de tests et éditeur technologique. Vraiment, je pleure à la fois devant les excuses avancées pour justifier ces tests et devant le titre trompeur.
J’ai lu pas moins de deux comparaisons artificielles de « HTTPS » et « HTTP » au cours des deux dernières semaines, prétendant démontrer que le HTTP sécurisé est incontestablement plus rapide que son homologue en texte clair, HTTP.
Oh, si seulement c'était vrai.
Voyez, l’astuce est que les deux comparaisons (et sans doute beaucoup d’autres suivront) comparent le HTTP/2 sécurisé avec le HTTP/1.1 non sécurisé. D'après la comparaison mentionnée ci-dessus : « Le texte en clair HTTP/1.1 est comparé au HTTP/2 HTTPS chiffré ».
Comme nous le savons tous déjà, HTTP/2 lui-même est plus rapide (de par sa conception) que HTTP/1.1 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 combinent pour fournir un protocole plus rapide et plus efficace, point final. Même s’il est probable que la superposition de sécurité (TLS ou SSL) sur HTTP/2 entraînera une légère dégradation des performances (car les mathématiques disent que ce sera le cas), cela ne suffira pas à réduire les performances aux niveaux auxquels nous sommes habitués avec HTTP/1.1, même non sécurisé.
Malheureusement, ces résultats sont présentés comme une preuve irréfutable que HTTPS est plus rapide que HTTP. Ce qui n’est tout simplement pas vrai. L'argument contre le test de sécurité HTTP/2 par rapport au texte clair HTTP/2 est que les navigateurs refusent de prendre en charge HTTP/2 sans sécurité, et qu'il n'existe donc aucun moyen d'effectuer un tel test. Un test a donc été imaginé pour prétendre illustrer les différences, mais en fait il ne fait rien de tel.
Il est vrai que comparer HTTP/2 sécurisé avec HTTP/2 non sécurisé serait extrêmement difficile, voire impossible. Alors que HTTP/2 a abandonné son exigence de connexions sécurisées uniquement et autorise le texte en clair, tous les principaux navigateurs ont refusé de prendre en charge le texte en clair et n'ont jusqu'à présent fourni de prise en charge que pour HTTP/2 via TLS/SSL . Même les outils de ligne de commande populaires comme curl refusent d'autoriser les connexions HTTP/2 non sécurisées. Ce qui finit par faire de HTTPS la norme de facto, même si la spécification ne le fait pas. Mais cela ne signifie pas que vous pouvez comparer les deux et ensuite faire des affirmations absolument ridicules basées sur ce test qui sont réfutées par de simples mathématiques.
Voyez, imaginons qu'une page Web transférée via HTTP/2 en texte clair prenne exactement 1,2 seconde à se charger. Ajoutons maintenant TLS. L'ajout de TLS (ou SSL d'ailleurs) signifie qu'il y a plus de traitement en cours, en particulier le cryptage et le décryptage des données. Même si cela ne prend que 0,3 seconde, cela signifie toujours que HTTPS est un tout petit peu plus lent que HTTP. Période. Les mathématiques le disent, et les mathématiques sont pures. Il n’a pas d’agenda, il ne se soucie pas des résultats, il dit simplement « voilà ».
Et les mathématiques disent que si vous faites X et que vous ajoutez ensuite Y, vous obtenez Z, et Z sera toujours supérieur à X ou Y.
Je comprends le désir de pousser les gens vers HTTP/2, car c'est plus rapide et c'est la première véritable « mise à niveau » vers HTTP que nous ayons eu depuis très longtemps, mais cela prend du temps, surtout lorsque cela nécessite de nombreuses mises à niveau et modifications de l'infrastructure qui nécessiteront des perturbations car tout le monde, du développement d'applications aux opérations en passant par les réseaux et la sécurité, doit abandonner ce qu'il fait et tester, déployer et tester à nouveau. Et cela ne tient pas compte des changements dans la modification des applications qui ont longtemps été construites autour de HTTP/1.1 et de sa spécification de 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 la nécessité de sauter dans le train HTTP/2.
L'amélioration des performances que les organisations verront signifie simplement que HTTP/2 fonctionne comme ses concepteurs l'ont prévu, avec une vitesse et une efficacité accrues. Cela signifie que les organisations doivent planifier les mises à niveau de l'infrastructure des applications et du réseau nécessaires pour migrer afin de prendre en charge la nouvelle norme, que ce soit via des passerelles HTTP ou non . Cela ne signifie pas que HTTPS est plus rapide que HTTP.
Faire des déclarations manifestement fausses pour créer des appâts à clics tels que des titres concernant des performances prétendument supérieures est tout simplement inacceptable. Oui, vous constaterez presque certainement une amélioration des performances si vous passez de HTTP/1.1 à HTTP/2, même avec une sécurité forcée. Mais cela ne signifie pas, dans un monde où la logique et les mathématiques existent, que HTTPS est plus rapide que HTTP. Si vous souhaitez aider les organisations, aidez-les à comprendre comment effectuer une transition en douceur de l’ancien au nouveau. Fournissez-leur des données significatives pour qu'ils puissent élaborer une analyse de rentabilisation qui leur permette de passer à la dernière et à la meilleure technologie. Donnez-leur les moyens de montrer que l’investissement dans le passage de HTTP/1.x à HTTP/2 sera rentable à long terme.
Proposez des lignes directrices et des bonnes pratiques, pas des titres accrocheurs ni des pistes enfouies.