Quelle est la différence de performance entre https et http pour apache ?

Pour un test rapide (c'est-à-dire sans aucune optimisation !), j'ai activé le site web Ubuntu apache2 par défaut (qui dit simplement "ça marche !") avec http et https (certificat auto-signé) sur une VM Ubuntu 9.04 locale et j'ai exécuté le benchmark d'apache " ab "avec 10 000 requêtes (pas de concurrence). Le client et le serveur se trouvaient sur la même machine/VM :

Résultats pour http (" ab -n 10000 http://ubuntu904/index.html ")

• Durée des tests : 2.664 secondes
• Requêtes par seconde : 3753.69 (#/sec)
• Temps par demande : 0,266 ms

Résultats pour https (" ab -n 10000 https://ubuntu904/index.html ") :

• Durée des tests : 107.673 secondes
• Requêtes par seconde : 92,87 (#/sec)
• Temps par requête : 10,767 ms

Si vous regardez de plus près (par exemple avec tcpdump ou wireshark) la communication tcp/ip d'un demande unique vous verrez que le cas http nécessite 10 paquets entre le client et le serveur alors que le cas https en nécessite 16 : la latence est beaucoup plus élevée avec https. (Pour en savoir plus sur l'importance de la latence aquí )

Ajout de la fonction "keep-alive" ( ab option -k ) au test améliore la situation car toutes les requêtes partagent désormais la même connexion, c'est-à-dire que la surcharge SSL est plus faible - mais https est toujours mesurablement plus lent :

Résultats pour http avec keep-alive (" ab -k -n 10000 http://ubuntu904/index.html ")

• Durée des tests : 1.200 secondes
• Requêtes par seconde : 8334.86 (#/sec)
• Temps par demande : 0,120 ms

Résultats pour https avec keep-alive (" ab -k -n 10000 https://ubuntu904/index.html ") :

• Durée des tests : 2.711 secondes
• Requêtes par seconde : 3688.12 (#/sec)
• Temps par demande : 0,271 ms

Conclusion :

• Dans ce cas de figure simple, https est beaucoup plus lent que http.
• C'est une bonne idée d'activer la prise en charge de https et d'effectuer des analyses comparatives. votre site web pour voir si vous voulez payer pour le surcoût de https.
• Utilisez wireshark pour vous faire une idée de l'overhead SSL.

Sur les serveurs modernes, je dirais que le goulot d'étranglement se situe au niveau du réseau et de l'application, et non du cryptage. Le TLS/SSL dans Apache sera écrit en C assez optimisé, et sera donc éclipsé par votre code PHP, surtout si vous allez faire des choses comme l'accès à la base de données. Le service de fichiers statiques aura probablement un impact plus important, car l'encryptage deviendra une partie plus importante de l'ensemble du processus. Je ne peux pas vous donner de chiffres concrets, mais je serais surpris que cela dépasse les 5 % et que cela soit plutôt de l'ordre de quelques pour cent.

Ne présumez de rien, testez-le vous-même ! Sur vos applications web spécifiques bien sûr.

• ab
• siège
• JMeter

Je constate que sur le matériel moderne, je suis plus susceptible d'être lié aux E/S pour une transaction donnée que d'être lié au processeur (calcul). C'est particulièrement vrai en ce qui concerne la compression et le cryptage. Le cryptage à 128 bits est trivial de nos jours - en général, la construction et la diffusion des pages sortantes sont beaucoup plus difficiles que l'utilisation de SSL, et je n'ai pas remarqué de différence significative de performance entre le trafic http et https depuis quelques années.

Je suis d'accord avec la recommandation de nginx. Dans mes propres tests, il a bien résisté en tant que déchargeur SSL dédié.