☰

TCP_DEFER_ACCEPTの実際の使用？

tag-icon • tag-icon linux networking tcp webserver
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に減らしたのか、それがどのように意味のある改善を提供したのかわかりません。

だから私の質問は基本的にこれです。これは単に役に立たないオプションですか、それともこのオプションの実際のユースケースはありますか？

答え1

(OPに関する私の意見のまとめ)

彼らが言及する3ウェイハンドシェイクはTCP接続設定の一部であり、議論されたオプションはこれに特別な関係はありません。さらに、データ交換は3方向ハンドシェイクの一部ではなく、単にオープン/設定状態でTCP接続を作成するだけです。

このオプションの存在に関して、これはソケットの伝統的な動作ではありません。通常、接続が承認されると、ソケットハンドラのスレッドが起動します（これはまだ3方向ハンドシェイクが完了した後です）、いくつかのプロトコルアクティビティは次から始まります。ここでは（たとえば、SMTPサーバーは220グリーティング行を送信します）、HTTPの場合、セッションの最初のメッセージはWebブラウザがGET / POST / etc行を送信することであり、HTTPサーバーはこれまで接続に興味がありません。 （タイミングを除く））ソケットの承認が完了したときにHTTPプロセスを起こすのは無駄な活動です。これは、プロセスが必要なデータを待つとすぐに再びスリープモードに移行するためです。

アイドルプロセスを覚醒させると、追加処理のために「準備」になると主張することもできますが（特に非常に古いシステムでログイン端末を起きてスワップから引き込むようにした記憶があります）、Aプロセスが次のように主張することもできます。交換がすでにリソースを必要とし、不要な追加要求が発生すると、システム全体のパフォーマンスが低下する可能性があります。個々のスレッドでパフォーマンスが著しく向上しても（非常に忙しいシステムではそうではありません）、ボトルネックが発生します。交換すると、他の作業が遅くなるディスクIOです。忙しい場合は、スリープモードのためにすぐに交換できます。これはギャンブルのように見え、最終的に「貪欲な」ギャンブルは忙しいコンピュータでは必ずしも成果を上げるわけではなく、すでにプロセスを変更したコンピュータで不要な追加作業を引き起こす可能性があります。あなたのアプローチは、The machineを使用しているコンピュータを対象としています。大部分のスリープモードである大規模なインメモリプロセスセットに最適化されており、一方のスリープ状態を別のスリープ状態に変更することは大きな問題ではありませんが、大量のメモリアクティブプロセスセットを持つマシンは追加のIOの影響を受けます。それ以外のすべてのメモリバインドシステムは影響を受け、CPUバインドシステムはさらに悪化します。

このレベルのパフォーマンス調整に関する一般的なアドバイスは、何が最善であるかをプログラムで決定するのではなく、システム管理者とオペレーティングシステムが一緒に作業してリソース管理の問題を処理できるようにすることです。これが彼らの使命であり、責任はたくさんあります。システム全体やその他のシステムのワークロードを理解するのに適しています。オプションと構成の選択肢を提供します。

質問に具体的に答えると、このオプションはHTTPトラフィックの過酷な負荷を除いてすべての設定に適しており、目立つレベルには移動しませんが、理論的には「正しい」方法です。すべてのUnixバージョン（またはすべてのLinux）にこの機能があるわけではないので、これはオプションです。したがって、移植性のためにそれらを含めないように構成できます。

答え2

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

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

  1. 仕える人:「こんにちは、Epiphyte Corp.」
  2. 訪問者：「こんにちは、私はランディです。」
  3. 仕える人：「はい、助けが必要ですか？」
  4. 訪問者:電話のテキストメッセージが冗談を要求し始めます。

これは、チャネル設定を保証するためにTCPで非常に重要です。クライアントが転送を開始すると文字通話サーバーは、聞く前に聞いていないか、準備ができていない可能性があります（3）。 Hearing（3）は、サーバーが送信直後に自然に燃焼しないことを保証しませんが、サーバーが受信する準備ができているという信頼性を高めます。

で述べたように握手に関するウィキペディア:

  1. Alice[サーバ]は確認番号y+1の確認メッセージで応答し、Bob[クライアント]はメッセージを受け取り、次に送信します。その人は返信する必要はありません。。

したがって、サーバーが準備されたという少しの確信を放棄したい場合、サーバーは（3）ステップをスキップすることができ、クライアントはサーバーが準備されたと仮定します。これは上記のプロトコル交換を次のように置き換えます。

  1. 仕える人:「こんにちは、Epiphyte Corp.」
  2. 訪問者：「こんにちは、私はランディです。」
  3. 訪問者：「イメルダマルコスについての冗談を知っていますか？」

関連情報