现在，有人告诉我，具有入站 QoS 策略的路由器能够通过丢弃 ACK 来利用 TCP 拥塞避免机制，以便对入站流量进行速率调整。我在实践中从未见过这样做过，或者至少从未见过它起作用；这是真的吗？如果是这样，它有效吗？在拥塞算法开始减慢速度之前，每次新连接加速时，难道不会导致大量丢包吗？

我对此表示怀疑，当然对于队列来说，因为它们相对 TCP 友好。一些路由器可能已经尝试过这种策略来构建 tcp 友好的监管器，但我怀疑这是否是一个不错的解决方案。首先，ACK 可以伴随数据，所以你不能真的只丢弃'ACK'。其次，即使对于某些流来说这是真的，为什么你只在返回路径上丢弃？对于 TCP 流，简单地丢弃原始数据同样好，这样您就不会浪费边缘路由器和接收器之间的带宽和处理资源。

更有可能的是采用 H-QoS，在电路/用户级别有一个 30Mbps 的队列/调度器，然后多个较小层的队列加入其中。一个简单的设置可以是让 TCP 和 UDP 进入两个不同的 25Mbps 队列，因此 TCP 仍然可以为 UDP 保留 5Mbps，反之亦然。当然，存在更复杂的变化。

另外，考虑到ssthresh它通常会很快适应您的可用带宽（此处为 30Mbps - 您的语音带宽）。虽然 TCP 不会停止增加，但它只会cwnd在ssthresh之后缓慢增加，并且在达到拥塞时只会轻微干扰您的语音流。但是，在 TCP 连接开始时，在 ssthresh 适应实际值之前，这可能会严重干扰您的语音流（尽管很快）。最后，虽然它可能只适用于少数 TCP 流，但当有人启动数百个 TCP 连接（例如 P2P 应用程序）时，它会变得更加困难。all ssthreshandcwnd值不太可能（快速）稳定以保证公平，如果这些连接非常不稳定（P2P 通常就是这种情况），则更是如此。

此外，在丢弃旁边注意到饱和连接也会对您的抖动产生负面影响，这有时可能与一些数据包丢失一样有问题（甚至更糟）。

然而，除此之外，如果使用该电路的流量主要是 UDP 呢？如果对大量 UDP 数据的请求被发送到服务器，它自然会尽可能快地发送数据，淹没队列并导致语音数据包丢失 - 但也许我对这种情况反应过度。如今，UDP 是否用于任何高吞吐量的互联网技术？

你 100% 正确，UDP 没有内置公平性。许多实时多媒体应用程序（voip、视频会议等）仍然使用 UDP。隧道（例如 VPN）通常也使用 UDP 来避免 TCP-in-TCP 重传计时器冲突。所以是的，您当然可以在连接上拥有相当多的高吞吐量 UDP 流量。

更具体地说，您是否曾经亲眼见过一种 QoS 方法，它可以让 VoIP 在没有 ISP 提供的 QoS 的情况下在频繁饱和的互联网连接上正常工作而不会出现持续的质量问题？您是否听说过 DSL 或电缆提供商为此类应用实施边缘路由器 QoS？我只听说过它作为 MPLS 产品的一部分提供，如果有人想要下游 QoS，这几乎是必需的吗？

好吧，这里的问题当然是许多现代互联网连接是否经常饱和。根据我的经验，固定连接的可用带宽通常超过平均使用量。总是有例外，但通常大部分人都有大量的 BW，它可能仍然在某处饱和，但在您的直接访问电路上并不常见。但是，您可能会在移动访问中更频繁地遇到它，因为这是一种相对低带宽、低可靠性的共享媒体。目前 4G 有很大帮助，但由于移动 BW 的使用量仍在大幅增长，因此只能持续这么长时间。

是的，我听说提供商为多媒体应用程序实施 QoS。对于哪些应用程序可能因提供商而异。假设他们只是将流量限定为 BE，除非有充分的理由不这样做。但有些人可能会无动于衷地优先考虑 SIP/RTP。

MPLS 肯定不是 QoS 的必要条件，今天任何体面的 BNG 也包括相当重要的 QoS 选项。