假设有一个网络在传输数据包时会出现很多超时错误。现在，超时可能是因为网络本身存在固有损耗（比如硬件差），也可能是由于网络高度拥塞，因此网络设备在其间丢失数据包，导致超时。现在，需要哪些关于正在传输的流量的额外统计数据（如丢失数据包错误等），以帮助我们了解超时是由于硬件差还是网络负载过大。请注意，我们只能访问网络中的一个节点（我们从中传输数据包），因此，我们无法了解网络上其他节点的负载。同样，我们也没有任何关于网络中使用的硬件的信息。我们只有统计数据。
网络节点只有关于其本地冲突域的硬件信息，在标准网络上，该域将是将主机连接到交换机的电缆。
TCP堆栈所知道的关于丢失数据包的所有信息都是，它没有接收到确认，因此需要重新发送，源和目的地之间的设备（例如交换机和路由器）没有机制告诉源存在问题。
在不访问任何其他节点的情况下，确定问题是否基于负载的唯一方法是运行一个测试，在网络上长时间发送一致的流量，如果每秒/分钟/小时的数据包重试次数保持不变，则表明存在硬件问题，如果丢失仅发生在流量高峰期，则问题可能与负载有关。当然，在这种情况下，错误配置的硬件问题只会在高流量时期显现出来，这将问题带回主要问题，即您需要从单个节点之外访问网络统计数据。
在实践中，地面网络路径上几乎所有的损失都是由于拥塞或防火墙造成的。由于比特错误而造成的损失极为罕见。即使在无线网络上，前向纠错也能处理大多数比特/媒体/传输错误。拥塞可能由许多不同的因素引起：任何给定的网络路径都会涉及数十个设备，如果其中任何一个设备过载一瞬间，数据包就会被丢弃。
区分拥塞引起的数据包丢失和媒体错误的唯一方法是，媒体错误的发生与负载无关。换句话说，无论您发送的是大量数据还是少量数据，丢失率都是相同的。
要测试这一点，您需要对路径上的负载进行一些控制，或者至少了解这些控制。由于您无法控制，并且您所掌握的唯一知识来自源节点观测，因此您所能做的最好的事情就是全天候、全周地采集测试样本（使用ping最简单），记录丢失率和延迟。这些应该可以让您了解路径何时相对空闲。如果即使路径（可能）空闲，丢失率仍然很高，则可能存在介质丢失问题。但同样，这种情况极为罕见。
作为背景，我写了几篇关于这个主题的文章：
- Loss、Latency和Speed，讨论您可以观察到的关于路径的统计数据及其含义
- 常见网络性能问题，讨论网络路径中最常见的组件以及它们如何影响性能（拥塞）