Hi List,
In the process of figuring out bandwidth limits (previous thread), we stumbled
on a much more interesting problem. Under some conditions (especially high
request rate), H3 connections simply stall. This appears to be more prevalent
in some browsers than others (Safari on iOS is the worst offender), and appears
to coincide with high packet_loss in `show quic`. I'm not sure if that's cause
or effect. I've tried tuning use of Retry threshold (raised to 1000) and
max-frame-loss (raised to 100), to no change.
On the client side, this manifests itself by requests spinning indefinitely
until HAProxy expires the connection or the client goes away. A refresh usually
fixes it, but not always. There is no HAProxy crash and it still sees the
connection in `show quic`, but no packets flow (and counters in show quic,
other than packet loss are zero). Some browsers smooth this over by
establishing a new connection or switching to H2 (but not always). This occurs
in IPv4 and IPv6, across networks and devices—even on separate continents. 😁
All backend connections are H/1.1.
All logs end up with CD-- or CL-- states and durations that are roughly the
same as the QUIC connection timeout (~30s).
What output would be helpful to debug this? I can send over a JSFiddle that
makes it fairly easy to replicate the behavior in iOS.
Relevant config:
global
tune.quic.socket-owner connection
frontend
bind quic4@0.0.0.0:443,quic6@[::]:443 ssl crt <cert> allow-0rtt
http-response set-header alt-svc "h3=\":443\";ma=86400"
I'm a bit at a loss as to what to try next, so we've disabled H3 for most
traffic.
Thanks!
Best,
Luke
—
Luke Seelenbinder
Stadia Maps | Founder & CEO
stadiamaps.com
