Gibt es eine Möglichkeit, den Verschlüsselungs-/Entschlüsselungsprozess mit SFTP auf mehrere Kerne aufzuteilen?

Gibt es eine Möglichkeit, den Verschlüsselungs-/Entschlüsselungsprozess mit SFTP auf mehrere Kerne aufzuteilen?

Ich befinde mich in einem Fall, in dem der Verschlüsselungsprozess bei einer SFTP-Übertragung einen CPU-Kern maximal auslastet. Meine IO-Bandbreite (Festplatten, Busse und Netzwerk) ist jedoch noch lange nicht ausgelastet.

Allerdings verfügt das betreffende System über mehrere Kerne: Ich möchte diese im Verschlüsselungs-/Entschlüsselungsprozess nutzen.

Ist das möglich? Und wenn ja, wie?

NB: Wenn irgendwie möglich, würde ich gerne Patch-Sets mit Modifikationen vermeiden, die nicht gut genug sind, um in Upstream aufgenommen zu werden OpenSSH.

Antwort1

Nein. Das SFTP-Protokoll bietet nicht viele Möglichkeiten zur Parallelisierung.Originalprotokollerfordert Verschlüsselungs- und MAC-Algorithmen, die nicht innerhalb eines Pakets parallelisiert werden können. OpenSSH unterstütztGCM, das parallelisiert werden kann, aber OpenSSH versucht nicht, innerhalb eines Pakets zu parallelisieren. Obwohl das Protokoll die Parallelisierung der Verarbeitung aufeinanderfolgender Pakete zulässt, tut OpenSSH dies nicht.

Warum parallelisiert OpenSSH nicht? Weil es kompliziert ist, Parallelisierung richtig durchzuführen, und sie nur in bestimmten Szenarien leistungsfördernd ist:

  • In den meisten Szenarien stellt das Netzwerk den Engpass dar, eine Optimierung hinsichtlich der CPU-Zeit ist daher sinnlos.
  • Wenn das System andere Aufgaben ausführt (einschließlich der parallelen Bereitstellung mehrerer SSH-Verbindungen), wirkt sich die Parallelisierung der SSH-Verarbeitung nachteilig auf die Leistung anderer Prozesse aus.
  • Die Parallelisierung hat ihren Preis: Die Arbeitslast muss an die beteiligten Prozessoren übertragen werden, und die Daten müssen zusammengestellt werden, wenn alle Prozessoren fertig sind. Die Synchronisierung ist mit ziemlich hohen Kosten verbunden, sodass die Parallelisierung nur dann von Vorteil ist, wenn jedes Arbeitselement ausreichend groß ist. Bei SSH ist die Parallelisierung innerhalb eines Pakets wahrscheinlich nicht von Vorteil.
  • Eine Parallelisierung der Verarbeitung mehrerer Pakete wäre zwar möglich, hätte jedoch enorme Auswirkungen auf das Design der Software: Anstelle eines einfachen Daten-Streamings müsste es nämlich eine komplexe Schnittstelle zwischen der Datenschicht und der Kryptografieschicht geben.

OpenSSH wurde mit Blick auf die Sicherheit entwickelt und Komplexität ist der Feind der Sicherheit. Daher wäre es völlig untypisch, auch nur über Parallelisierung nachzudenken. Jemand anders hat es jedoch getan:HPN-SSHist eine Reihe von Patches für OpenSSH, die parallele Verarbeitung ermöglichen. Es wird bis heute noch gepflegt.

ARMv8 führt Hardwarebeschleunigung für AES, SHA-1 und SHA-256 ein. Wenn Sie ein ARMv8-Board haben (egal, ob Sie ein 32-Bit- oder ein 64-Bit-System verwenden), stellen Sie sicher, dass Ihre Kryptobibliothek (OpenSSL für OpenSSH) mit ARMv8-Beschleunigung kompiliert ist. Einige Versionen vor ARMv8 verfügen über proprietäre Kryptobeschleunigung, die möglicherweisebereitgestellt durch den Linux-Kernel, aber OpenSSL unterstützt dies nicht standardmäßig (es gab Kernel- und OpenSSL-Patches, aber diese wurden in der Vergangenheit nicht mehr gewartet).

Wenn Sie die HPN-Patches nicht verwenden möchten, können Sie über der SSH-Schicht parallelisieren. Wenn Sie viele kleine Dateien übertragen müssen, kopieren Sie sie in Stapeln und parallelisieren Sie die Stapel. Wenn Sie eine große Datei übertragen müssen, kopieren Sie sie in Blöcken und parallelisieren Sie die Blöcke.

verwandte Informationen