アカウント名:
パスワード:
ネットワーク上に滞留していたパケットのためかと思ってたけど。Linuxではどんな扱いなんだろう？
> ネットワーク上に滞留していたパケットのためかと思ってたけど。
そうです。
> Linuxではどんな扱いなんだろう？
話に出ている tcp_tw_reuse は、
https://twitter.com/kosaki55tea/status/641267021443952640 [twitter.com]> シーケンスナンバーの初期値を十分ずらしてやれば TIME-WAITなsocketを再利用しても安全
というものだそうで。
TCP_TIMEWAIT_LEN を増やすほうは、コネクションが混ざっちゃう可能性があって、長時間滞留しているパケットがあると危険ですね。tcp_tw_reuse の方がたぶん安全。
TCPシーケンス番号予測攻撃 [wikipedia.org]を回避するためにSO_REUSEADDRに関係なくシーケンス番号をバラけさせる必要があるので「tcp_tw_reuseの方がたぶん安全」ということにはならないと思う。どっちみちランダムにバラけさせて開始するなら、低いとはいえ被る可能性があるSO_REUSEADDRの方が危ない。どうせ誤差レベルだし、他のメリット考えたらSO_REUSEADDRしといてもまず問題無いと思うけど。# Node.jsとかはデフォルトでSO_REUSEADDRだったかな。
> どっちみちランダムにバラけさせて開始するなら、低いとはいえ被る可能性があるSO_REUSEADDRの方が危ない。
だいぶ誤解があるようです。SO_REUSEADDR と tcp_tw_reuse は全然違う動作をします。
そもそも、SO_REUSEADDR は、TIME_WAIT で ip_local_port_range が満杯になっている時には効きません。効くのは、local port の自動割り当て時ではなく、bind(2) で明示的にポート番号を指定している場合だけです。
また、tcp_tw_reuse は、直前に使っていたシーケンス番号から 65535 + 2 だけ離してから再使用するので、被ることがないことが保証されてます。
だから、被る可能性がある TCP_TIMEWAIT_LEN よりも、tcp_tw_reuse の方が安全だっていうのが今回の話なわけです。
SO_REUSEADDR と tcp_tw_reuse はごっちゃにしてたよ、申し訳ない。だけどシーケンス番号を離してもその長さのデータがずらずら飛んできたらやっぱり衝突するはずです。どうせ今時のボーレートならすぐにシーケンス番号は一巡してしまうんですから。
それとtcp_tw_reuseを使わない場合にもシーケンス番号はランダム化すべきです。シーケンス番号のランダム化は昔から必要とされていたはずなのでとうぜん実装はあると思うのですが、であればそれを使うべきであって再利用のためにちょっとずらしただけの状態でいるべきではありません。
そしてシーケンス番号がランダム化されているなら、即座に再利用するより一定の時間を開けたほうが安全でしょう。長いほうが良いけど、そこはパフォーマンスとの兼ね合いもあるので考えて決める。
> だけどシーケンス番号を離してもその長さのデータがずらずら飛んできたらやっぱり衝突するはずです。
いえ、ずらしているのは送信側のシーケンス番号なので、衝突しないことは保証されています。もうクローズしたソケットですから、自分からデータを送信することはありませんから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
TIME_WAITの待ち時間 (スコア:0)
ネットワーク上に滞留していたパケットのためかと思ってたけど。
Linuxではどんな扱いなんだろう？
Re: (スコア:0)
> ネットワーク上に滞留していたパケットのためかと思ってたけど。
そうです。
> Linuxではどんな扱いなんだろう？
話に出ている tcp_tw_reuse は、
https://twitter.com/kosaki55tea/status/641267021443952640 [twitter.com]
> シーケンスナンバーの初期値を十分ずらしてやれば TIME-WAITなsocketを再利用しても安全
というものだそうで。
TCP_TIMEWAIT_LEN を増やすほうは、コネクションが混ざっちゃう可能性があって、
長時間滞留しているパケットがあると危険ですね。
tcp_tw_reuse の方がたぶん安全。
Re:TIME_WAITの待ち時間 (スコア:0)
TCPシーケンス番号予測攻撃 [wikipedia.org]を回避するためにSO_REUSEADDRに関係なくシーケンス番号をバラけさせる必要があるので「tcp_tw_reuseの方がたぶん安全」ということにはならないと思う。
どっちみちランダムにバラけさせて開始するなら、低いとはいえ被る可能性があるSO_REUSEADDRの方が危ない。
どうせ誤差レベルだし、他のメリット考えたらSO_REUSEADDRしといてもまず問題無いと思うけど。
# Node.jsとかはデフォルトでSO_REUSEADDRだったかな。
Re: (スコア:0)
> どっちみちランダムにバラけさせて開始するなら、低いとはいえ被る可能性があるSO_REUSEADDRの方が危ない。
だいぶ誤解があるようです。
SO_REUSEADDR と tcp_tw_reuse は全然違う動作をします。
そもそも、SO_REUSEADDR は、TIME_WAIT で ip_local_port_range が満杯になっている時には効きません。
効くのは、local port の自動割り当て時ではなく、bind(2) で明示的にポート番号を指定している場合だけです。
また、tcp_tw_reuse は、直前に使っていたシーケンス番号から 65535 + 2 だけ離してから再使用するので、
被ることがないことが保証されてます。
だから、被る可能性がある TCP_TIMEWAIT_LEN よりも、tcp_tw_reuse の方が安全だっていうのが今回の話なわけです。
Re: (スコア:0)
SO_REUSEADDR と tcp_tw_reuse はごっちゃにしてたよ、申し訳ない。
だけどシーケンス番号を離してもその長さのデータがずらずら飛んできたらやっぱり衝突するはずです。
どうせ今時のボーレートならすぐにシーケンス番号は一巡してしまうんですから。
それとtcp_tw_reuseを使わない場合にもシーケンス番号はランダム化すべきです。
シーケンス番号のランダム化は昔から必要とされていたはずなのでとうぜん実装はあると思うのですが、
であればそれを使うべきであって再利用のためにちょっとずらしただけの状態でいるべきではありません。
そしてシーケンス番号がランダム化されているなら、即座に再利用するより一定の時間を開けたほうが安全でしょう。
長いほうが良いけど、そこはパフォーマンスとの兼ね合いもあるので考えて決める。
Re: (スコア:0)
> だけどシーケンス番号を離してもその長さのデータがずらずら飛んできたらやっぱり衝突するはずです。
いえ、ずらしているのは送信側のシーケンス番号なので、衝突しないことは保証されています。
もうクローズしたソケットですから、自分からデータを送信することはありませんから。