私はApachehttpdマニュアルをオンラインで熟読していて、これを有効にするための指示に出くわしました。 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に関する私のコメントを要約するため）
彼らが参照しているスリーウェイハンドシェイクはTCP接続確立の一部であり、問題のオプションは特にこれに関連していません。また、データ交換は3ウェイハンドシェイクの一部ではなく、オープン/確立された状態でTCP接続を作成するだけであることに注意してください。
このオプションの存在に関して、これはソケットの従来の動作ではありません。通常、接続が受け入れられると（3ウェイハンドシェイクが完了した後でも）、ソケットハンドラーのスレッドがウェイクアップされ、一部のプロトコルではここでアクティビティが開始されます（たとえば、SMTPサーバーは220のグリーティング行を送信しますが、HTTPの場合、会話の最初のメッセージはGET / POST / etc行を送信するWebブラウザーであり、これが発生するまで、HTTPサーバーは接続に関心がありません（タイミング以外）したがって、ソケットの受け入れが完了したときにHTTPプロセスをウェイクアップすることは、プロセスが必要なデータを待ってすぐに再びスリープ状態になるため、無駄なアクティビティです。
アイドル状態のプロセスをウェイクアップすると、さらに処理できるようになるという議論は確かにありますが（特に、非常に古いマシンでログイン端末をウェイクアップし、スワップからチャグインさせることを覚えています）。スワップアウトされたプロセスはすでにリソースを要求しており、さらに不要な要求を行うと、システムパフォーマンスが全体的に低下する可能性があります。ただし、個々のスレッドの見かけのパフォーマンスが向上したとしても（そうでない場合もあります）、非常にビジーなマシンではディスクIOにボトルネックが発生します。スワップインした場合は他の処理を遅くし、忙しい場合は、すぐにスリープ状態にするとすぐにスワップアウトする可能性があります）。それはギャンブルのようであり、最終的には「貪欲な」ギャンブルは必ずしも忙しいマシンで報われるわけではなく、プロセスがすでにスワップインされているマシンで余分な不要な作業を確実に引き起こします-あなたのアプローチはほとんど休止状態にあるプロセスの大規模なメモリセット、およびある休止状態を別の休止状態に交換することは大したことではありませんが、アクティブなプロセスの大規模なメモリセットを備えたマシンは、余分なIOの影響を受け、メモリが制限されていないマシンは、 CPUにバインドされたマシンは悪化します。
関連：Linux – Linux上のrsyncがすべてのタイムスタンプ（作成時間）を保持しないのはなぜですか？そのレベルのパフォーマンス調整に関する私の一般的なアドバイスは、とにかく何が最善かについてプログラムによる決定を行うのではなく、システム管理者とオペレーティングシステムがリソース管理の問題に対処するために協力できるようにすることです。システム全体およびそれ以降のワークロードを理解するのに適しています。オプションと構成の選択肢を提供します。
質問に具体的に答えるために、このオプションはすべての構成で有益であり、HTTPトラフィックの極端な負荷がかかっている場合を除いて、これまで気付かなかったレベルではありませんが、理論的には「正しい」方法です。すべてのUnix（すべてのLinuxでさえも）フレーバーがその機能を備えているわけではないため、これはオプションです。したがって、移植性のために、傾斜しないように構成できます。