httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: No H2 Window updates!
Date Mon, 30 Nov 2015 12:24:07 GMT
I'm assuming that the brokenness also shows up on trunk,

Bert, Jan, can you check if trunk shows the same behavior?
I would prefer not hacking away on 2.4 directly and independently.


> On Nov 29, 2015, at 3:03 AM, Stefan Eissing <> wrote:
> Ok, thanks. I think I have an idea of what's happening:
> - on short request bodies, window updates get omitted and gives a shrinking connection
> - the window size of the connection itself should be at max Value right from the start
> I won't be able to do anything about it until later this week, though. 
> //stefan
> Am 28.11.2015 um 22:29 schrieb Bert Huijben <>:
>>> -----Original Message-----
>>> From: Bert Huijben []
>>> Sent: zaterdag 28 november 2015 14:32
>>> To:;
>>> Subject: RE: No H2 Window updates!
>>> In case of Subversion's real usage, I want to commit potentially hundreds
>> of
>>> MByte, so a connection level window of more than a few bytes would be
>>> very
>>> welcome.... With HTTP/1 we send out the data as fast as we can and the TCP
>>> windowing handles this from the httpd side... Now the http/2 level
>>> windowing
>>> should handle this.
>>> Mod_dav and mod_dav_svn are usually fast readers; just limited by trivial
>>> disk io or xml processing in the common operations, so I don't expect real
>>> problems there.
>> For my commits against the repository my latency/ping
>> time is +- 142 ms.
>> With the current simple algorithm and a maximum window of 64
>> Kbyte/connection, I can send a theoretical maximum of 64 Kbyte/142 ms per
>> connection to that server... which would be about 450 Kbyte/s.
>> (=1/0.142*65536/1024)
>> That is < 1/30th of the bandwidth I have at my disposal (+- 150 Mbit).
>> But currently I don't even get anywhere near that as my window continues to
>> shrink because some data is missed in accounting even after my simple patch.
>> For httpd we have to think carefully which algorithm we want to implement
>> here. Preferably the algorithm should be better than TCP could, as we know
>> the specifics of the http algorithm better than plain TCP could for
>> HTTP/1,1. TCP does send a lot of window updates though... Almost every
>> packet does.
>> Solving the really hard problems, like this one, is the reason I didn't
>> think the nghttp2 library would really be the solution for serf. 
>> It is nice for such a library to provide a head start on the protocol level,
>> but there is no way a standard library can really solve this scheduling
>> problem in a generic way. (If it could do it, we had used that solution for
>> TCP... and never had to resort to designing a HTTP/2 in the first place).
>> See for some
>> introduction on how TCP was extended to work above the limit that currently
>> applies to H2.
>> Dynamic window sizing/scaling will have to be implemented at some point, at
>> both the stream and the connection level... This will involve timing,
>> measuring, etc. etc. Things nghttp2 can't do for us right now.
>> And if I'm right this might take continuous optimizing for years to come.
>> When I connect to sites like google I immediately receive a large connection
>> level window, to allow me to post huge blobs without a delay. (Haven't
>> tested their stream level windows behavior yet)
>> In serf I do something similar... and then apply a bit of throttling at the
>> stream level.
>> I would guess some clients have already implemented some of this, so we
>> might be able to learn from their implementations... Clients will see much
>> more incoming data than servers of course :).
>>   Bert 

View raw message