[gelöst]Übertragungsgeschwindigkeit FTP vs SCP

[heinz0001]

Hallo Forum,

Ist die Übertragung via FTP wirklich signifikant schneller als via SCP?
Und macht es einen Unterschied ob ich eine große Datei habe oder viele kleine Dateien?

Grüße, Heinz

[Liffi]

Ist die Übertragung via FTP wirklich signifikant schneller als via SCP?

Das kommt drauf an, ob der Verschluesselungsoverhead fuer deinen Rechner viel Last erzeugt.
Wenn dein Rechner schnell genug ist: nein.

Und macht es einen Unterschied ob ich eine große Datei habe oder viele kleine Dateien?

Ja. Deshalb lohnt es sich evtl. eine ssh + tar Loesung.

[ThorstenS]

Bei Servern im LAN kannst du die SCP Übertragungsrate signifikant erhöhen, indem du dauerhaft in der ~.ssh/config Ciphers arcfour aktivierst. Oder pro Verbindugn über sftp -c arcfour $SERVER

Trotzdem ist FTP schneller.

[unitra]

Hallo Forum,

Ist die Übertragung via FTP wirklich signifikant schneller als via SCP?
Und macht es einen Unterschied ob ich eine große Datei habe oder viele kleine Dateien?

Grüße, Heinz

Der Protokoll-Overhead von einer gesicherten Verbindung ist viel größer als von einer FTP Verbindung.
Mal angenommen ein Ethernet-Frame IEEE 802.3 hat 1500 Bytes. Du könntest ausrechnen wieviel Protokol-Overhead eine FTP dir von dem 1500 Bytes weg nimmt, und wieviel Overhead eine SCP Verbindung beansprucht.
Du wirst sehen dass der SCP Overhead viel größer ausfällt als der FTP Overhead. (Hier ist nur der Protokoll Overhead gemeint)

Bei FTP sind weder Steuerdaten noch Dateiübertragung gesichert. SCP sichert die Steuerdaten und die Dateiübertragung via SSH. SFTP erweitert SCP und bietet zusätzliche Dateioperationen.

Aber zurück zu deiner Frage, nein FTP ist NICHT signifikant schneller als SCP, jedoch ist es schneller als SCP. Es nimmt weniger Platz im Header ein, also bleiben mehr Platz in deinem Ethernet Frame für Daten.
Es bleibt aber unter 3% und bei kleinen Dateien und wenigen Dateien macht es sich nicht spürbar bemerkbar.

FTP ist schneller bei der Übertragung als SCP, und nicht wie andere behaupten daß es keinen Unterschied macht. Es macht einen Unterschied.

[mR. bluE]

Bleibt nur noch zu erwähnen das man bei FTP natürlich auch einen verschlüsselten Data Path erzeugen kann (je nachdem was für ein daemon eingesetzt wird) das erzeugt dann natürlich auch wieder einen gewissen Overhead. Aber auch dann ist FTP meiner Erfahrung nach um schneller als SSH/SCP.
Viele kleine Dateien vorher in ein Archiv zu packen macht bei beiden Übertragungen Sinn. Wenn man das ganze dann noch komprimiert bevor man es überträgt gewinnt man auch noch n biserl was.

[syssi]

Im Gegensatz zu den bisherigen guten Antworten, hier noch eine unsachliche Antwort:

Code: Alles auswählen

$ scp linux-3.0-rc3.tar.bz2 sheldon:/tmp
linux-3.0-rc3.tar.bz2    100%   73MB  36.5MB/s   00:02
$ ncftpput sheldon /tmp ./linux-3.0-rc3.tar.bz2
./linux-3.0-rc3.tar.bz2:      73.06 MB   60.17 MB/s

Das ist der Durchsatz bei (m)einem Gigabit-Netzwerk. Schickt man die Daten ueber ein Loopback-Device sieht man den Unterschied noch deutlicher:

Code: Alles auswählen

$ scp daten localhost:/tmp
daten    100%  700MB  58.3MB/s   00:12
$ ncftpput localhost /tmp ./daten
./daten:   699.66 MB    1.26 GB/s  

Im zweiten Beispiel wurden die Daten aus dem Arbeitsspeicher (tmpfs) gelesen und auch wieder geschrieben. SCP war nicht in der Lage mehr als 58.3 MB/s zu schicken, da meine CPU nicht mehr hergegeben hat (100% Last). Ohne Encryption geht es der FTP-Uebertragung deshalb einiges besser. Wie das Ganze mit vielen kleinen Dateien aussieht, kann jeder fuer sich testen.

Gruss syssi

[ThorstenS]

und hier mal die große Auswirkung der verwendeten cipher (auf meinem altersschwachen Notebook mit Pentium M 1.4GHz)

Code: Alles auswählen

$ scp blob localhost:/tmp
thorsten@localhost's password: 
blob             100%  200MB  11.8MB/s   00:17    
$ scp -c arcfour blob localhost:/tmp
blob             100%  200MB  25.0MB/s   00:08    

[LessWire]

@ThorstenS: Wenn beide Kommandos so direkt nacheinander eingegeben werden, wird beim ersten Mal von der Disk gelesen (langsam), beim zweiten Mal (fast) alles aus dem Cache, was schon unabhängig vom verwendeten Cipher erheblich schneller geht.

Nach meinen Tests mit einer 1,2 GB grossen Datei gibt es diesen erheblichen Geschwindigkeitsunterschied nicht - es wird mit "arcfour" nur etwas schneller.

Code: Alles auswählen

> time scp testfile /dev/shm/
# 2. Kopiervorgang
real	0m1.934s
user	0m0.009s
sys	0m1.275s
> time scp -c arcfour testfile /dev/shm/
# 3. Kopiervorgang
real	0m1.251s
user	0m0.007s
sys	0m1.242s

Gruß, LW.

[Liffi]

Im zweiten Beispiel wurden die Daten aus dem Arbeitsspeicher (tmpfs) gelesen und auch wieder geschrieben. SCP war nicht in der Lage mehr als 58.3 MB/s zu schicken, da meine CPU nicht mehr hergegeben hat (100% Last). Ohne Encryption geht es der FTP-Uebertragung deshalb einiges besser.

Ok. Ich gebe zu, ich lag falsch. Heutige CPUs sind einfach noch zu langsam (oder die Netzwerke zu schnell ).

[ThorstenS]

@ThorstenS: Wenn beide Kommandos so direkt nacheinander eingegeben werden, wird beim ersten Mal von der Disk gelesen (langsam), beim zweiten Mal (fast) alles aus dem Cache, was schon unabhängig vom verwendeten Cipher erheblich schneller geht.

Nach meinen Tests mit einer 1,2 GB grossen Datei gibt es diesen erheblichen Geschwindigkeitsunterschied nicht - es wird mit "arcfour" nur etwas schneller.

Ich habe die Datei per dd erstellt, sie lag noch im RAM. Aber natürlich habe ich den Test mehrfach laufen lassen und bei meiner altersschwachen CPU mehrfach Werte in diesem Bereich erhalten.

Wenn ich den Test an der Arbeit auf meinem Core2 Duo E7500 und der SSD nochmal mit einer 1.2GB großen Datei durchgeführt.
Es zeichnet sich wieder ab, dass arcfour um einiges schneller ist:

Code: Alles auswählen

0 thorsten@wks:/usr/local/src
$ time scp -c arcfour  blob localhost:/usr/local/src/blob.out
blob          100% 1200MB 100.0MB/s   00:12 

real	0m11.949s
user	0m6.372s
sys	0m2.340s
0 thorsten@wks:/usr/local/src
$ time scp  blob localhost:/usr/local/src/blob.out2
blob           100% 1200MB  66.7MB/s   00:18

real	0m18.388s
user	0m11.269s
sys	0m2.316s

Wenn ich nach /dev/shm kopiere ist der Geschwindigkeitsvorteil - wie bei dir - sehr viel geringer.

[LessWire]

OK, muss ich mal unter anderen Bedingungen testen - wobei ich Deinen Ergebnissen natürlich glaube. Unter langsameren CPU's wird's noch effizienter - so kann es wohl nicht schaden, mit diesem Cipher als default im LAN zu arbeiten.
Danke + Gruß, LW.

[heinz0001]

sehr aufschlussreich, danke an alle!