it-swarm.com.de

Was ist der schnellste Weg, um Dateien über ein Netzwerk zu übertragen (FTP, HTTP, RSync usw.)

Ich versuche herauszufinden, wie große Datenmengen über ein Netzwerk zwischen zwei Systemen übertragen werden können. Ich beschäftige mich gerade mit FTP, HTTP oder RSync und frage mich, welches das schnellste ist. Ich habe online nach Antworten gesucht und die folgenden Websites gefunden:

Das Problem ist, dass diese alt sind und mehr über die theoretischen Unterschiede zwischen der Kommunikation der Protokolle sprechen. Ich bin mehr an tatsächlichen Benchmarks interessiert, das heißt, dass für ein bestimmtes Setup beim Übertragen von Dateien unterschiedlicher Größe ein Protokoll x% schneller ist als die anderen.

Hat jemand diese getestet und die Ergebnisse irgendwo gepostet?

21
oneself

Okay, also habe ich den folgenden Test eingerichtet:

  • Hardware: 2 Desktops Intel Core Duo-CPU mit 2,33 GHz und 4 G RAM.
  • Betriebssystem: Ubuntu 11.10 auf beiden Rechnern
  • Netzwerk: 100 MB dedizierter Switch, beide Computer sind mit dem Switch verbunden.
  • Software:

Ich habe die folgenden Dateigruppen auf jeden Server hochgeladen:

  1. 1 100 Millionen Datei.
  2. 10 10 Millionen Dateien.
  3. 100 1M Dateien.
  4. 1.000 100K-Dateien.
  5. 10.000 10K-Dateien.

Ich habe die folgenden Durchschnittsergebnisse über mehrere Läufe erhalten (Zahlen in Sekunden):

|-----------+---------+----------|
| File Size | FTP (s) | HTTP (s) |
|-----------+---------+----------|
|      100M |       8 |        9 |
|       10M |       8 |        9 |
|        1M |       8 |        9 |
|      100K |      14 |       12 |
|       10K |      46 |       41 |
|-----------+---------+----------| 

Es scheint also, dass FTP in großen Dateien etwas schneller ist und HTTP in vielen kleinen Dateien etwas schneller. Alles in allem denke ich, dass sie vergleichbar sind, und die Server-Implementierung ist viel wichtiger als das Protokoll.

35
oneself

Wenn die Maschinen an jedem Ende einigermaßen leistungsfähig sind (dh keine Netbooks,NAS- Boxen, Toaster usw.), würde ich erwarten, dass alle Protokolle, die überTCPfunktionieren, ungefähr dieselbe Geschwindigkeit haben bei der Übertragung von Massendaten. Die Aufgabe des Anwendungsprotokolls besteht eigentlich nur darin, einen Puffer für die Übertragung von TCP zu füllen, damit TCP das Tempo festlegt, solange sie ihn voll halten können.

Protokolle, die Komprimierung oder Verschlüsselung ausführen, können auf leistungsschwächeren Computern zu Engpässen bei der CPU führen. Mein Netbook macht FTP viel schneller als SCP.

rsync macht clevere Dinge, um inkrementelle Änderungen schnell zu übertragen, aber für Massenübertragungen hat es keinen Vorteil gegenüber dümmeren Protokollen.

7
Tom Anderson

Ein weiteres zu berücksichtigendes Dienstprogramm ist bbcp: http://www.slac.stanford.edu/~abh/bbcp/ .

Ein gutes, aber veraltetes Tutorial zu seiner Verwendung finden Sie hier: http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm . Ich habe festgestellt, dass bbcp beim Übertragen großer Dateien (mehrere GB) extrem gut ist. Nach meiner Erfahrung ist es im Durchschnitt schneller als Rsync.

4
kadal

rsync komprimiert optional seine Daten. Das beschleunigt die Übertragung in der Regel erheblich. Siehe rsync -z .

Sie haben scp nicht erwähnt, aber scp -C komprimiert auch.

Beachten Sie, dass durch die Komprimierung die Übertragung möglicherweise beschleunigt oder verlangsamt wird, abhängig von der Geschwindigkeit Ihrer CPU und Ihrer Netzwerkverbindung. (Langsamere Verbindungen und schnellere CPU machen die Komprimierung zu einer guten Idee, schnellere Verbindungen und langsamere CPU machen die Komprimierung zu einer schlechten Idee.) Wie bei jeder Optimierung sollten Sie die Ergebnisse in Ihrer eigenen Umgebung messen.

3
Robᵩ

Ich fürchte, wenn Sie die Antwort auf Ihre Anforderungen und Einstellungen wissen möchten, müssen Sie entweder spezifischer vorgehen oder Ihre eigenen Leistungs- (und Zuverlässigkeits-) Tests durchführen. Ein zumindest rudimentäres Verständnis der fraglichen Protokolle und ihrer Kommunikation ist hilfreich, daher würde ich die Artikel, die Sie zitiert haben, als hilfreiche Ressource betrachten. Es ist auch hilfreich zu wissen, mit welchen Einschränkungen die frühen Erfinder dieser Protokolle konfrontiert waren - wollten sie die Auswirkungen auf das Netzwerk gering halten, hatten sie keinen Speicher mehr oder mussten sie ihre CPU-Zyklen zählen? Hier sind einige Dinge zu beachten oder zu beantworten, wenn Sie eine Antwort erhalten möchten, die auf Ihre Situation zugeschnitten ist:

  • Betriebssystem-/Dateisystembezogen:
    • kopieren Sie zwischen derselben OS/FS-Kombination oder müssen Sie sich um Inkompatibilitäten sorgen, z. B. Dateitypen ohne Entsprechung auf der Empfängerseite?
    • Das heißt Haben Sie etwas Besonderes zu transportieren? Metadaten, Ressourcengabeln, erweiterte Attribute und Dateiberechtigungen werden möglicherweise nicht von dem Protokoll/Tool Ihrer Wahl übertragen oder sind auf der Empfängerseite bedeutungslos.
    • Das Gleiche gilt für spärliche Dateien, die am anderen Ende der Kopie möglicherweise auf die volle Größe aufgebläht werden und alle Pläne ruinieren, die Sie möglicherweise in Bezug auf die Größenanpassung hatten.
  • Physikalische Einschränkungen im Zusammenhang mit:
    • Auswirkungen auf das Netzwerk
    • cPU-Auslastung: Komprimierung ist heutzutage viel "billiger", da moderne CPUs von der Komprimierung weniger betroffen sind als in Zeiten, in denen die meisten Übertragungsprotokolle entwickelt wurden.
    • fehlertoleranz - Müssen Sie in der Lage sein, die Stelle zu übernehmen, an der Sie eine unterbrochene Übertragung hinterlassen haben, oder möchten Sie lieber neu beginnen?
    • inkrementelle Überweisungen oder vollständige Überweisungen? Bedeutet eine inkrementelle Übertragung eine erhebliche Ersparnis für Sie oder haben Sie aufgrund Ihrer Aufgabenstellung ohnehin eine vollständige Übertragung? Im letzteren Fall wäre die zusätzliche Latenz und die Auswirkung auf den Speicher beim Erstellen der Übertragungsliste vor dem Starten der Übertragung ein weniger wünschenswerter Kompromiss.
    • Wie gut kann das Protokoll die von Ihrem zugrunde liegenden Netzwerkprotokoll zur Verfügung gestellte MTU nutzen?
    • Müssen Sie einen konstanten Datenstrom aufrechterhalten, um beispielsweise ein Bandlaufwerk am empfangenden Ende zu halten?

Viele Dinge zu beachten, und ich bin sicher, dass die Auflistung nicht einmal vollständig ist.

2
Tatjana Heuser