ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % COMP5311 プロジェクト: TCP および UDP のパフォーマンス分析
newpage
Youtube ビデオを視聴するときに、Chrome ブラウザが Firefox よりもはるかに速く感じるのはなぜだろうか?私もそうなのですが、好奇心旺盛な学生として Wireshark を起動してトラフィックをキャプチャしたところ、これが見つかりました。
wiki 1によると、Chrome Web ブラウザから Google サーバーへのすべての接続の半分以上で QUIC が使用されています。
QUIC は、多数の多重 UDP を確立することで、現在 TCP 2 を使用している Web アプリケーションを改善することを目的としたプロトコルであり、「TCP/2」と呼ばれることもあります。次期 HTTP/3 (2021 年 2 月時点の Internet-Draft) も QUIC を使用するとされています。
ちょっと待ってください...TCP の代わりに UDP を使用しているのですか? UDP は信頼できないと言われましたが、どうして TCP を「廃止」しようとすることができるのでしょうか。 2 つのプロトコル (TCP と UDP) の比較は、ボーイングとエアバス (両方の輸送) ではなく、電車と飛行機を比較することに似ています。ただし、これらをいくつかの重要な指標と比較して、この QUIC が何を改善するために UDP を選択したかを垣間見ることはできます。
newpage
newpage
結果に影響を与える可能性のある要因が多数あるため、トランスポート層プロトコルを比較するのは簡単な作業ではありません。
プロトコル内の一部のパラメーター (TCP など) は実装に任されています (これにより、TCP/IP フィンガープリンティングが発生し、悪意のある攻撃者が特にホストの OS を識別できるようになります)。これは、これらの違いが、ホストの OS に微妙な影響を与える可能性があることを意味します。パフォーマンスの測定
パケットが通過する直接のルートは確かに結果に影響を与えるため、直接のルーター、その間のボトルネック リンク、その他のトラフィックも結果に影響を与える可能性があります。
上で述べたように、これらの直接リンクの帯域幅、または単にクライアントとサーバー間のリンクがわからないことがよくあります。言及した論文の 1 つは、リンクでは衝突が発生しないという仮定を立てています。
バッファーがこれらのプロトコルのパフォーマンスに影響を与える可能性があることがわかりました。バッファーのソフトウェア側だけが関係するわけではなく、ハードウェア部分も重要であり、多くの場合、これらの下位レベルの詳細を完全に制御できないことがわかりました。
これまでの研究のほとんどでは、作成者は実験を行うためにカスタム プログラムを実装することがよくありましたが、これらのソフトウェア実装が結果にどのような影響を与えるか、たとえば UDP パケットの送信間隔や制限はあるかなども考慮する必要があります。現在の目的で送信間隔に関して使用されている言語。
これらすべてを考慮して、できる限り現実に近い設定の単純なネットワーク トポロジを使用します。バッファキューのサイズやプロトコルなどの基礎となる詳細については、両方のプロトコルに同じものを使用します。そのため、パフォーマンス指標としてスループット、平均遅延、平均ジッターを使用して、有線 1 対 1 ホストでの IPv4 上の TCP と UDP を比較します。
UDP アプリケーションではそれぞれ 1472 バイト、TCP アプリケーションでは同等のバイト数の 10、100、 range(1e4, 1e5, 1e4)パケットを送信して、TCP アプリケーションと UDP アプリケーションの両方のフローを観察します。
JitterSumは、フローのすべての受信パケットのすべてのエンドツーエンド遅延ジッター (遅延変動) 値の合計が含まれます。ここで、パケットのジッターをストリームの最後のパケットに対する遅延変動として定義します。
newpage
上記の実験を計画する際の最初の問題は、シミュレーションを行うかどうかです。私たちの研究では、前述した考慮事項をより詳細に制御できるため、シミュレーションの方が優れている可能性があります。最大の欠点は、結果が「本物」であることをどうやって確認できるかということです。その答えは、実験の範囲を明確に定義し、それらの範囲の健全性チェックを頻繁に行う限り、結果がどの程度「本物」であるかを把握できるということです。
ns-3 、C++ で記述された、主に研究または教育目的で使用されるオープンソースの離散イベント ネットワーク シミュレーターです。シミュレータ自体には、オンラインで入手できる包括的なドキュメントがあります。
現在の目的のために必要なのは、 ns-3の主な抽象化だけを理解することです。
{幅=75%}
これはコンピューターのプロセスのようなもので、「ソケット」を使用してデータを下位層に送信します。 TCP ソケット、 UDPClient 、UDP パケットを送信するためのUDPServer 、およびパケットを監視するためのFlowMonitor使用してns-3に既製のBulkSendApplicationをインストールします。
2 マイクロ秒の間隔でパケットを送信します。これは、以下で指定される基礎となるチャネルの遅延です。
ここではペイロードを指します。 MTU は 1500 なので、当然 1500 バイトを使用することになります。ただし、IP ヘッダーと UDP ヘッダーには 20 + 8 バイトが必要なので、 5 の代わりに 1472 を使用する必要があります。これはシミュレーションで確認されています。 1500 バイトのパケットを使用すると、スループット パフォーマンスに悪影響を及ぼす可能性があります。
BulkSendApplication「このトラフィック ジェネレーターは、MaxBytes まで、またはアプリケーションが停止するまで (MaxBytes が 0 の場合) できるだけ速くデータを送信します。下位層の送信バッファーがいっぱいになると、さらにデータを送信するためのスペースが空くまで待機し、基本的にデータを送信します。絶え間ないデータの流れ。」
パフォーマンスを比較するために MaxBytes を UDP の合計バイト数 (PacketCount * PacketSize) に設定しましたが、一部の実験では SendSize は重要ではありませんでした。
InternetStackHelperとも呼ばれます。これには通常、UDP、TCP ソケット、IPv4、そして現在の目的ではTrafficControlLayerが含まれます。これにはキューが含まれており、キューがいっぱいになると上位層に通知します。
これは、ハードウェア (ネットワーク インターフェイス カード、NIC) とそれらのソフトウェア ドライバーの両方に対応し、パケットのキューも含まれるため、 ns-3には 2 つのレベルのキューがあります。
これは、コンピューターと同様に、 Application 、 InternetStack 、 NetDeviceインストールできるエンドホストです。 2 つのNodeを作成し、イーサネット ケーブルのようなもので接続します。
Nodeに通信チャネルを提供します。CSMA チャネル (イーサネットなど) を使用します。ここで重要な詳細は、調整に使用できる属性 (MTU、DataRate、および Delay) の選択です。標準 MTU (ジャンボ フレームなし、特定のネットワークで利用できる場合もあります)、ギガビット、2 マイクロ秒の遅延を使用します。 2 マイクロ秒の理由は、他の研究では遅延が 0 であるのに対し、光は 600 メートル進むためです。
newpage
結果は次のとおりです。
送信された 14720、147200 バイトの UDP のスループットが 1000Mbps を超えていることが観察されました (帯域幅は 1Gbps)。次に、パケットの損失を調べました。
147200 バイトで、100 パケット中 97 パケットが失われたことがわかります。これら 2 つを削除し、さらに調査する必要があると言っても過言ではありません。
また、TCP スループットが徐々に増加し、400Mbps 付近で横ばいになっていることがわかります。
トラフィック制御が欠如しているため、UDP パケットが下位層のキューに「スタック」する可能性があります。この結果は、パケットを高速に常時接続して送信することで輻輳が発生したことも原因である可能性があります。実際に遅延が増加するかどうかを確認するためにバッファーを下げるなど、さらに調査を行って確認する必要があります。
平均遅延は「ピーク」の直後に低下し、その後再び徐々に増加しました。これは、輻輳回避におけるcwnd調整が原因である可能性があります。 ns-3には多くの選択肢があるため (Veno、Cubic など)、輻輳制御のアルゴリズムが実際にそのようなパターンを生成することを確認する必要があるため、さらなる調査が必要です。
システムが「安定」し、遅延の変動が少なくなるにつれて、平均ジッターは減少すると予想されます。
UDP にトラフィック制御がないということは、パケットが継続的にスタックにプッシュダウンされ、干渉なしで送信されることを意味します。遅延の変動は最小限に抑えられる一方、トラフィック制御により連続するパケットの遅延が大きくなる可能性があります。
newpage
BulkSendApplication 、下位層の送信バッファがいっぱいになると待機するようにしました。したがって、パケットをドロップできる唯一の場所は、エラーを導入する必要があるチャネル内です。
UDPClientそのようなトラフィック制御がないため、パケットの損失が観察される可能性があります。
単にスループット (スループットの向上) とジッター (遅延の変動の減少) である可能性があります。平均遅延が大きくなるのは主に、QUIC が「輻輳制御アルゴリズムをカーネル空間ではなくユーザー空間に」移動させることを目的としたトラフィック制御の欠如によるものです1 。
https://github.com/alfredtso/ns-3-project
newpage
ns-3 トレーニング リソース
HTTP/3 ドラフト
クイック ↩ ↩ 2
クイック Google ドキュメント ↩
Yuan-Cheng Lai、Ahsan Ali、Md. Shohrab Hossain、Ying-Dar Lin、ソフトウェア定義ネットワーク上の TCP および UDP フローのパフォーマンス モデリングと分析、Journal of Network and Computer Applications、第 130 巻、2019 年、ページ 76-88、ISSN 1084-8045 ↩
Jingyi He、S.-H.Gary Chan、光パケット交換ネットワーク上のインターネットの TCP および UDP パフォーマンス、Computer Networks、第 45 巻、第 4 号、2004 年、505 ～ 521 ページ、ISSN 1389-1286 ↩
Eric Games、Rina Surós、IPv4 および IPv6 における TCP および UDP スループットの上限モデル、Journal of Network and Computer Applications、第 31 巻、第 4 号、2008 年、585 ～ 602 ページ、ISSN 1084-8045 ↩ ↩ 2
Shahrudin Awang Nor、Raaid Alubady、Wisam Abduladeem Kamil、4G ネットワーク上での TCP、SCTP、DCCP、および UDP プロトコルのパフォーマンスのシミュレーション、Procedia Computer Science、第 111 巻、2017 年、ページ 2 ～ 7、ISSN 1877-0509 ↩
