Dvě odchozí linky, ale jeden tunel: přepnutí, vyvažování nebo svazování
Přepnutí při výpadku, vyvažování po tocích a agregace jednoho toku jsou tři různé přísliby. Dvě výchozí trasy vám dají první, ale ne ty další dvě.
Dvě internetové linky mohou VPN zlepšit dostupnost a u některých úloh i zrychlit, ale o tom, co z toho nastane, rozhoduje mechanismus. Router se dvěma výchozími trasami není svázaný a tunel, který nese tisíce vnitřních spojení, je pořád jeden vnější tok. Pojmenovat příslib jako první je rozdíl mezi návrhem a drahým zklamáním. Tabulka níže odděluje možnosti podle toho, co každá potřebuje na vzdáleném konci a co ztráta linky udělá s přenosem.
Tři přísliby a jen jeden potřebuje partnera
Přepnutí při výpadku udržuje cestu dostupnou, když preferovaná linka zmizí. Vyvažování podle hashe toků rozprostírá nezávislé toky na obě odchozí linky. Agregace jednoho toku umožňuje jednomu přenosu využít obě linky najednou. To jsou různé produkty s různými požadavky a jen ten poslední potřebuje spolupráci něčeho mimo váš router.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
Nic v té tabulce není důvod kupovat druhou linku. Dělá něco jiného: brání tomu, aby se návrh přepnutí posuzoval, jako by šlo o svazování.
Proč tunel vypadá pro router jako jediný tok
Router vyvažující zátěž hašuje adresy zdroje a cíle spolu s porty a pak pošle celý tok tam, kam ukazuje hash. Tunel VPN je z pohledu routeru jeden takový tok, ať už v něm běží cokoli. Vnitřní spojení se k rozhodnutí o hashi nikdy nedostanou, protože vnější hlavička už cestu určila. Proto může druhá odchozí linka zdvojnásobit celkovou kapacitu pro mnoho uživatelů a na velkém přenosu jednoho uživatele nezměnit nic.
Dva oddělené tunely vám dají dva kandidáty, ale pořád potřebují záměrnou politiku, která přiděluje provoz a drží odpovědi na cestě, kterou odešel požadavek. Asymetrické směrování je obvyklým výsledkem vynechání tohoto kroku. Minimem je politika, která pojmenuje tok, preferovanou linku a záložní linku.
Svazování Ethernetu nepřekračuje nesouvisející poskytovatele, protože vzdálený konec se musí účastnit agregačního protokolu. Svazek přes dva poskytovatele je výzkumný projekt, dokud neexistuje spolupracující koncový bod.
Co multipath TCP potřebuje na obou koncích
Dokumentace Linuxu k Multipath TCP popisuje několik podtoků patřících jednomu spojení. Podpora jádra na jednom konci sama o sobě nic nezmění, protože protějšek musí tyto podtoky také přijmout. Proxy na vzdálené straně je druhé obvyklé uspořádání a stává se komponentou s vlastní kapacitou a dostupností, se kterými je třeba počítat. Stejná logika vylučuje snadnou odpověď pro WireGuard, jehož transport je UDP: MPTCP roste v TCP podtocích a tento tunel bez něčeho dalšího v návrhu agregovat nedokáže.
Ověřte, zda je funkce jádra zapnutá, než kolem ní budete navrhovat, protože mnoho distribucí ji dodává vypnutou. Tyto tři příkazy to zodpoví za minutu.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showVybírejte podle zátěže, ne podle brožury
Pokud je zátěží mnoho nezávislých relací, vyvažování podle hashe může přidat kapacitu bez spolupráce na vzdáleném konci. Pokud jde o jeden velký přenos, pomůže jen návrh agregace a ten potřebuje spolupracující protějšek. Pokud je požadavkem, aby práce pokračovala, když linka umře, odpovědí je přepnutí při výpadku a propustnost jednoho přenosu je irelevantní.
Napište požadavek jednou větou se slovesem: jedna záloha skončí dvakrát rychleji, nebo vypadlá linka neukončí relaci. Vágní cíle plodí návrhy, které nikdo nemůže přijmout ani odmítnout. Pak rozhodněte, čím vzdálený konec smí být, protože nejlevnější možnost je často ta, která tam nevyžaduje nic nového. Toto omezení vyřadí většinu tvrzení z brožury ještě před prvním setkáním.
Držte tři přísliby v dokumentu požadavků oddělené. Návrh, který tvrdí všechny tři, obvykle dodá jeden a tiše předpokládá ostatní. Další část zkouší, který se skutečně dodává.
Otestujte jeden přenos a mnoho, pak vytáhněte linku
Porovnejte jeden trvalý přenos s několika paralelními přenosy do stejného cíle a zaznamenejte ztráty, zpoždění a využití každé linky. Zisk jen při paralelních relacích ukazuje na rozložení toků, ne na agregaci jednoho toku. Otestujte ztrátu jedné odchozí linky zvlášť, protože kapacita při fungujících obou linkách nic neříká o přepnutí pro navázanou relaci. Před každým testem a po něm zaznamenejte trasu, socket a počítadla opakovaných přenosů.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Když jediný přenos pořád používá jednu odchozí linku, návrh dělá přesně to, co hash toku implikuje. Když se paralelní přenosy rozprostřou na obě, vyvažování funguje a agregace ne. Zaznamenejte, který ze tří příslibů návrh skutečně drží, a další rozhovor o kapacitě začne od důkazů, ne od tvrzení prodejce.