[squid-users] TCP_MISS/304 question
Yuri Voinov
yvoinov at gmail.com
Fri Oct 14 12:36:49 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
14.10.2016 18:30, Amos Jeffries пишет:
> On 15/10/2016 12:34 a.m., Yuri Voinov wrote:
>>
>> A bit more details.
>>
>> This is 4 transactions in chronological order. Two from wget -S and two
>> from same PC via browser for the same URL:
>>
>> *root @ khorne /tmp # wget -S
>> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
>> --2016-10-14 17:18:05--
>> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>> Connecting to 127.0.0.1:3128... connected.
>> Proxy request sent, awaiting response...
>> HTTP/1.1 301 Moved Permanently
>> Server: nginx
>> Date: Fri, 14 Oct 2016 11:18:07 GMT
>> Content-Type: text/html
>> Content-Length: 178
>> Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>> X-Cache: MISS from khorne
>> X-Cache-Lookup: MISS from khorne:3128
>> Connection: keep-alive
>> Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
[following]
>> --2016-10-14 17:18:07--
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>
> Notice how the Location header made wget fetch send a second fetch to
> *actually* load an HTTPS object.
>
> This means your use of HTTP is irrelevant. HTTP just results in an 301
> response. That is the end of the HTTP...
Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
This is no matter.
>
>
>
>> Connecting to 127.0.0.1:3128... connected.
>> Proxy request sent, awaiting response...
>> HTTP/1.1 200 OK
>> Server: nginx
>> Date: Fri, 14 Oct 2016 10:45:57 GMT
>> Content-Type: application/javascript; charset=windows-1251
>> Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
>> ETag: W/"cdf370-758-52351a306ac80"
>> Cache-Control: max-age=3600
>> Expires: Fri, 14 Oct 2016 11:45:57 GMT
>> Access-Control-Allow-Origin: *
>> Age: 1930
>> X-Cache: HIT from khorne
>> X-Cache-Lookup: HIT from khorne:3128
>> Transfer-Encoding: chunked
>> Connection: keep-alive
>> Length: unspecified [application/javascript]
>> Saving to: 'gazeta.media.query.js'
>>
>> gazeta.media.query. [ <=> ] 1.84K --.-KB/s in
>> 0s
>>
>> 2016-10-14 17:18:07 (138 MB/s) - 'gazeta.media.query.js' saved [1880]
>>
>> /HTTP object in cache and HIT./
>
> No. *HTTPS* object in cache and HIT.
Oh, mistype. Let it be HTTPS and HIT.
>
>
>
>> *
>> **root @ khorne /tmp # wget -S
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
>> --2016-10-14 17:18:30--
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>> Connecting to 127.0.0.1:3128... connected.
>> Proxy request sent, awaiting response...
>> HTTP/1.1 200 OK
>> Server: nginx
>> Date: Fri, 14 Oct 2016 10:45:57 GMT
>> Content-Type: application/javascript; charset=windows-1251
>> Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
>> ETag: W/"cdf370-758-52351a306ac80"
>> Cache-Control: max-age=3600
>> Expires: Fri, 14 Oct 2016 11:45:57 GMT
>> Access-Control-Allow-Origin: *
>> Age: 1953
>> X-Cache: HIT from khorne
>> X-Cache-Lookup: HIT from khorne:3128
>> Transfer-Encoding: chunked
>> Connection: keep-alive
>> Length: unspecified [application/javascript]
>> Saving to: 'gazeta.media.query.js.1'
>>
>> gazeta.media.query. [ <=> ] 1.84K --.-KB/s in
>> 0s
>>
>> 2016-10-14 17:18:30 (120 MB/s) - 'gazeta.media.query.js.1' saved [1880]
>>
>> /HTTPS object in cache and HIT too./
>
> No. Same HTTPS object from test #1 is still in cache and still being HIT.
>
>>
>> This is ok.
>
> Uh, not if you are going to interpret the first test as being an HTTP
> object in cache.
>
> What this tells is that fetching an HTTPS object twice in a row will
> produce a HIT.
Yes. Let it be.
>
>
>>
>> *Ctrl+F5 (force reload) from browser:*
>>
>> 1476443947.419 92 192.168.100.103 TCP_MISS/200 2323 GET
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js -
>> HIER_DIRECT/81.19.72.0 application/javascript
>>
>> MISS - it is ok too, client browser sends no-cache.
>
> Did you check the client request to verify that "no-cache" statement?
Yes.
>
>
>>
>> At this point we sure object in cache, right? Both in proxy cache and in
>> client cache (client is the same in attempt 3 and 4). Now - refresh from
>> browser on the same page (same session), which is equivalent of page
>> auto-refresh.
>
> Yes, that is a reasonable state to assume at this point. Though possibly
> wrong, since it is an assumption.
>
>>
>> *F5 (refresh) from the same browser:*
>>
>
> NP: be aware that two fetches in a row is different form force-refresh,
> which is different from non-forced refresh.
>
> One of the two refresh involved no-cache header, the other involves
> max-age=0 header.
> The double-fetch does not send either no-cache nor max-age=0.
>
> Also be aware that the MSIE browser name for the button "Refresh" which
> got copied by the others is browser GUI terminology, not HTTP terminology.
> HTTP terminology uses "force-refresh" or "reload" for the two request
> header cases caused by F5 and Ctrl+F5.
Sure. In case 3 and 4 latest Google Chrome used. No MSIE bullshit, which
is not respect RFC at all.
Anyway. This is word games.
The HTTPS object (HTTP/1.1) is absolutely sure in client and proxy
caches. Right?
So, why not expired object in both caches produces TCP_MISS/304?
>
>
>
>> 1476443997.252 96 192.168.100.103 TCP_MISS/304 353 GET
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js -
>> HIER_DIRECT/81.19.72.0 -
>>
>> Here is it. Object in proxy cache, in client cache, revalidation is ok -
>> object not changed. It must be TCP_REFRESH_UNMODIFIED, and this tag
>> we've got with HTTP object via browser.
>
> No. I think you have confused the GUI button name with the Squid log tag
> name.
> REFRESH tag occurs on revalidation transactions. The F5 (aka
> "forced-refresh") can lead to that.
> The Ctrl+F5 (aka. "reload") can only lead to MISS (aks reload, re-fetch,
> "discard cached contents").
>
> When a browser send no-cache the cached content must not be used, but
> can be updated by the reply that comes back.
>
> When the browser sends max-age=0, the cached contents *can* be used
> provided they meet the 0sec old criteria (ie revalidate, then use the
> resulting cache object).
>
>>
>> /But shit! HTTPS goes TCP_MISS/304! We're expected to get
>> TCP_REFRESH_UNMODIFIED/304! Because this is refresh operation, we're
>> sure object in both caches - proxy and client, revalidation is ok, but
>> this marks as MISS./
>
> Your expectation was fooled by the browser mis-naming of things.
>
>>
>> Why HTTP refresh goes with TCP_REFRESH_UNMODIFIED, and the same object
>> via HTTPS goes with TCP_MISS? As shown above, object has no headers
>> preventing caching.
>
> HTTP is not relevant for the reason stated above. What your test has
> done is fetch the same https:// URL in three different ways and seen
> three different log entries result from that.
>
> Whether they were the right responses is unknown. But at least they were
> different. I would be more worried if they were the same.
>
>>
>> Is it bug or feature? Because of, when site goes under HTTPS, it will
>> has lower hit with the same content. It seems wrong.
>
> I hope the above clarifies the situation. There may or may not be bugs
> involved, but this test does not demonstrate any that I can see.
>
> It also does not demonstrate any difference in HIT with HTTP vs HTTPS.
> In fact it demonstrates that HTTPS is getting HITs.
>
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYANFhAAoJENNXIZxhPexGbvIIAMTCtxLxWS7yd6nwTrBvVLqg
mG34AUO6buxKSaqw0ZVx0TZNWY/5t/V4ma4JxRpZKBXDrbE7AtP4LeyKoqShs3U8
AdME7HaSSe7Hdta26IZtisK3a6y9K24IyhiSlu6KeBKJqEdDVjBaoioqj0nrUBJC
hyclRgaV4mFDcJjUZ3ZZToz5ueVXQnBy6VbIz28pY4rjR1t94KrPKOmIKyKlf7Xc
1FlNAtgIZ7tFs4YhI8jx/I5NkHAVxcJN0R9Owp7AzU0afobaSFU/1dMYHs5/UxUG
3GqiHDZB6MdOhT8wAnctchkDlGpeShOxiRJJKfGLXBIOwQiZm3i4A50dsFpmc/I=
=yoS2
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161014/ce3ed501/attachment-0001.key>
More information about the squid-users
mailing list