steady peer connection pool

Hello,

    I am dealing with a Squid hierarchy where network connectivity
between a child Squid and several parent Squids is insecure and comes
with long round-trip times. To combat insecurity, the child Squid
encrypts connections to its peers, which makes connection establishment
even slower because it adds SSL handshake to the TCP handshake.

All proxies involved are using HTTP persistent connections to the extent
possible, but when a child Squid does not talk to a parent for a while,
pconns timeout (not to mention non-idempotent requests, network errors,
and other connection closure reasons). Due to erratic user behavior,
complex peer routing, network errors, and stringent performance demands,
it is not possible to just configure a long-enough timeout to always
keep a few connections open and ready for use.

The unlucky child Squid user whose requests are going to hit that
unused-for-a-while parent suffers from significant initial delays as the
child Squid has to establish several new connections to its peer,
performing TCP and SSL handshakes (accumulating many round-trip times).
After a few long seconds, the connections are established, the first
"page" finally loads.

Unfortunately, these users need nearly-instant responses, and it is
especially difficult to pacify them because they see decent performance
on established connections (so they know that available connectivity can
support their needs well).

It might be possible to utilize some kind of TCP level proxy that would
maintain a pool of TCP connections between the two proxies, but that
solution would significantly increase administrative overheads and will
not integrate well with the existing idle pconn pool already maintained
by Squid (not to mention existing Squid peer configuration and
management code).

The best solution I can come up with is to modify Squid so that it
proactively maintains a pool of N idle connections between two peers. If
an idle connection is removed from the pool (for any reason), the child
Squid opens a new one, even if there is no request that can use that
newly opened connection immediately.

The size of this "steady" pool would be configurable, of course. Squid
may also need to pace connection opening rate to avoid creating an
impression of a DoS attack, especially when priming large steady pools.
There are some other minor aspects of this algorithm that may need to be
configurable.

I think this "steady" connection pool feature would be useful in other
performance-sensitive environments with a fixed number of peers where
regular connection establishment is just too slow for the given user
delay tolerance.

Is there a better way to solve this problem? If not, any objections to
adding such a feature to Squid?

Thank you,

Alex.
Received on Fri Sep 20 2013 - 21:25:04 MDT