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

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

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

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

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

デフォルトでは、とき両方tcp_tw_reuseとtcp_tw_recycle無効になっている、カーネルはのソケットていることを確認しますTIME_WAIT十分な長さは、将来の接続に属するパケットは、古い接続の遅いパケットと間違われることはないと確信していることであることを-状態は十分な長さ、その状態のままになります。

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

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

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

• ホストが再起動されます（ただし、復旧するまでにTIME_WAITソケットの有効期限が切れている可能性があるため、問題はありません）。
• IPアドレスは他のものによってすぐに再利用されます（TIME_WAIT接続は少し残りますが、おそらく他の接続が影響を受けTCP RST、それによってスペースが解放されます）。
• 接続の途中でネットワークアドレス変換（またはsmarty-pantsファイアウォール）が行われます。

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

一部の人々は放っtcp_tw_recycletcp_tw_reusetcp_timewait_lenておくことを勧めますが、有効にして下げる。私は同意します ：-）

私はこれに噛まれたばかりだったので、おそらく誰かが私の痛みと苦しみから恩恵を受けるかもしれません。まず、多くの情報を含む関連リンク：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にアクセスする際のレイテンシを可能な限り低くします。そうなった。

影響を実際に調査せずに、一般向けのhaproxyシステムで負荷分散Webトラフィックを再度実行しました（ばか、そうですよね！）。多くのトラブルシューティングとゴーストの追跡の結果、次のことがわかりました。

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

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

ここでの短い話は、私の最近の苦しい経験では、役割に関係なく、これらをそのままにするか、一般向けサーバーで無効にすることです！

「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.

あまり助けにはなりません。この推測には、いくつかの優れた洞察もあります。

/programming/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

しかし、再利用がリサイクルより安全である理由に関する具体的な情報はありません。基本的な答えは、tcp_tw_reuseは、同じTCPパラメータを持つTIME_WAITにすでに1つ存在し、それ以上のトラフィックが予想されない状態（FINが送信されたとき）である場合、同じソケットを使用できるようにすることです）。一方、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.