☰

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.

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

記事を読んでも、3 ウェイ ハンドシェイクが完了するのを待つことの利点が何なのかよくわかりません。httpd接続が確立された後に遅延が発生する可能性をなくすため、ハンドシェイクがまだ進行中に関連インスタンスをスワップインする必要がないようにすることが有利であるように思われます。

この記事に関して、ソケットの状態に関係なく、4 つのパケット (それぞれハンドシェイク、データ) が必要になるようにも思えますTCP_DEFER_ACCEPT。どのようにしてカウントを 3 つに減らすのか、またそれがどのように意味のある機能強化をもたらすのかはわかりません。

私の質問は基本的に、これは単に古くて廃止されたオプションなのか、それともこのオプションの実際の使用例はあるのかということです。

答え1

（OPに対する私のコメントを要約すると）

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

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

確かに、アイドル プロセスを起動すると、それらのプロセスがさらに処理できる状態になる (非常に古いマシンでログイン ターミナルを起動し、スワップから読み込んだことを特に覚えています) という議論もありますが、そのプロセスをスワップアウトしたマシンはすでにリソースを要求しており、さらに不要な要求を行うと、システム全体のパフォーマンスが低下する可能性があるとも言えます。これは、個々のスレッドの見かけ上のパフォーマンスが向上したとしても (実際には向上しない可能性もあります。非常に忙しいマシンではディスク IO にボトルネックがあり、スワップインすると他の処理が遅くなります。それほど忙しい場合は、すぐにスリープするとすぐにスワップアウトされる可能性があります)。これはギャンブルのように思えますし、結局のところ、この「貪欲な」ギャンブルは、ビジー状態のマシンでは必ずしも報われるわけではなく、すでにプロセスがスワップインされているマシンでは余分な不要な作業を引き起こすことは確かです。あなたのアプローチは、ほとんどが休止状態のプロセスの大きなメモリ セットを持つマシン向けに最適化されており、休止状態を別の休止状態にスワップすることは大した問題ではありませんが、アクティブなプロセスの大きなメモリ セットを持つマシンは余分な IO に悩まされ、メモリが制限されていないマシンはすべて苦しみ、CPU に縛られたマシンはさらに悪い状況になります。

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

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

答え2

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

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

  1. サーバ: 「こんにちは、エピファイト株式会社です。」
  2. 発信者: 「こんにちは、ランディです。」
  3. サーバ: 「はい、どうぞご用件を」
  4. 発信者:通話の本文はジョークを要求することから始まります

これらはTCPにおいてチャネルが確立されていることを確認するために重要です。クライアントが送信を開始した場合呼び出し本体(3)を聞く前に、サーバーが聞いていないか準備ができていない可能性があります。(3)を聞いても、サーバーが送信後にすぐに自然発火しなかったことが保証されるわけではありませんが、サーバーが受信する準備ができているという確信は高まります。

前述の通り、握手に関するWikipedia:

  1. アリス[サーバー]は確認番号y + 1の確認メッセージで応答し、ボブ[クライアント]はそれを受け取り、彼は返事をする必要がない。

したがって、サーバーが準備完了であるという確実性を少し犠牲にしても構わないのであれば、Server はステップ (3) をスキップでき、クライアントはサーバーが準備完了であると想定するだけです。これにより、上記のプロトコル交換は次のようになります。

  1. サーバ: 「こんにちは、エピファイト株式会社です。」
  2. 発信者: 「こんにちは、ランディです。」
  3. 発信者: 「イメルダ・マルコスに関するジョークを知っていますか？」

関連情報