3

UDP チェックサム メカニズムを理解しようとしていました。このパケットを使用しています。すべてのフィールドを合計すると、UDP の長さが 2 回含まれる例を見ました。チェックサムに UDP の長さを 2 回含める必要があるのはなぜですか?

これは私が見た例です

IP header: Source IP address c0a8
… 0291
IP header: Destination IP address c0a8
… 0101
IP header: Protocol number(zero padded on left) 0011
16 bit UDP Length 0032
UDP header: source port 0618
UDP header: destination port 0035
UDP header: length 0032
UDP Data 
0001
0100
0001
0000
0000
0000
0131
0131
0331
3638
0331
3932
0769
6e2d
6164
6472
0461
7270
6100
000c
0001
  • すべての 16 進値の合計 181e
  • キャリー4
  • キャリーに追加 1822
  • 1 の補数 = チェックサム! E7dd
4

2 に答える 2

4

本当の理由は、疑似ヘッダーが UDP 用に作成されていないことです。これは TCP 用に定義され、UDP 用に含めることで使用されます。

TCP には、TCP ヘッダーに個別の長さフィールドがありません。TCP パケットのペイロード サイズは、IP パケットのサイズからヘッダーのサイズを引いたものです。特定の種類の破損から保護するために、TCP 設計者は実際のペイロードの長さを疑似ヘッダーに含めることにしました。

UDP は、独自のものを何も定義しないことにしました。代わりに、TCP 疑似ヘッダーをそのまま組み込みました。UDP のヘッダーには長さフィールドがあるため、UDP チェックサムを計算するために同じフィールドが 2 回使用されていることがわかります。

TCP に同様のフィールドが含まれていないのと同じ理由で、UDP ヘッダーの UDP の長さ自体が冗長であると主張できます。その理由も歴史的なものであり、IPv4 が確定する前に UDP が定義されたことに関係していることを理解する必要があります。これは、UDP RFC の日付が 1980 年 8 月であるのに対し、IP RFC の日付が 1981 年 9 月 (つまり、1 年以上後) であるという事実によって裏付けられています。

于 2014-10-14T08:52:43.777 に答える
3

それがRFC 768で述べられていることだからです。それ以外の答えは実際にはあり得ません。

于 2013-10-06T20:46:39.990 に答える