总结我家的网络最近延迟从 27 毫秒猛增至 600 毫秒。这种情况并不总是发生，而且似乎经常在晚上发生。我应该购买什么设备并进行哪些测试来推断原因？
设置
我家有 12Mb/800kb DSL。我住在山里，远离其他 Wi-Fi 源。过去（多年来）我可以 ping google.com 并获得约 27ms 的时间。如果网络或连接出现拥塞（iPhone 将所有照片与 iCloud 同步），ping 时间会跳到 2000-6000ms 范围内。但通常一切都很好。
然而，最近，网络有时会在几十分钟内保持在 600 毫秒左右。我找不到任何导致网络拥堵的设备。（可能存在，但我没有找到。）早上连接通常完全正常，晚上连接通常持续不佳（就在我们想在床上看节目的时候！）
在高延迟时间内，对网络上其他设备的 ping（我尝试过的一些）保持不变（始终 <2ms）。
失败且令人困惑的故障排除
我购买了所有新硬件（DSL 调制解调器、Wi-Fi 路由器、网络交换机）以排除此问题。问题仍然存在。以下是设置：
我尝试使用 DSL 调制解调器作为路由器 (PPPoE + DHCP + NAT)，并将 Wi-Fi 基站设置为桥接模式。我尝试将 DSL 调制解调器设置为透明桥接模式，并让第一个 Airport Extreme 处理 PPPoE、DHCP 和 NAT。问题仍然存在。
我已断开所有有线连接（仅留下 DSL 调制解调器和 Wi-Fi 基站）。问题仍然存在。
我只使用了 DSL 调制解调器（带 PPPoE）并使用了它自己的 Wi-Fi。问题仍然存在。我试图找到 Wi-Fi 上的所有旧平板电脑、手机、笔记本电脑并将它们关闭。问题仍然存在。我重命名了 Wi-Fi SSID 并为其设置了密码，通过 Wi-Fi 连接了一台 MacBook Pro 笔记本电脑。问题仍然存在。我通过 Wi-Fi 使用了另一台笔记本电脑。问题仍然存在。
我已通过以太网将笔记本电脑直接连接到调制解调器，调制解调器上的 Wi-Fi 已禁用，并且没有连接任何其他设备。问题消失了！（我认为……这个问题可能在我测试的三次中都没有出现。）
有一次，我只有一台通过以太网连接的笔记本电脑，我打开了调制解调器的 Wi-Fi问题就出现了。我一打开 Wi-Fi，Ping 延迟就立即上升，尽管我没有相信任何设备都通过 Wi-Fi 连接。
我用过互联网浏览器并且延迟时间长和噪音增加之间似乎没有任何关联。事实上，Wi-Fi 上的 SNR 一直很好。
请记住，当情况不好时，情况并不总是很糟糕。即使家里的所有设备都已打开并连接，有时延迟也会在几秒钟（或几分钟或几小时）内降至 30 毫秒左右，然后再次变糟。
下一步？
我思考iStumbler 向我表明该问题与 RF 问题无关。（也许我错了？）所以我认为这一定是网络上的真实流量。
Airport Extreme 基站不支持任何类型的 SNMP 日志记录。Actiontec C1000A 也不支持。我没有带监控端口的交换机，也没有集线器。我以前从未使用过 Wireshark。
但我愿意投入金钱和时间来解决这个问题
我应该买什么？我应该把它注入到我的网络中的哪里？我应该寻找什么？我如何才能观察网络上的每个数据包并建立直方图和图表来确定一个坏设备是否正在破坏所有人的状况？
编辑1：一切正常时的 DSL 统计信息
+-----------------+-------------+
| Connection | Status |
+-----------------+-------------+
| DSL Downstream: | 15.869 Mbps |
| DSL Upstream: | 0.896 Mbps |
+-----------------+-------------+
DSL 链路统计
+------------------------------+---------------------+
| Link Statistic | Status |
+------------------------------+---------------------+
| Broadband Mode Setting: | Auto Select |
| Broadband Mode Detected: | VDSL2 - 8A |
| DSL Link Uptime: | 0 Days, 10H:39M:57S |
| Retrains: | 1 |
| Retrains in Last 24 Hours: | 1 |
| Loss of Power Link Failures: | 0 |
| Loss of Signal Link Failure: | 0 |
| Loss of Margin Link Failure: | 0 |
| Link Train Errors: | 0 |
| Unavailable Seconds: | 23 |
| Estimated Loop Length: | 2250 |
| Uncanceled Echo: | N/A |
| Transport Mode: | PTM |
| Path Parameter: | 201 |
| Priority: | 0 |
| Service Type: | PTM-Tagged |
+------------------------------+---------------------+
DSL 电源
+--------------+-------------------------+------------------------+
| Levels | Downstream | Upstream |
+--------------+-------------------------+------------------------+
| SNR: | 16 dB | 10 dB |
| Attenuation: | (DS1)21.7, (DS2)58.8 dB | (US1)4.3, (US2)47.8 dB |
| Power: | 16.4 dBm | 7.8 dBm |
+--------------+-------------------------+------------------------+
DSL 传输
+----------------------+------------------+---------------+
| Transport | Downstream | Upstream |
+----------------------+------------------+---------------+
| Packets: | 1482864 | 1088249 |
| Error Packets: | 0 | 0 |
| 24 Hour Usage: | 1225940.68 Mbits | 2420.93 Mbits |
| Total Usage: | 1225940.68 Mbits | 2420.93 Mbits |
| 30 Minute Discarded: | 0 | 3930 |
+----------------------+------------------+---------------+
DSL 信道
+----------------+-------------+-------------+
| Channel | Near End | Far End |
+----------------+-------------+-------------+
| Channel Type: | Interleaved | Interleaved |
| CRC Errors: | 0 | 0 |
| 30 Minute CRC: | 0 | 0 |
| RS FEC: | 5873 | 29 |
| 30 Minute FEC: | 372 | 0 |
+----------------+-------------+-------------+
编辑2：DSLReports Bufferbloat 报告
在正常延迟期间运行速度测试表明问题发生在上传过程中
夜间和夜间的 Ping 时间
晚上 10:35 左右出现峰值，因为一台计算机开始上传到 Dropbox。
编辑3：ISP 技术支持说：
调制解调器接收到的信号比预期的要多。如果电缆不足以承载我们发送的负载，我们可以将其降低到 100%。为了测试这一点，我将降低信号 7 天，您可以观察浏览互联网是否更好。7 天后，我们的服务器将运行测试并再次增强您的信号。到那时，我们将有足够的数据来决定下一步该怎么做。
我们的服务器为您提供的服务超出了您的购买量。从技术上讲，这应该会使互联网速度更快，但如果客户观察到由流量引起的 ping 和延迟。我们可以将其调到购买的速度\信号，并观察客户场所的 DSL 线路是否能够承载负载。
实际/配置/购买速度
下行：15868/15872/12128Mbps
上行：896/896/896kbps
答案1
您报告的症状听起来像是缓冲区膨胀问题，即当链路拥塞时，路由器、DSL 调制解调器或 ISP 的 DSLAM 会缓冲过多数据包，从而导致高延迟。通常，TCP 会查找丢失的帧作为拥塞的证据，然后后退。但是，如果您的路由器、调制解调器或 DSLAM 永远缓冲并且从不让帧丢失，那么您最终会面临巨大的延迟增加，而 TCP 则没有机会后退以缓解拥塞。您不应该仅仅因为上行或下行带宽饱和而出现巨大的延迟增加。如果出现这种情况，您几乎肯定会出现缓冲区膨胀。
跑过dslreports.com 速度测试工具。与其他速度测试工具不同，此工具还会测量和报告缓冲区膨胀问题，当某些东西使用您的所有下行或上行带宽时（例如当您决定在夜间流式传输视频时），这可能会导致高延迟。
事实上，您已经证明，当某些东西使用了所有的上传带宽（例如，您的 iCloud 照片同步）时，延迟就会增加，这很好地表明您正遭受缓冲区膨胀问题。
您的 DSL 调制解调器可能是任何上行缓冲区膨胀问题的根源。一种解决方案可能是购买已知没有缓冲区膨胀问题的 DSL 调制解调器。不过，我还没有研究过这个市场，所以我无法为您提供任何建议。您的 Google-fu 可能和我的一样好。
或者，考虑购买可以运行 CeroWrt、OpenWrt 或 DD-WRT 的家庭网关，所有这些网关现在都具有防缓冲膨胀技术，例如 FQ_CoDel，这些技术最初是在 CeroWrt 中开创/开发的。通过使用这样的盒子人为地将你的上行和下行带宽限制在某个范围内轻微地比你的 DSL 链路实际能够承受的速度慢，并且有那个盒子实际上丢帧和发送显式拥塞通知（ECN）当达到该限制时，它不会永远缓冲，而是允许 TCP 检测拥塞并像 TCP 应该做的那样退避。
您不必放弃 DSL 调制解调器或 AirPort Extreme 来安装此 *Wrt 盒；您可以将其作为有线盒安装在 DSL 调制解调器和第一个 AirPort Extreme 之间。只需确保所有往返于家庭网络的流量都经过此盒即可。也就是说，确保除了此 *Wrt 盒之外，没有其他任何设备直接连接到 DSL 调制解调器。
如果您知道存在缓冲区膨胀，则应该在寻找其他潜在的延迟峰值来源之前将其消除，否则它会妨碍您寻找其他延迟来源的尝试。
答案2
有些不对劲。24 小时统计数据显示：
下载 312,600 MB 下载 247,500 MB
您没有包括链接速率，但 2KM 的 8A 可能为您提供 15/5 的链接。在 5Mb US 下，您只能上传大约 55GB/24 小时。即使在 10Mb 下，您也达不到 250GB，所以不要相信这些统计数据。
不过，这听起来确实像是您网络上的点对点/同步/恶意软件正在进行自我 DOS 攻击。
更新：
您的连接就像老式 ADSL 连接（8D 0.5U、12D 0.7U、15D 1U）一样平衡，而您通常使用 VDSL(2)（15D、3U）进行连接。这使您处于一种非常容易拥塞自己的链路的情况。
网络上运行的任何程序都可能导致上行队列，其中调制解调器保存一系列试图发送但发送速度快于其转发速度的帧。例如，从笔记本电脑到调制解调器需要 1ms，从调制解调器到交换机需要 20ms，从交换机到网站需要 5ms：从您到调制解调器需要 1ms，在帧缓冲区中等待 100ms，到交换机需要 20ms，到网站需要 5ms。发送的帧越多，等待时间就越长。
要寻找的东西：点对点（Bit Torrent、游戏启动器）同步应用程序：Windows 7/8/10 One Drive、Dropbox（尤其是相机同步）、iCloud 异地备份，如 Crashplan/Backblaze 等 VOIP/视频通话应用程序：Skype、TS/Mumble
任何将数据发送到网络的东西。