UDPの.Receive（）は1kの部分で断片化されたデータグラムを返す

Question

UDPの私の理解は、MTUサイズの制限がある間に、データグラムがMTUを超えると、IPレイヤーでフラグメント化され、別個のパケットとして受信し、次に受信側で再構成する。フラグメントの1つがドロップされた場合、UDPレイヤーはデータグラム全体をドロップします。すべてが到着すれば、IP層はデータグラムを再構成し、UDPはそれを全体として受け取るべきです。

これは私が経験している動作ではありません。ここでは単純なサーバーループ

var udp = new UdpClient(port); 

while (true) { 
    IPEndPoint remote = new IPEndPoint(IPAddress.Any, 0); 

    byte[] payload = udp.Receive(ref remote); 

    Console.WriteLine($"Received {payload.Length}, IP: {remote}"); 
} 

およびサーバーループはサイズ1024、1024と951バイトのペイロードで三回受け

head -c 2999 /dev/urandom | nc -4u -w1 localhost 8999 

を以下のようnetcatを介してデータの2999 bytesを送信します。 2*1024 + 951 = 2999以降、私が送信しようとしていたデータが実際に送信されたのは明らかですが、UdpClientは3つの異なるデータグラムとして受信しています。

これはUDP層がデータグラム全体に作用するという事実と矛盾しているようです。 UDPで直接作業する場合は、独自のフラグメント再構成ロジックを実装する必要がありますか？あるいは、完全なデータグラムだけを受信する方法はありますか？

Answer 1

あなたのUDPの理解は本当に正しいです。すべてのフラグメントが宛先に到着する限り、プロトコルは透過的にフラグメント化と再アセンブリを処理します。私は当初、headが1024バイトのチャンクでnetcatにデータを渡す可能性があると考えていましたが、そうではありません。

実際には反対のシナリオです。netcatは、1024バイトのブロックでstdinから読み取り、毎回新しいUDPパケットを生成しています。 netcatは、下層でどのようにパケット化されているかにほとんど関係のないデータの連続ストリームを処理するのに最適です。

詳細はthis StackOverflow questionをご覧ください。