To opkoblinger, én tunnel: fejlskift, lastfordeling eller sammenkædning
Fejlskift, lastfordeling pr. strøm og sammenkædning af én strøm er tre forskellige løfter. To standardruter giver dig det første, men ikke de to andre.
To internetlinjer kan gøre en VPN mere tilgængelig, og de kan gøre den hurtigere for nogle arbejdsbelastninger, men mekanismen afgør, hvilket af de to der sker. En router med to standardruter er ikke sammenkædet, og en tunnel, der bærer tusindvis af indre forbindelser, er stadig én ydre strøm. At navngive løftet først er forskellen mellem et design og en dyr skuffelse. Tabellen nedenfor adskiller mulighederne efter, hvad hver især kræver i den fjerne ende, og hvad et linktab gør ved en overførsel.
Tre løfter, og kun ét kræver en partner
Fejlskift holder en vej tilgængelig, når det foretrukne link forsvinder. Lastfordeling via hash på strømme spreder uafhængige strømme over begge opkoblinger. Sammenkædning af én strøm lader én overførsel bruge begge links på én gang. Det er forskellige produkter med forskellige krav, og kun det sidste kræver samarbejde fra noget uden for din router.
| 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 |
Intet i den tabel er en grund til at købe en anden linje. Det, den gør, er at forhindre, at et fejlskiftsdesign bliver vurderet, som om det var sammenkædning.
Hvorfor en tunnel ser ud som én strøm for routeren
En lastbalancerende router hasher kilde- og destinationsadresser sammen med portene og sender derefter hele strømmen derhen, hvor hashen peger. En VPN-tunnel er én sådan strøm set fra routeren, uanset hvad der kører inde i den. Indre forbindelser når aldrig hashbeslutningen, fordi det ydre header allerede har bestemt vejen. Derfor kan en anden opkobling fordoble den samlede kapacitet for mange brugere og ikke ændre noget for én brugers store overførsel.
To separate tunneller kan give dig to kandidater, men de har stadig brug for en bevidst politik, der tildeler trafik og holder svar på den vej, der bar anmodningen. Asymmetrisk routing er det sædvanlige resultat af at springe det trin over. Et minimum er en politik, der navngiver strømmen, det foretrukne link og reserve-linket.
Ethernet-sammenkædning krydser ikke uvedkommende udbydere, fordi den fjerne ende skal deltage i aggregeringsprotokollen. En sammenkædning over to udbydere er et forskningsprojekt, medmindre der findes et samarbejdende endepunkt.
Hvad multipath-TCP kræver i begge ender
Linux’ dokumentation om Multipath TCP beskriver flere understrømme, der hører til én forbindelse. Kernelunderstøttelse i den ene ende ændrer intet i sig selv, da modparten også skal acceptere disse understrømme. En proxy i den fjerne ende er den anden almindelige ordning, og den bliver en komponent med sin egen kapacitet og tilgængelighed, som skal planlægges. Den samme logik udelukker et nemt svar for WireGuard, hvis transport er UDP: MPTCP vokser TCP-understrømme og kan ikke aggregere den tunnel uden noget andet i designet.
Kontroller, om kernelfunktionen er aktiveret, før du designer omkring den, da mange distributioner leverer den slukket. Disse tre kommandoer svarer på det på et minut.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showVælg efter arbejdsbelastningen, ikke efter brochuren
Hvis arbejdsbelastningen er mange uafhængige sessioner, kan lastfordeling via hash tilføje kapacitet uden samarbejde i den fjerne ende. Hvis det er én stor overførsel, hjælper kun et aggregeringsdesign, og det design kræver en samarbejdende modpart. Hvis kravet er, at arbejdet fortsætter, når et link dør, er fejlskift svaret, og gennemstrømningen af én overførsel er irrelevant.
Skriv kravet i én sætning med et udsagnsord i: én sikkerhedskopi bliver færdig dobbelt så hurtigt, eller et tabt link afslutter ikke en session. Vage mål giver designs, som ingen kan acceptere eller afvise. Beslut derefter, hvad den fjerne ende må være, fordi den billigste mulighed ofte er den, der ikke kræver noget nyt der. Den begrænsning fjerner de fleste brochurepåstande før det første møde.
Hold de tre løfter adskilt i kravdokumentet. Et design, der påstår alle tre, leverer normalt ét og antager stiltiende de andre. Det næste afsnit tester, hvilket der faktisk leveres.
Test én overførsel og mange, og træk så et link
Sammenlign én vedvarende overførsel med flere parallelle overførsler til samme destination, og registrér tab, forsinkelse og udnyttelse pr. link for hver. En gevinst kun ved parallelle sessioner peger på strømfordeling, ikke på sammenkædning af én strøm. Test tabet af én opkobling separat, fordi kapacitet, mens begge links virker, intet siger om fejlskift for en etableret session. Registrér ruten, socketten og genudsendelsestællerne før og efter 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ørsel stadig bruger én opkobling, gør designet præcis det, et strømhash antyder. Når parallelle overførsler spredes over begge, virker lastfordelingen, og sammenkædningen gør ikke. Registrér, hvilket af de tre løfter designet faktisk holder, og den næste kapacitetssamtale begynder med beviser i stedet for en leverandørs påstand.