Re: [squid-users] Re: ICP and HTCP and StoreID

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 15 Jan 2014 23:21:17 -0700

On 01/15/2014 03:31 PM, Niki Gorchilov wrote:
> Actually, it is working. [...] inter cache communication is working only with
> altered URLs but this still does the job:
> - If UDP is MISS the originating peer makes a TCP connection to
> destination server and caches the result
> - if UDP is HIT, the call is forwarded via sibling with modified URL,
> but the sibling handles the request without problems
>
> UDP HIT request example:
> peer B: UDP_HIT/000 0 HTCP_TST
> http://c.youtube.com.squid.internal/videoplayback/09ebf166f4892e4f.140.712704-950271
> - HIER_NONE/- -
> peer B: TCP_HIT/200 237948 GET
> http://c.youtube.com.squid.internal/videoplayback/09ebf166f4892e4f.140.712704-950271
> - HIER_NONE/- application/octet-stream
> peer A: TCP_MISS/200 237948 GET
> http://r2---sn-bavc5aoxu-nv4e.googlevideo.com/videoplayback? -
> SIBLING_HIT/peerb application/octet-stream
>
> UDP MISS request example:
> peer B: UDP_MISS/000 0 HTCP_TST
> http://c.youtube.com.squid.internal/videoplayback/09ebf166f4892e4f.140.2138112-2375679
> - HIER_NONE/- -
> peer A: TCP_MISS/200 237938 GET
> http://r2---sn-bavc5aoxu-nv4e.googlevideo.com/videoplayback? -
> HIER_DIRECT/r2---sn-bavc5aoxu-nv4e.googlevideo.com
> application/octet-stream
>
> Case closed!

Store ID is not a URL (even if it is often convenient to think that
way). If Squid sends requests with StoreIDs, Squid is broken (even if it
happens to usually work in your particular case). Consider the situation
where the peer returned UDP_HIT but then purged the cached entry. What
will it do with the c.youtube.com.squid.internal request?

Somebody who cares about this _and_ can reproduce it, should file a bug
report, but please double check that the requests are indeed using Store
IDs using cache.log debugging or a packet trace. Do not just assume that
Squid will never log a Store ID instead of a URL.

Thank you,

Alex.

> On Wed, Jan 15, 2014 at 6:22 PM, Niki Gorchilov <niki_at_gorchilov.com> wrote:
>> Hi All,
>>
>> I know, according to wiki
>> (http://wiki.squid-cache.org/Features/StoreID) ICP & HTCP are not
>> supported. “URL queries received from cache_peer siblings are not
>> passed through StoreID helper. So the resulting store/cache lookup
>> will MISS on URLs normally alterd by StoreID.”
>>
>> Still, in lab test show that cache peer is queried by the StoreID
>> altered URL, so this part is actually working. At least in version
>> 3.4.1.
>>
>> The real problem is, when a siblink replies with UDP_HIT, the actual
>> HTTP request sent to this peer uses the altered URL, instead of the
>> original one.
>>
>> Here's a simple example:
>>
>> 1. Peer A receives request for URL like
>> http://r2---sn-bavc5aoxu-nv4e.googlevideo.com/videoplayback?
>> 2. Peer A's StoreID helper normalizes the URL to
>> http://c.youtube.com.squid.internal/videoplayback/09ebf166f4892e4f.140.950272-1187839
>> 3. Peer A makes an ICP/HTCP query to Peer B for
>> http://c.youtube.com.squid.internal/videoplayback/09ebf166f4892e4f.140.950272-1187839
>> 4. Peer B replies with "UDP_HIT/000 0 HTCP_TST
>> http://c.youtube.com.squid.internal/videoplayback/09ebf166f4892e4f.140.950272-1187839"
>> 5. Peer A creates HTTP connection to Peer B and makes "GET
>> http://c.youtube.com.squid.internal/videoplayback/09ebf166f4892e4f.140.950272-1187839
>> HTTP/1.1"
>> 6. Peer B, tries to connect to the non-existent host
>> c.youtube.com.squid.internal and as a result generates HTTP 504 error.
>> 7. Peer A receives "TCP_MISS/504 4181 GET
>> http://c.youtube.com.squid.internal/videoplayback/09ebf166f4892e4f.140.950272-1187839
>> - HIER_NONE/- text/html" and goes directly to youtube "TCP_MISS/200
>> 237938 GET http://r2---sn-bavc5aoxu-nv4e.googlevideo.com/videoplayback?
>> - HIER_DIRECT/r2---sn-bavc5aoxu-nv4e.googlevideo.com
>> application/octet-stream"
>>
>> The question is how to force squid to use the original URL when making
>> the TCP/HTTP connection to the peer after UDP_HIT? UDP request shall
>> keep using the normalized/rewritten URL.
>>
>> Thank in advance for any ideas.
>>
>> Best,
>> Niki
Received on Thu Jan 16 2014 - 06:21:24 MST

This archive was generated by hypermail 2.2.0 : Thu Jan 16 2014 - 12:00:05 MST