Hi, On Mon, Dec 10, 2018 at 09:07:05PM -0500, klzgrad wrote: > Hi, > > HTTP/2 does flow control at connection level (and stream level). > HAProxy's server receive window at connection level is only 65535, > severely limiting upload ability. Per bandwidth-delay product, 65535 > means at 100ms latency upload can't be faster than 655KB/s. > > 65535 is the default initial connection window size in the RFC. The > size can be raised by the server sending a WINDOW_UPDATE. But HAProxy > doesn't do that or throttle connection-level traffic at all, thus > RFC-conforming clients have to keep to the 65535 value. Also, the > setting tune.h2.initial-window-size only applies to stream windows.
Hmmm I thought it applied to the connection as well. Now I've rechecked the RFC and indeed the initial window size is only for streams. Ah crap! I messed up on this one, sorry about that! And it will be even more visible with 1.9 and backend H2. Thus I guess the only way to increase the connection's window size is to emit an initial WINDOW_UPDATE right after the SETTINGS frame. I'll check this. > See the following comparison of initial connection window sizes of > various servers: > > Nginx: NGX_HTTP_V2_MAX_WINDOW (2^31-1) > H2O: H2O_HTTP2_SETTINGS_HOST_CONNECTION_WINDOW_SIZE (16777216) > Apache Traffic Server: Http2::initial_window_size (1048576) We'll have to make it huge, because with people using haproxy to origin servers, we can expect to have LFNs. Typically a CDN 50ms away from the origin on a 40Gbps pipe will have 250 MB in flight. I don't see any benefit in making it smaller than the maximum since it's per connection. Thanks for reporting this, I really appreciate it! Willy
