There's an article pointed to by slashdot @
http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html
where the author found that instead of a slow start of sending a packet
or two and waiting for an ACK, some sites like Google and Microsoft,
optimize for their initial web page display by NOT "slow starting" and
sending 4 or more packets w/o waiting for the initial ACK. This gives
them a LARGE boost for that initial page -- and would for any initial
start of a TCP connection.
Since many connections to squid are small TCP session, it seems
eliminating the 'slow start' might provide a significant boost when
loading pages with browsers that use many small TCP connections.
Is this something the squid designers have given any consideration to
for inclusion as an option -- is it something that could be done when
setting up a connection to a remote server? I.e. when 'fetching', is it
possible to set the initial window 'larger' -- since most of the benefit
comes from using a larger window where the RTT is 'large' (~>30ms).
If the RTT times between the squid cache and the client are very low
already, then the benefit wouldn't be as noticeable.
Some research papers from presentations on the benefit of increasing the
initial startup window:
Abstract:
http://www.google.com/research/pubs/pub36640.html
Full Paper:
http://www.isi.edu/lsam/publications/phttp_tcp_interactions/node2.html
Some simulations from 1998 on the value of increasing the initial TCP
window size:
http://www.rfc-archive.org/getrfc.php?rfc=2414
Apparently, a patch may be necessary to give applications control over
this, this patch was shown here:
http://www.amailbox.org/mailarchive/linux-netdev/2010/5/26/6278007
-----
Also another method of speeding up web page delivery has to do with
HTTP pipelining -- however, some paper (forget the link, had too many
open and then the window crashed...ARG)...said this wasn't widely used
due to problems with proxy support.
Doesn't (or does?) squid support this?
Just some general questions...
Thanks!
Linda
