[squid-users] Squid returns NONE_ABORTED/000 and high response time but the internet access itself looks okay

[Ahmad, Sarfaraz]

>> Your guess is wrong. The TCP level setup is only between Squid and the client. It has to have completed before the TLS stuff can begin.
So when does Squid start setting up the TCP connection with the origin server ? After setting up a TCP connection with client and identifying it to be TLS ? 

What would this log message likely mean then ? I was reading that as 78477ms was the time it took for Squid to connect to 173.194.142.186 on port 443 and Squid and client(not the origin server) had already established a TCP connection beforehand (while it(squid) tries connecting to the remote server on port 443).
1533612202.312  78477 <ip> NONE_ABORTED/000 0 CONNECT 173.194.142.186:443 - HIER_NONE/- -

That would imply two things.
1) It took a lot of time for clients to set up a TCP connection with Squid given Chrome's dev tools 
2) Second, Squid took a while to establish a connection with origin server. 

Moreover, my ICAP settings look like this,
icap_service localicap reqmod_precache icap://127.0.0.1:1345/reqmod bypass=on routing=off on-overload=wait

ICAP would come into the picture only after I see a GET request in the access.log, right? 

Regards,
Sarfaraz

-----Original Message-----
From: Amos Jeffries <squid3 at treenet.co.nz> 
Sent: Tuesday, August 7, 2018 9:04 PM
To: Ahmad, Sarfaraz <Sarfaraz.Ahmad at deshaw.com>; squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Squid returns NONE_ABORTED/000 and high response time but the internet access itself looks okay

On 08/08/18 02:14, Ahmad, Sarfaraz wrote:
> I cannot reproduce this. This is intermittent.  In Chrome's dev tools, 
> it appeared to take over 20 secs to setup the TCP connection.
> I am SSL bumping all TLS connections unless they match certain ACLs.
> So it is safe to assume that the vast majority of the traffic was 
> bumped.
> 
> I don't see any TLS handshake failure messages in cache.log. I think 
> the access.log messages I posted earlier are fake CONNECT requests 
> created using TCP-level info (the response time logged there is 
> directly proportionate to what I see in Chrome's dev tools). Guessing 
> that Squid would send TCP SYN-ACK only after it receives SYN-ACK from 
> remote/origin server.

Your guess is wrong. The TCP level setup is only between Squid and the client. It has to have completed before the TLS stuff can begin.

The first fake-CONNECT is done after TCP connection setup to see whether the client is allowed to perform TLS inside it - and how Squid handles that TLS.


> I don’t think ICAP(reqmod) would come into the picture yet either 
> (assuming that even the TCP connections have not been set up yet) so 
> that is safe to rule out. Am I right here ?

You are right about that in relation to TCP.

But TCP is already over and done with by the time the fake-CONNECT gets generated. So wrong about ICAP's lack of involvement - it may (or not) be.

NP: The only thing fake about the early CONNECT's is that the client did not actually generate it. They are handled in Squid same as a regular CONNECT message would be.

Amos