スピードテスト

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動先: 案内検索

ブロードバンドスピードテスト、あるいは単にスピードテスト、とは、主にインターネット接続における実効速度に関連する指標をベンチマークし数値化する作業である。

概要[編集]

簡易な回線スループット測定サービスとして、インターネット上に公開された、「特定のスピード測定専用サーバから、自分の端末までのTCP/IPスループット」を簡単に測定することができる。

ウェブブラウザから専用サイトにアクセスするものや、端末にインストールして利用するツール等が存在する。

測定結果に対する注意点[編集]

各種スピードテストにより数値化される指標は、通信回線の帯域幅伝送路容量表すものではなく、あくまでもネットワークまたはインターネット上の2地点間におけるネットワークスループットを数値化したものでしか無い。

さらに、単一のセッション[1]における最大スループットの数値化に過ぎないので、「Webブラウザの利用上の『体感速度』」などと言うものとは殆ど関係がない。なぜなら、今日のWebブラウザの利用シーンにおいてはしばしば、1ページの表示のために数10程度のTCPコネクションが、インターネット上の世界各地に散在するサーバーに対して張られるためである。また、Webページの複雑化に伴い、端末側での表示処理、Webサーバー側での内部処理の負荷がいずれも増大しており、ネットワークスループットの影響度が小さくなっているためである。

結果を変動させる要因[編集]

1つのTCPコネクションにおけるスピードテストの結果は、しばしば以下に列記する要因によって大幅に変動する。

さらに、スピードテストの1セッションにおいて複数のTCPコネクションを同時に張って測定するサイトも多く、スピードテストの結果の数値は逓倍スパンで変動し得る[2]。よって、結果数値につき同時コネクション数の明示は重要である。

経路上の各通信回線の品質、遅延輻輳(混雑度合い)
品質が悪い(ロス率)が高いネットワークでは再送によりスループットが低下する。
遅延が大きいと後述の帯域遅延積により、TCP最大スループットが制限される。[3]
経路上にある各機器(ルーター等)の性能、輻輳
ルーター[4]の遅延が大きかったりパケット損失率が高いとスループットが低下する。
TCPによる帯域遅延積の影響
TCPはスライディングウィンドウによるフロー制御を採用しているため、受信側のウィンドウサイズ(RWIN)、1つのTCPコネクション仮想回線の帯域幅(bps)、2地点間の通信遅延時間(RTT)は次の関係式で表される。
帯域幅 ≦ 定数×(RTT÷RWIN)
そのため、RTTの大きい仮想回線上では、RWINを十分大きくしないと帯域幅の上限が制限されうる。なおRTTについては、インターネットの場合は物理的距離(光速に比例する)だけでなく、ホップ数(通信経路上で経由するルーター数)によっても大きな影響を受ける[5]
今日のFTTH等による高速インターネットサービスでは、幾ら回線容量が大きくなっても、1TCPコネクションのスループットは頭打ちになりやすい。それは、多くの端末の実装で、RTTに対する効率的なRWINの調整が難しいためである。
経路の変動
インターネットの場合、通信経路は常に一定と言うわけではなく変動した場合は遅延も変化する。
サーバーや計測側コンピューターの設置場所
特にインターネットの場合は、それぞれの2地点の場所によって、経路や遅延なども自明的に変化する。例えば日本国内からスピードテストのサイトに接続する場合、関東地方にあるサーバーと北米のサーバーとでは後者の方が測定結果は大幅に小さい結果になる(前述の帯域遅延積)。
サーバーや計測側コンピューター要因での遅延
サーバーの場合はスピードテスト要求が過度に集中した場合、サーバー近傍の通信回線の輻輳やサーバー自体の過負荷によりスループットは低下する。
また測定結果を表示するコンピューター側でも、オペレーティング・システムや、セキュリティソフトを含むさまざまなソフトウェアの負荷、NIC、ネットワーク・デバイスドライバの性能によりスループットが低下する。(次項移行も参照のこと)

正確な測定の阻害要因[編集]

Wi-Fi端末を使用
端末のLAN内への接続に関しては、今日の最新のWi-Fi仕様であるIEEE802.11acにおいても、有線LAN(GbE)による接続と比較して、レイテンシや実効速度の面で大幅に劣る。特に遅延の部分は影響が大きく、前述の帯域遅延積により測定結果は大幅に低下する。
性能の低い端末を使用
今日のWebブラウザによるスピードテストにおいては、ブラウザの動作自体にある程度のマシンパワーを必要とする。低価格PCでは測定結果が低下する事はおろか、ブラウザの動作速度自体が緩慢であるため、ネットワークの速度如何に関わらずWebブラウザの利用上の『体感速度は大幅に低いものとなる。今日の最新スマートフォンやタブレットの性能は、低価格PCと大差がない。
スピードテストサイトのWeb仕様
Javaアプレット、JavaScript、Flashなどを利用したサイトが依然として多数あるが、これらは今日のWebブラウザにおいては非標準であり、端末依存である。特にPC向けに設計されたサイトをスマートフォンやタブレットで利用した場合、例えブラウザーが同種(Chrome等)であっても正確な測定を阻害する場合もある。
IPv6に関する諸問題
日本のNTTのフレッツによるインターネット接続サービスに特有の問題であるが、IPv6関連の設定が正しく行われていない場合[6]に、IPv6のDNS名前解決に起因する遅延として、「IPv6-IPv4フォールバック問題」や「IPv6マルチプレフィックス問題」が生じ得る。この影響下にある端末では、本番のデータ通信の直前に名前解決のために大きな遅延が生じる。この遅延が通信時間にカウントされてしまうと、1TCPコネクションに対するスピードテストの結果数値も大きく低下する。
また、フレッツに限らず全世界的にも、IPv4ネットワークとIPv6ネットワークは論理上は切り離されたネットワークであり、IPv6インターネット接続サービスを利用する場合の各種方式においても、v4とv6とではネットワーク経路や品質が大きく異なる場合もあり、その状況下では、TCPv4通信とTCPv6通信の場合とで、1TCPコネクションのスピードテスト結果も大きく変動する。
2016年時点においてスピードテストサイト側でIPv6通信への対応や、TCPv4、TCPv6通信のいずれかを区別し正しく表示するサイトはかなりの少数派である。なお、IPv4とIPv6の何れの通信が優先されるかは、端末の設定やルーター等の環境などによって異なる。さらに、スピードテストの際のアクセス傾向と、実際のWeb等のアプリケーションによる通信の際のアクセス傾向も異なるのが通常である。

その他[編集]

スピードテストサイトでは殆どの場合TCPコネクションにより測定するため帯域遅延積によりスループットは頭打ちとなる。しかし、UDPデータグラムにより測定する試みはほとんどなされない。それは、UDPにおいてはフロー制御が難しく、目一杯の帯域でネットワークに対しデータグラムを送出すると、経路上のネットワークの帯域幅を食い尽くし、ルーターを過負荷にする[7]などDoS攻撃さながらの行為になりかねないからである(圧縮されたビデオ、オーディオストリームでは一定の時間間隔でデータグラムを送出し、さらにフロー制御を行う仕様である)。

測定ツールの方式[編集]

方式としては以下のようなものがある。

ブラウザによる測定
JavaScriptWebサーバにより速度を測定する方式である。
Flashによる測定
FlashのActionScriptと測定サーバにより速度を測定する方法である。
Java Appletによる測定
Java Appletと測定サーバにより速度を測定する方法である。
専用ソフトウェアによる測定
クライアント側とサーバ側両方に測定ソフトウェアをインストールし、測定する方法である。

脚注[編集]

  1. ^ 個々のTCPコネクションと言う意味ではなく、(例えば1つのWebページの表示や、1回のスピードテストと言ったような)1まとまりの通信処理の開始から終了までと言う意味である
  2. ^ 1TCPコネクションのスループットは頭打ちになりやすいためである(後述)
  3. ^ これに対し、UDPではトランスポート層レベルでは帯域遅延積の影響は受けにくい。ただし、より上位層でフロー、輻輳制御が必要となる。
  4. ^ ここでは、ISP基幹ネットワークで使用するものから、ブロードバンドルーターまでの、ルーター全般のこと
  5. ^ 伝送路容量が低い領域(数Mbps程度)ではRWIN、RTTともさほど問題にならなかったが、FTTHなどの伝送路容量が数十Mbps〜の高速な回線が普及すると、受信側の不十分なRWINや、RTTの大きさが測定結果に大きな影響を及ぼすようになっている。
  6. ^ 詳細は「フレッツ#IPv6サービス開始前に見られた諸問題」参照
  7. ^ さらに、出口ネットワークの帯域幅がデータグラムのストリーム帯域幅より狭い場合はパケット廃棄が生じる。

関連項目[編集]

外部リンク[編集]