3

私はUDPを使用してC#ネットワークでいくつかの作業を行ってきました。順調に進んでいますが、テストで問題が発生しているいくつかの基本的な質問への回答が必要です。

  • 現在、私は〜16000バイトのデータグラムでデータを送信しています.wiresharkによると、これは(最大パケットサイズの制限のため)いくつかの1500バイトのパケットに分割され、反対側で再構築されます.

データグラムが相手側で完全に受信されるか、まったく受信されないことを理解しているのは正しいですか。IEは、オールオアナッシングです。パケット損失により断片化されたデータグラムになる可能性はありませんか?

したがって、データグラムが 1500 バイト未満であることを確認してそれぞれに ACK を送信するのではなく、データグラムごとに ACK を送信するだけでよいのですか?

私は多くの場所を見てきましたが、データグラムと基礎となるパケットの違いには多くの混乱があるようです...

助けてくれてありがとう!

4

3 に答える 3

2

パケット損失のためにデータグラムが断片化してしまう可能性はありませんか?

それは本当だと思います。フラグメント化とフラグメントの再構築はUDPの下のプロトコル層によって処理されます。つまり、「IP」層によって処理されます。これは、パケットフラグメントをデータグラムに再構成できない場合にエラーになります(たとえば、検索RFC 792の「フラグメント」の場合)。

http://www.pcvr.nl/tcpip/udp_user.htm#11_5によると、

「宛先のIP層が再構成を実行します。目標は、パフォーマンスの低下の可能性を除いて、断片化と再構成をトランスポート層(TCPおよびUDP)に対して透過的にすることです。」

于 2012-12-08T14:26:09.780 に答える
1

16ビットのUDP長フィールドは、合計65535バイトを送信できることを示しています。ただし、データは理論的には(sizeof(IPヘッダー)+ sizeof(UDPヘッダー))= 65535-(20 + 8)=65507バイトにすることができます。

ただし、これは、UDPを使用しているすべてのアプリケーションがこの量のデータを送信することを意味するわけではありません。DNSパケットの例として、512バイトに制限されています。これは、サーバーからACKパケットを取得しないためです。これが、ネットワークでパケットが失われる可能性がある理由の1つです(パケット送信の問題と損失)。次に、IPSECまたは他のプロトコルの例のように、中間ノードが別のプロトコル内にデータグラムをカプセル化する場合があります。

UDPの場合、ACKパケットはありません。したがって、基盤となるアプリケーションがUDPを使用している場合、ACKパケットは表示されません。次に、一部のサーバーは、アプリケーションに応じてサイズを最大UDPパケットに制限するため、クライアントからサーバーへのデータ転送がある場合は、同じバイト、たとえば512バイトが表示されるはずです。Wiresharkで行ったり来たりします。ほとんどの場合、送信元は要求を行い、宛先はXバイトのUDPデータグラムを送り返します。

これらのリンクはあなたの質問に役立つかもしれません:

  1. WiresharkのUDP分析
  2. RFC 1122 (576が最小の最大再構成バッファサイズであると述べています)
于 2012-12-08T14:26:20.130 に答える
-1

データグラムが相手側で完全に受信されるか、まったく受信されないことを理解しているのは正しいですか。IEは、オールオアナッシングです。パケット損失により断片化されたデータグラムになる可能性はありませんか?

それは正しいです。

したがって、データグラムが 1500 バイト未満であることを確認してそれぞれに ACK を送信するのではなく、データグラムごとに ACK を送信するだけでよいのですか?

この質問がわかりません。サイズに関係なく、各データグラムに ACK を送信する必要があります。断片化されないように、データグラムを 1500 バイト未満にする必要があります。そうしないと、特定のデータグラムが繰り返し断片化され、断片が繰り返し失われると、まったく送信できなくなる可能性があります。

于 2012-12-08T22:58:02.767 に答える