since 2004/09/12 06:00

この サイトが重い時には ミラーサイト(RIMNET) の計測ページを使って下さい
また
3Mバイト版takuoさんのサイト にあります 
関連内容: MTUに関するFAQ(第2版)  最適 TCP受信窓 (RWIN) の計算


使い方
JavaScript 使用。 
アクセス手段の速度
 によって
データサイズ
 を選んで下さい。 
左側は、そのサイズの
 データで受信速度を測
 る通常タイプです。 
右側
同時2接続
 1接続あたり半分の量
 のデータを、2接続
 同時に受信します。 
 それにより、単一接続と
 は異なる帯域条件の下
 で、転送の効率性や安
 定性などを調べることが
 可能になります。 
 ちなみに Webブラウザ
 は、既定モードで最高
 同時4接続のデータ転
 送を行なって、回線帯
 域を効率的に利用して
 います。 
○ クリックした後、「
計測
 
」の印が消えると、別
 窓に測定結果が表示さ
 れます。


データ受信速度の計測
 
アクセス手段
の速度
〜 256k bps
データサイズ
アクセス手段
の速度
256k 〜 800k bps
データサイズ
アクセス手段
の速度
800k 〜 1.6M bps
データサイズ
アクセス手段
の速度
1.6M 〜 (3.2M) bps
データサイズ




速度変化グラフに時々現われる異常に高い速度 について

TCPエラー訂正の影響

混雑時にはパケットを捨てて各部の転送能力を維持するインターネットのベスト・エフォート方式を支えているのが、 TCP(インターネットの標準転送方式)のエラー訂正機能です。

パケットロスが発生すると、受信側では、その欠番部が再送により補填されるまでの間、継続受信している欠番以降のパケット・データは TCPバッファー部に保管され、Webブラウザは受け取れなくなります。

              <----- TCP受信バッファ ----->|<--- Webブラウザ ---
  回線→[11]→                          [9]→

              <----- TCP受信バッファ ----->|<--- Webブラウザ ---
  回線→[12]→                     [11]欠番|待ち状態
        ← 再送要求(SACK or 3-dup-ACKs) ┘

  (より正確には「欠番連絡」であり、[12]以降に対する確認応答で再送条件が決まる)

そのため、補填作業中の状態で終了した 部分計測区間では、Webブラウザが受け取るデータ量はその部分区間の回線受信量より少なくなる傾向を持ちます。

              <----- TCP受信バッファ ----->|<--- Webブラウザ ---
  回線→[10]→ [16]欠番[14][13][12][11]欠番|待ち状態
        ← 再送要求 ┘(SACK有効時)

              <----- TCP受信バッファ ----->|<--- Webブラウザ ---
  回線→[17]→                     [16]欠番|[14][13][12][11][10]
        ← 再送要求(SACK無効時) ────┘

また、より前の部分区間から続いていた補填作業が(一部または全部)完了して Webブラウザに保管データが渡された時点を含む部分区間では、Webブラウザが受け取るデータ量は回線受信量より多くなる傾向を持ちます。

しかし、計測区間全体で見れば、この 回線受信量Webブラウザ受信量の違いは相殺されます。(稀に発生する不要な再送パケットの回線受信量を除く)


Webブラウザその他の処理速度ムラ

また、アクセス装置から PCの OSにパケットが渡される時も、RS232C, USB, イーサネットなどのインターフェース部で、比較的大きな処理速度のムラが発生する環境もあります。しかしより一般的に発生するのは、 Webブラウザの処理速度ムラでしょう。

             <--------------- 処理速度ムラ -------------->
  回線終端装置→インターフェース部→TCP/IP処理→Webブラウザ

Webブラウザが受け取ったデータを解釈・実行する時は、(ネットワーク装置を処理する時とは違って) 時間的な同期を要求されないため、非常に短い時間内で見れば、全く処理を行わない時溜まったデータをまとめて処理する時 とがあります。また処理する時の速度も、その時の PCの他の仕事の負荷状態と(Webブラウザに)残された処理パワーによって異なります。

  |--------------------- PC の作業配分 ---------------------|
  ←緊急的なイベント同期型作業→ 他の作業(残されたパワー内)

したがって同じ受信データ量でも、受信が高速 になるにつれてデータが到着する時間間隔が短くなって、同期を要求される緊急的な作業が増えると同時に、速度変化グラフがより短時間内の変動を表わすようになって、この Webブラウザの処理速度ムラがグラフ上に現われるようになります。

そのこともあって、速度計測では、高いデータ転送速度 ほどより大きなデータサイズを選んで、全体や各部の計測間隔が時間的に同程度(全体で 5〜10秒、部分で 0.5〜1秒程度)になるようにしています。また、計測している間、(寂しく^^;)ただじっと待つのは、計測中の Webブラウザに他の作業による負荷を加えないためです。

── ◆ ──

ちなみに、もしも(微少時間内のムラではなく)より 平均的な状況においてすら、データの流入速度が Webブラウザの処理限界を超えてしまった場合には、まず Webブラウザ内の未処理バッファーが一杯になり、次に TCP受信バッファー内に引き取れないデータが溜ります。

              <----- TCP受信バッファ ----->|<--- Webブラウザ ---
  回線→[26]→         [25][24][23][22][21] 引き取れない
        ← 通知するTCP受信窓サイズを縮小 ┘

この時、TCPのデータ受信側は、受信確認応答(ACK)パケットの中で常に 送信側に通知している TCP受信窓(RWIN)の値を小さくして、送信側に送出速度の抑制を依頼します。そうして低い流入速度によって、Webブラウザが TCP受信バッファー内のデータをすべて引き取ることが可能になると、通知するTCP受信窓の値を元に戻し、送信側に送出速度の抑制解除 を依頼します。しかしその速度では Webブラウザが処理し切れないため … と、このサイクルが全データ転送の終りまで繰り返されます。

つまり、データ転送・処理全体の流れが破綻 するのを防止するために、受信側の処理状況に合わせて送信側の送出速度を変化させるメカニズムが、(インターネットに)組み込まれているわけです。

Webブラウザの種類CPU速度 などによって、計測結果に大きな違いが出るのは、上のように受信ホスト側の処理能力が流れを抑制しているケースです。また逆に、受信ホスト側の処理能力や回線容量が十分でも、受信ホストの TCP受信窓サイズ設定値 が小さすぎる場合には、最初から常に、不必要な送出速度抑制を送信側に依頼していることになるため、広帯域アクセス環境では注意が必要です。

  

 
モデムページにもどる