Long intermittent connection stalls when using an HTTP2 proxy
Reported by
k...@luminance.org,
Aug 16 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Steps to reproduce the problem: 1. Use rich web applications over a HTTP2 proxy with developer tools' network panel open What is the expected behavior? No unexplained stalls in requests What went wrong? When I play browser games or access other web applications directly via Chrome I get pretty consistent timings because I have a good connection. If I access the same games/applications through an HTTP2 proxy (with the proxy located near to the applications' servers) the latency is dramatically lower, because the HTTP2 proxy is doing the HTTP handshakes and what have you. Unfortunately, requests through the HTTP2 proxy randomly stall for multiple seconds at a time, and this seems to be occurring in Chrome's network stack, not on the proxy. Did this work before? N/A Chrome version: 60.0.3112.90 (Official Build) (64-bit) (cohort: Stable) Revision 6ee4392c6cef820c64ff50b5fd5eeb8596cd0394-refs/branch-heads/3112@{#702} Channel: stable OS Version: 10.0 Flash Version: I'm pretty certain this isn't an issue with the proxy, since it's a very simple stock installation of squid (for proxying http requests) and nghttpx (for http2). Everything works great except for when a request stalls. It's hard to find relevant info, but in chrome://tracing the stalled requests look like weird stuff happened. I managed to capture one and I'll paste it in a comment below. This seems like it might be a variation on issue 473259, but I'm not sure.
,
Aug 17 2017
,
Aug 17 2017
Looks like we're stalled waiting to receive the body from the server. Seems unlikely to be a general proxy issue, so if it's a Chrome issue, most likely either H2 or H2 proxy related, though seems to me it could well be a proxy issue (Since the proxy is what's doing all the work there). I'll defer to the owner of the H2 code.
,
Aug 17 2017
Oh, and we'll probably need the full log, to see what's happening at the H2 session and possibly socket layers (We don't need all bytes, just need to see all reads and H2 events).
,
Aug 17 2017
CCing bnc@ as he may be interested in looking at the H2 log, and Needs-Feedback for the full log.
,
Aug 17 2017
How do I retain and save the full log? I couldn't find a way to do it when I dug around.
,
Aug 17 2017
Thank you for providing more feedback. Adding requester "pauljensen@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 17 2017
,
Aug 18 2017
Here's a network log that I believe contains a stall, along with a screenshot of the request that should have stalled. I didn't have the network internals tab open this time so I wasn't able to check the text there to see if it was similar. The timing from the log should show that almost all requests through the proxy complete quickly, except for the stall, which takes over 3 seconds.
,
Aug 18 2017
Thank you for providing more feedback. Adding requester "pauljensen@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 23 2017
Adding TE-NeedsTriageHelp , as the issue is out of TE scope. Thanks!
,
Apr 16 2018
This is still an issue and I think a recent update to Chrome may have made it worse. I previously was mitigating this with an extension that sends periodic pings to a web server (via the proxy) to 'wake up' stalled requests but that no longer seems to reliably work around the issue. I haven't changed my proxy configuration at all so it seems like something would have had to change in Chrome.
,
May 13 2018
This also occurs using Caddy in http2 forward proxy configuration. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by k...@luminance.org
, Aug 16 2017