Google IP 向我的路由器發送 TCP（ACK、PSH）。知道為什麼？
我正在監控我的流量，並註意到我的路由器輸入鏈上的幾次TCP（ACK、PSH） 連接嘗試被我的防火牆丟棄。
日誌如下所示：
Dropping input: src-mac 9c:80:df:a0:8a:dd, proto TCP (ACK,PSH), 172.217.16.78:443 (google ip) ->192.168.1.2:40382 (my router IP), len 115顯然這被丟棄了，因為我在輸入鏈上的最後一條規則是丟棄數據包。
我不太了解 TCP 協議，如果這有點幼稚，很抱歉，但是為什麼請求會定向到我的路由器？
我有各種使用Google服務的設備，可能還有第三方軟體，但我很困惑，為什麼數據包實際上被發送到路由器而不是我網路中的設備（這將是轉發鏈，對吧？）。
我還沒有註意到我的設備在使用Google產品方面的體驗有所下降。軟體更新、推送通知等似乎都可以正常工作。
這種現象稍微複雜一些。我在相應的日誌中做了一些研究，並想在這里為所有想知道的人分享我的猜測。
相關日誌條目顯示輸入鏈中帶有 TCP 標誌
ACK和PSH(push) 的丟棄。這表明網路中的某些服務正在等待來自Google伺服器的消息（通過推送）。但是等等——為什麼包被記錄在輸入鏈中？這很容易解釋——如果路由器（或@chexum 已經提到的——conntrack）沒有關於NATed/PATed 流量的連接資訊，那麼這個包看起來像是路由器的流量，而不是它後面的任何設備的流量。這就解釋了為什麼“Google正在向路由器發送流量”。但問題是為什麼路由器沒有這些包的連接資訊。在這裡，我現在只能推測：在大多數使用者上網的時候觀察到下降。我的猜測是Google的回复需要很長時間（我可能是因為它之前推送的流量低於其他），因此連接超時。這個特定路由器上的超時對於 TCP 包大約為 10 秒，對於
SYN. 再過一段時間，conntrack 將刪除他對舊的“無效”流量的記憶，從那時起，來自該連接的每個流量看起來都像輸入流量。這也是為什麼不觸發無效規則的一種可能解釋。我認為@samuel 應該多觀察一下，看看是否有任何模式是可辨識的。但總的來說，我相信@chexum 認為這些下降是可以忽略的。