To oppkoblingar men éin tunnel: svitsjing, fordeling eller samanslåing
Svitsjing ved feil, fordeling per straum og samanslåing av éin straum er tre ulike lovnader. To standardruter gir deg den første, og ikkje dei to andre.
To internettlinjer kan gjere ein VPN meir tilgjengeleg, og dei kan gjere han raskare for nokre arbeidsbelastningar, men mekanismen avgjer kva av dei to som skjer. Ein ruter med to standardruter er ikkje samanslått, og ein tunnel som ber tusenvis av indre samband er framleis éin ytre straum. Å namngje lovnaden først er skilnaden mellom eit design og ei dyr skuffing. Tabellen nedanfor skil alternativa etter kva kvart eitt treng i den fjerne enden og kva eit linjetap gjer med ein overføring.
Tre lovnader, og berre éin treng ein partnar
Svitsjing ved feil held ein veg tilgjengeleg når den føretrekte linja forsvinn. Fordeling etter straumhash spreier uavhengige straumar over begge oppkoblingane. Samanslåing av éin straum lèt éin overføring bruke begge linjene samstundes. Det er ulike produkt med ulike krav, og berre det siste treng samarbeid frå noko utanfor rutaren din.
| 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 |
Ingenting i den tabellen er ein grunn til å kjøpe ei anna linje. Det han gjer, er å hindre at eit svitsjedesign blir vurdert som om det var samanslåing.
Kvifor ein tunnel ser ut som éin straum for rutaren
Ein ruter som fordeler last, hashar kjelde- og måladdresse saman med portar, og sender deretter heile straumen dit hashen peikar. Ein VPN-tunnel er éin slik straum sett frå rutaren, uansett kva som køyrer inne i han. Indre samband når aldri hash-avgjerda, fordi den ytre headeren alt har bestemt vegen. Difor kan ei anna oppkobling doble den totale kapasiteten for mange brukarar og ikkje endre noko for den store overføringa til éin brukar.
To separate tunnelar kan gje deg to kandidatar, men dei treng framleis ein medviten politikk som tildeler trafikk og held svar på vegen som bar førespurnaden. Asymmetrisk ruting er det vanlege resultatet av å hoppe over det steget. Minimumet er ein politikk som namngjev straumen, den føretrekte linja og reservelinja.
Ethernet-samanslåing kryssar ikkje uvedkommande leverandørar, fordi den fjerne enden må delta i aggregeringsprotokollen. Ei samanslåing over to leverandørar er eit forskingsprosjekt med mindre det finst eit samarbeidande endepunkt.
Kva fleirvegs-TCP krev i begge endar
Linux-dokumentasjonen om Multipath TCP skildrar fleire understraumar som høyrer til éin samband. Kjernestøtte i den eine enden endrar ingenting i seg sjølv, sidan motparten òg må godta desse understraumane. Ein proxy i den fjerne enden er det andre vanlege oppsettet, og han blir ein komponent med eigen kapasitet og tilgjenge som må planleggjast. Den same logikken utelukkar eit enkelt svar for WireGuard, der transporten er UDP: MPTCP veks TCP-understraumar og kan ikkje aggregere den tunnelen utan noko anna i designet.
Sjekk om kjernefunksjonen er slått på før du designar rundt han, sidan mange distribusjonar leverer han avslått. Desse tre kommandoane svarar på det på eit minutt.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showVel etter arbeidsbelastninga, ikkje etter brosjyren
Viss arbeidsbelastninga er mange uavhengige økter, kan fordeling etter straumhash leggje til kapasitet utan samarbeid i den fjerne enden. Viss det er éin stor overføring, hjelper berre eit aggregeringsdesign, og det designet treng ein samarbeidande motpart. Viss kravet er at arbeidet held fram når ei linje døyr, er svitsjing svaret, og gjennomstrøyminga til éin overføring er irrelevant.
Skriv kravet i éi setning med eit verb i: ein sikkerheitskopi blir ferdig dobbelt så raskt, eller ei fallen linje avsluttar ikkje ei økt. Vage mål gir design som ingen kan godta eller avvise. Bestem deretter kva den fjerne enden kan vere, fordi det billegaste alternativet ofte er det som ikkje krev noko nytt der. Den avgrensinga fjernar dei fleste brosjyrepåstandane før det første møtet.
Hald dei tre lovnadene skilde i kravdokumentet. Eit design som hevdar alle tre, leverer vanlegvis eitt og føreset stille dei andre. Den neste delen testar kva som faktisk blir levert.
Test éin overføring og mange, og trekk så ut ei linje
Samanlikn éin vedvarande overføring med fleire parallelle overføringar til same mål, og registrer tap, forseinking og utnytting per linje for kvar. Ei vinning berre med parallelle økter peikar på straumfordeling, ikkje på samanslåing av éin straum. Test tapet av éi oppkobling separat, fordi kapasitet medan begge linjene verkar ikkje seier noko om svitsjing for ei etablert økt. Registrer ruta, socketen og attsendingsteljarane før og etter kvar test.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Når den enkelte overføringa framleis brukar éi oppkobling, gjer designet nøyaktig det ein straumhash antydar. Når parallelle overføringar blir spreidde over begge, verkar fordelinga og samanslåinga ikkje. Registrer kva av dei tre lovnadene designet faktisk held, og den neste kapasitetssamtalen byrjar med prov i staden for ein leverandørpåstand.