Два излазна канала, а један тунел: пребацивање, балансирање или спајање
Пребацивање на резерву, балансирање по токовима и спајање једног тока три су различита обећања. Две подразумеване руте дају вам прво, али не и друга два.
Две интернет линије могу учинити VPN доступнијим, а неким радним оптерећењима и бржим, али механизам одлучује шта ће се од тога догодити. Рутер са две подразумеване руте није спојен, а тунел који носи хиљаде унутрашњих веза и даље је један спољни ток. Именовати обећање прво разлика је између пројекта и скупог разочарања. Табела испод дели опције према томе шта свака тражи на удаљеном крају и шта губитак везе чини с преносом.
Три обећања, а само једно тражи партнера
Пребацивање на резерву одржава пут доступним када преферирана веза нестане. Балансирање по хешу токова распоређује независне токове на оба излазна канала. Спајање једног тока омогућава једном преносу да истовремено користи обе везе. То су различити производи с различитим захтевима, и само последњи тражи сарадњу нечега изван вашег рутера.
| 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 |
Ништа у тој табели није разлог за куповину друге линије. Она ради нешто друго: спречава да се пројекат пребацивања оцењује као да је спајање.
Зашто тунел за рутер изгледа као један ток
Рутер који балансира оптерећење хешира адресе извора и одредишта заједно с портовима, а затим шаље цео ток тамо где хеш показује. VPN тунел је један такав ток из перспективе рутера, шта год радило унутар њега. Унутрашње везе никада не стижу до одлуке о хешу, јер је спољно заглавље већ одредило пут. Зато други излазни канал може удвостручити укупни капацитет за многе кориснике и не променити ништа у великом преносу једног корисника.
Два одвојена тунела могу вам дати два кандидата, али им и даље треба намерна политика која додељује саобраћај и држи одговоре на путу којим је захтев отишао. Асиметрично рутирање уобичајен је резултат прескакања тог корака. Минимум је политика која именује ток, преферирану везу и резервну везу.
Ethernet спајање не прелази преко неповезаних добављача, јер удаљени крај мора учествовати у протоколу агрегације. Спајање преко два добављача интернета истраживачки је пројекат, осим ако не постоји крајња тачка која сарађује.
Шта вишепути TCP тражи на оба краја
Linux документација за Multipath TCP описује више подтокова који припадају једној вези. Подршка језгра на једном крају сама по себи ништа не мења, јер и партнер мора да прихвати те подтокове. Прокси на удаљеној страни други је уобичајен распоред, и он постаје компонента са сопственим капацитетом и доступношћу о којима треба планирати. Иста логика искључује једноставан одговор за WireGuard, чији је транспорт UDP: MPTCP развија TCP подтокове и не може агрегирати тај тунел без нечег другог у пројекту.
Проверите да ли је функција језгра укључена пре него што пројектујете око ње, јер многе дистрибуције је испоручују искључену. Ове три наредбе одговарају на то у минути.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show
Бирајте према радном оптерећењу, не према брошури
Ако је радно оптерећење много независних сесија, балансирање по хешу може додати капацитет без сарадње на удаљеном крају. Ако је један велики пренос, помоћи ће само пројекат агрегације, а том пројекту треба партнер који сарађује. Ако је захтев да посао настави када веза умре, одговор је пребацивање на резерву и пропусност једног преноса је неважна.
Напишите захтев у једној реченици с глаголом: једна резерва завршава двоструко брже, или испала веза не прекида сесију. Нејасни циљеви дају пројекте које нико не може прихватити ни одбити. Затим одлучите шта удаљени крај сме бити, јер најјефтинија опција често је она која тамо не тражи ништа ново. То ограничење уклања већину тврдњи из брошуре пре првог састанка.
Држите три обећања одвојено у документу захтева. Пројекат који тврди сва три обично испоручи једно и тихо претпостави остала. Следећи део проверава које је заиста испоручено.
Тестирајте један пренос и много њих, па извуците везу
Упоредите један трајни пренос с неколико паралелних преноса на исто одредиште, и забележите губитак, кашњење и искоришћење по вези за сваки. Добитак само с паралелним сесијама упућује на расподелу токова, а не на агрегацију једног тока. Тестирајте губитак једног излазног канала одвојено, јер капацитет док обе везе раде не говори ништа о пребацивању за успостављену сесију. Забележите руту, сокет и бројаче поновног преноса пре и после сваког теста.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5
Када један пренос и даље користи један излазни канал, пројекат ради тачно оно што хеш тока имплицира. Када се паралелни преноси распореде на оба, балансирање ради а агрегација не. Забележите које од три обећања пројекат заиста држи, и следећи разговор о капацитету почиње од доказа, а не од тврдње продавца.