Noch viel lernen Du mußt, junger Padawan.
SFTP verschlüsselt die Daten und ist somit immer langsamer....
Nicht zwangsläufig, und nicht
wegen der Verschlüsselung.
Naja, die unterliegenden SSH-Verbindung erzeugt mehr Daten:
mehr Daten=mehr Datenaufkommen=langsamer.
So einfach ist das begründet. Ist in der Praxis aber gar nicht so viel.
SFTP ist aber viel sicherer.
Deine Schlußfolgerung ist nicht korrekt. Was Deine Aussage über die Sicherheit von SFTP im Zusammenhang mit SSH sein soll verstehe ich nicht. SFTP ist ein Subsystem von SSH, verwendet daher die identen Authentifizierungsmechanismen und Verschlüsselungen. SFTP
kann daher garnicht sicherer oder unsicherer sein als SSH.
Sicherer als
FTP (welches komplett unverschlüsselt läuft) ist SSH/SFTP auf jeden Fall.
Dazu kommt, daß man FTP, FTP/S und SFTP nicht verwechseln darf.
FTP ist unverschlüsselt und überträgt Benutzernamen und Passwörter im Klartext.
FTP/S ist ganz normales FTP mit SSL Verschlüsselung.
SFTP ist Secure FTP und benutzt SSH als Übertragungsmechanismuß.
Die tatsächlich erreichbare Übertragungsgeschwindigkeit hängt dabei von mehreren Faktoren ab.
- Art der Netzwerkverbindung
- Bandbreite der Netzwerkverbindung
- Fremdauslastung der Netzwerkverbindung
- Authentifizierungsmechanismuß
- Verschlüsselungsalgorithmus
- Rechenleistung des Senders für die Verschlüsselung
- Rechenleistung des Empfängers für die Verschlüsselung
- Datenstruktur
- Übertragungskompression
Quasi jeder einigermaßen Mac OS X taugliche Rechner ist schnell genug für die Verschlüsselung, daß diese schnell genug erfolgen kann um eine heutzutage übliche Internetanbindung auszulasten. So schafft beispielsweise ein PowerMac G4/450DP (2001) über
scp stabil über 5MB/s.
Für Übertragungen übers Internet ist bei einem
üblichen Internetanschluß die Verschlüsselung also völlig unerheblich, da sie sich nicht auf die Übertragungsgeschwindigkeit auswirkt. Im LAN kann das anders aussehen.
Fremdauslastung des Netzwerkes kann man schlecht bis garnicht beeinflussen, ist daher als Faktor zwar erheblich, aber nicht kalkulierbar. Die Auswirkungen der Art des Netzwerkes kommen je nach Protokoll mehr oder weniger zum Tragen. Da man die Art der Netzwerkanbindung meist nicht spontan ändern kann, ist auch das wenig zu beeinflussen.
Für die meisten Übertragungsmethoden (Protokolle) gilt, daß wenige große Dateien meist schneller übertragen werden als viele kleine Dateien mit der selben Datenmenge. Es entsteht weniger Protokolloverhead und es sind weniger Metadaten zu übertragen. Es ist daher beispielsweise empfehlenswert viele kleine Daten vorher per
tar zu einer Datei zusammenzufassen. Dies wirkt sich bei schmalbandigen Anbindungen deutlich mehr aus als bei hohen Bandbreiten.
Der Authentifizierungsmechanismuß ist für die Initiale Verzögerung bis der eigentliche Kopiervorgang beginnt relevant. Da dies üblicherweise nur einmal passiert kann man diese Zeit für die Übertragung von größeren Datenmengen (oft schon ab ein paar hundert kB aufwärts) bereits getrost vernachlässigen.
Ein sehr wichtiger Faktor ist die Verwendung von Kompression. FTP (mit und ohne SSL) sind unkomprimierte Verfahren. Es müssen daher wirklich die kompletten Daten so wie sie sind übertragen werden.
SFTP,
scp,
rsync (alle über SSH) können optional Kompression (über
gzip bzw. auch über
bzip2) verwenden. Dies wirkt sich bei vielen Datentypen (beispielsweise Text) sehr förderlich auf die tatsächlich zu übertragende Datenmenge aus.
Somit ist in den meisten Fällen die Übertragung per
rsync über SSH die sicherste und gleichzeitig die schnellste Übertragungsmethode, gefolgt von
scp. Die Verwendung von Kompression wirkt hier deutlich stärker als der Verschlüsselungsoverhead.
In manchen Fällen im LAN (100MBit/s oder GBit) kann die Kompression der Daten länger dauern als die eigentliche Übertragung der unkomprimierten Daten, hier kann es auch sein, daß die Verschlüsselung eine eigentlich schnellere Übertragung ausbremst. Übers Internet ist das allerdings nicht zu erwarten.
Gruß Pepi
Doch, grade deswegen. Alle Daten müssen verschlüsselt werden, was viel CPU-Leistung zieht und damit einfach langsamer ist als ein reines lesen und über ein Socket schicken. Ich rede allerdings hier nicht von riesigen Unterschieden.
!