Hi Ilya, On Sat, Feb 08, 2014 at 04:12:03PM -0800, Ilya Grigorik wrote: > Ok, I have the following setup: client -> haproxy (npn + tcp proxy) -> > spdylay (spdy 3.1 without TLS). > > http://www.webpagetest.org/result/140208_DM_57a2a0feaf3258b93d7e3ce3c802b278/4/details/- > 100ms RTT / 3Mbps down. > - tcpdump: > http://cloudshark.org/captures/666f2481eafa?filter=tcp.stream%3D%3D1 > - Page loads two images > onload event > 1s later loads one image > 0.4s > later loads another image > 3.6s later loads last image. > > All resources are loaded over the same SPDY connection (TLS terminated by > HAProxy, and SPDY-sans-tls by spdylay :)), and all assets are static > assets. As expected, session starts with 1400 byte records, then gets > bumped to ~16K records and continues using 16K records until the end of the > entire session -- since all resources here are static resources, there are > no gaps between HEADERS and DATA frames and we never hit the case of two > incomplete reads... This is somewhat suboptimal, since ideally we'd reset > record size when delivering the first image after 1s idle pause following > onload, and also when delivering the last image following the 3s+ idle > pause. > > Now, let's imagine that HAProxy "understood" SPDY and had knowledge of the > individual streams (instead of running in tcp mode): it seems like we > *wouldn't* want the logic of new stream > reset record size to apply for > SPDY connections. Reset on new request makes sense in HTTP/1.1 mode since > everything is serialized and we're using multiple connections (although > even here this strategy can be suboptimal if we have back-to-back requests > on same connection and low RTT), but when we have many multiplexed streams > with SPDY, this behavior would lead to a lot of unnecessary resets - e.g. > multiple streams in flight, record size is at 16K, and new stream is > initiated and resets record size for everyone. > > I'm back to wondering if the incomplete read strategy is the best approach > to take here. It seems like it wouldn't work out that well for SPDY / > HTTP/2 even if HAProxy understood those protocols... unless there was a lot > more smarts added for tracking parallel in-flight streams, etc. Instead, > seems like a connection idle timeout strategy would be much simpler and > would work uniformly well across HTTP/1, HTTP/2 (and any other protocol for > that matter) even without understanding any of them? > > What do you guys think? Am I overlooking anything?
The observations and analysis are interesting, and the choice of solutions is not easy. I think that relying on a pause only is dangerous because there are generally a number of losses when delivering to clients, causing pauses during the transfers, and we wouldn't want to reset the window in this case, TCP congestion control already handles this. So maybe the difference between a congested link+retries and a ping-pong transfer is the state of the buffer during pauses : if we have to stop because of losses, the buffer is full and we should not reset the window. If the buffer is empty, it means we're facing a pause caused by the client. I'm trying to do something like this and will post the patch if I manage to do something clean enough. Thanks! Willy
