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

  • GC und beliebige Präzision in Java

    24.11.2018

    Das letzte Mal, als ich über Vor- und Nachteile der Durchführung mathematischer Berechnungen mit verschiedenen Datentypen schrieb, vernachlässigte ich einen Aspekt, dessen Einfluss und Wichtigkeit von der benutzten Programmiersprache und konkreten Implementierung abhängt:

    Weiterlesen...

Neueste Artikel

  • Assertions für XML-Generierung nutzen

    Neulich habe ich den Entschluss gefasst, meinen Generator für XML aus vorgegebenen XML-Schemas zu erweitern: Ich wollte versuchen, den Generator um Unterstützung für Assertions zu ergänzen

    Weiterlesen...
  • Online Werkzeuge

    Eine Liste interessanter Werkzeuge zur Benutzung "on the road"...

    Weiterlesen...
  • DynamicMBean Wrapper für JavaBeans

    Nachdem ich meine Forschungen zu Annotations und BeanInfos für JavaBeans abgeschlossen hatte, entschloss ich mich ein weiteres Projekt zum Abschluss zu bringen, das bereits geraume Zeit geduldig im Backlog meiner Aufmerksamkeit harrte...

    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.