ftp <-> www
-
Erstmal vielen Dank für die vielen Antworten.
Wenn beide Servertypen ungefähr gleich performant sind werde ich erstmal beim Apache bleiben. Weniger Arbeit für mich
-
Threadstarter schrieb:
Wenn beide Servertypen ungefähr gleich performant sind werde ich erstmal beim Apache bleiben.
Sind sie nicht. Dachte das wäre mittlerweile klar geworden. Selbst mit keep-alive hat man bei HTTP einen Header, den man mit FTP nicht hat. Bei vielen kleinen Dateien summiert sich das auch. Und gzip, sofern es der Client überhaupt unterstützt, bringt einem nichts, wenn die Daten schon komprimiert sind (z.B. jpeg, gif, zip, rar, mp3 ...). Der Spaß heißt ja auch nicht umsonst HTTP (Hypertext Transfer Protocol). Deswegen ja auch der Header mit content-type, etc. Im Gegensatz dazu steht eben das File Transfer Protocol, welches optimal ist um reine Daten von A nach B zu schieben.
-
da man ja bei ftp angeblich keinen header hat möchte ich doch mal deinen blick sarfuan auf folgenden link lenken
http://www.elektronik-kompendium.de/sites/net/0902241.htm
dort findet man mal die daten des steuerports für eine ftp sitzung dies ist gleichbedeutend mit einen header bei http, denn auch bei ftp müssen dateiname und größe übertragen werden!!! und zu der komprimierung es gibt erstens nicht nur verschlüselte dateien sondern im netz werden ja auch dokumente (*.txt *.doc) übertragen auch ganze webseiten und scripte in php usw diesich sehr gut kompriemieren lassen wobei sich dort z.b. gzip lohnt so groß ist der unterschied also nicht.
überlegenswert ist daher wie oft und wieviele personen ziehen denn dateien von dem server gibt es viele große dateien nur wenn die belastung ziemlich hoch ist würde sich der umstieg lohnen wobei ich immer dachte apache beherrscht auch ftp? daer wäre das ja denn eigentlich kein umstieg
-
Skippy schrieb:
dort findet man mal die daten des steuerports für eine ftp sitzung dies ist gleichbedeutend mit einen header bei http, denn auch bei ftp müssen dateiname und größe übertragen werden!!!
Nein, ist es nicht. Ein FTP-Client kann Dateinamen und Größe via LIST anfordern, muss es aber nicht. Sowohl bei HTTP als auch bei FTP sind die Dateinamen in der Anforderung schon bekannt (HTTP: "GET /datei1 HTTP/1.1", FTP: "RETR datei1"), müssen und werden also nicht extra in Form eines Headers übertragen. Und nein, FTP muss keine Dateigrößen übertragen und tut dies bei einem Dateitransfer auch nicht. Die Größe ergibt sich schließlich ja automatisch.
Wie gesagt, wenn der FTP-Client alle Dateinamen und Größen wissen will, kann er ein Verzeichnislisting anfordern. Das ist aber optional und, für die komische Diskussion hier wichtiger, erfolgt NICHT für jede Datei extra (kann mithin also auch in keinster Weise als Header betrachtet werden), sondern gesammelt.
Kurzum FTP hat keine Extra-Header. Siehe auch deinen Link, der bestätigt das ja letztlich.und zu der komprimierung es gibt erstens nicht nur verschlüselte dateien sondern im netz werden ja auch dokumente (*.txt *.doc) übertragen auch ganze webseiten und scripte in php usw diesich sehr gut kompriemieren lassen wobei sich dort z.b. gzip lohnt so groß ist der unterschied also nicht.
Hab ich dem widersprochen? Nein
Anmerken möchte ich aber, dass, wenn jemand frägt, ob FTP oder HTTP effizienter ist, er wohl kaum daran interessiert sein wird, HTML- oder Textdateien anzubieten. Sondern eben eher etwas in Richtung zip, rar, mp3, ...
-
sarfuan schrieb:
Threadstarter schrieb:
Wenn beide Servertypen ungefähr gleich performant sind werde ich erstmal beim Apache bleiben.
Sind sie nicht.
Ohne zu wissen was der Threadstarter überhaupt machen will, kann man das so nicht sagen.
Du redest hier die ganze zeit von mehr Effizienz, nur weil bei HTTP ungefähr 20 byte mehr Header zurückgeschickt wird?Wenn man zig Dateien hin- und herschieben will ist sicherlich ftp besser.
Ein einzelnes wget http://blub ist dagegen schneller als wget ftp://blub. Wegen der FTP-Authentifizierung.Und wenn es nur darum geht mit welchem Protokoll man ein paar 100MB-Datei schneller runtergeladen hat, nehmen sich die beiden quasi gar nichts.
-
FTP ist doch vor allem deswegen problematisch, weil man eine weitere Datenverbindung öffnen muss, was zB bei Firewalls problematisch werden kann.
-
DrGreenthumb schrieb:
Du redest hier die ganze zeit von mehr Effizienz, nur weil bei HTTP ungefähr 20 byte mehr Header zurückgeschickt wird?
Wenn man zig Dateien hin- und herschieben will ist sicherlich ftp besser.
...
tosto schrieb:
besonders wenn viele kleine dateien runtergealden werden, (...), ist http empfehlenswert
sarfuan schrieb:
Gerade bei vielen kleinen Dateien ist FTP deutlich effizienter als HTTP.
sarfuan schrieb:
Bei vielen kleinen Dateien summiert sich das auch.
Noch jemand irgendwelche Kommentare auf Lager?
-
Ja toll, aber hier schreibst du:
sarfuan schrieb:
Threadstarter schrieb:
Wenn beide Servertypen ungefähr gleich performant sind werde ich erstmal beim Apache bleiben.
Sind sie nicht. Dachte das wäre mittlerweile klar geworden. Selbst mit keep-alive hat man bei HTTP einen Header, den man mit FTP nicht hat. Bei vielen kleinen Dateien summiert sich das auch. Und gzip, sofern es der Client überhaupt unterstützt, bringt einem nichts, wenn die Daten schon komprimiert sind (z.B. jpeg, gif, zip, rar, mp3 ...). Der Spaß heißt ja auch nicht umsonst HTTP (Hypertext Transfer Protocol). Deswegen ja auch der Header mit content-type, etc. Im Gegensatz dazu steht eben das File Transfer Protocol, welches optimal ist um reine Daten von A nach B zu schieben.
Und da könnte jetzt jemand verstehen, FTP sei generell effizienter. Und das ist Unsinn. Wie ich bereits ganz zu Anfang dieser Diskussion schrieb.
-
Um eine Datei auf den Server hochzuladen braucht es mehr als HTTP. z.B. PHP.
Ein PHP-Script hat aber ein Zeitlimit für max. Ausführung und das kann schnell mal zu ende gehen. Der Webdienst braucht mehr Resourcen am Rechner als der FTP-Dienst.
Warum sollte man das verschwenden.
Und wenn schon FTP dann SFTP. Ist zwar langsamer aber was solls.
-
Gibt ja auch noch WebDAV