Re: [squid-users] Re: Caching netflix by Mime headers

Dont get me wrong,

Im preparing a cache to save bandwidth on classic home who has already
netflix suscription, but you have kids. You know kids watch again and
again same picture, there is where we can save bandwidth.

Thats why i want to cache the ISMV/ISMA flux. What I have realized is
that the same request is always done by same pair movie-device.

LD

2013/2/17 Amos Jeffries <squid3_at_treenet.co.nz>:
> On 18/02/2013 8:58 a.m., Eliezer Croitoru wrote:
>>
>> You will need more then just one or two lines of logs and data to
>> determine that.
>>
>
> Sadly those lines are enough to say that Squid does not currently have Range
> support. So Squid can't cache those 206 responses yet anyway - even if more
> complicated tricks are used to avoid other request differences.
>
>
>> I don't know a thing about how netflix players do their stuff but I doubt
>> they will make it simple as "cache it using basic squid".
>>
>
> Netflix appear to be one of the cache-friendly providers. Some smart cookies
> over there are using cache controls and HTTP bandwidth reduction features
> *properly* for once.
>
> I advise leaving their traffic alone. Yes their site uses a lot of
> bandwidth, but these *are* large HD movies with per-user licensing embeded.
> The binaries *actually* can't be shared by multiple users - making them
> non-cacheable in most cases. Note that due to bandwidth costs Netflix
> themselves have an ongoing vested interest in improving cacheability of
> their content wherever possible.
>
>
>
>> Eliezer
>>
>> On 2/17/2013 9:01 PM, Luis Daniel Lucio Quiroz wrote:
>>>
>>> I turn on more loggin and i realize this
>>>
>>>
>>> 1361126274.457 66976 192.168.7.134 TCP_MISS/206 18439445 GET
>>>
>>> http://108.175.42.86/658595255.ismv?c=ca&n=812&v=3&e=1361155197&t=L_cj-INb4sDdWF9RHoaOwwjBg7o&d=android&p=5.c4MuCNB5I0-lmXZGQaxWaOpiwGX91JBhZqIvTbIHroM
>>> - HIER_DIRECT/108.175.42.86 application/octet-stream
>>>
>>>
>>> 1361126280.021 72537 192.168.7.134 TCP_MISS/206 1095098 GET
>>>
>>> http://108.175.42.86/658618947.isma?c=ca&n=812&v=3&e=1361155197&t=_I4PVA3JkFpFxS90V8qgmM1Q-OU&d=android&p=5.c4MuCNB5I0-lmXZGQaxWaOpiwGX91JBhZqIvTbIHroM
>>> - HIER_DIRECT/108.175.42.86 application/octet-stream
>>>
>>> My question is, if i force caching of \d+\.ism[av] files, the ?
>>> payload will be clashed or will diferenciate a?b, and a?c for example
>>>
>
> Both the *.ism* and the t=* pieces of that URI are changing between those
> requests.
>
> Do you know exactly what those pieces mean? in particular do you *know* they
> are safe to remove?
> ... if you say yes, you are probably wrong. One seems to be an audio stream
> and the other a video stream.
>
> IMO, you may be able to alias the IP address back to a hostname using
> storeID feature now in squid-3 (but not the Store-URL versionin 2.7) to
> de-duplicate. But that is just another guess as well.
>
> Remember that what you risk when getting it wrong:
> - responding with movie A to movie B requests (worst case: movie A being XXX
> rated and movie B a kids flick.)
> - Also, DRM licensing *inside* the media risks that user receiving a HIT
> cannot play it after a huge bandwidth wasting D/L.
> - Also, loss or crossover of video or audio streams.
>
> None of which are great experiences for your users or your helpdesk. Not
> everybody is out to break your cache. You could be doing it to yourself
> without any need.
>
> Amos
Received on Sun Feb 17 2013 - 23:36:42 MST