# TCPバックログキューとSYNクッキー ## 定義 TCPのインバウンド接続のバーストは2つのバックログキューで処理される。1つ目はTCPハンドシェイク中の未確立接続のためのSYNバックログ、2つ目はアプリケーションによるaccept(2)を待つ確立済み接続のためのリスンバックログである。以前のカーネルは1個のキューしか持たずSYNあふれ攻撃(偽のIPアドレスから大量のSYNを送りつけるDoS攻撃の一種)に弱かったが、2つに分離することで、最初のキューが偽の接続かもしれない要求のためのステージング領域として機能し、必要最小限のメタデータだけを格納するよう最適化できる。SYNクッキーを使っている場合はクライアントが認可済みであることがわかるため最初のキューはバイパスされる。プロセスに送られてくる接続要求が多すぎて時間内に受け入れられなくなるとバックログが上限に達し、SYNパケットが落ちてクライアントは再送しなければならなくなる。バックログに起因するドロップとSYN再送は、ホストの過負荷の指標である。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.3.7, §10.4.3.2) 2つのキューの長さは独立にチューニングできる。第1のキュー(SYNバックログ)はnet.ipv4.tcp_max_syn_backlogで、第2のキュー(リスンバックログ)はnet.core.somaxconnで、それぞれシステム全体の上限を設定する。第2のキューの長さはlisten(2)システムコールのバックログ引数という形でアプリケーションからも設定できる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.8.1.3) ## 横断的知見 (このconceptは現時点で単一ソース(詳解 システム・パフォーマンス 第2版 第10章)のみに基づく。複数ソースの突き合わせで見えた観察が蓄積されるまでは、本節は空のまま育てていく。) ## 未解決の問い - Netflixの本番sysctl例ではnet.ipv4.tcp_max_syn_backlog=8192・net.core.somaxconn=1024が使われ、2020年中にnet.core.somaxconnを4096へ引き上げることを検討中(非回帰テスト保留中)と記載されている。この変更は最終的に適用されたか、その後の版でどう扱われているか。 - tcpsynbl.btはSYNバックログの長さをヒストグラムで可視化するが、リスンバックログ側の飽和を同様に可視化する標準ツールは何か。 - SYNクッキーによるバックログバイパスは、正当なクライアントの接続確立レイテンシにどの程度の追加コストを生むか。 ## 関連 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] — 接続バックログ(§10.3.7)、TCP接続キュー(§10.4.3.2)、TCPバックログのチューニング(§10.8.1.3)、tcpsynbl.btによる可視化(§10.6.12.3.2)。 - [[詳解 システム・パフォーマンス 第2版]] ## 出典 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.3.7, §10.4.3.2, §10.6.12.3.2, §10.8.1.3