On 1/31/2013 4:21 AM, Amos Jeffries wrote:
Have you actually sighted use of the Range: HTTP headers in Youtube
traffic? and have you verified that (2) beow is no longer happening (as
of 2 year ago it was)?
In my experience ...
1) they do not use HTTP Range: headers on most of the videos (at least 2
years ago it was rare).
2) they prefix each snippet of video with FLV meta headers
3) several of the HD video encodings used are VBR encodings based on
IP-layer speed detection.
<SNIP>
I know about the meta headers.
I was referring to the actual thing that two different http
objects(urls) are in-fact a range of the same video.
So we can might try to store partial responses in a cache object
specifically for partial response.
This is where my question was about size since most of the clients
will request more then just 8k chunk and we can even do some
statistics from existing live server logs to make sure of it.
This is the most practical way in the current situation.
This indeed will open a small weakness in cases which there are two
clients requesting the same object one with partial content request
and the other a full response.
A solution for that can be for squid to learn if it dosn't know how to
serve partial content from a complete file.
Squid already has this capability. For the range_offset_limit and HIT
Range: serving capabilities.
This is mainly why I was suggesting wait on Collapsed Forwarding,
because you might find it easier to collapse the two requests down and
service the Range: request out of the full requests response. Or service
the full request using two parallel 'filler' requests around the
underway Range request - together the three background requests
consisting of a full object fetch.
Amos
I suppose this is worth to wait for.
--
Eliezer Croitoru
