This new feature is useful for specific response(s) bandwidth limiting.
AFAIK, there are situations when doing this is hardly possible
(or impossible) by means of netfilter/iptables operating with
TCP/IP packets and IP addresses information for filtering. In other
words, sometimes it is problematic to 'extract' a single response from
TCP/IP data flow at system level. For example, a single Squid-to-client
TCP connection can transmit multiple responses (persistent connections,
pipelining or HTTP/2 connection multiplexing) or be encrypted
(HTTPS proxy mode).
HTH,
Eduard.
On 09.01.2017 09:33, Amos Jeffries wrote:
On 24/12/2016 9:26 p.m., Eduard Bagdasaryan wrote:
Hello,
This patch introduces a new "response_delay_pools" feature.
The feature restricts Squid-to-client bandwidth and applies to both
cache hits and misses.
When Squid starts delivering the final HTTP response to a client, Squid
checks response_delay_pool_access rules (supporting fast ACLs only), in
the order they were declared. The first rule with a matching ACL wins.
If (and only if) an "allow" rule won, Squid assigns the response to the
corresponding named delay pool.
If a response is assigned to a delay pool, the response becomes subject
to the configured bucket and aggregate bandwidth limits of that pool,
similar to the current "class 2" server-side delay pools, but with a
brand new, dedicated "individual" filled bucket assigned to the
matched response.
The new feature serves the same purpose as the existing client-side
pools: both features limit Squid-to-client bandwidth. Their common
interface was placed into a new base BandwidthBucket class. The
difference is that client-side pools do not aggregate clients and always
use one bucket per client IP. It is possible that a response becomes a
subject of both these pools. In such situations only matched response
delay pool will be used for Squid-to-client speed limiting.
The accurate SMP support (with the aggregate bucket shared among
workers) is outside this patch scope. In SMP configurations,
Squid should automatically divide the aggregate_speed_limit and
max_aggregate_size values among the configured number of Squid
workers.
I have not synced with last v5 yet: this patch applies to v4 r14793.
To speed up the process and initiate the discussion I am posting with
"preview" flag and meanwhile start merging with the current v5 version.
Thanks. Sorry I didn't get a chance to look at it yet. That should now
happen in the next few days.
Can you please add to the above an explanation of why this is being
added instead of improving ways to send TOS/NFMARK to feed the system
QoS bandwidth controls. We really should not be re-inventing QoS in
Squid (for about the third time AFAICT).
Amos
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
