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 podrazumijevane rute daju vam prvo, ali ne i druga dva.
Dvije internet linije mogu učiniti VPN dostupnijim, a nekim radnim opterećenjima i bržim, ali mehanizam odlučuje šta će se od toga dogoditi. Ruter s dvije podrazumijevane rute nije spojen, a tunel koji nosi hiljade unutrašnjih veza i dalje je jedan vanjski tok. Imenovati obećanje prvo razlika je između projekta i skupog razočaranja. Tabela ispod dijeli opcije prema tome šta svaka traži na udaljenom kraju i šta gubitak linka čini s prijenosom.
Tri obećanja, a samo jedno traži partnera
Prebacivanje na rezervni link održava put dostupnim kada preferirani link nestane. Balansiranje po hešu tokova raspoređuje nezavisne tokove na oba uzlazna kanala. Spajanje jednog toka omogućava jednom prijenosu da istovremeno koristi oba linka. To su različiti proizvodi s različitim zahtjevima, i samo posljednji traži saradnju nečega izvan vašeg rutera.
| 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 tabeli nije razlog za kupovinu druge linije. Ona radi nešto drugo: sprječava da se projekat prebacivanja ocjenjuje kao da je spajanje.
Zašto tunel za ruter izgleda kao jedan tok
Ruter koji balansira opterećenje hešira adrese izvora i odredišta zajedno s portovima, a zatim šalje cijeli tok tamo gdje heš pokazuje. VPN tunel je jedan takav tok iz perspektive rutera, šta god da radi unutar njega. Unutrašnje veze nikada ne stižu do odluke o hešu, 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 za veliki prijenos jednog korisnika.
Dva odvojena tunela mogu vam dati dva kandidata, ali im i dalje treba namjerna politika koja dodjeljuje saobraćaj i drži odgovore na putu kojim je zahtjev otišao. Asimetrično rutiranje uobičajen je rezultat preskakanja tog koraka. Minimum je politika koja imenuje tok, preferirani link i rezervni link.
Ethernet spajanje ne prelazi preko nepovezanih provajdera, jer udaljeni kraj mora učestvovati u protokolu agregacije. Spajanje preko dva ISP-a je istraživački projekat osim ako ne postoji krajnja tačka koja sarađuje.
Šta 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 ništa ne mijenja, jer i partner mora prihvatiti te podtokove. Proxy na udaljenoj strani je drugi 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 projektujete oko nje, jer mnoge distribucije je isporučuju isključenu. Ove tri komande odgovaraju na to za minutu.
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 nezavisnih sesija, balansiranje po hešu može dodati kapacitet bez saradnje na udaljenom kraju. Ako je jedan veliki prijenos, pomoći će samo projekat agregacije, a tom projektu treba partner koji sarađuje. Ako je zahtjev da posao nastavi kada link 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 ispalni link ne prekida sesiju. Nejasni ciljevi daju projekte koje niko ne može prihvatiti ni odbiti. Zatim odlučite šta 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. Projekat koji tvrdi sva tri obično isporuči jedno i tiho pretpostavi ostala. Sljedeći dio provjerava koje je zaista isporučeno.
Testirajte jedan prijenos i mnogo njih, pa izvucite link
Uporedite jedan trajni prijenos s nekoliko paralelnih prijenosa na isto odredište, i zabilježite gubitak, kašnjenje i iskorištenje po linku za svaki. Dobitak samo s paralelnim sesijama ukazuje na raspodjelu tokova, a ne na agregaciju jednog toka. Testirajte gubitak jednog uzlaznog kanala odvojeno, jer kapacitet dok oba linka rade ne govori ništa o prebacivanju za uspostavljenu sesiju. Zabilježite rutu, socket i brojače ponovnog prenosa 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, projekat radi tačno ono što heš toka implicira. Kada se paralelni prijenosi rasporede na oba, balansiranje radi a agregacija ne. Zabilježite koje od tri obećanja projekat zaista drži, i sljedeći razgovor o kapacitetu počinje od dokaza, a ne od tvrdnje prodavača.