1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Fileserver: FTP sollte mit 50 endlich…

Warum http sterben sollte

Helft uns, die neuen Foren besser zu machen! Unsere kleine Umfrage dauert nur wenige Sekunden!
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Warum http sterben sollte

    Autor: fabiwanne 19.04.21 - 16:01

    So mein NAS (Nextcloud) ist jetzt mit 40G angeschlossen. Da an meinen Rechner nur 10G gehen hatte ich damit gerechnet. Also freut man sich aufs bedenkenlose auch größere Mengen Daten hin und her schieben...
    Der Webdav mount zuckelt aber leider nur mit knapp über 100MBit/s. Ein ls auf nem Orner nit ein paar duzend Dateien braucht mehrere Sekunden Google liefert schnell die Antwort: dav2fs ist wohl irgend eine Krüppelimplementierung. Also OK. Webinterface... Dateilisting geht jetzt flüssig. Aber uploads gehen selbst bei Einzeldateien nicht über 200MBit/s. Über Ordner will ich gar nicht reden. kio bricht längere uploads ohne Kommentar irgend wann ab. OK. In der Linux welt scheint da wohl was im Argen zu liegen. Windows booten und da mal testen: Sorry Dateien über 4GiB sind da leider nicht drin. (Laut MS-Doku sind es sogar nur 2GiB was nicht mal stimmt.) WTF?! Wir haben 2020 nicht 1990.
    OK einige meckern über Nextcloud und PHP mal das WebDAV vom Apache versuchen... Kein Unterschied. Scheint wirklich an den Clienten zu liegen.
    Zur Ehrenrettung muss ich zugeben, dass das Gnome meines Mitbewohners in seinem seinem Filebrowser tatsächlich fast ~1GBit/s kam solange man nur einzelne Dateien und keine Ornder und nur runter und nicht hoch lädt. – Nur nutze ich kein Gnome.

    Ende des Liedes ProFTP installiert 7GBit/s, was wohl das Limit des RAIDS ist. Egal ob im Konqueror per wget oder mount selbst mit DatenSSL. Mit vielen Dateien Bricht es ein. Aber aber selbst die Musiksamlung macht noch 3.5GBit/s. Gleicher Ordner als externer Storag im nextcloud für Leute die das Webinterface haben wollen. Fertig. So muss das. Danke an die Leute die vor 20 Jahren Software schreiben konnten, die einfach performant tut. (Zugegeben: Rechtemanagement in Nextcloud und ProFTP synchron zu bekommen war etwas mehr Arbeit aber tut.)
    Selbes Spiel habe ich mit S3. Bis das auf 10GBit/s und Latenzen unter 5ms kommt, kannst du auch erst mal 20 Jahre Optionen Optimieren währen selbst steinalte Lustre oder BeeGFSim µs-Bereich und 100GBit/s machen. Selbst ein dummes ZFS auf iSER flutscht um Größenordnungen besser. (Kann aber nur einen Client haben.) Aber Dateisysteme sind sowas von von vorgestern...

    Sorry mir kann der HTTP dreck gestohlen bleiben.



    1 mal bearbeitet, zuletzt am 19.04.21 16:03 durch fabiwanne.

  2. Warum http leben sollte

    Autor: ttloop 19.04.21 - 16:23

    Zuviel Netzwerk-Hardware funktioniert noch und nur mit HTTP. Zum Beispiel die kleinen XPorts. HTTP ist einfach einzusetzen. Bei weitem nicht jede Anwendung benötigt aufwendigere Transfer-Verfahren. Ich werde HTTP Technik sicher nicht entsorgen weil andere Leute HTTP sterben lassen wollen.

  3. Re: Warum http leben sollte

    Autor: fabiwanne 19.04.21 - 16:42

    > Bei weitem nicht jede Anwendung benötigt aufwendigere Transfer-Verfahren.
    Volle FTP-Implementierung in C ~300 Zeilen Code.
    Minimale HTTP-Implementierung in C ~5000 Zeilen Code

    FTP-RFC: 3933 Zeilen
    HTTP: 29489 Zeilen verteilt über 11 unterschiedliche RFCs+diverse optionale Erweiterungen.

    Natürlich sollte HTTP oder zumindest QUIC (HTTP/1.1 kann gerne weg. Dafür hätte ich gerne überall ein Fallback auf primitives HTTP 1.0) nicht sterben. Die Browser können damit viele tolle Sachen machen. Aber gerade auf primitiven Geräten die nicht ein mal Googles QA-Abteiltung für die Wartung haben sollten solche Codemonster genau nichts sein. Meist wäre da TFTP oder ähnliches eher der vernünftige Weg.



    1 mal bearbeitet, zuletzt am 19.04.21 16:46 durch fabiwanne.

  4. Re: Warum http leben sollte

    Autor: MarcusK 19.04.21 - 16:45

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > > Bei weitem nicht jede Anwendung benötigt aufwendigere
    > Transfer-Verfahren.
    > Volle FTP-Implementierung in C ~300 Zeilen Code.
    > Minimale HTTP-Implementierung in C ~5000 Zeilen Code
    >
    > FTP-RFC: 3933 Zeilen
    > HTTP: 29489 Zeilen verteilt über 11 unterschiedliche RFCs+diverse optionale
    > Erweiterungen.

    netter vergleich.
    Aber es kann nicht stimmen. In 300 Zeilen code kann ich bequem einen einfachen http server unterbringen der einfach eine Seite ausliefern. Oder was meinst du mit minimal?
    Oder ist minimal der alle Funktionen unterstützt?

    Hat sogar schon jemand gemacht

    https://github.com/shenfeng/tiny-web-server/blob/master/tiny.c

    (ok, mehr als 300 Zeilen aber man kann auch noch ein paar dinge einsparen)



    1 mal bearbeitet, zuletzt am 19.04.21 16:48 durch MarcusK.

  5. Re: Warum http leben sollte

    Autor: fabiwanne 19.04.21 - 16:48

    > Aber es kann nicht stimmen. In 300 Zeilen code kann ich bequem einen einfachen http server unterbringen der einfach eine Seite ausliefern. Oder was meinst du mit minimal?
    Ein Client, der alle Funktionen die HTTP/1.1 als nicht Optional vorschreibt unterstützt.

  6. Re: Warum http leben sollte

    Autor: MarcusK 19.04.21 - 16:50

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > > Aber es kann nicht stimmen. In 300 Zeilen code kann ich bequem einen
    > einfachen http server unterbringen der einfach eine Seite ausliefern. Oder
    > was meinst du mit minimal?
    > Ein Client, der alle Funktionen die HTTP/1.1 als nicht Optional vorschreibt
    > unterstützt.

    reden wir von Server oder von Client?

  7. Re: Warum http leben sollte

    Autor: ralfh 19.04.21 - 16:50

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > > Bei weitem nicht jede Anwendung benötigt aufwendigere
    > Transfer-Verfahren.
    > Volle FTP-Implementierung in C ~300 Zeilen Code.
    > Minimale HTTP-Implementierung in C ~5000 Zeilen Code
    >
    > FTP-RFC: 3933 Zeilen
    > HTTP: 29489 Zeilen verteilt über 11 unterschiedliche RFCs+diverse optionale
    > Erweiterungen.

    Nicht alles was hinkt ist ein Vergleich. Auch zu FTP gibt es zig Erweiterungen, aber du kannst mir bestimmt eine Referenzimplementierung in 300 Zeilen C zeigen, die einen FTP Server implementiert welcher:

    a) active + passive mode unterstützt
    b) UTF-8 Dateinamen
    c) FTPS + TLS/SNI
    d) Vhosts
    e) Transfer Restarts (REST)

    Und wo wir schon dabei sind auch eine sinnvolle Behandlung der lächerlichen Unterscheidung zwischen ASCII und Binärmode.

    Oh und bevor du fragst: das habe ich mir nicht aus den Händen gezogen. Das sind tatsächlich alles reale FTP-Erweiterungen.

  8. Re: Warum http leben sollte

    Autor: fabiwanne 19.04.21 - 16:57

    Von der Fetteren Komponente. Das ist bei HTTP halt der Client, weil für HTTP-Server defakto alles Optional ist und sich der Client die Features suchen muss, die der Server unterstützt.
    Aber alleine Pipelining dürft schwer in die 300 Zeilen zu bekommen sein und das ist für den Server nicht optional. Wenn der Client das macht, muss der Server.

  9. Re: Warum http leben sollte

    Autor: MarcusK 19.04.21 - 17:03

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > Von der Fetteren Komponente. Das ist bei HTTP halt der Client, weil für
    > HTTP-Server defakto alles Optional ist und sich der Client die Features
    > suchen muss, die der Server unterstützt.
    > Aber alleine Pipelining dürft schwer in die 300 Zeilen zu bekommen sein und
    > das ist für den Server nicht optional. Wenn der Client das macht, muss der
    > Server.

    https://de.wikipedia.org/wiki/HTTP-Pipelining
    > Server, die HTTP/1.1 unterstützen, unterstützen Pipelining mindestens insofern, als
    > entsprechende Anfragen nicht zu Fehlern führen.

    es ist keine Pflicht weder im Server noch in Client.

  10. Re: Warum http leben sollte

    Autor: fabiwanne 19.04.21 - 17:22

    Passive-Mode ist Optional. Aber bekommen wir sicher unter.
    UTF-8 Dateinamen? Easy ist ja schlicht eine Admin Entscheidung, welches Flag du zurück gibst. User hat passende Namen zu verwenden. Aber zugegebener Maßen hässlich. HTTP hat da aber auch nichts vergleichbares. Server sagt halt das encoding. Wenns nicht passt passt es nicht...
    FTPS + TLS/SNI – Not my department. Und SNI ist eh ein Leak das beseitigt gehört.
    Vhosts? Das ist wirklich keine valide Erweiterung. Einfach dran zu klatschen aber vermutlich wirst du mit 90% der nicht Browser-Clienten scheitern. Nur bei HTTP ist das Pflicht.
    REST – Ja gerne und hoffentlich.

    Der hat ~1500 Zeilen. Aber wenn du geter und seter inlinest und die Kommentare raus wirfst bist du sicher unter der Hälfte. Dann noch der Java - Klasen Overhead weg....
    https://github.com/Guichaguri/MinimalFTP/tree/master/src/main/java/com/guichaguri/minimalftp
    Ähnlich groß:
    https://github.com/continental/fineftp-server/blob/master/fineftp-server/src/ftp_session.cpp
    Schmeiß die Sonderbehandlung für Win32 und debug weg und du bist in ner ähnlichen Kategorie:
    https://github.com/continental/fineftp-server/blob/master/fineftp-server/src/ftp_session.cpp

    Und wenn wir bei optionalen Features sind: jetzt fang du mal an alleine HLS zu implementieren. Wir reden dann in 10 Jahren weiter.

  11. Re: Warum http leben sollte

    Autor: fabiwanne 19.04.21 - 17:26

    Das ist unterstützen. Du musst die Anfragen beantworten und darfst keine Fehler produzieren. Die Speck ist da sehr eindeutig. – Es muss nur nicht aus prinzip schneller gehen als anders, was aber im Normalfall automatisch passieren wird, wenn du ein OS drunter hast, das Multithreadding kann. Für die Embeddend devices kannst du eine Liste machen und die nacheinander abarbeiten. Dürfte ähnlich aufwändig sein.

  12. Re: Warum http leben sollte

    Autor: MarcusK 19.04.21 - 17:30

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > Das ist unterstützen. Du musst die Anfragen beantworten und darfst keine
    > Fehler produzieren. Die Speck ist da sehr eindeutig. – Es muss nur
    > nicht aus prinzip schneller gehen als anders, was aber im Normalfall
    > automatisch passieren wird, wenn du ein OS drunter hast, das
    > Multithreadding kann. Für die Embeddend devices kannst du eine Liste machen
    > und die nacheinander abarbeiten. Dürfte ähnlich aufwändig sein.
    aber die Liste macht doch schon er TCP-Stack.

    - anfrage abrufen - bis zum \r\n\r\n
    - Anfrage bearbeiten -> Anwort senden
    - nächste anfrage lese wieder bis zum \r\n\r\n
    usw.

    sehe da nicht wirklich ein Problem.

  13. Re: Warum http leben sollte

    Autor: fabiwanne 19.04.21 - 17:46

    > aber die Liste macht doch schon er TCP-Stack.
    Nein. pipelining läuft explizit über den selben Stream. Du musst also irgend wie in deiner Anwendung multiplexen. Du kannst das zwar dumm nacheinander ausliefern. Aber Trotzdem musst du das implementieren, dass dir gleichzeitig und jederzeit Requests auflaufen können, während du sendest. Inklusive der passenden Race-Conditions.
    Genau das ist der Vorteil von FTP, wo du schlicht selbst auf nem RTOS sagen kannst: Netzwerkkarte mach das für mich: 5 Files 5 TCP-Verbindungen. 5 mal unabhängig: Mach das! Der TCP-Stack sortiert für mich was wohin gehört. Wenn er fertig ist, kannst du getrost aufräumen.
    Prinzipiell ist das HTTP-Modell effizienter, weil du eben weniger wie der TCP-Stack machen musst. Aber die Anwendung muss halt den Teil fürs Multiplexing nochmal implementieren.

  14. Re: Warum http leben sollte

    Autor: MarcusK 19.04.21 - 17:50

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > > aber die Liste macht doch schon er TCP-Stack.
    > Nein. pipelining läuft explizit über den selben Stream. Du musst also
    > irgend wie in deiner Anwendung multiplexen. Du kannst das zwar dumm
    > nacheinander ausliefern. Aber Trotzdem musst du das implementieren, dass
    > dir gleichzeitig und jederzeit Requests auflaufen können, während du
    > sendest. Inklusive der passenden Race-Conditions.
    welche Race-Conditions? Ich lasse die byte einfach in der input Queue. Wenn ich nur lese wenn ich mit den alten fertig bin gib es keine Race-Conditions. Die gibt es erst wenn man über events oder extra threads die Daten direkt und sofort einlese.

    > Aber die Anwendung muss halt den Teil fürs
    > Multiplexing nochmal implementieren.
    abhängig von der Implementierung. Wie schon oben geschrieben. Wenn man nur ein Thread hat und alles schön der reihe nach macht, gibt es keine Probleme.

  15. Re: Warum http leben sollte

    Autor: fabiwanne 19.04.21 - 18:22

    Genau das ist das Problem, dass viele Server haben: while(write(fd,&data,len)){i++}; close(fd); klingt toll. Nur verschluckst du da den 2. Request. Und spätestens beim 3. läuft dir dein RWin über...
    Du musst dir also mindestens ein send und receive Buffer vor halten, die du Interleaved füllst.
    Die primitivste Variante ist, abwächslend ~1kiB Write/reads zu machen und die Requests sobald sie fertig sind (Achtung das musst du erkennen...) an ne linked list zu schmeißen, die dann deine Sends nacheinander abarbeitet. Die müssen dann aber erkennen ob die Liste noch oder schon leer ist. Und dann hast du die beschissene Performance die die die üblichen WebDAV-Server so haben...
    Oder halt nicht implementieren und hoffen, dass die Clients das halt auch nicht tun. (Was dann der Grund ist, warum 9 von 10 Clienten so eine scheiß Performance haben.) Aber vermutlich wird das mit QUIC oder HTTP/3 besser. Das ist wirklich so kompliziert, dass jeder weiß, dass er das nicht mal kurz runter codet.



    2 mal bearbeitet, zuletzt am 19.04.21 18:24 durch fabiwanne.

  16. Re: Warum http leben sollte

    Autor: MarcusK 19.04.21 - 18:30

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > Genau das ist das Problem, dass viele Server haben:
    > while(write(fd,&data,len)){i++}; close(fd); klingt toll. Nur verschluckst
    > du da den 2. Request. Und spätestens beim 3. läuft dir dein RWin über...
    das close würde ich da schon mal weglassen.

    Und wenn das RWin überläuft, dann bekommt der der Stack schon mit und sagt der Gegenstelle das sie nicht mehr send soll - ist doch alles gut.
    Klar bekommt man damit nicht die höchste Performance aber darum geht es ja nicht.

  17. Re: Warum http sterben sollte

    Autor: redmord 19.04.21 - 18:35

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > So mein NAS (Nextcloud) ist jetzt mit 40G angeschlossen. Da an meinen
    > Rechner nur 10G gehen hatte ich damit gerechnet. Also freut man sich aufs
    > bedenkenlose auch größere Mengen Daten hin und her schieben...
    > Der Webdav mount zuckelt aber leider nur mit knapp über 100MBit/s. Ein ls
    > auf nem Orner nit ein paar duzend Dateien braucht mehrere Sekunden Google
    > liefert schnell die Antwort: dav2fs ist wohl irgend eine
    > Krüppelimplementierung. Also OK. Webinterface... Dateilisting geht jetzt
    > flüssig. Aber uploads gehen selbst bei Einzeldateien nicht über 200MBit/s.
    > Über Ordner will ich gar nicht reden. kio bricht längere uploads ohne
    > Kommentar irgend wann ab. OK. In der Linux welt scheint da wohl was im
    > Argen zu liegen. Windows booten und da mal testen: Sorry Dateien über 4GiB
    > sind da leider nicht drin. (Laut MS-Doku sind es sogar nur 2GiB was nicht
    > mal stimmt.) WTF?! Wir haben 2020 nicht 1990.
    > OK einige meckern über Nextcloud und PHP mal das WebDAV vom Apache
    > versuchen... Kein Unterschied. Scheint wirklich an den Clienten zu liegen.
    > Zur Ehrenrettung muss ich zugeben, dass das Gnome meines Mitbewohners in
    > seinem seinem Filebrowser tatsächlich fast ~1GBit/s kam solange man nur
    > einzelne Dateien und keine Ornder und nur runter und nicht hoch lädt.
    > – Nur nutze ich kein Gnome.
    >
    > Ende des Liedes ProFTP installiert 7GBit/s, was wohl das Limit des RAIDS
    > ist. Egal ob im Konqueror per wget oder mount selbst mit DatenSSL. Mit
    > vielen Dateien Bricht es ein. Aber aber selbst die Musiksamlung macht noch
    > 3.5GBit/s. Gleicher Ordner als externer Storag im nextcloud für Leute die
    > das Webinterface haben wollen. Fertig. So muss das. Danke an die Leute die
    > vor 20 Jahren Software schreiben konnten, die einfach performant tut.
    > (Zugegeben: Rechtemanagement in Nextcloud und ProFTP synchron zu bekommen
    > war etwas mehr Arbeit aber tut.)
    > Selbes Spiel habe ich mit S3. Bis das auf 10GBit/s und Latenzen unter 5ms
    > kommt, kannst du auch erst mal 20 Jahre Optionen Optimieren währen selbst
    > steinalte Lustre oder BeeGFSim µs-Bereich und 100GBit/s machen. Selbst ein
    > dummes ZFS auf iSER flutscht um Größenordnungen besser. (Kann aber nur
    > einen Client haben.) Aber Dateisysteme sind sowas von von vorgestern...
    >
    > Sorry mir kann der HTTP dreck gestohlen bleiben.

    Natürlich hast du mit HTTP im LAN eine bescheidene Leistung. Das Protokoll ist quasi nur mit Warten beschäftigt. HTTPS ist die Wahl der Qual. Danach ist der Bottleneck die Implementierung.



    1 mal bearbeitet, zuletzt am 19.04.21 18:36 durch redmord.

  18. Re: Warum http sterben sollte

    Autor: M.P. 19.04.21 - 18:50

    40g Netzwerkport am NAS...Endlich mal ein IT-Profi ...

  19. Re: Warum http leben sollte

    Autor: wasdeeh 19.04.21 - 19:41

    fabiwanne schrieb:
    --------------------------------------------------------------------------------
    > > Bei weitem nicht jede Anwendung benötigt aufwendigere
    > Transfer-Verfahren.
    > Volle FTP-Implementierung in C ~300 Zeilen Code.
    > Minimale HTTP-Implementierung in C ~5000 Zeilen Code
    >
    > FTP-RFC: 3933 Zeilen
    > HTTP: 29489 Zeilen verteilt über 11 unterschiedliche RFCs+diverse optionale
    > Erweiterungen.

    Eine "volle FTP-Implementierung" ist bei dir also RFC959 und sonst nix? LOL.

  20. Re: Warum http sterben sollte

    Autor: menno 20.04.21 - 07:12

    Nextcloud und WebDAV.
    Ist schon viele Jahre her, da war ich genervt von der Larmarschigkeit von Nextclouds WebDAV-Lösung.
    Webdav per Apache aufgesetzt und schwups, doppelt so schnell.
    Nutze beides nicht mehr.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Haufe Group, Freiburg
  2. Hays AG, Berlin
  3. Dr. August Oetker Nahrungsmittel KG, Bielefeld
  4. mahl gebhard konzepte Landschaftsarchitekten BDLA Stadtplaner Partnerschaftsgesellschaft mbB, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 3,33€
  2. 19,49€
  3. für PC, PS4/PS5, Xbox und Switch


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme