几个月来我一直在为这个问题苦苦思索，现在我决定是时候寻求帮助了。
我似乎在 wifi 网络上遇到了明显的数据包丢失。任何实时视频/音频流式传输到网络上的任何设备时，这种情况都很明显。通常，连接良好且稳定，但似乎每隔一两分钟，给定设备上就会出现 5-10 秒的数据包完全丢失（这些是相对隔离环境中的固定设备 - 即周围没有太多活动）或者网络上的其他已知活动）。
我有点茫然，因为 MTR 报告称 wifi 上的设备与路由器的丢失率为 0%，而且所有丢失似乎都在上游：
Host Loss% Snt Last Avg Best Wrst StDev
1. local-router xxxxxxxxxxxxxxxxxxxxxx 0.0% 128 2.2 5.7 1.7 129.0 17.5
2. ISP-router (off premises) xxxxxxxxx 0.8% 128 4.1 8.1 3.1 139.3 14.2
3. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.0% 128 4.6 8.7 3.7 105.8 15.5
4. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 11.7% 128 16.2 19.3 12.9 155.8 16.0
5. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.8% 128 15.6 20.2 12.7 134.1 15.9
6. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.8% 128 13.8 18.4 13.2 140.1 18.5
7. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1.6% 128 15.6 19.3 14.2 154.0 17.1
8. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1.6% 128 13.6 16.8 12.9 235.7 20.1
9. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1.6% 127 14.1 19.4 13.1 211.1 24.8
我发现延迟增加并且超时，同时还看到数据包丢失：
64 bytes from xxx: icmp_seq=105 ttl=58 time=14.048 ms
64 bytes from xxx: icmp_seq=106 ttl=58 time=14.312 ms
64 bytes from xxx: icmp_seq=107 ttl=58 time=14.323 ms
64 bytes from xxx: icmp_seq=108 ttl=58 time=135.899 ms
64 bytes from xxx: icmp_seq=109 ttl=58 time=186.013 ms
Request timeout for icmp_seq 110
Request timeout for icmp_seq 111
64 bytes from xxx: icmp_seq=112 ttl=58 time=13.927 ms
64 bytes from xxx: icmp_seq=113 ttl=58 time=14.140 ms
64 bytes from xxx: icmp_seq=114 ttl=58 time=15.410 ms
64 bytes from xxx: icmp_seq=115 ttl=58 time=15.171 ms
64 bytes from xxx: icmp_seq=116 ttl=58 time=13.993 ms
64 bytes from xxx: icmp_seq=117 ttl=58 time=14.378 ms
最后，当我从有线网络上的设备，一切似乎都很好：
Host Loss% Snt Last Avg Best Wrst StDev
1. local-router xxxxxxxxxxxxxxxxxxxxxx 0.0% 208 0.7 0.6 0.4 1.9 0.2
2. ISP-router (off premises) xxxxxxxxx 0.0% 208 3.9 4.0 1.7 39.5 5.0
3. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.0% 208 3.1 3.7 1.8 39.3 4.2
4. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.0% 208 12.0 14.9 11.1 31.8 3.9
5. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.0% 208 11.8 14.3 10.9 27.2 3.4
6. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.0% 208 12.6 12.5 11.7 13.9 0.3
7. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.0% 208 13.7 13.6 12.0 18.4 0.7
8. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.0% 208 12.8 12.6 11.6 14.5 0.4
9. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0.0% 207 12.7 12.5 11.4 14.1 0.3
几个月来，我时不时地看到这种现象。重启路由器和 AP 似乎没有帮助。就硬件而言，网络是一个简单的、由 ISP 提供的 C3510XZ，用作调制解调器和路由器，并直接连接 unifi u6-lr 接入点。unifi 软件报告称，在我测试的所有设备上，体验率为 99%，信号强度范围为 -71 到 -60 dBm（编辑：我还在信号为 -45 dBm 的 AP 旁边进行了测试，并注意到了相同的行为）。
一般来说，我只是想知道为什么我会看到基于接入点的引入而产生的不同上行行为。我知道 MTR 发送的每个数据包都有不同的 TTL，但如果 wifi 是罪魁祸首，我认为会看到本地路由器的一些数据包丢失。无论如何，任何见解/建议都将不胜感激。
答案1
a) 以太网/IP 数据帧中没有任何信息表明它们源自基于 WIFI 的网络。b
) 当您在互联网上前进时，跳跃之间可能至少有一个 NAT 转换（此处：数据包标识更改）。c
) 我敢打赌这些问题在某种程度上是随机的。可能是由于邻近的 WIFI 网络在相同或附近的信道中活动所致。
您所做的运行mtr看起来像是在“未加载”网络上运行的结果；如果是因此，我建议你在视频流处于活动状态时进行同样的运行。
此类运行的结果可能更能说明问题所在。