Cato クラウドには TCP Acceleration という機能があり、この機能は Cato クラウド経由で行う TCP 通信を高速化するための機能です。この機能にどの程度効果があるのか気になりましたので、実際に測定を行ってみました。
TCP 通信が遅くなる原因
インターネット回線を敷設して十分な帯域を契約しているのに、期待するほどスループットが出ないといった経験をお持ちではないでしょうか？
利用しているネットワーク機器や通信相手の帯域・混雑が原因でスループットが出ないことがありますが、それ以外の原因でスループットが出ないこともあります。特に、海外との間で大きなデータを送受信する際に数 Mbps のスループットになってしまうようなケースがあり、これは TCP の通信特性が原因であることが多いです。
TCP は信頼性のある通信プロトコルであり、受信確認 (ACK) と再送の仕組みによりパケットロスが発生しても確実にデータを届けることができるようになっています。このとき、1つのパケットを送信して受信確認が返ってきてから次のパケットを送信するというのでは通信効率が非常に悪いため、受信ウィンドウ (Window) というパラメータを受信者が指定することで一定量のパケットをまとめて送信・受信確認する仕組みも用意されています。
さらに、TCP の実装 (Windows、macOS、Linux などの OS) はネットワーク上での輻輳発生を防ぐために輻輳ウィンドウ (Congestion Window) を動的に変更して送信量を制御する仕組みを持っており、輻輳が発生しない範囲で効率的な通信を行えるようにもなっています。各ウィンドウのサイズがどのように変動して定まるかについては複雑なのでここでは説明せず一部後述するに留めますが、メモリサイズの上限、パケットロスの発生、レイテンシの変動などによって定まるものと理解ください。
TCP のスループットはパケットロスや輻輳が無ければ「ウィンドウサイズ ÷ RTT」という式で概ね近似できます。例えば、ウィンドウサイズが 64KB で RTT が 5ms の場合、102.4Mbps (64 / 1000 * 8 / 0.005) となります。通信を行う2点間の距離が遠いほど RTT が大きくなりますので、スループットは反比例して低くなっていきます。ウィンドウサイズを大きくすればスループットは高くなりますが、輻輳が発生するとパケットロスやレイテンシの悪化によって輻輳ウィンドウサイズが小さくなるため、制限なく大きくできるということはありません。
こういった TCP の通信特性により、海外との通信ではスループットが期待するほど高まらないという結果に繋がります。
TCP Acceleration 機能が通信を速くする仕組み
Cato クラウドの TCP Acceleration 機能は、2点間の TCP 通信を複数の TCP 通信に分割することで実現されています。Knowledge Base の次のページにも仕組みが記載されていますので、そちらもご参照ください。
ここでは例として、アメリカ東海岸に出張した社員が Cato クライアントで Ashburn_DC2 PoP に接続し、Tokyo_DC2 PoP に接続された日本国内の拠点にある社内サーバにアクセスするケースで説明します。
通常は出張した社員の PC と社内サーバとの間で1つの TCP 通信が行われますが、TCP Acceleration 機能が有効だと次の3つの TCP 通信に分割されます。
- 出張した社員の PC と Ashburn_DC2 PoP の間の TCP 通信
- 社内サーバと Tokyo_DC2 PoP の間の TCP 通信
- Ashburn_DC2 PoP と Tokyo_DC2 PoP の間の TCP 通信
1と2の通信は比較的近距離で行われ、RTT は数ミリ秒程度なので高速な通信を行えます。
3の通信は日本とアメリカ東海岸の間で行われる遠距離通信で、インターネット経由だと RTT は 150ms 以上あります。この通信は Cato のプライベートバックボーン上で行われ、インターネットで通信するよりも低レイテンシで信頼性の高いネットワークとなっているようです。
TCP Acceleration 機能を利用するとスループットに影響を与える RTT は3の TCP 通信の値になって小さくなりますので、全体としてスループットの高速化が実現されています。
効果測定
TCP Acceleration 機能が実際にどの程度効果があるのか測定してみました。
測定環境
効果測定にあたり Amazon EC2 の東京リージョンとバージニア北部リージョン (アメリカ東海岸) にそれぞれ1台ずつ Linux マシンを用意し、バージニアから東京に向けてトラフィックを流すような測定を行いました。ここでは便宜上、東京のマシンをサーバ、バージニアのマシンをクライアントと呼ぶことにします。
また、測定のために、スループットやレイテンシの測定によく利用されるツールである iperf2 を利用しました。
測定パターン
測定パターンは次の5つです。
- インターネットだけを用いた通信
- Cato クラウドの WAN 通信 (TCP Acceleration 機能あり)
- Cato クラウドの WAN 通信 (TCP Acceleration 機能なし)
- クライアントマシンは Ashburn_DC2 PoP に接続し、その PoP からインターネット経由でサーバマシンに通信 (TCP Acceleration 機能あり)
- クライアントマシンは Ashburn_DC2 PoP に接続し、Tokyo_DC2 PoP からインターネット経由でサーバマシンに通信 (TCP Acceleration 機能あり)
TCP Acceleration 機能を有効にするかどうかは CMA (Cato 管理画面) の [Network] – [Network Rules] の設定画面で変更でき、”Voip Voice” カテゴリ (Zoom や SIP など音声通信系のアプリケーション) 以外の通信では TCP Acceleration 機能がデフォルトで有効となっています。
これに加えて、3の測定を行う前には TCP Acceleration 機能を無効にする次のような Network Rule を追加しました。
また、Cato クラウド経由でインターネットアクセスを行う場合、通常は接続した PoP からインターネットに通信が行われますが、5の測定を行う前に Tokyo_DC2 PoP からインターネットに通信が行われるようにする Network Rule も追加しました。
測定指標
測定した指標は次の4つです。
- ping を用いた RTT
- トラフィック無制限時の平均スループットと、そのときの最大レイテンシ
- 少量トラフィック (2Mbps) を流したときの最大レイテンシ
測定結果
各測定パターンについて1度ずつ測定した結果は次の通りとなりました。
| 測定パターン | ping による RTT | 無制限時の平均スループット | 無制限時の最大レイテンシ | 少量スループット時の最大レイテンシ |
| 1 | 165ms | 68.6Mbps | 246ms | 83.6ms |
| 2 | 159ms | 153Mbps | 1900ms | 132ms |
| 3 | 同上 | 9.61 Mbps | 296ms | 763ms |
| 4 | 163ms | 75.2Mbps | 1619ms | 131ms |
| 5 | 161ms | 183Mbps | 1796ms | 136ms |
今回の環境では、インターネットだけを用いたとき (測定パターン1) は開始から10秒後にスループットが 80Mbps 程度まで上昇し、その後はその速度で安定して通信できていました。上記の測定とは別で UDP を用いてさらにトラフィックを流してみたところ、1Gbps のトラフィックも問題なく流せましたので、それと比べると TCP のスループットは低いです。インターネット回線で長距離通信なので高トラフィックを流すとパケットロスが発生しやすく、1Gbps の UDP トラフィックでは 1.5% 程度、100Mbps だと 0.011% 程度発生しましたので、パケットロスも影響して TCP のスループットが低くなっているものと考えられます。
TCP Acceleration 機能を有効にした WAN 通信 (測定パターン2) やインターネット通信 (測定パターン5) を見ると、スループットは2倍以上に上昇しています。時間的な変動があり安定した速度ではありませんでしたが、有意に速くなっています。ただし、TCP 通信が3つに分割されたことや Cato クラウドによるトラフィック検査などの影響もあり、レイテンシが増えてしまっています。無制限時の最大レイテンシは見かけ上かなり大きくなっているだけなので特に気にしなくても良いですが、少量スループット時のレイテンシが 83.6ms から 50ms 程度大きくなっている点は利用者の体感にもいくらか影響を与えるものかもしれません。
測定パターン2と3を比較すると、TCP Acceleration 機能を無効にしたパターンは非常に悪い値となってしまっています。測定パターン3は1と同程度の値となると予想していたため、予想外の結果でもあります。通常は無効化することはない設定を無効化したためにこのような結果になったのかもしれません。
測定パターン4と5は日本とアメリカ東海岸の間でインターネットを経由するか Cato クラウドのバックボーンを経由するかの違いですが、バックボーン経由のほうが有意に良い結果となっています。ただし、パターン1と4を比較するとわずかにスループットが上昇しており、TCP Acceleration 機能というよりも Cato クラウドを利用することで通信が高速化したと言えるかもしれません。
Cato クラウドの輻輳制御に関して
前項の効果測定において、Cato クラウドのプライベートバックボーンを通るパターン (2,5) はそうでないパターン (1,4) に比べてスループットが2倍以上になっています。しかし、RTT は日米間の物理的な距離の影響が大きいため、わずかに減少しているだけです。そこで「ウィンドウサイズ ÷ RTT」というスループットの近似式を改めて見つめなおすと、RTT の減少ではなくウィンドウサイズの増加によってスループットが上昇したものと考えられます。
ウィンドウのうち、輻輳ウィンドウは TCP 通信で用いる輻輳制御アルゴリズムの種類によって異なる変動をします。Windows、macOS、Linux の現在主流のバージョンでは、デフォルトの輻輳制御アルゴリズムとして CUBIC が採用されています。このアルゴリズムはパケットロスが発生しない間はウィンドウを増加させ、パケットロスが発生するとウィンドウを減少させることで、輻輳が発生しない状態を維持しつつ極力多くのデータを送信するというものです。
一方、Cato クラウドでは輻輳制御アルゴリズムとして BBR の利用が推奨されており、各テナントの CMA の [Administration] – [Advanced Configuration] の中で BBR を利用するようデフォルト設定されています。
BBR はパケットロスではなくレイテンシを指標とし、レイテンシが悪化しない程度までウィンドウを増加させるアルゴリズムです。ただし、ネットワーク状況によってレイテンシが悪化することがあるため、定期的にウィンドウを最小に戻すという操作も行われます。
効果測定の結果や輻輳制御アルゴリズムの違いを踏まえると、Cato クラウドのプライベートバックボーン中では大きなトラフィックを流してもレイテンシが悪化しにくくなるような何らかのトラフィック制御が行われているものと推測されます。
まとめ
測定結果から、TCP Acceleration 機能に効果があることが確認できました。特に、物理的に距離が離れた通信で Cato クラウドのネットワークを経由するような形で TCP Acceleration を有効にすると、スループットが2倍以上に上昇するのは期待以上の効果でした。
インターネットとの通信において TCP Acceleration を適切に機能させるには、通信先のサーバと近い PoP からインターネットに出ていくように Network Rule を設定する必要がありましたので、この点は要注意です。
日本国内の TCP 通信については TCP Acceleration の仕組みや TCP 通信の特性上あまり効果は期待できず、測定により Cato クラウドのネットワークに負荷をかけることになってしまうため、今回は測定しませんでした。逆に、日本国内の通信における TCP Acceleration 機能を無効化することでパフォーマンスをチューニングできるのかどうかについては気になるところではありますので、機会があれば試すかもしれません。
Skeed 高速ファイル転送ソリューションのご紹介
今回のように日本と海外との間の通信を高速化するソリューションとして、弊社のグループ会社である Skeed 社もご紹介します。
このソリューションは大容量ファイルの転送に特化したものであり、TCP 通信の課題を UDP 通信によって乗り越えるというものです。一般的な通信に向けたものではありませんが、日本と海外との間で大容量ファイル（映像データ、ビッグデータ、データベースのバックアップデータなど）をやり取りしたいという際には、このソリューションもご検討いただければ幸いです。