HTTP/3 and QUIC: What Network Engineers Must Handle

HTTP/3 has quietly moved a large share of web traffic off TCP port 443 and onto QUIC over UDP. For the network team that means flow records no longer line up with what the firewall sees, TLS inspection stops working on that traffic, and a single aggressive UDP policy can silently downgrade user experience without any alert firing. This article covers the operational consequences rather than the protocol design, and the checks to run before you decide whether to allow, shape or block QUIC.

What actually changes on the wire

QUIC runs over UDP, typically port 443, with encryption applied to the transport itself rather than only to the payload. Connection setup and loss recovery are implemented in userspace, and connection identifiers let a session survive an IP address change. Browsers reach for QUIC first and fall back to TCP when UDP 443 is blocked or filtered, which is precisely why a silent block degrades performance without producing a visible error.

Consequences for the four functions network teams own

• Firewalls — many devices track TCP state well and UDP poorly. Where QUIC specific tracking is unavailable, admins either write explicit UDP 443 rules or block QUIC outright so that traffic falls back to TCP and stays visible.
• TLS inspection — certificate-based inspection operates on TCP TLS sessions. QUIC flows bypass that path entirely unless the platform has dedicated QUIC support, so a policy that inspects TCP 443 does not automatically cover it.
• Flow telemetry — NetFlow and IPFIX exporters see UDP, not HTTP. Long-lived QUIC connections with migrated connection IDs can also confuse per-flow accounting, as discussed in NetFlow, IPFIX and sFlow telemetry compared.
• Load balancers — UDP needs different persistence and health-check logic, and a QUIC-capable backend behind a TCP-only VIP will appear broken to modern clients.

Policy choices and their trade-offs

# Force fallback to TCP so inspection and logging work
# (vendor syntax varies; the intent is a deny rule for UDP 443)
block udp dport 443
block udp sport 443

# Or allow QUIC and accept reduced visibility
allow udp dport 443
allow udp sport 443

Blocking QUIC restores visibility and TLS inspection coverage at the cost of the latency improvements that motivated QUIC in the first place. Allowing it keeps user performance and gives up flow-level application knowledge. The decision should be deliberate and documented, because leaving it to whatever the default UDP policy happens to be produces the worst of both: unpredictable performance and no visibility.

Testing before you commit

# Is QUIC actually in use from a client?
curl -s -I --http3 https://example.com/ | head -1
curl -s --http3-only https://example.com/ -o /dev/null -w '%{http_version}\n'

# Is UDP 443 open through this path?
nmap -sU -p 443 --reason host.example.com
tcpdump -ni eth0 'udp port 443' -c 20

--http3-only forces the path even if a TCP fallback is available, which is the only reliable way to prove the return path works. A successful TCP TLS handshake tells you nothing about QUIC reachability.

Capacity and queueing are the underrated part

UDP has no congestion control of its own, and QUIC implements its own in userspace. On an access edge with a small policer, a QUIC flow can look more bursty than the equivalent TCP flow, and a policer tuned for TCP will drop more of it than expected. Where you police UDP, measure first: tc -s qdisc show dev eth0 and interface drop counters from Linux tc HTB traffic shaping show whether you are actually losing packets or just assuming it. Where you shape, remember that shaping UDP is a blunt instrument because you cannot see inside the flow.

The pragmatic deployment posture most organisations land on: allow QUIC where the destination is trusted and the platform can log it, block it where inspection is a compliance requirement, and never leave the decision implicit.

原文链接：https://codilime.com/blog/http3-protocol/