Hi List, Am 27.08.20 um 11:45 schrieb Tim Düsterhus, WoltLab GmbH: >> You can see two h2c connections, one is on the frontend (hence the 'F') >> and the other one is on the backend. The h2s is the H2 stream, unique to >> a request (though it comes from a pool, so it will be reused for new >> streams on any connection once this one is finished). Thus bu just >> filtering on the h2 and correlating with what you see in the logs (with >> your source ports), and the date of course, you can quite reliably match >> connections, hence requests. > > Okay, that works sufficiently well for me. I've extracted the relevant > parts, redacted any private information and will check with a coworker > to see if I missed anything. I'll send you the traces + logs in private > after the contents have been ACKed :-) >
Willy and I discussed this in private. My understanding is that this issue is caused by an inherent limitation of H2 with regard to head of the line blocking. In simple terms: If the stuff at the beginning of the the backend connection belongs to a client that is very slowly or not reading the stuff within its client connection then everything that's within that backend connection will stall until the slow client finally gets around to reading the stuff thats intended for it. Basically a very slow client can block *other* clients that are unfortunate and share the backend connection. Our resolution is simple: We disable H2 for the backend connections and use good old H1. We don't *need* end to end H2. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 [email protected] www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P
