🔗 Feature: Client Bandwidth Limits

• 目标: 控制Squid到客户端的带宽使用，基于客户端IP级别，适用于400万个IP地址（/10网络）。
• 状态：完成
• 版本: 3.2
• 开发者: AlexRousskov, ChristosTsantilas

🔗 用例

在移动环境中，Squid需要限制每个用户可用的Squid到客户端的带宽，用户通过其IP地址标识。IP地址池可能高达/10网络（400万个唯一IP地址）。

NP: 对于IPv6网络，范围可能高达/32，并带有单个终端站点解析。这相当于/0，即整个IPv4空间，具有单IP解析。对于单个主机解析，需要在其之上额外添加一个64位长的主机标识符。相关：bug 2144

🔗 现有工具

应尽可能考虑并重用一些现有机制

• 现有的Squid 延迟池限制的是服务器到Squid的带宽，而我们需要的是Squid到客户端的整形。也没有一个池类能够容纳400万个唯一IP地址。
• 应研究Squid2实验性的客户端带宽限制代码。其中部分可能可重用。根据Adrian Chad的说法，实验性的Squid2代码并未经过广泛测试，并且不满足项目的所有要求。
• Linux iptables本身也无法工作，因为它们基于连接而不是源IP进行操作：多个连接可能无法共享同一个桶，一旦连接断开，带宽使用历史也就消失了。

🔗 详细信息

这项工作基于现有的服务器到Squid延迟池架构以及一个处理客户端限制的实验性Squid2特性。新池的整体架构和配置预计与现有的延迟池特性类似，只是可能需要开发特殊代码来支持单个客户端池的大地址空间。如果情况允许，也可以考虑替代设计。

所有Squid流量整形工具都在应用层工作。Squid看不到、丢弃或延迟单个TCP/IP数据包。如果客户端的带宽桶已空，它只会停止向该客户端写入HTTP有效载荷，直到带宽桶重新注满。Squid通过向客户端发送数据来消耗桶。管理员指定桶的重新注满速率（每秒字节数），以及可选的最大桶大小（以允许初始流量突发）。

带宽使用信息不是持久的。例如，所有带宽桶在Squid重启和重新配置时都会重新注满。

客户端由客户端HTTP/TCP连接的IPv4源地址标识。来自同一客户端ID的所有传输都将消耗同一个桶，无论该客户端与Squid之间有多少个HTTP/TCP连接。新特性限制了每个客户端ID可用的近似下载带宽。

类别：功能

导航：站点搜索，站点页面，类别，🔼 向上