Två upplänkar men en tunnel: växling, lastdelning eller sammanslagning
Växling vid fel, lastdelning per flöde och sammanslagning av ett enda flöde är tre olika löften. Två standardrutter ger dig det första, och inte de andra två.
Två internetlinjer kan göra en VPN mer tillgänglig, och de kan göra den snabbare för vissa arbetsbelastningar, men mekanismen avgör vilket av de två som händer. En router med två standardrutter är inte sammanslagen, och en tunnel som bär tusentals inre anslutningar är fortfarande ett enda yttre flöde. Att namnge löftet först är skillnaden mellan en design och en dyr besvikelse. Tabellen nedan skiljer alternativen åt efter vad varje kräver i fjärränden och vad en länkförlust gör med en överföring.
Tre löften, och bara ett behöver en partner
Växling vid fel håller en väg tillgänglig när den föredragna länken försvinner. Lastdelning per flödeshash sprider oberoende flöden över båda upplänkarna. Sammanslagning av ett enda flöde låter en överföring använda båda länkarna samtidigt. Det är olika produkter med olika krav, och bara den sista behöver samarbete från något utanför 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 |
Ingenting i den tabellen är ett skäl att köpa en andra linje. Det den gör är att hindra att en växlingsdesign bedöms som om den vore sammanslagning.
Varför en tunnel ser ut som ett enda flöde för routern
En router som lastbalanserar hashar käll- och måladdresser tillsammans med portar och skickar sedan hela flödet dit hashen pekar. En VPN-tunnel är ett sådant flöde sett från routern, vad som än körs inuti den. Inre anslutningar når aldrig hashbeslutet, eftersom det yttre huvudet redan har bestämt vägen. Därför kan en andra upplänk fördubbla den totala kapaciteten för många användare och inte ändra något för en användares stora överföring.
Två separata tunnlar kan ge dig två kandidater, men de behöver fortfarande en medveten policy som tilldelar trafik och håller svar på den väg som bar begäran. Asymmetrisk routning är det vanliga resultatet av att hoppa över det steget. Minimumet är en policy som namnger flödet, den föredragna länken och reservlänken.
Ethernet-sammanslagning korsar inte orelaterade leverantörer, eftersom fjärränden måste delta i aggregeringsprotokollet. En sammanslagning över två leverantörer är ett forskningsprojekt om det inte finns en samarbetande ändpunkt.
Vad flervägs-TCP kräver i båda ändar
Linux dokumentation om Multipath TCP beskriver flera underflöden som hör till en anslutning. Kärnstöd i ena änden ändrar ingenting i sig, eftersom motparten också måste acceptera dessa underflöden. En proxy i fjärränden är det andra vanliga arrangemanget, och den blir en komponent med egen kapacitet och tillgänglighet att planera för. Samma logik utesluter ett enkelt svar för WireGuard, vars transport är UDP: MPTCP växer TCP-underflöden och kan inte aggregera den tunneln utan något annat i designen.
Kontrollera om kärnfunktionen är aktiverad innan du designar runt den, eftersom många distributioner levererar den avstängd. Dessa tre kommandon svarar på det på en minut.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showVälj efter arbetsbelastningen, inte efter broschyren
Om arbetsbelastningen är många oberoende sessioner kan lastdelning per flödeshash lägga till kapacitet utan samarbete i fjärränden. Om det är en stor överföring hjälper bara en aggregeringsdesign, och den designen behöver en samarbetande motpart. Om kravet är att arbetet fortsätter när en länk dör är växling svaret, och genomströmningen för en enda överföring är irrelevant.
Skriv kravet i en mening med ett verb i: en säkerhetskopiering blir klar dubbelt så snabbt, eller en fallen länk avslutar inte en session. Vaga mål ger designer som ingen kan acceptera eller avvisa. Bestäm sedan vad fjärränden får vara, eftersom det billigaste alternativet ofta är det som inte kräver något nytt där. Den begränsningen tar bort de flesta broschyrpåståenden före det första mötet.
Håll de tre löftena åtskilda i kravdokumentet. En design som hävdar alla tre levererar vanligtvis ett och förutsätter tyst de andra. Nästa avsnitt testar vilket som faktiskt levereras.
Testa en överföring och många, dra sedan ut en länk
Jämför en varaktig överföring med flera parallella överföringar till samma mål, och registrera förlust, fördröjning och utnyttjande per länk för varje. En vinst bara med parallella sessioner pekar på flödesfördelning, inte på sammanslagning av ett enda flöde. Testa förlusten av en upplänk separat, eftersom kapacitet medan båda länkarna fungerar inte säger något om växling för en etablerad session. Registrera rutten, socketen och omsändningsräknarna före och efter varje test.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5När den enda överföringen fortfarande använder en upplänk gör designen exakt det en flödeshash antyder. När parallella överföringar sprids över båda fungerar lastdelningen och sammanslagningen inte. Registrera vilket av de tre löftena designen verkligen håller, och nästa kapacitetssamtal börjar med bevis i stället för en leverantörs påstående.