5
私は、LAN上およびWAN上でパケットを送信するために、UDPの上で停止と待機のプロトコルを使用するプログラムを作成しています。私は最近、私のプログラムをテストしており、パケット損失率が大きいパケット（64kバイトに近づく）の方がパケット損失率が高いことに注目しました。直観的にはこれは理にかなっていますが、実際の理由は何ですか？UDPパケットのサイズとパケットの損失
A
答えて
7
これらのパケットを伝送するネットワークのMTU sizeより大きいUDPパケットは自動的に複数のパケットに分割され、受信者によって再組み立てされます。これらの複数のサブパケットのいずれかがドロップされた場合、受信者は残りのサブパケットもドロップします。
たとえば、63k UDPパケットを送信してイーサネットを経由すると、47バイト以上の小さな "フラグメント"パケットに分割されます（イーサネットのMTUは1500バイトですが、 UDPパケットで利用可能なユーザデータ空間の量はそれよりも小さい）。受信者は、47個以上のフラグメントパケットがすべて正常に通過した場合にのみ、そのUDPパケットを「参照」します。これらのフラグメントパケットのうちの1つだけがドロップされると、操作全体が失敗します。
0
まあ、データネットワークは信頼性が高くありません。パケットは常に削除されます。オーバーロードされたルータ、完全なバッファ、および破損したパケットは、いくつかの理由があります。 UDPにはフロー制御機能がないため、たとえば受信側に過負荷がかかると速度を低下させることはできません。
ジェレミーが説明したように、ペイロードが大きければ大きいほど、パケットが分割される可能性が高くなり、そのため一部のパケットが失われる可能性が高くなります。
UDPは、ここにドロップパケットが届いても、時間内に到着するかどうかに何か必要なものやケースに影響を与えない場合に使用されます。 （VoIP、ストリーミングビデオなど）
-1
すべてのIP断片化とデフラグメンテーション。 MTU以上のパケットは最終的なホストでフラグメント化され、フラグメント化されなければなりません。また、フラグメントがパス上で再びフラグメント化され、遅延が追加される可能性もあります。場合によっては、一部のN/W要素がレイヤ4フィルタリング用に設定されている場合、最適化を行い（最終ホストではない）、規則を適用してから、再度一致させて転送します。それは、パフォーマンスが必要なアプリケーションが常にサイズのデータを送信しようとする理由です。< =（MTU-ETHHDR-IPHDR）
64kパケットを送信することはできません。最大UDPペイロードは65507バイトです。 – EJP
ええと、私たちが姪を選ぶならば、65507バイトのペイロードを持つUDPパケットは65535バイト（ヘッダーを含む）です - 64KiBの1バイト不足です。しかし、正確さのために、私の例を63kに変更します。 –
この影響は、パケットロスの少ない量がパフォーマンスに大きな影響を与える可能性があります。この例では、2％のパケット損失があった場合、平均で約50％のパケットが失われ、スループットが大幅に低下します。参照：http://stackoverflow.com/a/19057666/84206 – AaronLS