Dva uzlazna kanala, a jedan tunel: prebacivanje, balansiranje ili spajanje
Prebacivanje na rezervu, balansiranje po tokovima i spajanje jednog toka tri su različita obećanja. Dvije zadane rute daju vam prvo, ali ne i druga dva.
Dvije internetske linije mogu VPN učiniti dostupnijim, a nekim radnim opterećenjima i bržim, ali mehanizam odlučuje što će se od toga dogoditi. Usmjerivač s dvije zadane rute nije spojen, a tunel koji nosi tisuće unutarnjih veza i dalje je jedan vanjski tok. Imenovati obećanje prvo razlika je između projekta i skupa razočaranja. Tablica u nastavku dijeli opcije prema tome što svaka traži na udaljenom kraju i što gubitak veze čini s prijenosom.
Tri obećanja, a samo jedno traži partnera
Prebacivanje na rezervu održava put dostupnim kada preferirana veza nestane. Balansiranje po hashu tokova raspoređuje neovisne tokove na oba uzlazna kanala. Spajanje jednog toka omogućuje jednom prijenosu da istodobno koristi obje veze. To su različiti proizvodi s različitim zahtjevima, i samo posljednji traži suradnju nečega izvan vašeg usmjerivača.
| 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 |
Ništa u toj tablici nije razlog za kupnju druge linije. Ona radi nešto drugo: sprječava da se projekt prebacivanja ocjenjuje kao da je spajanje.
Zašto tunel za usmjerivač izgleda kao jedan tok
Usmjerivač koji balansira opterećenje hashira adrese izvora i odredišta zajedno s portovima, a zatim šalje cijeli tok tamo gdje hash pokazuje. VPN tunel je jedan takav tok iz perspektive usmjerivača, što god radilo unutar njega. Unutarnje veze nikada ne stižu do odluke o hashu, jer je vanjsko zaglavlje već odredilo put. Zato drugi uzlazni kanal može udvostručiti ukupni kapacitet za mnoge korisnike i ne promijeniti ništa u velikom prijenosu jednog korisnika.
Dva odvojena tunela mogu vam dati dva kandidata, ali im i dalje treba namjerna politika koja dodjeljuje promet i drži odgovore na putu kojim je zahtjev otišao. Asimetrično usmjeravanje uobičajen je rezultat preskakanja tog koraka. Minimum je politika koja imenuje tok, preferiranu vezu i rezervnu vezu.
Ethernet spajanje ne prelazi preko nepovezanih davatelja, jer udaljeni kraj mora sudjelovati u protokolu agregacije. Spajanje preko dva davatelja internetskih usluga istraživački je projekt osim ako ne postoji krajnja točka koja surađuje.
Što višeputni TCP traži na oba kraja
Linux dokumentacija za Multipath TCP opisuje više podtokova koji pripadaju jednoj vezi. Podrška kernela na jednom kraju sama po sebi ne mijenja ništa, jer i partner mora prihvatiti te podtokove. Proxy na udaljenoj strani drugi je uobičajen raspored, i on postaje komponenta s vlastitim kapacitetom i dostupnošću o kojima treba planirati. Ista logika isključuje jednostavan odgovor za WireGuard, čiji je transport UDP: MPTCP razvija TCP podtokove i ne može agregirati taj tunel bez nečeg drugog u projektu.
Provjerite je li funkcija kernela uključena prije nego što projektirate oko nje, jer mnoge distribucije je isporučuju isključenu. Ove tri naredbe odgovaraju na to u minuti.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showBirajte prema radnom opterećenju, ne prema brošuri
Ako je radno opterećenje mnogo neovisnih sesija, balansiranje po hashu može dodati kapacitet bez suradnje na udaljenom kraju. Ako je jedan veliki prijenos, pomoći će samo projekt agregacije, a tom projektu treba partner koji surađuje. Ako je zahtjev da posao nastavi kada veza umre, odgovor je prebacivanje na rezervu i propusnost jednog prijenosa je nevažna.
Napišite zahtjev u jednoj rečenici s glagolom: jedna rezerva završava dvostruko brže, ili ispala veza ne prekida sesiju. Nejasni ciljevi daju projekte koje nitko ne može prihvatiti ni odbiti. Zatim odlučite što udaljeni kraj smije biti, jer najjeftinija opcija često je ona koja tamo ne traži ništa novo. To ograničenje uklanja većinu tvrdnji iz brošure prije prvog sastanka.
Držite tri obećanja odvojeno u dokumentu zahtjeva. Projekt koji tvrdi sva tri obično isporuči jedno i tiho pretpostavi ostala. Sljedeći dio provjerava koje je doista isporučeno.
Testirajte jedan prijenos i mnogo njih, pa izvucite vezu
Usporedite jedan trajni prijenos s nekoliko paralelnih prijenosa na isto odredište, i zabilježite gubitak, kašnjenje i iskorištenje po vezi za svaki. Dobitak samo s paralelnim sesijama upućuje na raspodjelu tokova, a ne na agregaciju jednog toka. Testirajte gubitak jednog uzlaznog kanala odvojeno, jer kapacitet dok obje veze rade ne govori ništa o prebacivanju za uspostavljenu sesiju. Zabilježite rutu, socket i brojače ponovnog prijenosa prije i poslije svakog testa.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Kada jedan prijenos i dalje koristi jedan uzlazni kanal, projekt radi točno ono što hash toka implicira. Kada se paralelni prijenosi rasporede na oba, balansiranje radi a agregacija ne. Zabilježite koje od tri obećanja projekt doista drži, i sljedeći razgovor o kapacitetu počinje od dokaza, a ne od tvrdnje prodavača.