構成ファイルで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タイムスタンプを有効にする必要がありますboth終了(少なくとも、それは私の理解です)残酷な詳細については tcp_twsk_uniqueの定義 を参照してください。
tcp_tw_recycle
を有効にすると、カーネルはより積極的になり、リモートホストで使用されるタイムスタンプを想定します。 TIME_WAIT
状態の接続を持つ各リモートホストによって使用された最後のタイムスタンプを追跡し、タイムスタンプが正しく増加した場合にソケットを再利用できます。ただし、ホストが使用するタイムスタンプが変更された場合(つまり、時間的に反り返った場合)、SYN
パケットは通知なしで破棄され、接続は確立されません(「接続タイムアウト」のようなエラーが表示されます) )。カーネルコードを詳しく知りたい場合は、 tcp_timewait_state_processの定義 が出発点として適している可能性があります。
現在、タイムスタンプは過去にさかのぼってはなりません。次の場合を除き:
TIME_WAIT
ソケットの有効期限が切れている可能性があるため、問題はありません)。TIME_WAIT
接続は少し残りますが、他の接続はおそらくTCP RST
によって打たれ、それによって領域が解放されます);後者の場合、同じIPアドレスの背後に複数のホストが存在する可能性があるため、タイムスタンプのシーケンスが異なります(または、タイムスタンプはファイアウォールによって接続ごとにランダム化されます)。その場合、サーバーのTIME_WAIT
バケットのタイムスタンプが新しいポートにマッピングされるため、一部のホストはランダムに接続できなくなります。そのため、ドキュメントでは「NATデバイスまたはロードバランサーは設定が原因でフレームのドロップを開始する可能性がある」と説明しています。
tcp_tw_recycle
をそのままにすることをお勧めしますが、tcp_tw_reuse
以下を有効にするtcp_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にヒットするためのレイテンシを低くしました人間的に可能な限り。
影響を実際に調査せずに、パブリックトラフィックハプロクシーシステムでWebトラフィックの負荷分散を再度行いました(ダム、そうですか?!)。
顧客側では、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.
_
あまり助けにはなりません。この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.
_