如果我不设置任何流量整形，Linux 如何在进程之间分配（传出）带宽？
我的具体情况是，我在云虚拟机上运行 30 个相同的进程，每个进程基本上都是尽可能快地通过网络 (TCP) 发送数据。它们加起来似乎达到了我预期的总传出带宽。但是，有些进程比其他进程完成得快得多，并且消耗的带宽也多得多（最多多 3 倍）。一旦快速进程完成，其余进程就会加速并使用更多带宽。
Linux 如何决定每个进程应该获得多少带宽？
答案1
像大多数性能问题一样，它很复杂。每个任务获得多少带宽是网络堆栈不同层上许多事物之间复杂的交互。即使没有整形。以下是一份不完整的清单：
- CPU 调度程序，用于确定何时可以使用 CPU 执行任务（以及驱动程序中断处理程序）
- 任务获取数据的速度有多快，可能受到瓶颈或争用的限制
- 使用哪种排队规则，本质上是数据包调度程序
- 驱动程序详细信息，例如硬件 TX 队列的数量以及它们如何选择流
- TCP 协议行为，如果一个流碰巧遇到拥塞控制，则在带宽有限的情况下，它可能保持缓慢
- 对于接收流量的远程系统，上述所有考虑
- 如果你的所有连接不是发往同一个收件人，则其他结束可能比你的结尾
其中许多优化并非针对带宽“公平性”，而是其他标准。TCP 拥塞控制宁愿有一点吞吐量，也不愿遭受拥塞崩溃。
别忘了，你大概在任何给定时间都不是网络中唯一的一个 - 所以您还需要考虑“这里”和“那里”之间的路由器、交换机等。
如果这不仅仅是好奇的话，那么尽快解决的办法就是获得更多带宽。
或者，执行 QoS、整形或应用程序限制可以设置配额以实现更好的整体行为，无论“更好”意味着什么。但这不再是尽可能快，您可以根据策略选择赢家和输家。
答案2
您是否注意到，在一条拥挤但不完全堵塞的多车道高速公路上，有些汽车和车道实际上会暂时比其他汽车和车道更快？没有人明确控制汽车流量并为这些汽车分配“带宽”，同样，Linux 也没有明确在进程之间分配带宽。
您看到的主要是各个 TCP 连接之间的 TCP 流和拥塞控制的交互。如果共享资源稀缺，当多个代理争夺其中一些资源时，就会出现暂时的赢家和输家。
答案3
很大程度上取决于“nice”因素（可以为每个进程设置和修改）和当前正在运行的所有其他进程的“nice”因素，以及可用的 CPU 数量和“前”总线、“后”总线、数据总线等的速度