IPv6 でiperf ( https://iperf.fr/ ) を使用して UDP 帯域幅テストを行っています。次のコマンド ラインで Linux UDP クライアントを使用すると、非常に悪い結果が得られます。
iperf -u -V -c fe80::5910:d4ff:fe31:5b10%usb0 -b 100m
Wireshark で問題を調査すると、クライアントがデータを送信している間に断片化が発生することがわかりました。より正確には、サイズが 1510 バイトと 92 バイトの UDP クライアント送信パケットが交互に表示されます。たとえば、私が確認した UDP パケットには次のパターン (サイズ) があります: 1510、92、1510、92、1510、92、...、1510、92、...
iperf2 のドキュメントを読む オプション (-l) については、次を読みます。
読み書きするバッファの長さ。iPerf は、len バイトの配列を何度も書き込むことによって機能します。デフォルトは、TCP の場合は 8 KB、UDP の場合は 1470 バイトです。UDP の場合、これはデータグラム サイズであり、IPv6 アドレッシングを使用する場合は、断片化を避けるために 1450 以下に減らす必要があります。-n および -t オプションも参照してください。
Linux iperf UDP クライアント コマンド ラインを次のように置き換えて、同じ帯域幅テストを実行しようとしました。
iperf -u -V -c fe80::5910:d4ff:fe31:5b10%usb0 -b 100m -l1450
良い結果が得られます。Wireshark のキャプチャを見ると、断片化が見られません。
IPv4 で同じテストを行うと、良い結果を得るためにデフォルトの UDP データグラム サイズを変更する必要はありません (「-l」オプションを使用する必要はありません)。
したがって、私の結論は、断片化 (IPv6 経由) が帯域幅パフォーマンスの低下の原因であるということです。
とにかく、UDP データグラムのサイズを IPv6 で 1450 に設定すると実際に何が起こるのか疑問に思っています。UDP データグラム サイズのデフォルト値で、IPv4 ではなく IPv6 でフラグメンテーションが発生するのはなぜですか? さらに、UDP データグラムのサイズを 1450 に減らすと断片化が発生しないのはなぜですか?
ありがとうございました。