在過去的幾個月裡，我一直在與定期的網路中斷作鬥爭，這影響了我本地網路上的所有設備，迫使我重新啟動電纜數據機。今天我注意到，透過安裝暴雪 Battle.net 遊戲，我可以重現此問題 - 或具有相同症狀的類似問題。
這不僅僅是為了讓我的頻寬飽和，因為
- 下載本身也會停止，
- 限制下載速度時也會發生這種情況，
- 暫停下載時它不會自動解決 - 只有重新啟動調製解調器才有幫助。
為了準確地查看我的互聯網連接何時失敗，我在ping 8.8.8.8連接到同一網絡的單獨Linux 筆記本（我使用的是Arch btw）上運行一個簡單的程序- 但即使我的互聯網失敗，我仍然能夠繼續執行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 時發出的請求將獲得一個新的 id
- 對於正在運行的程式發送的每個請求，序號都會增加平，但重新啟動時設定為 1
這是非常預期的行為，並且並沒有真正幫助我任何進一步 - 畢竟，為什麼這會導致請求得到不同的對待？
答案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 隧道在您的路由器可以看到的範圍內僅被視為一個狀態。