Performances HTTP vs HTTPS

StackOverflow https://stackoverflow.com/questions/149274

  •  02-07-2019
  •  | 
  •  

Question

Existe-t-il des différences de performances majeures entre http et https? Il me semble me rappeler avoir lu que HTTPS peut être un cinquième aussi rapide que HTTP. Est-ce valable avec les serveurs Web / navigateurs de la génération actuelle? Si oui, y a-t-il des livres blancs pour le soutenir?

Était-ce utile?

La solution

La réponse à cette question est très simple: Définissez les performances de votre serveur Web afin de déterminer les conséquences négatives sur les performances de votre situation. Il existe plusieurs outils sur le marché. pour comparer les performances d’un serveur HTTP vs HTTPS (JMeter et Visual Studio me viennent à l’esprit) et elles sont relativement simples à utiliser.

Personne ne peut vous donner une réponse significative sans quelques informations sur la nature de votre site Web, de votre matériel, de vos logiciels et de votre configuration réseau.

Comme d'autres l'ont déjà dit, le chiffrement entraînera un certain surcroît de travail, mais il dépend fortement:

  • matériel
  • Logiciel serveur
  • Ratio contenu dynamique / contenu statique
  • Distance du client au serveur
  • Durée de session typique
  • Etc (mon favori personnel)
  • Comportement en cache des clients

D'après mon expérience, le protocole HTTPS a moins d'impact sur les serveurs gourmands en contenu dynamique, car le temps passé à chiffrer (temps système SSL) est insignifiant par rapport au temps de génération de contenu.

Les serveurs qui consomment très peu de pages statiques pouvant facilement être mises en cache en mémoire souffrent d'une surcharge beaucoup plus importante (dans un cas, le débit a été réduit à néant sur un "intranet").

Modifier: Plusieurs autres points ont soulevé le fait que la négociation SSL est le coût principal du protocole HTTPS. C’est vrai, c’est pourquoi "durée de session typique" et "comportement de mise en cache des clients". sont importants.

De nombreuses sessions très courtes signifient que le temps passé en contact submergera tous les autres facteurs de performance. Des sessions plus longues impliqueront des coûts de prise de contact au début de la session, mais les demandes ultérieures entraîneront des frais généraux relativement faibles.

La mise en cache du client peut être effectuée à plusieurs étapes, du serveur proxy à grande échelle au cache de navigateur individuel. En général, le contenu HTTPS ne sera pas mis en cache dans un cache partagé (bien que quelques serveurs proxy puissent exploiter un comportement de type intermédiaire dans ce but). De nombreux navigateurs mettent en cache le contenu HTTPS pour la session en cours et souvent entre les sessions. L'impact de la non-mise en cache ou de la réduction de la mise en cache signifie que les clients récupéreront le même contenu plus fréquemment. Cela se traduit par davantage de demandes et de bande passante pour desservir le même nombre d'utilisateurs.

Autres conseils

HTTPS nécessite une poignée de main initiale qui peut être très lente. La quantité réelle de données transférées dans le cadre de la poignée de main n'est pas énorme (moins de 5 ko en général), mais pour de très petites requêtes, cela peut être un peu long. Cependant, une fois la poignée de main terminée, une forme très rapide de cryptage symétrique est utilisée, de sorte que les frais généraux sont minimes. En bout de ligne: faire beaucoup de demandes courtes via HTTPS sera un peu plus lent que HTTP, mais si vous transférez beaucoup de données en une seule demande, la différence sera insignifiante.

Cependant, keepalive est le comportement par défaut de HTTP / 1.1. Vous devrez donc établir une liaison unique , puis un grand nombre de demandes sur la même connexion. Cela fait une différence significative pour HTTPS. Vous devriez probablement profiler votre site (comme d'autres l'ont suggéré) pour vous en assurer, mais je soupçonne que la différence de performances ne sera pas perceptible.

Pour vraiment comprendre comment HTTPS augmentera votre temps de latence, vous devez comprendre comment les connexions HTTPS sont établies. Voici un joli diagramme . La clé est qu’au lieu que le client obtienne les données après 2 "jambes". (un aller-retour, vous envoyez une demande, le serveur envoie une réponse), le client ne recevra pas de données avant au moins 4 étapes (2 allers-retours). Ainsi, s'il faut 100 ms pour qu'un paquet se déplace entre le client et le serveur, votre première requête HTTPS prendra au moins 500 ms.

Bien sûr, cela peut être atténué en réutilisant la connexion HTTPS (ce que les navigateurs devraient faire), mais cela explique une partie de ce blocage initial lors du chargement d’un site Web HTTPS.

La surcharge n'est PAS due au cryptage. Sur un processeur moderne, le cryptage requis par SSL est simple.

La surcharge est due aux liaisons SSL, qui sont longues et augmentent considérablement le nombre d'allers et retours nécessaires pour une session HTTPS sur une session HTTP.

Mesurez (à l'aide d'un outil tel que Firebug) les temps de chargement de la page lorsque le serveur se trouve à la fin d'un lien simulé à latence élevée. Il existe des outils pour simuler un lien à latence élevée - pour Linux, il existe "netem". Comparez HTTP avec HTTPS dans la même configuration.

La latence peut être atténuée dans une certaine mesure par:

  • S'assurer que votre serveur utilise HTTP keepalives - cela permet au client de réutiliser des sessions SSL, ce qui évite le recours à une autre poignée de main
  • Réduire le plus petit nombre possible de demandes - en combinant les ressources autant que possible (par exemple, les fichiers d'inclusion .js, CSS) et en encourageant la mise en cache côté client
  • Réduisez le nombre de chargement de pages, par exemple en chargeant des données non requises dans la page (peut-être dans un élément HTML masqué), puis en les affichant à l'aide du script client.

Mise à jour de décembre 2014

Vous pouvez facilement tester la différence entre les performances HTTP et HTTPS dans votre propre navigateur à l'aide du Test HTTP vs HTTPS site Web par AnthumChris : «Cette page mesure le temps de chargement de ce dernier sur des connexions HTTP non sécurisées et cryptées HTTPS. Les deux pages chargent 360 images uniques non mises en cache (2,04 Mo au total). "

Les résultats risquent de vous surprendre.

Il est important de disposer de connaissances à jour sur les performances HTTPS car l'autorité de certification Encrypt démarre. Nous avons émis des certificats SSL gratuits, automatisés et ouverts à l'été 2015, grâce à Mozilla, Akamai, Cisco, Electronic Frontier Foundation et IdenTrust.

Mise à jour de juin 2015

Mises à jour sur Let’s Encrypt - Arrivée en septembre 2015:

Plus d'infos sur Twitter: @letsencrypt

Pour plus d'informations sur les performances HTTPS et SSL / TLS, voir:

Pour plus d'informations sur l'importance d'utiliser HTTPS, voir:

En résumé, permettez-moi de citer Ilya Grigorik : " TLS a exactement un problème de performances: ce n'est pas le cas. largement utilisé. Tout le reste peut être optimisé. "

Merci à Chris - auteur de la Test HTTP vs HTTPS - pour ses commentaires ci-dessous.

La réponse actuelle maximale n'est pas tout à fait correcte.

Comme d'autres l'ont fait remarquer ici, https nécessite une prise de contact et multiplie donc les allers-retours TCP / IP.

Dans un environnement de réseau étendu, la latence devient généralement le facteur limitant et non l’utilisation accrue de la CPU sur le serveur.

N'oubliez pas que le temps de latence entre l'Europe et les États-Unis peut être d'environ 200 ms (temps de transition).

Vous pouvez facilement mesurer cela (dans le cas d'un utilisateur unique) avec HTTPWatch .

En plus de tout ce qui a été mentionné jusqu'à présent, veuillez garder à l'esprit que certains (tous?) navigateurs Web ne stockent pas le contenu mis en cache obtenu via HTTPS sur le disque dur local pour des raisons de sécurité. Cela signifie que, du point de vue de l'utilisateur, les pages contenant beaucoup de contenu statique sembleront se charger plus lentement après le redémarrage du navigateur, et du point de vue de votre serveur, le volume de demandes de contenu statique via HTTPS sera supérieur à celui qu'il aurait été via HTTP.

Il n'y a pas une seule réponse à cette question.

Le cryptage consommera toujours plus de ressources processeur. Ceci peut souvent être déchargé sur du matériel dédié et le coût varie en fonction de l'algorithme sélectionné. 3des est plus cher que l'AES, par exemple. Certains algorithmes sont plus coûteux pour le crypteur que pour le décrypteur. Certains ont le coût opposé.

Le coût de la négociation est plus coûteux que le chiffrement en masse. Les nouvelles connexions consomment beaucoup plus de ressources processeur. Cela peut être réduit avec la reprise de session, au prix de garder les anciens secrets de session jusqu'à leur expiration. Cela signifie que les petites demandes d'un client qui n'en revient pas davantage sont les plus chères.

Pour le trafic Internet croisé, il est possible que vous ne remarquiez pas ce coût dans votre débit de données, car la bande passante disponible est trop faible. Mais vous le remarquerez certainement dans l’utilisation du processeur sur un serveur occupé.

Je peux vous dire (en tant qu'utilisateur dialup) que la même page via SSL est plusieurs fois plus lente que via HTTP classique ...

Dans un certain nombre de cas, l’impact de la négociation SSL sur les performances sera atténué par le fait que la session SSL peut être mise en cache des deux côtés (bureau et serveur). Sur les machines Windows, par exemple, la session SSL peut être mise en cache pendant 10 heures maximum. Voir http://support.microsoft.com/kb/247658/EN-US. Certains accélérateurs SSL auront également des paramètres vous permettant de régler l’heure de mise en cache de la session.

Un autre impact à prendre en compte est que le contenu statique servi via HTTPS ne sera pas mis en cache par les mandataires, ce qui pourrait réduire les performances de plusieurs utilisateurs accédant au site via le même proxy. Cela peut être atténué par le fait que le contenu statique sera également mis en cache sur les ordinateurs de bureau, le contenu statique HTTPS en cache d'Internet Explorer versions 6 et 7, sauf indication contraire (Menu Outils / Options Internet / Avancé / Sécurité / Ne pas enregistrer les pages cryptées. sur le disque).

J'ai fait une petite expérience et obtenu une différence de temps de 16% pour la même image provenant de flickr (233 kb):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

entrer la description de l'image ici

Bien sûr, ces chiffres dépendent de nombreux facteurs, tels que les performances de l'ordinateur, la vitesse de connexion, la charge du serveur, la qualité de service sur le chemin d'accès (le chemin réseau particulier emprunté du navigateur au serveur), mais cela montre l'idée générale: HTTPS est plus lent que HTTP , car il lui faut plus d’opérations à compléter (protocole de transfert SSL et encodage / décodage des données).

Voici un excellent article (un peu ancien, mais toujours excellent) sur la latence de négociation SSL. M'a aidé à identifier SSL comme principale cause de lenteur pour les clients qui utilisaient mon application via des connexions Internet lentes:

http://www.semicomplete.com/blog/geekery/ssl- latency.html

Comme je suis en train d’examiner le même problème pour mon projet, j’ai trouvé ces diapositives. Plus vieux mais intéressant:

http://www.cs.nyu.edu/ artg / recherche / comparaison / comparaison_slides / sld001.htm

Il semble y avoir un cas délicat ici: Ajax sur un réseau wifi encombré.

Ajax signifie généralement que KeepAlive a expiré après 20 secondes, par exemple. Cependant, le wifi signifie que la connexion ajax (idéalement rapide) doit faire plusieurs allers-retours. Pire encore, le wifi perd souvent des paquets et il y a des retransmissions TCP. Dans ce cas, HTTPS fonctionne vraiment très mal!

  

TLS est-il encore rapide? Oui.

De nombreux projets visent à brouiller les lignes et à rendre le protocole HTTPS aussi rapide. Comme SPDY et mod-spdy .

  

COMPARAISON DES PERFORMANCES HTTP VS HTTPS

J'ai toujours associé HTTPS à des temps de chargement de page plus lents que si vous utilisiez du vieux HTTP ordinaire. En tant que développeur Web, la performance des pages Web est importante pour moi et tout ce qui peut ralentir les performances de mes pages Web est un non-droit.

Afin de comprendre les implications en termes de performances, le diagramme ci-dessous vous donne une idée de base de ce qui se passe sous le capot lorsque vous faites une demande pour une ressource utilisant HTTPS.

entrer la description de l'image ici

Comme vous pouvez le constater dans le diagramme ci-dessus, l'utilisation de HTTPS nécessite quelques étapes supplémentaires par rapport à l'utilisation d'un protocole HTTP simple. Lorsque vous faites une demande en utilisant HTTPS, une poignée de main doit avoir lieu afin de vérifier l'authenticité de la demande. Cette poignée de main est une étape supplémentaire par rapport à une requête HTTP et entraîne malheureusement une surcharge.

Afin de comprendre les implications en termes de performances et de voir par moi-même si l'impact sur les performances serait important ou non, j'ai utilisé ce site comme plate-forme de test. Je me suis dirigé vers webpagetest.org et j'ai utilisé l'outil de comparaison visuelle pour comparer le chargement de ce site en utilisant HTTPS et HTTP.

Comme vous pouvez le voir sur cliquez ici pour obtenir des informations détaillées

Il existe un moyen de mesurer cela. L'outil d'Apache appelé jmeter mesurera le débit. Si vous configurez un large échantillon de votre service avec jmeter, dans un environnement contrôlé, avec et sans SSL, vous devez obtenir une comparaison précise du coût relatif. Je serais intéressé par vos résultats.

HTTPS a une surcharge de cryptage / décryptage, il sera donc toujours un peu plus lent. La terminaison SSL est très gourmande en ressources CPU. Si vous avez des périphériques pour décharger SSL, la différence de latence peut être à peine perceptible en fonction de la charge de vos serveurs.

Une différence de performances plus importante réside dans le fait qu’une session HTTPS est ouverte sur ketp lorsque l’utilisateur est connecté. Une "session" HTTP ne dure que pour une demande d'élément unique.

Si vous exécutez un site avec un grand nombre d'utilisateurs simultanés, attendez-vous à acheter beaucoup de mémoire.

Cela va presque certainement être vrai étant donné que SSL nécessite une étape de cryptage supplémentaire qui n'est tout simplement pas requise par le protocole HTTP non-SLL.

Les navigateurs peuvent accepter le protocole HTTP / 1.1 avec HTTP ou HTTPS, mais ils ne peuvent gérer que le protocole HTTP / 2.0 avec HTTPS. Les différences de protocole entre HTTP / 1.1 et HTTP / 2.0 font que HTTP / 2.0 est en moyenne 4 à 5 fois plus rapide que HTTP / 1.1. En outre, parmi les sites qui implémentent HTTPS, la plupart le font via le protocole HTTP / 2.0. Par conséquent, le protocole HTTPS sera presque toujours plus rapide que HTTP simplement en raison du protocole différent qu’il utilise généralement. Cependant, si HTTP sur HTTP / 1.1 est comparé à HTTPS sur HTTP / 1.1, HTTP est légèrement plus rapide, en moyenne, que HTTPS.

Voici quelques comparaisons que j'ai effectuées avec Chrome (version 64):

HTTPS sur HTTP / 1.1:

  • Temps de chargement moyen d'une page de 0,47 seconde
  • 0,05 seconde plus lent que HTTP sur HTTP / 1.1
  • 0,37 seconde plus lent que HTTPS sur HTTP / 2.0

HTTP sur HTTP / 1.1

  • Temps de chargement moyen d'une page de 0,42 seconde
  • 0,05 seconde plus rapide que HTTPS sur HTTP / 1.1
  • 0,32 seconde plus lent que HTTPS sur HTTP / 2.0

HTTPS sur HTTP / 2.0

  • temps de chargement moyen de 0,10 seconde
  • 0,32 seconde plus rapide que HTTP sur HTTP / 1.1
  • 0,37 seconde plus rapide que HTTPS sur HTTPS / 1.1
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top