On Fri, 13 Oct 2023, 12:13 Poul-Henning Kamp, <phk@phk.freebsd.dk> wrote: > -------- > Kazuho Oku writes: > > > If we take this approach, there will be a guarantee that the client will > > open no more than 100 streams initially, > > Does any published data exist on how "100" relates to how many streams > real-life legit clients /actually/ open on a new H2 connection ? > As outlined in the Cloudflare blog post[1], in response to the DoS traffic dropping the concurrency was something thst was trialled as a remediation. We quickly received reports about websites hit by this change. The best example I saw was something like example.com index.html loading an image gallery of well over 100 images. These were loaded via <img> and pointed to other.com. Chrome would parse the HTML, discover all the things to fetch, open a new connection, and then send 100 requests immediately before the server SETTINGS arrived. So while the RFC says the limit is undefined until server SETTINGS arrives, my survey of clients shows that most don't wait and simply restrict themselves to 100 streams. A server that attempts any value lower either has to soak up the burst (I.e. soak up the raciness of H2) or reset the streams and then hope the client can retry them. I have no doubts that certain page constructions could lead to greater peak concurrency if it were so permitted without the magic client clamp. Cheers Lucas [1] - https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
Received on Friday, 13 October 2023 11:30:25 UTC