回線とは？
|
混雑時にはパケットを捨てて各部の転送能力を維持するインターネットのベスト・エフォート方式を支えているのが、 パケットロスが発生すると、受信側では、その欠番部が再送により補填されるまでの間、継続受信している欠番以降のパケット・データは 部分計測区間では、Webブラウザが受け取るデータ量はその部分区間の回線受信量より少なくなる傾向を持ちます。 Webブラウザに保管データが渡された時点を含む部分区間では、Webブラウザが受け取るデータ量は回線受信量より多くなる傾向を持ちます。 回線受信量と Webブラウザ受信量の違いは相殺されます。（稀に発生する不要な再送パケットの回線受信量を除く） USB, イーサネットなどのインターフェース部で、比較的大きな処理速度のムラが発生する環境もあります。しかしより一般的に発生するのは、 時間的な同期を要求されないため、非常に短い時間内で見れば、全く処理を行わない時と溜まったデータをまとめて処理する時 とがあります。また処理する時の速度も、その時の PCの他の仕事の負荷状態と（Webブラウザに）残された処理パワーによって異なります。 になるにつれてデータが到着する時間間隔が短くなって、同期を要求される緊急的な作業が増えると同時に、速度変化グラフがより短時間内の変動を表わすようになって、この 5〜10秒、部分で 0.5〜1秒程度）になるようにしています。また、計測している間、（寂しく^^;）ただじっと待つのは、計測中の 平均的な状況においてすら、データの流入速度が Webブラウザの処理限界を超えてしまった場合には、まず Webブラウザ内の未処理バッファーが一杯になり、次に TCP受信バッファー内に引き取れないデータが溜ります。 送信側に通知している TCP受信窓（RWIN）の値を小さくして、送信側に送出速度の抑制を依頼します。そうして低い流入速度によって、Webブラウザが TCP受信バッファー内のデータをすべて引き取ることが可能になると、通知するTCP受信窓の値を元に戻し、送信側に送出速度の抑制解除 を依頼します。しかしその速度では Webブラウザが処理し切れないため … と、このサイクルが全データ転送の終りまで繰り返されます。 するのを防止するために、受信側の処理状況に合わせて送信側の送出速度を変化させるメカニズムが、（インターネットに）組み込まれているわけです。 などによって、計測結果に大きな違いが出るのは、上のように受信ホスト側の処理能力が流れを抑制しているケースです。また逆に、受信ホスト側の処理能力や回線容量が十分でも、受信ホストの TCP受信窓サイズ設定値 が小さすぎる場合には、最初から常に、不必要な送出速度抑制を送信側に依頼していることになるため、広帯域アクセス環境では注意が必要です。 |
[ 9] SPEED TEST
[引用サイト] http://homepage2.nifty.com/oso/speedtest/
