> -----Original Message----- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: zaterdag 28 november 2015 14:32 > To: stefan.eiss...@greenbytes.de; dev@httpd.apache.org > 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 svn-master.apache.org 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 https://en.wikipedia.org/wiki/TCP_window_scale_option 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
