Shadowsocks 速率调节：算法原理与实战优化

• 为什么要对 Shadowsocks 流量做速率调节
• 速率调节的几个层级与关注点
• 常见算法与原理解析
• 令牌桶（Token Bucket）
• 漏桶（Leaky Bucket）
• 队列调度（fq, fq_codel, cake）
• 在 Shadowsocks 场景下如何组合这些算法
• 调优思路与实践步骤
• 参数选择的经验规则
• 实际案例：多用户 VPS 上的常见误区
• 性能监控与调试工具
• 权衡与展望

为什么要对 Shadowsocks 流量做速率调节

当多用户共用一台 Shadowsocks 服务器时，未受控的吞吐会导致链路拥塞、延迟飙升和不公平的带宽分配。简单粗暴地限速虽然能保住总体带宽，但会牺牲交互式应用体验（例如网页加载、视频、SSH）。因此需要一种既能保障总体带宽利用率，又能兼顾低延迟和流量公平的速率调节方案。

速率调节的几个层级与关注点

在实际部署中，速率调节可以放在不同层级，每层有各自优缺点：

• 应用层（Shadowsocks 进程）：可以按用户、端口或账户细粒度限速，易于与认证、计费系统集成。但受进程性能和加密开销限制，难以精细控制低层队列行为。
• 内核网络层（tc、iptables）：可实现精确的队列管理（qdisc）、整形（shaping）与调度（scheduling），适合控制延迟与公平性，性能开销低。
• 链路/物理层（ISP 路由器）：能直接控制出站总带宽，适合总量把控，但对单用户或单连接的细粒度控制能力有限。

常见算法与原理解析

令牌桶（Token Bucket）

令牌桶允许突发（burst）传输。桶以固定速率生成令牌，传输前消耗令牌，若令牌不足则等待或丢包。适合需要允许瞬时突发的场景，例如网页请求。

漏桶（Leaky Bucket）

漏桶实现恒定输出速率，能平滑流量但会抹掉突发特性，适合需要严格带宽形状（shaping）的场景，不利于交互延迟。

队列调度（fq, fq_codel, cake）

Linux 内核提供的 fq/fq_codel/cake 等 qdisc 侧重解决 bufferbloat 与公平性：将流量拆成多个流队列，轮询调度，结合延迟感知丢包（codel）在拥塞前主动丢弃导致延迟的包，从而保持低延迟和高吞吐。

在 Shadowsocks 场景下如何组合这些算法

实战常见做法是把应用层的用户分组信息传递到内核层进行调度：Shadowsocks 负责鉴别与流量标签（例如使用不同端口或 mark），内核 tc 根据 mark 应用不同的 qdisc/带宽策略。推荐组合：

• 总体出站链路使用 HTB/Token Bucket 做总量整形（保证不会超链路峰值）；
• 在每个类（class）上挂载 fq_codel 或 cake，提供 per-flow 公平与低延迟特性；
• 对关键交互型用户或端口设置较高的优先级与较小的延迟目标，对大流量备份/下载类给出较低优先级。

调优思路与实践步骤

下面给出一套可复用的调优流程，便于在不同链路条件下快速定位最优参数（数值以示例说明，需根据实际链路调整）：

1) 采集基线
   - 使用 ping/iperf/bmon 等工具测量带宽、RTT 和抖动。
   - 记录峰值带宽与空闲带宽。

2) 确定目标
   - 总带宽上限（例如 200 Mbps）。
   - 交互延迟目标（例如 RTT < 50 ms）。
   - 最大允许突发（例如 2 MB）。

3) 配置总量整形
   - 将总带宽设置为链路的 95% 峰值，以避免拥塞。

4) 启用 fq_codel/cake
   - 每个用户/端口设置独立队列，防止“流量霸占”。

5) 设置公平与优先级
   - 给低速交互流小队列带宽保证，高吞吐下载流使用剩余带宽。

6) 验证与迭代
   - 在高并发和单大文件下载场景下测试，关注延迟和带宽利用率。
   - 调整 burst/quantum/target 参数，平衡吞吐与延迟。

参数选择的经验规则

• 带宽设置：总整形速率略低于物理链路峰值（90–98%），避免因瞬时突发触发下游拥塞。
• Burst 值：允许短时间突发以提升页面加载体验，但不要超过链路 RTT × 带宽 的量级。
• fq_codel 的 target/interval：target 决定延迟目标（默认 5–20 ms），interval 决定检测窗口，低延迟链路可将 target 调小。
• 分配策略：优先级队列用于小包延迟敏感流（DNS、TLS 握手），令牌桶用于大流量整形。

实际案例：多用户 VPS 上的常见误区

案例一：直接在 Shadowsocks 进程里强制限速。问题是 CPU 在流量高峰时成为瓶颈，限速不均匀，且难以解决 bufferbloat。

案例二：只在路由器上开限速而不做 per-flow 调度。结果是某条大流占满队列，其他小流延迟剧增。解决方法是引入 fq_codel 或 cake 做流级别调度。

性能监控与调试工具

日常维护推荐工具：ping、mtr、iperf3、bmon、iftop、tc 的统计、netstat/tcpdump。通过这些工具可以区分是链路拥塞、TCP 窗口限制还是应用端瓶颈。

权衡与展望

理想的速率调节既能保证总体带宽利用率，又能让交互式应用保持低延迟。当前最佳实践是“内核 qdisc + 应用标记”的组合：Shadowsocks 做鉴别与标记，内核做精细调度。随着 BBRv2、ECN 与智能队列调度的发展，未来在延迟控制和公平性之间的折中会更少，用户体验也会更好。