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: https://github.com/squid-cache/squid/commit/b27668e 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... HTH, Alex. > чт, 21 июн. 2018 г. в 8:18, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>: >> >> 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). >> >> >> HTH, >> >> Alex. > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
