TCP_DEFER_ACCEPTの実際の使用？

私はApache httpdマニュアルをオンラインで閲覧していて、これを有効にするためのディレクティブに出会いました。次のマニュアルページで説明を見つけましたtcp。

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

それから私はこの記事を見つけましたが、これがどのようなワークロードに役立つかはまだわかりません。httpdこのための特別なオプションがある場合、Webサーバーとの関連性が必要だと思います。またhttpd、ネットワーク接続の方法だけでなく、オプションであるという事実から、必要なユースケースとそうでないユースケースがあると仮定しています。

記事を読んだ後でも、3方向ハンドシェイクが完了するのを待つことの利点が何であるかはわかりません。httpd接続が形成された後に遅延を引き起こす可能性がある代わりに、ハンドシェイクが継続している間にそうすることで、関連するインスタンスをスワップインする必要がないことを保証することは有利に思えます。

また、この記事でTCP_DEFER_ACCEPTは、ソケットの状態に関係なく、4つのパケット（ハンドシェーク、その後データ）が必要になると思われます。彼らがどのようにカウントを3に減らすか、それがどのように意味のある強化を提供するのか分かりません。

だから私の質問は基本的には、これは単に古い時代遅れのオプションですか、このオプションの実際のユースケースはありますか？

（OPに関する私のコメントを要約するため）

参照している3ウェイハンドシェイクはTCP接続確立の一部であり、問​​題のオプションはこれに特に関連していません。また、データ交換は3方向ハンドシェイクの一部ではないことに注意してください。これにより、TCP接続がオープン/確立状態で作成されます。

このオプションの存在に関しては、これはソケットの従来の動作ではありません。通常、接続が受け入れられると（まだ3ウェイハンドシェイクが完了した後）、ソケットハンドラのスレッドが起動され、一部のプロトコルアクティビティはここから始まります（たとえば、SMTPサーバーは220挨拶行を送信しますが、HTTPの場合、会話の最初のメッセージはWebブラウザーがGET / POST / etc行を送信し、これが発生するまで、HTTPサーバーは接続に関係しません（タイミング以外）そのため、ソケットの受け入れが完了したときにHTTPプロセスをウェイクアップすることは、プロセスがすぐに再びスリープ状態になって必要なデータを待機するため、無駄なアクティビティです。

アイドル状態のプロセスを起動すると、さらに処理を行う準備が整うという議論は確かにありますが（特に、非常に古いマシンでログイン端末を起動し、スワップから追い込むことを覚えています）、また、スワップアウトされたプロセスはすでにリソースを要求しているため、さらに不必要な要求を行うと、システムパフォーマンスが全体的に低下する可能性があります-個々のスレッドの見かけのパフォーマンスが向上したとしてもあなたがスワップインした場合、他のことを遅くし、その忙しい場合、即時のスリープはすぐにそれをスワップアウトするかもしれません）。それはギャンブルのようであり、最終的に「貪欲な」ギャンブルは忙しいマシンで必ずしも報われるとは限りません。

そのレベルのパフォーマンスチューニングに関する一般的なアドバイスは、とにかく何が最善かについてプログラムで決定するのではなく、システム管理者とオペレーティングシステムが連携してリソース管理の問題に対処できるようにすることです。システム全体およびそれ以降のワークロードを理解するのにより適しています。オプションと構成の選択肢を提供します。

質問に具体的に答えるために、このオプションはすべての構成で有益であり、HTTPトラフィックの極端な負荷下を除いて、おそらく気付くレベルではありませんが、理論的には「正しい」方法です。すべてのUnix（すべてのLinuxでさえ）フレーバーがその機能を持っているわけではないため、これはオプションです。したがって、移植性のために、傾斜しないように構成することができます。

3ウェイハンドシェイクが完了するのを待つことの利点が何であるかはわかりません。

スリーウェイハンドシェイクは、音声電話の一般的なプロトコルです。

1. サーバー：「こんにちは、Epiphyte Corp.」
2. 呼び出し元：「こんにちは、これはランディです。」
3. サーバー：「はい、どのようにお手伝いしますか？」
4. 呼び出し元：呼び出しの本文が冗談を要求し始めます

それらは、チャネルが確立されることを保証するためにTCPで重要です。クライアントが（3）を聞く前にコールのボディの送信を開始した場合、サーバーがリッスンしていないか、準備ができていない可能性があります。ヒアリング（3）は、サーバーが送信後すぐに自然発火しないことを保証するものではありませんが、サーバーが受信する準備ができているという自信を高めます。

ハンドシェイクに関するウィキペディアに記載されているとおり：

1. アリス[サーバー]は、確認番号y + 1の確認メッセージで返信します。ボブ[クライアント]はこれを受信し、返信する必要はありません。

したがって、サーバーの準備ができているという少しの確実性を放棄しても構わない場合、サーバーは手順（3）をスキップでき、クライアントはサーバーの準備が整ったと見なします。これにより、上記のプロトコル交換が次のようになります。

1. サーバー：「こんにちは、Epiphyte Corp.」
2. 呼び出し元：「こんにちは、これはランディです。」
3. 呼び出し元：「イメルダマルコスについてジョークを知っていますか？」