Két feltöltő kapcsolat, mégis egy alagút: átváltás, terheléselosztás vagy összekapcsolás
A hibára váltás, a folyamonkénti elosztás és az egyetlen folyam összevonása három különböző ígéret. Két alapértelmezett útvonal az elsőt adja, a másik kettőt nem.
Két internetvonal elérhetőbbé tehet egy VPN-t, és bizonyos munkaterheléseknél gyorsabbá is, de a mechanizmus dönti el, melyik történik meg. A két alapértelmezett útvonallal rendelkező router nincs összekapcsolva, és az ezer belső kapcsolatot szállító alagút továbbra is egyetlen külső folyam. Az ígéret előzetes megnevezése a különbség a terv és a drága csalódás között. Az alábbi táblázat aszerint választja szét a lehetőségeket, hogy melyik mit igényel a távoli végén, és mit tesz a kapcsolat elvesztése egy átvitellel.
Három ígéret, és csak egynek kell partner
A hibára váltás elérhetően tart egy útvonalat, amikor az előnyben részesített kapcsolat eltűnik. A folyamhash-alapú elosztás független folyamokat oszt szét a két feltöltő kapcsolaton. Az egyetlen folyam összevonása lehetővé teszi, hogy egy átvitel egyszerre használja mindkét kapcsolatot. Ezek különböző követelményű termékek, és csak az utóbbinak kell a routeren kívüli valami együttműködése.
| 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 |
A táblázatban semmi nem ok arra, hogy második vonalat vegyen. Amit tesz, az az, hogy megakadályozza a hibára váltó terv értékelését úgy, mintha összekapcsolás lenne.
Miért tűnik az alagút egyetlen folyamnak a router számára
A terhelést elosztó router a forrás- és célcímet a portokkal együtt hash-eli, majd az egész folyamot oda küldi, ahová a hash mutat. A VPN-alagút a router szemszögéből egy ilyen folyam, bármi is fut benne. A belső kapcsolatok soha nem jutnak el a hash döntéséig, mert a külső fejléc már meghatározta az útvonalat. Ezért képes egy második feltöltő kapcsolat megduplázni a teljes kapacitást sok felhasználó számára, és semmit sem változtatni egyetlen felhasználó nagy átvitelén.
Két külön alagút két jelöltet adhat, de még mindig kell hozzájuk egy szándékos szabály, amely kiosztja a forgalmat, és a válaszokat azon az úton tartja, amely a kérést szállította. Az aszimmetrikus útválasztás a lépés kihagyásának szokásos eredménye. A minimum egy olyan szabály, amely megnevezi a folyamot, az előnyben részesített kapcsolatot és a tartalék kapcsolatot.
Az Ethernet összekapcsolás nem lép át egymástól független szolgáltatók között, mert a távoli végnek részt kell vennie az aggregációs protokollban. Két internetszolgáltató közötti összekapcsolás kutatási projekt, hacsak nincs együttműködő végpont.
Mit igényel a többutas TCP mindkét végén
A Linux Multipath TCP dokumentációja több, egy kapcsolathoz tartozó al-folyamot ír le. Az egyik végén lévő kernel-támogatás önmagában semmit nem változtat, mert a partnernek is el kell fogadnia ezeket az al-folyamokat. A távoli oldali proxy a másik szokásos elrendezés, és saját kapacitással és rendelkezésre állással rendelkező komponenssé válik, amelyre tervezni kell. Ugyanez a logika zárja ki a könnyű választ a WireGuard esetében, amelynek szállítása UDP: az MPTCP TCP al-folyamokat növeszt, és a tervben más nélkül nem tudja összevonni azt az alagutat.
Ellenőrizze, hogy a kernelfunkció engedélyezve van-e, mielőtt köré tervezne, mert sok disztribúció kikapcsolva szállítja. Ez a három parancs egy perc alatt válaszol erre.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showA munkaterhelés alapján válasszon, ne a prospektus alapján
Ha a munkaterhelés sok független munkamenet, a folyamhash-alapú elosztás kapacitást adhat a távoli vég együttműködése nélkül. Ha egyetlen nagy átvitel, csak az aggregációs terv segít, és annak együttműködő partner kell. Ha a követelmény az, hogy a munka folytatódjon a kapcsolat halálakor, a válasz a hibára váltás, és egyetlen átvitel áteresztőképessége irreleváns.
Írja le a követelményt egy igét tartalmazó mondatban: egy biztonsági mentés kétszer olyan gyorsan fejeződik be, vagy egy kiesett kapcsolat nem fejez be egy munkamenetet. A homályos célok olyan terveket szülnek, amelyeket senki nem tud elfogadni vagy elutasítani. Utána döntse el, mi lehet a távoli vég, mert a legolcsóbb lehetőség gyakran az, amely ott semmi újat nem igényel. Ez a korlát a prospektus állításainak többségét kiszűri az első megbeszélés előtt.
Tartsa külön a három ígéretet a követelménydokumentumban. Az a terv, amely mindhármat állítja, általában egyet szállít, és csendben feltételezi a többit. A következő rész azt vizsgálja, melyik valósul meg valójában.
Teszteljen egy átvitelt és sokakat, majd húzzon ki egy kapcsolatot
Hasonlítson össze egy folyamatos átvitelt több párhuzamos, ugyanarra a célra irányuló átvitellel, és jegyezze fel mindegyiknél a veszteséget, a késleltetést és a kapcsolatonkénti kihasználtságot. A nyereség csak párhuzamos munkameneteknél a folyamok szétosztására utal, nem az egyetlen folyam összevonására. Tesztelje külön az egyik feltöltő kapcsolat elvesztését, mert a kapacitás, miközben mindkét kapcsolat működik, semmit nem mond a hibára váltásról egy meglévő munkamenet esetében. Rögzítse az útvonalat, a socketet és az újraküldési számlálókat minden teszt előtt és után.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Amikor az egyetlen átvitel továbbra is egy feltöltő kapcsolatot használ, a terv pontosan azt teszi, amit a folyamhash sugall. Amikor a párhuzamos átvitelek szétoszlanak mindkettőn, az elosztás működik, az összevonás nem. Jegyezze fel, melyik ígéretet tartja be a terv valójában, és a következő kapacitásbeszélgetés bizonyítékokkal indul, nem szállítói állítással.