1

アプリケーションを作成していて、そのスループット (ネットワーク上で送信される 1 秒あたりのビット数) を任意のレートに設定できます。ただし、ネットワーク上の他のトラフィックが大きな影響を受けない限り、できるだけ高く設定したいと考えています。

問題は、その影響を測定するための適切な指標がないことです。私は次のものを考えましたが、どちらも実際には「完全」ではありません。

  1. パケットの平均遅延時間の増加
  2. パケットロスの増加
  3. ジッターの増加
  4. TCP トランザクションの完了にかかる平均時間の増加 (http を使用したファイルのダウンロード)

標準的な指標はありますか?ネットワークへのアプリケーションの影響を測定する方法について、他にアイデアはありますか?

ところで - 私はネットワークを完全に制御しており、そのメトリックを計算するために必要な測定を行うことができます。

ありがとう、

ロウリ

4

3 に答える 3

0

トラフィック エンジニアリングはかなり複雑な分野です。サービスの品質は、おそらくこの問題の良い出発点です。

于 2009-05-18T17:38:36.427 に答える
0

これは、プログラムで答えるのが難しいかもしれない質問の 1 つです。私が見たアプリでは、この種のスロットリングが許可されていましたが、これは常に構成オプションでした。一般に、ユーザーのネットワークについて知ることは非常に困難です。あなたが行った仮定はおそらく間違っているでしょう。

于 2009-05-18T17:45:14.307 に答える
0

帯域幅を超えると、ネットワークによって動作が異なります。それらのほとんどには、次のような一連の悪い点があります。

  1. 一部のパケットをキューに入れたり、再送信したりする必要があるため、ジッターが屋根を突き破り始めます (たとえば、半二重イーサネットまたはワイヤレスでの衝突)。平均レイテンシはわずかに上昇します。
  2. 過飽和状態が続く (または過飽和レベルが高くなる) と、ほぼすべてのパケットがキューに入れられるか再送信されるため、平均レイテンシーは屋根を通り抜けます。キューのサイズが小さい場合、これは制限される可能性があります。
  3. キューがオーバーフローすると、パケット損失が増加します。帯域幅を高くすると、より多くのパケットが失われます。ハードウェアによっては、ジッターと遅延が元に戻る場合と戻らない場合があります。

何らかの形式の QoS が使用されている場合、異なるパケット ストリームがこれらの影響を個別に見る可能性があります。たとえば、アプリ接続で 3 倍の帯域幅をポンピングしても、ping 時間の変化は比較的少ないと考えられます。したがって、アプリケーションのパケットで測定する必要があります。

(1) と (2) は、特定のネットワークでは発生しない場合があります。(3) 何があっても必ず起こる。残念ながら、この 3 つすべてが、帯域幅の制限に達していない場合でも発生する可能性があります。

于 2009-05-18T18:57:12.260 に答える