QUIC und Timeout
Auf dieser Seite geht es um den Sonderfall, dass ein Webserver ihrem Client eine Verbindung per QUIC anbietet, ihr Client es nutzen möchte aber es auch anderen Gründen nicht funktioniert. Dies kann beim Start einer Verbindung aber auch inmitten des Betriebs erfolgen, wenn sich z.B. das Netzwerk ändert.
Regelfall
Wir haben von QUIC im Internet gelernt, dass es schon sehr viele Dienste gibt, die QUIC anbieten und die heutigen Browser auch QUIC unterstützen. Auf der Seite QUIC Handshake haben Sie vielleicht schon gelesen, dass Der Client auf das Angebot des Browser wartet und dann erst QUIC versuchen wird. Um dies nachzustellen haben ich eine QUIC-Verbindung gegen einen Testserver geprüft. Wobei es gar nicht so einfach ist, einen entsprechenden Test aufzubauen oder z zu finden.
Auf der Seite https://bagder.github.io/HTTP3-test/ gibt es eine Übersicht einiger QUIC-Server und Links zu Testseiten. Ich habe meine Tests mit https://www.litespeedtech.com/ gestartet. Der Server mit der IP-Adresse 52.55.120.73 stand während des Tests bei Amazon, USA
- Whois: 52.0.0.0 - 52.79.255.255
https://www.whois.com/whois/52.55.120.73
Der erste Abruf produzierte im Chromium Debugger folgende Einträge:
Die erste Verbindung braucht natürlich am längsten, das der Browser erst eine DNS-Anfrage etc. stellen muss.
Die DNS-Anfrage war schnell aber die initiale Connection hat hier sehr lange gedauert. Der Server selbst ist leider nicht anpingbar aber ein Traceroute ergab, dass der Server nicht per GeoDNS oder AnycastIP mehrere Instanzen hat, sondern über 100ms "entfernt" in den USA steht. Damit sind 219ms für den TCP SYN ACK RES-Handshake und noch mal 12ms für den TLS Handshake verständlich und sogar ein besserer Testfall als ein lokaler schneller Server.
Nach den ersten 444 Sekunden zeigt der Trace aber auch, dass viele Dateien noch über die bestehende Verbindung parallel heruntergeladen werden und die QUIC-Verbindung erst weiter unten aktiviert ist. Anscheinend nutzt Chrome 128.0.6613.138 hier erst einmal die schon bestehende Verbindung, eher er dann auch noch QUIC dazu schaltet.
Reload und Caching
Wenn ich aber danach ein "Reload" antriggere, dann lädt er auch die Startseite schon per "h3". Einige Folgeseiten von anderen Domains, zu denen noch keine QUIC-Information vorliegt, werden über eine TCP-Connection geladen.
Je häufiger ich per "RELOAD" die Seite nachgeladen habe, desto mehr Dateien wurde über QUIC übertragen.
Chromium merkt sich den QUIC-Status unabhängig vom Browsercache.
Im parallel mitgeschnittenen Chrome-Netzwerk-Trace finde ich am Anfang die UDP-Abfragen zur Namensauflösung, die den lokalen DNS-Server elegant ignorieren! und dann eine klassische HTTPS-Verbindung starten.
Die weitere Zeitstempel sind:
Start Time Aktion 2024-09-23 12:51:53.984 937472: NETWORK_SERVICE_HOST_RESOLVER 2024-09-23 12:51:57.652 937475: HTTP_STREAM_JOB_CONTROLLER https://www.litespeedtech.com/ 2024-09-23 12:51:57.653 937478: QUIC_SESSION_POOL_DIRECT_JOB 2024-09-23 12:51:57.653 937479: UDP_CLIENT_SOCKET --> address = "[2001:4860:4860::8888]:443" --> net_error = -109 (ERR_ADDRESS_UNREACHABLE) 2024-09-23 12:51:57.668 937486: URL_REQUEST https://www.litespeedtech.com/ ... weitere HTTP-requests 2024-09-23 12:51:57.890 937493: HTTP2_SESSION www.litespeedtech.com:443 ([direct://]) Antwort mit dem "Alt-Svc"-Header 2024-09-23 12:51:58.106 937502: UDP_CLIENT_SOCKET SOCKET_CONNECT --> address = "52.55.120.73:443" 2024-09-23 12:51:58.107 937504: QUIC_SESSION www.litespeedtech.com erster Request und Daten ...
Auch in diesem Trace sehen wir, dass es ca. 500ms dauert, bis QUIC aktiv wird. Der Browser trifft aber schon vorher die Vorbereitungen zur QUIC, obwohl er noch gar keinen "Alt-Svc"-Header bekommen haben kann.
Wenn der Browser aber schon vorher die Information hatte, dass die Gegenstellt QUIC nutzt, dann finde ich auch direkt schon die erste Anfrage beim "Reload" über QUIC.
Wo genau Chrome sich die gelernten QUIC-Parameter einer Webseite merkt, habe ich noch nicht weiter erforscht.
Chrome Discovery
Es ist nicht einfach, entsprechende Quellen zu finden, die das Verhalten der Browser beschreiben. Die erste Verbindung wird wohl auch noch lange Zeit eine HTTP/TCP-Verbindung sein, bis der "Alt-Svc"-Header beim Client ankommt. Aber schon diese Information kann der Client für die angegebene Zeit im Cache halten und direkt mit QUIC starten. Das haben ich am Anfang der Seite auch mit "Reloads" auf eine bestehende Seite schon gesehen.
First Connection
When Chrome makes a request to an origin it has never spoken to before, it does
not know that the origin supports QUIC and so it will send the first request
over TCP. The server’s response will indicate that it also supports QUIC via the
Alt-Svc HTTP response header. (For example, the response. ‘Alt-Svc:
h3=”:443”’ tells Chrome that the origin supports QUIC on port 443.)
Broken Connections
In the event that a QUIC handshake fails (for example if UDP is blocked, or if
the server does not speak a compatible version of QUIC) then Chrome will mark
QUIC as broken for that host. Any requests which were in-flight will be
re-issued over TCP. While QUIC is marked as broken for a host, no QUIC
connections will be attempted. After 5 minutes, the broken entry will be expired
QUIC will be marked as “recently broken” for that origin. When the next request
is issued to the origin, Chrome will race a QUIC job with a TCP job. Because
QUIC was “recently broken” the 0-RTT handshake will be disabled. If the
handshake fails again, QUIC will be marked as broken for that origin again this
time for 10 minutes, and the process repeats marking QUIC as broken for twice as
long as the previous period. If the handshake succeeds, the request will be sent
over QUIC and QUIC will no longer be marked as “recently broken”
QUIC Discovery
https://docs.google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2LFxPM/edit#heading=h.dk2fhev07ryt
Es sind hier die Feinheiten von Chrome, dass es kein "Ja/Nein"-Spiel ist, sondern QUIC versucht und bei Erfolg genutzt wird. Sollte aber keine QUIC-Verbindung zustande kommen, dann ist das keine Entscheidung für Immer, sondern wird nach 5, bzw. 10 Minuten wiederholt. Damit kann ein Browser natürlich auch flexibel auf Netzwerkänderungen reagieren, z.B. wenn es mehrere Pfade mit abweichenden Richtlinien gibt oder im Betrieb z.B. eine "Congestion Control" oder "Flow-Control" die QUIC-Funktion zeitweilig beschränkt.
Wenn Sie einen Netzwerktrace im Browser auswerten, dann sehen Sie noch viele weitere Optionen zu QUIC
Bislang habe ich aber an den Defaultwerten noch nichts geändert.
- RFC 9002 QUIC Loss Detection and
Congestion Control
https://datatracker.ietf.org/doc/rfc9002/
4.7. Probe Timeout Replaces RTO and TL
QUIC uses a probe timeout (PTO; see Section 6.2)
Firewall Block/Drop/Reject
Zuerst hat mich das Verhalten des Client interessiert, wenn er per HTTP einen "Alt-Svc"-Header bekommt, eine Verbindung startet aber die Firewall die Pakete verhindert. eine Firewall hat ja drei Optionen auf eine nicht erwünschte Verbindung zu reagieren: PASS, DROP, REJECT. Aber so einfach ist es nicht, wie ich auf folgender Seite beschreibt:
Also habe ich eine Firewall aufgebaut, die 443/UDP still gedroppt hat und mit die Webseite von Amazon angeschaut:
Ich interpretiere die Zugriffe so, dass der erste Zugriff relativ schnell über HTTP/2 over TCP erfolgte und auch die weiteren vier Dateien noch über den gleichen Stream geladen werden. Aber die danach folgenden Seiten kommen erst nach einige Zeit zum Download über HTTP/2. Die Details der einen Datei zeigen:
Leider habe ich zu dem Trace keinen Netzwerkmitschnitt laufen lassen aber dass ein Request über 4 Sekunden "pausiert" wird.
Quelle:
https://developer.chrome.com/devtools/docs/network#resource-network-timing
"Stalled" bedeutet bei Chrome, dass er gerade keine Möglichkeit hat, den Request abzusetzen. In der Zeit ohne QUIC war dies meist ein Zeichen, dass keine TCP-Connections mehr verfügbar waren. Chrome hat nämlich maximal 6 TCP-Connections parallel gestartet und wenn eine Webseite dann z.B. 20 Bilder nachladen wollte, dann mussten mit HTTP/1.1 ein paar Request eben warten, bis vorherige Requests abgeschlossen waren. Chromium zieht auch bestimmte Dateien, z.B. CSS und Fonts vor, so dass die Seite möglich formattreu aufgebaut und die Bilder dann nachgeliefert werden.
Mit QUIC ergibt sich nun die Problematik, dass Chrome weiterhin bis zu sechs Verbindungen startet bzw. mit HTTP/2 in einer TCP-Connection die Anfragen absetzt aber nebenbei auch noch die UDP-Verbindung für QUIC startet. Die kann aber erst genutzt, werden, wenn der initiale QUIC-Handshake stattgefunden hat. Hier kommt dann wieder die Frage des Timeout auf, d.h. wie lange Chromium abwartet, ehe die Anfragen weiter über TCP abgerufen werden.
- QUIC mit Proxy und Firewall
- Firewall Reaktion
- Chrome HTTP Request stuck in "Stalled"
State
https://xangelo.ca/posts/chrome_request_stalled/ - Understanding Chrome network log "Stalled"
state
https://stackoverflow.com/questions/29206067/understanding-chrome-network-log-stalled-state - How to debug frequent request stalling
issue?
https://groups.google.com/a/chromium.org/g/chromium-discuss/c/btp4Zf5SrHo - Palo Alto: Actions in Security Profiles
https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-web-interface-help/objects/objects-security-profiles/actions-in-security-profiles - How to Block QUIC Protocol
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC - What a difference a Deny makes
https://live.paloaltonetworks.com/t5/community-blogs/what-a-difference-a-deny-makes/ba-p/188811 - zscalerSecure Internet and SaaS Access
(ZIA) Managing the QUIC Protocol
https://help.zscaler.com/zia/managing-quic-protocol - QUIC - Deny or Drop
https://www.reddit.com/r/paloaltonetworks/comments/1b9drsp/quic_deny_or_drop/ - Blocking QUIC (on the network)
https://groups.google.com/a/chromium.org/g/proto-quic/c/ksokVdwXfQ0 - Debian TARPIT iptables How To
https://sysadminblog.net/2013/08/debian-iptables-tarpit/ - OPNSense: Blocking QUIC
https://forum.opnsense.org/index.php?topic=31246.0 - How to Block Google QUIC Protocol on
SonicOSX 7.0?
https://www.sonicwall.com/support/knowledge-base/how-to-block-google-quic-protocol-on-sonicosx-7-0/200727110451837
Proxy ohne DNS
Eine weitere Möglichkeit ist der Verzicht auf eine Namensauflösung von Internet-Adressen über DNS, so dass Clients zwingend über einen Proxy-Server gehen müssen. Wenn so ein Client dann nach "www.amazon.com" sucht, bekommt er einfach ein
Damit kann der Browser keine IP-Adresse finden und gar nicht erst QUIC starten.
Eine Messung dieser Konfiguration steht noch auf. Ich sehe diese Option aber als eher selten an. Siehe auch QUIC abschalten
QUIC auf Client verboten
Wenn Sie die absolute Kontrolle über ihre Clients haben, dann können Sie pro Produkt prüfen, ob eine Steuerung der Verbindung über Richtlinien oder Konfiguration möglich ist. Für die gängigen Browser Edge, Chrome, Firefox, Opera, Brave etc. ist die recht einfach möglich.
Auch für SMB können Sie die QUIC-Funktion sehr einfach abschalten.
Set-SmbClientConfiguration -EnableSMBQUIC $false
Ein Test zum Verhalten einer SMB-Verbindung bei geblockter UDP-Kommunikation steht noch aus.
Es hängt aber vom Programm ab, denn QUIC ist kein Bestandteil des Betriebssystems selbst, sondern wird von jeder Software selbst oder über eine Library implementiert.
- Set-SmbClientConfiguration
https://learn.microsoft.com/en-us/powershell/module/smbshare/set-smbclientconfiguration?view=windowsserver2022-ps - Configure SMB over QUIC client access control in Windows Server 2022 Azure
Edition and Windows Server 2025 (preview)
https://learn.microsoft.com/en-us/windows-server/storage/file-server/configure-smb-over-quic-client-access-control
Weitere Links
- QUIC im Internet
- QUIC Handshake
- QUIC und SMB
- QUIC mit Proxy und Firewall
- Nutzung von QUIC steuern
- QUIC Server und Clients
- TCP SYN ACK RES
- TLS Handshake mit NetMon
- Anycast-Routing
- Firewall Reaktion
- https://bagder.github.io/HTTP3-test/
- https://www.litespeedtech.com/
- Applicability of the QUIC Transport Protocol
https://quicwg.org/ops-drafts/draft-ietf-quic-applicability.html - QUIC Discovery
https://docs.google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2LFxPM/edit#heading=h.dk2fhev07ryt - How to Block QUIC Protocol
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC - What a difference a Deny makes
https://live.paloaltonetworks.com/t5/community-blogs/what-a-difference-a-deny-makes/ba-p/188811 - QUIC - Deny or Drop
https://www.reddit.com/r/paloaltonetworks/comments/1b9drsp/quic_deny_or_drop/ - Question: Fallback to TCP when QUIC is suddenly blocked
https://github.com/google/ExoPlayer/issues/5160 - TCP fallback after UDP flooding prevention
https://groups.google.com/a/chromium.org/g/proto-quic/c/pw-3btBWPYs - Was ist ein DDoS-Angriff per QUIC-Flood? | QUIC- und UDP-Floods
https://www.cloudflare.com/de-de/learning/ddos/what-is-a-quic-flood/ - Google-Suche extrem langsam
https://www.reddit.com/r/Zscaler/comments/1cj6vke/google_search_extremely_slow/?tl=de