[squid-users] TCP_MISS only

[Amos Jeffries]

On 22/10/22 01:50, Andy Armstrong wrote:
> Hi Amos, All,
> 
> I continue to struggle with only receiving TCP_MISS when using 
> squid-cache. I have now implemented a server which is responding to HTTP 
> GETs. I have checked the endpoint with redbot.org and it states that :
> 
> 1/The response allows all caches to store it
> 
> 2/The response is fresh until 7 days from now
> 
> The reason may still be served by a cache once it becomes stale.
> 
> Therefore I believe the server side of this is now valid as a test for 
> squid cache.
> 

Excellent.


> My client, is routing calls to squidcache, and when it arrives there, I 
> see the following log entry:
> 
> 1666355825.841106 10.1.1.70 TCP_MISS/200 60646 GET 
> http://192.168.20.1:3004/largeapp/largeapp/007005/bongo? - 
> HIER_DIRECT/192.168.20.1 application/json
> 

The URL contains a query-string section. That is elided by default for 
security (in case credentials or other sensitive info is in there).

To more accurately test this you should add this to your squid.conf:

   strip_query_terms off

That will log the full query-string for accurate URL checking in 
access.log. You can remove it for the production system later if you want.


If the resulting access.log shows any difference (one single byte is 
enough) between the URLs they are different objects as far as the cache 
can tell.

Are you using the Vary feature of HTTP at all? If so the exact bytes in 
the named client headers matter (both case-sensitive and order-sensitive).



> Infact every single client call I make results in this TCP_MISS.
> 
> I therefore think this may be to do with my squid.conf.
> 

There does not appear to be anything wrong with your squid.conf.
I suspect some misunderstanding of the HTTP semantics.

...
> 
> refresh_pattern -i http:\/\/192.168.20.1:3001\/.* 10080 100% 43200  
> override-lastmod
> 
> refresh_pattern -i http:\/\/192.168.20.1:3004\/.* 10080 100% 43200  
> override-lastmod
> 

The redbot.org results indicate that the object is cacheable according 
to the server headers so you should not need these. I do not think they 
are being harmful, but please remove for now to simplify the 
troubleshooting.


Please do the following:

  * add this to squid.conf to see the actual traffic flow in cache.log:

    debug_options ALL,1 11,2

  * make two (2) client requests for the same object. Waiting until the 
server responses have both arrived.

  * check access.log to verify the full URL is indeed identical.

We will need to see the HTTP traffic sequence you should be able to find 
in cache.log. The log entries are multi-line and start with the 
following tags, appearing in this order:

   "HTTP Client REQUEST"
   "HTTP Server REQUEST"
   "HTTP Server RESPONSE"
   "HTTP Client RESPONSE"

Please post the line(s) with that tag and the block of headers that 
follow it.

If any other log lines appear interesting or suspicious, it would be 
helpful to see those too and where exactly in the sequence they appear.


HTH
Amos