Also; Javas SSL-Implementierung ist unter den meisten Umständen nicht besonders schnell. Ich habeBlogs gesehenEs zeigt sich eine spürbare Beschleunigung, wenn eine Java-App zu Solaris verschoben wird, um die Vorteile des Kernel-basierten SSL zu nutzen.
Das ist alles schön und gut auf Hardware von Sun/Oracle (insbesondere auf SPARC-Basis), die über integrierte Beschleuniger verfügt, aber gibt es irgendwelche Informationen dazu, wie eine Java-App funktionieren würde, wenn die Solaris-Installation auf einer handelsüblichen Intel-Box (oder sogar einem VPS) ohne hardwarebasierte Beschleunigung erfolgt?
d. h.: Um wie viel beschleunigt KSSL eine SSL-fähige Java-App auf einer x86-Solaris-Box?
Antwort1
Beachten Sie, dass x86 etwas Beschleunigung für SSL von der CPU erhalten kann. Sie können eine Liste der Beschleuniger erhalten, indem Sie ausführen cryptoadm list -mv. Sogar der Kernel-Softwareanbieter hat einige Optimierungen. Diese Anbieter sind dieselben, die KSSL ausführen.
Um den Unterschied zu messen, führen Sie beispielsweise Folgendes aus:
/usr/sfw/bin/openssl speed rsa2048
/usr/sfw/bin/openssl speed rsa2048 -engine pkcs11
Der erste ist reine Software und der zweite ist ein kernelbeschleunigter Provider, der als PKCS11-Token zugänglich ist. Genau diese beiden schaffen auf meinem alten T1 Niagara 8,4 Zeichen/s gegenüber 19740,0 Zeichen/s. Das ist definitiv ein riesiger Unterschied. Moderne x86-CPUs können beispielsweise AES beschleunigen und soweit ich weiß, wird es in Software-Kernel-Providern verwendet. Prüfen Sie selbst, was der Unterschied ist. Wichtiger sind schnelle asymmetrische Chiffren, da diese beim Herstellen einer Verbindung verwendet werden und mehr CPU-Leistung benötigen ... Webanwendungen schließen Verbindungen häufig.
Übrigens ist KSSL tatsächlich nur ein SSL-Verschlüsselungsproxy im Kernel … die Tatsache, dass es im Kernel passiert, trägt auch zur Geschwindigkeit bei.
Nur zum Vergleich: Auf einer anderen Maschine, etwa im gleichen Alter wie T1, wie oben angegeben, erreicht x86 in VMware bei mir 42,1 Zeichen/s gegenüber 98,6 Zeichen/s bei rsa2048. Also mehr als doppelt so viel Geschwindigkeit.
Antwort2
Der Solaris-Kernel-SSL-Proxy bietet Leistungsverbesserungen basierend auf: 1. Zusammenführung von Daten, sodass weniger read()-Systemaufrufe der Proxy-Anwendung erforderlich sind 2. Auslagerung von Kryptooperationen an Hardware-Kryptoanbieter
Die Verbesserung des ersten Punktes ist im Vergleich zum Offload von Kryptooperationen wahrscheinlich viel geringer. Der zweite Punkt hängt von der Anzahl der von KSSL verwalteten SSL-Sitzungen, der Menge des Datenverkehrs, der zugrunde liegenden Hardware und den von den Clients verwendeten und von KSSL unterstützten Verschlüsselungssammlungen ab.
Auf x86 unter Solaris ist der zweite Punkt derzeit nur für AES-basierte SSL/TLS-Chiffre-Suiten auf Maschinen sichtbar, die den AES-NI Intel-Befehlssatz unterstützen. Dies ist im Wesentlichen Intel Westmere und höher. Derzeit wird auf Intel/AMD-Architekturen keine andere Chiffre beschleunigt, daher gilt dies nur für 2 von KSSL unterstützte Chiffre-Suiten: rsa_aes_256_cbc_sha und rsa_aes_128_cbc_sha. Da es sich nur um eine symmetrische Chiffrebeschleunigung handelt, zahlt es sich eher für Massendatenübertragungen als für kurzlebige Verbindungen mit kleinen Datenmengen aus.
Was die Quantifizierung der Leistungsverbesserung betrifft, liefert ein Test mit openssl(1) speed einige Hinweise, aber man sollte vorsichtig sein, da die OpenSSL PKCS#11-Engine mehrere Schichten durchlaufen muss (OpenSSL-Engine, PKCS#11-Metaslot, PKCS#11-Kernel /dev/crypto-API zum Kernel), sodass der Overhead der Schichten die Messungen ziemlich verfälschen kann, insbesondere bei kleinen Datenmengen. KSSL muss nur eine sehr dünne Schicht durchlaufen (Kernel Crypto Framework API) und es gibt keinen Systemaufruf-Übergangs-Overhead für die eigentliche Verarbeitung von SSL-Datensätzen.