是否有可能將多個網路管道合而為一？ 圍繞這個主題有很多誤解和神話；即使是經驗豐富的網路工程師也常常不知道這是可能的。 在大多數情況下，鏈路聚合被錯誤地稱為 NAT 等級的平衡或故障轉移。 但實數求和允許 透過所有 Internet 通道同時啟動一個 TCP 連接例如，視訊廣播，這樣如果任何網路頻道中斷，廣播就不會中斷。
視訊廣播有昂貴的商業解決方案，但此類設備的成本高達數千美元。 本文介紹如何設定免費的開源 OpenMPTCPRouter 包，並解決了有關通道求和的常見誤解。
關於通道求和的誤解
現在有許多家用路由器支援多WAN功能。 有時製造商將此稱為通道求和，但這並不完全正確。 不少網友認為，除了 以及 L2 層級的求和，不存在其他通道聚合。 我經常從電信工作人員那裡聽說這通常是不可能的。 因此，讓我們嘗試了解流行的神話。
IP 連線等級的平衡
這是同時利用多個網路管道的最實惠和流行的方式。 為簡單起見，我們假設您有三個 Internet 供應商，每個提供者都為您提供來自其網路的真實 IP 位址。 所有這些提供者都連接到支援多 WAN 功能的路由器。 這可以是具有 mwan3 軟體包的 OpenWRT、mikrotik、ubiquiti 或任何其他家用路由器，因為這樣的選項已不再罕見。
為了模擬這種情況，我們假設提供者給了我們以下地址：
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
即連接到遠端伺服器 example.com 透過每個供應商，遠端伺服器將看到三個獨立的來源 IP 用戶端。 平衡可讓您跨通道分配負載並同時使用所有三個通道。 為簡單起見，我們假設我們在所有通道之間平均分配負載。 因此，當客戶打開包含三個圖像的網站時，他會透過單獨的提供者下載每個圖像。 在網站方面，它看起來像是來自三個不同 IP 的連線。
在連線層級進行平衡時，每個 TCP 連線都透過單獨的提供者。
這種平衡模式常常會為使用者帶來問題。 例如，許多網站將cookie和令牌嚴格綁定到客戶端的IP位址，如果它突然改變，請求將被拒絕或客戶端從網站登出。 這通常會在客戶銀行系統和其他具有嚴格使用者會話規則的網站中重現。 這是一個簡單的說明性範例：VK.com 上的音樂檔案僅在使用與IP 綁定的有效會話金鑰的情況下才可用，並且使用這種平衡的客戶端通常不會播放音頻，因為請求沒有通過提供者會話已平手。
下載種子時，連線等級平衡會匯總所有通道的頻寬
這種平衡可讓您在使用多個連線時獲得 Internet 通道的速度總和。 例如，如果三個供應商的速度都是 100 兆比特，那麼下載種子時我們將獲得 300 兆比特。 因為一個 torrent 會開啟許多連接，這些連接分佈在所有提供者之間，並最終利用整個通道。
重要的是要理解，一個 TCP 連線始終只經過一個提供者。 也就是說，如果我們透過 HTTP 下載一個大文件，那麼該連線將透過其中一個提供者建立，如果與該提供者的連線斷開，下載也會中斷。
一個連線將始終僅使用一個 Internet 通道
對於視訊廣播也是如此。 如果您將串流視訊廣播到某種有條件的 Twitch，則 IP 連線層級的平衡不會帶來任何特別的好處，因為視訊串流將在一個 IP 連線內廣播。 在這種情況下，如果 WAN 3 供應商開始出現通訊問題（例如資料包遺失或速度降低），那麼您將無法立即切換到另一個提供者。 廣播必須停止並重新連接。
真正的通道求和
真實通道求和使得可以透過所有提供者同時運行與條件 Twitch 的一個連接，這樣即使任何提供者發生故障，連接也不會中斷。 這是一個令人驚訝的難題，至今仍沒有最佳解決方案。 很多人甚至不知道這是可能的！
從前面的插圖中，我們記得條件Twitch 伺服器只能從我們的一個來源IP 位址接收視訊串流，這意味著它必須始終對我們來說是恆定的，無論哪些提供者已停止運作以及哪些提供者正在運行。 為了實現這一目標，我們需要一台求和伺服器來終止所有連線並將它們合併為一個。
求和伺服器將所有通道聚合到一條隧道中。 所有連線均源自求和伺服器位址
在此方案中，使用所有提供程序，停用其中任何一個都不會導致與 Twitch 伺服器的通訊遺失。 本質上，這是一個特殊的 VPN 隧道，在其背後同時存在多個網路通道。 這種方案的主要任務是獲得最高品質的通訊頻道。 如果其中一個提供者開始出現問題、資料包遺失、延遲增加，那麼這不會以任何方式影響通訊質量，因為負載將自動分配到其他更好的可用通道上。
商業解決方案
這個問題長期以來一直困擾著那些直播賽事且無法存取高品質網路的人。 對於此類任務，有幾種商業解決方案，例如，Teradek 公司製造了這種巨大的路由器，其中插入了 USB 數據機包：
具有頻道求和功能的視訊廣播路由器
此類設備通常具有透過 HDMI 或 SDI 擷取視訊訊號的內建功能。 與路由器一起出售頻道匯總服務的訂閱，以及處理視訊串流、轉碼並進一步轉發。 此類設備的價格從 2 美元起，配備一組調製解調器，再加上單獨的服務訂閱。
有時看起來很可怕：
設定 OpenMPTCPRouter
協議 （多路徑 TCP）的發明是為了能夠同時透過多個通道進行連線。 例如，他的 並且可以同時透過 WiFi 和蜂窩網路連接到遠端伺服器。 重要的是要理解，這些不是兩個單獨的 TCP 連接，而是同時透過兩個通道建立的一個連接。 為此，遠端伺服器也必須支援 MPTCP。
是一個開源軟體路由器項目，可實現真正的通道匯總。 作者表示該項目處於 alpha 版本狀態，但已經可以使用。 它由兩部分組成 - 位於互聯網上的求和伺服器和路由器，多個互聯網提供商和客戶端設備本身連接到：電腦、電話。 客製化路由器可以是 Raspberry Pi、某些 WiFi 路由器或普通電腦。 各種平台都有現成的組件，非常方便。
OpenMPTCPRouter 的工作原理
設定摘要伺服器
求和伺服器位於網際網路上，並將來自客戶端路由器的所有通道的連線終止為一個。 透過 OpenMPTCPRouter 存取網際網路時，該伺服器的 IP 位址將是外部位址。
對於此任務，我們將使用 Debian 10 上的 VPS 伺服器。
對求和伺服器的要求：
- MPTCP 不適用於 OpenVZ 虛擬化
- 應該可以安裝自己的Linux內核
執行一條指令即可部署伺服器。 該腳本將安裝支援 mptcp 的核心以及所有必需的軟體包。 安裝腳本適用於 Ubuntu 和 Debian。
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
伺服器安裝成功的結果。
我們保存密碼，我們將需要它們來設定客戶端路由器並重新啟動。 請務必記住，安裝後，SSH 將在連接埠 65222 上可用。重新啟動後，我們需要確保使用新核心啟動
uname -a
Linux test-server.local 4.19.67-mptcp
我們在版本號碼旁邊看到了 mptcp 字樣，這表示核心已正確安裝。
設定客戶端路由器
上 現成的建置可用於某些平台，例如 Raspberry Pi、Banana Pi、Lynksys 路由器和虛擬機器。
openmptcprouter的這一部分是基於OpenWRT的，使用LuCI作為接口，對於任何接觸過OpenWRT的人來說都是熟悉的。 該發行版大約有50MB！
作為測試平台，我將使用 Raspberry Pi 和幾個具有不同運營商的 USB 數據機：MTS 和 Megafon。 我想我不需要告訴你如何將圖像寫入 SD 卡。
最初，Raspberry Pi 中的乙太網路連接埠配置為具有靜態 IP 位址的 lan 192.168.100.1。 為了避免擺弄桌子上的電線，我將 Raspberry Pi 連接到 WiFi 接入點，並將電腦的 WiFi 適配器設定為靜態位址 192.168.100.2。 預設未啟用 DHCP 伺服器，因此您必須使用靜態位址。
現在您可以登入網頁介面了
當您第一次登入時，系統會要求您設定root密碼；使用相同的密碼即可使用SSH。
在 LAN 設定中，您可以設定所需的子網路並啟用 DHCP 伺服器。
我使用的調變解調器被定義為具有單獨 DHCP 伺服器的 USB 乙太網路接口，因此需要安裝 。 該過程與在常規 OpenWRT 中設定調變解調器相同，因此我不會在這裡介紹它。
接下來您需要設定 WAN 介面。 最初，系統建立了兩個虛擬介面 WAN1 和 WAN2。 需要為它們分配一個實體設備，在我的例子中，這些是 USB 數據機介面的名稱。
為了避免與介面名稱混淆，我建議在透過 SSH 連線時查看 dmesg 訊息。
由於我的數據機本身充當路由器，並且本身俱有 DHCP 伺服器，因此我必須更改其內部網路範圍的設定並停用 DHCP 伺服器，因為最初兩個數據機都會從同一網路發出位址，這會導致衝突。
OpenMPTCPRouter 要求 WAN 介面位址是靜態的，因此我們為數據機設定子網，並在系統 → openmptcprouter → 介面設定選單中設定它們。 此處需要指定安裝求和伺服器時所取得的IP位址和伺服器金鑰。
如果設定成功，狀態頁面上應該會出現類似的圖片。 可以看到路由器能夠到達求和伺服器，並且兩個通道都運作正常。
預設模式是shadowsocks + mptcp。 這是一個將所有連接包裝在其內部的代理。 它最初配置為僅處理 TCP，但也可以啟用 UDP。
如果狀態頁面上沒有錯誤，則可以認為設定已完成。
對於某些供應商，當流量路徑上的 mptcp 標誌被切斷時，可能會出現以下情況，然後會出現以下錯誤：
在這種情況下，您可以使用不同的操作模式，而不使用 MPTCP，更多關於此 .
結論
OpenMPTCPRouter 專案非常有趣且重要，因為它可能是解決通道求和問題的唯一開放式綜合解決方案。 其他一切要么是嚴格封閉和專有的，要么只是普通人無法理解的獨立模組。 在目前的開發階段，該專案還相當粗糙，文件極度貧乏，很多東西根本就沒有描述。 但同時它仍然有效。 我希望它能夠繼續發展，我們將獲得能夠正確組合開箱即用的頻道的家用路由器。
在 Instagram 上關注我們的開發者
來源： www.habr.com