Am 20.11.2013 09:26, schrieb Harald Weidner:
Laut SSH Manpage wird hier gzip verwendet. | -C Requests compression of all data (including stdin, stdout, | -stderr, and data for forwarded X11 and TCP connections). | The compression algorithm is the same used by gzip(1), and the | "level" can be controlled by the CompressionLevel option for | protocol version 1. Compression is desirable on modem lines and | other slow connections, but will only slow down things on fast | networks. The default value can be set on a host-by-host basis | in the configuration files; see the Compression option.
Das bringt aber bei weitem nicht die Komprimierung, die ein gzip an der Kommandozeile bringt. Warum, weiß ich nicht, aber es ist experimentell ermittelt. Praktisch keine Beschleunigung der Übertragung bei SSH -C, Komprimierung im Router, etc. (Messwerte schwanken zwischen Faktor 0,9 und 1,1, das würde ich mal als Messungenauigkeit abtun), während erst packen, dann übertragen, dann entpacken die Übertragungszeit von 6 Minuten auf 1 Minute reduziert.
Alternativ kann man auch sowas nutzen: < inputfile gzip --best | ssh user@host 'gzip -d > outputfile' oder bzip2 statt gzip.
Das bringt mir strenggenommen nur zusätzlichen Overhead, denn aktuell geht es mit netcat von A nach B (es ist ja schon ein VPN dazwischen, noch mal verschlüsseln ist da nicht wirklich notwendig - der Datenstrom wird zwischen Quell- und Zielgerät sowieso im Plaintext übertragen, deswegen könnte ich da auch die Ziel-IP problemlos mit dazupacken, wenn ich sie denn nur irgendwie ermitteln könnte).
Gruß Stefan