{"id":53735,"date":"2019-12-09T00:00:00","date_gmt":"2019-12-08T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/nastoyashhee-summirovanie-internet-kanalov-openmptcprouter"},"modified":"2020-02-18T14:01:40","modified_gmt":"2020-02-18T11:01:40","slug":"nastoyashhee-summirovanie-internet-kanalov-openmptcprouter","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/nastoyashhee-summirovanie-internet-kanalov-openmptcprouter","title":{"rendered":"Prawdziwe sumowanie kana\u0142\u00f3w internetowych \u2014 OpenMPTCPRouter","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Prawdziwe
\n
\nCzy mo\u017cna po\u0142\u0105czy\u0107 kilka kana\u0142\u00f3w internetowych w jeden? Wok\u00f3\u0142 tego tematu kr\u0105\u017cy wiele nieporozumie\u0144 i mit\u00f3w, nawet do\u015bwiadczeni in\u017cynierowie sieciowi cz\u0119sto nie wiedz\u0105, \u017ce jest to mo\u017cliwe. W wi\u0119kszo\u015bci przypadk\u00f3w po\u0142\u0105czenie kana\u0142\u00f3w b\u0142\u0119dnie nazywa si\u0119 r\u00f3wnowa\u017ceniem ruchu na poziomie NAT lub failover. Prawdziwe sumowanie pozwala przes\u0142a\u0107 jedno pojedyncze po\u0142\u0105czenie TCP jednocze\u015bnie przez wszystkie kana\u0142y internetowe<\/b>, na przyk\u0142ad transmisj\u0119 wideo, tak aby przy przerwaniu kt\u00f3regokolwiek z kana\u0142\u00f3w internetowych nadawanie nie zosta\u0142o przerwane. <\/p>\n

Istniej\u0105 drogie komercyjne rozwi\u0105zania do transmisji wideo, ale takie urz\u0105dzenia kosztuj\u0105 wiele tysi\u0119cy dolar\u00f3w. W artykule opisano konfiguracj\u0119 darmowego, otwartego pakietu OpenMPTCPRouter oraz obalane s\u0105 popularne mity o sumowaniu kana\u0142\u00f3w.
\n<\/a><\/noindex><\/p>\n

Mity o sumowaniu kana\u0142\u00f3w<\/h2>\n

\nJest wiele domowych router\u00f3w, kt\u00f3re wspieraj\u0105 funkcj\u0119 Multi-WAN. Czasami producenci nazywaj\u0105 to sumowaniem kana\u0142\u00f3w, co nie jest do ko\u0144ca poprawne. Wiele os\u00f3b zajmuj\u0105cych si\u0119 sieciami wierzy, \u017ce poza LACP<\/a><\/noindex> i sumowaniem na poziomie L2, nie ma \u017cadnych innych sposob\u00f3w \u0142\u0105czenia kana\u0142\u00f3w. Cz\u0119sto s\u0142ysza\u0142em, \u017ce jest to ca\u0142kowicie niemo\u017cliwe od os\u00f3b pracuj\u0105cych w telekomunikacji. Dlatego spr\u00f3bujemy rozwik\u0142a\u0107 popularne mity. <\/p>\n

R\u00f3wnowa\u017cenie na poziomie po\u0142\u0105cze\u0144 IP<\/h2>\n

\nTo naj\u0142atwiejszy i najpopularniejszy spos\u00f3b wykorzystania kilku kana\u0142\u00f3w internetowych jednocze\u015bnie. Dla uproszczenia za\u0142\u00f3\u017cmy, \u017ce macie trzech dostawc\u00f3w internetowych, ka\u017cdy przydziela wam prawdziwy adres IP ze swojej sieci. Wszyscy ci dostawcy s\u0105 pod\u0142\u0105czeni do routera z funkcj\u0105 Multi-WAN. Mo\u017ce to by\u0107 OpenWRT z pakietem mwan3, mikrotik, ubiquiti lub jakikolwiek inny domowy router, bior\u0105c pod uwag\u0119, \u017ce teraz taka opcja nie jest ju\u017c rzadko\u015bci\u0105.<\/p>\n

Aby zobrazowa\u0107 sytuacj\u0119, za\u0142\u00f3\u017cmy, \u017ce dostawcy przydzielili nam takie adresy:<\/p>\n

WAN1 \u2014 11.11.11.11\nWAN2 \u2014 22.22.22.22\nWAN2 \u2014 33.33.33.33\n<\/code><\/pre>\n
\nTo znaczy, pod\u0142\u0105czaj\u0105c si\u0119 do zdalnego serwera example.com<\/b> Przez ka\u017cdego z dostawc\u00f3w, zdalny serwer zobaczy trzy niezale\u017cne source IP klienta. Load balancing pozwala na podzia\u0142 obci\u0105\u017cenia mi\u0119dzy kana\u0142y i wykorzystanie ich wszystkich jednocze\u015bnie. Dla uproszczenia za\u0142\u00f3\u017cmy, \u017ce dzielimy obci\u0105\u017cenie r\u00f3wno pomi\u0119dzy wszystkimi kana\u0142ami. W rezultacie, gdy klient otwiera stron\u0119, na kt\u00f3rej s\u0105 przyk\u0142adowo trzy obrazy, \u0142aduje ka\u017cdy obraz przez oddzielnego dostawc\u0119. Po stronie strony wygl\u0105da to jak po\u0142\u0105czenia z trzech r\u00f3\u017cnych IP.<\/p>\n
\"Prawdziwe
\nPrzy balansowaniu na poziomie po\u0142\u0105cze\u0144, ka\u017cde po\u0142\u0105czenie TCP przebiega przez oddzielnego dostawc\u0119.<\/p>\n
Taki tryb balansowania cz\u0119sto niesie za sob\u0105 problemy dla u\u017cytkownik\u00f3w. Na przyk\u0142ad wiele stron ostro wi\u0105\u017ce cookies i tokeny z adresem IP klienta, a je\u015bli nagle si\u0119 zmieni, zapytanie jest odrzucane lub klient zostaje wylogowany na stronie. To cz\u0119sto zdarza si\u0119 w systemach bankowo\u015bci internetowej i na innych stronach z surowymi zasadami sesji u\u017cytkownik\u00f3w. Oto prosty, obrazowy przyk\u0142ad: pliki muzyczne na VK.com s\u0105 dost\u0119pne tylko przy wa\u017cnym kluczu sesji, kt\u00f3ry jest powi\u0105zany z IP, a klienci u\u017cywaj\u0105cy takiego balansowania cz\u0119sto nie mog\u0105 odtwarza\u0107 audio, poniewa\u017c zapytanie posz\u0142o nie przez tego dostawc\u0119, do kt\u00f3rego przypisana jest sesja.<\/p>\n
\"Prawdziwe
\nPodczas pobierania torrent\u00f3w, load balancing na poziomie po\u0142\u0105cze\u0144 sumuje przepustowo\u015b\u0107 wszystkich kana\u0142\u00f3w.<\/p>\n
Taki spos\u00f3b balansowania pozwala uzyska\u0107 sumowanie pr\u0119dko\u015bci \u0142\u0105cza internetowego przy u\u017cyciu wielu po\u0142\u0105cze\u0144. Na przyk\u0142ad, je\u015bli ka\u017cdy z trzech dostawc\u00f3w ma pr\u0119dko\u015b\u0107 100 Megabit\u00f3w, to podczas pobierania torrent\u00f3w uzyskamy 300 Megabit\u00f3w. Poniewa\u017c torrent otwiera wiele po\u0142\u0105cze\u0144, kt\u00f3re s\u0105 rozdzielane mi\u0119dzy wszystkich dostawc\u00f3w i w rezultacie wykorzystuj\u0105 ca\u0142y kana\u0142.<\/p>\n
Wa\u017cne jest zrozumienie, \u017ce jedno jedyne po\u0142\u0105czenie TCP zawsze przechodzi tylko przez jednego dostawc\u0119. To znaczy, \u017ce je\u015bli \u015bci\u0105gamy jeden du\u017cy plik przez HTTP, to to po\u0142\u0105czenie b\u0119dzie realizowane przez jednego z dostawc\u00f3w, a je\u015bli po\u0142\u0105czenie z tym dostawc\u0105 zostanie przerwane, to pobieranie r\u00f3wnie\u017c si\u0119 zatrzyma. <\/p>\n
\"Prawdziwe
\nJedno po\u0142\u0105czenie zawsze b\u0119dzie u\u017cywa\u0107 tylko jednego kana\u0142u internetowego.<\/p>\n
To samo dotyczy transmisji wideo. Je\u015bli nadajesz strumieniowo na przyk\u0142ad na Twitchu, balansowanie na poziomie po\u0142\u0105cze\u0144 IP nie przyniesie \u017cadnych szczeg\u00f3lnych korzy\u015bci, poniewa\u017c strumie\u0144 wideo b\u0119dzie przesy\u0142any w obr\u0119bie jednego po\u0142\u0105czenia IP. W takim przypadku, je\u015bli u dostawcy WAN wyst\u0105pi\u0105 problemy z \u0142\u0105czem, takie jak utrata pakiet\u00f3w lub spadek pr\u0119dko\u015bci, nie b\u0119dziesz w stanie w mgnieniu oka prze\u0142\u0105czy\u0107 si\u0119 na innego dostawc\u0119. Transmisja b\u0119dzie musia\u0142a zosta\u0107 wstrzymana, a nast\u0119pnie po\u0142\u0105czona na nowo. <\/p>\n
Sumowanie kana\u0142\u00f3w<\/h2>\n
\nSumowanie kana\u0142\u00f3w w praktyce pozwala na przes\u0142anie jednego po\u0142\u0105czenia do Twitcha przez wszystkich dostawc\u00f3w w taki spos\u00f3b, \u017ce je\u015bli kt\u00f3rakolwiek z firm dostarczaj\u0105cych \u0142\u0105cze przestanie dzia\u0142a\u0107, po\u0142\u0105czenie nie zostanie zerwane. To zadanie jest zaskakuj\u0105co skomplikowane i nadal nie ma na nie optymalnego rozwi\u0105zania. Wielu ludzi nawet nie wie, \u017ce jest to mo\u017cliwe! <\/p>\n
Z poprzednich ilustracji pami\u0119tamy, \u017ce serwer Twitch mo\u017ce przyj\u0105\u0107 od nas strumie\u0144 wideo tylko z jednego adresu IP \u017ar\u00f3d\u0142owego, co oznacza, \u017ce musi by\u0107 on zawsze sta\u0142y, niezale\u017cnie od tego, kt\u00f3rzy dostawcy przestali dzia\u0142a\u0107, a kt\u00f3rzy s\u0105 aktywni. Aby to osi\u0105gn\u0105\u0107, potrzebujemy serwera sumuj\u0105cego, kt\u00f3ry b\u0119dzie terminowa\u0142 wszystkie nasze po\u0142\u0105czenia i \u0142\u0105czy\u0142 je w jedno.<\/p>\n
\"Prawdziwe
\nSerwer sumuj\u0105cy agreguje wszystkie kana\u0142y w jeden tunel. Wszystkie po\u0142\u0105czenia odbywaj\u0105 si\u0119 z adresu serwera sumuj\u0105cego.<\/p>\n
W tej strukturze wykorzystywani s\u0105 wszyscy dostawcy, a wy\u0142\u0105czenie kt\u00f3rego\u015b z nich nie spowoduje zerwania po\u0142\u0105czenia z serwerem Twitch. W istocie jest to specjalny tunel VPN, pod kt\u00f3rym dzia\u0142a kilka po\u0142\u0105cze\u0144 internetowych. G\u0142\u00f3wnym celem tego rozwi\u0105zania jest uzyskanie jak najwy\u017cszej jako\u015bci kana\u0142u komunikacyjnego. Je\u015bli jeden z dostawc\u00f3w zacznie mie\u0107 problemy, utrat\u0119 pakiet\u00f3w lub zwi\u0119kszenie op\u00f3\u017anie\u0144, nie powinno to w \u017caden spos\u00f3b wp\u0142yn\u0105\u0107 na jako\u015b\u0107 komunikacji, poniewa\u017c obci\u0105\u017cenie automatycznie rozdzieli si\u0119 na inne, lepszej jako\u015bci kana\u0142y, kt\u00f3rymi dysponujemy. <\/p>\n
Rozwi\u0105zania komercyjne<\/h3>\n
\nProblem ten od dawna niepokoi osoby prowadz\u0105ce transmisje na \u017cywo event\u00f3w i nie maj\u0105ce dost\u0119pu do jako\u015bciowego internetu. Dla takich sytuacji istnieje kilka rozwi\u0105za\u0144 komercyjnych, na przyk\u0142ad firma Teradek produkuje takie monstrualne routery, do kt\u00f3rych wk\u0142ada si\u0119 ca\u0142e paczki modem\u00f3w USB:<\/p>\n
\"Prawdziwe
\nRouter do strumieniowego przesy\u0142ania wideo z funkcj\u0105 sumowania kana\u0142\u00f3w<\/p>\n
W takich urz\u0105dzeniach zwykle wbudowana jest mo\u017cliwo\u015b\u0107 przechwytywania sygna\u0142u wideo przez HDMI lub SDI. Wraz z routerem sprzedawana jest subskrypcja na us\u0142ug\u0119 sumowania kana\u0142\u00f3w, a tak\u017ce przetwarzania strumienia wideo, jego transkodowania i retransmisji dalej. Cena takich urz\u0105dze\u0144 zaczyna si\u0119 od 2k$ z zestawem modem\u00f3w, plus oddzielna subskrypcja na us\u0142ug\u0119. <\/p>\n
Czasami wygl\u0105da to do\u015b\u0107 przera\u017caj\u0105co:<\/p>\n
\"Prawdziwe
\n<\/p>\n
Konfiguracja OpenMPTCPRouter<\/h2>\n
\nProtok\u00f3\u0142 MP-TCP<\/a><\/noindex> (MultiPath TCP) zosta\u0142 wymy\u015blony, aby umo\u017cliwi\u0107 pod\u0142\u0105czenie kilku kana\u0142\u00f3w jednocze\u015bnie. Na przyk\u0142ad, jego obs\u0142uguje iOS<\/a><\/noindex> i mo\u017ce jednocze\u015bnie \u0142\u0105czy\u0107 si\u0119 z zdalnym serwerem przez WiFi i sie\u0107 kom\u00f3rkow\u0105. Wa\u017cne jest, aby zrozumie\u0107, \u017ce to nie s\u0105 dwa oddzielne po\u0142\u0105czenia TCP, ale jedno po\u0142\u0105czenie na dw\u00f3ch kana\u0142ach. Aby to dzia\u0142a\u0142o, zdalny serwer musi r\u00f3wnie\u017c obs\u0142ugiwa\u0107 MPTCP.<\/p>\n
OpenMPTCPRouter<\/a><\/noindex> to otwarty projekt programowego routera, kt\u00f3ry naprawd\u0119 pozwala na sumowanie kana\u0142\u00f3w. Autorzy twierdz\u0105, \u017ce projekt jest w fazie alfa, ale ju\u017c mo\u017cna go u\u017cywa\u0107. Sk\u0142ada si\u0119 z dw\u00f3ch cz\u0119\u015bci \u2014 serwera sumuj\u0105cego, kt\u00f3ry jest umieszczony w internecie, oraz routera, do kt\u00f3rego pod\u0142\u0105czaj\u0105 si\u0119 r\u00f3\u017cni dostawcy internetu i same urz\u0105dzenia klienckie: komputery, telefony. Jako router u\u017cytkownika mo\u017ce dzia\u0142a\u0107 Raspberry Pi, niekt\u00f3re routery WiFi lub zwyk\u0142y komputer. Istniej\u0105 gotowe wersje pod r\u00f3\u017cne platformy, co jest bardzo wygodne.<\/p>\n
\"Prawdziwe
\nZasada dzia\u0142ania OpenMPTCPRouter<\/p>\n
Konfiguracja serwera sumuj\u0105cego<\/h2>\n
\nSerwer sumuj\u0105cy znajduje si\u0119 w internecie i termininuje po\u0142\u0105czenia ze wszystkich kana\u0142\u00f3w klienta routera w jedno. Adres IP tego serwera b\u0119dzie zewn\u0119trznym adresem przy wyj\u015bciu do internetu przez OpenMPTCPRouter. <\/p>\n
Do tego zadania u\u017cyjemy serwera VPS na Debianie 10.<\/p>\n
Wymagania dla serwera sumuj\u0105cego:<\/p>\n