会话同步是数据面做，还是控制面做

这是一个非常深刻且关键的问题，涉及到 网络系统架构中控制平面（Control Plane）与数据平面（Data Plane）的职责划分，尤其是在负载均衡、防火墙、NAT、安全网关等高性能系统中。

我们以 DPVS、LVS、F5、防火墙、Nginx 等系统为例，来详细分析"会话（Session）"的本质和同步机制。

✅ 一、会话（Session）是数据面对象，还是控制面对象？

🔹 结论：会话本质上是数据平面（Data Plane）对象，但由控制平面管理生命周期。

更准确地说：

会话是数据平面在转发过程中动态创建的"运行时状态（runtime state）"，但它受控制平面策略驱动。

🔹 为什么说是数据平面对象？

原因	说明
✅ 创建时机	在数据包到达时，由数据平面（如 DPVS worker 线程、Nginx worker）创建
✅ 访问频率	每个后续数据包都要查会话表（每秒百万次），必须在数据平面本地内存中
✅ 性能要求	查表延迟必须在微秒级，不能跨进程/跨节点查询
✅ 位置	存在于数据平面的哈希表中（如 `rte_hash`、`nf_conntrack`）
✅ 作用	实现连接保持（如 LVS 的 persistence）、NAT 映射、连接跟踪、负载均衡一致性

arduino 复制代码

c
深色版本
// 典型数据平面会话结构（DPVS 中）
struct dpvs_conn {
    struct dpvs_conn_key key;     // 五元组：sip, sport, dip, dport, proto
    struct dpvs_real_server *dest; // 转发目标
    time_t expire;                // 超时时间
    int state;                    // 连接状态
};

📌 它是数据平面转发决策的依据，属于"运行时状态"。

🔹 为什么说受控制平面影响？

原因	说明
✅ 创建策略	是否开启会话保持（persistence）、超时时间、hash 方法，由控制平面配置
✅ 销毁触发	控制平面可下发命令清除所有会话（如 `ipvsadm -C`）
✅ 同步机制	控制平面可能协调会话同步（如主备节点间）

📌 控制平面决定"要不要会话、怎么管理会话"，但不直接持有会话。

✅ 二、会话同步：是数据面做，还是控制面做？

🔹 结论：会话同步通常由控制平面发起或协调，但同步动作可能由数据面或专用通道完成。

取决于系统架构，主要有以下几种模式：

🔹 模式 1：控制平面驱动同步（推荐）

典型系统：F5 BIG-IP、Citrix ADC、高端防火墙

数据平面创建会话时，通知控制平面
控制平面通过 集群通信通道（如 CMP、gRPC、自定义协议）将会话同步到其他节点
接收节点的控制平面将会话注入本地数据平面

css 复制代码

text
深色版本
Node A (Active)
  |
  | 数据平面创建会话
  ↓
控制平面 A → 网络 → 控制平面 B
                    ↓
              数据平面 B 创建相同会话

✅ 优点：解耦清晰，可审计，支持复杂策略

🔹 用于：高可用（HA）、集群模式

🔹 模式 2：数据平面直接同步（高性能）

典型系统：DPVS、Linux LVS with `conn_sync`

数据平面使用 专用网卡或 multicast 直接发送会话更新消息
使用 CT_MSG 消息格式广播会话创建/删除
其他节点的数据平面直接接收并插入本地会话表

arduino 复制代码

c
深色版本
// DPVS 中的 conn_sync 模块
conn_sync_send(struct dpvs_conn *conn, bool is_add);

css 复制代码

text
深色版本
数据平面 A → (multicast) → 数据平面 B/C/D

✅ 优点：延迟低，不经过控制平面

⚠️ 缺点：耦合紧，调试难，扩展性差

🔹 模式 3：无状态 + 一致性哈希（现代云架构）

典型系统：Envoy、Nginx Plus、ALB

不共享会话状态
使用 一致性哈希（ketama） 确保同一连接总是落到同一后端
即使节点故障，通过快速重连恢复

✅ 优点：无需同步，水平扩展好

🔹 用于：微服务、云原生

✅ 三、典型系统对比

系统	会话位置	会话同步方式
DPVS	数据平面（rte_hash）	数据平面 `conn_sync`（multicast）
Linux LVS	内核 `ip_vs_conn`	`conntrackd` + `CT` 协议（控制平面）
F5 BIG-IP	TMM（数据平面）	控制平面通过 `config sync` 和 `session sync`
Nginx	worker 进程内存	❌ 默认不共享（需 sticky + external store）
Nginx Plus	共享内存 + 控制平面	`zone` + `session_sync` 指令
iptables/nftables	`nf_conntrack`（内核）	`conntrackd` 同步（用户态控制平面）
Cloud Load Balancer	无状态	一致性哈希 or 外部存储（如 Redis）

✅ 四、会话同步的关键挑战

挑战	说明
⚠️ 同步延迟	主节点创建会话，备节点未同步，故障切换时连接中断
⚠️ 状态一致性	网络分区时可能出现"脑裂"
⚠️ 性能开销	每个新连接都要同步，可能成为瓶颈
⚠️ 内存占用	所有节点都存储全量会话，内存翻倍
⚠️ 故障恢复	同步链路中断时，如何降级

✅ 五、总结

问题	答案
会话是数据面对象还是控制面对象？	✅ 数据平面对象（运行时状态），但受控制平面策略控制
会话在哪里创建？	数据平面收到第一个包时创建
会话存在哪里？	数据平面的哈希表中（如 `rte_hash`、`nf_conntrack`）
会话同步是谁做的？	可能是： • 控制平面驱动（推荐，解耦好） • 数据平面直连同步（高性能） • 不同步（无状态架构）
为什么不能只靠控制平面查会话？	❌ 延迟太高（>1ms），无法满足数据平面微秒级查表需求

🎯 最佳实践建议：

会话是数据平面的核心运行时状态，必须本地化、高性能访问
会话同步应由控制平面协调，保证一致性与可管理性
高性能场景可考虑数据平面直连同步（如 DPVS）
云原生系统优先考虑无状态 + 一致性哈希
避免"控制平面查会话"用于转发决策（性能灾难）

🔹 记住：数据平面负责"快"，控制平面负责"稳"和"管" 。会话是"快"的一部分，同步是"稳"的保障。