To oppkoblinger men én tunnel: svitsjing, fordeling eller sammenslåing
Svitsjing ved feil, fordeling per strøm og sammenslåing av én strøm er tre forskjellige løfter. To standardruter gir deg det første, og ikke de to andre.
To internettlinjer kan gjøre en VPN mer tilgjengelig, og de kan gjøre den raskere for noen arbeidsbelastninger, men mekanismen avgjør hvilken av de to som skjer. En ruter med to standardruter er ikke sammenslått, og en tunnel som bærer tusenvis av indre forbindelser er fortsatt én ytre strøm. Å navngi løftet først er forskjellen mellom et design og en dyr skuffelse. Tabellen nedenfor skiller alternativene etter hva hvert enkelt krever i den fjerne enden og hva et linjetap gjør med en overføring.
Tre løfter, og bare ett trenger en partner
Svitsjing ved feil holder en vei tilgjengelig når den foretrukne linjen forsvinner. Fordeling etter strømhash sprer uavhengige strømmer over begge oppkoblingene. Sammenslåing av én strøm lar én overføring bruke begge linjene samtidig. Det er forskjellige produkter med forskjellige krav, og bare det siste trenger samarbeid fra noe utenfor ruteren 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 en grunn til å kjøpe en annen linje. Det den gjør, er å hindre at et svitsjedesign blir vurdert som om det var sammenslåing.
Hvorfor en tunnel ser ut som én strøm for ruteren
En ruter som fordeler last, hasher kilde- og måladdresser sammen med porter, og sender deretter hele strømmen dit hashen peker. En VPN-tunnel er én slik strøm sett fra ruteren, uansett hva som kjører inne i den. Indre forbindelser når aldri hash-beslutningen, fordi den ytre headeren allerede har bestemt veien. Derfor kan en annen oppkobling doble den totale kapasiteten for mange brukere og ikke endre noe for én brukers store overføring.
To separate tunneler kan gi deg to kandidater, men de trenger fortsatt en bevisst policy som tildeler trafikk og holder svar på veien som bar forespørselen. Asymmetrisk ruting er det vanlige resultatet av å hoppe over det trinnet. Minimumet er en policy som navngir strømmen, den foretrukne linjen og reservelinjen.
Ethernet-sammenslåing krysser ikke uvedkommende leverandører, fordi den fjerne enden må delta i aggregeringsprotokollen. En sammenslåing over to leverandører er et forskningsprosjekt med mindre det finnes et samarbeidende endepunkt.
Hva flerveis-TCP krever i begge ender
Linux-dokumentasjonen om Multipath TCP beskriver flere understrømmer som tilhører én forbindelse. Kjerne-støtte i den ene enden endrer ingenting i seg selv, siden motparten også må godta disse understrømmene. En proxy i den fjerne enden er det andre vanlige oppsettet, og den blir en komponent med egen kapasitet og tilgjengelighet som må planlegges. Den samme logikken utelukker et enkelt svar for WireGuard, hvis transport er UDP: MPTCP vokser TCP-understrømmer og kan ikke aggregere den tunnelen uten noe annet i designet.
Sjekk om kjernefunksjonen er aktivert før du designer rundt den, siden mange distribusjoner leverer den avslått. Disse tre kommandoene svarer på det på et minutt.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showVelg etter arbeidsbelastningen, ikke etter brosjyren
Hvis arbeidsbelastningen er mange uavhengige økter, kan fordeling etter strømhash legge til kapasitet uten samarbeid i den fjerne enden. Hvis det er én stor overføring, hjelper bare et aggregeringsdesign, og det designet trenger en samarbeidende motpart. Hvis kravet er at arbeidet fortsetter når en linje dør, er svitsjing svaret, og gjennomstrømningen til én overføring er irrelevant.
Skriv kravet i én setning med et verb i: én sikkerhetskopi blir ferdig dobbelt så raskt, eller en falt linje avslutter ikke en økt. Vage mål gir design som ingen kan godta eller avvise. Bestem deretter hva den fjerne enden kan være, fordi det billigste alternativet ofte er det som ikke krever noe nytt der. Den begrensningen fjerner de fleste brosjyrepåstandene før det første møtet.
Hold de tre løftene atskilt i kravdokumentet. Et design som hevder alle tre, leverer vanligvis ett og forutsetter stille de andre. Den neste delen tester hvilket som faktisk leveres.
Test én overføring og mange, og trekk så ut en linje
Sammenlign én vedvarende overføring med flere parallelle overføringer til samme mål, og registrer tap, forsinkelse og utnyttelse per linje for hver. En gevinst bare med parallelle økter peker på strømfordeling, ikke på sammenslåing av én strøm. Test tapet av én oppkobling separat, fordi kapasitet mens begge linjene virker ikke sier noe om svitsjing for en etablert økt. Registrer ruten, socketen og gjensendingstellerne før og etter hver 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øringen fortsatt bruker én oppkobling, gjør designet nøyaktig det en strømhash antyder. Når parallelle overføringer spres over begge, virker fordelingen og sammenslåingen ikke. Registrer hvilket av de tre løftene designet faktisk holder, og den neste kapasitetssamtalen begynner med bevis i stedet for en leverandørpåstand.