Comparaison de la vitesse entre HTTPS et HTTP

Question

Mise à jour 2013-04-25 :

Il s'agit d'une question populaire qui suscite plus d'attention qu'elle ne le devrait probablement. Afin d'empêcher la diffusion de fausses informations, veuillez d'abord lire les paragraphes suivants et l'article qui les accompagne :

La vitesse ne doit pas être un facteur déterminant dans la décision d'utiliser HTTPS ou HTTP. Si vous besoin de HTTPS pour tout de votre site (connexions, inscriptions, cartes de crédit, etc.), vous avez absolument besoin de HTTPS pour tout cela tout le temps.

Veuillez lire SSL n'est pas une question de cryptage par Troy Hunt pour en connaître les raisons.

---

J'envisage de mettre tout mon site de commerce électronique sous https. J'ai décidé d'effectuer un benchmark grossier pour mesurer le temps de téléchargement d'une image de 156 Ko par https par rapport à http, car j'avais lu que https était surchargé par le processus de cryptage.

Le benchmark a été réalisé en utilisant Firebug de Firefox, en transcrivant simplement les temps d'attente et de réception (tous les autres temps sont égaux à 0) dans Excel à partir du panneau Net lors du téléchargement de l'image à partir d'un cache vide.

Mes résultats étaient inattendus :

http: 11.233 seconds
Waiting     Receiving   Total 
1.56        0.88        2.44 
1.55        0.101       1.651 
1.53        0.9         2.43 
1.71        0.172       1.882 
1.9         0.93        2.83 

https: 9.936 seconds
Waiting     Receiving  Total
0.867       1.59       2.457
0.4         1.67       2.07
0.277       1.5        1.777
0.536       1.29       1.826
0.256       1.55       1.806

[Obvious] Observations à partir du benchmark :

• La réponse du serveur est plus rapide mais le temps de téléchargement est plus lent pour https que pour http.
• https est globalement plus rapide d'un montant significatif (~10%).

Quelqu'un peut-il expliquer pourquoi cela se produit ?
Pensez-vous qu'un document (html, css, javascript) donnera des résultats différents ?
Quelqu'un a-t-il une meilleure méthode d'évaluation des téléchargements ?

---

Voici l'image de test :

[image d'essai supprimée]

Informations supplémentaires :

• Le site web est sur un compte d'hébergement partagé chez Godaddy.com.
• Si vous avez la gentillesse d'exécuter votre propre benchmark, n'ajoutez pas le sous-domaine "www"... J'utilise le Root pour le contenu statique de toute façon.
• Utilise IIS7 en mode pipeline intégré.

Edit : benchmark pour 1px GIF (35 bytes) ci-dessous :

http: 2.666 seconds
Waiting     Receiving  Total
0.122       0.31       0.432
0.184       0.34       0.524
0.122       0.36       0.482
0.122       0.34       0.462
0.126       0.64       0.766

https: 2.604 seconds
Waiting     Receiving  Total
0.25        0.34       0.59
0.118       0.34       0.458
0.12        0.34       0.46
0.182       0.31       0.492
0.134       0.47       0.604

Résultats : https est toujours plus rapide, bien que trivialement dans ce cas.

Si quelqu'un voit une faille dans mon benchmark, faites-le moi savoir afin que je puisse poster de meilleurs résultats.

Ainsi, sur l'hébergement mutualisé Godaddy, vers 18h00, sur mon serveur spécifique, le contenu servi en https est plus rapide qu'en http.

Answer 1

Si vous regardez vos temps, http a un plus grand temps d'attente et un plus petit temps de réception. https, par contre, a un plus petit temps d'attente et un plus grand temps de réception. J'interprète cela comme le port http du serveur d'hébergement mutualisé est plus occupé, donc une requête reste plus longtemps dans la file d'attente jusqu'à ce qu'elle soit acceptée par le serveur. Une fois acceptée, la demande est transférée plus rapidement que sur le port https. Sur le port https, il y a moins de trafic sur le serveur, la demande est donc traitée plus rapidement mais le transfert prend plus de temps.

Pour toute comparaison entre https et http, vous devrez tenir compte du temps plus long nécessaire à l'établissement d'un lien entre chaque demande pour https et http. Vous devriez constater une dégradation lorsque vous effectuez de nombreuses petites requêtes.

Answer 2

Vous pouvez également prendre en compte le fait que les documents HTTPS ne seront presque jamais mis en cache ailleurs que dans le navigateur de l'utilisateur. qu'il y a peu de différence pour un utilisateur individuel, mais qu'un document HTTP peut être beaucoup plus rapide pour un grand nombre de personnes partageant un cache. (Il est encore assez courant dans certains endroits que les FAI fassent passer leurs clients leurs clients à travers un cache proxy partagé)

Si cela ne vous dérange pas que les utilisateurs le partagent, bien sûr.

Answer 3

Je pense que la performance plus rapide que vous voyez sur HTTPS n'est pas un hasard.

Remarquez deux choses à propos de vos résultats :

1. HTTP est toujours plus rapide pour le premier résultat "total", mais plus lent pour les totaux suivants.
2. Les résultats HTTPS sont plus cohérents.

Les équilibreurs de charge modernes activent généralement la compression pendant l'utilisation de SSL pour améliorer les performances. S'il est vrai que la poignée de main SSL initiale entraîne une latence importante, les mécanismes utilisés pour maintenir la session (la " poignée de main reprise " et le cryptage symétrique au lieu du cryptage asymétrique) n'ajoutent qu'une latence négligeable. Par conséquent, à moins que vos sessions ne soient courtes, la compression vous apporte plus d'avantages en termes de performances que la maintenance de la session ne vous en fait perdre.

L'idée reçue selon laquelle le SSL entraîne une latence importante est dépassée (sauf si vos sessions sont très courtes). Certains ingénieurs de Google a écrit un article expliquant comment certaines hypothèses précédentes sur le SSL ne sont plus vraies.

Answer 4

Https fonctionne comme suit : Tout d'abord, une poignée de main à 4 voies est effectuée (du moins si je me souviens bien, c'était à 4 voies), le client et le serveur se mettent d'accord sur l'algorithme de cryptage symétrique utilisé par la suite et échangent des certificats (contenant les clés publiques).

Ils échangent une session (clé pour le code symétrique ultérieur) en utilisant la cryptographie à clé publique.

Ils envoient maintenant des messages chiffrés avec la clé de session et un algorithme de chiffrement (3des, aes, rc4, rc5, etc.). Comme les cryptages symétriques ne sont pas des opérations très coûteuses, les différences de temps de téléchargement ne sont pas très importantes.

Le fait que vous ayez moins Le temps d'attente est dû au fait que vous avez probablement moins de trafic sur le port http ou moins de trafic au moment où vous avez fait la demande https par rapport aux demandes http.

Pour optimiser les performances, vous devez donc utiliser le moins de connexions https possible, car la poignée de main est une procédure relativement coûteuse.

Answer 5

Accédez-vous à votre site par le biais d'un proxy ? Si c'est le cas, il se peut que vous constatiez une amélioration des performances parce que le proxy est contourné ou réduit au traitement des demandes de connexion initiales.

Un proxy peut vérifier et mettre en cache le contenu lorsque vous utilisez le protocole HTTP, ce qui réduit les performances.