網絡之間的套接字連接超時有所不同

Question

我有一個相當有趣的問題。 我們有2個網絡在工作，它們是彼此的物理副本（網絡A和網絡B）。 它們只是在不同的子網上運行。

我正在為在網絡上相互群集的設備進行一些容錯改進。 我正在測試的一個測試案例是引入錯誤配置時這些設備的行為。 例如，假設我有兩個具有以下接口配置的設備：

設備X IP：10.200.234.127子網掩碼：255.255.254.0默認網關：10.200.234.1

設備Y IP：10.200.234.127子網掩碼：255.255.254.0默認網關：10.200.234.1

這兩個設備通過群集心跳的廣播相互發現。 心跳包含設備的ip地址等，從而使它們之間可以建立通信。 很標准的東西。 現在，可以說我引入了一個網絡配置錯誤，使得這些設備之一針對不同的sunbet配置：

設備X IP：192.168.1.115子網掩碼：255.255.255.0默認網關：192.168.1.1

此處發生的是，兩個設備仍從群集廣播中相互學習（它們在同一交換機上物理連接在一起）。 但是，正如您期望的那樣，它們無法按預期相互通信。 但是，當這些設備嘗試相互通信時，我看到一些有關連接超時的奇怪行為。 例如，如果設備連接到網絡A，則連接嘗試在幾秒鍾內超時，這非常好。 現在，如果我將兩個設備都放在網絡BI上，則會看到完全不同的行為。 在網絡B上，在設備之間建立套接字連接的connect（）調用不會很快失敗。 相反，它們陷入了此退避和重新傳輸周期，該周期花了189秒才能最終放棄（如通過wireshark驗證的3、6、12、24、48和96秒重新傳輸）。

所以我想知道的是，為什么connect（）調用在網絡A而不是網絡B中如此快速地失敗。我嘗試使用阻塞套接字和對connect（）的調用以及非阻塞套接字和對connect（），然后調用select（）。 在這兩種情況下，我都無法早於189秒放棄連接。 我知道我可以在選擇和放棄電話時強加較短的超時時間，但這不是重點。 我試圖了解導致這兩個問題的這兩個網絡上可能有什么不同。

Answer 1

也許您應該提供更多地址？ 目前尚不清楚IP是什么。

我的猜測是：

• 在較慢的情況下，您會遇到ARP故障（由於目標的網絡掩碼不正確，因此沒有響應）
• 在快速情況下，您會遇到路由故障。 如果主機的網絡掩碼較小，它甚至不會嘗試ARP。

請嘗試跟蹤阻塞套接字，錯誤代碼應該不同。