Différences entre HTTP et HTTPS

HTTP vs HTTPS en un coup d'œil

Le protocole de transfert hypertexte (HTTP) est un protocole utilisé lorsque votre navigateur web (client) demande des informations à un serveur.

  • L'URL commence par "http://"
  • utilise le port 80 pour la communication
  • il n'est pas sécurisé
  • aucun chiffrement n'est en place
  • aucun certificat n'est requis.

Le protocole de transfert hypertexte sécurisé (HTTPS) est une combinaison du protocole de transfert hypertexte (HTTP) et des protocoles Secure Sockets Layer (SSL) et Transport Layer Security (TLS).

  • L'URL commence par "https://"
  • utilise le port 443 pour la communication
  • est un moyen plus sécurisé d'envoyer des données d'un client à un serveur et inversement
  • la communication est chiffrée
  • des certificats de chiffrement SSL sont requis

Pourquoi le protocole compte lors des tests de charge

Le schéma dans votre URL cible, http:// par rapport à https://, n'est pas cosmétique. Il indique à l'agent de test de charge quel protocole utiliser et sur quel port se connecter par défaut, 80 pour HTTP et 443 pour HTTPS. Tester http://example.com et https://example.com correspond à deux requêtes différentes, potentiellement gérées par deux configurations serveur différentes, alors assurez-vous que l'URL que vous saisissez correspond à celle que vos vrais utilisateurs sollicitent réellement.

Surcoût de la négociation TLS

HTTPS ajoute une négociation TLS avant que la moindre donnée applicative ne soit échangée : le client et le serveur négocient un chiffrement, échangent et valident des certificats, et se mettent d'accord sur des clés de session. Cette négociation coûte des allers-retours et du temps CPU supplémentaires par rapport au HTTP simple, en particulier lors de la première connexion. Deux choses réduisent ce coût en pratique :

  • Réutilisation de connexion (keep-alive) : une fois qu'une connexion TLS est établie, les requêtes suivantes sur la même connexion sautent la négociation, si bien que la majeure partie du surcoût est un coût ponctuel par connexion, et non par requête.
  • Reprise de session : le TLS moderne permet à un client de reprendre une session précédente sans négociation complète, réduisant encore le coût sur les connexions répétées.

À forte concurrence, lorsque de nombreux utilisateurs virtuels ouvrent de nombreuses nouvelles connexions à la fois, les négociations TLS deviennent gourmandes en CPU côté serveur. Si vous comparez les performances HTTP et HTTPS pour le même point de terminaison, attendez-vous à ce que HTTPS paraisse légèrement plus lent sur les tests à forte création de connexions, et ne confondez pas cette différence avec une régression au niveau de l'application.

Validation des certificats

Comme HTTPS nécessite un certificat valide, un agent de test de charge qui se connecte à votre point de terminaison doit pouvoir le valider. Un certificat expiré, auto-signé, ou émis par une autorité de certification privée ou interne peut provoquer des échecs de connexion qui n'ont rien à voir avec les performances réelles de votre application. Si vous constatez des erreurs de connexion uniquement sur la variante HTTPS d'un point de terminaison, vérifiez la chaîne de certificats avant de supposer qu'il s'agit d'un problème de charge ou de capacité.

Redirections entre HTTP et HTTPS

De nombreux sites redirigent tout le trafic HTTP vers HTTPS avec une réponse 301 ou 302. Si vous pointez un test de charge vers l'URL HTTP en vous attendant à ce qu'il atteigne directement votre application, vous mesurez en réalité le saut de redirection plus la requête HTTPS qui suit, ce qui ajoute une latence qui n'existerait pas si vous testiez directement le point de terminaison HTTPS. Pour des chiffres de référence précis, testez l'URL HTTPS finale sur laquelle vos utilisateurs atterrissent. Ne testez directement l'URL HTTP que si vous souhaitez spécifiquement mesurer le comportement de redirection lui-même.

Pour savoir ce qui compte comme une URL cible valide, y compris le préfixe http ou https, voir https://loadfocus.com/docs/fr-fr/knowledge-base/using-valid-url-endpoints.