TCP速度テスターアルゴリズムの質問

Question

私はISPの会社で働いています。私たちはお客様のためにスピードテスターを開発していますが、TCPスピードテストでいくつかの問題に取り組んでいます。

1つのクライアントの合計時間間隔は102秒で、8192のパケットサイズで100 MBを転送しました。100.000.000/8192 = 12.202パケット。クライアントがACKを送信する場合は、ACKを送信するだけの時間が多くかかるように見えます。クライアントが6000個のACKを送信し、RTTが15ミリ秒であるとします。つまり、ACKの場合は6000 * 7.5 = 45.000ms = 45秒ですか？

私はMbit/sのためにこの計算を使用する場合：私はMbpで/秒で結果を取得します

(((sizeof_download_in_bytes/durationinseconds) /1000) /1000) * 8 = Mbp/s 

が、その後、TTLが送信者とクライアントの下Mbpで/ sの間にある高をスピードになる。

ユーザがサーバに近いとシミュレートするには、Mbp/sの最終結果でACK応答時間を削除するのが「合法」ですか？これは、エンドユーザがサーバに近いことをシミュレートするようなものでしょうか？

(((sizeof_download_in_bytes/(durationinseconds - 45sec)) /1000)/1000) * 8 = Mbp/s 

ことが有効である：

は、だから私は、エンドユーザにこの計算を表示していましたか？

Answer 1

ここでの問題は、RTTが大きすぎて帯域幅全体が使用されないことです。 TCPウィンドウのサイズを増やしたい場合は、テスト目的でソケット単位で行うことができ、system-wideとすることもできます。

スピードテストプログラムが最適ではないシステム設定を通知し、それらを修正するオプションを提供していれば、私はそれを素晴らしいサービスと考えています。

TCPウィンドウの設定が正しい場合は、かなりの数のパケットを失っていない限り、RTTはTCP速度テストでは問題にならないはずです（ただし、最初は検出したいものです）。

Answer 2

TCPはウィンドウフロー制御を利用し、通常は次のフレームを送信する前にACKを待つことはありません。 ACKはデータフレームと同時に送られ、追加の壁時計時間を必要としません。最近のTCP実装では、このようなRTTとビットレートをスピード・ロスなしに処理できます。

だから、正しい計算は、あなたが必ず本当にあなたのテストサーバーに、顧客のPCから8192 MTUのネットワークを持っている、また、数1

のですか？ 1500 MTUのイーサネットセグメントが存在し、8192バイトの送信バッファが標準的な1500バイトのTCPセグメントにTCPスタックで分割されている可能性があります。

最後に、1024バイトがキロバイトで、1024キロバイトがメガバイトです。