HTTP/3 ist da: TCP fliegt raus - es geht schneller und sogar verschlüsselt

Einmal mehr wird Google einen wichtigen Beitrag zur Weiterentwicklung des Webs leisten: Das experimentelle Protokoll HTTP-over-QUIC wird nach einem Beschluss der Ingenieure des Netzes offiziell zur dritten Version des wichtigen HTTP erhoben. mehr... Web, HTTP, WWW Bildquelle: Rock1997 (GFDL) Web, HTTP, WWW Web, HTTP, WWW Rock1997 (GFDL)

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Damit werden immer mehr ältere Browser nicht mehr benutzbar. Klar, sollte man eigentlich sowieso nicht machen, aber es gibt Leute, die mit ATARI ST, Commodore Amiga, Windows 3.11/9x oder alten Unix-Workstations noch ihren Spaß haben, und z.B. mit dem Browser NetSurf oder Mosaic unterwegs sind. Das geht dann nicht mehr, obwohl solche Rechner für moderne Malware eigentlich immun sind.
 
@1ST1: naja umstellung heißt idr sowieso nur dass HTTP3 dann erstmal geht. du kannst auch auf http2 seiten noch mit HTTP1 ran.
 
@1ST1: Und wegen 0,0....1% der Nutzer soll es keinen Fortschritt mehr geben?

Google hat vor einer Weile auch die Unterstützung für textbasierte Browser wie Lynx und co eingestellt...
 
@1ST1: Nicht dein Ernst jetzt? Mosaic-Browser... Ich dachte den gibt es genau so nicht mehr wie CompuServe und AOL. Sorry, aber wenn jemand (speziell in der Technologie) so der Vergangenheit anhängt, dann sollte er ausschließlich im Museum surfen... Im Intranet...
 
@DioGenes: Jetzt sag blos, Du hast keinen AOL Account mehr - versteh ich nicht.
 
@Deepstar: Die waren mir immer unsympathisch. Hatte nie einen ;-)
 
@DioGenes: Die waren doch geil... da konntest du doch faktisch immer umsonst surfen in einer Zeit wo es noch teuer war! Probemonat von den 1000ten CD, nutzen kündigen neuer Probemonat von der nächsten CD usw.
 
@1ST1: Für den Amiga mit OS3.x und OS4.x gibt es IBrowse, wo es noch letztes Jahr ein Update gab. Also zumindest dort, könnte es weitergehen.
 
@1ST1: Für gewöhnlich können sie Server auch weiterhin via HTTP/1.x erreicht werden. Das Problem liegt da schon eher bei der HTTPS-Zwangsweiterleitung. Uralt-Browser können mit TLS 1.x als Minimum nichts anfangen.

Und selbst wenn diese Hürde nicht besteht: Viel Spaß mit einer aktuellen Webseite (HTML5/CSS3 inkl. JavaScript) in diesen alten Browsern :D
 
@Stratus-fan: Man muss nur mal mit dem Internet Explorer von Windows 95 versuchen zu surfen...weit kommt man nicht und ein aktueller Firefox ist auch nicht mal so eben installiert.
 
@1ST1: Wie wärs mit einem Zwischenproxie, der den Server sauber abfragt und dann die Anfrage intern so umbaut das es weiter geht. Müsste doch gehen? Vielleicht schafft das sogar ein Raspi W?
 
Leider konnte ich auf die Schnelle keine Details über die Funktionsweise finden, aber wenn das Web in Zukunft wirklich über UDP verschickt wird, sehe ich enorme Nachteile für Verbindungen, die gerade mal nicht zu 100% laufen. Hoffentlich wurde das Gedöns um eine umfangreiche Paketüberprüfung erweitert.
 
@Islander: Sehe ich genauso. Bei UDP gibt es keine MSS im Header. Man kann zum Beispiel UDP nicht mitteilen, dass der Traffic über einen VPN Tunnel geht und daher mit einer kleineren Packetgrösse gearbeitet werden sollte. UDP Packete müssen daher vom VPN Router geteilt werden. Heutzutage nicht allzuschlimm, da 90% des Internetraffics TCP ist. Dies könnte sich in Zukunft aber ändern und verursacht wieder Delay. Ebenfalls können dinge wie ECN welche helfen Packetloss zu minimieren nicht verwendet werden. Das Protokoll muss selbst einen Algorythmus einbauen um verlorengegangene Packete neu anzufordern. Auf Session Based appliances wie Firewall und Router wird es ebenfalls schwierig, Verbindungen zu tracken. Sessions können nicht mehr einfach geschlossen werden da kein FYN verschickt wird. Heisst, dass Verbindungen eventuell pauschal geöffnet oder aber idle timer angepasst werden müssen. Ich hoffe die Netzwerkausrüster kommen mit neuen Firmwares und entpsrechender DeepPacketInspection daher um einige dieser Nachteile auszugleichen.
 
@pcbona: Statt ein seltsames Konstrukt zu konstruieren könnte man auch einfach in die Protokollbeschreibung schauen: https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit

Dort sieht man dann auch, dass QUIC selbst verständlich Flow Control, Connection Reliability und Congestion Control hat.
Wäre sehr seltsam wenn die IETF reines UDP für sowas durchwinken würde.
 
@NamelessOne: Ich habe nichts davon geschrieben, dass QUIC kein Flow Control oder Connection Reliability hat. Und was bringt denn ein Congestion Control, wenn die Netzwerkgeräte dazwischen dieses nicht unterstützen? Es wird sich in Zukunft zeigen wie lange es geht bis Netzwerkausrüster dies unterstützen. Im Falle von ECN dauert die Akzeptanz bereits Jahre. Das Problem der Packetgrösse ist auch nicht behoben. Ebenfalls verwendet QUIC multiplexing was das erkennen von Sessions
erschwert. Das ist für zu Hause auf dem Heim und Hobby Routern egal, aber auf Netzwerkequipment welches mit dynamischen Whitelists arbeiten um den Rücktraffic einer Anfrage zuzulassen, problematisch. Aber sendet weiter Whitelists ohne meine Bedenken verstanden zu haben...
 
@Islander: Ich melde Deinen Kommentar an Google und die IETF. Die haben das sicher übersehen, das muss man denen schnell sagen. Aber wahrscheinlich lesen die das Forum hier ja mit, sonst würdest Du das ja direkt an Google senden und nicht hierher.
 
@DailyLama: Ich gehe davon aus, dass dies Google einfach schlichtweg scheissegal ist. Business cases lagen Google noch nie am Herzen.
 
@pcbona: siehe Kommentar von namelessone: "Dort sieht man dann auch, dass QUIC selbst verständlich Flow Control, Connection Reliability und Congestion Control hat." Mit Link zur Quelle. Google hat sich dabei schon was gedacht. Du bei deinem Posting eher weniger.
 
@DailyLama: Wow, woher die aggression Mister knowitall?
 
@pcbona: "scheissegal" ist wohl freundlich und sachlich?
 
@pcbona: Er ist nicht aggressiv. Er kann sich aber informieren, Texte lesen und sie auch verstehen.
 
"Das experimentelle Protokoll HTTP-over-QUIC wird nach einem Beschluss der Ingenieure des Netzes offiziell zur dritten Version wichtigen HTTP erhoben."

Ich spende ein "des"
 
also wird das Browsen noch Mal ein wenig beschleunigt?
und wie lange braucht eine IT News Seite wie winfuture zur Umstellung, so lange wie zu HTTPS? xD
 
@neuernickzumflamen: Dafür müssen die Webserver (nginx, Apache...) das Protokoll implementieren, alles stabil laufen, Webmaster den Probebetrieb starten und dann kann es Live gehen. Das ist "etwas" komplizierter als ein Windows-Update durchzuführen, wenn man dabei nicht die komplette Webseite abschießen will.
 
google sollte mal TTS German vorantreiben
Kommentar abgeben Netiquette beachten!
Einloggen

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.