Login
Newsletter
Werbung

Thema: HTTP/3 vor weiteren Hürden

28 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von schmidicom am Mo, 16. März 2020 um 16:12 #

ine Implementation von QUIC im Kernel könnte zumindest einige Kontextwechsel zwischen Kernel und Anwendungen einsparen. Das würde aber auch eine neue TLS-Implementation im Kernel erfordern, da QUIC TLS anders verwendet als es bisher implementiert ist.
Bei dem Theater das einige wegen "Kernel TLS" gemacht haben dürfte so etwas wohl wenig Chancen auf Erfolg haben...

  • 2
    Von Andy_m4 am Mo, 16. März 2020 um 16:17 #

    Meines Erachtens hat sowas auch im Kernel nix verloren. Die sind tendenziell jetzt schon zu aufgebläht.
    Denn Bugs oder gar Sicherheitslücken sind halt auf Kernel-Ebene immer am verheerendsten.

    Wenn also so was im Kernel implementiert werden muss, damit es schnell genug ist, ist schon das Konzept ansich ähm .... suboptimal.

    • 1
      Von Yugga am Di, 17. März 2020 um 12:08 #

      Du willst damit sagen dass das konzept eines Filesystems ansich suboptimal ist?
      Koennte man sogar hineininterpretieren dass das konzept eines Mono-Kernel...suboptimal ist?

5
Von Andy_m4 am Mo, 16. März 2020 um 16:15 #

Ein Nachfolger wurde für notwendig erachtet, da die massive Steigerung der Bedeutung des WWW zu Anforderungen nach mehr Geschwindigkeit und niedrigeren Latenzen führte.
Mal ehrlich. Eigentlich braucht "niemand" HTTP/3. Die Notwendigkeit ergibt sich doch eher daraus, das Webseiten heutzutage total aufgeblasen werden durch Schnickschack, Endlose Einbindung von externen Ressourcen/Frameworks usw. und natürlich jede Menge Werbung.

Gefühlt war das Internet in den 90er Jahren ähnlich schnell wie heute. Und das, obwohl wir da noch HTTP/1.0 hatten und über Modem (ich hatte anfangs sogar nur ein 14,4 kbit/s Modem).
Heute hat man DEUTLICH mehr Bandbreite und DEUTLICH schnellere Computer und es gibt offenbar trotzdem ein Problem.

Und einfach nur was schneller machen wird deshalb auch in Zukunft nicht helfen. Denn historisch betrachtet wurde Geschwindigkeitszuwachs hauptsächlich durch zusätzlichen Bullshit aufgefressen.

  • 1
    Von St3ve am Mo, 16. März 2020 um 17:20 #

    :up: wahre Worte :up:

    1
    Von klopskind am Mo, 16. März 2020 um 23:17 #

    Ja, vernünftig ist leider Vieles nicht. Aber es ist nunmal leider Realität. HTTP/3 selbst trägt an diesen Entwicklungen jedoch keine Schuld, oder? Und wieso nicht auf Protokollebene Dinge optimieren und Ressourcen sparen, wo es geht? Letztlich ist es auch eine Kostenfrage für die großen Betreiber von Netzinfrastruktur.

    1
    Von Tom_Sawyer am Di, 17. März 2020 um 07:17 #

    Gefühlt war das Internet in den 90er Jahren ähnlich schnell wie heute.
    Das trifft nur zu, wer in den 90ern schon einen Internetzugang bei der Uni hatte. Damals hatten wir noch Ping-Zeiten von 200-400ms bei 56K Modems, mit denen die Mehrheit bestenfalls ins Netz kam.

    Heute hat man DEUTLICH mehr Bandbreite

    Ach hättest du nur den Artikel gelesen, dass die Signallaufzeiten das Problem sind und gerade nicht die Bandbreite, dann würdest du auch nicht behaupten, dass "niemand" HTTP/3 braucht. Das braucht vielleicht nicht jeder - wie 4G oder 5G - aber jeder der es hat, will nicht mehr zu GPRS oder Edge zurück.

    • 1
      Von Andy_m4 am Di, 17. März 2020 um 09:34 #

      Ach hättest du nur den Artikel gelesen
      Ach hättest Du nur mein Posting gelesen.

      0
      Von kamome umidori am Mi, 18. März 2020 um 10:25 #

      > will nicht mehr zu GPRS oder Edge zurück.

      Ich dafür zu Kabel und Faser (nicht, dass ich wirklich 4G- oder 5G-Nutzer wäre)!

    0
    Von schmidicom am Di, 17. März 2020 um 08:01 #

    Es gibt schon einige Dinge die von einer Protokoll-Optimierung profitieren würden, zum Beispiel WebRTC.

    0
    Von Froz am Di, 17. März 2020 um 09:34 #

    Ich muss dir leider zustimmen, ich bin selbst Webentwickler. Frameworks wie React oder Vue sehen schön aus und bringen interessante Features zur Wiederverwendbarkeit und sauberen Abtrennung von Komponenten mit. Die Wahrheit ist allerdings, sehr komplexe Komponenten aus Stackoverflow-Antworten, die nie wieder wiederverwendet werden. Die Ressourcen zur Optimierung haben nur die wenigsten Firmen und viele Programmierer interessieren sich wenig für Qualität sondern nur um die TTD (Total Time to Deploy).

    Das Web könnte sehr schnell, responsive, funktional und wiederverwendbar sein. Leider scheitert es an den Unternehmen und vielen Programmierern. :/

    • 0
      Von Yugga am Di, 17. März 2020 um 12:13 #

      Trotzdem ist doch eine optimierung auf protokoll-ebene keine schlechte sache oder?
      Das ist wie zu sagen, niemand braucht lzma macht doch einfach weniger daten dann genuegt zip allemal.

    0
    Von hoschi am Di, 17. März 2020 um 16:46 #

    Sehe ich ähnlich. Ich habe den Eindruck, Google schafft einen Standard. Findet den doof, macht den nächsten konkurrierenden Standard. Google hat dem IETF HTTP/2 angedient. Und es ist gescheitert.Weil es niemand benützt und jetzt wollen sie HTTP/3 gleich nachlegen. Nicht alles was Google macht ist richtig, HPKP war auch ein Fehler.

    Felix von Leitner hat oft nicht recht, aber da steckt auch wahres dahinter:
    https://blog.fefe.de/?ts=aa031bbb

    Nur weil etwas nicht perfekt ist wie HTTP/1 muss es nicht weg. Es funktioniert, ist weit verbreitet und sowohl Verschlüsselung als auch Pipelining kann man mit HTTP/1.1 erreichen. TCP funktioniert und garantiert mir, dass die Bytes ankommen, UDP nicht und bietet dafür mehr Durchsatz. Für Website brauchen wir also TCP, aber UDP ist ja "schneller". Also frickeln man da mit QUIC noch was dran.

    • 1
      Von Yugga am Di, 17. März 2020 um 17:43 #

      Http2 ist nicht schlecht wenn es jeder nutzen kann, was wirklich schlecht ist und von Google kommt ist AMP.....das sollte "verboten" werden

      0
      Von Yugga am Di, 17. März 2020 um 17:48 #

      Zudem setzt quic nur auf UDP auf, und macht in einer hoeheren ebene das congestion controll und loss recovery von packeten:

      https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/129618/
      QUIC-authors-copy.pdf

      0
      Von Verfluchtnochmal_5987108 am Fr, 20. März 2020 um 02:36 #

      Deppata du brauchst kein tcp sondern nur dessen Eigenschaften die sich auf Basis von udp problemlos implementieren lassen und zwar ohne dem ganzen Schwachsinn der für heutige Netze oftmals mehr Nachteile als Vorteile bringt

      http3 sendet nicht einfach blind Pakete und wenn die Hälfte am Weg verloren gegangen ist wird das genauso behandelt wie per tcp

0
Von Tipp Fehler am Di, 17. März 2020 um 08:44 #

"QUIC selbst baut auf UDP auf und stellt wie TCP einen zuverlässigen, verlustfreien Transport bereit, aber ohne die genannten Nachteile von TLS"
... wohl heißen, die Nachteile von TCP.

Es ist allerdings schon so eine Sache, ein eigentlich ohne Vollständigkeitsprüfung veranlagtes UDP im Nachhinein mit einem Framework zur verlustfreien Übertragung zu versehen. Von hinten durch die Brust ins Auge sozusagen.

"tcpdump unterstützt QUIC noch gar nicht" Naja, UDP-Pakete kann es schon mitschreiben. Nur viellicht die Zusammenhänge des QUIC nicht erkennen. Ist auch schwer, wenn es noch nicht mal eine gültige Spezifikation gibt. Wäre Kaffesatzleserei mehr zu erwarten als schon bekannt ist. Und wenn es festgelegte Standards gibt, dürfen Programmierer auch erst mal programmieren und müssen nicht auf der Stelle was im Hut haben. Also ales im grünen Bereich.

  • 0
    Von Yugga am Di, 17. März 2020 um 18:24 #

    Das stimmt nicht, was man will ist ein einfaches schnelles "base-protokoll" auf diesem aufsetztend machst du dann die erweiterungen die Du willst.

    Ist auf jedenfall besser als ein 'fettes' basisprotokoll wo Du dann probleme hast weil Dir 'feautures' in einer tieferen schicht das leben schwer machen, sollte Unix-Leuten eigentlich klar sein....beispiel WebRTC...da ist es egal ob du einen frame verlierst...hauptsache das ganze ist fluessig und muss nicht auf verpasste frames warten.

    Viele Dinge die TCP (und zu dieser Zeit zurecht) umsetzt willst Du heute nicht mehr "dort unten" haben sondern in einer hoeheren Schicht die du kontrollieren kannst.

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung