# TCP接続局所性 ## 定義 TCP 接続局所性とは、ある接続に関する NIC 割り込み、TCP 状態の検索・更新、受信ペイロード処理、送信パケット生成、アプリケーションアクセスを同じ CPU コアで処理する性質である。接続単位のデータ構造と処理をコアへ固定することで、CPU キャッシュバウンスとコア間同期を減らし、established table のコア単位分割を正しく成立させる。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]] §1, §2.2) ## 設計軸 - **局所化の範囲**: 受動接続だけか、プロキシや RPC で重要な能動接続も含むか。 - **状態の分割単位**: listen table、established table、TCB、ソケットバッファをコアごとに持つか。 - **パケットの到着制御**: RSS、RFS、RFD、NIC の Flow Director など、受信パケットをどのコアへ届けるか。 - **アプリケーションとの結合**: プロセスやスレッドを CPU コアへ固定するか、処理ループの所有者を統合側へ委ねるか。 - **障害時の堅牢性**: コア局所化した高速経路と、アプリケーション障害時に使う共有の救済経路をどう併存させるか。 - **互換性との境界**: カーネルの機能と BSD socket API を保持したまま内部状態だけを分割するか、カーネルを迂回して API と機能を置き換えるか。 ## Fastsocket の実現 [[Fastsocket]] は、Local Listen Table と Local Established Table を CPU コア単位に分割し、Receive Flow Deliver（RFD）で能動接続の応答パケットを担当コアへ戻す。Local Listen Table は受動接続を局所化し、global listen socket を障害時の救済経路として残す。RFD は送信元ポートへコア番号を符号化し、返送パケットの宛先ポートからコアを復元する。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]] §3.2–§3.3) Fastsocket の評価では、RSS だけの能動接続 local packet 比率は 6.2%だった。RFD と RSS の組み合わせはスループットを 261K cps から 277K cps へ 6.1%向上させ、FDir Perfect-Filtering と RFD の組み合わせは local packet 比率 100%、スループット 293K cps から 300K cps への 2.4%向上を得た。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]] §4.2.4) ## 横断的知見 - **接続局所性はカーネル内外の両方で、スケーラビリティの中心問題として現れる**: Fastsocket はカーネル TCP スタックのテーブルと VFS を分割し、mTCP は TCP スレッド、TCB、ソケットバッファをユーザー空間のコアごとに分離する。両者は実行場所が異なるが、共有状態とコア間移動を減らすことが短命接続の性能向上の共通手段になっている。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]], [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]]) - **受信割り込みを均等に分散することと、接続を局所化することは同じではない**: Fastsocket の RSS 単独条件では NIC はパケットをコアへ分散するが、アプリケーションの処理コアとの一致は 6.2% にとどまった。RFS はアプリケーションの最後の実行コアを参照するがテーブル管理と容量制限を伴い、RFD はポート符号化と NIC 機能を使って能動接続の対応を明示的に作る。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]], [[RFS（Receive Flow Steering）]]) - **局所性は性能最適化だけでなく、コア単位の状態分割の正しさを支える**: established socket を作成したコアと後続パケットを処理するコアが異なると、単純な per-core established table は接続を見失う。したがって「状態を分けること」と「パケットを正しい状態所有者へ届けること」は分離できない設計問題である。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]]) - **固定的な一接続一コアと、選択可能な実行モデルには緊張関係がある**: Fastsocket は接続を一つのコアへ固定し、mTCP はアプリケーションスレッドと TCP スレッドを一対一で対応づける。一方、iip は split、merge、unified の CPU コア割り当てモデルを統合側が選べる。局所性の強さと、負荷変動に対する柔軟な再配置は同じ設計軸上のトレードオフになる。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]], [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]], [[@2024__SIGCOMM CCR__iip - An Integratable TCP IP Stack]]) - **接続の寿命と測定対象によって、局所性の利得の現れ方が変わる**: Fastsocket と mTCP は短命接続の確立・終了、共有ロック、キャッシュバウンスを主に削減する。100 Gbps 級の長フローでは受信側データコピー、NUMA、キャッシュ容量が支配的になり、2026 年の短い RPC では softIRQ 計上、公平性、割り込み調整がテールレイテンシを支配する。接続局所性は必要条件になり得るが、すべてのホストネットワークボトルネックを単独では説明しない。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]], [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]], [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) - **カーネルバイパスは接続局所性を実現する一つの経路にすぎない**: mTCP や iip はユーザー空間でコア局所状態を持つが、Fastsocket はカーネルの TCP 機能、BSD socket API、VFS 外部互換性を残したまま内部を分割する。比較すべきなのはカーネルかユーザー空間かという二値ではなく、状態所有者、パケット到着先、アプリケーション実行コア、互換性境界の組み合わせである。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]], [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]], [[@2024__SIGCOMM CCR__iip - An Integratable TCP IP Stack]]) ## 未解決の問い - 現代の Linux、マルチキュー NIC、NUMA、DPU 環境で、Fastsocket 型のカーネル内テーブル分割と mTCP・iip 型のユーザー空間実装を同じ短命接続ワークロードで比較すると、どの設計軸が支配的になるか。 - 接続を一コアへ固定する方式は、動的な負荷変動、コア障害、CPU 周波数制御、コンテナ移動時の状態移送コストを含めても有効か。 - RSS、RFS、RFD、FDir、XDP、io_uring を組み合わせる場合、NIC・カーネル・アプリケーションのどの層が接続の状態所有権を宣言すべきか。 - 接続局所性を保ちながら、長短フロー混在時の受信側データコピー、GRO/TSO の集約、NUMA 非局所性を同時に最適化できるか。 - Per-Core Process Zone の局所化と、ネットワーク要求数を単位とする CPU 公平性を両立させるスケジューラ設計は可能か。 - コア単位の高速経路と global socket の障害救済経路を、アプリケーション障害・パケット再順序化・攻撃的ポート選択の下でも形式的に検証できるか。 ## 関連 - [[Fastsocket]] — カーネル内テーブル分割と RFD で接続局所性を実現するシステム。 - [[ユーザーレベルTCPスタック]] — mTCP など、カーネル外でコア局所 TCP 処理を行う系譜。 - [[RSS（Receive Side Scaling）]] — NIC が受信キューを CPU コアへ分散する基盤。 - [[RFS（Receive Flow Steering）]] — アプリケーションの実行コアを考慮する Linux の受信制御。 - [[TCP IPスタック統合|TCP/IPスタック統合]] — 状態所有者、実行ループ、NIC 機能の責任境界を設計する問題。 - [[ホストネットワークスタック性能]] — 接続局所性を含むホスト側の性能ボトルネック。 - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] — TCPの輻輳制御・RPCトランスポート設計を歴史的視点で論じる関連ソース(接続局所性そのものは直接扱わない)。 ## 出典 - [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]] - [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]] - [[@2024__SIGCOMM CCR__iip - An Integratable TCP IP Stack]] - [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]] - [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]