你的一个问题中至少有两个问题:)

在问题上“投入更多带宽”并不能解决任何问题，它只是隐藏了问题。在 IP 网络中，您应该始终准备基线 QoS 架构，以保证关键流量的交付并管理不同类别流量的其他流量参数（如抖动或延迟）。您可以查看 NANOG 演示档案，以获取在此类讨论中产生的大量材料，通常的结果是“是的，也许我们应该做 QoS”。

传统上，QoS 被认为是“很难做对的事情”，因为 IP 网络的 PHB 模型确实非常复杂，要正确规划和实施。从历史上看，它通常还与特定的硬件要求、体系结构和配置复杂性有关，这些都无济于事。但是当您查看传统 SP 及其网络时 - 他们通常实施至少 3-4 类流量和 QoS 策略来管理其网络内的流量。在过去几年中，传统的认证测试往往从测试 4 类和队列转移到传输网络的 8-16 类。

OTOH，网络中没有任何 QoS 通常也意味着那些说“不需要 QoS，我没有它，一切正常”的人没有实际手段来监控网络的行为方式以及实际环境应用程序的用途他们自己的使用。TCP 对网络条件的适应性很强，有时问题用“肉眼”是看不出来的，但当我们深入挖掘细节和比特流时，问题就会变得非常明显。

至于你的问题的第二部分 - 除了有足够深的缓冲区来容纳它们之外，没有什么可以帮助你对抗微爆。如果您倾向于简化并抛出具有足够快的内存的数据包缓冲区以实际处理微突发（这既不简单又便宜），这几乎会立即导致诸如缓冲区膨胀和路径上的额外延迟之类的事情。不幸的是，QoS（至少——在通常的网络设备工具集中可用的机制）并不能帮助“控制”微爆。然而，好消息是您会发现微爆通常只在 HPC 和一般的 DC 环境中是危险的或具有破坏​​性的，而不是在典型的传输网络中。

QoS 在拥塞时采取行动。所以，是的，您的团队成员说 50% 到 70% 使用的链接不需要 QoS 时可能是对的。

首先，让我们考虑每秒 1 位的理论链接，时钟速率为 1 秒（意味着将有 1 条线传输 1 或 0 持续 1 秒，因为如果信号更短）：直到我们需要发送的流量达到每秒 1 位，我们才将该位放入线路中。不需要 QoS。

但是如果我们每秒从更快的链路（例如 LAN）接收 2 个比特，这 2 个比特需要转发到 1bit/s 链路，因此我们需要排队或丢弃收到的 2 个数据包中的 1 个，同时转发其他 1 位。这里应该使用 QoS 来决定必须首先转发哪个位，以及我们应该如何处理另一个位（基本上，丢弃或排队）。

其次，在现实世界中，我们拥有具有固定带宽并且只能在该带宽下传输的链路；例如，以太网 100M 全双工只能以 100Mbps 的速度发送和接收数据。如果我们通过 100M 以太网链路连接到 ISP，但我们为 50Mbps 付费，则我们的链路必须以 100Mbps 的速度发送帧/数据包。为了达到 50Mbps，我们需要做一些事情，比如以 100Mbps 的速度传输半秒，然后再等半秒不​​传输任何东西，在 1 秒的时间内获得 50Mbps 的平均值。在此示例中，如果我们在前 1 秒内没有传输任何内容，则突发可能允许以 100Mbps 的速度传输整整 1 秒。

考虑到这些概念，我们可以理解使用 50% 的链路，没有任何超出链路容量的突发，永远不会拥塞，也不会使用 QoS。另一方面，在现实世界中，很少会花费大量资金购买从未被充分利用的 WAN 链接（但它可能不在 LAN 中）；此外，流量高峰通常以不可预见的方式发生。因此，在一个好的计划中应该考虑拥塞时刻，以便在牺牲非关键流量的同时允许关键流量的流动。

无论如何，QoS 相当复杂，如果您有兴趣，我写了这个专栏：https : //www.matteo.site/blog/post/quality-of-service/

QoS 很复杂。它需要在您的网络的整个边缘进行绝对正确的标记，并在您的网络内部进行正确的信任/排队以保证操作。此外，在您的网络中运行的软件/硬件需要不同的语法，并且会影响 QoS 功能和操作。这并不是说当您无法增加链路容量时，QoS 不是有效的解决方案。对于抖动敏感的基于 SLA 的流量（SIP 中继/托管 VoIP），除了“标准”队列之外，通常还值得配置一个优先级队列。

增加带宽解决了容量不足的长期问题，而无需配置和监控 QoS 性能所涉及的复杂性，然后当链路在比预期短的时间内过饱和时仍然需要增加带宽。