Du išėjimo kanalai, bet vienas tunelis: perjungimas, balansavimas ar sujungimas
Perjungimas gedimo atveju, balansavimas pagal srautą ir vieno srauto sujungimas yra trys skirtingi pažadai. Du numatytieji maršrutai duoda pirmąjį, bet ne kitus du.
Dvi interneto linijos gali padaryti VPN labiau prieinamą, o kai kuriems darbo krūviams – ir greitesnį, tačiau mechanizmas nusprendžia, kuris iš šių dalykų įvyks. Maršrutizatorius su dviem numatytaisiais maršrutais nėra sujungtas, o tunelis, nešantis tūkstančius vidinių ryšių, vis tiek yra vienas išorinis srautas. Pažado įvardijimas pirmiausia yra skirtumas tarp projekto ir brangaus nusivylimo. Žemiau esanti lentelė atskiria variantus pagal tai, ko kiekvienas reikalauja tolimajame gale ir ką ryšio praradimas padaro perdavimui.
Trys pažadai, ir tik vienam reikia partnerio
Perjungimas gedimo atveju išlaiko kelią prieinamą, kai pageidaujama linija išnyksta. Balansavimas pagal srautų maišą paskirsto nepriklausomus srautus abiem išėjimo kanalams. Vieno srauto sujungimas leidžia vienam perdavimui naudoti abi linijas vienu metu. Tai skirtingi produktai su skirtingais reikalavimais, ir tik paskutiniam reikia bendradarbiavimo su kuo nors už jūsų maršrutizatoriaus ribų.
| 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 |
Nieko toje lentelėje nėra priežastis pirkti antrą liniją. Ji daro kita: neleidžia perjungimo projekto vertinti taip, tarsi tai būtų sujungimas.
Kodėl tunelis maršrutizatoriui atrodo kaip vienas srautas
Apkrovą balansuojantis maršrutizatorius maišo šaltinio ir paskirties adresus kartu su prievadais, o paskui siunčia visą srautą ten, kur rodo maišas. VPN tunelis maršrutizatoriaus požiūriu yra vienas toks srautas, kad ir kas jame veikia. Vidiniai ryšiai niekada nepasiekia maišo sprendimo, nes išorinė antraštė jau nustatė kelią. Štai kodėl antras išėjimo kanalas gali dvigubai padidinti bendrą talpą daugeliui naudotojų ir nieko nepakeisti vieno naudotojo dideliam perdavimui.
Du atskiri tuneliai gali duoti du kandidatus, bet jiems vis tiek reikia sąmoningos politikos, kuri paskirsto srautą ir išlaiko atsakymus tame kelyje, kuriuo ėjo užklausa. Asimetrinis maršrutizavimas yra įprastas to žingsnio praleidimo rezultatas. Minimalus reikalavimas – politika, kuri įvardija srautą, pageidaujamą liniją ir atsarginę liniją.
Ethernet sujungimas neperžengia nesusijusių tiekėjų, nes tolimasis galas turi dalyvauti sujungimo protokole. Sujungimas per du interneto tiekėjus yra tyrimų projektas, nebent egzistuoja bendradarbiaujantis galinis taškas.
Ko daugiakelis TCP reikalauja abiejuose galuose
Linux Multipath TCP dokumentacija aprašo kelis posraučius, priklausančius vienam ryšiui. Branduolio palaikymas viename gale pats savaime nieko nekeičia, nes partneris taip pat turi priimti tuos posraučius. Tarpinis serveris tolimojoje pusėje yra kita įprasta sąranka, ir jis tampa komponentu su savo talpa ir prieinamumu, kuriuos reikia planuoti. Ta pati logika atmeta lengvą atsakymą WireGuard atveju, kurio transportas yra UDP: MPTCP augina TCP posraučius ir negali sujungti to tunelio be ko nors kito projekte.
Patikrinkite, ar branduolio funkcija įjungta, prieš projektuodami aplink ją, nes daugelis distribucijų ją tiekia išjungtą. Šios trys komandos atsako per minutę.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showRinkitės pagal darbo krūvį, o ne pagal brošiūrą
Jei darbo krūvis yra daug nepriklausomų sesijų, balansavimas pagal srautų maišą gali pridėti talpos be bendradarbiavimo tolimajame gale. Jei tai vienas didelis perdavimas, padės tik sujungimo projektas, o tam projektui reikia bendradarbiaujančio partnerio. Jei reikalavimas yra, kad darbas tęstųsi linijai žuvus, atsakymas yra perjungimas, o vieno perdavimo pralaidumas neturi reikšmės.
Parašykite reikalavimą vienu sakiniu su veiksmažodžiu: viena atsarginė kopija baigiama dvigubai greičiau, arba nutrūkusi linija nesibaigia sesijos. Neaiškūs tikslai kuria projektus, kurių niekas negali priimti ar atmesti. Tada nuspręskite, kuo gali būti tolimasis galas, nes pigiausias variantas dažnai yra tas, kuris ten nereikalauja nieko naujo. Šis apribojimas pašalina daugumą brošiūros teiginių dar prieš pirmą susitikimą.
Laikykite tris pažadus atskirai reikalavimų dokumente. Projektas, kuris teigia visus tris, paprastai pateikia vieną ir tyliai daro prielaidą apie kitus. Kitas skyrius tikrina, kuris iš tikrųjų pateikiamas.
Išbandykite vieną perdavimą ir daug, tada ištraukite liniją
Palyginkite vieną nuolatinį perdavimą su keliais lygiagrečiais perdavimais į tą patį tikslą, ir užrašykite nuostolius, delsą ir kiekvienos linijos naudojimą. Pelnas tik su lygiagrečiomis sesijomis rodo srautų paskirstymą, o ne vieno srauto sujungimą. Atskirai išbandykite vieno išėjimo kanalo praradimą, nes talpa, kol abi linijos veikia, nieko nesako apie perjungimą jau nustatytai sesijai. Užrašykite maršrutą, lizdą ir pakartotinio siuntimo skaitiklius prieš kiekvieną bandymą ir po jo.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Kai vienintelis perdavimas vis dar naudoja vieną išėjimo kanalą, projektas daro būtent tai, ką reiškia srautų maišas. Kai lygiagretūs perdavimai pasiskirsto abiem, balansavimas veikia, o sujungimas ne. Užrašykite, kurį iš trijų pažadų projektas iš tikrųjų laiko, ir kitas pokalbis apie talpą prasidės nuo įrodymų, o ne nuo tiekėjo teiginio.