我在互联网上运行Linux路由器（更确切地说是OpenWRT），带宽非常有限，下游大约1 MBit / s，上游大约有十几kBit / s。
网上有几台机器可以做低带宽的东西，比如播放networking收音机或者发送测量数据。 其他机器偶尔会开始正常的软件更新下载。
每当一台机器开始下载，低带宽的东西变得不稳定。 我想stream量的带宽会减less，因为路由器上还有另外一个连接，尽pipe它可以很好地适应广域网。 这有点违背我的直觉，我想configuration路由器更公平地分配带宽。
“相当”我的意思是：
假设有1 MBit / s的下行带宽，使用64 kBit / s。 访问WAN的下一个客户端应至多获得（1 MBit-64 kBit）/ s的带宽。 当且仅当下行带宽全部用完时，各个连接的带宽应该降低，并且它应该被调整，使得连接与它们的大小成比例地被调节（越小越小）。
首先，我的理解是否正确？ 如果是这样，我能做些什么来影响路由器的带宽分配？ 注意：我不想要文献中通常推荐的内容，即将每个客户端的带宽限制为可用总带宽的一小部分。 我的网站上的广域网速度太慢，无法做到这一点。
你对这个问题的理解是正确的，但是你提出的解决scheme实施起来非常复杂。 “什么是客户？”的问题 和“什么是联系？” 上来，可能难以回答。
更典型的带宽限制策略是这样的：
VOIP可能使用超过192Kbit / sec，所以我们可以让它从“所有人”池中借用（反之亦然）。 当“每个人”池饱和时，就像我们上游链路真正饱和一样，开始丢弃数据包（例如，使用Random Early Detection （ 随机早期检测）来select丢弃受害者。
通常这是在UPSTREAMstream量上完成的。 下行stream量可以用相同的方式进行限制，但是不能避免下行stream量造成的链路饱和（数据包仍然必须到达防火墙才能做出下降决定，因此它们仍然沿着您的线路传播）是由于TCP协议感知到“链路饱和”拥塞并且远程侧退避其发送速率，直到丢包停止为止，随后是自然衰减的stream量猛增。
另外请注意，这并不能保证客户机的“公平性”，除非随机早期检测将随机丢弃数据包（随机性足够大，以至于不会总是客户机A在链接时丢弃数据包饱和的）。 你要指望的是，“随机”下降，自然会形成stream量，你不必担心一个客户饿死，而另一个客户端占用所有的带宽。
在你的特定情况下，一个开箱即用的解决scheme可能是限制可用于更新的带宽（可能这些来自已知的子网，所以限制这些），但是这仍然受到上面提到的警告的影响。
或者，如果您有可用的硬件，则可以从本地服务器（WSUS，本地适配器镜像等）分发更新 – 这样，您便可以在非工作时间将这些更新安排在本地，而无人使用您的networking，最终会为您节省大量带宽，为每台机器传输单个更新。
由于更新已经是本地的，所以当单独的客户端机器接收到它们时并不重要 – 它们不会出去上网，所以只要你没有饱和你的本地networking（非常困难！），不会遇到显着的性能问题。 当然，缺点是你需要投入时间和硬件来设置更新服务器。
不，现在没有好办法做到这一点。 基本的问题是，您的ISP决定将哪些数据包放在您的链接上，并且没有任何可用于做出该决定的信息。 简短而可悲的回答是，消费者的互联网接入并不是为了做到这一点。
有这个相当古老的脚本就是这样做的。 我已经使用了很多年了。
它在幕后非常复杂，但实际的用户configuration非常简单。
我的fork： https ： //github.com/kalmi/FairNAT （它有一些小的修复，允许它在最新版本的Linux上运行）
有一个openwrt脚本的版本，但它没有使用它。
（我不得不closuresTOS支持，因为它会导致一些站点（维基，imgur等）的随机TCP重置。这可能是由于在这个特定的上游ISP有些古怪，但我不知道。）