1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Altes Protokoll: Debian-Projekt…

Alternative Fakten oder wie?

  1. Thema

Neues Thema Ansicht wechseln


  1. Alternative Fakten oder wie?

    Autor: /mecki78 26.04.17 - 16:50

    > So biete die Technik "keine Unterstützung für Caching
    > oder Beschleunigungstechniken", die Implementierung
    > für die FTP-Technik stagniere und sie sei zudem
    > "schwierig einzurichten und zu benutzen". Ebenso sei das
    > Protokoll ineffizient und erfordere umständliche Basteleien
    > an Firewalls oder Load-Balancern.

    Also, dass FTP selber keine Unterstützung für Caching oder Beschleunigungstechniken ist korrekt... aber das bietet HTTP auch nicht. Diese wurden um HTTP herum gebaut (z.B. HTTP Proxies) und diese hätte man um FTP genauso herum bauen können. Dass das kaum einer gemacht hat, weil es da anscheinend nicht genug Interesse für gab, das ist eine andere Geschichte; aber es gibt FTP Proxy AFAIK.

    Oder meinen die hier das Caching, des Webbrowsers? Ja, das gibt es bei FTP wirklich nicht, aber spielt aber bei einmaligen Downloads keine Rolle, d.h. so gesehen ist die Aussage zwar auch korrekt, aber für den Use Case hier völlig irrelevant. Und da sich die Dateien nicht ändern (nicht ohne den Namen zu ändern) kann man so ein Caching auch super einfach selber implementieren.

    Dann stagniert natürlich die Entwicklung, denn die Clients/Servers sind Feature Complete. Das Protokoll wurde ja seit ewigen Zeiten nicht mehr verändert und die Clients können alles was man mit FTP kann, was genau soll man da jetzt noch groß entwickeln?

    Und schwierig einzurichten? Ich kenne FTP Server, die hat man mit 3 Mausklicks eingerichtet und selbst wenn man FTP per Hand mit einem Config File konfigurieren muss... schon mal einen Webserver von Hand eingerichtet? Wo bitte soll das einfacher sein?

    Ich kann auch nicht nachvollziehen, was an dem Protokoll ineffizient sein soll. Beim "Browsen" ist es genauso effizient wie HTTP, sogar besser, da es immer die Verbindung offen hält (HTTP erst seit HTTP/1.1 und nur wenn der Server das erlaubt) und beim Datentransfer sogar noch effizienter (Null Protokoll Overhead). Wenn es also danach geht, hätte man HTTP schon ewig killen müssen.

    Bastelleinen an Firewalls? Nicht auf der Client Seite wenn man PASSIVE FTP nutzt, und das ist heute eigentlich der Standard. Und auch auf der Serverseite muss man nur mindestens einen zweiten Port freigeben, aber das war's dann auch schon, wenn der FTP Server halbwegs gut programmiert ist und nicht der primitivste ist, den man für kein Geld bekommt.

    Und Load Balancer? I beg to defer! Gerade FTP lässt sich viel einfacher Load Balancing als HTTP, eben weil es eine Kontrollverbindung und Datenverbindungen gibt. Ein Front Server kann die Aufgabe übernehmen sich um alle Kontrollverbindungen zu kümmern bzw. auch das können mehrere sein, wo einfach eingehende Anfragen zufällig verteilt werden, und für die Datenverbindungen, wenn der Nutzer dann wirklich was herunterladen möchte, kann dann ein ganz anderer Server aus irgend einer Serverfarm diesen Part übernehmen. Der muss dann wiederum nichts von FTP wissen, sondern braucht nur einen Client, den man sagen kann "Wenn IP Adresse a.b.c.d sich zu deinem Port x verbindet, dann schickst du über diese Verbindung den Inhalt folgender Datei und beendest die Verbindung" Mehr muss der Client dort nicht können. Das sind vielleicht 500 Zeilen C Code.

    Nicht das ich FTP eine Träne nachweinen werde, es ist ein Kackprotokoll, aber die ganzen Argumente hier sind alle nur vorgeschoben und so wie sie dastehen schlicht unwahr. Die Wahrheit ist:

    1) Wir sind zu faul was eigenes zu machen.
    2) Für HTTP bekommen wir fertige Lösungen umsonst.
    3) FTP passt aber nicht zu diesen fertigen Lösungen.
    4) Wir finden FTP auch Kacke und daher weg damit.

    Würde man es so begründen, dann wäre das wenigstens ehrlich.

    /Mecki



    1 mal bearbeitet, zuletzt am 26.04.17 16:51 durch /mecki78.

  2. Re: Alternative Fakten oder wie?

    Autor: _Pluto1010_ 27.04.17 - 07:57

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Ich kann auch nicht nachvollziehen, was an dem Protokoll ineffizient sein
    > soll. Beim "Browsen" ist es genauso effizient wie HTTP, sogar besser, da es
    > immer die Verbindung offen hält (HTTP erst seit HTTP/1.1 und nur wenn der
    > Server das erlaubt) und beim Datentransfer sogar noch effizienter (Null
    > Protokoll Overhead). Wenn es also danach geht, hätte man HTTP schon ewig
    > killen müssen.

    Es ist aber doch aufwendiger zwei Connections aufzumachen und eine dabei offen zu halten. Und das nur um eine Datei anzufragen. Das Browsen selber kommt ja wohl bei nem Debian apt oder sowas eher nicht vor. Die Laden immer gezielt Dateien herunter. Also ist es sinnvoll wenn man diese Dateien mit einer Verbindung und Anfrage direkt anfragen kann. Und dann kann man meinetwegen auch via HTTP 1.1 oder weiterem schönen Werkzeug noch Verbindungszeiten reduzieren. Oder via HTTP 2 sogar Chunking verwenden um Dinge parallel anzufordern (warum auch immer).

    HTTP ist in der Implementierung einfacher als FTP. Allein schon weil der ganze Aktiv-Passiv-Zirkus entfällt. HTTP ist immer Aktiv. Und das geht ganz toll per NAT.

  3. Re: Alternative Fakten oder wie?

    Autor: /mecki78 27.04.17 - 12:35

    _Pluto1010_ schrieb:
    --------------------------------------------------------------------------------
    > Es ist aber doch aufwendiger zwei Connections aufzumachen und eine dabei
    > offen zu halten.

    ... sagt er, und warf sein Downloadbeschleunigerplugin im Browser an, das 16 Verbindungen zum Server zeitgleich offen hält.

    Bei FTP wirst du kaum erleben, dass ein Client mehr als Zwei Verbindungen aufmacht - und das muss ja nicht zum selben Server sein (das ist ja eines der wenigen coolen Features von FTP! Du kannst getrennte Datenserver und Kontrollserver haben, wovon der Client nichts groß wissen oder verstehen muss). Bei HTTP hingegen, naja, Browser machen so im Schnitt 24 bis 32 Verbindungen zum gleichen Server auf, wenn du einfach nur eine Webseite abrufst, auch mit Keep-Alive sind 4-8 Verbindungen nicht unüblich.

    Speziell für den apt-get Fall würde ich nur einen fetten Kontrollserver bauen, der kann problemlos alle FTP Anfragen zeitgleich verarbeiten und dann eben beliebige Datenserver daneben stellen, die als reine Datenpumpen arbeiten. Letztere sind super primitiv, die brauchen keinen FTP Server oder einen HTTP Server, die brauchen (wie gesagt) nur ein kleines Programm, dass ich dir mit 500-1000 Zeilen C Code in nur einen Tag schreibe bzw. das kriege ich auch als Python oder Ruby Script hin, kein Thema. Ich mach's dir sogar mit PERL. Und das ist alles, wirklich alles was da laufen muss. CPU Verbrauch? Fast nix. Speicherverbrauch? Lächerlich. Noch billiger, noch einfacher, noch weniger Resourcen geht gar nicht als das. Und auch der FTP Kontrollserver belegt vielleicht 20-25% so viele Resourcen wie der einfachste HTTP Server braucht, den ich kenne.

    Man muss diese Lösung nur basteln, weil es sie nicht fertig gibt, aber alles hat es irgendwann mal nicht fertig gegeben, alles musste ja irgendwann mal irgendwer basteln. Jede noch so primitive HTTP Load Balancing Technik ist ungelogen mindestens 10x mal komplexer als das und verbraucht ein vielfaches an Resourcen.

    /Mecki

  4. Re: Alternative Fakten oder wie?

    Autor: Menplant 27.04.17 - 16:55

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > > So biete die Technik "keine Unterstützung für Caching
    > > oder Beschleunigungstechniken", die Implementierung
    > > für die FTP-Technik stagniere und sie sei zudem
    > > "schwierig einzurichten und zu benutzen". Ebenso sei das
    > > Protokoll ineffizient und erfordere umständliche Basteleien
    > > an Firewalls oder Load-Balancern.
    >
    > Also, dass FTP selber keine Unterstützung für Caching oder
    > Beschleunigungstechniken ist korrekt... aber das bietet HTTP auch nicht.
    > Diese wurden um HTTP herum gebaut (z.B. HTTP Proxies) und diese hätte man
    > um FTP genauso herum bauen können. Dass das kaum einer gemacht hat, weil es
    > da anscheinend nicht genug Interesse für gab, das ist eine andere
    > Geschichte; aber es gibt FTP Proxy AFAIK.
    >
    > Oder meinen die hier das Caching, des Webbrowsers? Ja, das gibt es bei FTP
    > wirklich nicht, aber spielt aber bei einmaligen Downloads keine Rolle, d.h.
    > so gesehen ist die Aussage zwar auch korrekt, aber für den Use Case hier
    > völlig irrelevant. Und da sich die Dateien nicht ändern (nicht ohne den
    > Namen zu ändern) kann man so ein Caching auch super einfach selber
    > implementieren.
    >
    > Dann stagniert natürlich die Entwicklung, denn die Clients/Servers sind
    > Feature Complete. Das Protokoll wurde ja seit ewigen Zeiten nicht mehr
    > verändert und die Clients können alles was man mit FTP kann, was genau soll
    > man da jetzt noch groß entwickeln?
    >
    > Und schwierig einzurichten? Ich kenne FTP Server, die hat man mit 3
    > Mausklicks eingerichtet und selbst wenn man FTP per Hand mit einem Config
    > File konfigurieren muss... schon mal einen Webserver von Hand eingerichtet?
    > Wo bitte soll das einfacher sein?
    >
    > Ich kann auch nicht nachvollziehen, was an dem Protokoll ineffizient sein
    > soll. Beim "Browsen" ist es genauso effizient wie HTTP, sogar besser, da es
    > immer die Verbindung offen hält (HTTP erst seit HTTP/1.1 und nur wenn der
    > Server das erlaubt) und beim Datentransfer sogar noch effizienter (Null
    > Protokoll Overhead). Wenn es also danach geht, hätte man HTTP schon ewig
    > killen müssen.
    >
    > Bastelleinen an Firewalls? Nicht auf der Client Seite wenn man PASSIVE FTP
    > nutzt, und das ist heute eigentlich der Standard. Und auch auf der
    > Serverseite muss man nur mindestens einen zweiten Port freigeben, aber das
    > war's dann auch schon, wenn der FTP Server halbwegs gut programmiert ist
    > und nicht der primitivste ist, den man für kein Geld bekommt.
    >
    > Und Load Balancer? I beg to defer! Gerade FTP lässt sich viel einfacher
    > Load Balancing als HTTP, eben weil es eine Kontrollverbindung und
    > Datenverbindungen gibt. Ein Front Server kann die Aufgabe übernehmen sich
    > um alle Kontrollverbindungen zu kümmern bzw. auch das können mehrere sein,
    > wo einfach eingehende Anfragen zufällig verteilt werden, und für die
    > Datenverbindungen, wenn der Nutzer dann wirklich was herunterladen möchte,
    > kann dann ein ganz anderer Server aus irgend einer Serverfarm diesen Part
    > übernehmen. Der muss dann wiederum nichts von FTP wissen, sondern braucht
    > nur einen Client, den man sagen kann "Wenn IP Adresse a.b.c.d sich zu
    > deinem Port x verbindet, dann schickst du über diese Verbindung den Inhalt
    > folgender Datei und beendest die Verbindung" Mehr muss der Client dort
    > nicht können. Das sind vielleicht 500 Zeilen C Code.
    >
    > Nicht das ich FTP eine Träne nachweinen werde, es ist ein Kackprotokoll,
    > aber die ganzen Argumente hier sind alle nur vorgeschoben und so wie sie
    > dastehen schlicht unwahr. Die Wahrheit ist:
    >
    > 1) Wir sind zu faul was eigenes zu machen.
    > 2) Für HTTP bekommen wir fertige Lösungen umsonst.
    > 3) FTP passt aber nicht zu diesen fertigen Lösungen.
    > 4) Wir finden FTP auch Kacke und daher weg damit.
    >
    > Würde man es so begründen, dann wäre das wenigstens ehrlich.

    +1
    Bin kein Profi auf dem Gebiet aber klingt nachvollziehbar.

  5. Re: Alternative Fakten oder wie?

    Autor: hjp 27.04.17 - 20:10

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > > So biete die Technik "keine Unterstützung für Caching
    > > oder Beschleunigungstechniken", die Implementierung
    > > für die FTP-Technik stagniere und sie sei zudem
    > > "schwierig einzurichten und zu benutzen". Ebenso sei das
    > > Protokoll ineffizient und erfordere umständliche Basteleien
    > > an Firewalls oder Load-Balancern.
    >
    > Also, dass FTP selber keine Unterstützung für Caching oder
    > Beschleunigungstechniken ist korrekt... aber das bietet HTTP auch nicht.
    > Diese wurden um HTTP herum gebaut (z.B. HTTP Proxies) und diese hätte man
    > um FTP genauso herum bauen können.

    Hätte man vielleicht können, hat man aber nicht. In HTTP hingegen wurden entsprechende Erweiterungen eingebaut - de facto bereits mit HTTP/1.0, wirklich offiziell spezifiziert aber erst mit HTTP/1.1 (glaube ich, das ist ja jetzt auch schon ein Zeiterl her).

    > Dass das kaum einer gemacht hat, weil es
    > da anscheinend nicht genug Interesse für gab, das ist eine andere
    > Geschichte; aber es gibt FTP Proxy AFAIK.
    >
    > Oder meinen die hier das Caching, des Webbrowsers? Ja, das gibt es bei FTP
    > wirklich nicht, aber spielt aber bei einmaligen Downloads keine Rolle, d.h.
    > so gesehen ist die Aussage zwar auch korrekt, aber für den Use Case hier
    > völlig irrelevant. Und da sich die Dateien nicht ändern (nicht ohne den
    > Namen zu ändern) kann man so ein Caching auch super einfach selber
    > implementieren.

    Das stimmt nicht. Die Files eines Debian-Repositorys ändern sich sehr wohl. Und als wir noch einen Squid hatten (und eine nicht besonders schnelle Internet-Anbindung), hat es auch einen deutlichen Unterschied gemacht, ob 20 Debian-Rechner direkt oder über den Proxy auf das Repository zugegriffen haben.

    Relevanter dürfte im allgemeinen Fall (nicht unbedingt bei Debian, wo das anders gelöst ist) aber wohl das Caching durch CDNs sein. Natürlich könnte man da auch für FTP was basteln, aber HTTP hat diese Features halt bereits.

    > Dann stagniert natürlich die Entwicklung, denn die Clients/Servers sind
    > Feature Complete. Das Protokoll wurde ja seit ewigen Zeiten nicht mehr
    > verändert und die Clients können alles was man mit FTP kann, was genau soll
    > man da jetzt noch groß entwickeln?

    Das, was FTP eben alles nicht kann. Aber nein, man sollte das nicht entwickeln. FTP soll endlich sterben. Das ist seit 20 Jahren überfällig.


    > Ich kann auch nicht nachvollziehen, was an dem Protokoll ineffizient sein
    > soll. Beim "Browsen" ist es genauso effizient wie HTTP, sogar besser, da es
    > immer die Verbindung offen hält (HTTP erst seit HTTP/1.1 und nur wenn der
    > Server das erlaubt) und beim Datentransfer sogar noch effizienter (Null
    > Protokoll Overhead). Wenn es also danach geht, hätte man HTTP schon ewig
    > killen müssen.

    Für jeden Dateitransfer eine eigene Verbindung aufmachen zu müssen, finde ich jetzt nicht sonderlich effizient. Das ist nicht "null Overhead", denn gerade der Verbindungaufbau ist bei TCP relativ teuer. HTTP kann persistente Connections seit ca. 18 Jahren (HTTP/1.1 wurde 1999 spezifiziert).

    > Bastelleinen an Firewalls? Nicht auf der Client Seite wenn man PASSIVE FTP
    > nutzt, und das ist heute eigentlich der Standard. Und auch auf der
    > Serverseite muss man nur mindestens einen zweiten Port freigeben, aber das
    > war's dann auch schon, wenn der FTP Server halbwegs gut programmiert ist
    > und nicht der primitivste ist, den man für kein Geld bekommt.

    Ein zweiter Port reicht nicht, man braucht beliebig viele Ports (jedenfalls wenn man damit rechnet, mehrere Connections von der gleichen IP-Adresse (NAT) zu bekommen). Also entweder am serverseitigen Firewall dynamisch Ports öffnen (braucht entsprechendes Modul), oder ausreichend große Port-Range statisch freigeben (und hoffen, dass sich dort nichts anderes einnistet), oder am besten einen dedizierten FTP-Server ohne Firewall. Alles nicht so prickelnd, vor allem, wenn man auf "Sponsoren" angewiesen ist.

    > Und Load Balancer? I beg to defer!

    You what?

    > Gerade FTP lässt sich viel einfacher
    > Load Balancing als HTTP, eben weil es eine Kontrollverbindung und
    > Datenverbindungen gibt. Ein Front Server kann die Aufgabe übernehmen sich
    > um alle Kontrollverbindungen zu kümmern bzw. auch das können mehrere sein,
    > wo einfach eingehende Anfragen zufällig verteilt werden, und für die
    > Datenverbindungen, wenn der Nutzer dann wirklich was herunterladen möchte,
    > kann dann ein ganz anderer Server aus irgend einer Serverfarm diesen Part
    > übernehmen. Der muss dann wiederum nichts von FTP wissen, sondern braucht
    > nur einen Client, den man sagen kann "Wenn IP Adresse a.b.c.d sich zu
    > deinem Port x verbindet, dann schickst du über diese Verbindung den Inhalt
    > folgender Datei und beendest die Verbindung" Mehr muss der Client dort
    > nicht können. Das sind vielleicht 500 Zeilen C Code.
    >
    > Nicht das ich FTP eine Träne nachweinen werde, es ist ein Kackprotokoll,
    > aber die ganzen Argumente hier sind alle nur vorgeschoben und so wie sie
    > dastehen schlicht unwahr. Die Wahrheit ist:
    >
    > 1) Wir sind zu faul was eigenes zu machen.

    Was hat das mit FTP zu tun? FTP existiert, da muss man nichts eigenes machen. Man muss allerdings im Fall von Debian Freiwillige (meistens wohl Firmen) davon überzeugen, dass sie einen FTP-Server betreiben sollen.

    Natürlich könnte man einen eigenen verteilten FTP-Server schreiben, so wie Du ihn oben skizziert hast. Aber dann musst Du nicht nur Leute davon überzeugen, dass sie einen Standard-FTP-Server ihrer Wahl betreiben, sondern deinen Spezialserver.

    > 2) Für HTTP bekommen wir fertige Lösungen umsonst.

    Vor allem wird jeder, der anbietet, einen Debian-Mirror zu betreiben, bereits einen HTTP-Server haben und Leute, die sich damit auskennen. Das ist das wesentlich wichtigere Argument als ein paar Euro Lizenz-Kosten.

    > 3) FTP passt aber nicht zu diesen fertigen Lösungen.
    > 4) Wir finden FTP auch Kacke und daher weg damit.

    Das ist das wichtigste Argument. FTP war schon vor 20 Jahren Kacke. Für Downloads hat es keinen Vorteil gegenüber HTTP, aber etliche Nachteile. Für Uploads war es leider noch einige Zeit unverzichtbar, aber erstens ist das auch schon einige Zeit her und zweitens ist das für den Anwendungsfall irrelevant.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Hessisches Ministerium der Finanzen / FITKO, Frankfurt am Main, Berlin
  2. Altair Engineering GmbH, Böblingen, München
  3. Hochschule Furtwangen, Furtwangen
  4. Landratsamt Starnberg, Starnberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 38,40€ (Preis wird im Warenkorb angezeigt. Vergleichspreis 89,99€)
  2. (aktuell u. a. Logitech G703 Hero Lightspeed für 65€ statt ca. 75€ im Vergleich im Vergleich...
  3. (aktuell u. a. Corsair Gaming Sabre RGB als neuwertiger Outlet-Artikel für 24,99€ + Versand...
  4. (u. a. bis zu 27% auf Raspberry Pi und 20% auf TP-Link)


Haben wir etwas übersehen?

E-Mail an news@golem.de