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

Il y a une réponse très simple à cela: profilez les performances de votre serveur Web pour voir quelle est la pénalité de performances pour votre situation particulière. Il existe plusieurs outils pour comparer les performances d'un serveur HTTP vs HTTPS (JMeter et Visual Studio viennent à l'esprit) et ils sont assez faciles à utiliser.

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

Comme d'autres l'ont dit, il y aura un certain niveau de surcharge en raison du cryptage, mais cela dépend fortement de:

• Matériel
• Logiciel serveur
• Rapport entre contenu dynamique et contenu statique
• Distance du client au serveur
• Durée de session typique
• Etc (mon préféré)
• Comportement de mise en cache des clients

D'après mon expérience, les serveurs qui sont lourds sur le contenu dynamique ont tendance à être moins impactés par HTTPS parce que le temps passé au chiffrement (surcharge SSL) est insignifiant par rapport au temps de génération de contenu.

Les serveurs qui sont lourds sur un ensemble assez restreint de pages statiques qui peuvent facilement être mises en cache en mémoire souffrent d'un surcoût beaucoup plus élevé (dans un cas, le débit a été perturbé sur un "intranet").

Edit: Un point qui a été soulevé par plusieurs autres est que la négociation SSL est le coût principal de HTTPS. C'est correct, c'est pourquoi la «longueur de session typique» et le «comportement de mise en cache des clients» sont importants.

De nombreuses sessions très courtes signifient que le temps de prise de contact dépassera tous les autres facteurs de performance. Des sessions plus longues signifieront que le coût de la négociation sera engagé au début de la session, mais les demandes ultérieures auront des frais généraux relativement faibles.

La mise en cache du client peut être effectuée en plusieurs étapes, depuis un serveur proxy à grande échelle jusqu'au cache du navigateur individuel. Généralement, le contenu HTTPS ne sera pas mis en cache dans un cache partagé (bien que quelques serveurs proxy puissent exploiter un comportement de type homme du milieu pour y parvenir). De nombreux navigateurs mettent en cache le contenu HTTPS pour la session en cours et souvent sur plusieurs sessions. L'impact de la non-mise en cache ou moins de mise en cache signifie que les clients récupéreront le même contenu plus fréquemment. Il en résulte plus de demandes et de bande passante pour desservir le même nombre d'utilisateurs.

HTTPS nécessite une prise de contact initiale qui peut être très lente. La quantité réelle de données transférées dans le cadre de la prise de contact n'est pas énorme (moins de 5 Ko en général), mais pour les très petites demandes, cela peut être un peu lourd. Cependant, une fois la prise de contact terminée, une forme très rapide de cryptage symétrique est utilisée, de sorte que la surcharge y est minimale. Conclusion: faire beaucoup de courtes demandes 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 dans HTTP / 1.1, vous ferez donc une seule poignée de main, puis de nombreuses 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 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 "étapes" (un aller-retour, vous envoyez une demande, le serveur envoie une réponse), le client n'obtiendra les données qu'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 trivial.

La surcharge est due aux poignées de main SSL, qui sont longues et augmentent considérablement le nombre d'aller-retour requis pour une session HTTPS par rapport à une session HTTP.

Mesurez (à l'aide d'un outil tel que Firebug) les temps de chargement des pages pendant que le serveur est à l'extrémité d'un lien simulé à latence élevée. Il existe des outils pour simuler une liaison à latence élevée - pour Linux, il existe "netem". Comparez HTTP avec HTTPS sur la même configuration.

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

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

Mise à jour de décembre 2014

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

Les résultats pourraient vous surprendre.

Il est important d'avoir une connaissance à jour des performances HTTPS, car l' Autorité de certification Let's Encrypt commencera à émettre 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:

• Calendrier de lancement de Let's Encrypt (16 juin 2015)
• Cryptons les certificats racine et intermédiaires (4 juin 2015)
• Projet d'accord d'abonnement Let's Encrypt (21 mai 2015)

Plus d'informations sur Twitter: @letsencrypt

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

• TLS est-il encore rapide?
• Réseau de navigateur haute performance, Chapitre 4: Sécurité de la couche de transport
• Overclocking SSL
• Anatomie et performances du traitement SSL

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

• Pourquoi HTTPS pour tout? (La norme HTTPS uniquement)
• Let's Encrypt (Internet Security Research Group)
• HTTPS Everywhere (Electronic Frontier Foundation)

Pour résumer, permettez-moi de citer Ilya Grigorik : "TLS a exactement un problème de performances: il n'est pas suffisamment utilisé. Tout le reste peut être optimisé."

Merci à Chris - auteur du benchmark HTTP vs HTTPS - pour ses commentaires ci-dessous.

La première réponse actuelle n'est pas entièrement correcte.

Comme d'autres l'ont souligné ici, https nécessite une négociation et fait donc plus d'allers-retours TCP / IP.

Dans un environnement WAN, la latence devient alors le facteur limitant et non l'augmentation de l'utilisation du processeur sur le serveur.

Gardez à l'esprit que la latence de l'Europe aux États-Unis peut être d'environ 200 ms (temps de torundtrip).

Vous pouvez facilement mesurer cela (pour 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 semblent 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 plus élevé qu'il ne l'aurait été via HTTP.

Il n'y a pas de réponse unique à cela.

Le chiffrement consommera toujours plus de CPU. Cela peut être déchargé sur du matériel dédié dans de nombreux cas, et le coût variera selon l'algorithme sélectionné. 3des est plus cher que AES, par exemple. Certains algorithmes sont plus chers pour le crypteur que pour le décrypteur. Certains ont le coût inverse.

Le coût de la poignée de main est plus cher que la cryptographie en vrac. Les nouvelles connexions consommeront beaucoup plus de CPU. Cela peut être réduit avec la reprise de la session, au prix de garder les anciens secrets de session jusqu'à leur expiration. Cela signifie que les petites demandes d'un client qui ne revient pas pour plus sont les plus chères.

Pour le trafic Internet croisé, vous ne remarquerez peut-être 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 par ligne commutée) que la même page via SSL est plusieurs fois plus lente que via HTTP standard ...

Dans un certain nombre de cas, l'impact sur les performances des poignées de main SSL sera atténué par le fait que la session SSL peut être mise en cache aux deux extrémités (bureau et serveur). Sur les machines Windows par exemple, la session SSL peut être mise en cache jusqu'à 10 heures. 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 peut 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 bureaux, les versions 6 et 7 d'Internet Explorer mettent en cache le contenu statique HTTPS pouvant être mis en cache, 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 j'ai obtenu 16% de différence de temps pour la même image de flickr (233 ko):

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

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

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 QoS sur le chemin (le chemin réseau particulier emprunté du navigateur au serveur), mais il montre l'idée générale: HTTPS est plus lent que HTTP, car il requesres plus d'opérations à terminer (SSL handshaking et encodage / décodage des données).

Voici un excellent article (un peu ancien, mais toujours aussi génial) sur la latence de la prise de contact SSL. M'a aidé à identifier SSL comme la 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

Puisque j'étudie le même problème pour mon projet, j'ai trouvé ces diapositives. Plus ancien mais intéressant:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

Il semble y avoir un cas de bord méchant ici: Ajax sur wifi congestionné.

Ajax signifie généralement que la KeepAlive a expiré après environ 20 secondes. Cependant, le wifi signifie que la connexion ajax (idéalement rapide) doit effectuer 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.

• Regardez: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Lire: https://istlsfastyet.com/

Il existe de nombreux projets qui visent à brouiller les lignes et à rendre HTTPS tout 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 par rapport à l'ancien HTTP simple. En tant que développeur Web, les performances des pages Web sont importantes pour moi et tout ce qui peut ralentir les performances de mes pages Web est un non-non.

Afin de comprendre les implications de performances impliquées, le diagramme ci-dessous vous donne une idée de base de ce qui se passe sous le capot lorsque vous faites une demande de ressource à l'aide de HTTPS.

Comme vous pouvez le voir sur le diagramme ci-dessus, il y a quelques étapes supplémentaires qui doivent être effectuées lors de l'utilisation de HTTPS par rapport à l'utilisation de HTTP simple. Lorsque vous effectuez une demande à l'aide de HTTPS, une négociation 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 des frais généraux.

Afin de comprendre les implications en termes de performances et de voir par moi-même si l'impact sur les performances serait significatif, 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 ce chargement de site en utilisant HTTPS vs HTTP.

Comme vous pouvez le voir dans Voici la vidéo de test, le résultat en utilisant HTTPS a eu un impact sur les temps de chargement de ma page, mais la différence est négligeable et je n'ai remarqué qu'une différence de 300 millisecondes. Il est important de noter que ces délais dépendent de nombreux facteurs, tels que les performances de l'ordinateur, la vitesse de connexion, la charge du serveur et la distance du serveur.

Votre site peut être différent, et il est important de tester soigneusement votre site et de vérifier l'impact sur les performances impliqué dans le passage au HTTPS.

Il existe un moyen de mesurer cela. L'outil d'Apache appelé jmeter mesurera le débit. Si vous configurez un large échantillonnage de votre service avec jmeter, dans un environnement contrôlé, avec et sans SSL, vous devriez 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, donc il sera toujours légèrement plus lent. La terminaison SSL est très gourmande en ressources processeur. Si vous avez des appareils pour décharger SSL, la différence de latence peut être à peine perceptible selon la charge de vos serveurs.

Une différence de performances plus importante est qu'une session HTTPS est ouverte pendant que l'utilisateur est connecté. Une «session» HTTP ne dure que pour une seule demande d'élément.

Si vous gérez 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 HTTP non SLL.

Le HTTPS affecte en effet la vitesse de la page ...

Les citations ci-dessus révèlent la folie de nombreuses personnes concernant la sécurité et la vitesse du site. La prise de contact du serveur HTTPS / SSL crée un blocage initial lors de l'établissement des connexions Internet. Il y a un lent délai avant que quoi que ce soit commence à s'afficher sur l'écran du navigateur de votre visiteur. Ce retard est mesuré en informations du temps jusqu'au premier octet.

Le surdébit d'établissement de liaison HTTPS apparaît dans les informations de temps jusqu'au premier octet (TTFB). Le TTFB commun varie de moins de 100 millisecondes (dans le meilleur des cas) à plus de 1,5 seconde (dans le pire des cas). Mais, bien sûr, avec HTTPS, c'est 500 millisecondes de moins.

Les connexions 3G sans fil aller-retour peuvent durer 500 millisecondes ou plus. Les trajets supplémentaires doublent les retards à 1 seconde ou plus. Il s'agit d'un impact important et négatif sur les performances mobiles. De très mauvaises nouvelles.

Mon conseil, si vous n'échangez pas de données sensibles, vous n'avez pas du tout besoin de SSL, mais si vous aimez un site Web de commerce électronique, vous pouvez simplement activer HTTPS sur certaines pages où des données sensibles sont échangées comme la connexion et le paiement.

Source: Pagepipe

Les navigateurs peuvent accepter le protocole HTTP / 1.1 avec HTTP ou HTTPS, mais les navigateurs 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 rendent HTTP / 2.0, en moyenne, 4 à 5 fois plus rapide que HTTP / 1.1. De plus, la plupart des sites qui implémentent HTTPS le font via le protocole HTTP / 2.0. Par conséquent, HTTPS va presque toujours être plus rapide que HTTP simplement en raison des différents protocoles qu'il utilise généralement. Cependant, si HTTP sur HTTP / 1.1 est comparé à HTTPS sur HTTP / 1.1, alors HTTP est légèrement plus rapide, en moyenne, que HTTPS.

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

HTTPS sur HTTP / 1.1:

• Temps de chargement moyen des pages de 0,47 seconde
• 0,05 seconde plus lent que HTTP sur HTTP / 1.1
• 0,37 secondes plus lent que HTTPS sur HTTP / 2.0

HTTP sur HTTP / 1.1

• Temps de chargement moyen des pages de 0,42 seconde
• 0,05 seconde plus rapide que HTTPS sur HTTP / 1.1
• 0,32 secondes 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