本文介绍在 Linux 环境下，无需改动 Go 应用代码，即可精准限制其 HTTPS 上传带宽（如 2500 KB/s）的实践方案，重点解析基于 cgroups v2 的进程级限速与容器化 tc 限流两种可靠方法，并指出常见误区。
本文介绍在 linux 环境下，无需改动 go 应用代码，即可精准限制其 https 上传带宽（如 2500 kb/s）的实践方案，重点解析基于 cgroups v2 的进程级限速与容器化 `tc` 限流两种可靠方法，并指出常见误区。
在 OpenStack 对象存储（如 Swift）上传场景中，Go 工具常因高吞吐占用全部出口带宽，影响同机其他服务或用户。用户希望实现进程粒度、单向（上传）、不影响物理网卡全局性能的限速，且拒绝修改源码——这排除了 flowrate 等库内写入限速（因其依赖底层 IO 实时性，而 swift.ObjectCreateFile.Write() 实际为缓冲写入，关闭时才触发传输），也绕开了 trickle 对静态链接 Go 二进制的失效问题（Go 默认静态链接，trickle 依赖 LD_PRELOAD 动态劫持 send()/write()，对 Go 不生效）。
✅ 推荐方案一：cgroups v2 进程级网络限速（最轻量、最精准）
Linux 内核 5.13+ 原生支持通过 cgroups v2 的 io.max 和 net_cls（需启用 CONFIG_NET_CLS_CGROUP）实现进程级带宽控制。但更通用、零依赖的方式是结合 tc + cgroup 分类器：
# 1. 创建 cgroup v2 控制组（假设使用 systemd） sudo mkdir -p /sys/fs/cgroup/upload-limiter echo $$ | sudo tee /sys/fs/cgroup/upload-limiter/cgroup.procs # 将当前 shell 加入（后续 exec 启动的 Go 进程自动继承） # 2. 使用 tc 配合 cls_cgroup 分类器（需内核支持） sudo tc qdisc add dev lo root handle 1: htb default 30 sudo tc class add dev lo parent 1: classid 1:1 htb rate 2500kbit ceil 2500kbit sudo tc filter add dev lo parent 1: protocol ip u32 match ip src 127.0.0.1 flowid 1:1 # 仅限本地回环测试
⚠️ 注意：tc 本身不直接识别进程，但可通过 cgroup 标记流量。生产环境推荐使用 cgroups v2 + tc filter with match cgroup（需较新内核）：
# 启用 cgroup 匹配（要求内核 >= 5.16） sudo tc filter add dev eth0 parent 1: protocol ip prio 1 cgroup match 0x00010001 flowid 1:1 # 其中 0x00010001 是 /sys/fs/cgroup/upload-limiter/cgroup.events 中的 id（需解析）
更实用的做法是：启动 Go 程序前，将其置于专用 cgroup，并用 tc 对该 cgroup 出口流量限速。完整脚本如下：
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
#!/bin/bash CGROUP_PATH="/sys/fs/cgroup/upload-limit" UPLOAD_RATE="2500kbit" # 2500 KB/s = 20000 kbit/s → 注意单位换算！ INTERFACE="eth0" # 创建并配置 cgroup sudo mkdir -p "$CGROUP_PATH" echo "20000000" | sudo tee "$CGROUP_PATH/net_cls.classid" # 0x01388000 (hex) → 十进制 20000000 # 配置 tc（HTB 队列） sudo tc qdisc replace dev "$INTERFACE" root handle 1: htb default 30 sudo tc class add dev "$INTERFACE" parent 1: classid 1:1 htb rate "$UPLOAD_RATE" ceil "$UPLOAD_RATE" sudo tc filter add dev "$INTERFACE" parent 1: protocol ip prio 1 handle 0x01388000 fw flowid 1:1 # 启动 Go 程序（自动继承 cgroup） sudo sh -c "echo \$\$ > $CGROUP_PATH/cgroup.procs && ./your-go-upload-binary"
✅ 优势：零侵入、内核级、精确到进程、不影响其他进程或网卡全局性能。
⚠️ 注意：2500 KB/s = 20,000 kbit/s（1 Byte = 8 bits），务必换算正确；net_cls子系统需在内核编译时启用（Ubuntu 22.04+ 默认开启）。
✅ 推荐方案二：Docker 容器 + tc 网络限速（兼容性最强）
若系统内核较旧或权限受限，Docker 是最稳妥的沙箱方案。关键在于不在宿主机 tc，而在容器内部对 eth0 限速（避免影响宿主机）：
# Dockerfile.upload
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y iproute2 && rm -rf /var/lib/apt/lists/*
COPY your-go-upload-binary /app/
WORKDIR /app
# 启动时自动限速并运行
CMD tc qdisc add dev eth0 root tbf rate 20000kbit burst 32kbit latency 400ms && \
./your-go-upload-binary构建并运行（指定网络模式为 bridge，确保容器有独立网络命名空间）：
docker build -t upload-limited . docker run --network host -it upload-limited # 或使用 --network bridge（需额外 --cap-add=NET_ADMIN）
✅ 优势：完全隔离、全发行版兼容、无需内核模块、可复用 CI/CD 流程。
⚠️ 注意：必须添加--cap-add=NET_ADMIN权限（或使用--privileged），否则tc命令失败。
❌ 方案辨析：为什么其他方法不推荐？
iptables+tc直接匹配端口/IP？
可行但脆弱：OpenStack Swift 上传可能复用连接、动态端口，且无法区分同一端口下的不同进程流量，易误伤其他服务。trickle/wondershaper？
对 Go 静态链接二进制无效（trickle依赖LD_PRELOAD，Go 不加载共享库）；wondershaper作用于整张网卡，违反“不影响其他用户”前提。应用层限速（如
io.LimitReader）？
违反“不改源码”要求，且如问题所述，swiftSDK 缓冲机制导致限速失效。
总结：选择即刻可用的方案
| 场景 | 推荐方案 | 关键命令 |
|---|---|---|
| 现代 Ubuntu 22.04+/CentOS 9+，追求极致轻量 | cgroups v2 + tc 分类器 |
mkdir /sys/fs/cgroup/xxx && echo $PID > cgroup.procs && tc filter ... cgroup |
| 老旧系统、CI/CD 环境、需快速验证 | Docker + tc in container |
docker run --cap-add=NET_ADMIN ... |
| 临时调试（单次上传） | timeout 30s tc qdisc add ... && ./binary & wait |
结合 timeout 防止规则残留 |
最终，无论采用哪种方式，请始终用 iftop -P https 或 nethogs 实时验证上传速率是否稳定在目标值（2500 KB/s），并确认宿主机其他进程网络不受干扰——这才是外部限速的本质目标。
