QUIC-Technologie ist selbst im schnellen Internet nicht schnell genug

 (arxiv.org)
2 Punkte von GN⁺ 2024-10-20 | 1 Kommentare | Auf WhatsApp teilen

QUIC ist in schnellem Internet nicht schnell genug

  • Forschungshintergrund

    • Von QUIC wird erwartet, dass es eine wichtige Rolle bei der Verbesserung der Leistung von Webanwendungen spielt.
    • Diese Arbeit untersucht die Leistung von QUIC in Hochgeschwindigkeitsnetzwerken systematisch.

  • Zentrale Erkenntnisse

    • In schnellem Internet erreicht der Stack UDP+QUIC+HTTP/3 im Vergleich zu TCP+TLS+HTTP/2 eine um bis zu 45,2 % geringere Datenübertragungsrate.
    • Mit steigender verfügbarer Bandbreite wird der Leistungsunterschied zwischen QUIC und HTTP/2 größer.
    • Das Problem betrifft nicht nur Dateiübertragungen, sondern auch verschiedene Anwendungen wie Video-Streaming (bis zu 9,8 % geringere Video-Bitrate) und Web-Browsing.

  • Analysemethode

    • Durch Paketverfolgungsanalyse sowie Profiling im Kernel- und User-Space wurden die grundlegenden Ursachen des Problems identifiziert.
    • Die Verarbeitungs-Overheads auf der Empfängerseite sind hoch; insbesondere übermäßige Datenpakete und die User-Space-ACKs von QUIC sind die Ursache.

  • Empfohlene Verbesserungen

    • Es werden konkrete Empfehlungen vorgestellt, um die beobachteten Leistungsprobleme abzumildern.

Zusammenfassung von GN⁺

  • Diese Arbeit analysiert die Leistungsprobleme von QUIC in Hochgeschwindigkeitsnetzwerken und liefert wichtige Einblicke, die zur Verbesserung der Leistung von Webanwendungen beitragen können.
  • Sie zeigt, dass die Leistungseinbußen von QUIC auf Verarbeitungs-Overheads auf der Empfängerseite zurückzuführen sind, und präsentiert konkrete Maßnahmen zu deren Behebung, was nützliche Informationen für Netzwerkingenieure und Entwickler bietet.
  • Ein anderes Protokoll mit ähnlicher Funktionalität ist HTTP/2; der Leistungsvergleich damit zeigt mögliche Verbesserungsrichtungen für QUIC auf.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-20
Hacker-News-Kommentare

  • Die Branche versucht alles, außer leichtgewichtige Websites zu bauen. Ende der 90er hatte man bei einer schnellen Internetverbindung kleine Seiten und fast kein JavaScript. Auch heute findet man noch solche schnell ladenden, leichtgewichtigen Seiten, und die Erfahrung ist fast surreal. Wenn die User Experience besser gewesen wäre, hätte man es eher ertragen können.

  • Ich habe bei Google an einem reinen JS-Speedtest gearbeitet. Damals war Ookla Flash-basiert und funktionierte daher nicht auf Chromebooks. Ich habe viel darüber gelernt, wie TCP auf verschiedene Faktoren reagiert. Beim Lesen dieses Artikels wirken die Ergebnisse auf mich erwartbar. Denn die Flusskontrolle wird vom Kernel in den User Space verlagert. TCP hat Flusskontrolle und Sequenzierung. QUIC lässt das alles selbst verwalten. Die TCP-Staukontrolle passt nicht zu modernen Verbindungsgeschwindigkeiten, deshalb braucht es neue Algorithmen wie BBR, aber die haben ihren Preis. Die wichtigste Erkenntnis ist, dass man bei Netzwerktests die Bedeutung der Latenz nicht unterschätzen darf. Wer in Asien oder Australien lebt, weiß, wie verheerend 100 ms RTT-Latenz sein können. Der Overhead von QUIC ist möglicherweise in der Praxis nicht entscheidend. Denn die tatsächliche Bandbreite über eine einzelne TCP-Verbindung oder einen QUIC-Stream kann deutlich unter der Rohbandbreite liegen.

  • Daniel Stenberg, Gründer und Maintainer von curl, hat über HTTP/3 gebloggt. Er hob die hohe CPU-Auslastung von HTTP/3 hervor und erwähnte, dass die CPU den Durchsatz begrenzen kann. Ich frage mich, ob das an der Unreife der Implementierung liegt oder an der Art, wie QUIC konzipiert ist.

  • Auf schnellem Internet soll der UDP+QUIC+HTTP/3-Stack die Datenübertragungsgeschwindigkeit gegenüber TCP+TLS+HTTP/2 um bis zu 45,2 % verringern. Ich habe die Arbeit noch nicht ganz gelesen, aber offenbar gelten unter 600 Mbit/s bereits als „langsames Internet“.

  • QUIC soll auf schnellem Internet nicht schnell genug sein. Ich habe mit QUIC+HTTP/3 900 Mbps erreicht und frage mich, ob die TLS-Implementierung schlecht ist oder frühe Implementierungen ineffizient sind. Die CPU-Auslastung lag im Schnitt bei etwa 5 % auf einem Gen-2-Epyc-Kern.

  • Mit „schnellem Internet“ sind hier 500 Mbps gemeint, und es heißt, dass QUIC CPU-abhängig ist. Ich habe nicht geprüft, ob das Testsystem ein typisches Consumer-System war oder ob das Problem auch auf einem High-End-Desktop auftritt.

  • Ich dachte, QUIC sei auf Latenz optimiert. Es ist darauf ausgelegt, auf Webseiten und in Videospielen viele kleine Pakete zu laden. Wenn man nur den Gesamtdurchsatz misst, könnte es schlechter abschneiden. Ich frage mich, ob man auf Protokollebene große Dateiübertragungen oder Video-Streaming mit hoher Bandbreite erkennen und auf etwas weniger CPU-intensives umschalten könnte. Ich frage mich auch, ob QUIC auf Hardware-/OS-Ebene einfach weniger optimiert ist als TCP.

  • Ich wünschte, QUIC hätte einen Modus ohne TLS. Bei lokaler Entwicklung möchte ich manchmal sehen, was übertragen wird, und das sorgt für unnötige Reibung.