TCPパケットでフラグメント化しない」の利点？
お客様の1人が、アプリケーション（PC上）からサーバー（地理的に異なる場所）にデータを送信するのに問題があります。 1100バイト未満のパケットを送信すると、すべてが正常に機能しますが、これを超えると、TCP数秒ごとにパケットを再送信し、応答がありません。テストに使用しているパケットは約1400バイトです（ただし、それより少ない） 1472よりも）。1472バイトのICMP pingをwww.google.comに送信して、応答を取得できます（したがって、ルーター/最初の数ホップではありません）。
アプリケーションがこれらのパケットにDFフラグを設定していることがわかりました。サーバーに向かう途中のルーターのMTUは1100以下であり、パケットをドロップしていると思います。
これは5000人に1人のクライアントに影響しますが、すべての人のルートが異なるため、これは予想されます。
データはSOAPエンベロープであり、SOAP応答が返されることを期待しています。なぜそれを行うのか正当化できません。これを行うためのコードは、以前の開発者。
だから...何か利点はありますかORDFフラグをTCPパケットに設定することの正当化アプリケーションデータ？
ネットワーク診断アプリケーションに必要な理由は考えられますが、私たちの状況では必要ありません（データがフラグメント化されているかどうかに関係なく、エンドポイントに到達する必要があります）。私たちのシステム管理者の1人は、SSLを使用することと関係があるかもしれないと言いましたが、私が知る限り、SSLはストリームのようなものであり、断片化に関係なく、ストリームが最後に再構築される限り、問題はありません。
正当な理由がない場合は、アプリケーションの動作を変更します。
前もって感謝します。
DFフラグは通常、TCPセグメントを伝送するIPパケットに設定されます。
これは、TCP接続がパスMTUに一致するようにセグメントサイズを動的に変更でき、TCPセグメントがそれぞれ1つのIPパケットで伝送されると全体的なパフォーマンスが向上するためです。
したがって、TCPパケットにはDFフラグが設定されており、shouldにより、ICMP FragmentationNeededパケットが返されます。中間ルーターが大きすぎるためにパケットを破棄する必要がある場合。送信するTCPは、接続のパスMTU（最大伝送ユニット）の推定値を減らし、より小さなセグメントで再送信します。 DFが設定されていない場合、送信側のTCPは、送信しているセグメントが大きすぎることを認識しません。このプロセスはPMTU-D（「パスMTUディスカバリー」）と呼ばれます。
ICMP Fragmentation Neededパケットが通過しない場合は、壊れたネットワークを処理しています。理想的には、最初のステップは、誤って構成されたデバイスを特定し、それを修正することです。ただし、それでも問題が解決しない場合は、アプリケーションに構成ノブを追加して、setsockopt()でTCP_MAXSEGソケットオプションを設定するように指示します。 （誤って構成されたデバイスの典型的な例は、経験の浅いネットワーク管理者によってallICMPをドロップするように構成されたルーターまたはファイアウォールであり、フラグメンテーションが必要なパケットを認識していませんTCP PMTU-D）で必要です。
Path-MTUディスカバリーの操作は、RFC 1191、 https://tools.ietf.org/html/rfc1191 で説明されています。 TCPは、特定のサイズを超えるすべてのパケットを2つの部分（通常は1つは大きいものと1つは小さいもの）に断片化するよりも、Path-MTUを検出する方が適切です。