Rev.12を表示中。最新版はこちら。

1. 概要

listen()時に指定するbacklogに関するメモ。

2. backlogとsyn backlog

 listen()システムコールでLISTEN状態にあるソケットはbacklogというキューを持つ。backlogにはクライアントからのTCP接続要求が確立(ESTABLISH状態)し、まだaccept()されていない接続が並ぶ。

Listenソケットはbacklog以外にもTCP接続中(SYN_RECV状態)の接続を格納しておくキューがある。各種ドキュメントではキューと呼んでいるが、実際にはハッシュテーブルで実装されている。ここではsyn backlogと呼ぶ。

backlogのキューはinet_csk(sk)->icsk_accept_queueの.rskq_accept_headと.rskq_accept_tailで管理され、syn backlogのハッシュはinet_csk(sk)->icsk_accept_queue.listen_opt->syn_tableで管理される(図1)。

図1 Listenソケットとbacklog

backlogのキュー長はlisten()時に指定されるbacklog引数の値に設定される。ただし、指定値がsysctlのnet.core.somaxconnより大きかった場合は、net.core.somaxconnの値に切り詰められる。

syn backlogの最大サイズはbacklog値を8〜net.ipv4.tcp_max_syn_backlogの範囲に収めた後、一つ上の2の階乗の値に切り上げた値になる。例えば、backlog長が200ならsyn backlogサイズは256、backlog長が256ならsyn backlogサイズは512となる(syn backlogの初期化処理はreqsk_queue_alloc()で行っている)。

3. SYN Flood攻撃の検出とSYN cookies

SYN Flood攻撃を受けるとSYN_RECV状態の接続が大量にできる。SYN RECVがsyn backlogからあふれた場合の動作はnet.ipv4.tcp_syncookiesの設定により異なる。

(1) net.ipv4.tcp_syncookies = 0の場合

SYN_RECVの数がsyn backlogの最大サイズの3/4を越えると、新たにSYN_RECVは登録せず廃棄する。このため、新たにTCP接続を確立できない。

(2) net.ipv4.tcp_syncookies = 1の場合

SYN_RECVの数がsyn backlogの最大サイズを越えると、SYN Flood攻撃と判断しSYN cookiesの動作が始まる。

SYN Flood攻撃への耐性をあげようとsyn backlogのサイズを大きくしようとする場合は、以下の点に注意する。

(a) net.ipv4.tcp_max_syn_backlogを大きくする

(b) listen()で指定するbacklog値を大きくする(apacheならListenBackLogディレクティブで指定できる)

(c) backlogの値自体はnet.core.somaxconnに切り詰められるため、net.core.somaxconnの方も大きくしておく。

syn backlogの最大サイズはbacklogサイズに基づいて決まるため(2. backlogとsyn backlog を参照)、net.ipv4.tcp_max_syn_backlogを大きくするだけでなく、backlog自体が大きくなるように(b),(c)も行う必要がある。