Beschleunigung von scp trotz verhältnismäßig schwacher Hardware

vorhergehende Artikel in: Linux Security
19.01.2023

Im Zuge meiner neuerlichen Experimente mit dem von mir liebevoll so genannten Trump-Board wurde ich mir wieder eines schmerzlichen Defizits dieser (und ähnlicher) Hardware bewusst: der mangelnden Geschwindigkeit beim Kopieren großer Dateien über das Netzwerk.

Die genannten Boards erreichen eine Performance von 900 Gbit/s mittels iperf gemessen - und das sowohl am internen GBit-Netzwerkanschluss wie auch mit UISB3-GBit-Ethernet.Adaptern aus der Grabbelkiste. Schaut man sich die Auslastung des Systems während einer Übertragung einer großen Datei mittels scp oder fuse-ssh jedoch an, so sieht man, dass die Geschwindigkeit nur bei mageren 30 MB pro Sekunde liegt und einer der Kerne zu 100% ausgelastet ist, während sich die anderen langweilen. Das ist natürlich weit von den theoretisch möglichen 100 MB pro Sekunde einer GBit-Verbindung entfernt.

Das ist auch einer der Gründe, warum ich meine Idee eines damit realisierten Raid-Systems nicht weiter verfolgt habe.

Man sieht hieran sehr deutlich, dass eindeutig die CPU der limitierende Faktor ist und nicht - wie man auch hätte annehmen können - die langsame als Massenspeicher benutzte SD-Karte.

Daher machte ich mich auf die Suche nach Möglichkeiten, trotz der Nutzung einer verschlüsselten Datenübertragung die Transferrate zu steigern. Experimente mit der zeitgleichen Kompression strich ich sofort - in dem beschriebenen Szenario ging es ja um Multimediadateien, die bereits optimal komprimiert sind und bei denen daher der Versuch einer Kompression während der Übertragung reine Verschwendung bedeuten würde.

Ich recherchierte statt dessen ob es irgendwie möglich wäre, SSH bzw. scp multi-threaded zu betreiben. Für jemanden, der gerne Experimente macht gibt es so etwas tatsächlich: Diese Lösung ist eine Patchsammlung für OpenSSH, die diverse Cryptoalgorithmen multi-threaded zur Verfügung stellt.

So experimentierfreudig war ich aber nicht, denn ich las in der Dokumentation auch, dass ein neuer Cryptoalgorithmus implementiert wurde, der die Klartext-Daten einfach durchleitet. Dadurch wurde ich darauf aufmerksam, dass man ja bei SSH und scp angeben kann, mit welchem Algorithmus der Kanal verschlüsselt wird.

Daraufhin sah ich mir an, welche Algorithmen zur Verfügung standen (auf beiden Seiten der Verbindung) und probierte alle, die sowohl Client wie auch Server unterstützten aus. Der Server war dabei wie folgt ausgestattet: uname -a Linux 5.15.0-53-generic SMP x86_64 GNU/Linux und ssh -V lieferte OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020 - der Client stellte sich wie folgt dar: uname -a lieferte Linux rock64 4.4.167-1213-rockchip-ayufan-g34ae07687fce SMP aarch64 GNU/Linux und ssh -V lieferte OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1n 15 Mar 2022 als Ergebnis.

Die Ergebnisse gemessen mittels scp und einer 1GB großen Testdatei enthaltend eine MP4-Videodatei waren mit Standard-scp wie oben bereits angegeben 30 MB/s - mit dem schnellsten verfügbaren Algorithmus (in meinem Fall aes256-gcm@openssh.com) erreichte ich dagegen bereits 51 MB/s - eine drastische Steigerung, die zwar immer noch recht weit von der theoretisch erreichbaren maximalen Datenrate entfernt ist, jedoch bei mir den Entschluss reifen ließ, den Algorithmus auf meinem Trump-Board durch einen entsprechenden Eintrag in /etc/ssh/ssh_config als Standardeinstellung fest einzutragen.

Nach diesem erfolgreichen Ausgang des Experiments untersuchte ich das gleiche nochmals auf einem bereits etwas angejahrten Pi Version 3. Hier waren die Steigerungsraten nicht ganz so drastisch, ich konnte aber immerhin noch eine Steigerung von 16 MB/s auf 20 MG/s feststellen.

Zum Abschluss sei nochmals gewarnt: die niedrigere Komplexität und damit der niedrigere Verbrauch von Rechenzeit durch die anderen Cryptoalgorithmen geht beinahe sicher auch mit einer geringeren Stärke der Verschlüsselung einher - daher sollte man gut abwägen, ob man die Geschwindigkeitssteigerung wirklich benötigt und ob die jeweilige Einsatzumgebung sicher und vertrauenswürdig genug dafür ist!

Artikel, die hierher verlinken

Realtex 88x2 unter Linux

12.06.2023

Ich habe aus Gründen ein Ersatzteil gebraucht: einen USB WiFi-Dongle. Er sollte unter Linux funktionieren und als ich einen gefunden hatte, dessen Anschaffungswiderstand mir nicht zu hoch erschien, klickte ich auf "Kaufen"...

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Brian May, Kerry Ellis & Vittorio Grigolo: Bohemian Rhapsody

    19.05.2019

    Eine andere Sicht auf den schönen Queen-Klassiker

    Weiterlesen...

Neueste Artikel

  • sQLshell, SQLite und Redis - oh my!

    Ich habe in letzter Zeit hin und wieder mit der sQLshell und SQLite herumgespielt - Neulich wurde ich gefragt, ob die sQLshell eigentlich auch Redis kann...

    Weiterlesen...
  • bad-certificates Version 3.0.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern wurde um eine weitere Kategorie von Zertifikaten erweitert

    Weiterlesen...
  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.