{"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\/it\/blog\/administrirovanie\/nastoyashhee-summirovanie-internet-kanalov-openmptcprouter","title":{"rendered":"La somma reale dei canali Internet \u2014 OpenMPTCPRouter","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"La
\n
\n\u00c8 possibile combinare pi\u00f9 canali Internet in uno? Ci sono molti fraintendimenti e miti su questo tema, persino ingegneri di rete esperti non sempre sanno che sia possibile. Nella maggior parte dei casi, l'unione dei canali viene erroneamente chiamata bilanciamento a livello di NAT o failover. Ma la vera somma consente di effettuare un'unica connessione TCP tramite tutti i canali Internet<\/b>, ad esempio una trasmissione video, in modo che l'emissione non si interrompa in caso di guasto di uno qualsiasi dei canali Internet. <\/p>\n

Esistono costose soluzioni commerciali per le trasmissioni video, ma tali dispositivi costano migliaia di euro. L'articolo descrive la configurazione del pacchetto gratuito e open-source OpenMPTCPRouter, chiarendo i miti pi\u00f9 diffusi sulla somma dei canali.
\n<\/a><\/noindex><\/p>\n

Miti sulla somma dei canali<\/h2>\n

\nCi sono molti router domestici che supportano la funzione Multi-WAN. A volte i produttori chiamano questo somma dei canali, il che non \u00e8 del tutto corretto. Molti professionisti della rete credono che oltre a LACP<\/a><\/noindex> e la somma a livello L2, non esiste un'altra aggregazione dei canali. Spesso ho sentito dire da persone che lavorano nelle telecomunicazioni che ci\u00f2 sia impossibile. Quindi cerchiamo di chiarire alcuni miti popolari. <\/p>\n

Bilanciamento a livello di connessioni IP<\/h2>\n

\nQuesto \u00e8 il modo pi\u00f9 accessibile e popolare per utilizzare simultaneamente pi\u00f9 canali internet. Per semplificare, immaginiamo di avere tre provider internet, ognuno dei quali ci offre un indirizzo IP reale dalla propria rete. Tutti questi provider sono collegati a un router con funzionalit\u00e0 Multi-WAN. Pu\u00f2 essere OpenWRT con il pacchetto mwan3, Mikrotik, Ubiquiti o qualsiasi altro router domestico, dato che ora questa opzione non \u00e8 pi\u00f9 rara.<\/p>\n

Per modellare la situazione, immaginiamo che i provider ci abbiano fornito i seguenti indirizzi:<\/p>\n

WAN1 \u2014 11.11.11.11\nWAN2 \u2014 22.22.22.22\nWAN3 \u2014 33.33.33.33\n<\/code><\/pre>\n
\nCio\u00e8, collegandosi a un server remoto example.com<\/b> Attraverso ciascuno dei provider, il server remoto vedr\u00e0 tre IP sorgente indipendenti del cliente. Il bilanciamento permette di suddividere il carico tra i canali e di utilizzarli tutti e tre contemporaneamente. Per semplificare, immaginiamo di suddividere il carico equamente tra tutti i canali. Di conseguenza, quando un cliente apre un sito che ha, ad esempio, tre immagini, carica ogni immagine attraverso un provider diverso. Sul lato del sito, questo appare come connessioni provenienti da tre IP diversi.<\/p>\n
\"La
\nCon il bilanciamento a livello di connessione, ogni connessione TCP passa attraverso un provider separato.<\/p>\n
Questa modalit\u00e0 di bilanciamento pu\u00f2 causare problemi agli utenti. Ad esempio, molti siti collegano rigidamente cookie e token all'indirizzo IP del cliente, e se questo cambia improvvisamente, la richiesta viene rifiutata o l'utente viene disconnesso dal sito. Questo si verifica frequentemente nei sistemi di online banking e su altri siti con regole rigorose sulle sessioni degli utenti. Ecco un semplice esempio: i file musicali su VK.com sono accessibili solo con una chiave di sessione valida, collegata all'IP, e i clienti che utilizzano questo tipo di bilanciamento spesso non riescono a riprodurre l'audio, perch\u00e9 la richiesta non \u00e8 passata attraverso il provider a cui \u00e8 collegata la sessione.<\/p>\n
\"La
\nQuando si scaricano torrent, il bilanciamento a livello di connessione somma la larghezza di banda di tutti i canali.<\/p>\n
Questa bilanciatura consente di sommare la velocit\u00e0 della connessione Internet utilizzando pi\u00f9 collegamenti. Ad esempio, se ciascun fornitore ha una velocit\u00e0 di 100 Megabit, durante il download di torrent otterremo 300 Megabit. Questo perch\u00e9 il torrent apre molteplici collegamenti, che vengono distribuiti tra tutti i fornitori e alla fine sfruttano l'intera larghezza di banda.<\/p>\n
\u00c8 importante comprendere che un'unica connessione TCP passer\u00e0 sempre solo attraverso un fornitore. Ci\u00f2 significa che se stiamo scaricando un grande file tramite HTTP, quella connessione sar\u00e0 stabilita da uno dei fornitori, e se la connessione con quel fornitore si interrompe, il download si fermer\u00e0. <\/p>\n
\"La
\nUna connessione utilizzer\u00e0 sempre solo un canale Internet.<\/p>\n
Questo vale anche per le trasmissioni video. Se trasmetti video in streaming su una piattaforma come Twitch, il bilanciamento a livello di connessioni IP non offre alcun vantaggio particolare, poich\u00e9 il flusso video sar\u00e0 trasmesso all'interno di una singola connessione IP. In questo caso, se il provider WAN ha problemi di connessione, ad esempio perdite di pacchetti o riduzione della velocit\u00e0, non sarai in grado di passare immediatamente a un altro provider. Dovrai interrompere la trasmissione e riconnetterti da capo. <\/p>\n
Somma reale dei canali<\/h2>\n
\nLa somma reale dei canali consente di instradare una connessione a una piattaforma come Twitch attraverso tutti i provider, in modo che, se uno dei provider dovesse avere un guasto, la connessione non venga interrotta. \u00c8 una sfida sorprendentemente complessa, che ancora non ha una soluzione ottimale. Molti non sanno nemmeno che sia possibile! <\/p>\n
Dalle illustrazioni precedenti, ricorderemo che un server Twitch condizionale pu\u00f2 ricevere da noi un flusso video solo da un indirizzo IP sorgente, il che significa che deve sempre essere costante, indipendentemente dai provider che non funzionano o che sono attivi. Per ottenere ci\u00f2, avremo bisogno di un server aggregante che terminer\u00e0 tutte le nostre connessioni e le unir\u00e0 in una sola.<\/p>\n
\"La
\nIl server aggregante aggrega tutti i canali in un'unica tunnel. Tutte le connessioni avvengono dall'indirizzo del server aggregante.<\/p>\n
In questo schema vengono utilizzati tutti i provider e la disconnessione di uno di essi non causer\u00e0 l'interruzione del collegamento con il server Twitch. Fondamentalmente, si tratta di un tunnel VPN particolare, sotto il quale ci sono pi\u00f9 canali internet. L'obiettivo principale di questo schemi \u00e8 ottenere il canale di comunicazione di massima qualit\u00e0. Se uno dei provider inizia a presentare problemi, perdita di pacchetti o aumento delle latenza, questo non dovrebbe riflettersi sulla qualit\u00e0 della comunicazione, poich\u00e9 il carico verr\u00e0 automaticamente distribuito su altri canali di qualit\u00e0 superiore disponibili. <\/p>\n
Soluzioni commerciali<\/h3>\n
\nQuesto problema ha preoccupato a lungo coloro che trasmettono eventi in diretta senza avere accesso a una connessione Internet di qualit\u00e0. Ci sono diverse soluzioni commerciali per tali esigenze; ad esempio, l'azienda Teradek produce router molto potenti che possono ospitare pacchi di modem USB.<\/p>\n
\"La
\nRouter per streaming video con funzione di aggregazione dei canali<\/p>\n
In questi dispositivi \u00e8 generalmente presente la possibilit\u00e0 di acquisire il segnale video tramite HDMI o SDI. Insieme al router viene venduto un abbonamento al servizio di aggregazione dei canali e alla lavorazione del flusso video, compresa la sua ricodifica e rilancio. Il prezzo di questi dispositivi inizia da 2.000 $ con un pacchetto di modem, pi\u00f9 un abbonamento separato al servizio. <\/p>\n
A volte appare piuttosto intimidatorio:<\/p>\n
\"La
\n<\/p>\n
Configurazione di OpenMPTCPRouter<\/h2>\n
\nProtocollo MP-TCP<\/a><\/noindex> (MultiPath TCP) \u00e8 stato creato per consentire la connessione su pi\u00f9 canali contemporaneamente. Ad esempio, \u00e8 supportato da iOS<\/a><\/noindex> e pu\u00f2 collegarsi contemporaneamente a un server remoto sia tramite WiFi che tramite rete mobile. \u00c8 importante comprendere che non si tratta di due connessioni TCP separate, ma di una sola connessione stabilita attraverso due canali. Perch\u00e9 questo funzioni, il server remoto deve supportare anche MPTCP.<\/p>\n
OpenMPTCPRouter<\/a><\/noindex> \u00e8 un progetto open source di un router software che consente di sommare realmente i canali. Gli autori affermano che il progetto \u00e8 in fase alpha, ma \u00e8 gi\u00e0 utilizzabile. \u00c8 composto da due parti: un server di somma che si trova su Internet e un router a cui si collegano pi\u00f9 provider Internet e i dispositivi client stessi: computer, telefoni. Un Raspberry Pi, alcuni router WiFi o un computer normale possono funzionare come router utente. Ci sono build pronte per diverse piattaforme, il che \u00e8 molto conveniente.<\/p>\n
\"La
\nPrincipio di funzionamento di OpenMPTCPRouter<\/p>\n
Configurazione del server di somma<\/h2>\n
\nIl server di somma si trova su Internet e termina le connessioni da tutti i canali del router client in uno. L'indirizzo IP di questo server sar\u00e0 l'indirizzo esterno quando si accede a Internet tramite OpenMPTCPRouter. <\/p>\n
Per questo compito utilizzeremo un server VPS con Debian 10.<\/p>\n
Requisiti per il server aggregatore:<\/p>\n