[squid-dev] TLS proxy-server connection optimization

[Vishali Somaskanthan]

Hey Alex,

Thank you for mentioning about specific details. Here is the point.

[Alex] Why does Squid close the (not pinned) Squid-to-server connection in
this
case? What code/condition triggers that closure in your tests?

When the SSL-bump steps are
1. *peek-splice and peek-peek-splice*,
we observe the behavior that squid does tunneling and presume that SSL
proxying is not happening in this case.
Hence, after the series of writes, *keepGoingAfterRead()* is called where
the following snippet triggers the closure from squid to server.

*/* Only close the remote end if we've finished queueing data to it */*
*        if (from.len == 0 && Comm::IsConnOpen(to.conn) ) {*
*            to.conn->close();*

Here, we would to like to do the optimization where instead of closing
them, we want to Push the connection to Pconn pool which can be used later
for a second request. So that TCP persistence is achieved.

2. *peek-bump*

As we have discussed already in the general forum (http://squid-web-pro
xy-cache.1019090.n4.nabble.com/server-persistent-connections
-and-cache-td4685973.html), the table contains the cases where pinning
happens and where not, we would like to achieve the SSL persistence here
from squid to-server connection. When we unpin the connection it gets
closed, and we would like to retain them up in the pool. Please let me know
what information is required in this case for further validation.


Thank you,
Vishali


On Tue, Jul 31, 2018 at 4:29 PM, Alex Rousskov <
rousskov at measurement-factory.com> wrote:

> On 07/31/2018 05:00 PM, Vishali Somaskanthan wrote:
> > If I peek @step1 and splice@ step2 -> The connections are **not** pinned
> > as such. However, Client-squid SSL+TCP termination results in
> > squid-server SSL+TCP termination.
>
> Why does Squid close the (not pinned) Squid-to-server connection in this
> case? What code/condition triggers that closure in your tests?
>
>
> > Please provide any insights on whether this is going to be a valid
> > optimization and if we can come up with a set of rules where this
> > could apply.
>
> With enough information/analysis, we should be able to correctly
> evaluate your proposal, but that proposal will have to be a lot more
> specific than "We want to optimize TLS and evaluate if squid to-server
> TLS connection can be reused for consecutive requests from multiple
> clients". My question above is a (small) step towards formulating a
> specific "We want to change Squid to do X instead of Y" proposal.
>
>
> Thank you,
>
> Alex.
>



-- 
Regards,
Vishali Somaskanthan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20180803/b07c9247/attachment.html>