Dve odchádzajúce linky, ale jeden tunel: prepnutie, vyvažovanie alebo zlúčenie
Prepnutie pri výpadku, vyvažovanie podľa toku a zlúčenie jedného toku sú tri rôzne prísľuby. Dve predvolené trasy vám dajú prvý, ale nie ostatné dva.
Dve internetové linky môžu VPN sprístupniť a niektorým pracovným zaťaženiam aj zrýchliť, ale o tom, čo z toho nastane, rozhoduje mechanizmus. Smerovač s dvoma predvolenými trasami nie je zlúčený a tunel, ktorý nesie tisíce vnútorných spojení, je stále jeden vonkajší tok. Pomenovať prísľub ako prvý je rozdiel medzi návrhom a drahým sklamaním. Tabuľka nižšie oddeľuje možnosti podľa toho, čo každá potrebuje na vzdialenom konci a čo strata linky urobí s prenosom.
Tri prísľuby a len jeden potrebuje partnera
Prepnutie pri výpadku udržiava cestu dostupnou, keď preferovaná linka zmizne. Vyvažovanie podľa hashu tokov rozdeľuje nezávislé toky na obe odchádzajúce linky. Zlúčenie jedného toku umožňuje jednému prenosu využiť obe linky naraz. To sú rôzne produkty s rôznymi požiadavkami a len ten posledný potrebuje spoluprácu niečoho mimo vášho smerovača.
| 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 |
Nič v tej tabuľke nie je dôvod kupovať druhú linku. Robí niečo iné: bráni tomu, aby sa návrh prepnutia posudzoval, akoby išlo o zlúčenie.
Prečo tunel vyzerá pre smerovač ako jediný tok
Smerovač vyvažujúci záťaž hašuje adresy zdroja a cieľa spolu s portami a potom pošle celý tok tam, kam ukazuje hash. Tunel VPN je z pohľadu smerovača jeden taký tok, nech v ňom beží čokoľvek. Vnútorné spojenia sa nikdy nedostanú k rozhodnutiu o hashi, pretože vonkajšia hlavička už cestu určila. Preto môže druhá odchádzajúca linka zdvojnásobiť celkovú kapacitu pre mnohých používateľov a na veľkom prenose jedného používateľa nezmeniť nič.
Dva oddelené tunely vám dajú dvoch kandidátov, ale stále potrebujú zámernú politiku, ktorá prideľuje prevádzku a drží odpovede na ceste, ktorou odišla požiadavka. Asymetrické smerovanie je obvyklým výsledkom vynechania tohto kroku. Minimom je politika, ktorá pomenuje tok, preferovanú linku a záložnú linku.
Zlúčenie Ethernetu neprechádza cez nesúvisiacich poskytovateľov, pretože vzdialený koniec sa musí zúčastniť agregačného protokolu. Zlúčenie cez dvoch poskytovateľov je výskumný projekt, ak neexistuje spolupracujúci koncový bod.
Čo viaccestný TCP potrebuje na oboch koncoch
Dokumentácia Linuxu k Multipath TCP opisuje niekoľko podtokov patriacich jednému spojeniu. Podpora jadra na jednom konci sama o sebe nič nezmení, pretože protistrana musí tieto podtoky tiež prijať. Proxy na vzdialenej strane je druhé obvyklé usporiadanie a stáva sa komponentom s vlastnou kapacitou a dostupnosťou, s ktorými treba počítať. Rovnaká logika vylučuje jednoduchú odpoveď pre WireGuard, ktorého transport je UDP: MPTCP rastie v TCP podtokoch a tento tunel bez niečoho ďalšieho v návrhu agregovať nedokáže.
Overte, či je funkcia jadra zapnutá, skôr než okolo nej budete navrhovať, pretože mnohé distribúcie ju dodávajú vypnutú. Tieto tri príkazy to zodpovedia za minútu.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showVyberajte podľa záťaže, nie podľa brožúry
Ak je záťažou mnoho nezávislých relácií, vyvažovanie podľa hashu môže pridať kapacitu bez spolupráce na vzdialenom konci. Ak ide o jeden veľký prenos, pomôže len návrh agregácie a ten potrebuje spolupracujúcu protistranu. Ak je požiadavkou, aby práca pokračovala, keď linka zomrie, odpoveďou je prepnutie a priepustnosť jedného prenosu je irelevantná.
Napíšte požiadavku jednou vetou so slovesom: jedna záloha skončí dvakrát rýchlejšie, alebo vypadnutá linka neukončí reláciu. Neurčité ciele plodia návrhy, ktoré nikto nemôže prijať ani odmietnuť. Potom rozhodnite, čím vzdialený koniec smie byť, pretože najlacnejšia možnosť je často tá, ktorá tam nevyžaduje nič nové. Toto obmedzenie vyradí väčšinu tvrdení z brožúry ešte pred prvým stretnutím.
Držte tri prísľuby v dokumente požiadaviek oddelené. Návrh, ktorý tvrdí všetky tri, zvyčajne dodá jeden a ticho predpokladá ostatné. Ďalšia časť skúša, ktorý sa skutočne dodáva.
Otestujte jeden prenos a mnoho, potom vytiahnite linku
Porovnajte jeden trvalý prenos s niekoľkými paralelnými prenosmi do rovnakého cieľa a zaznamenajte straty, oneskorenie a využitie každej linky. Zisk len pri paralelných reláciách ukazuje na rozloženie tokov, nie na agregáciu jedného toku. Otestujte stratu jednej odchádzajúcej linky zvlášť, pretože kapacita pri fungujúcich oboch linkách nič nehovorí o prepnutí pre nadviazanú reláciu. Pred každým testom a po ňom zaznamenajte trasu, socket a počítadlá opakovaných prenosov.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Keď jediný prenos stále používa jednu odchádzajúcu linku, návrh robí presne to, čo hash toku implikuje. Keď sa paralelné prenosy rozložia na obe, vyvažovanie funguje a agregácia nie. Zaznamenajte, ktorý z troch prísľubov návrh skutočne dodržiava, a ďalší rozhovor o kapacite začne od dôkazov, nie od tvrdenia predajcu.