FTP via Zip - Transfer - Unzipp
0 
Felix Riesterer
0 2 1 dedlfix
1
1
FTP via Zip - Transfer - Unzipp
Der Martin
StruppiHallo,
wäre es nicht wesentlich schneller wenn mein FTP-Programm bei Uploads oder Downloads ab sagen wir mal 20 Files auf der Quellseite die Files erst Zippt und nach dem einmaligen Transfer auf der Zielseite wieder Unzippt und speichert!? Anstatt jede Datei einzeln zu bearbeiten?
Iris
-
Liebe Iris,
das entzippen aus einem FTP-Programm heraus ist nicht möglich.
Meine Dateiverwaltung könnte soetwas, jedoch kann sie die in PHP eingestellten Limits für die Dateigröße bei Uploads nicht überwinden. Du müsstest also per FTP eine ZIP-Datei hochladen und mittels meiner Dateiverwaltung entzippen...
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:) -
Hallo,
wäre es nicht wesentlich schneller wenn mein FTP-Programm bei Uploads oder Downloads ab sagen wir mal 20 Files auf der Quellseite die Files erst Zippt und nach dem einmaligen Transfer auf der Zielseite wieder Unzippt und speichert!? Anstatt jede Datei einzeln zu bearbeiten?
Mal unabhängig von der Zipperei: FTP hält beim Dateitransfer ein weiteres socket offen, über dass der Status der Übertragung zwischen Server und UserAgent ständig abgeglichen wird. Das bringt einen gewissen Geschwindigkeitsverlust gegenüber anderen Protokollen wie z.B. HTTP was nach jeder Übertragung ein Connection Close macht. Andererseits ermöglicht FTP über den Kontrollkanal eine Fortschrittsanzeige für den UA.
Wenn Du experimentierfeudig bist, vergleiche mal den Dateitransfer mit FTP vs. HTTP, letzeres ist etwa um Faktor 2 schneller. http://rolfrost.de/httpcont.html
Noch schneller ist TFTP, der triviale Filetransfer. Hier erfolgt überhaupt keine Kontrolle ob die Daten angekommen sind, es wird anstelle TCP auch UDP benutzt.
Hotti
-
Hi!
Wenn Du experimentierfeudig bist, vergleiche mal den Dateitransfer mit FTP vs. HTTP, letzeres ist etwa um Faktor 2 schneller.
Das stimmt /so pauschal/ _nicht_. Du behauptest hier Sachen und 'belegst' diese Aussagen dann mit einem Dokument Deiner eigenen Webpräsenz - das finde ich so nicht ok!
Wenn *Du* experimentierfreudig bist, dann vergleiche einmal den Download von *richtig großen* Dateien oder *richtig vieler* via http und ftp.
Noch schneller ist TFTP, der triviale Filetransfer.
Hier erfolgt überhaupt keine Kontrolle ob die Daten angekommen sind, es wird anstelle TCP auch UDP benutzt.Ach? Ohne Three-Way-Handshake geht es schneller? Quelle surprise!
Das ist Äpfel mit Birnen verglichen.off:PP
--
"You know that place between sleep and awake, the place where you can still remember dreaming?" (Tinkerbell)
-
Das stimmt /so pauschal/ _nicht_. Du behauptest hier Sachen und 'belegst' diese Aussagen dann mit einem Dokument Deiner eigenen Webpräsenz - das finde ich so nicht ok!
Genau! Auf meiner Website behaupte ich nicht nur, ich zeige es auch :-)
Wenn *Du* experimentierfreudig bist, dann vergleiche einmal den Download von *richtig großen* Dateien oder *richtig vieler* via http und ftp.
Aber Hallo ;-)
Bei Dateien jenseits der Fünfzig-Megabyte-Grenze fängt der Spaß mit HTTP erst richtig an ;-)
Darüber hinaus ist HTTP im Gegensatz zu FTP in einem CMS viel schöner zu automatisieren, wegen DOCUMENT_ROOT. Hier ein kleiner Einblick in mein
Das Crux bei den meisten Hostern ist der Unterschied zwischen (http)DOCUMENT_ROOT und FTP_ROOT. Content Management via HTTP heißt: Einheitliche Prozesse, Transparenz, Scalierbarkeit, klar definierte Schnittstellen und überschaubarer Code. Wenn Du da noch Fragen hast, auf meinen Seiten stehen die Antworten.
Hotti
-
Hi!
Das stimmt /so pauschal/ _nicht_. Du behauptest hier Sachen und 'belegst' diese Aussagen dann mit einem Dokument Deiner eigenen Webpräsenz - das finde ich so nicht ok!
Genau! Auf meiner Website behaupte ich nicht nur, ich zeige es auch :-)
Sorry: tust Du nicht!
Wenn *Du* experimentierfreudig bist, dann vergleiche einmal den Download von *richtig großen* Dateien oder *richtig vieler* via http und ftp.
Aber Hallo ;-)
Bei Dateien jenseits der Fünfzig-Megabyte-Grenze fängt der Spaß mit HTTP erst richtig an ;-)
Ich sprach von *richtig großen* oder *richtig vielen* Dateien - z.B. eine Linux-Distribution. Die per http ziehen, oder via ftp?
Darüber hinaus ist HTTP im Gegensatz zu FTP in einem CMS viel schöner zu automatisieren, wegen DOCUMENT_ROOT. Hier ein kleiner Einblick in mein
Was soll denn das? Mein Wurzelverzeichnis für Webdokumente heißt --maxundmoritz und ich verwende den HTTP-Server OurNet auf OS myWorld - und nu?
Das Crux bei den meisten Hostern ist der Unterschied zwischen (http)DOCUMENT_ROOT und FTP_ROOT. Content Management via HTTP heißt: Einheitliche Prozesse, Transparenz, Scalierbarkeit, klar definierte Schnittstellen und überschaubarer Code.
Zum Marketing-Fachmann fehlt Dir leider _auch_ die Sachkenntnis - sorry nochmal!
Wenn Du da noch Fragen hast, auf meinen Seiten stehen die Antworten.
Ich habe da keine Fragen - Deine Antworten sind leider nicht ok!
BTW: es geht mir total auf die *, dass hier immer von /Seiten/ die Rede ist - so etwas gibt es im Web nicht!
off:PP
--
"You know that place between sleep and awake, the place where you can still remember dreaming?" (Tinkerbell)
-
-
-
Hi!
FTP hält beim Dateitransfer ein weiteres socket offen, über dass der Status der Übertragung zwischen Server und UserAgent ständig abgeglichen wird.
Umgekehrt wird ein Schuh draus. Es wird eine Kontroll-Verbindung aufgebaut, über die Befehle an den Server gesendet werden, und die der Server mit Statuscodes beantwortet. Die Übertragung von Dateien wird mit einem Befehl ausgelöst und findet in einer eigenen Verbindung statt. Währenddessen ist auf der Kontroll-Verbindung Funkstille. Da muss nämlich nicht ständig ein Status ausgetauscht werden, weil das die Datenverbindung über das TCP-Protokoll von selbst hinbekommt.
Das bringt einen gewissen Geschwindigkeitsverlust gegenüber anderen Protokollen wie z.B. HTTP was nach jeder Übertragung ein Connection Close macht. Andererseits ermöglicht FTP über den Kontrollkanal eine Fortschrittsanzeige für den UA.
Die Übertragung selbst läuft nicht langsamer als bei HTTP, jedoch nimmt der Befehlsverkehr vor dem Start der Übertragung etwas Zeit in Anspruch. Was macht die Erwähnung des Connection Close hier? Zumal es nicht zwingend notwendig ist, die Verbindung zu schließen. Eine Fortschrittsanzeige wird auch bei FTP nicht über Statusinformationen realisiert sondern wie bei HTTP anhand der Anzahl der bereits übertragenen Daten im Verhältnis zur vorher mitgeteilten Dateigröße/Content-Length, falls der Server sie mitteilt, wozu er weder bei FTP noch HTTP verpflichtet ist.
Wenn Du experimentierfeudig bist, vergleiche mal den Dateitransfer mit FTP vs. HTTP, letzeres ist etwa um Faktor 2 schneller.
Den Faktor 2 bekommst du vielleicht bei kleinen Dateien hin, wenn der Verwaltungsaufwand verhältnismäßig viel Zeit in Anspruch nimmt. Bei großen Dateien fällt der Unterschied nicht mehr ins Gewicht.
Noch schneller ist TFTP, der triviale Filetransfer. Hier erfolgt überhaupt keine Kontrolle ob die Daten angekommen sind, es wird anstelle TCP auch UDP benutzt.
Und weil UDP verwendet wird, das keine Kontrolle über eine Reihenfolge oder den Verlust von Paketen bietet, was sich aber bei einer Dateiübertragung äußerst negativ auswirkte, hat beim TFTP der Empfänger jedes Paket zu quittieren, bevor der Sender das nächste auf die Reise schickt. "Noch schneller" ist da lediglich der Austausch der Befehlsinformation am Anfang, weil der auf ein Minimum reduziert ist.
Lo!
-
Hallo,
[...] falls der Server sie mitteilt, wozu er weder bei FTP noch HTTP verpflichtet ist.
oh, danke für die Info; ich dachte, bei FTP sei die Angabe zwingend.
Wenn Du experimentierfeudig bist, vergleiche mal den Dateitransfer mit FTP vs. HTTP, letzeres ist etwa um Faktor 2 schneller.
Den Faktor 2 bekommst du vielleicht bei kleinen Dateien hin, wenn der Verwaltungsaufwand verhältnismäßig viel Zeit in Anspruch nimmt. Bei großen Dateien fällt der Unterschied nicht mehr ins Gewicht.Genau das habe ich ihm auch schon versucht klarzumachen, als er vor zwei Wochen seinen Artikel hier das erste Mal vorgestellt hat, und mit einem "selbstgesägten" schnellen HTTP-Upload geprahlt hat.
Zwar ist mir nachträglich klar geworden, dass meine Zahlenbeispiele nur für einen HTTP/FTP-Download, nicht aber für einen Upload stimmen, weil ich für die Zeitabschätzung die Downstream-Bandbreite eines ADSL-Anschlusses genommen habe, nicht die deutlich geringere Upstream-Bandbreite. Bei geringerer Bandbreite ist zwar der Einfluss des größeren Overheads bei FTP möglicherweise noch größer als bei Hottis "Binary HTTP Upload" (obwohl ich vermute, dass die Antwortzeiten der beteiligten Hosts eine größere Rolle spielen als die Transferbandbreite), aber trotzdem nivelliert sich das bei großen Transfermengen wieder aus.Leider hat hotti seinerzeit auf meinen Einwurf nicht einmal reagiert.
So long,
Martin--
Lehrer: Wieviel ist die Hälfte von 8?
Schüler: Kommt drauf an. Waagrecht 0 und senkrecht 3.
-
Hi!
[...] falls der Server sie mitteilt, wozu er weder bei FTP noch HTTP verpflichtet ist.
oh, danke für die Info; ich dachte, bei FTP sei die Angabe zwingend.Content-Type muss ein HTTP-Server antworten, aber Content-Length nicht. Die ergibt sich aus im einfachsten Fall aus indem die die Daten nach dem Doppel-Enter am Ende der Headerzeilen beginnen und die Verbindung am Ende der Übertragung ordentlich beendet wird.
Bei FTP antwortet ein Server immer nur mit einem dreistelligen Zahlencode und einem nicht näher spezifizierten Text, der für Menschen bestimmt ist. Der Client weiß, wie groß eine Datei ist, wenn er vorher ein Directory-Listing gemacht hat oder extra mit SIZE nachgefragt hat, was eine Erweiterung des FTP-Protokolls ist. Ansonsten haben die Daten ein definiertes Beginn und Ende durch die Datenverbindung, die auf- und am Ende wieder abgebaut wird. Es gibt einfach keine Notwendigkeit die Größe mitzuteilen. Durch TCP in der dedizierten Datenverbindung ist sichergestellt, dass die Daten in voller Länge und der richtigen Reihenfolge beim Client landen (oder beim Server, wenn man sendet).
Lo!
-
Genau das habe ich ihm auch schon versucht klarzumachen, als er vor zwei Wochen seinen Artikel hier das erste Mal vorgestellt hat, und mit einem "selbstgesägten" schnellen HTTP-Upload geprahlt hat.
Ich hab mittlerweile das Gefühl, im geht es nur darum seine Links zu hier zu platzieren. Er hat ja mittlerweile google Ads auf der Seite.
Fast alle Artikel, die er hier "vorstellt" (er verlinkt sie i.d.R. nur ohne sich wirklich an Diskussionen zu beteiligen) sind stark Fehlerhaft oder zumindest mißverständlich.
Viele Artikel sind auch einfach sinnlos, was bringt mir ein Artikel über ein "Content Managment Object" wenn ich nicht das dazu gehörige Skript kenne.
Oder er wirft die Links z.T. in Threads ein ohne dass sie wirklich Problemlösung dienen.
Struppi.
-
-
-
Hallo Rolf,
Noch schneller ist TFTP, der triviale Filetransfer. Hier erfolgt überhaupt keine Kontrolle ob die Daten angekommen sind, es wird anstelle TCP auch UDP benutzt.
Tut mir leid, aber das stimmt nicht. TFTP verwendet zwar UDP, es bestätigt aber ähnlich wie bei TCP jedes empfangene Paket.
Gruß
Patrick
-
-
Moin Moin!
wäre es nicht wesentlich schneller wenn mein FTP-Programm bei Uploads oder Downloads ab sagen wir mal 20 Files auf der Quellseite die Files erst Zippt und nach dem einmaligen Transfer auf der Zielseite wieder Unzippt und speichert!? Anstatt jede Datei einzeln zu bearbeiten?
Das wäre es, sofern Bandbreite Dein Problem ist und nicht CPU-Leistung und Arbeitsspeicher. Also meistens "JA", denn CPU und RAM ist meistens mehr als genug vorhanden.
Stell Dir vor, es gäbe ein Protokoll, dass die Komprimierung komplett transparent für Dich erledigt. Stell Dir vor, das Protokoll würde ganz nebenbei Deine Daten und insbesondere Dein Passwort verschlüsselt übertragen. Und stell Dir vor, das Protokoll könnte auf ein Passwort ganz verzichten, zugunsten eines wesentlich sicheren Public-Key-Verfahrens.
Schön, dass so ein Protokoll bereits existiert, oder?
Es heißt SSH und bietet neben einem mehr als vollwertigem Ersatz für Telnet zwei Dateitransfer-Protokolle: Das ältere und einfachere SCP und das wesentlich mächtigere SFTP. Gängige Clients für Windows sind PuTTY (Terminal, und u.a. Konsolenanwendungen für SCP und SFTP) und WinSCP (Grafische Oberfläche für SCP und SFTP). MacOS X und die gängigen Unixe haben in aller Regel ssh, scp, sftp und ggf. auch passende grafische Oberflächen schon an Bord.
Einziger kleiner Haken: Die Komprimierung ist normalerweise nicht aktiviert. Bei PuTTY und WinSCP ist das nur ein Häkchen irgendwo in den Einstellungen, bei den Unix-Programmen ein Kommandozeilen-Parameter oder ein Eintrag in der Konfigurationsdatei.
Übrigens bieten einige FTP-Server als Erweiterung für den Download (und NUR für den Download) auch die Möglichkeit, sich einen Verzeichnisbaum als GZIP-komprimiertes TAR-Archiv herunter zu laden, in dem man die (nicht existierende) Datei <verzeichnisname>.tar.gz anfordert.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".