[squid-users] server persistent connections and cache

[Vishali Somaskanthan]

Hi,

Resuming the above conversation; When looking at the cache log and the
code, I find that when peek is done at step 1 and then bumped, the
connection gets pinned after *httpsPeeked() *is called.

Log:

*2018/07/23 11:40:29.572 kid1| 17,4| AsyncCallQueue.cc(55) fireNext:
entering ConnStateData::ConnStateData::httpsPeeked(local=4.16.205.42:33596
<http://4.16.205.42:33596> remote=96.43.144.26:443
<http://96.43.144.26:443>        FD 15 flags=1, request=0x559f3b1a6ed0*5)*
* 40056 2018/07/23 11:40:29.572 kid1| 17,4| AsyncCall.cc(38) make: make
call ConnStateData::ConnStateData::httpsPeeked [call261]*
* 40057 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419)
cbdataReferenceValid: 0x559f3b64b4a8*
* 40058 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419)
cbdataReferenceValid: 0x559f3b64b4a8*
* 40059 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419)
cbdataReferenceValid: 0x559f3b64b4a8*
* 40060 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419)
cbdataReferenceValid: 0x559f3b64b4a8*
* 40061 2018/07/23 11:40:29.572 kid1| 17,4| AsyncJob.cc(123) callStart:
Http1::Server status in: [ job10]*
* 40062 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419)
cbdataReferenceValid: 0x559f3b64b4a8*
* 40063 2018/07/23 11:40:29.572 kid1| 33,3| Pipeline.cc(35) front: Pipeline
0x559f3b64b4f0 front 0x559f3b1a9190*2*
* 40064 2018/07/23 11:40:29.572 kid1| 33,3| Pipeline.cc(35) front: Pipeline
0x559f3b64b4f0 front 0x559f3b1a9190*3*
* 40065 2018/07/23 11:40:29.572 kid1| 33,3| client_side.cc(4089)
unpinConnection:*
* 40066 2018/07/23 11:40:29.572 kid1| 33,3| client_side.cc(3927)
pinConnection: local=4.16.205.42:33596 <http://4.16.205.42:33596>
remote=96.43.144.26:443 <http://96.43.144.26:443> FD 15 flags=1*

I assume that a pinned connection means a server connection which MUST have
a 1:1 relationship with some client connection. Accordingly, if the client
terminates, then the server connection should also be closing. From the
post:
http://lists.squid-cache.org/pipermail/squid-users/2015-June/004298.html

1. Are there any security reasons behind *pinning the connection* when a
peek is done at Step1 such that server connection get closed if
corresponding client closes. Why is that done?

2.a)  I see a stmt "reusing a pinned conn" in the function
selectPeerForIntercepted().
>From the logs, I dont find this function getting called. Under what
scenario will this get called? In other words, what is the scenario where a
pinned connection can be reused?

   b) Which configure option is used to enable *#if STRICT_ORIGINAL_DST ?*


*#if STRICT_ORIGINAL_DST*
*if (isIntercepted && useOriginalDst) {*
*        selectPeerForIntercepted();*
*        // 3.2 does not suppro re-wrapping inside CONNECT.*
*        // our only alternative is to fake destination "found" and
continue with the forwarding.*
*        startConnectionOrFail();*
*        return;*
*    }*
*#endif*


On Wed, Jul 18, 2018 at 5:00 PM, Alex Rousskov <
rousskov at measurement-factory.com> wrote:

> On 07/18/2018 03:03 PM, Vishali Somaskanthan wrote:
>
> > I had a problem after sending too many requests to the same server where
> > my persistence stopped working suddenly.
>
> Please note that there are many reasons why a proxy may close a
> connection. For pinned to-server connections (like those created by
> SslBump), it may not be possible to open a new to-server connection so
> Squid should close both from-client and to-server connections.
>
> In general, a client should not rely on a connections staying persistent
> except in some very unusual/special circumstances.
>
>
> > 1. What is the relationship between the caching and the persistence
> > connection established?
>
> Virtually none. Caching decisions are done primarily based on request
> and response headers.
>
>
> > 2. When will squid use cached results and when will it not if the cache
> > deny all directive weren't specified.
>
> Squid will deliver a response from the cache when HTTP rules and Squid
> configuration allow a hit. The details are too complex to document here.
>
>
> > 3. However, this didn't work fully. Even with /cache deny all/
> > directive, persistence wasn't working when I peeked at the sslBump step
> > 1 and then Bumped.
> > Persistence worked only when I directly did sslbump allow all (without
> > peeking at first step).
>
> Bumping step should not affect connection persistence AFAICT. I do not
> know why it does in your case. This could be a Squid bug or a
> misunderstanding. If you can reproduce, Squid logs should contain
> reasons for each connection closure (but it may be difficult to find).
>
>
> HTH,
>
> Alex.
>



-- 
Regards,
Vishali Somaskanthan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180726/a357f369/attachment-0001.html>