web-dev-qa-db-ja.com

tcp_tw_recycle / reuseを1に設定するとどのような影響がありますか?

構成ファイルでtcp_tw_recycle/reuseの両方を1に設定しました。

これを行うことの影響は何ですか?

TCPソケットを再利用する場合、セキュリティ上のリスクはありますか?つまり、2つの異なる接続の両方でデータを送信できる可能性がありますか?

再接続の可能性が少しある短期間の接続に適していますか?

10
codecompleting

デフォルトでは、tcp_tw_reusetcp_tw_recycleの両方が無効になっていると、カーネルはTIME_WAIT状態のソケットがその状態にとどまるようにします。将来の接続は、古い接続の遅いパケットと間違えられません。

tcp_tw_reuseを有効にすると、TIME_WAIT状態のソケットが期限切れになる前に使用でき、カーネルはTCPシーケンス番号に関する衝突がないことを確認しようとします。tcp_timestamps(別名PAWS、ラップされたシーケンス番号に対する保護)を有効にすると、これらの衝突が発生しないことが保証されます。ただし、TCPタイムスタンプを有効にする必要がありますboth終了(少なくとも、それは私の理解です)残酷な詳細については tcp_twsk_uniqueの定義 を参照してください。

tcp_tw_recycleを有効にすると、カーネルはより積極的になり、リモートホストで使用されるタイムスタンプを想定します。 TIME_WAIT状態の接続を持つ各リモートホストによって使用された最後のタイムスタンプを追跡し、タイムスタンプが正しく増加した場合にソケットを再利用できます。ただし、ホストが使用するタイムスタンプが変更された場合(つまり、時間的に反り返った場合)、SYNパケットは通知なしで破棄され、接続は確立されません(「接続タイムアウト」のようなエラーが表示されます) )。カーネルコードを詳しく知りたい場合は、 tcp_timewait_state_processの定義 が出発点として適している可能性があります。

現在、タイムスタンプは過去にさかのぼってはなりません。次の場合を除き:

  • ホストが再起動されます(ただし、復旧するまでに、TIME_WAITソケットの有効期限が切れている可能性があるため、問題はありません)。
  • iPアドレスは他のものによってすぐに再利用されます(TIME_WAIT接続は少し残りますが、他の接続はおそらくTCP RSTによって打たれ、それによって領域が解放されます);
  • ネットワークアドレス変換(またはsmarty-pants Firewall)が接続の途中で発生しています。

後者の場合、同じIPアドレスの背後に複数のホストが存在する可能性があるため、タイムスタンプのシーケンスが異なります(または、タイムスタンプはファイアウォールによって接続ごとにランダム化されます)。その場合、サーバーのTIME_WAITバケットのタイムスタンプが新しいポートにマッピングされるため、一部のホストはランダムに接続できなくなります。そのため、ドキュメントでは「NATデバイスまたはロードバランサーは設定が原因でフレームのドロップを開始する可能性がある」と説明しています。

tcp_tw_recycleをそのままにすることをお勧めしますが、tcp_tw_reuse以下を有効にするtcp_timewait_len を推奨する人もいます。私は同意します :-)

24
jpetazzo

私はこれを私に噛んだだけだったので、おそらく誰かが私の痛みと苦しみから恩恵を受けるかもしれません。まず、多くの情報を含む関連リンク: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

特に:

このドキュメントの欠如の単なる結果は、これらの両方の設定を1に設定してTIME-WAIT状態のエントリの数を減らすようにアドバイスする多数のチューニングガイドを見つけたことです。ただし、tcp(7)のマニュアルページで述べられているように、net.ipv4.tcp_tw_recycleオプションは、同じNATの背後にある2つの異なるコンピューターからの接続を処理しないため、公衆向けサーバーにとって非常に問題があります。 =デバイス、これは検出するのが難しく、あなたを噛むのを待っている問題です:

私は、クライアントからMySql NDBクラスターへの可能な限り低いレイテンシのhaproxy接続を提供するために、これらを有効にして使用しました。これはプライベートクラウド内にあり、どの接続もすべての種類のNATが混在していませんでした。ユースケースは理にかなっており、半径クライアントがhaproxyを介してNDBにヒットするためのレイテンシを低くしました人間的に可能な限り。

影響を実際に調査せずに、パブリックトラフィックハプロクシーシステムでWebトラフィックの負荷分散を再度行いました(ダム、そうですか?!)。

  • これは、NATを介して接続するクライアントに混乱を引き起こします。
  • それは完全にランダムで断続的であり、症状は顧客Aを襲い、顧客Bとはまったく異なる(またはそうでない)時期であるため、特定することはほとんど不可能です。

顧客側では、SYNパケットに対する応答が得られなくなる期間が見られます。これは、あちこちにある場合もあれば、長期間にわたる場合もあります。繰り返しますが、ランダムです。

ここでの短い話は、私の最近の痛みを伴う経験では、役割に関係なく、これらを単独で/公開サーバーで無効にしておくことです!

6
Mac

「man 7 tcp」からこれが表示されます。

_   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.
_

あまり助けにはなりません。このuestionもいくつかの良い洞察を持っています:

https://stackoverflow.com/questions/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

しかし、再利用がリサイクルよりも安全である理由に関する具体的な情報はありません。基本的な答えは、tcp_tw_reuseは、同じTCPパラメータを持つTIME_WAITにすでに1つあり、それ以上のトラフィックが予想されない状態にある場合、同じソケットを使用できるようにすることです(一方、tcp_tw_recycleは、状態に関係なく、TIME_WAITにあるソケットを同じパラメーターで再利用するだけなので、異なるパケットを予期している可能性のあるステートフルファイアウォールを混乱させる可能性があります。

tcp_tw_reuseは、SO_REUSEADDRソケットオプションを設定することにより、コードで選択的に実行できます。これは、_man 7 socket_に記載されています。

_   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.
_
4
SpamapS