问题：客户可能会经历 10 秒、30 秒甚至更长时间的总丢包。这导致提供价格的 TCP 连接停止，从而使网站无用。从数据中心到对等点的所有连接都已正确调整大小，并且有备用容量。

有人断言，这在公共互联网中很常见。然而，我的直觉说不，我作为消费者的所有经验都与此相反，但是我没有确凿的事实可以借鉴。

你的直觉是正确的。作为一个在过去 20 年里建立网络的人，你永远不应该盲目地接受有线网络上持续的重大丢包，也不要让任何设备供应商或 ISP 告诉你其他情况。10 到 30 秒的定期中断是不可接受的；如果你有选择，也许你可以让你的上游知道你将开始考虑你的选择，除非他们认真对待这个问题。可悲的现实是带宽不是免费的，ISP 的利润率通常很低，一些提供商会尽其所能来省钱，即使这意味着客户不满意（听起来很疯狂）。

假设我正在发送基本的 TCP 流量，对于公共 Internet 服务（您预计偶尔会因超额订阅而造成一些损失），我将接受的最大丢包率是 24 小时内的 0.10%，任何情况下都不会超过 0.50%。 5 分钟时间^{注 1}。

在我们的有线公司网络中，我容忍 0.0% 的数据包丢失^{注 2}。只要不出现数据包丢失，企业网络工程师在发现数据包丢失时就应该升级他们的电路（或 LAN）。

假设丢包是由拥塞引起的，当路由变得拥塞时，持有该路由的路由器肯定会选择备用路由，而且这样做的速度会比 10 秒更快？

默认情况下，OSPF 或 BGP 等路由协议不会根据拥塞重新路由，除非拥塞使它们丢弃路由协议数据包的时间足够长以宣布邻居关闭（默认计时器为 40 秒到 120 秒）；这里的棘手问题是，在许多供应商设备中，路由协议数据包的优先级高于其他流量。这意味着在路由协议丢弃之前，电路必须在整个间隔内真正拥塞。

最后，当路线拥堵时，是否有任何可用的反馈？

有一些技术工具可以管理您为给定路线选择的上游供应商（假设您有多个上游）；将Cisco 的 PfR视为解决此问题的一种可能方法。

^{注 1}：虽然我认为 5 分钟内 0.5% 的数据包丢失足以引起注意，但我不会对此有什么大不了的......这个阈值只是一个数字，您可以承认可能开始出现明显的 TCP性能问题；0.5% 的损失可能不会引起您的注意。但是，如果数据包丢失既正常又严重到足以引起注意（例如您的情况），请坚持让您的提供商解决问题（只要丢失在他们的网络中）。

^{注 2}：根据我的经验，当多个用户在此交换机上时，某些交换机根本无法以零丢包率运行。此时您有选择：A) 铲除所有现有交换机（如果丢包问题足够大），B) 等待供应商的补丁来解决问题，或 C) 接受丢包作为“功能” ”的开关。举例来说，我曾在Cisco 3850 的共享缓冲区架构中面临过这种选择。

10-30 秒的总丢包率肯定是由互联网上某处丢失的数据包以外的其他因素引起的。丢失的 tcp 数据包通常会在约 10-100 毫秒内产生重传。拥塞的链接不会在如此长的时间内阻塞所有流量。

拥塞的链路通常不会让路由器选择备用路由，除非链路状态丢失，或者路由器与链路另一端的相邻路由器失去连接，从而迫使路由器重建其路由表。

这是否同时发生在您的所有客户身上？如果是这样，您可能有其他类型的路由问题。我遇到过 ospf 问题，其中 ip-routes 被错误配置的设备“劫持”，以类似的方式中断流量。

我认为您作为“最终用户”不会在路由器链接拥塞时收到任何形式的反馈。您必须调试数据包流并解释 tcp 重传、tcp 窗口大小的变化等。然而，路由器和网络协议有许多方法来处理和缓解网络拥塞。有关详细信息：http : //en.wikipedia.org/wiki/Network_congestion