[squid-users] server persistent connections and cache

[Alex Rousskov]

On 07/30/2018 06:37 PM, Vishali Somaskanthan wrote:

> 2. Can you provide an example where NOT PINNING and not having the
> shared fate breaks *fewer transactions*?? 

I do not know of any specific services like that, but it is easy to
imagine one. For example, consider a server that sends the client the
number of requests that sever has seen on the current TCP connection. A
client expecting to receive "1" in its first response may break after
receiving "10" instead. And it gets worse when Squid-to-server
connections are picked at random for every request.

Like Amos said, HTTP allows the proxy to do juggle to-server connections
like that, so no reasonable plain text client that goes through a proxy
would expect a pinned server connection, but in our "secure" context, a
reasonable client can expect that it is talking directly to the service
at HTTP level.


> 3. Is Pinning maintained at SSL level?? When the connection is pooled,
> do you save SSL session states ??

Yes and yes: The kind of pinning we are talking about is maintained at
"destination connection" level (see #3 in my earlier response), which
includes both TCP and SSL connection info.


> 4. We are looking forward to do an optimization where the same
> TCP connection from squid to server is re-used for multiple requests
> from client. Will that be a valid process with squid?? 

As the first step, I would post a specific RFC (to the squid-dev mailing
list) to see if there is consensus that what you want is officially
acceptable in principle. Please mention the motivation and include
risk/benefit analysis along with Squid configuration changes (if any).
Then comes implementation and official review.

For more details, please see https://wiki.squid-cache.org/MergeProcedure

N.B. The same TCP connection from squid to server is _already_ reused
for multiple requests from client so what you probably want to optimize
is something different (e.g., the same Squid-to-server TLS connection is
reused for multiple consecutive TLS clients).


HTH,

Alex.