在过去的几个月里，我一直在努力应对经常性的互联网中断，影响到我本地网络上的所有设备，迫使我关闭有线调制解调器的电源。今天我注意到，通过安装暴雪的 Battle.net 游戏，我可以重现此问题（或具有相同症状的类似问题）。
这不仅会占用我的带宽，因为
- 下载本身也会停止，
- 限制下载速度时也会出现这种情况，
- 暂停下载时它不会自动解决 - 只有重新启动调制解调器才有帮助。
为了准确了解我的互联网连接何时失败，我ping 8.8.8.8在连接到同一网络的另一台 Linux 笔记本电脑上运行了一个简单的程序（顺便说一下，我使用的是 Arch）——但即使我的互联网出现故障，我仍然可以继续 ping！只有停止运行时平，然后重新启动它，我不再收到任何回应。
我对这种行为感到有点困惑。我也尝试过并排跑步ping 8.8.8.8-watch -n1 ping -c 1 8.8.8.8虽然持续跑步平流程继续运行，平进程定期重新启动手表一旦我的互联网断线，它就会失败。
这怎么可能？似乎“活动 ping 会话”不受我的中断影响。但是使用第 3 层 ICMP 进行 ping，我不明白为什么保持平跑步，而不是重新开始。
在看到 Battle.net 下载也会导致此问题后，我立即怀疑与过多的 P2P 连接堵塞了我的路由器有关。但我既不确定 Battle.net 是否真的使用 P2P，也没有在路由器上看到任何可疑的活动连接（最多 15,360 个连接，其中约 3,000 到 4,000 个）、内存使用情况或类似情况。
不幸的是，我无法真正查看来自电缆调制解调器的指标，因为我的 ISP 没有提供适当的接口 - 这也是我以桥接模式运行它的原因。
对于这种行为有什么解释吗？
编辑：我使用 Wireshark 查看了 ICMP 消息：获得响应的 ICMP 回显请求与没有获得响应的 ICMP 回显请求之间唯一明显的区别是：
- ICMP 标识符与进程绑定；来自正在运行的平具有相同的 ID，来自重新启动的 ping 的请求将获得一个新的
- 运行程序发送的每个请求的序列号都会增加平，但对于重新启动的
这是非常预期的行为，并且实际上并没有给我任何帮助——毕竟，为什么这会导致请求得到不同的处理？
答案1
这怎么可能？似乎“活动 ping 会话”不受我的中断影响。但是使用第 3 层 ICMP 进行 ping，我不明白为什么保持 ping 运行与重新开始有什么区别。
即使对于没有明确状态的协议（如 UDP 和 ICMP Echo），路由器仍需要保持自己的状态以实现防火墙和 NAT 功能。（例如，它会跟踪 NAT 映射以了解将 Echo Reply 数据包返回到哪个内部主机。）对于此类协议，您发送的任何第一个数据包都会建立状态；不活动后的超时会导致其被删除。
就像 TCP 一样，状态表会记住 UDP 数据包流的源目标端口，或 ICMP Echo 流的单个“请求 ID”。尽管 ICMP 没有端口号，但 Echo 请求有一个 ID，其作用相同，即区分不同的流。（如果您查看 Wireshark 中的数据包捕获，就会看到这一点。）这意味着，每次新的ping调用都会导致添加新的状态条目。
（举一个实际的例子：如果你这样做，conntrack -L你就可以看到你的计算机的 iptables/nftables 防火墙跟踪的状态，这与大多数家用路由器内部使用的状态基本相同。请注意idICMP Echo 状态的字段。）
因此，从您的问题描述来看，这听起来确实像是路由器的状态表因过多的“连接”而填满，并且其固件配置为停止接受新状态，而不是让它们推出旧状态。（公平地说，我思考这是 Linux conntrack 的默认行为吗？
也可能是有问题的路由器有一个错误，导致它永远无法清算状态，并且其内存会一直填满，直到重新启动；特别是如果路由器将 NAT 卸载到硬件加速，并且如果所述卸载破坏了状态删除。（如果是这种情况，我完全不会感到惊讶，ISP 只是将其编程为每周重新启动一次，这对普通用户来说“足够好了”。）
Battle.net 现在不再使用 P2P，它只是来自 CDN 的 HTTP（虽然很久以前它曾经是基于 BitTorrent 的），但它做建立相对大量的并行 HTTP 下载，肯定会加剧问题。
最后，正如评论中提到的，这是可能的（虽然我不确定是否可能）路由器的防火墙会丢失所有过滤器和/或 NAT 规则。这对于基于 Linux 的设备来说是有意义的 - 事实上，iptables 会自动处理现有状态的 NAT，因此如果传出的 SNAT 或 MASQUERADE 规则由于某种原因被删除，它将阻止建立新连接，但现有连接将继续工作（它们将继续根据已存储在状态中的信息进行 NAT）。
如果您找不到解决方法，VPN 可能是个解决方法——就您的路由器可见的范围而言，整个 VPN 隧道仅算作一个状态。