ネットワークが突然終了すると、TCP接続はどうなりますか
ユーザースペースアプリケーションにTCP非ローカルエンドポイントとの接続があるとします。ある時点で、ネットワークが突然切断されます（つまり、ネットワークマネージャーで接続が削除され、wifiドングルが抜かれ、イーサネットケーブルが切断されます）
この状況に対処するためにカーネル内で概念的に何が起こっているのでしょうか。また、それがユーザースペースアプリケーションにどのように現れるのでしょうか。
ガイドラインのサブ質問：
- 関係するタイムアウトは何ですか？
- カーネルは、再接続を試みている間に接続が失われたことをユーザースペースから隠そうとしますか？
- 応答を待つことで、ユーザースペースアプリが正常に終了したくない場合がありますか？
ネットワークインターフェイスまたは他のインフラストラクチャがダウンしても、必ずしも「接続が失われた」ことを意味するわけではありません-TCPは、接続を切断する前に長時間再送信を試み続ける可能性があります（何が起こったかによって異なります-エラーローカルインターフェイスはおそらく即時エラーを引き起こしますが、パスのどこかでダウンしているルーターはそうではないかもしれません）。
これはカーネル次第ではありません。TCPプロトコルによって決定され、「ユーザースペースアプリ」はソケットでエラーを受信する前に長時間待機する可能性があります。
各サブ質問に具体的に答えるには：
- タイムアウトの最大9分前の提案を見てきました（これらのタイムアウトのいくつかは構成可能である可能性があり、プロトコルで許可されており、TCPキープアライブはより早くタイムアウトを引き起こすように構成できます） ;
- カーネルは物事を隠したり、「再接続」しようとしたりせず、単にTCPプロトコルに従い、未確認のセグメントの送信を継続的に再試行します...「ユーザースペースアプリ」はシステムコール内で一時停止するだけです（例：write（）、sendto（）など）。つまり、「ユーザースペースアプリ」はカーネルモードで実行されており、コンテキストが切り替えられ、何らかのイベントによってプロセスが「実行可能」になるまで元に戻されません。 "再び;
- 一時停止中、「ユーザースペースアプリ」は「中断不能」である可能性があります。つまり、ルートとしてSIGKILL（つまり、kill -9）を使用しても、それを強制終了することはできません。これはソケットでの送信で発生する可能性があるとは思わないでください。短期的で優先度が高いと見なされるものである必要があります。たとえば、ハードマウントとintrフラグが設定されていないNFS上のファイルへの書き込みで実行できます）...ただし、オプションであっても、エラーをキャッチして正常に終了するように「アプリ」を作成する必要があります。カーネルが「アプリ」を終了すると、正常に終了しません：-）（たとえば、exitを実行しません）ハンドラーまたは「アプリ」の外部に割り当てられたリソースの解放など）