Existe-il des différences majeures en termes de performances entre http et https? Je me souviens de la lecture de cette HTTPS peut être un cinquième aussi vite que HTTP. Est-ce valable avec la génération actuelle des serveurs/navigateurs? Si oui, existe-il des livres blancs pour la soutenir?
Réponses
Trop de publicités?
Il y a une réponse très simple à cela: le Profil de la performance de votre serveur web pour voir ce que la perte de performance est pour votre situation particulière. Il existe plusieurs outils là-bas pour comparer les performances de un HTTP vs serveur 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, le matériel, les logiciels et la configuration du réseau.
Comme d'autres l'ont dit, il y aura un certain niveau de frais généraux en raison du chiffrement, mais il est très dépendant de:
- Matériel
- Logiciel de serveur
- Ratio de la dynamique vs statique contenu
- Client à distance au serveur
- Typique de la durée de la session
- Etc (mon préféré)
- Comportement de mise en cache des clients
Dans mon expérience, les serveurs qui sont lourdes sur le contenu dynamique ont tendance à être moins touchés par HTTPS parce que le temps passé cryptage SSL (frais généraux) est négligeable par rapport à la génération de contenu en temps.
Les serveurs qui sont lourds sur la signification d'un ensemble assez restreint de pages statiques qui peuvent facilement être mis en cache dans la mémoire souffrent de beaucoup plus de frais généraux (dans un cas, le débit a été havled sur un "intranet").
Edit: Un point qui a été évoqué par plusieurs autres, c'est que SSL handshake est le principal coût de HTTPS. C'est exact, c'est pourquoi "typique de la durée de la session" et "comportement de mise en cache, les clients sont importants.
De nombreux, de très courtes sessions signifie que la poignée de main de temps aura raison de tous les autres facteurs de performance. Des séances plus longues, signifie l'établissement de la liaison des coûts seront engagés au début de la session, mais les demandes suivantes ont relativement peu de frais généraux.
Mise en cache du Client peut être fait à plusieurs étapes, n'importe où à partir d'une grande échelle serveur proxy de l'individu cache du navigateur. Généralement HTTPS contenu ne sera pas mis en cache dans un cache partagé (bien qu'un peu de serveurs proxy peuvent exploiter un man-in-the-middle type de comportement). De nombreux navigateurs cache le contenu HTTPS pour la session en cours et, le plus souvent à travers des sessions. L'impact de la non-mise en cache ou moins la mise en cache signifie que les clients de récupérer le contenu même de plus en plus fréquemment. Il en résulte plus de demandes et de la bande passante de service le même nombre d'utilisateurs.
Graeme Perrow
Points
22249
HTTPS nécessite une première poignée de main qui peut être très lent. Le montant réel de données transférées dans le cadre de la poignée de main n'est pas énorme (moins de 5 ko généralement), mais pour les très petites demandes, cela peut être tout à fait un peu de surcharge. Cependant, une fois que la poignée de main est fait, très rapide en forme de chiffrement symétrique est utilisé, de sorte que la surcharge est minime. Bottom line: faire beaucoup de court demandes sur HTTPS sera un peu plus lent que HTTP, mais si vous transférez un grand nombre de données en une seule requête, la différence sera négligeable.
Toutefois, la directive keepalive est le comportement par défaut dans HTTP/1.1, afin de vous faire une simple 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 le profil de votre site (comme d'autres l'ont suggéré) pour être sûr, mais je pense que la différence de performance ne sera pas perceptible.
twk
Points
6300
Pour vraiment comprendre comment HTTPS permettra d'augmenter votre temps de latence, vous devez comprendre comment les connexions HTTPS sont établies. Voici un joli schéma. La clé est que, au lieu de le client d'obtenir les données après 2 "jambes" (aller-retour, vous envoyez une requête, le serveur envoie une réponse), le client ne sera pas obtenir les données, au moins jusqu'à 4 pattes (2 allers-retours). Donc, si on prend 100 ms pour un paquet pour vous déplacer entre le client et le serveur, votre première demande HTTPS va prendre au moins 500 ms.
Bien sûr, cet effet peut être atténué par la reprise de l'aide de la connexion HTTPS (les navigateurs qui devrait faire), mais il n'explique en partie initiale de décrochage lors du chargement d'un site web HTTPS.
MarkR
Points
37178
La surcharge n'est PAS due pour le chiffrement. Sur un PROCESSEUR récent, le chiffrement requis par le protocole SSL est trivial.
La surcharge est due à la SSL poignées de main, qui sont longues et considérablement augmenter le nombre d'aller-retours nécessaires pour une session HTTPS sur un serveur HTTP.
Mesure (à l'aide d'un outil comme Firebug) le temps de chargement de page alors que le serveur est à la fin d'une simulation de liaison à latence élevée. Des outils existent pour simuler une latence élevée lien - pour Linux, il est "netem". Comparer les HTTP et HTTPS sur le même programme d'installation.
Le temps de latence peut être atténué dans une certaine mesure par:
- S'assurer que votre serveur utilise le protocole HTTP keepalive - cela permet au client de réutiliser les sessions SSL, ce qui évite la nécessité d'une autre poignée de main
- Réduire le nombre de demandes pour aussi peu que possible par la combinaison de ressources lorsque cela est possible (par exemple .js inclure les fichiers, CSS) et en encourageant la mise en cache côté client
- Réduire le nombre de chargement de la page, par exemple en chargeant les données non requises dans la page (peut-être caché dans un élément HTML) puis en montrant à l'aide de script client.
kohlerm
Points
1672
L'actuel haut de réponse n'est pas entièrement correct. Comme d'autres l'ont souligné ici: https nécessite la prise de contact et donc de ne plus tcpip allers-retours. Dans un environnement WAN généralement le temps de latence devient le facteur limitant, et non l'augmentation de l'utilisation du PROCESSEUR sur le serveur. Il suffit de garder à l'esprit que le temps de latence de l'Europe vers les états-unis peuvent être autour de 200ms (torundtrip temps).
vous pouvez facilement mesurer (pour le seul cas d'utilisation) avec HTTPWatch
