<div dir="ltr"><font face="verdana, sans-serif">Hey Alex,</font><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">Thank you for mentioning about specific details. Here is the point. </font></div><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">[Alex] <span style="font-size:12.800000190734863px">Why does Squid close the (not pinned) Squid-to-server connection in this</span></font></div><span style="font-size:12.800000190734863px"><font face="verdana, sans-serif">case? What code/condition triggers that closure in your tests?</font></span><div><span style="font-size:12.800000190734863px"><font face="verdana, sans-serif"><br></font></span></div><div><font face="verdana, sans-serif"><span style="font-size:12.800000190734863px">When the SSL-bump steps are</span></font></div><div><font face="verdana, sans-serif"><span style="font-size:12.800000190734863px">1. <b>peek-splice and peek-peek-splice</b>, </span></font></div><div><font face="verdana, sans-serif"><span style="font-size:12.800000190734863px">we observe the behavior that </span></font><span style="font-size:12.800000190734863px;font-family:verdana,sans-serif">squid does tunneling and presume that SSL proxying is not happening in this case. </span></div><div><font face="verdana, sans-serif"><span style="font-size:12.800000190734863px">Hence, after the series of writes, </span><i style="background-color:rgb(255,255,0)">keepGoingAfterRead()</i></font> <font face="verdana, sans-serif">is called where the following snippet triggers the closure from squid to server.</font></div><div><font face="verdana, sans-serif"><br></font></div><div><div><font face="verdana, sans-serif"><i>/* Only close the remote end if we've finished queueing data to it */</i></font></div><div><font face="verdana, sans-serif"><i>        if (from.len == 0 && Comm::IsConnOpen(to.conn) ) {</i></font></div><div><font face="verdana, sans-serif"><i>            to.conn->close();</i></font></div></div><div><br></div><div><font face="verdana, sans-serif">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. </font></div><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">2. <b>peek-bump</b></font></div><div><font face="verdana, sans-serif"><b><br></b></font></div><div><font face="verdana, sans-serif">As we have discussed already in the general forum (</font><a href="http://squid-web-proxy-cache.1019090.n4.nabble.com/server-persistent-connections-and-cache-td4685973.html" target="_blank" style="font-family:verdana,sans-serif;font-size:12.800000190734863px">http://squid-web-pro<wbr>xy-cache.1019090.n4.nabble.com<wbr>/server-persistent-connections<wbr>-and-cache-td4685973.html</a><font face="verdana, sans-serif">), 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. </font></div><div><br></div><div><br></div><div><font face="verdana, sans-serif">Thank you,</font></div><div><font face="verdana, sans-serif">Vishali </font></div><div><font face="verdana, sans-serif"><br></font></div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Jul 31, 2018 at 4:29 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 07/31/2018 05:00 PM, Vishali Somaskanthan wrote:<br>
> If I peek @step1 and splice@ step2 -> The connections are **not** pinned<br>
<span>> as such. However, Client-squid SSL+TCP termination results in<br>
> squid-server SSL+TCP termination.<br>
<br>
</span>Why does Squid close the (not pinned) Squid-to-server connection in this<br>
case? What code/condition triggers that closure in your tests?<br>
<span><br>
<br>
> Please provide any insights on whether this is going to be a valid<br>
> optimization and if we can come up with a set of rules where this<br>
> could apply.<br>
<br>
</span>With enough information/analysis, we should be able to correctly<br>
evaluate your proposal, but that proposal will have to be a lot more<br>
specific than "We want to optimize TLS and evaluate if squid to-server<br>
<span>TLS connection can be reused for consecutive requests from multiple<br>
</span>clients". My question above is a (small) step towards formulating a<br>
specific "We want to change Squid to do X instead of Y" proposal.<br>
<br>
<br>
Thank you,<br>
<br>
Alex.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-7547919228956311941gmail_signature"><div dir="ltr"><div>Regards,</div>Vishali Somaskanthan</div></div>
</div></div>