スループット
スループット(throughput)は、一般に単位時間当たりの処理能力やデータ転送量のこと。特に以下の用例が挙げられる。
コンピュータやネットワークが一定時間内に処理できるデータ量のこと。レイテンシとならんで、パフォーマンスの評価基準となる。
コンピュータ・ネットワークを構成する機器によって、送信フレームが損失しない最大レート(後述のRFC定義)。
機器や規格の仕様に基づいた理論上の数値から求められる単位時間あたりの処理能力やデータ転送量の最大値のことを理論スループット(theoretical throughput)あるいは理論最大スループット(theoretical maximum throughput)という。
一方、実際に通信や計算を行なったときの単位時間あたりの処理能力やデータ転送量のことを実効スループット(effective throughput)あるいは有効スループットという。
日本産業規格による翻訳では「伝送速度」という直訳が割り当てられているネットワーク関連規格もある。
コンピュータの、単位時間あたりの処理能力を指す。データ処理におけるスループットには、コンピュータに搭載されるCPU/GPUのクロック周波数や並列コア数、メモリおよびバスの帯域幅、ハードディスクの回転速度、ソリッドステートドライブの読み書き速度、オペレーティングシステムなど、様々な要因が影響する。
単位時間あたりのデータ転送量を指す。家庭用のルーターや無線LAN機器などで、「スループット:50Mbps」などと表記される。なお、表記されるスループットは理論値の場合があり、一般的に理論値どおりのスループットを引き出すのは難しい。
ネットワーク機器や通信回線の導入の際には、両者のスループットの違いについて考慮すべきである(例えば、家庭用ブロードバンド回線に接続する機器は、回線と同程度か、もしくはそれを超えるスループットのものとするなど)。
スループットの低い機器や回線が途中経路に存在すると、そこがボトルネックになる。
スループットの測定法には各種ある。専用の測定機器としてはSpirent社のSmartBitsが有名である。一般的な測定方法としては、異なった比率の負荷トラフィックを機器にそれぞれ転送させ、その負荷別の得失差を検証し、負荷トラフィックのフレームサイズごとのスループットを求める方法がある。
また、ADSL等のブロードバンド回線が一般家庭に普及した頃から、簡易な回線スループット測定サービスとして、インターネット上の特定サーバから自分の端末までのTCP/IPスループットを簡単に測定することができるウェブサイトが現れている。
あるネットワークにおいてデータを転送する速度であるスループットの尺度には、bps(ビット/秒)が用いられている。回線提供事業者は、ネットワークが維持できる最大量のスループット、理論上の最適な条件のものを宣伝する。しかし、こうした最大値が、コンピュータなどの機器が処理できる速度を上回っていれば、処理できる速度に制限される。
こうした実行速度を計測するためのウェブサイトや、端末にインストールして利用するソフトウェア/アプリケーションが存在する。
またグッドプットでは、アプリケーション層に依存しハードウェアが処理できる速度よりも小さく示なる。例えばでは、データそのものと、データを圧縮せず、CRC情報などを持つが、こうしたデータ自体以外の量(オーバーヘッド)が通信プロトコルによって異なるためである。
スピードテストの結果は、様々な要因で変動する。
経路上の各通信回線の品質、遅延や輻輳(混雑度合い)
品質が悪い(ロス率が高い)ネットワークでは再送によりスループットが低下する。
遅延が大きいと後述の帯域遅延積により、TCP最大スループットが制限される。
経路上にある各機器(ルーター等)の性能、輻輳
ルーターの遅延が大きかったりパケット損失率が高いとスループットが低下する。
TCPはスライディングウィンドウによるフロー制御を採用しているため、受信側のウィンドウサイズ(RWIN)、1つのTCPコネクション仮想回線の帯域幅(bps)、2地点間の通信遅延時間(RTT)は次の関係式で表される。
帯域幅 ≦ 定数×(RTT÷RWIN)
そのため、RTTの大きい仮想回線上では、RWINを十分大きくしないと帯域幅の上限が制限されうる。なおRTTについては、インターネットの場合は経由する全伝送路の物理的距離(光速に比例する)だけでなく、ホップ数(通信経路上で経由するルーター数)によっても大きな影響を受ける。
今日のFTTH等による高速インターネットサービスでは、幾ら回線容量が大きくなっても、1TCPコネクションのスループットは頭打ちになりやすい。それは、多くの端末の実装で、RTTに対する効率的なRWINの調整が難しいためである。
インターネットの場合、通信経路は常に一定と言うわけではなく変動した場合は遅延も変化する。
特にインターネットの場合は、それぞれの2地点の場所によって、経路や遅延なども自明的に変化する。例えば日本国内からスピードテストのサイトに接続する場合、関東地方にあるサーバーと北米のサーバーとでは後者の方が測定結果は大幅に小さい結果になる(前述の帯域遅延積による)。
サーバーの場合はスピードテスト要求が過度に集中した場合、サーバー近傍の通信回線の輻輳やサーバー自体の過負荷によりスループットは低下する。
また測定結果を表示するコンピューター側でも、オペレーティング・システムや、セキュリティソフトを含むさまざまなソフトウェアの負荷、NIC、ネットワーク・デバイスドライバの性能によりスループットが低下する。(次項移行も参照のこと)
Wi-Fi端末を使用
端末のLAN内への接続に関しては、今日の最新のWi-Fi仕様であるIEEE802.11acにおいても、有線LAN(GbE)による接続と比較して、レイテンシや実効速度の面で大幅に劣る。特に遅延の部分は影響が大きく、前述の帯域遅延積により測定結果は大幅に低下する。
今日のWebブラウザによるスピードテストにおいては、ブラウザの動作自体にある程度のマシンパワーを必要とする。低価格PC、性能の低いPCではスピードテストサイトの測定結果自体が低下する事はおろか、ブラウザの動作速度自体が緩慢であるため、ネットワークの速度如何に関わらず、実利用におけるWebブラウザの『体感速度』は大幅に低いものとなる。今日の最新スマートフォンやタブレットの性能は、低価格PCと大差がない。
日本のNTTのフレッツによるインターネット接続サービスに特有の問題であるが、IPv6関連の設定が正しく行われていない場合に、IPv6のDNS名前解決に起因する遅延として、「IPv6-IPv4フォールバック問題」や「IPv6マルチプレフィックス問題」が生じ得る。この影響下にある端末では、本番のデータ通信の直前に名前解決のために大きな遅延が生じる。この遅延が通信時間にカウントされてしまうと、1TCPコネクションに対するスピードテストの結果数値も大きく低下する。
スピードテストの1セッションにおいて、同時に複数のTCPコネクションを使って測定するサイトでは、同時に接続するコネクション数によっても結果は変動する。
Javaアプレット、JavaScript、Flashなどを利用したスピードテストサイトが依然として多数あるが、これらは今日のWebブラウザにおいては非標準であり、端末依存である。特にPC向けに設計されたサイトをスマートフォンやタブレットで利用した場合、例えブラウザーが同種(Chrome等)であっても正確な測定を阻害する場合もある。
またフレッツに限らず全世界的にも、IPv4ネットワークとIPv6ネットワークは論理上は切り離されたネットワークであり、IPv6インターネット接続サービスを利用する場合の各種方式においても、v4とv6とではネットワーク経路や品質が大きく異なる場合もあり、その状況下では、TCPv4通信とTCPv6通信の場合とで、1TCPコネクションのスピードテスト結果も大きく変動する。2016年時点においてスピードテストサイト側でIPv6通信への対応や、TCPv4、TCPv6通信のいずれかを区別し正しく表示するサイトはかなりの少数派である。なお、IPv4とIPv6の何れの通信が優先されるかは、端末の設定やルーター等の環境などによって異なる。さらに、スピードテストの際のアクセス傾向と、実際のWeb等のアプリケーションによる通信の際のアクセス傾向も異なるのが通常である。
スピードテストサイトでは殆どの場合TCPコネクションにより測定するため帯域遅延積によりスループットは頭打ちとなる。しかし、UDPデータグラムにより測定する試みはほとんどなされない。それは、UDPにおいてはフロー制御が難しく、目一杯の帯域でネットワークに対しデータグラムを送出すると、経路上のネットワークの帯域幅を食い尽くすなどDoS攻撃さながらの行為になりかねないからである(圧縮されたビデオ、オーディオストリームでは一定の時間間隔でデータグラムを送出し、さらにフロー制御を行う仕様である)。
方式としては以下のようなものがある。
JavaScriptとWebサーバにより速度を測定する方式である。
FlashのActionScriptと測定サーバにより速度を測定する方法である。
Java Appletによる測定
Java Appletと測定サーバにより速度を測定する方法である。
クライアント側とサーバ側両方に測定ソフトウェアをインストールし、測定する方法である。
1242の3.17では、「その機器によって送信フレームが損失しない最大レート」と定義されている。データストリーム中の1つのフレームが欠けたとしても、上位プロトコルのタイムアウトを待たねばならず、そこに遅延が発生する。それを回避するための事前検証として、対象機器がフレームを欠けさせること無く送信できる最大レート、つまりスループットを知ることが同RFCで推奨されている。