Combien de temps système SSL impose-t-il?
Je sais qu'il n'y a pas de réponse simple et précise, mais existe-t-il un générique? estimation d'ordre de grandeur approximation de la surcharge de cryptage de SSL par rapport à une communication de socket non cryptée? Je parle uniquement du traitement de la communication et du temps de connexion, sans compter le traitement au niveau de l'application.
Mettre à jour
Il y a ne question à propos de HTTPS par rapport à HTTP , mais je suis intéressé par une recherche plus bas dans la pile.
(J'ai remplacé l'expression "ordre de grandeur" pour éviter toute confusion; je l'utilisais comme un jargon informel plutôt que dans le sens formel de CompSci. Bien sûr, si je avait le pensais formellement, comme un vrai geek j'aurais pensé binaire plutôt que décimal! ;-)
Mettre à jour
Par requête dans le commentaire, supposons qu'il s'agisse de messages de bonne taille (de 1 à 10k) via des connexions persistantes. La configuration de la connexion et la surcharge des paquets ne sont donc pas des problèmes importants.
Ordre de grandeur: zéro.
En d'autres termes, votre débit ne sera pas réduit de moitié, ni plus, si vous ajoutez TLS. Les réponses à la question "duplicate" sont largement axées sur les performances des applications et sur leur comparaison avec le temps système SSL. Cette question exclut spécifiquement le traitement des applications et cherche à comparer uniquement les protocoles non SSL à SSL. Bien qu’il soit logique d’avoir une vision globale des performances lors de l’optimisation, ce n’est pas ce que cette question demande.
La surcharge de SSL est la poignée de main. C'est là qu'intervient la cryptographie asymétrique coûteuse. Après négociation, des chiffrements symétriques relativement efficaces sont utilisés. C'est pourquoi il peut être très utile d'activer les sessions SSL pour votre service HTTPS, où de nombreuses connexions sont établies. Pour une connexion de longue durée, cet effet final n'est pas aussi significatif et les sessions ne sont pas aussi utiles.
Voici ne anecdote intéressante. Lorsque Google a fait passer Gmail à HTTPS, aucune ressource supplémentaire n'a été nécessaire. pas de matériel réseau, pas de nouveaux hôtes. Cela n'a augmenté la charge du processeur que d'environ 1%.
Je seconde @erickson: la pénalité de vitesse de transfert de données pure est négligeable. Les processeurs modernes atteignent un débit crypto/AES de plusieurs centaines de MBit/s. Donc, à moins que votre système ne dispose de ressources limitées (téléphone mobile), TLS/SSL est assez rapide pour transmettre des données.
Mais gardez à l'esprit que le cryptage rend la mise en cache et l'équilibrage de charge beaucoup plus difficiles. Cela pourrait entraîner une pénalité de performance énorme.
Mais la configuration de la connexion est vraiment un obstacle pour de nombreuses applications. Sur les connexions à faible bande passante, à perte de paquets élevée et à latence élevée (périphérique mobile à la campagne), les allers-retours supplémentaires requis par TLS peuvent rendre quelque chose de lent en inutilisable.
Par exemple, nous avons dû supprimer l'exigence de cryptage pour accéder à certaines de nos applications Web internes: elles étaient pratiquement inutilisables si elles étaient utilisées depuis la Chine.
En supposant que vous ne comptiez pas la configuration de la connexion (comme vous l'avez indiqué dans votre mise à jour), cela dépend fortement du chiffrement choisi. La surcharge du réseau (en termes de bande passante) sera négligeable. La surcharge du processeur sera dominée par la cryptographie. Sur mon portable Core i5, je peux chiffrer environ 250 Mo par seconde avec RC4 sur un seul cœur. (RC4 est ce que vous devriez choisir pour une performance maximale.) AES est plus lent, fournissant "seulement" environ 50 Mo/s. Donc, si vous choisissez les chiffrements corrects, vous ne réussirez pas à occuper un seul noyau actuel avec la surcharge de cryptage, même si vous avez une ligne 1 Gbit pleinement utilisée. [Edit: RC4 ne doit pas être utilisé car il n'est plus sécurisé. Cependant, la prise en charge matérielle AES est désormais présente dans de nombreux processeurs, ce qui rend le cryptage AES très rapide sur ces plates-formes.]
L'établissement de la connexion est cependant différent. Selon l’implémentation (prise en charge du faux départ TLS, par exemple), des allers-retours s’ajouteront, ce qui peut entraîner des retards importants. De plus, une crypto coûteuse a lieu lors de l'établissement de la première connexion (la CPU susmentionnée ne peut accepter que 14 connexions par cœur et par seconde si vous avez utilisé furtivement des clés de 4096 bits et 100 si vous utilisez des clés de 2048 bits). Lors des connexions suivantes, les sessions précédentes sont souvent réutilisées, évitant ainsi le chiffrement coûteux.
Donc, pour résumer:
Transfert sur connexion établie:
- Retard: presque aucun
- CPU: négligeable
- Bande passante: négligeable
Premier établissement de connexion:
- Retard: allers-retours supplémentaires
- Bande passante: plusieurs kilo-octets (certificats)
- CPU sur le client: moyen
- CPU sur serveur: haut
Établissements de connexion suivants:
- Retard: aller-retour supplémentaire (pas sûr si un ou plusieurs, peut dépendre de la mise en œuvre)
- Bande passante: négligeable
- CPU: presque aucun