Deep-Dive テスト結果分析

ネットワークテストでは複雑でかつ相互に関連した項目が測定結果として出力されます。本記事では、主だった情報と内容をお知らせしますが、既存のネットワーク詳細設定により実際に導入する内容はさまざまです。改善点の導入については社内 IT 管理部門と連携いただき、測定結果から引き出される問題点の回避、改善にお役立てください。

本テストツールの提供元 Visualware社では、測定結果の内容詳細、トラブルシューティングにお役立ていただけるよう詳細なリソースをご用意しています。参照記事 (英文):Visualware Quality Test Resources

以下、テストで検知される項目をご確認ください。

ベーシックテスト測定結果の分析

ベーシックテスト測定結果は、以下タブごと内容をまとめて表示します。

Speed Icon
テストにより検知したダウンロード、アップロード速度、一貫性、タイミング、遅延を表示します。また、ハイパーリンクから詳細な測定結果を確認できます。
tab_capacity.png
スピードごとにパケットロスの集計を表示し、LANやインターネット接続の問題を検知します。
tab_route.png
tracerouteの結果を表で一覧します。テスト端末とDialpadテストサーバー間のパス品質を確認します。
tab_voip.png
テスト中に検知したジッター、パケットロス率を表示します。ハイパーリンクから詳細な測定結果を確認できます。
tab_firewall.png
テストで検知した開放されたポートとブロックされたポート数を表示します。詳細のポートテストはフルポートテストを実行して測定結果を確認します。
tab_graph.png
アップロード/ダウンロード速度やジッター/パケットロス率など、6つのレポートを表示します。左右の矢印で次レポートを表示します。枠内右下のハイパーリンクで詳細分析を確認します。
tab_rtt.png
テスト端末とDialpad テストサーバー間をパケットが往復する実際の速度の平均値を表示します。
tab_summary.png
ベーシックテストのハイレベルな測定結果を表示します。上部のリンクからは各項目の詳細、また本文内のリンクでは各項目のタブへ移動します。

 

ベーシックテストが終了すると、Summary (サマリー) タブが表示されます。ベーシックテスト測定結果 ヘルプ記事でもご案内しています。

ネットワークに関する参照・リソース一覧 ヘルプ記事では、測定結果とネットワークパフォーマンスの改善についてリソースを一覧しておりますのでご参照ください。

速度 (Speed)

速度は帯域と遅延の影響により測定される主観的評価です。接続が速い、帯域幅が非常に高い環境でも、データ通信に長い遅延 (Latency) が発生する高速ネットワークでは、接続の速度は遅いと感じる場合があります。参照:用語集 

page_speed.png

Speedタブでは、テスト端末でのダウンロード、アップロード速度と、他の回線速度との比較を視覚的に表示します。また、他の計測値も表示されます。

Down/Up consistency of service (CoS) [通信品質の一貫性]:利用するネットワークサービスの最大速度に対して、実際の通信速度が達した比率。短時間だけ100 Mbpsで通信が実行されその後はダイアルアップの低速度になるのは、低いパフォーマンスです。高ビットレートと低CoSよりも、低ビットレートと高CoSの実現が適正です。

Round Trip Time (RTT) [ラウンドトリップタイム]:テスト端末とサーバ間で、データパケットが発信してから応答が帰るまでの時間をミリ秒で計測します。

Max Delay (Delay) [最大遅延]:ラウンドトリップタイム (RTT) テストでの最長の待ち時間を計測します。

TCP Equilibrium Speed [TCP平衡速度]:クライアント端末から送信したレートパケットがサーバ応答と同期するまでに、2点間を通過したトラフィックの量を計測します。(例:バッファキューを低く調整するなど)

TCP Force Idle [TCP強制アイドル]:ルートで通信可能な容量と実際の通信容量の差異を測定します。交通量の少ない道路にはさらに利用可能な交通量がある状況と似ています。この差異は、接続が滞っている環境では増加し、パケットは通信されずにキューに入るため、音声が途切れる原因になります。

Timer Accuracy [タイマー精度]:本テスト測定結果では分析されません。

スピード (Speed) 測定結果の分析

Speedタブの測定結果分析と、パフォーマンス改善点をご案内します。

Down/Up consistency of service (CoS) [通信品質の一貫性]: CoS スコアが 100% から大きく下回る場合、ネットワークテスト中に一部のデータ通信が実行されていないと考えられます。このスコアは概要のみで実際の問題点の把握はできません。

  • CoS スコアがインターネットプロバイダーのサービス内容に満たない場合、ネットワーク上で制限がかかっていないか、またご利用のプロバイダーの提供サービス品質に問題がある場合があります。

Round Trip Time (RTT) [ラウンドトリップタイム]:Dialpad は、世界各国のユーザーにお応えできるよう地域クラスターのご提供に努めています。通話管理をローカル環境で実行することで、通話品質維持の実現に努めています。米国のユーザーでは40ミリ秒以下の範囲が適正値です。これを大きく上回る数値では通話音声に劣化がともない、相手の応答が届くまでに時間がかかる結果となります。

  • RTTの数値が高い場合、ご利用のインターネットプロバイダとDialpadテストサーバーを結ぶインターネットルートが適正dでないことが原因です。インターネットプロバイダーへペアリングルートの修正を依頼する事が考えられます、
  • VPN接続ではRTTが高くなり、通信データを切り分けらて送信することによりリアルタイムの通話品質が大きく劣化する原因となります。業界標準のベストプラクティスとして、VoIP通信ではVPNはサポートされておりません。VoIPコミュニケーションの精度を維持するには、VPNスプリットトンネリングの設定が必須です。Deailpad では、品質を損なうことなくデータセキュリティ保護のため多重の対策を導入しています。

Max Delay [最大遅延]:ラウンドトリップタイム (RTT) テストでの最長の待ち時間を計測しますが、これのみでは問題点の把握はできません。接続するサーバーによって数値を返さない場合は100ミリ秒を自動表示します。

TCP Force Idle [TCP強制アイドル]:VoIP での適正値は40です。これ以上の遅れがある場合、パケット未着信と認識して再送信を試みる原因となります。この重複通信は音声の途切れや、不在着信の原因となり、また制限されたネットワーク環境では既存の輻輳問題が悪化する可能性があります。

  • セキュリティ機器、劣化したルーター、インターネットプロバイダーによるローカル接続の遅延などは、TCPレイヤーの通信が一時停止する大きな原因となります。

スピードテストにより、ローカルLANネットワーク側の問題点が判別されるかもしれません。使用可能帯域の上限近くに達している場合には、ネットワーク再構成でボトルネックを解消したり、バックアップ同期システムによる管理、またメディア機器やアプリをストリーミングするなどの検討が必要です。プロバイダーにて帯域を追加できる場合には、ローカルネットワークが追加分のトラフィックフローを正しく処理するよう構成することで改善が可能です。

ネットワークに関する参照・リソース一覧 ヘルプ記事では、測定結果とネットワークパフォーマンスの改善についてリソースを一覧しておりますのでご参照ください。

キャパシティ (Capacity)

こちらの 用語集 にあるように、キャパシティは2拠点間のネットワークパフォーマンスの評価です。キャパシティは、帯域、遅延、また時間の経過に伴うネットワーク動作の変化に影響を受けます。ネットワーク・ストレステストを実行し (最大80Mbps) 、測定結果が遅い場合にはVoIP通信の劣化の原因となります。

Capacity Results

測定結果では、ターゲット速度、実際の達成速度とパケットロス率を表示します。

Show UP/Show Down (Show Up/Show Down) オプションで、上り/下りの通信結果表示に切り替えます。一般的に上り、下りの測定結果には差異があり、特に非対称性のブロードバンド接続では差異は顕著です。

上下の矢印 (Up and Down arrows) をクリックして、ページをスクロールします。

キャパシティ測定結果の分析

測定結果で、高いビットレートでのパケットロスは一般的で、パケットロス率が1%以下であれば概ね正しく動作します。一方で、VoIP通話やビデオ会議サービスが実行される低ビットレートでパケットロスが発生している場合には注意が必要で、通話中の切断、通話品質、通話に応答できないなどのほか、アプリ接続エラーや利用端末のOSエラーなどの原因となります。

個人に発生するパケットロス:個人ユーザーに発生する場合、電話機・コンピュータとウォールソケット間のイーサーネットケーブルをCAT5e、CAT6 など新しいケーブルに置き換えることで解消することがあります。

ネットワーク上の複数ユーザーに発生するパケットロス:スイッチのポートほか、ネットワーク機器に古いファームウェアが使用されている可能性があります。LAN接続にて期待値を達成している場合には、インターネットプロバイダーにパケットロスの原因を調査依頼する必要となる場合があります。

VPNユーザーに発生するパケットロス:VPN接続ではリアルタイムデータを分割することから、表面的に問題なく利用できている一方で、一般に通話データ品質は大きく劣化している傾向にあります。このため業界標準としてVPN接続の利用はサポートしていないため、VPNスピリットトネリングでの利用をお願いします。Dialpadでは多数の業界ベストプラクティスに取り組み、パフォーマンスを維持しつつ通話セキュリティを保護しております。

ネットワークに関する参照・リソース一覧 ヘルプ記事では、測定結果とネットワークパフォーマンスの改善についてリソースを一覧しておりますのでご参照ください。

ルート (Route)

こちらの 用語集 にあるように、ルートは1つのエンドポイントから、各ネットワークデバイスを通過して目的のエンドポイントへ達するまでの経路です。テストツールは、テスト端末からサーバー (発信ルート)とサーバーからテスト端末 (受信ルート) の2回テストを実行します。上下ボタン (page up/down buttons) をクリックして、ルートの全ホップ結果を確認します。また、Show server to client (サーバーからテスト端末) | Show client to server (テスト端末からサーバー) ボタンで両方向について確認します。

Route results

受信 (サーバーからテスト端末)テストでは、最後のホップがテスト端末です。発信 (テスト端末からサーバー) テストでは、テストサーバーが最後のホップになります。IPアドレスで最初の2桁が同じホップについては、通常省略できます。

ルート測定結果の分析

初回の2ホップ、また最後のホップにおけるパケットロス:ご利用のネットワーク内、あるいはネットワークとインターネットプロバイダー間で重大な問題がある可能性があります。御社IT管理者とご連携ください。

不均衡なホップ数:発信、受信の両ルートでホップ数がおよそ同じ場合、ルーティングには特段問題ありません。一方のルートが19ホップ、他方が11など不均衡な場合は御社IT管理者へ連携し、インターネットプロバイダーなどと必要な措置を講じてください。

ホップが終了しない、1000ホップ数:20以上のホップ数は通常値外、25ホップ以上は重大な問題が考えられます。VPN接続では ping テストを省略し100%パケットロスを表示することがあります。VPNを無効にして再テストを実行しホップ数が均衡するか確認します。合わせて、上述の [Note:クラウドサービスについて] をご参照ください。

ネットワークに関する参照・リソース一覧 ヘルプ記事では、測定結果とネットワークパフォーマンスの改善についてリソースを一覧しておりますのでご参照ください。

VoIP

こちらの 用語集 にあるように、ジッターはVoIP品質をみる上でキーとなる測定値です。この項目では、パケットロスとジッターに焦点をあててVoIP利用に適正であるかを分析します。テストでは10回の連続したVoIPコール (G.711 音声コーデック) をシミュレートし、ジッター、パケットロス、MOSスコアを測定します。

VoIP results

ジッターが高い場合、通信データの到達が不安定な状況を意味し、音声の途切れの原因になり、またネットワークロードが高くなります。リアルタイム通信の観点より、ジッターは 5ms (ミリ秒) 以下が適正値です。

ジッターは、瞬間的なブリップ、時間にともない継続する遅延、または短期間の音声の途切れなどの原因となります。

VoIP 測定結果の分析

VoIP ジッターが5ms 超となる:御社IT管理部門と連携をおすすめします。これは、通話の切断や音声のこもりの原因となる可能性があります。QoSルール によりパケット優先順位を更新し、WiFi設定や一番近いWiFiアクセスポイントへの近接性を調整、またファイル同期サービス更新中にネットワークが詰まらないよう調整するなどで改善を行うことができます。可能であれば、VoIPトラフィックを独自の最優先VLANに分離することで、他のネットワークトラフィックによる干渉を回避することができます。

VoIP ジッターにパケットロスが見られる (ジッターのパターンに限らない):ネットワーク接続に問題があります。御社IT管理部門と連携して、WiFiシグナルロス、ネットワークケーブルの損傷、スイッチのログからのエラー検知、またオフィスへのインターネットサービスでの干渉の有無などを確認します。また、古く、メンテナンスされていないネットワークインフラ機器やネットワークケーブル (ほこりをかぶったりペンキがついているなど) は、通信途中でデータが欠落する原因になります。

VoIP サマリーで SIP ALG Firewall が [Y (アクティブ)]:SIP ALG はファイアウォールの一つで、VoIP通信では非常な悪影響を与える可能性があります。インターネットプロバイダのルーターでデフォルトでオンに設定されている場合には、オフに設定して改善するかご確認ください。

ネットワークに関する参照・リソース一覧 ヘルプ記事では、測定結果とネットワークパフォーマンスの改善についてリソースを一覧しておりますのでご参照ください。

ファイアーウォール (Firewall)

こちらの 用語集 にあるように、ファイアーウォールはネットワークと機器を外部のアクセスから保護するツールです。ネットワーク自体に設定したルールと、ネットワーク上に設置された機器のファイアーウォール設定が一致していない可能性があります。ファイアーウォールは、ルールリストをチェックして、そのルールにもとづいてトラフィックを許可、またブロックします。

Firewall results

ベーシックテストで測定するファイアーウォール結果は、許可、またブロックされたポート数を表示し、また基本的なポートを数個だけテストし、またVoIP通話で使用するメディアポートをサンプリングします。ベーシックテストでブロックポートが検出された場合には、フルポートテストに進みブロックされているポートを確認してください。

フルポートテスト では、包括的なファイアーウォール結果を測定します。通話コントロール、またVoIP通信で使用されるすべてのポートを検知します。具体的にどのポートがブロックされるか確認します。

Dialpadが使用するポート一覧は、ネットワークベストプラクティス ヘルプ記事を参照ください。フルポートテスト の結果と比較して、ブロックされたポートとプロトコルを確認します。

ファイアーウォール測定結果の分析

数個のポートのみブロック:ベーシックテストでブロック数ゼロ、かつフルポートテストで数個のみブロックが検出された場合、一般的にポートのブロックが直面している問題の原因である可能性は非常に低いと考えます。これは、通信にてブロックポートへ接続して失敗すると別のポートへ再試行するためで、ブロックが数個のポートのみであれば、再試行により解消されるので影響は非常に低くなります。

数個以上のポートがプロック:多くのポートがブロックされている環境では、ポート接続が失敗後の再試行数が増加する傾向となります。この場合、通話で音声取得するまでに長い遅延が発生するなど、システムからの応答に遅延が発生します。ネットワークベストプラクティス ヘルプ記事で、Dialpad VoIPサービス利用にあたり許可が必要なポートを確認ください。

ネットワークに関する参照・リソース一覧 ヘルプ記事では、測定結果とネットワークパフォーマンスの改善についてリソースを一覧しておりますのでご参照ください。

グラフ (Graph)

こちらの 用語集 にあるように、速度は、接続をどのくらい速く感じるかなど、帯域幅と遅延の影響により測定される主観的評価です。このテストでは異なる速度でのパケットロスと遅延を測定し、最も効果的な速度にもとづいてランク付けします。グラフ (Graph) タブは左右全6ページで構成され、第1、2ページではダウンロード、アップロード速度での最適な帯域幅を測定します。

Pie graph example

第3、4ページではアップロード、ダウンロードトラフィックの速度 (青) と遅延 (赤) を時系列で表示します。ページの右下のリンクからは詳細と分析が表示されます。

Line graph example

第5、6ページでは、テストの数秒間で測定したジッター (青) とパケットロス (赤) を表示します。ジッターの適正値は5 ms (ミリ秒) 以下です。ジッターが10ms以上で、特に複数回のテストでも同様の結果となる場合には、ネットワーク接続が不十分です。ページの右下のリンクからは詳細と分析が表示されます。

Line graph example alternate

測定結果では、ダウンロードとアップロードの結果を比較して、同じ種類の問題 (パケットロスや遅延、ジッターのスパイク、極端な動作) を確認してください。

グラフの測定値の分析

ダウンロード/アップロードで遅延 (赤) が40ms以上:ネットワーク機器、あるいはインターネットプロバイダが一度に処理する通信量が過多となっている状況下では、パケットを送信してデバイスに短い間隔でデータの送信を停止させます。 これはある程度は正常な動作ですが、VoIPなどのリアルタイムシステムでは、遅延が大きすぎると音声の途切れやロボットのような音声の原因となります。

規則的なパターンのジッター:2秒毎にジッターのスパイクがあるなど規則性がある場合は、バックエンドで自動バックアップシステムの実行が走っているなどが原因であることがあります。ジッターパターンに悪影響がある場合には、御社IT管理者へ連携ください。

ネットワークに関する参照・リソース一覧 ヘルプ記事では、測定結果とネットワークパフォーマンスの改善についてリソースを一覧しておりますのでご参照ください。

ラウンドトリップタイム (RTT)

こちらの 用語集 にあるように、ルートはネットワークやインターネット上での2拠点間の通信経路です。ラウンドトリップタイム (RTT) を数度間隔をおいて測定することは端末とサーバー間のルートの効率性を確認する上で有効です。測定値が比較的同じで、平均からわずかな偏差のみである結果が適正値です。

RTT time consistency columns

RTT 測定結果の分析

高いRTT値:ラウンドトリップタイムは、1つの地理的地域と別の地理的地域のデバイスとネットワーク間で一貫している必要があります。米国および米国-カナダと米国-メキシコの国境付近では、最寄りのDialpadサーバーへのRTTは通常50ミリ秒以下です。

変動するRTT + 高いRTT値:RTTに大きなばらつきがあり、ルートのIN (イン) と OUT (アウト) が大きく異なる場合、接続するインターネットプロバイダーが不正なルートを使用している可能性があります。これらプロバイダーは最適なルートでデータ送信をしておらず、解決にはプロバイダーによるヘルプが必要です。

前のページへ ネットワークに関する記事一覧へ

 

ネットワークテストガイドの目次 へもどる

 

 

この記事は役に立ちましたか?

/