我們有一個應用程序定期以定義的速率發送TCP消息（使用MODBUS TCP）。如果在設定的時間內未收到消息，則會發出警報。然而，每過一段時間，收到的消息似乎都會延遲。調查顯示，這與正在刷新的ARP緩存相關，導致TCP消息的重新發送。如何減少MODBUS TCP的ARP沖刷引起的TCP延遲
IP堆棧提供程序告訴我們，這是TCP的預期行爲。問題是， 這是IP棧的預期行爲？如果沒有，其他堆棧在IP/MAC地址轉換不可用時的工作方式如何工作 如果這是預期的行爲，那麼在此期間如何減少TCP消息中的延遲？（已嘗試永久ARP條目，但未最好的解決方案）
在我上一份工作中，我曾與一家建立路由器和交換機的公司合作。我們的實現會對等待ARP答覆的數據包進行排隊，並在接收到ARP答覆時發送它們。因此，不需要TCP重傳。
當在給定時間內沒有收到ACK時，發生TCP中的重傳。如果ARP應答需要很長時間，或者本身丟失，那麼即使等待ARP應答的設備正在對數據包進行排隊，您也可能會收到重傳。
從您的問題中可以看出，TCP消息的週期短於ARP刷新時間。這意味着重複使用ARP並不會導致其刷新，這可能會對您的情況有所幫助。
發生情況的數據包跟蹤可能會有幫助 - 您是否實際上丟失了第一個數據包？ ARP答覆需要多長時間？
爲了阻止ARP緩存超時，您可能需要嘗試查找將刷新它的內容，例如另一個針對相同地址的ARP請求或免費ARP。 我發現一個MODBUS TCP的規範，但它沒有幫助。你可以發佈你的網絡的一些細節 - 媒體，設備，速度？
您的描述表明對等ARP條目在TCP段之間過期，並導致某些後續段由於缺少當前MAC目標而失敗。
如果在單獨的子網上有MODBUS設備，則目標路由器可能會對該段進行排隊，直到它接收到有效的MAC。如果您不能使用單獨的子網，您可以嘗試強制會話保持激活狀態 - 這會導致定期發送空的消息，以保持ARP定時器的重置。如果保持活動的開銷太高，並且您完全控制系統中的應用程序，則可以嘗試強制將零長度的消息傳遞給對等設備。