strace ... -e sendtoどこかにUDPデータグラムを送信しようとする成功した（つまり正の戻り値）試行の結果を表示しますが、そのtcpdump -i anyネットワーク名前空間に関連付けられた応答は表示しません。
sendto発信パケットが発生しない理由をどのようにデバッグできますか？すべての層（ルーティング、フロー制御、nftablesなど）で要求を追跡し、データグラム内の情報がカーネルから消えたときに出力できるツールはありますか？それともチェックリストを含むガイド/文書がありますか？詳細これが起こる理由のリストは何ですか？
ベストアンサー1
コンピュータが独自のパケット、特にUDPパケットを聞くことができるという保証はありません。したがって、sendto（）と同じシステムでtcpdumpを実行すると、sendtoが有効であっても予想される動作を見つけることができます。
送信元と送信先の間のルータ（または他のネットワークデバイス）が何らかの理由で（メモリ、帯域幅、停電、宇宙船、ルーティングループなど）パケットを送信できない場合、UDPパケットは破棄または複製されます。または事前の通知なしに注文されていない状態で受け取ります。
UDPパケットが転送されるという保証はありません。カーネルにメモリが不足すると削除されることがあります。メッセージを送信しようとしたときにネットワークがいっぱいになると、メッセージが削除されることがあります。当時、受信コンピュータの使用量が多すぎると削除されることがあります。したがって、sendtoが動作し、別のコンピュータでtcpdumpを実行しても、tcpdumpはまだパケットを見ることができません。
パケットが転送されていないという事実を送信者が受信できる唯一の通知は、宛先がパケットの受け入れを積極的に拒否したり、中間ルータがパケットを転送するためのパスがないと判断した場合です。さらに、これらの通知は特定のパケットに対して保証されず、パケットグループ全体に対して一度だけ送信できます。
これらの条件が気に入らない場合は、UDPを使用しないでください。任意の理由で「信頼できないデータグラムプロトコル」という名前は指定されていません。 UDPのポイントは、遅延パケットが無駄なパケットであることです。 UDPは安定性ではなく速度に最適化されています。パケットの信頼性が高く秩序ある配信を保証するTCPのプロトコルは、パケット遅延、制限、保存、バッファリング、分解、再組み立て、照合、およびバッチ処理を引き起こす可能性があります。技術的には、tcpはパケットも提供せず、tcpが提供するデータストリームにはパケット境界があるだけであり、これらの「境界」は送信者と受信者で同じであることは保証されません。