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
