2つのボンディングされたVPNチャネルでのボンディングパフォーマンスが低い
結合リンクを介して接続したい2台のLinuxマシンがあります。
1台のマシンにはゲートウェイとして2つのUMTSモデム（DN：5mbit UL：1.2mbit）があり、もう1台のマシンにはゲートウェイとして光ファイバー（DL：100Mbit UL：20mbit）があります。
2つのOpenVPNチャネル（iptablesルールを使用してUMTSモデムごとに1つ）を正常に作成し、これらのチャネルにLinuxボンディングドライバー（モード0、ラウンドロビン配布）を適用できました。
ここまでは順調ですね。結合されたインターフェースは、2つの集約されたVPNチャネルを介して2つのLinuxマシンを接続します。ここで、各マシンにpingを実行したり、ファイルを転送したりできます。
私の問題は、結合の帯域幅です。理論的には帯域幅は2倍になるはずですが、実際には、ボンド内のVPN接続の数に関係なく同じです。
2つのUMTSモデムを備えたマシンで、1つのVPNのみを使用すると、DN：5mbit UL：1.2mbitに近い帯域幅で他のマシンに到達できます。ボンドインターフェイス内で2つのVPNを使用すると、チャネルあたりの帯域幅はDN：2.5mbit UL：0.6mbitに近いため、一方または両方のVPNチャネルを使用しても、全体の帯域幅は同じです。
この動作は、TCPまたはUDPのいずれかを使用してデータを転送するときに発生するため、プロトコルの問題ではありません。
他の誰かもこれを経験しましたか？
前もって感謝します。
最後に、問題の（明らかな）原因を見つけました。
「低帯域幅のネットワークリンクがある場合は、複数を並列に配置して高帯域幅の結合リンクを作成するのは簡単ですが、遅延の悪いネットワークリンクがある場合は、いくつでもそれらを回すことができません。待ち時間の長いリンクに。」 @ It's the Latency、Stupid、Stuart Cheshire、1996年5月。
VPNの遅延は約110ミリ秒であるため、リンクの最大帯域幅は約4.8mbpsになります（ http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-による） for-long-distance-links / ）
これを確認するために、テストを実施しました。各UMTSモデムの帯域幅を2mbps DLおよび1.2mbpsUL（ワンダーシェイパーでトラフィックをシェーピング）に下げ、3.65mbps DLおよび2mbpsULの結果を得ました。集約された帯域幅。
再開すると、集約された帯域幅が遅延によって課せられた最大帯域幅を超えない場合はVPNボンディングを使用できます。それ以外の場合は、リソースの浪費になります。
データを含むリターントラフィックがリンク間でバランスが取れているとは思えないため、最初にボンディングされたインターフェイスでアップリンク速度をテストすることをお勧めします。
リンクにあるように、TCPウィンドウサイズを大きくしてみませんか？サイズを2倍にすると、目的の帯域幅に到達できるはずです。