4. ftp <-> www

ftp <-> www

  • S

    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

    0
  • S

    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

    0
  • ?

    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 😉

    0
  • S

    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.

    0
  • S

    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

    0
  • S

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

    0
  • D

    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.

    0
  • R

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

    0
  • S

    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?

    0
  • D

    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.

    0
  • U

    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.

    0
  • R

    Gibt ja auch noch WebDAV

    0
Anmelden zum Antworten