ftp <-> www

Hallo Forum,
ich habe irgendwo mal gehört das es nicht so effizient sei große Dateien über das www Protokoll zu übertragen wie bei ftp. Weiß einer von Euch näheres?

DrGreenthumb

das ist unsinn

Naja, bei den WinInet Funktionen von Windows ist es z.B. so, dass beim http Protokoll (nicht www) Dateien möglichst (Text)Zeilenweise übertragen werden.
Vermutlich sind auch viele http-Server zum kurzfristigen Senden von kleinen Textdateien optimiert, während die typische FTP-Verbindung etwas länger dauert.

DrGreenthumb

es gibt doch einen content-type. Wieso sollte man da alles nach Zeilen auswerten.

Yup, du hast recht. Gilt nur für html-Dateien.

tosto

www ist kein protokoll.
du meinst wahrscheinlich http.
rein theoretisch ist ftp in der hinsicht besser, aufgrund des schlankeren headers, wenn ich das richtig in erinnerung habe.
in der praxis merkst du davon aber wirklich nur was wenn es drauf an kommt.
generell bekomme ich mit ftp rund 2-3kbit/s mehr als mit http. bei mir reizt es das dann aber auch nicht mehr aus.
rein theoretisch ist es aber schneller, bei großen dateien!
für viele, besonders kleine, hat es aber keinen vorteil. besonders wenn viele kleine dateien runtergealden werden, z.b. automatisch per skript, ist http empfehlenswert: ftp hat eine vorgeschriebene anmeldung und authentifizierung am server, http nicht (also es wird sich natürlich am server "angemeldet", aber nicht in der form das benutzername und passwort übertragen werden müssen). das ist auch bei sog anonymous verbindungen so. das kostet zeit -> geschwindigkeits vorsprung > 0 .

ciao

DrGreenthumb

rein theoretisch ist es aber schneller, bei großen dateien!

wieso?

sarfuan

tosto schrieb:

für viele, besonders kleine, hat es aber keinen vorteil. besonders wenn viele kleine dateien runtergealden werden, z.b. automatisch per skript, ist http empfehlenswert: ftp hat eine vorgeschriebene anmeldung und authentifizierung am server, http nicht (also es wird sich natürlich am server "angemeldet", aber nicht in der form das benutzername und passwort übertragen werden müssen). das ist auch bei sog anonymous verbindungen so. das kostet zeit -> geschwindigkeits vorsprung > 0

Gerade bei vielen kleinen Dateien ist FTP deutlich effizienter als HTTP.

Bei HTTP wird bei jeder einzelnen Datei der komplette, umfangreiche HTTP-Header übertragen. Die Verbindung wird bei HTTP nicht gehalten. Das heißt, dass für jede einzelne Datei eine neue Verbindung zum Server aufgebaut werden muss (deswegen auch für jede Datei der Header). Das kostet.

Bei FTP dagegen wird am Anfang eine Kommandoverbindung aufgebaut und gehalten. Über diese Verbindung erfolgt die gesamte Kommunikation wie Login mit Username und Passwort. Diese Verbindung wird, wie gesagt, einmal aufgebaut und gehalten. Das bedeutet, es ist nur EIN Login EINMAL pro SITZUNG (und nicht pro Datei!) notwendig. Zur Übertragung von jeder einzelnen Datei wird eine Datenverbindung aufgebaut, über der dann ausschließlich die Daten der Datei übertragen werden, sonst nichts. KEIN Extra-Header für jede Datei wie bei HTTP.

tosto

KEIN Extra-Header für jede Datei wie bei HTTP.

das will ich sehn, wie du dateien ohne header durchs netz schickst :p
dei grundverbidnung zum ftp bleibt erhalten(insofern es die programme machen...), die abfragen ob die datei vorhanden ist usw. müssen aber neu gestellt werden, da fällt mehr an als bei http das einfach eine 404 oder gar nichts liefert.
für kleine dateien hat sichd as ftp protokoll bei mir noch nie bewehrt.
vll lag es daran das alle server die ich bisher nutzte die geschwindigkeit nach oben schraubten anstatt erstmal voll drauf los zu senden wie es bei http so bei mir ist. da geht die geschwindigkeit von oben nach unten, nicht umgekehrt wie es bei ftp so ist. für viele kleine dateien die per batch z.b. mit wget runtergeladen wurden hat es sich bei mir nicht rentiert.
erfahrungsbericht von mir.
soweit ich weiß ist der ftp header im gegensatz zum http nicht so "aufgebläht" erfordert aber gewisse anmelde und authentifizierungs verfahren was das ganze bei kleinen dateien in die höhe treibt das dies öffters vergenommen werden muss.

rein theoretisch ist es aber schneller, bei großen dateien!

wieso?

aufgurnd des schmaleren headers und des protokolls.

ciao

DrGreenthumb

tosto schrieb:

rein theoretisch ist es aber schneller, bei großen dateien!

wieso?

aufgurnd des schmaleren headers und des protokolls.

und wieso werden große Dateien jetzt schneller übertragen, wenn am Anfang ein kleinerer Header übertragen wurde?
Und was hat das Protokoll sonst damit zu tun?

Das würd den coolio jetzt aber auch mal interessieren.

sarfuan

tosto schrieb:

KEIN Extra-Header für jede Datei wie bei HTTP.

das will ich sehn, wie du dateien ohne header durchs netz schickst :p
dei grundverbidnung zum ftp bleibt erhalten(insofern es die programme machen...), die abfragen ob die datei vorhanden ist usw. müssen aber neu gestellt werden, da fällt mehr an als bei http das einfach eine 404 oder gar nichts liefert.

Mit FTP natürlich. Zeig ich dir doch gerne:

<< 220 gnftpd Server [home1]
>>    USER sarfuan
<< 331 Password required for sarfuan.
>>    PASS (hidden)
<< 230 User sarfuan logged in.
>>    RETR datei1
<< 150 Opening BINARY mode data connection for datei1.
<< 226 Transfer complete.
>>    RETR datei2
<< 150 Opening BINARY mode data connection for datei2.
<< 226 Transfer complete.
>>    QUIT
<< 221 Goodbye.

Und weil es so schön ist, das selbe Szenario nochmal mit HTTP:

>> GET /sarfuan/datei1 HTTP/1.1
>> HOST: sarfuan:80
<< HTTP/1.0 200 OK
   Connection: close
   Date: Tue, 23 Aug 2005 10:31:32 GMT
   Server: Apache/1.3.26 (Unix) FrontPage/5.0.2.2623 AuthMySQL/2.20
   Last-Modified: Tue, 23 Aug 2005 10:30:41 GMT
   Accept-Ranges: bytes
   Content-Length: 21
   Content-Type: text/plain

   Der Inhalt von Datei1

>> GET /sarfuan/datei2 HTTP/1.1
>> HOST: sarfuan:80
<< HTTP/1.0 200 OK
   Connection: close
   Date: Tue, 23 Aug 2005 10:31:32 GMT
   Server: Apache/1.3.26 (Unix) FrontPage/5.0.2.2623 AuthMySQL/2.20
   Last-Modified: Tue, 23 Aug 2005 10:30:41 GMT
   Accept-Ranges: bytes
   Content-Length: 21
   Content-Type: text/plain

   Der Inhalt von Datei2

Kann ich dir noch etwas zeigen oder informierst du dich jetzt doch lieber freiwillig bevor du etwas kommentierst?

Ich würde dir ja die hier empfehlen:
http://www.faqs.org/rfcs/rfc959.html
http://www.faqs.org/rfcs/rfc2616.html

Skippy

da muss ich euch ein klein wenig wiedersprechen denn das jedesmal der komplette header übertragen werden muss stimmt so nicht dann alle neueren server beherrschen den verbindungstyp keep-alive und dort brauch nur das erstemal der komplette header übertragen werden und danach nur noch der minimale da sich ja dann nur noch daten wie content-typ, dateigröße und dateiname ändern.
und wenn man dann noch im server gzip aktiviert und der client gzip unterstütz werden die daten sogar noch komprimiert übertragen was bandbreite spart

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

sarfuan

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.

Skippy

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

sarfuan

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, ...

DrGreenthumb

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.

rüdiger

FTP ist doch vor allem deswegen problematisch, weil man eine weitere Datenverbindung öffnen muss, was zB bei Firewalls problematisch werden kann.

sarfuan

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?

ftp &lt;-&gt; www

ftp <-> www