[squid-users] Youtube not TCP_HIT Squid3.5.21-25

[Amos Jeffries]

On 29/05/17 05:21, Yuri wrote:
>
> 28.05.2017 21:09, Eduardo Carneiro пишет:
>> Ok. Tell me what technical details you need and I post here.
> Configs. Logs. Topology. Usecases. Examples for single transactions.
>> But if this were an ignoring cache-control issue, wouldn't that happen on
>> squid 3.5.19 and previous versions as well?
>>
>> With the same conf works on 3.5.19 but not in newest squid3 versions.
> Once more. Ignoring cache-control in squid is deprecated due to RFC
> requirements. So, it leads to drops down with byte HIT in general. I do
> not remember when it exactly desupported in squid's code, but seems
> approx. at some 3.5.x.

 From 3.5.19 onwards ..

3.5.21 added support for Squid to differentiate between revalidation 
checks that were always vs sometimes necessary. Fixing the situation 
where responses had both a CC:private or CC:no-cache header and 
information stating cacheability "freshness".

3.5.22 fixed issues that were then seen with missing Last-Modified and 
old Date values, and the Collapsed Forwarding feature.

3.5.23 added support for caching objects with "Vary: *" which depended 
on the change in .21, and caching of 3034 responses. Also fixed the main 
outstanding issue behind Host verify MISS happening, and a regression in 
the .22 collapsed forwarding change.

3.5.24 fixed a regression in the "cache deny" access control handling 
which was causing some thing to be cached and revalidated when they 
should not have. This may make some things now un-cacheable if there is 
a misconfiguration in that directive.

3.5.25 fixed a stall that happens when SSL-Bump interacts with Host 
verification through the SNI value. While not strictly related, having 
it fixed allows a lot more Google/YouTube/Akamai transactions to reach 
the caching stages so their operations start to be visible instead of 
splice/tunnel'ed.


The expected effect of these changes was to fix several major 
unnecessary bandwidth uses;
  - cached YouTube videos starting mid-video when someone else using the 
proxy had only partially watched the same video - causing the user to 
force-refresh and purge the cached video.
  - Chrome and similar Google originated downloads being a MISS for 
identical objects.
  - the often cited terrible HIT reduction on some major hosting 
services (again Google, though also Akamai) traffic since 3.2 Host 
verify was added.
  - collapsed forwarding resulting in large objects being stored to the 
cache then immediately deleted by a parallel fetch.


Amos