wake-up-neo.com

Wie viel Aufwand verursacht SSL?

Ich weiß, dass es keine eindeutige Antwort gibt, aber es gibt eine generische größenordnungsschätzung Annäherung für den Verschlüsselungsaufwand von SSL gegenüber unverschlüsselter Socket-Kommunikation? Ich spreche nur von der Kommunikationsverarbeitung und der Verbindungszeit, nicht von der Verarbeitung auf Anwendungsebene.

Update

Es gibt eine Frage zu HTTPS versus HTTP , aber ich bin daran interessiert, im Stapel nach unten zu schauen.

(Ich habe den Ausdruck "Größenordnung" ersetzt, um Verwirrung zu vermeiden. Ich habe ihn eher als informellen Jargon als im formalen Sinne von CompSci verwendet. Natürlich, wenn ich hatte es formal als wahr gemeint habe Aussenseiter, ich hätte eher binär als dezimal gedacht! ;-)

Update

Angenommen, es handelt sich bei einer Anforderung im Kommentar um Nachrichten mit guter Größe (Bereich von 1 KB bis 10 KB) über dauerhafte Verbindungen. Der Verbindungsaufbau und der Paket-Overhead sind also keine nennenswerten Probleme.

164
joel.neely

Größenordnung: Null.

Mit anderen Worten, wenn Sie TLS hinzufügen, wird Ihr Durchsatz nicht halbiert. Die Antworten auf die Frage "Duplizieren" konzentrieren sich stark auf die Anwendungsleistung und wie sich dies im Vergleich zum SSL-Overhead verhält. Diese Frage schließt die Anwendungsverarbeitung ausdrücklich aus und versucht, nur Nicht-SSL mit SSL zu vergleichen. Während es sinnvoll ist, bei der Optimierung einen globalen Blick auf die Leistung zu werfen, stellt sich diese Frage nicht.

Der Hauptaufwand für SSL ist der Handshake. Hier findet die teure asymmetrische Kryptographie statt. Nach der Verhandlung werden relativ effiziente symmetrische Chiffren verwendet. Aus diesem Grund kann es sehr hilfreich sein, SSL-Sitzungen für Ihren HTTPS-Dienst zu aktivieren, bei denen viele Verbindungen hergestellt werden. Für eine langlebige Verbindung ist dieser "Endeffekt" nicht so bedeutend und Sitzungen sind nicht so nützlich.


Hier ist eine interessante Anekdote Als Google Google auf die Verwendung von HTTPS umstellte, waren keine zusätzlichen Ressourcen erforderlich. Keine Netzwerkhardware, keine neuen Hosts. Die CPU-Auslastung wurde nur um ca. 1% erhöht.

173
erickson

I second @erickson: Die reine Datenübertragungsgeschwindigkeitsstrafe ist vernachlässigbar. Moderne CPUs erreichen einen Crypto/AES-Durchsatz von mehreren hundert MBit/s. Sofern Sie sich nicht in einem System mit eingeschränkten Ressourcen (Mobiltelefon) befinden, ist TLS/SSL schnell genug, um Daten zu übertragen.

Beachten Sie jedoch, dass die Verschlüsselung das Caching und den Lastenausgleich erheblich erschwert. Dies kann zu einer enormen Leistungsverschlechterung führen.

Aber der Verbindungsaufbau ist für viele Anwendungen wirklich ein Show Stopper. Bei Verbindungen mit geringer Bandbreite, hohem Paketverlust und hoher Latenz (mobiles Gerät auf dem Land) können die zusätzlichen Roundtrips, die von TLS benötigt werden, dazu führen, dass etwas Langsames zu etwas Unbrauchbarem wird.

Zum Beispiel mussten wir die Verschlüsselungsanforderungen für den Zugriff auf einige unserer internen Web-Apps fallen lassen - sie waren praktisch unbrauchbar, wenn sie aus China verwendet wurden.

39
max

Angenommen, Sie zählen den Verbindungsaufbau nicht (wie in Ihrem Update angegeben), hängt dies stark von der ausgewählten Verschlüsselung ab. Der Netzwerk-Overhead (in Bezug auf die Bandbreite) ist vernachlässigbar gering. Der CPU-Overhead wird von der Kryptographie dominiert. Auf meinem mobilen Core i5 kann ich mit RC4 auf einem einzelnen Core ungefähr 250 MB pro Sekunde verschlüsseln. (RC4 ist das, was Sie für maximale Leistung wählen sollten.) AES ist langsamer und liefert "nur" etwa 50 MB/s. Wenn Sie also die richtigen Chiffren auswählen, wird es Ihnen nicht gelingen, einen einzelnen aktuellen Kern mit dem Krypto-Overhead zu beschäftigen, selbst wenn Sie über eine voll ausgelastete 1-Gbit-Leitung verfügen. [Edit: RC4 sollte nicht verwendet werden, da es nicht mehr sicher ist. AES-Hardwareunterstützung ist jedoch mittlerweile in vielen CPUs vorhanden, wodurch die AES-Verschlüsselung auf solchen Plattformen sehr schnell ist.]

Der Verbindungsaufbau ist jedoch anders. Abhängig von der Implementierung (z. B. Unterstützung für TLS-Fehlstart) werden Roundtrips hinzugefügt, die zu spürbaren Verzögerungen führen können. Außerdem findet beim ersten Verbindungsaufbau eine teure Verschlüsselung statt (die oben genannte CPU kann nur 14 Verbindungen pro Kern und Sekunde akzeptieren, wenn Sie törichterweise 4096-Bit-Schlüssel und 100, wenn Sie 2048-Bit-Schlüssel verwenden). Bei nachfolgenden Verbindungen werden frühere Sitzungen häufig wiederverwendet, um die teure Krypto zu vermeiden.

Also, um zusammenzufassen:

Übertragung bei bestehender Verbindung:

  • Verzögerung: fast keine
  • CPU: vernachlässigbar
  • Bandbreite: vernachlässigbar

Erster Verbindungsaufbau:

  • Verspätung: zusätzliche Hin- und Rückfahrten
  • Bandbreite: mehrere Kilobyte (Zertifikate)
  • CPU auf dem Client: mittel
  • CPU auf dem Server: hoch

Nachfolgende Verbindungsaufbau:

  • Verzögerung: zusätzliche Hin- und Rückfahrt (nicht sicher, ob eine oder mehrere implementiert werden können)
  • Bandbreite: vernachlässigbar
  • CPU: fast keine
11
Jan Schejbal