Re: persistent TCP-connections between squids

heiri@switch.ch writes:

>Hallo Duane,
>
>It's well known that HTTP/1.0 isn't efficient for low bandwidth/high latency
>links (as most transatlantic links are).
>It's suffering from 'TCP slow start' and from high RTT when opening a
>new TCP connections.
> http://www.w3.org/Protocols/MUX/WD-mux-961023.html
> http://www.w3.org/Protocols/HTTP/Performance/
>
>
>Question:
>-----------
>I know HTTP/1.1 will improve this situation. When do you expect HTTP/1.1
>to be implemented in squid? (I know it has the priority 2 in your
>to-do list - it seems to be a lot of work).
>
>
>Proposal:
>---------
>What about implementing (a configurable number of) multiple
>persistent TCP connections between two neighbor proxies?
>
>Having persistent connections will save the time for opening
>TCP connections many times and will speedup the transfer because
>there is only once a 'slow start' period when opening a new connection.
>
>The implementation of such a feature is possibly much easier than the
>implementation of HTTP/1.1 ?
>Once persistent TCP connections are implemented the efficiency of ICP
>could be improved as well in using them.
>
>
>Our motivation for persistent TCP connections:
>-----------------------------------------------
>We would like to use such a feature mainly to improve the efficiency of our
>transatlantic link in placing a proxy at each end of the line.
>There are about 160.000 TCP request for .com per day and about 12.000
>requests in a peak hour.
>May be we could improve the connection to our child-proxies and to
>our siblings in other European countries too in using persistent
>connections.
>
>
>What is your opinion about this idea?

Hello Ernst and others!

A few days ago I finished the initial implementation of server-side
persistent connections for Squid-1.2. It now has both client-side and
server-side persisitent connections. However, it has not been
tested all that much and I'm sure there are some kinks to work out.

For now, Squid's persistent connections are implemented like this:
There is an upper limit on the number of "idle" connections per
host. An idle connection will be closed after some configurable
timeout. Squid does not pipeline requests; rather than wait for
one request to complete, Squid will open another connection to that
host. I'm sure that will change (to become more complex) as the
implementation evolves.

About having a fixed number of persistent TCP connections between
neighbors (for HTTP/1.0 I presume?): This is complicated somewhat by
some mis-features of HTTP. For example, for requests that do not have
a content-length header, the client-side only knows the object is
completely transferred when the connection is closed. Would you
propose using some other kind of encapsulation protocol around HTTP?

Also, note that Squid-1.2 will include some HTTP/1.1 features, but
certainly not all. As time goes on we will continue to add more
and more HTTP/1.1 things, but with the slow way that we operate,
it would take us a very long time to implement everything.

Duane W.
Received on Tue Jul 29 2003 - 13:15:42 MDT