Dwa łącza wysyłania, ale jeden tunel: przełączanie, równoważenie czy łączenie
Przełączanie przy awarii, równoważenie na przepływ i łączenie jednego przepływu to trzy różne obietnice. Dwie trasy domyślne dają pierwszą, a nie pozostałe dwie.
Dwie linie internetowe mogą uczynić VPN bardziej dostępnym, a niektórym obciążeniom dać większą prędkość, ale to mechanizm decyduje, która z tych rzeczy nastąpi. Router z dwiema trasami domyślnymi nie jest połączony, a tunel przenoszący tysiące wewnętrznych połączeń nadal jest jednym zewnętrznym przepływem. Nazwanie obietnicy jako pierwszej to różnica między projektem a kosztownym rozczarowaniem. Tabela poniżej rozdziela opcje według tego, czego każda wymaga na drugim końcu i co utrata łącza robi z transferem.
Trzy obietnice, a tylko jedna potrzebuje partnera
Przełączanie przy awarii utrzymuje ścieżkę dostępną, gdy preferowane łącze znika. Równoważenie według skrótu przepływu rozkłada niezależne przepływy na oba łącza wysyłania. Łączenie jednego przepływu pozwala jednemu transferowi używać obu łączy naraz. To różne produkty o różnych wymaganiach, i tylko ostatni potrzebuje współpracy czegoś spoza twojego routera.
| 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 |
Nic w tej tabeli nie jest powodem, by kupować drugą linię. Robi ona coś innego: nie pozwala oceniać projektu przełączania tak, jakby to było łączenie.
Dlaczego tunel wygląda dla routera jak jeden przepływ
Router równoważący obciążenie haszuje adresy źródła i celu wraz z portami, a następnie wysyła cały przepływ tam, gdzie wskazuje skrót. Tunel VPN jest z punktu widzenia routera jednym takim przepływem, cokolwiek działa w jego wnętrzu. Połączenia wewnętrzne nigdy nie docierają do decyzji o skrócie, ponieważ nagłówek zewnętrzny już wyznaczył ścieżkę. Dlatego drugie łącze wysyłania może podwoić całkowitą przepustowość dla wielu użytkowników i niczego nie zmienić w dużym transferze jednego użytkownika.
Dwa osobne tunele mogą dać dwóch kandydatów, ale nadal potrzebują świadomej polityki, która przydziela ruch i utrzymuje odpowiedzi na ścieżce, którą szło żądanie. Routing asymetryczny jest zwykłym skutkiem pominięcia tego kroku. Minimum to polityka, która nazywa przepływ, preferowane łącze i łącze zapasowe.
Łączenie Ethernet nie przechodzi przez niepowiązanych dostawców, ponieważ drugi koniec musi uczestniczyć w protokole agregacji. Łączenie przez dwóch dostawców internetu to projekt badawczy, o ile nie istnieje współpracujący punkt końcowy.
Czego wielościeżkowy TCP wymaga na obu końcach
Dokumentacja Linuksa dotycząca Multipath TCP opisuje kilka podprzepływów należących do jednego połączenia. Obsługa jądra na jednym końcu sama niczego nie zmienia, bo druga strona też musi przyjąć te podprzepływy. Serwer proxy po drugiej stronie to inne częste rozwiązanie, i staje się komponentem z własną przepustowością i dostępnością, które trzeba zaplanować. Ta sama logika wyklucza łatwą odpowiedź dla WireGuard, którego transportem jest UDP: MPTCP rozwija podprzepływy TCP i nie może zagregować tego tunelu bez czegoś jeszcze w projekcie.
Sprawdź, czy funkcja jądra jest włączona, zanim zaczniesz wokół niej projektować, bo wiele dystrybucji dostarcza ją wyłączoną. Te trzy polecenia odpowiadają na to w minutę.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showWybieraj według obciążenia, nie według broszury
Jeśli obciążeniem jest wiele niezależnych sesji, równoważenie według skrótu przepływu może dodać przepustowość bez współpracy na drugim końcu. Jeśli to jeden duży transfer, pomoże tylko projekt agregacji, a ten projekt potrzebuje współpracującego partnera. Jeśli wymaganiem jest, by praca trwała dalej, gdy łącze umiera, odpowiedzią jest przełączanie, a przepustowość jednego transferu nie ma znaczenia.
Zapisz wymaganie w jednym zdaniu z czasownikiem: jedna kopia zapasowa kończy się dwa razy szybciej, albo zerwane łącze nie kończy sesji. Niejasne cele dają projekty, których nikt nie może przyjąć ani odrzucić. Potem zdecyduj, czym może być drugi koniec, bo najtańsza opcja to często ta, która niczego tam nie wymaga. To ograniczenie usuwa większość twierdzeń z broszury jeszcze przed pierwszym spotkaniem.
Trzymaj trzy obietnice osobno w dokumencie wymagań. Projekt, który twierdzi, że spełnia wszystkie trzy, zwykle dostarcza jedną i po cichu zakłada pozostałe. Następna sekcja sprawdza, która jest rzeczywiście dostarczana.
Przetestuj jeden transfer i wiele, potem wyrwij łącze
Porównaj jeden ciągły transfer z kilkoma równoległymi transferami do tego samego celu, i zapisz straty, opóźnienie i wykorzystanie każdego łącza. Zysk tylko przy równoległych sesjach wskazuje na rozkład przepływów, a nie na agregację jednego przepływu. Przetestuj oddzielnie utratę jednego łącza wysyłania, bo przepustowość przy działających obu łączach nic nie mówi o przełączaniu dla ustanowionej sesji. Zapisz trasę, gniazdo i liczniki retransmisji przed każdym testem i po nim.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Gdy pojedynczy transfer nadal używa jednego łącza wysyłania, projekt robi dokładnie to, co sugeruje skrót przepływu. Gdy równoległe transfery rozkładają się na oba, równoważenie działa, a agregacja nie. Zapisz, którą z trzech obietnic projekt naprawdę spełnia, a następna rozmowa o przepustowości zacznie się od dowodów, nie od twierdzenia dostawcy.