squid对http range的处理以及range_offset_limit

ts2009

range_offset_limit

　　A range request comes from a client that wants only some subset of an HTTP response. They are sometimes used to resume a failed transfer of a large file. Squid isn't yet able to cache partial responses and thus must make a decision when forwarding a range request: either remove the Range header or leave it in.
If Squid leaves the Range header in, the origin server sends only the subset that the client wants, and the client receives the response immediately. However, this partial response isn't cached.
On the other hand, if Squid removes the header before forwarding, it receives the entire response, which may be cached. Squid is then responsible for ensuring that the client receives only the subset it needs. The origin server may send a lot of data the client doesn't want. Depending on the speed of your connection, the client may be forced to wait a long time until its range is available.
If the beginning of the requested range is larger than the range_offset_limit value, Squid forwards the Range header and doesn't cache the response. Setting range_offset_limit to 0 causes Squid to always forward the Range header (the default). Setting it to -1 causes Squid to never forward the header.
　　

Syntax	range_offset_limit size-specification
Default	range_offset_limit 0 KB
Example	range_offset_limit 100 KB

　　
　　问答：
　　> Range headers - from my understanding, it looks like they use this for
> video streaming.. it looks like the client can request a part of the object
> body to be sent alone to him. Is it correct? In this case, if multiple
> ranges are requested, is it sent separately or in a consolidated manner?
I'm not sure what your use case is, but I've been playing with youtube
caching lately, and range headers play a part in trying to cache
client requests.
Squid won't cache range header requests for specific byte ranges.
However, squid can accept range headers from client and discard them
when sending upstream.
  range_offset_limit -1 [<optional_acl>]
will do the job.  I use an ACL to only apply it to specific domains I
want the behaviour for.
Squid will serve the client the correct bytes, but by discarding the
range headers for the upstream retrieval, it will cache the whole
object and subsequent range requests for the cached object will result
in a hit.
Parallel simultaneous requests to the same object with a range header
will likely result in parallel, full retrieval of the whole file
though (I say likely as I havn't tested but suspect that will be the
case).
A related behaviour on youtube specifically (and possibly others) is
the use of '&range=X-Y' URL parameters instead of range header
requests.  I've noticed this more on web-browsers on PCs, whereas I've
seen the range header requests on Apple IOS mobile platforms.
There have been some clever tricks using storeurlrewrite or storeid to
include the range bytes in the key of the object stored, so without
the use of range_offset_limit, squid can store an object per unique
client range request & provide a hit for subsequent requests.  My
testing has indicated this is unreliable as the byte-ranges tend to be
dynamic based on the clients current bitrates so off-by-one range
requests result in a lot of duplication in the cache.
You can also utilise an ICAP server to do even funkier stuff like
mould range URL parameters into range header requests so the different
client behaviours share the same cache objects.
　　
　　以上摘自国外网站上的一些阐述和问答。
　　首先要明确的是squid是不会缓存partial content的，我们要做的是在文件未完整缓存的情况下如何处理回源请求。
　　组合配置：
　　range_offset_limit 10 MB　　#超出此值将forward range header，否则去掉range
quick_abort_min 10 MB　　　#小于此值将继续从源服务器完成下载
quick_abort_max 50 MB　　  #超出此值将放弃从源服务器下载
quick_abort_pct 95　　　　　#进度超出此值将继续从源服务器完成下载
　　以上配置需要根据业务需求和统计数据合理设置。