可以根据 tcp 的拥塞控制机制来控制每个用户所占用的服务器的带宽么

可以，我们公司就是，要不控制，人一多直接把光猫带宽挤爆。

以前是随机丢包，对 UDP 限速效果好，但是对 TCP 限速效果很差，会不稳定。

后来改成了修改 TCP 的 window size 窗口值，一下子就好多了。

动态调整带宽可以用 tc

实际写代码测试了下，第一种可以控制服务端的上传流量 只不过没有直接用程序控制平稳

1. 不清楚你的使用场景，从不信任客户端的角度上说，单独在客户端做限速是可以被轻易绕过的。考虑一下变速齿轮，客户端获取到的系统时间是不可信的。

2. 看你的描述，应该是服务器出口流量分配的策略。比较 naive 的实现有可能在用户不饱和的时候难以有效利用带宽。

3. 限速模块尽量与主逻辑解耦，可以把限速委托给系统或者平台，比如 tc 配合防火墙，或者前置反代等等。主要是界定限速的目标是产品意义上的用户，还是软件意义上的客户端，限制来源可以有包级别，链接级别以及 session 级别等等。

4. 比较简单的限速策略容易在客户端和服务器端之间产生尖峰流量（锯齿状），不适合流媒体等场景。需要平滑速率曲线需要的不是限速（ throttling ）而是流量整形（ traffic shaping ）。

现在 Linux 内核基本都自带华为 cake 队列，用 cake 队列平均限速很简单。设置一个总带宽，然后 cake 会尽量给每个客户端平均速率。比如总带宽 1000M 10 个用户平均每人 100M 100 个用户平均每人 10M 。

看看这个

https://x.com/plantegg/status/1654081183985147906

通过非常巧妙的少量丢包或乱序（图一中粗线下挂的小黑点），并控制 RTT ，让 Linux TCP sender 的 cwnd 钳制在几十 KB ，RTT 在 10ms ，进而限制吞吐量在几千 KB/s

@geekvcn cake 并不是平均带宽，cake 目的是低延迟，保证带宽公平

CAKE's approach is to maintain fairness, minimize bufferbloat, and manage different types of traffic with minimal configuration and tuning. This is achieved through various techniques including flow isolation, bandwidth shaping, and prioritization of small packets.

这个当然可以做，如果你熟悉 tc 的话，按照来源 ip 限流。忘了代码贴在这个站哪个贴里。

当年刺激主要来源于
1.ibm 的广告，1 个不起眼的文件导致流量损失。
2.好心网友提供固件下载，结果有人用脚本循环下载。结果一会儿的事情下爆流量。

所以前面是 quota 限制总流量
后面是 tc 限制用户平均访问流量