ユーザー空間アプリケーションに、ローカルではなく一部のエンドポイントへのTCP接続があるとします。ある時点でネットワーク接続が突然切断されます（たとえば、ネットワーク管理者からの接続の削除、WiFiアダプタの取り外し、イーサネットケーブルの切断）。
概念的には、この状況を処理するためにカーネル内で何が起こっていますか？これはユーザースペースアプリケーションにどのように現れますか？
ガイドサブ質問：
- どのタイムアウトが関連していますか？
- カーネルは、再接続を試みるときにユーザー空間で接続損失を隠そうとしますか？
- 応答を待つと、ユーザースペースアプリケーションが正常に終了しなくなりますか？
ベストアンサー1
ネットワークインタフェースまたは他のインフラストラクチャのエラーが必ずしも「接続を切断する」ことを意味するわけではありません。 TCPは、接続を終了する前に長時間再送信を試みることができます（発生した状況によって異なります）。ローカルインターフェイスのエラーはすぐにエラーを引き起こす可能性がありますが、それに応じてルートに沿ってどこかに降りるAルータはそうではありません).
これはカーネルではなくTCPプロトコルによって決定され、「ユーザー空間アプリケーション」はソケットからエラーを受け取るのに長い時間を待つ可能性があります。
各サブ質問に具体的に答えてください。
- 制限時間を超過する前に最大9分の推奨事項を見たことがあります（プロトコルが許可する限り、これらのタイムアウトのいくつかは設定可能であり、TCPキープアライブなどのエントリはより早いタイムアウトを引き起こすように設定できます）と思います）。
- カーネルはコンテンツを非表示にしたり、「再接続」を試みたりすることなく、TCPプロトコルに従い、不正なセグメントを送信しようとし続けます。 （））で中断されます。など）、すなわち、「ユーザ空間アプリケーション」はカーネルモードで実行され、そのコンテキストは切り替えられ、一部のイベントがプロセスを再度「実行可能」にするまで再び切り替えられない。
- 中断中、「ユーザー空間アプリケーション」は「中断不可能」になる可能性があります。つまり、rootとしてSIGKILL（Kill -9など）を使用しても終了できません。 「エレガントなシャットダウン」はオプションではないかもしれません（私はそうではありません）。そうしてください）ソケットから転送するときにこれが起こらないと思う場合は、寿命が短く優先順位が高いと見なす必要があります。たとえば、ハードマウントを介してNFSのファイルに書き込む場合、intrフラグが設定されていない場合はそうすることができます。 ...しかし、それがオプションであってもエラーをキャッチし、それ自体が正常に終了するには、「アプリケーション」を書く必要があります。カーネルが「アプリケーション」を終了した場合、エレガントではありません。