クライアント端末のパフォーマンスに関する問題を切り分けるためには問題の発生箇所や影響範囲を正確に特定することが重要です
この記事では、影響範囲を特定するためのiPerf を用いたトラブルシュートステップについて解説します。
はじめに
TCP スループットの理論値について
TCP スループット低下の要因は、ネットワーク遅延とパケットロスなどが考えられます。
TCP 通信では、レイテンシが大きくなると比例してスループットは低下し、通信の完了が大きく影響を受けます。
TCP 通信の最大スループットの理論値はこのウィンドウサイズと往復遅延時間（RTT: Round Trip Time）から以下の式で求めることができます。
式
スループット = TCP Window Size(Bit) / RTT(sec)
※これは、理論値となるため、様々な要因で変動する可能性のあるものとなっております。
デフォルトのウィンドウサイズはOS によって異なりますが、一般的には64KB 程度となっております。
しかし、実際には、64KB では現在のネットワークでは不足しており、RFC 1323で定義されているTCP オプションや
複数のTCP セッションを構成することで実通信は拡張されることになります。
つまり、予想される理論値に基づいて、iPerf などのテスト結果とサイジングガイドに沿った期待されるパフォーマンスが出せていることが確認でき、
遅延とパケットロスが無くパフォーマンスが悪い状況が続く場合は、クライアント端末側のチューニングやネットワーク環境のチューニング(輻輳制御/帯域制御、MTU など)することで改善が見込まれます。例えば、以下の観点のチューニングが考えられます。
- Path MTU Discovery
- OS での TCP Buffer Size 調整
- Software での TCP Buffer Size 調整
- 転送回数削減: 並列処理、効率的プログラミング・アルゴリズムの使用、など
- 転送サイズ縮小化: データ圧縮、オーバーヘッドの少ない暗号アルゴリズムの選択、など
これらのチューニングに関しては、以下のMicrosoft、Google、Cisco からも公開された記事があります。
[ネットワーク アダプターのパフォーマンス チューニング | Microsoft Learn]
[ネットワーク パフォーマンスの TCP 最適化 | Compute Engine Documentation | Google Cloud]
[アプリケーションが10Mbpsしか使用しない理由リンクが1Gbpsであっても？]
前述の通り、64KB は、現在のネットワークでは十分ではありませんが、パフォーマンス測定のために64KB でのiPerf テストも効果的です。
例えば、64 KB (524288 bit)を6ms (0.006s)で割った値 = 87381333 bit/s = 約87Mbps が予想されるTCP スループット理論値となります。
しかし、実際のテストは、クライアント処理速度など様々な要因により常にわずかに低くなることが予想されます。
64KB の時のRTT に応じた理論値のスループット値(並列クライアントストリームはシングルの想定)
以下のiPerf テストでは、RTT 値は平均8ms となっているため、約66Mbps が理論値となり近しい値となっています。
iPerf の解説
iPerf は、Server とClient の2台のPC を用意して、LAN およびWLAN のスループットをテストするために使用できるツールです。
iPerf アプリケーションのダウンロードや使い方は、ドキュメント内のリンクを参照してください。
利用構成例：
以下は、iPerf のコマンドオプションの解説と便利なコマンドセットです。
オプションリスト
-s ＝ サーバの指定
-c ＝ クライアントの指定
-R ＝ 逆方向モードで実行 (サーバが送信、クライアントが受信)
-w ＝ TCP window size の指定
-P ＝ 実行する並列クライアントストリームの数
--logfile = 実行ディレクトリに指定のファイル名のログを保存する
-u ＝ UDP の指定
-b ＝ ターゲットビットレート（ビット/秒）の指定。（無制限の場合は0）（デフォルトはUDPの場合は1 Mbit/秒、TCPの場合は無制限）
-i ＝ 定期的なスループット報告の間隔（秒）
便利なコマンドセット
Server side:
iperf3 -s --logfile [file name]
Client side:
- Performance per Window size per direction（TCP）
iperf3 -c <server_IP> -w 128kb -P 3 --logfile [file name]
iperf3 -R -c <server_IP> -w 128kb -P 3 --logfile [file name]
iperf3 -c <server_IP> -w 256kb -P 3 --logfile [file name]
iperf3 -R -c <server_IP> -w 256kb -P 3 --logfile [file name]
iperf3 -c <server_IP> -w 5M -P 3 --logfile [file name]
iperf3 -R -c <server_IP> -w 5M -P 3 --logfile [file name]
- Bandwidth test（UDP）
iperf3 -c <server_IP> -u -b 50M --logfile [file name]
iperf3 -R -c <server_IP> -u -b 50M --logfile [file name]
iperf3 -c <server_IP> -u -b 80M --logfile [file name]
iperf3 -R -c <server_IP> -u -b 80M --logfile [file name]
iperf3 -c <server_IP> -u -b 100M --logfile [file name]
iperf3 -R -c <server_IP> -u -b 100M --logfile [file name]
iperf3 -c <server_IP> -u -b 150M --logfile [file name]
iperf3 -R -c <server_IP> -u -b 150M --logfile [file name]
iperf3 -c <server_IP> -u -b 200M --logfile [file name]
iperf3 -R -c <server_IP> -u -b 200M --logfile [file name]
チェックリスト
1. 問診をもとに問題箇所の特定と想定されるWAN リンク速度を確認します。
2. ドキュメントを参考にICMP レベルにて拠点内でのパケットロスが無いことを確認します。
3. MX をご利用の場合は、サイジングガイドでデバイスと設定値をチェックし、期待される最大スループットを確認します。
4. 対象宛先または、iPerf サーバに対してPing を実行して、RTT 値を確認する。
5. Traceroute、MTR、Pathping(Windows) などを実行して、経路上のLoss が無いことを確認する。
6. iPerf にてパフォーマンス測定を実施します。この時にパケットキャプチャの取得も行います。
※外部リンクですが、Public iPerf サーバを利用することも可能。 https://github.com/R0GGER/public-iperf3-servers
また、iPerf を用いたテストを行うことで被疑箇所の特定と期待値の測定などを実施することが可能となります。
被疑箇所の特定の考え方を以下に示します。
構成はMeraki フルスタック構成例となりますが、被疑箇所の特定は、他の構成でも同じ考え方が当てはまります。
① インターネットスピードテスト、または、VPN 越しにiPerf または、Speed test を実行した時に低パフォーマンスが見られるか。（実際の事象の確認）
② MX に直接接続した時に同じテストを実施して、事象が見られるか。（この時に事象が見られない場合、LAN 内における問題の可能性が高い。）
③ MR 配下のiPerf client からMX に直接接続しているServer に向けてテストを実施した時に同様に低パフォーマンスが見られるか。（ここで事象が見られる場合、MS とMX の間の問題の可能性が高い。）
④ 同じようにMS に接続しているServer に向けてテストを行い同様の事象が見られるか。この時、影響範囲の絞り込むため別のMR がある場合は、別のMR からも実施する。（ここで事象が見られる場合、無線環境または、MR とMS の間の問題の可能性が高い。なお、この時点で③で事象が見られるが④で見られない場合は、③の被疑が強まる。）
⑤ 異なるMR がある場合、MR 間のクライアントでiPerf テストを実施する。異なるMR がない場合、MR のLocal status page にアクセスしてSpeed test 測定を行う。（ここで事象が見られる場合、無線環境の問題の可能性が高い。）
※ Local status page のSpeed test は、現時点（2025-02-25）では約 250 Mbps に制限されているため、40Mhz、80Mhz を利用しており、
スループットが超過することが予想される場合、ローカル環境でのiPerf テストを行う必要があります。
構成例：
TCP 試験例
例えば、以下の試験では、RTT 値は平均8ms となっているため、約66Mbps が理論値となり近しい値となっています。
iperf3.exe -c Server IP -i 1 -w 64KB
さらに、並列ストリーム (3つのインスタンスを実行)して実施すると3倍程度の値となっていることが確認できます。
この結果から、TCP ストリームが増えることでその分可能な通信量が増えることを証明しています。
iperf3.exe -c Server IP -i 1 -w 64KB -P 3
さらにウィンドウサイズを大きくすることでさらに増加することが確認できます。
この結果から、ウィンドウサイズが増え一回の送信する量が増える分可能な通信量が増えることを証明しています。
iperf3.exe -c Server IP -i 1 -w 5M -P 3
UDP 試験例
さらに、UDP の通信に関しても確認を進めていきます。
UDP の場合は、プロトコルの性質上、理論値の算出はできません。
しかし、通常は、帯域で利用可能な上限を送信可能と考えられます。
UDP の場合、-b コマンドを利用して徐々に回線の上限まで引き上げて確認を進めていきます。
iperf3.exe -c Server IP -u -b 100M
100M の場合、ロスが無いことが確認できます。
iperf3.exe -c Server IP -u -b 300M or 400M
300,400M とすると、トラフィックが過負荷になり、パケットの数% が受信者によってドロップされ、
速度は約250 - 260Mbpsであることがわかります。
これは、MX をご利用の場合、サイジングガイドで期待されている予想範囲内にあれば問題ありません。
※各ネットワーク環境とトラフィックの特徴は独自のものであることに注意してください。
サイジングガイドで提示されている数値は、有害なネットワークや特徴のあるトラフィックの挙動が存在しない状態でのテスト中に取得されたものであるということにご留意ください。
今回の場合、TCP で確認したものと大きな差異は無いため問題無いと判断できます。
追加リソース
Troubleshooting Client Speed using iPerf - Cisco Meraki Documentation
https://community.meraki.com/t5/Meraki-サポートの記事/スループットの問題が発生した際の確認ポイント/ba-p/270330
https://community.meraki.com/t5/Meraki-サポートの記事/ワイヤレススループットの計算とテスト/ba-p/268941
