Divi augšupielādes kanāli, bet viens tunelis: pārslēgšanās, līdzsvarošana vai apvienošana
Pārslēgšanās kļūmes gadījumā, līdzsvarošana pa plūsmām un vienas plūsmas apvienošana ir trīs dažādi solījumi. Divi noklusējuma maršruti dod pirmo, bet ne pārējos divus.
Divas interneta līnijas var padarīt VPN pieejamāku un dažiem darba apjomiem arī ātrāku, bet mehānisms izlemj, kurš no šiem diviem notiks. Maršrutētājs ar diviem noklusējuma maršrutiem nav apvienots, un tunelis, kas pārvadā tūkstošiem iekšējo savienojumu, joprojām ir viena ārējā plūsma. Solījuma nosaukšana vispirms ir atšķirība starp projektu un dārgu vilšanos. Zemāk esošā tabula sadala iespējas pēc tā, ko katra prasa tālajā galā un ko saites zudums nodara pārsūtīšanai.
Trīs solījumi, un tikai vienam vajag partneri
Pārslēgšanās kļūmes gadījumā uztur ceļu pieejamu, kad vēlamā saite pazūd. Līdzsvarošana pēc plūsmas jaucējkoda sadala neatkarīgas plūsmas pa abiem augšupielādes kanāliem. Vienas plūsmas apvienošana ļauj vienai pārsūtīšanai izmantot abas saites vienlaikus. Tie ir dažādi produkti ar dažādām prasībām, un tikai pēdējam vajag sadarbību ar kaut ko ārpus jūsu maršrutētāja.
| 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 |
Nekas tajā tabulā nav iemesls pirkt otru līniju. Tā dara ko citu: neļauj pārslēgšanās projektu vērtēt tā, it kā tas būtu apvienošana.
Kāpēc tunelis maršrutētājam izskatās kā viena plūsma
Slodzes līdzsvarošanas maršrutētājs jauc avota un galamērķa adreses kopā ar portiem un pēc tam sūta visu plūsmu tur, kur rāda jaucējkods. VPN tunelis no maršrutētāja skatpunkta ir viena šāda plūsma, lai kas tajā darbotos. Iekšējie savienojumi nekad nesasniedz jaucējkoda lēmumu, jo ārējā galvene jau ir noteikusi ceļu. Tāpēc otrs augšupielādes kanāls var divkāršot kopējo jaudu daudziem lietotājiem un neko nemainīt viena lietotāja lielajā pārsūtīšanā.
Divi atsevišķi tuneļi var dot divus kandidātus, bet tiem joprojām vajag apzinātu politiku, kas piešķir datplūsmu un notur atbildes tajā ceļā, pa kuru gāja pieprasījums. Asimetriska maršrutēšana ir ierastais šī soļa izlaišanas rezultāts. Minimums ir politika, kas nosauc plūsmu, vēlamo saiti un rezerves saiti.
Ethernet apvienošana nešķērso nesaistītus pakalpojumu sniedzējus, jo tālajam galam ir jāpiedalās apvienošanas protokolā. Apvienošana pāri diviem interneta pakalpojumu sniedzējiem ir pētniecības projekts, ja vien nepastāv sadarbojošs galapunkts.
Ko daudzceļu TCP prasa abos galos
Linux Multipath TCP dokumentācija apraksta vairākas apakšplūsmas, kas pieder vienam savienojumam. Kodola atbalsts vienā galā pats par sevi neko nemaina, jo arī partnerim ir jāpieņem šīs apakšplūsmas. Starpniekserveris tālajā pusē ir otrs ierastais risinājums, un tas kļūst par komponentu ar savu jaudu un pieejamību, kas jāplāno. Tā pati loģika izslēdz vieglu atbildi WireGuard gadījumā, kura transports ir UDP: MPTCP audzē TCP apakšplūsmas un nevar apvienot šo tuneli bez kaut kā cita projektā.
Pārbaudiet, vai kodola funkcija ir iespējota, pirms projektējat ap to, jo daudzas distribūcijas to piegādā izslēgtu. Šīs trīs komandas atbild minūtes laikā.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showIzvēlieties pēc darba apjoma, nevis pēc brošūras
Ja darba apjoms ir daudz neatkarīgu sesiju, līdzsvarošana pēc plūsmas jaucējkoda var pievienot jaudu bez sadarbības tālajā galā. Ja tas ir viens liels pārsūtījums, palīdzēs tikai apvienošanas projekts, un tam projektam vajag sadarbojošu partneri. Ja prasība ir, lai darbs turpinātos, kad saite mirst, atbilde ir pārslēgšanās, un vienas pārsūtīšanas caurlaidspēja nav svarīga.
Uzrakstiet prasību vienā teikumā ar darbības vārdu: viena rezerves kopija beidzas divreiz ātrāk, vai arī pārtrūkusi saite nebeidz sesiju. Neskaidri mērķi rada projektus, ko neviens nevar pieņemt vai noraidīt. Pēc tam izlemiet, kas tālajam galam drīkst būt, jo lētākais variants bieži ir tas, kas tur neprasa neko jaunu. Šis ierobežojums novērš lielāko daļu brošūras apgalvojumu vēl pirms pirmās sanāksmes.
Turiet trīs solījumus atsevišķi prasību dokumentā. Projekts, kas apgalvo visus trīs, parasti piegādā vienu un klusām pieņem pārējos. Nākamā sadaļa pārbauda, kurš patiešām tiek piegādāts.
Pārbaudiet vienu pārsūtīšanu un daudzas, tad izraujiet saiti
Salīdziniet vienu nepārtrauktu pārsūtīšanu ar vairākām paralēlām pārsūtīšanām uz to pašu galamērķi, un pierakstiet zudumus, aizturi un katras saites izmantojumu. Ieguvums tikai ar paralēlām sesijām norāda uz plūsmu sadali, nevis uz vienas plūsmas apvienošanu. Atsevišķi pārbaudiet viena augšupielādes kanāla zudumu, jo jauda, kamēr abas saites darbojas, neko nepasaka par pārslēgšanos jau izveidotai sesijai. Pierakstiet maršrutu, ligzdu un atkārtotas sūtīšanas skaitītājus pirms katra testa un pēc tā.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Kad vienīgā pārsūtīšana joprojām izmanto vienu augšupielādes kanālu, projekts dara tieši to, ko nozīmē plūsmas jaucējkods. Kad paralēlās pārsūtīšanas sadalās pa abām, līdzsvarošana strādā, bet apvienošana ne. Pierakstiet, kuru no trim solījumiem projekts patiešām ievēro, un nākamā saruna par jaudu sāksies ar pierādījumiem, nevis piegādātāja apgalvojumu.