AES-NI in OpenSSL oder Kernel-Offload: Was brauchen Sie wirklich?

Zwei Etiketten werden verwendet, als wären sie dasselbe: hardwarebeschleunigt und kernel-offloaded. Das eine beschreibt, welche Instruktionen die AES-Routine einer Bibliothek ausführt, das andere beschreibt, wo die Paketverarbeitung stattfindet. Ein VPN kann das erste ohne das zweite haben, das zweite ohne das erste oder beides zugleich. Jede Entscheidung über Leistung muss damit beginnen, zu benennen, welche der beiden Sie tatsächlich ändern.

Zwei Achsen, keine einzige Punktzahl

Die erste Achse ist die Implementierung: Wird der Code, der AES-256-GCM ausführt, an eine Version geleitet, die die dedizierten Instruktionen des Prozessors nutzt, oder an eine portable Routine, die sie als gewöhnliche Arithmetik ausführt. Diese Wahl liegt innerhalb der kryptografischen Bibliothek und wird bei ihrer Initialisierung getroffen.

Die zweite Achse ist die Platzierung: Durchläuft das Paket den Transformationspfad des Kernels, oder liest ein Daemon im Userspace von einem Tunnelgerät, verschlüsselt und schreibt zurück.

Keine Achse schränkt die andere ein. Ein Userspace-VPN auf einer CPU mit AES-Instruktionen kann sie die ganze Zeit nutzen, und ein Kernel-Pfad auf einer CPU ohne sie fällt auf eine Softwareimplementierung zurück. Die Etiketten in Herstellermaterial machen diesen Unterschied selten, weshalb Tuning-Ratschläge, die zwischen den beiden Situationen kopiert werden, so oft nichts bewirken.

Achse eins: Welcher Code verschlüsselt

OpenSSL erkennt Prozessormerkmale während der Initialisierung und nutzt das Ergebnis, um optimierte Codepfade zu wählen, wie die Dokumentation der x86-Fähigkeiten beschreibt. AES-NI ist eine der dokumentierten Fähigkeiten hinter dieser Weiche. Nichts davon verlangt, dass die Bibliothek zu einer Kernelkomponente wird.

Bestätigen Sie, dass das Merkmal für den Prozess sichtbar ist, bevor Sie annehmen, der schnelle Pfad werde genutzt. Unter Linux ist die Quelle das Feld flags in /proc/cpuinfo, und innerhalb eines Gasts spiegelt es wider, was der Hypervisor offenlegt, nicht den Modellnamen des physischen Hosts.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

Der zweite Befehl nennt die in diesem Build geladenen Provider. Er sagt Ihnen nicht, welche Bibliothek der VPN-Dienst gelinkt hat, und ein Host kann zwei OpenSSL-Installationen tragen, während der laufende Prozess nur eine davon nutzt.

Achse zwei: Wo der Paketpfad läuft

Platzierung im Kernel bedeutet, dass die Transformation in der IPsec-Maschinerie des Kernels selbst oder in einem Tunnel-Treiber im Kernel stattfindet, sodass Pakete für jeden Stapel keine Hin-und-zurück-Reise durch einen Userspace-Prozess brauchen. Das kann Kopien und Kontextwechsel einsparen und Arbeit über Kerne verteilen, wie es ein einthreadiger Daemon nicht kann. Es verschiebt auch die Zähler und Traces, die Sie lesen werden, wenn der Durchsatz sinkt, weil die Arbeit nun jenseits einer Grenze geschieht, die Sie nicht kontrollieren. Betrachten Sie das als Debugging-Kosten, nicht nur als Leistungsentscheidung.

Es erzeugt keinen Instruktionssupport, konfiguriert keine Cipher und macht eine bestehende Route nicht funktionsfähig.

Virtualisierung fügt auch auf dieser Achse eine Falte hinzu. Einem Gast kann ein maskiertes CPU-Modell gegeben werden, das Merkmale verbirgt, die der Host hat, und ein verschachtelter Gast sieht womöglich noch weniger. Lesen Sie die Fähigkeitsansicht von innerhalb der Umgebung, in der das VPN tatsächlich läuft, nicht von der Hypervisor-Konsole.

Was jede Wahl kauft und was sie nicht kann

Die praktische Frage ist, wohin die Zeit geht. Wenn ein einzelner beschäftigter Thread, wiederholte Pufferkopien oder ein Systemaufruf pro Paket den Durchsatz begrenzen, kann es helfen, die Transformation auf einen Pfad zu verschieben, der diese Kosten beseitigt, sofern der Kernel die benötigte Transformation implementiert.

Wenn die Grenze ein überlasteter Uplink, ein verlustreicher Pfad, eine lange Umlaufzeit, ein gesättigter Zieldienst oder ein an einen Kern gebundener Thread ist, ändert die Platzierung nichts Wesentliches. Dasselbe gilt für die Instruktionswahl: AES auf dedizierter Hardware kann eine fehlende Route nicht reparieren und hilft nicht, wenn der Tunnel untätig ist, weil die Namensauflösung fehlschlägt.

Wo beides gilt, ergänzen sie sich. Ein Kernel-Pfad kann dieselbe Weiche auf Instruktionsebene innerhalb der Crypto-API des Kernels nutzen, und ein Userspace-Pfad mit gut gewählter Bibliothek nutzt sie bereits. Die Entscheidung ist nicht, welche im Abstrakten schneller ist; sie ist, für welche Kosten Sie Belege haben.

Notieren Sie die vier Fakten, bevor Sie etwas ändern

Notieren Sie das Dienst-Binary und die Kryptobibliothek, gegen die es gelinkt ist, denn diese entscheiden Achse eins. Dann halten Sie die ausgehandelte Datensicherung fest, denn eine Cipher ohne dedizierten Instruktionspfad verhält sich anders als eine mit, und die Suite wird von beiden Seiten gewählt.

Als Nächstes die Fähigkeitsansicht von innerhalb der laufenden Umgebung und schließlich der aktive Paketpfad mit Belegen dafür, dass der Modus, den Sie für aktiv halten, es wirklich ist. Ein geladenes Modul ist kein Beleg dafür, dass ein Profil es nutzt, und eine Konfigurationszeile ist kein Beleg dafür, dass der Kernel sie akzeptiert hat.

Ändern Sie eine Sache und vergleichen Sie dann mit einer gleichbleibenden Last bei denselben Endpunkten und derselben Übertragungsrichtung. Eine Geschwindigkeitsbehauptung, die Sie nicht gemessen haben, ist weniger wert als eine Notiz, dass das Backend nie in Zweifel stand.