我正在尝试排除网络连接故障。连接是无线的，大部分情况下运行良好。（从计算机到路由器的物理连接，从路由器到无线 ISP 屋顶天线/碟形天线的物理连接。）但是，有时带宽似乎比正常情况慢得多，并且各种操作（例如将文件上传到 gmail）会失败。
我决定ping google.com -t使用 Windows 机器 ping 一个可靠的服务器，我看到 ping 的响应基本上很快，但偶尔也会出现间隙，就好像连接完全不存在一样。
这是什么意思？我该如何进一步诊断问题？
答案1
对于 TCP 来说，0.1％ 的数据包丢失已经是糟糕的边缘。1％ 的数据包丢失已经很多了。10％ 则是无法忍受的。
在这个例子中，您接近 12%。您当然需要先解决数据包丢失问题，然后再担心任何剩余的吞吐量问题。
打开两个窗口，一个 ping 你的 Wi-Fi 家庭网关 AP 的私有端 IP 地址，另一个 ping 你的屋顶 WISP 链路远端的 IP 地址（即你的 ISP 的某个 IP 地址）。
如果两个网络同时掉线，则表明 Wi-Fi 有问题。如果只有 WISP 网络掉线，则表明 WISP 连接有问题。
检查您的 WISP 使用的频率范围，并确保您的 Wi-Fi 家庭网关 AP 未使用相同的频率范围。例如，我帮助过的一个人有一个屋顶 WISP，它使用 5.7~5.8 GHz 设备，与 802.11a/n 5GHz 频段的高端重叠（Wi-Fi 信道 149-165），并且这个人的同步双频 Wi-Fi AP 的 5GHz 无线电设置为信道 149。当他将其更改为信道 36 时，他的问题就消失了。
如果问题出在您屋顶的 WISP 链路上，并且您可以确认自己的 Wi-Fi 网络不会干扰该链路，那么您必须联系 WISP 让他们修复链路。如果他们无法为您提供低于千分之一的数据包丢失率，请探索其他宽带互联网替代方案。
答案2
大多数 ISP 不会对 3-5% 的损失采取任何措施。如果您有商业线路，您可以抱怨 3% 或更高。如果您有住宅连接，除非您能证明 5% 的损失恒定，并且只在他们的网络上，否则您不会从 ISP 那里得到太多研究。
第一步是直接连接。将计算机直接连接到调制解调器，然后重试。如果仍然有丢失，则将调制解调器直接连接到 NID，然后重试。此时，如果仍然有丢失，请尝试致电您的 ISP，他们无论如何都会让您这样做，因此您最好在致电之前先这样做。如果您想进行进一步的测试，您可以在 *nix 机器上使用 MTR，或者在 Windows 机器上使用 winmtr 或 pathping 来获取不同跳数的丢失。这将让您的 ISP 知道他们是否能够控制该网络。如果它在他们的主干网上，他们可以采取一些措施。如果问题发生在他们的网络之外，那么他们能做的最好的事情就是尝试重新路由您（您可能必须推到第 2 层或第 3 层才能找到知道如何执行此操作的人）。
如果直接连接到调制解调器后没有看到丢失，则问题出在您的网络上。尝试不同的无线网卡、不同的路由器，尝试有线连接到路由器，尝试移除/替换所有变量，直到您注意到差异，然后您就找到了罪魁祸首。
答案3
据我所见，大多数 ping 都会收到回复，并且 RTT 相对较好。
您看到的超时可能是由于数据包丢失造成的（是的，存在数据包丢失，主要是在无线链路中）。
TCP 协议不能很好地处理数据包丢失。数据包丢失是确定网络拥塞的一种隐式方法。当检测到丢失的数据包时，TCP 协议的拥塞窗口会降低，这（简单地说）意味着带宽也会降低。
由于您很可能使用 TCP 来执行您所提到的任务（上传文件和发送电子邮件），因此您看到的数据包丢失可以解释带宽低的原因。
为了进一步诊断问题，我将进行带宽测试，主要比较 UDP 和 TCP，因为 UDP 没有这种控制拥塞的机制。
我可能误解了这个问题，但至少如果我遇到了这个问题，我会从这个开始。另外，我并不是 TCP 方面的专家，不知道您遇到的数据包丢失率是否足以解释带宽低和操作失败的原因。
答案4
下一步是找出数据包丢失发生的位置。无线链路更容易导致数据包丢失，因为可能有其他信号处于同一频率。因此，看看您是否可以可靠地访问本地路由器（可能）和 ISP 网络上的某个主机（可能不行）会很有趣。
也许有某种方法可以获取无线链路的状态数据，如吞吐量和/或载波/噪声比。它还可能有助于查明此 ISP 的其他附近用户（使用另一个无线链路端点）是否遇到同样的问题。如果是这样，您所在区域可能存在本地噪声源。在这种情况下，您可能无能为力，只能通知您的 ISP，他们可以尝试优化链路或找到并关闭噪声源。