- In Umgebungen, in denen pro Verbindung 500 Mbit/s bis über 1 Gbit/s möglich sind, etwa schnelle kabelgebundene Netze, WiFi 6/7 und 5G, zeigt der Stack UDP+QUIC+HTTP/3 eine um bis zu 45,2 % niedrigere Datenübertragungsrate als TCP+TLS+HTTP/2
- Über einfache Datei-Downloads hinaus wächst der Leistungsabstand zwischen QUIC und HTTP/2 in Chrome, Edge, Firefox, Opera sowie auf Desktop- und Mobilumgebungen, je höher die Bandbreite wird
- Paket-Traces sowie Profiling von Kernel- und User-Space zeigen: Der Flaschenhals liegt eher beim Verarbeitungs-Overhead auf der Empfangsseite als auf der Sendeseite; beim QUIC-Empfang fallen mehr Pakete und User-Space-ACK-Verarbeitung an
- Die Auswirkungen auf Anwendungen führen zu einer um bis zu 9,8 % geringeren Bitrate bei DASH-Video und im Durchschnitt der 100 wichtigsten Websites zu 3,0 % längeren Seitenladezeiten
- Zur Abmilderung sind eine Verbreitung von UDP GRO auf der Empfangsseite, QUIC-freundliche Verbesserungen an GSO/GRO, Verbesserungen der Empfangslogik und die Nutzung mehrerer CPU-Kerne nötig; die Vielfalt von Client-Geräten und Betriebssystemen erschwert die Umsetzung jedoch
QUIC-Leistungslücke in Hochgeschwindigkeitsnetzen sichtbar
- QUIC ist ein multiplexendes Transportprotokoll über UDP und wurde als Transportbasis von HTTP/3 durch die IETF standardisiert
- Mehrere Unternehmen wie Google, Akamai, Meta und Cloudflare setzen QUIC seit 2013 produktiv ein; zusammen mit HTTP/3 gilt es als Kandidat, der die Web-Performance verändern könnte
- Bisherige QUIC-Performance-Studien variierten bei Implementierungen, Computing-Umgebungen und Netzwerkbedingungen; viele konzentrierten sich auf Use Cases mit geringem Durchsatz
- Der Fokus der Messungen liegt auf dem Verhalten von QUIC in Hochgeschwindigkeitsnetzen, die pro Verbindung über 500 Mbit/s oder über 1 Gbit/s erreichen, etwa schnelle kabelgebundene Links, WiFi 6/7 und 5G
- Verglichen wird nicht ein einzelnes Protokoll, sondern der gesamte Stack
- QUIC-Seite: UDP+QUIC+HTTP/3
- Herkömmliche Seite: TCP+TLS+HTTP/2
- In der Zusammenfassung werden sie jeweils QUIC und HTTP/2 genannt
Unterschiede in Datei-Download-Experimenten
- In einfachen Datei-Download-Experimenten mit cURL und dem Chromium-basierten
quic_clientwurden Congestion-Control-Algorithmen, Serverkonfiguration und Netzwerkbedingungen angeglichen - Bei relativ niedriger Bandbreite von unter etwa 600 Mbit/s war die Performance von QUIC und HTTP/2 ähnlich, bei höherer Bandbreite lag der QUIC-Durchsatz jedoch um bis zu 15,7 % niedriger als bei HTTP/2
- Mit steigender Bandbreite wurde die Leistungslücke deutlicher; während des Paketempfangs zeigte QUIC auf aktuellen Client-Hosts eine deutlich höhere CPU-Auslastung als HTTP/2
- In Experimenten mit großen Browsern wurde die Lücke noch größer
- Getestete Browser waren Chrome, Edge, Firefox, Opera
- In Chrome beginnt QUIC zurückzufallen, sobald die Bandbreite etwa 500 Mbit/s übersteigt
- Bei 1 Gbit/s ist QUIC 45,2 % langsamer als HTTP/2
- Auf schwächeren Clients wie Mobilgeräten wird die Lücke noch größer
Auswirkungen auf Webanwendungen
- Der Performance-Rückgang beschränkt sich nicht auf große Dateiübertragungen, sondern zeigt sich auch bei Anwendungen mit intermittierenden Traffic-Mustern
- Bei der Übertragung von DASH-Video-Chunks über schnelles Ethernet und 5G erreicht QUIC gegenüber HTTP/2 eine um bis zu 9,8 % niedrigere Video-Bitrate
- Diese QoE-Verschlechterung wird erst sichtbar, wenn die zugrunde liegende Bandbreite ausreichend hoch ist
- Bei 4G wird der Effekt verdeckt
- Bei 5G zeigt sich der Effekt
- In Web-Browsing-Experimenten ist die Page Load Time (PLT) von QUIC im Durchschnitt über 100 repräsentative Websites 3,0 % länger als bei HTTP/2
- Im Long Tail gibt es Fälle, in denen die Lücke bei der Seitenladezeit über 50 % liegt
Ursache des Flaschenhalses: Empfangsseitige Verarbeitung und User-Space-ACKs
- Paket-Traces und Leistungsdaten zeigen, dass QUIC-Clients deutlich mehr Pakete empfangen als bei HTTP/2-Downloads
- Wenn QUIC mit hoher Datenübertragungsrate empfängt, wächst die Verzögerung zwischen eingehenden Datenpaketen und den zugehörigen ACK-Paketen, wodurch die QUIC-Paketverarbeitungszeit steigt
- Beide Beobachtungen deuten darauf hin, dass die Ursache der QUIC-Leistungseinbußen im schnellen Internet in den Grenzen der empfangsseitigen Verarbeitungskapazität liegt
- Es gibt zwei Gründe, warum die Empfangsseite als Flaschenhals gilt
- Server sind in der Regel leistungsfähiger als Clients wie Desktops, Notebooks und Smartphones
- Das QUIC-Design bringt eigene Schwierigkeiten bei der Verarbeitung empfangener Daten mit sich
- Tiefgehendes Profiling identifizierte zwei Hauptursachen
- Zu viele Datenpakete
- Beim Download derselben Datei verursacht der UDP-Stack im Kernel deutlich mehr
netif_receive_skb-Paketlesevorgänge als TCP - Keine der untersuchten QUIC-Implementierungen nutzt UDP Generic Receive Offload, also UDP GRO
- UDP GRO fasst mehrere empfangene UDP-Datagramme in der Link-Layer-Komponente zu einem großen Datagramm zusammen, bevor sie an die Transportschicht weitergereicht werden
- Das steht im Kontrast zur breiten Verbreitung von TCP Segmentation Offload und zur jüngsten Betonung von GSO, dem Offloading auf der UDP-Sendeseite
- Beim Download derselben Datei verursacht der UDP-Stack im Kernel deutlich mehr
- User-Space-ACK-Verarbeitung
- Im User-Space hat QUIC einen höheren Overhead bei der Verarbeitung empfangener Pakete und beim Erzeugen von Antworten
- Zu den Ursachen zählen die übermäßige Zahl aus dem Kernel übergebener Pakete, die User-Space-Verarbeitung von QUIC-ACKs und das Fehlen einiger Optimierungen wie Delayed ACKs in QUIC
- Zu viele Datenpakete
Vorläufige Messungen und Ansätze zur Abmilderung
- Ein Vorabexperiment mit dem Chrome-Browser beim Download einer 1-GB-Datei zeigte, dass sich die Downloadzeit bei aktiviertem QUIC ungefähr verdoppelt
- Die Stichprobenergebnisse sind Durchschnittswerte aus 10 Durchläufen
- Desktop-Ethernet: HTTP/2 9,32 Sekunden, HTTP/3 18,60 Sekunden, also 99 % Zunahme; CPU-Auslastung steigt von 77,5 % auf 96,9 %
- Pixel 5 Low-Band-5G: HTTP/2 37,11 Sekunden, HTTP/3 78,65 Sekunden, also 112 % Zunahme; CPU-Auslastung steigt von 121,55 % auf 161,77 %
- Pixel 5 mmWave-5G: HTTP/2 30,10 Sekunden, HTTP/3 63,20 Sekunden, also 110 % Zunahme; CPU-Auslastung steigt von 128,43 % auf 165,20 %
- Die CPU-Auslastung auf dem Desktop bezieht sich auf den Browser-Netzwerkdienst, die Smartphone-Messung auf den gesamten Browserprozess
- CPU-Auslastungswerte über 100 % bedeuten, dass der Browserprozess auf einem Mehrkernsystem mehr als einen Kern genutzt hat
- Vorgeschlagene Gegenmaßnahmen sind die Verbreitung von UDP GRO auf der Empfangsseite, QUIC-freundliche Verbesserungen an GSO und GRO, Verbesserungen der empfangsseitigen QUIC-Logik sowie der QUIC-Datenempfang über mehrere CPU-Kerne
- Client-Hosts umfassen PCs, Mobilgeräte, Embedded-Geräte und verschiedene Betriebssysteme und sind damit heterogener als Server; das bringt praktische Schwierigkeiten bei der Umsetzung der Gegenmaßnahmen mit sich
- Messdaten und Quellcode werden zusammen mit der Studie veröffentlicht
1 Kommentare
Meinungen auf Hacker News
Die Branche scheint alles tun zu wollen, außer leichte Websites zu bauen.
Schon Ende der 90er war das Internet mit einer schnellen Leitung unmittelbar da, Seiten waren klein, und JavaScript gab es kaum.
Auch heute findet man noch solche schnellen, schlanken Seiten; es wirkt fast surreal, weil es sich anfühlt, als sei die Seite vollständig geladen, noch bevor man die Maustaste loslässt.
Wenn wenigstens die User Experience besser geworden wäre, könnte man es ertragen, aber auch das haben wir nicht bekommen.
Sie ist schneller und deutlich robuster geworden, und auch die Zustandsabweichungen zwischen Frontend und Backend sind verschwunden.
Für Komfortfunktionen akzeptieren wir ein Minimum an JavaScript; derzeit sind es ein paar Hundert Zeilen, und wir werden noch etwas mehr hinzufügen, damit es weiterhin ein wenig wie eine Single-Page-App wirkt.
Dadurch können wir etwa 40.000 Zeilen React und etwa 20.000 Zeilen Kotlin loswerden, müssen aber rund 30.000 Zeilen Backend-Code neu schreiben.
Trotzdem gefällt es mir.
Also sammelte ich Erfahrung, indem ich meine Homepage auf eine statische VUE.JS-Version migrierte. Die Art, View und State zu verbinden, indem Variablennamen als Strings übergeben werden, war seltsam; der Ausbau der Build-Umgebung war unnötig komplex; alles war langsam und musste auf eine bestimmte Weise gemacht werden.
Weil es alle nutzten, dachte ich, es müsse schon richtig sein. Inzwischen bin ich von dieser Sichtweise weg, und die neue Version habe ich mit rohem HTML und Templates eines statischen Site-Generators umgesetzt.
Die HTML-Größe sank um 90 %, die JS-Nutzung um 97 %, und die Build-Zeit ging von 20 Sekunden auf 2 Sekunden zurück.
Auch die User Experience wurde besser, und seit der neuen Version sind die Besuche um 30 % gestiegen.
Wenn man weniger Web einsetzt, kann das Web viel großartiger sein.
Auch im Backend besteht die Goldgrube heute darin, Microservices über per API angebundene headless SaaS-Produkte zu verkaufen, und Performance werde dann schon selbstverständlich besser, heißt es.
https://macharchitecture.com/
Wenn die Leute solche Schaufeln kaufen wollen, bleibt uns in der IT-Welt nichts anderes übrig, als solche Schaufeln auf Lager zu legen.
Mein Blog ist eine statisch gerenderte Hugo-Site ganz ohne JS, und meine Projekte basieren auf Rails und serverseitig gerendertem HTML, mit nur minimalem JS für Nice-to-have-Funktionen.
Sie funktionieren auch ohne JS.
Vielleicht sage ich das nur, weil es meine eigenen Sites sind, aber die Erfahrung ist viel besser als im Großteil des Webs, und wir haben zu viel verloren.
Google hat einmal einen rein JS-basierten Speedtest gebaut.
Damals war Ookla noch Flash-basiert, funktionierte daher nicht auf Chromebooks, und das wurde für die Installationsverantwortlichen zum Problem, wenn sie den Installationszustand verifizieren wollten.
Dabei habe ich viel darüber gelernt, wie TCP auf verschiedene Faktoren reagiert.
Die Ergebnisse dieses Artikels entsprechen ziemlich genau den Erwartungen, denn die Flusskontrolle wurde aus dem Kernel und vielleicht sogar vom Netzwerkadapter in den User Space verlagert.
TCP bietet Flusskontrolle und Reihenfolgegarantie, und QUIC zwingt einen im Grunde dazu, das selbst zu verwalten.
Dafür gibt es natürlich auch gute Gründe.
Die TCP-Staukontrolle ist bekannt dafür, bei modernen Verbindungsgeschwindigkeiten hinterherzuhinken, und es gibt zwar neue Algorithmen wie BBR, aber die haben ihren Preis [1].
Ein zentraler Punkt, der bei Netzwerk- oder Webanwendungstests viel zu oft fehlt, ist Latenz.
Wer in Asien oder Australien lebt, weiß, wie verheerend 100 ms Round-Trip-Latenz sein können.
Etwas, das völlig reaktionsschnell war, kann dadurch praktisch unbenutzbar werden; wegen des Fensters sinkt die von der Verbindung unterstützbare Bandbreite, und auch Fehler- und Staukontrolle werden träger.
Wenn ihr Netzwerke oder Web-Apps testet, empfehle ich dringend einen Test, der zufällig 100 ms zur Latenz hinzufügt [2].
Deshalb ist der Overhead von QUIC in der Praxis womöglich gar nicht so wichtig.
Denn die effektive Bandbreite über eine einzelne TCP-Verbindung oder einen QUIC-Stream kann deutlich niedriger sein als die tatsächliche rohe Bandbreite.
Anders gesagt: Selbst mit 45 % zusätzlichen Daten kann es ein Gewinn sein, wenn durch selbst verwaltete Staukontrolle die effektive Geschwindigkeit zwischen zwei Punkten höher wird.
[1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
[2]: https://bencane.com/simulating-network-latency-for-testing-i...
Rückblickend ist es offensichtlich: Bei TCP kann man einfach sagen: „Kernel, schick bitte diesen riesigen Buffer“, während UDP paketbasiert ist und schon das Senden von 0 auf den meisten Betriebssystemen und Consumer-Hardware wegen Moduswechseln CPU-Kosten verursacht.
Es gibt Workarounds, aber sie sind nicht einfach, nach meiner Erfahrung noch nicht wirklich ausgereift, und sie schränken die Wahl von Sprache, Bibliothek und Plattform ein.
Nebenbei habe ich gesehen, dass der Durchsatz stark einbricht, wenn ein MacBook im Akkubetrieb läuft; vermutlich hängt das mit den Effizienz-Kernen zusammen.
Zweitens: QUIC war bei der Staukontrolle nicht gut.
Ich habe quic-go verwendet, daher kann es je nach Umgebung anders sein, aber kein Tuning half wirklich, und wenn es neben einem TCP-Stream lief, holte sich TCP mehr Bandbreite.
Drittens ist die API seltsam.
QUIC selbst hat mehrere Streams und ist deshalb kein Drop-in-Ersatz für TCP.
Allerdings scheint die Absicht zu sein, HTTP/3 auf einer höheren Schicht zu einem Drop-in-Ersatz zu machen; das habe ich aber nicht ausprobiert, daher kann ich dazu nichts sagen.
Wenn man auf Stream-Ebene arbeitet, sollte man das im Kopf behalten.
Unterm Strich fühlte es sich ziemlich wie eine Niederlage an, zugleich habe ich aber neuen Respekt für die Optimierung und Robustheit des alten Freundes TCP gewonnen.
Es ist wirklich eine erstaunliche Technologie, und das Betriebssystem liefert sie immer kostenlos mit.
Einige der Hauptprobleme von TCP liegen auch eher an konservativen oder Legacy-Defaults als an Designfehlern.
Dinge wie Buffer-Limits unter Linux oder Nagle.
Es wäre schön, wenn man einfach TCP verbessern könnte, statt das Rad neu zu erfinden.
[1]: https://payload.app/
Es war eine Entscheidung, die für den Start von QUIC notwendig war, aber jetzt, wo es existiert, kann man sie auch erneut prüfen.
Es gibt keine technischen Hindernisse, QUIC im Kernel zu implementieren, und wenn der Performance-Vorteil groß ist, wird das ziemlich sicher bald jemand tun.
Der Unterschied ist wie Tag und Nacht.
Es gibt Presets für Slow/Fast 4G und 3G, und man kann eigene Presets erstellen, in denen Download- und Upload-Geschwindigkeit, Latenz in ms, Paketverlustrate und Paket-Warteschlangenlänge festgelegt werden; auch Paket-Neusortierung lässt sich aktivieren.
Daniel Stenberg, Ersteller und Maintainer von curl, hat vor ein paar Monaten über HTTP/3 in curl geschrieben: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
Einer der Punkte, die er hervorhob, war die höhere CPU-Auslastung von HTTP/3, und zwar so stark, dass die CPU den Durchsatz begrenzte.
Ich frage mich, wie viel davon auf die Unreife der Implementierung zurückzuführen ist und wie viel auf Eigenschaften des QUIC-Designs selbst.
Die dritte Empfehlung ist UDP GRO: Kernel, idealerweise auch NIC-Hardware, so anzupassen, dass eingehende UDP-Pakete gebündelt werden und Arbeit pro Paket durch Arbeit pro Gruppe ersetzt wird.
Bei TCP gibt es das bereits, und auf der Sendeseite existieren ähnliche Mechanismen wie TSO bzw. GSO unter Linux.
Auch das fühlt sich nach Unreife an, könnte aber wegen fehlender Hardwarefunktionen schwerer zu beheben sein.
Das Abstract spricht von den Kosten des ACK-Verfahrens von QUIC, aber diese Argumentation habe ich mir nicht im Detail angesehen.
Eine weitere Funktion, die man bei modernen TCP-basierten Servern sieht, ist das Offloading von TLS in Hardware.
Bei Servern, die gleichzeitig viele TCP-Streams senden, scheint das wichtiger zu sein.
Unter Linux geht das über User-Space-Networking oder über „kernel tls“ und wird, wenn möglich, in Hardware ausgelagert.
Diese Funktion hängt auch mit einer speziellen Linux-Fähigkeit zusammen, TCP-Streams in „Messages“ aufzuteilen und an andere Threads zu schicken; ich weiß aber nicht, ob nachgelagerte Messages schon weitergereicht werden können, wenn ein früheres Paket verloren ging.
Ich hatte nicht den Eindruck, dass es alle Verbindungen schneller machen sollte.
Aus dieser Perspektive ergibt der Trade-off Sinn.
Ich bin kein Experte, also möge mich jemand mit mehr Ahnung korrigieren.
QUIC wurde entwickelt, weil es praktisch keine Möglichkeit gibt, die gesamte Hardware und Middleware überall im Internet dazu zu bringen, einen neuen TCP- oder TLS-Standard zu unterstützen.
Daher ist QUIC eine elegante Lösung, um einen neuen Transportstandard über UDP auf Legacy-Internet-Hardware aufzusetzen.
In einer idealen Welt hätte man neue TCP- und TLS-Standards geschaffen und alle Internet-Router und -Hardware weltweit ersetzt oder aktualisiert, um das mit geringerer CPU-Auslastung zu implementieren.
In dem Test kam das CPU-limitierte quiche auf unter 200 MB/s, während nghttp2 über 900 MB/s erreichte.
Ich frage mich, ob die CPU gedrosselt wurde.
Wenn eine HTTP/3-Implementierung viermal so viel CPU verbraucht, ist das interessant; wenn der absolute Wert aber von Anfang an sehr niedrig war, muss es nicht unbedingt ein großes Problem sein.
Der Kernpunkt ist: „Auf schnellem Internet reduziert der UDP+QUIC+HTTP/3-Stack die Datenrate gegenüber TCP+TLS+HTTP/2 um bis zu 45,2 %“; ich habe das Paper noch nicht vollständig gelesen, aber in der Einleitung scheint alles unter 600 Mbit/s als langsames Internet zu gelten.
Cloudflare etwa unterstützt QUIC nur zwischen Client und Edge, nicht für Origin-Verbindungen.
Wenn die Verbindung Edge <> Origin wiederverwendbar, stabil und „schnell“ ist, ergibt das Sinn.
https://developers.cloudflare.com/speed/optimization/protoco...
Das klingt nicht nach einem grundlegenden Problem des Protokolls selbst.
Solche Latenzprobleme erhöhen den Akkuverbrauch jedoch nicht stark, anders als CPU-Auslastungsprobleme, die die CPU zum Boosten bringen.
In der Server-zu-Server-Kommunikation ist es ebenfalls kein Problem.
Im Grunde wird eine High-Bandwidth-Übertragung auf Endnutzergeräten bei einer selbst für 2024 sehr schnellen Verbindung „langsamer“.
Mit Geschwindigkeit ist hier nicht die beworbene, gekaufte Geschwindigkeit gemeint, sondern die tatsächlich effektive Geschwindigkeit vom Gerät bis zum Server.
Das heißt nicht, dass das Paper nutzlos wäre; Browser-Implementierungen sollten verbessert werden, und das zeigt es gut.
Der Titel des Papers ist allerdings nahezu 100 % Clickbait.
In einer Zeit, in der Gigabit-Internet sich verbreitet, auf eine langsamere Übertragungsmethode umzusteigen, ist eindeutig ein Fehler.
In 30 Jahren wird es noch schneller sein; wenn man dann ein älteres Protokoll verwenden muss, um die Leitungsrate auszuschöpfen, wäre das absurd.
Derselbe Artikel wurde auch im September gepostet: QUIC is not quick enough over fast internet (acm.org)
https://news.ycombinator.com/item?id=41484991 (327 Kommentare)
Brave/Vivaldi/Opera usw. muss man bewusst wählen.
Nach dem Motto: Wenn nur die Werbung schnell ankommt, ist der Rest egal.
Das klingt wirklich ziemlich seltsam.
Ich habe mit QUIC+HTTP/3 allein, und auch nur mit QUIC, schon 900 Mbit/s erreicht.
Das wirkt wie eine schlechte TLS-Implementierung oder eine frühe, ineffiziente Implementierung.
Die CPU-Auslastung lag auf einem EPYC-Core der zweiten Generation bei etwa 5 %, also ziemlich durchschnittlich.
Eine Anekdote: Es gab Probleme beim Zugriff auf wordpress.org
Als ich WordPress zum ersten Mal nutzte, konnte ich die Dokumentation problemlos lesen, aber irgendwann konnte ich überhaupt nicht mehr auf die Website zugreifen.
Durch Dual Boot mit Linux war klar, dass es kein Windows-Problem war;
pingfunktionierte einwandfrei, und auch der Wechsel zwischen drei Browsern änderte nichts.Wenn ich die Seite aufrief, blieb sie einfach hängen und lud gar nicht, oder gelegentlich stoppte der Seitenaufbau mittendrin.
Heute habe ich die Lösung gefunden: In den Chrome-Einstellungen Experimental QUIC Protocol deaktivieren.
Über Monate hatte ich Zugriffsprobleme mit wordpress.org, und es gab keinerlei Hinweis darauf, dass QUIC die Ursache war; das ist beunruhigend.
Ich habe es nur zufällig bemerkt, weil in den Entwicklertools gelegentlich QUIC-bezogene Fehler auftauchten.
Ich frage mich, wie viele Websites es noch gibt, die wegen dieses Protokolls unzugänglich werden, ohne dass Nutzer die Ursache kennen.
Mit schnellem Internet sind hier 500 Mbit/s gemeint, weil QUIC darüber hinaus offenbar CPU-limitiert ist.
Ich habe nicht detailliert genug nachgesehen, um zu prüfen, ob das Testsystem ein normales Consumer-Gerät war oder ob das Problem auch auf High-End-Desktops weiterhin besteht.
Das Lustige ist, dass wir implizit Vorstellungen wie „QUIC ist das neue HTTP/2“ akzeptieren, obwohl wir die Details gar nicht gut kennen – nur weil schnell = gut gilt.
Das ist ähnlich, als würde man ein neues 5G-Handy kaufen, weil es angeblich um ein Vielfaches schneller ist als 4G.
Dabei gilt: 1) Mein 4G-Handy hat noch nie mit der maximalen 4G-Geschwindigkeit gearbeitet, und 2) Verbindungsprobleme liegen fast immer nicht an der Geschwindigkeit der Internetleitung, sondern an DNS-Servern, der Ziel-Website oder Multiplexing-Geräten beim Anbieter.
Trotzdem heißt es dann: „Aber es ist doch 5G.“
Auch Werbung für „Glasfaser-Broadband“, in der Menschen beim Fernsehen so inszeniert werden, als würde ihnen der Wind durchs Haar wehen, ist ziemlich komisch.
So funktioniert es in Wirklichkeit nicht.
Früher konnte man auch mit einer 8-Mbit-Verbindung streamen; 300 Mbit mögen also für manche Dinge gut sein, aber ob man den großen Unterschied wirklich spürt, ist fraglich.
Ich wünschte, QUIC hätte einen Nicht-TLS-Modus.
Bei lokaler Entwicklung möchte man manchmal einfach sehen, was über die Leitung geht, aber das sorgt für viel unnötige Reibung.
Deshalb kann es ohne diese nicht funktionieren.