Re: H2 HEADERS and flow control

On 2014–07–04, at 1:54 PM, Greg Wilkins <gregw@intalio.com> wrote:

> Whilst what I'm advocating could be somewhat implemented by self control/priorty I don't think it can entirely be done so, and certainly not just by the server.
> 
> Currently a browser that has just sent a 64KB header is free to immediately send another 64KB of data without any say so from the server.  This will effectively give that client twice the share of any shared connections from load balancer to app server vs a browser that sends small headers.

Too many requests is exactly what ENHANCE_YOUR_CALM is for. It’s not supposed to happen under normal conditions, i.e. it’s an indication of trouble.

> If the header size was included in the flow control calculations, then the browser would have to wait for a WINDOW_UPDATE after sending a 64KB header before it could send any data.   It would thus be only able to take the same share of any amalgamated connection as a small header sender.

TCP window updates do the job you’re asking for. The load balancer should simply delay reading the delinquent socket at the time it sends or forwards ENHANCE_YOUR_CALM.

To be sure, this sucks for other users sharing the same client-side proxy (assuming it aggregates connections). But that raises doubt of whether equal sharing of server resources is a useful goal in the first place.

Received on Friday, 4 July 2014 07:19:02 UTC