我有一個使用 Boost ASIO TCP 套接字的客戶端/伺服器網路應用程式。客戶端運行在嵌入式Linux 系統上，其中有多個網路介面可用（WiFi、蜂窩等），任何時候只有一個網路介面處於啟動狀態並簽署IP 位址，如果該介面處於關閉狀態，則另一個網路介面處於啟動狀態並簽署IP位址。我遇到的麻煩是，當應用程式在一個可用介面中建立TCP 套接字時，它可以將資料傳輸到遠端伺服器，但是當該介面關閉時，另一個介面打開，客戶端應用程式仍然將數據傳輸到遠端伺服器使用相同的down介面導致伺服器無法接收資料。我認為Linux作業系統路由應該能夠處理網路介面故障轉移，用戶TCP應用程式應該不需要擔心網路介面的變化。感謝任何修復程序的提示。
我在運行帶有以太網和WiFi 的Ubuntu 18 的筆記型電腦上也看到同樣的問題，如果我在以太網連接時運行連接到遠端站點的ssh，當我拔掉以太網電纜時，WiFi 仍然連接，但ssh 凍結，它無法透過作業系統路由轉移連接。
謝謝。
親切的問候，
- j
您是在談論當一個介面故障時現有的 TCP 連線會切換介面嗎？這是行不通的，TCP 不是多宿主的，所以這是協定的缺陷，而不是 Linux 的缺陷。預設情況下，在 TCP 套接字上偵聽的 OTOH 將使用所有接口，就像打開 TCP 連接一樣。
是的，當一個介面發生故障時，現有的 TCP 連線會切換介面。
如果您控制客戶端-伺服器應用程式中的兩端，請考慮使用多宿主協議，例如 SCTP 或多路徑 TCP。
是的，我控制客戶端伺服器應用程式的兩側。我使用Boost ASIO套接字，將檢查Boost是否支援多路徑TCP。
還有其他方法可以處理實體連結的故障轉移，例如綁定，但它們也要求您能夠控制雙方。
是或否，我控制客戶端伺服器應用程式的兩側，但我只控制伺服器平台網站而不是客戶端平台網站我可以建議客戶端網站更改網路操作，這行得通嗎？
謝謝。
答案1
您是在談論當一個介面故障時現有的 TCP 連線會切換介面嗎？這是行不通的，TCP 不是多宿主的，所以這是協定的缺陷，而不是 Linux 的缺陷。奧托傾聽TCP 套接字將預設使用所有接口，如下所示開幕TCP 連線。
如果您控制客戶端-伺服器應用程式中的雙方，請考慮使用多宿主協議，例如SCTP或者多路徑TCP。
我認為Linux作業系統路由應該能夠處理網路介面故障轉移
它沒有也從來沒有這樣做過，任何其他現有的 TCP 和 UDP 實作也沒有這樣做。同樣，您也不能輕鬆地同時使用多個 ISP，這是一個常見問題。
還有其他方法可以處理實體連結的故障轉移，例如綁定，但它們也要求您能夠控制雙方。
編輯
根據伺服器和用戶端之間的情況，網路的這一部分可能會也可能不會讓 SCTP 通過（有疑問，請測試）。
對於大多數嵌入式 Linux 系統，您應該能夠重新編譯內核，這正是多路徑 TCP 所需要的。
如果你做不到這一點，你可能會遇到這個問題 - 那麼唯一的解決方法是偵測介面是否關閉，並重新開啟客戶端的連線（假設伺服器有一個已知的 IP）。