[squid-users] Speed limit from file size
rousskov at measurement-factory.com
Thu Jun 21 16:09:35 UTC 2018
On 06/21/2018 05:11 AM, Michael Pro wrote:
> Simplify the task, let's say that I need to limit the speed only for
> what is in the cache, for each client.
> for this type of traffic is it possible made this logic ?
> file =<1MB client download with 400Kbit/s
> file 1MB...5MB client donload with 4Mbit/s
> file >5MB - no speed limit
The Content-Length part of my earlier response still applies.
The adaptation parts of my earlier response do not apply to cache hits:
Squid does not support the post-cache RESPMOD vectoring point.
If your use case is limited to cache hits, then modifying Squid to add a
response size-like ACL would be even more tempting because fully cached
hits without a Content-Length header have known (to Squid) sizes. Please
note cache hits that are still in the process of being downloaded (and
cached) may lack the Content-Length header. In that case, those cache
hits will not have a known (to Squid) size.
You could try using client delay pools (see Amos response for details)
but please note that those pools aggregate based on client IP addresses.
If you have many clients with the same source IP address (NAT or a peer
proxy), then this aggregation may present problems.
You may prefer response delay pools, but they are only available in v5:
Overall, you may be better off redesigning your bandwidth limiting plans
away from "file size" and towards something more directly related to
bandwidth consumption. The further you get from HTTP, the more difficult
mapping your requirements to HTTP tool capabilities becomes...
> чт, 21 июн. 2018 г. в 8:18, Alex Rousskov <rousskov at measurement-factory.com>:
>> On 06/20/2018 01:44 PM, Michael Pro wrote:
>>> Is it possible to limit the speed of receiving the file to the client
>>> depending on the file size?
>>> Let's say,
>>> file =<1MB client download with 400Kbit/s
>>> file 1MB...5MB client donload with 4Mbit/s
>>> file >5MB - no speed limit
>> For HTTP responses with a Content-Length header, you can create poor
>> man's equivalent of a missing response_body_size ACL. For example:
>> acl smallerThanTenBytes rep_header Content-Length ^[0-9]$
>> With an ACL like that, you can direct responses to the right pool. IIRC,
>> pool assignment may happen multiple times during the lifetime of a
>> transaction so you need to be careful to deal with assignments that are
>> done before there is a response. Delay pools are not my area of
>> expertise but others on the list can help you with the details.
>> For HTTP responses without a Content-Length header, you can use an
>> adaptation service (ICAP or eCAP) to tag transactions that start to
>> exceed 1MB and 5MB boundaries. A "note" ACL can check for that tag, but
>> I do not think Squid delay pools re-check pool ACLs after the response
>> body bytes start to flow. If I am right, then you would not be able to
>> (re)route response body bytes to the right delay pool for responses
>> without a Content-Length header.
>> You could use an adaptation service itself to slow responses without
>> Content-Length down (partially duplicating Squid's delay pools
>> capabilities), but the precision of such an approach may be too low due
>> to Squid internal buffering. YMMV.
>> For HTTP CONNECT tunnels (i.e., HTTPS traffic) even the adaptation
>> tricks would not work because adaptation services do not get CONNECT
>> tunnel bytes (yet?). You would have to bump the tunnel to get access to
>> the HTTP responses inside (and bumping opens another huge Pandora box).
> squid-users mailing list
> squid-users at lists.squid-cache.org
More information about the squid-users