HTTPS nécessite une première poignée de main 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 les très petites requêtes, cela peut être un peu de frais généraux. Cependant, une fois que la poignée de main est faite, une forme très rapide de cryptage symétrique est utilisée, de sorte que la hauteur est minime. En bref: faire beaucoup de requêtes courtes sur HTTPS sera un peu plus lent que HTTP, mais si vous transférez beaucoup de données en une seule fois demande, la différence sera négligeable.

Toutefois, la directive keepalive est le comportement par défaut dans HTTP/1.1, afin de vous faire un unique poignée de main et puis beaucoup de demandes au cours de 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 en être sûr, mais je soupçonne que la différence de performance ne sera pas perceptible.

pour vraiment comprendre comment HTTPS va augmenter 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'après au moins 4 étapes (2 aller-retour). 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 prendre 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 en partie ce décrochage initial lors du chargement d'un site Web HTTPS.

les frais généraux ne sont pas dus au cryptage. Sur un CPU moderne, le cryptage requis par SSL est trivial.

les frais généraux sont dus aux poignées de main SSL, qui sont longues et augmentent considérablement le nombre de voyages nécessaires pour une session HTTPS par rapport à une session HTTP.

mesure (à l'aide d'un outil tel que Firebug) le temps de chargement de la page alors que le serveur est à la fin d'un lien de haute latence simulée. Il existe des outils pour simuler un lien de haute latence - Pour Linux il y a"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 les keepalives HTTP - cela permet au client de réutiliser les sessions SSL, ce qui évite le besoin d'une autre poignée de main
• réduire le nombre de demandes à un minimum - en combinant les ressources dans la mesure du possible (p. ex.js include files, CSS) et encourageant cache côté client
• réduire le nombre de pages chargées, par exemple en chargeant des données non nécessaires dans la page (peut-être dans un élément HTML caché) et en les montrant ensuite en utilisant 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 test HTTP vs HTTPS site Web par AnthumChris : "cette page mesure son temps de chargement sur des connexions HTTP et HTTPS non sécurisées. Les deux pages chargent 360 images uniques, non mises en cache (2,04 Mo total)."

les résultats peuvent vous surprendre.

il est important d'avoir des connaissances à jour sur les performances HTTPS car l'Autorité de certification chiffrons 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:

• chiffrons le calendrier de lancement (16 juin 2015)
• chiffrons les certificats racine et intermédiaire (4 juin 2015)
• Projet nous allons Chiffrer le Contrat d'abonnement au (21 Mai 2015)

plus d'informations sur Twitter: @letsencrypt

pour plus d'informations sur HTTPS et SSL/TLS les performances de voir:

• est-ce que TLS est encore Rapide?
• Haute Performance Du Navigateur De Mise En Réseau, Chapitre 4: Transport Layer Security
• Overclocking SSL
• de l'Anatomie et de la Performance de Traitement SSL

pour plus d'informations sur l'importance d'utiliser HTTPS voir:

• Pourquoi HTTPS pour Tout? (Le HTTPS Standard Uniquement)
• chiffrons (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 performance: il n'est pas utilisé assez largement. Tout le reste peut être optimisé."

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

la dernière réponse n'est pas entièrement correcte.

comme d'autres l'ont fait remarquer ici, https nécessite une prise de main et fait donc plus de trajets aller-retour TCP/IP.

dans un environnement WAN, la latence devient généralement le facteur limitant et non l'utilisation accrue de CPU sur le serveur.

il suffit de garder à l'esprit que la latence de l'Europe vers les États-Unis peut être d'environ 200 ms (temps de torundtrip).

vous pouvez facilement mesurer cela (pour le cas de l'utilisateur unique) avec HTTPWatch .

en plus de tout ce qui a été mentionné jusqu'à présent, veuillez garder à l'esprit que certains (tous? pour des raisons de sécurité, les navigateurs web ne stockent pas le contenu mis en cache obtenu via HTTPS sur le disque dur local. Cela signifie que du point de vue de l'utilisateur, les pages avec 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 requêtes pour du contenu statique sur HTTPS sera plus élevé que ce qu'il aurait été sur HTTP.

il n'y a pas une seule réponse à cela.

consommera toujours plus de CPU. Cela peut être déchargé à 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 coûteux pour l'encryption de que le déchiffreur. Certains ont le coût opposé.

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

pour le trafic internet vous ne pouvez pas remarquer ce coût dans votre débit de données, parce que la bande passante disponible est trop faible. Mais vous remarquerez certainement dans l'utilisation du PROCESSEUR sur un serveur occupé.

je peux vous dire (en tant qu'utilisateur commuté) que la même page sur SSL est plusieurs fois plus lente que via le HTTP régulier...

dans un certain nombre de cas, L'impact des poignées de main SSL sur les performances 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 à considérer est les contenus statiques servis sur HTTPS ne seront pas mis en cache par des serveurs mandataires, ce qui peut réduire les performances de plusieurs utilisateurs accédant au site sur le même serveur mandataire. Cette situation peut être atténuée par le fait que le contenu statique sera mis en cache sur les ordinateurs de bureau, ainsi que par les versions 6 et 7 d'Internet Explorer qui permettent de mettre en cache le contenu statique HTTPS à moins d'instructions contraires (menu Outils/Options Internet/Avancé/sécurité/ne sauvegardez pas 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 kb):

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

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

bien sûr, ces chiffres dépend de nombreux facteurs, tels que l'ordinateur performance, vitesse de connexion, charge du serveur, QoS sur le chemin (le chemin de réseau particulier pris du navigateur au serveur) mais il montre l'idée générale: HTTPS est plus lent puis HTTP, car il nécessite plus d'opérations à compléter (SSL handshaking et encodage/décodage des données).

voici un grand article (un peu vieux, mais toujours génial) sur la latence de la poignée de main SSL. M'a aidé à identifier SSL comme la principale cause de la lenteur pour les clients qui utilisaient mon application au moyen de connexions Internet lentes:

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

comme j'enquête sur le même problème pour mon projet, j'ai trouvé ces diapositives. Plus vieux mais intéressant:

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

est-ce que TLS est encore en jeûne? Oui.

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

il existe de nombreux projets qui visent à brouiller les lignes et à rendre les HTTPS tout aussi rapides. Comme SPDY et mod-spdy .

COMPARAISON DES PERFORMANCES HTTP VS HTTPS

j'ai toujours associé HTTPS avec des temps de chargement de page plus lents par rapport à L'ancien HTTP. En tant que développeur web, la performance des pages web est importante pour moi et tout ce qui ralentira la performance de mes pages web est un non-non.

afin de comprendre les implications de performance 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 pour une ressource en utilisant HTTPS.

comme vous pouvez le voir sur le diagramme ci-dessus, il y a quelques étapes supplémentaires qui doivent avoir lieu lors de L'utilisation de HTTPS par rapport à L'utilisation de HTTP simple. Lorsque vous faites une demande en utilisant HTTPS, une poignée de main doit se produire 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 ne malheureusement assumer certains frais généraux.

afin de comprendre les implications sur le rendement et de voir par moi-même si l'impact sur le rendement serait significatif, j'ai utilisé ce site comme plate-forme d'essai. Je me suis dirigé vers webpagetest.org et utilisé l'outil de comparaison visuelle pour comparer le chargement de ce site en utilisant HTTPS vs HTTP.

comme vous pouvez le voir à partir de voici le résultat Vidéo Test l'utilisation de HTTPS a eu un impact sur ma page les temps de charge, cependant 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 temps dépendent de nombreux facteurs, tels que la performance 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 votre site à fond et de vérifier l'impact de performance impliqué dans le passage à HTTPS.

PEUT-ON AMÉLIORER LA PERFORMANCE? visitez ici pour obtenir des informations détaillées

il semble y avoir un cas de bord désagréable ici: Ajax sur wifi congestionné.

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

il y a un moyen de mesurer ceci. 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 ou sans SSL, vous devriez obtenir une comparaison exacte du coût relatif. Je serais intéressé par vos résultats.

HTTPS a un chiffrement / déchiffrement en tête donc il sera toujours un peu plus lent. La terminaison SSL est très intensive en CPU. Si vous avez des appareils pour décharger SSL, la différence de latences peut être à peine perceptible en fonction de la charge de vos serveurs.

une différence de performance plus importante est qu'une session HTTPS est ouverte ketp alors que l'utilisateur est connecté. Une 'session' HTTP ne dure que pour une seule requête.

, vous êtes à l'exécution d'un site avec un grand nombre d'utilisateurs simultanés, attendre pour acheter beaucoup de mémoire.

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

peuvent accepter le protocole HTTP/1.1 avec HTTP ou HTTPS, mais ils ne peuvent traiter 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, parmi les sites qui implémentent HTTPS, la plupart le font via le protocole HTTP/2.0. Par conséquent, 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é avec HTTPS sur HTTP/1.1, alors HTTP est légèrement plus rapide, en moyenne, que HTTPS.

voici quelques comparaisons que j'ai faites en utilisant Chrome (Ver. 64):

HTTPS sur HTTP / 1.1:

• 0.47 secondes moyenne de temps de chargement de page
• 0.05 secondes plus lente que HTTP sur HTTP / 1.1
• 0.37 secondes plus lente que HTTPS sur HTTP / 2.0

HTTP sur HTTP / 1.1

• 0,42 secondes de temps moyen de chargement de la page
• 0,05 secondes plus rapide que HTTPS sur HTTP / 1.1
• 0,32 seconde plus lente que HTTPS sur HTTP / 2.0

HTTPS over HTTP / 2.0

• 0,10 secondes de temps de charge moyen
• 0.32 secondes plus rapide que HTTP sur HTTP / 1.1
• 0.37 secondes plus rapide que HTTPS sur HTTPS / 1.1