サーバーからのデータに対して並列要求を発行するクライアントがあります。各リクエストは個別の TCP 接続を使用します。受信したデータに基づいて、使用可能なスループット (帯域幅) を推定したいと考えています。
1 つの接続 TCP 接続の場合、ダウンロードされたデータの量をデータのダウンロードにかかった時間で割ることで、これを行うことができることを知っています。しかし、複数の同時接続があることを考えると、接続によってダウンロードされたすべてのデータを合計し、最初の要求を送信してから最後のバイトが到着するまでの時間 (つまり、最後に終了するダウンロードの最後のバイト)? それとも、ここで何かを見落としていますか？
[これは以前の回答を書き直したもので、乱雑になりすぎています]
スループットを計算するために測定したい 2 つのコンポーネントがあります。転送されたバイトの合計数と、それらのバイトの転送にかかった合計時間です。これら 2 つの数値が得られたら、バイト数を期間で割り、スループット (1 秒あたりのバイト数) を取得します。
転送されたバイト数の計算は簡単です。各 TCP 接続で転送したバイト数を集計し、シーケンスの最後にすべての集計を合計して 1 つの合計にします。
1 つの TCP 接続が転送を行うのにかかる時間の計算も同様に簡単です。TCP 接続が最初のバイトを受信した時間 (t0) と最後のバイトを受信した時間 (t1) を記録するだけです。であり、その接続の期間は (t1-t0) です。
すべての TCP 接続が同時に開始および停止するという保証がないため、またはそれらのダウンロード期間が交差するという保証さえないため、集約プロセス (OTOH) が完了するまでにかかる時間の計算はそれほど明白ではありません。まったく。たとえば、5 つの TCP 接続があり、そのうちの最初の 4 つがすぐに開始され、1 秒以内に終了するシナリオを想像してください。一方、最後の TCP 接続はハンドシェイク中にいくつかのパケットをドロップし、5 秒までダウンロードを開始しません。開始から 1 秒後に終了します。そのシナリオでは、総ダウンロード プロセスの所要時間は 6 秒、2 秒、または ??? だったと言えますか?
ダウンロードがアクティブでなかった「デッド タイム」 (つまり、上記の t=1 から t=5 までの時間) を集計期間の一部としてカウントする場合、集計期間の計算は簡単です。単に減算するだけです。最大の t1 値から最小の t0 値。(これにより、上記の例では合計で 6 秒の継続時間が得られます)。ただし、ダウンロードが 1 回遅れると、報告された帯域幅の見積もりが大幅に減少する可能性があるため、これは私たちが望んでいるものではない可能性があります。
おそらくより正確な方法は、集計期間には、少なくとも 1 つの TCP ダウンロードがアクティブであった期間のみを含める必要があると言うことです。そうすれば、結果には無駄な時間が含まれないため、おそらくネットワーク パスの実際の帯域幅をより適切に反映したものになります。
そのためには、すべての TCP ダウンロードの開始時刻 (t0s) と終了時刻 (t1s) を時間間隔のリストとして取得し、以下のスケッチに示すように重複する時間間隔をマージする必要があります。次に、マージされた時間間隔の期間を合計して、総期間を取得できます。
