問題タブ [ip-fragmentation]

パケット フラグメンテーションの目的は理解しています。答えから、私が理解していないのは、全長とフラグメントのオフセットだけです。この問題を解決するためにあなたが私に与えることができる助けを大いに感謝します.

以下、質問と回答です。

ホスト A がルーター R 1 に接続され、R 1 が別のルーター R 2 に接続され、R 2 がホスト B に接続されているとします。900 バイトのデータと 20 バイトの TCP ヘッダーを含む TCP メッセージがホスト A で IP コードに渡され、B に配信されます。3 つのリンクを介して送信される各パケットの IP ヘッダーの全長、識別、DF、MF、およびフラグメント オフセット フィールドを表示します。リンク A-R1 は 14 バイトのフレーム ヘッダーを含む 1024 バイトの最大フレーム サイズをサポートでき、リンク R1-R2 は 8 バイトのフレーム ヘッダーを含む 512 バイトの最大フレーム サイズをサポートでき、リンク R2-B をサポートできると仮定します。 12 バイトのフレーム ヘッダーを含め、最大 512 バイトのフレーム サイズをサポートできます。

答え：

断片化されたパケットの再構築中に、断片化されたパケットをバッファに入れています。タイムアウトになる前に、最後のフラグメントが到着したかどうかを確認し、それらを再構築して上位層に配信します。

基本的な問題は、最後のフラグメントが他のフラグメントの前に到着した場合、再構成がどのように行われるかです。

もう1つの疑問は、フラグメントバッファを使用するのに適したデータ構造は何ですか? キーとして識別番号を持つハッシュマップは役に立ちますか?

UDP 経由で独自のプロトコルを実装しようとしています。

インターネットの多くのマニュアルで示唆されているように、MTU 未満のサイズのパケットを送信して IP フラグメンテーションを回避することをお勧めします。

メッセージの最適なサイズを取得する最良の方法は何ですか? どうにかして MTU 値を取得する必要がありますか (たとえば、このように)、または 1300 や 1400 のように単純に設定し、時間の経過とともに減少したり変化したりしないようにする必要がありますか?

MTU 値 ( https://en.wikipedia.org/wiki/Path_MTU_Discovery )を取得する際にいくつかの問題があると聞きましたが、私の知る限り、現在のルートや時間の経過とともに変化する可能性のあるその他の要因に大きく依存しています。

試験問題(追加情報なし):

多数の IP データグラム フラグメントがネットワーク経由で送信され、そのうちの 1 つだけが宛先に到達しない場合、何が起こるでしょうか?

ここで ICMP が関与しているかどうかはわかりません。ICMP は、同じフラグメント (この 1 つのフラグメントのみ) を再送信する必要があることをソースに報告するエラー レポートを送信しますか?

問題は、IP フラグメントが UDP を使用するのか TCP を使用するのかがわからないため、質問に対する答えがわからないことです。

(私は networkengineering.stackexchange に投稿しましたが、私の質問は拒否されました)

UDP ベースのシステムを設計しており、推奨される最大データ パケット サイズを知る必要があります。Ethernet v2の一般的な MTUは、私の理解では 1500 バイトです。ただし、PPoE を使用すると、1492 に低下します。

これは、一般的なネットワークでの断片化を避けるためにシステムのデータ部分を最大 1492 バイトにする必要があるということですか、それとも PPoE を無視して 1500 バイトにする必要があるのでしょうか??

Linux TUN インターフェイスを使用しているサーバー/クライアント ソケット アプリケーションに取り組んでいます。

サーバーは TUN インターフェイスから直接パケットを取得してクライアントに渡し、クライアントは受信したパケットを直接 TUN インターフェイスに入れます。

Server_TUN からのパケットは、クライアントに送信する前に IP レイヤーでフラグメント化する必要がある場合があります。

そのため、サーバーで TUN からパケットを読み取り、IP レイヤーでフラグメント化を開始し、ソケット経由でクライアントに送信します。

断片化ロジックが実装されたとき、ソリューションはうまく機能しませんでした。

Client_TUN で Wireshark を開始した後、フラグメント化されたすべての着信パケットで TCP チェックサム エラーが発生することに気付きました。

与えられたスクリーンショットでは、フレーム番号 154 が 155 で再構築されると主張されています。

しかし、TCP チェックサムは正しくないと主張されています!

サーバー側では、tcp データをそのまま保持します。この例では、Wireshark で逆のことがわかりますが、1452 バイト (IP ヘッダーを含む) と 30 バイト (IP ヘッダーを含む) のパケットを分割しました。

また、サーバーで TCP チェックサム値を確認しましたが、正確には 0x935e であり、着信パケットのチェックサム オフロードが問題になるとは思いませんでしたが、クライアントでオフロードを確認したところ、オフでした。

それにもかかわらず、解決策が現在機能していないため、オフロード効果が原因ではないと思います。

フラグメント化されたパケットの TCP チェックサムが正しくない理由を知っていますか?

UDP パケットでデータを送信するプログラムを C で作成しました。

ソケットは使用してフラグメント化されません

サーバー (debian 8 KVM 仮想化) で TSHARK をチェックすると、すべてのパケットがフラグメント化されないことが設定されています。

しかし、クライアントでは、断片化された大きなパケットが受信されます!!

次に、もっと有線のものを考え出しました。IPv4 ID フィールドが 0 に設定されました!

断片化しない効果が原因かもしれないと思いました（パケットが断片化されないため）。

次に、Openvpn プログラムを開始し、サーバーでパケットをスニッフィングしましたが、パケットに IPv4 ID != 0 がありましたが、フラグメントは設定されていませんでした。

なぜこれが私に起こっているのか分かりますか?!

編集: これは、tshark の結果からコピーして貼り付けたサーバーでの大きなパケットの別のサンプルです。

ご覧のとおり、フラグメント化しないが設定されていますが、PMTU より大きいすべてのパケットはフラグメント化されてクライアント側に受信されます。

これは、同じサーバーでの openvpn のパケット トレースの例です。ご覧のとおり、少なくともIPv4 IDが計算されています!

この質問は、Node.js Net モジュールが ip-fragmentation を処理しないことを示唆しています: Node.js how to handle packet fragmentation with net.Server

それが本当だとはほとんど想像できませんが、これに関するドキュメントは見つかりません (これに関する情報を見つけるのがそれほど難しくない場合は、ご容赦ください :-) )。本当ですか？

そうでない場合：ありがとう、それは私にとって本当に安全です:-)。

本当の場合: データグラム全体の大きさがわからない場合、この問題をどのように処理しますか?

状況: 組み込みシステム (Wiznet W5500) との TCP 接続があります。MSS (最大セグメント サイズ、MTU - 40 にほぼ等しい) は 536 に設定され、データ パッケージは可変サイズで、サイズが 4kb を超える場合があります。そのため、データ パッケージは複数のセグメントで送信されます。「オンデータ」イベントは、セグメントが受信されたときにトリガーされますか、それともパッケージ全体が受信されたときにのみトリガーされますか?

副次的な質問: データ セグメント (MSS レジスタの説明で Wiznet が話していることについて) が ip-fragment に相当するというのは正しいですか? したがって、4000 バイト (すなわちペイロード) を送信する必要があり、MSS が 536 に設定されている場合、連続して受信します: segment1: 536bytes payload segment2: 536bytes payload segment3: 536bytes payload segment4: 536bytes payload segment5: 536bytes payload segment6: 536bytes payload segment7: 536bytes payload segment8: 248bytes payload 「データ上」イベントはセグメント 8 の後にのみトリガーされ、「データ引数」にはパッケージ全体が含まれるか、それともセグメントを個別に受信するたびに「on data」イベントがトリガーされることはありますか?

処理を続行する前に、パッケージ全体を取得することを 100% 確実にするにはどうすればよいですか? 私が考えた解決策：

• データ パッケージの最初の 2 バイトは、全体の長さのバイト長です。受信したデータを、バイト数分受信するまで連結し続けます。パッケージ サイズを超えるサイズを受信した場合は、これらの連続するバイトが後続のデータ パッケージの開始であると想定します。

この「解決策」はややこしいと思いますが、それが必要でないことを願っています。

前もって感謝します！情報が不足している場合: 申し訳ありませんが、お気軽にお問い合わせください :-)。