腾讯云聚通 Linux SDK 部署形态说明
下载
聚焦模式
字号
适用产品：多网聚合加速（腾讯云聚通）Linux SDK。
适用场景：L4 智能驾驶、Robotaxi、具身智能机器人等需要多蜂窝链路聚合的车载 / 机器人平台。
背景
云聚通 Linux SDK 以托管进程形式运行，安装后在本机 127.0.0.1:9801 提供 HTTP API，业务侧通过 API 下发配置并启停加速（安装与调用流程见快速接入）。SDK 的核心配置项之一是 interfaces ——参与多网聚合的接口列表。在车载与具身智能场景中，蜂窝链路（SIM 卡）与运行 SDK 的算力单元往往不在同一块板子上：SIM 卡在 T-Box，算力在域控制器。
因此在集成开始之前，必须先回答两个问题：
1. SDK 装在哪个 OS 上？（T-Box 的 OS，还是域控制器的 OS）
2. interfaces 里填什么接口名？（物理蜂窝网卡，还是 VLAN 子接口）
判断方法
SDK 的多链路能力建立在一个前提上：在 SDK 运行的这个 Linux OS 里，每一条待聚合链路都表现为一个独立的网络接口，且该接口持有独立 IP 与独立下一跳网关。
这个前提来自 SDK 的策略路由机制。SDK 内置的策略路由管理模块是基于 WAN 接口源 IP 的——它让指定源 IP 的数据包从该源 IP 对应的接口发出。若没有这样的策略路由，所有包会统一走默认路由，SDK 就无法从多张网卡收发报文。
# ip rule79: from 198.18.0.1 lookup 180 # SDK 虚拟网卡 mp_tun079: from all fwmark 0x1/0xf lookup 180 # 被引流的业务流量80: from 192.168.81.80 lookup 100 # 链路一源 IP81: from 10.221.7.233 lookup 101 # 链路二源 IP# ip route ls table 100default via 192.168.81.1 dev ath0# ip route ls table 101default via 10.21.5.17 dev rmnet_mhi0.1
注意：
第二条链路的接口名 rmnet_mhi0.1 本身就是一个子接口。这说明 SDK 对接口的要求是逻辑层面的——只要有独立 IP 与独立下一跳网关，物理口与 VLAN 子接口对 SDK 是等价的。
由此得到形态选择的判据：
所有待聚合链路在同一个 OS 内已是独立网卡 → 选形态一：SDK 就装在这个 OS 上。
待聚合链路分散在多个硬件单元上，任一单元都看不全 → 选形态二：聚合点上移到域控制器，把链路映射进来。
两种标准形态
形态一：T-Box 内集成（链路本地可见）
1. 适用条件
T-Box 自身即为双链路载体，两条链路在 T-Box 的 OS 内已经是两张独立网卡：
DSDA（Dual SIM Dual Active，双卡双通）：两张 SIM 可同时在线并各自建立数据连接
双模组：T-Box 内置两个独立蜂窝模组
蜂窝 + 其他链路：如 5G + Wi-Fi、5G + 卫星
2. 配置方式
curl -X POST 'http://127.0.0.1:9801/api/v2/client/mp-speeder' \\-H 'Content-Type: application/json' \\-d '{"dataKey": "<从腾讯云控制台获取的设备密钥>","interfaces": ["rmnet_mhi0", "rmnet_mhi1"],"scheduleMode": "bonding"}'
接口名以设备实际情况为准（常见形态：rmnet_、usb0/usb1、wwan0/wwan1、eth）。可通过 ip addr 确认。
3. 优势与代价
优势：链路路径最短，无需跨硬件单元的网络配置；业务侧（域控 / 车机）无需任何改造，SDK 在 T-Box 内以引流规则接管流量即可。
代价：SDK 与 T-Box 型号绑定。每更换一次 T-Box 供应商或型号，集成、验证、固化都要重做一轮。若项目存在多个 T-Box 供应商或后续有换型计划，这部分成本会重复发生。
形态二：域控制器集成 + 链路映射（链路远端可见）
1. 适用条件
出现以下任一情况时，聚合点必须上移到域控制器：
存在两个及以上 T-Box，每个各带一张 SIM：任一 T-Box 都只看得到自己那一条链路，无法在 T-Box 内完成聚合。
T-Box 供应商 / 型号不固定：把 SDK 收敛到域控，供应商切换时端侧集成方案不必重做。
T-Box 算力或系统权限不足：无法满足 SDK 的算力、内核、TUN、iptables、持久化等要求。
形态二的一个重要价值在于：同一套端侧集成方案可以覆盖不同的链路承载拓扑。常见的两种变体:
1 × T-Box，双模组 / DSDA 双卡双通：两条链路来自同一个通信单元。
2 × T-Box，每个各 1 张 SIM：两条链路来自两个独立通信单元。
对 SDK 而言完全等价。只要每条链路都能映射为域控制器 OS 内的独立接口（持有独立 IP 与独立下一跳网关），SDK 侧的集成方式与 interfaces 配置就不需要任何改动。SDK 只认接口，不关心链路来自几个物理通信单元。对于需要在多种硬件配置间保持方案一致的项目，这可以显著降低适配与维护成本。
2. 链路映射方式
需要把 T-Box 上的蜂窝链路映射成域控制器 OS 内的独立接口。有两种做法：
VLAN 子接口（推荐）：适用于车载以太网为共享链路，或需经区域控制器 / 中央网关中转；interfaces 填子接口名，如 ["eth0.75", "eth0.76"]
独立物理网口：适用于域控有足够空闲网口，可与各 T-Box 点对点直连；interfaces 填物理口名，如 ["eth1", "eth2"]
VLAN 方式解决的是"一根物理以太网上承载多条逻辑链路"的问题——车载以太网通常经区域控制器（ZCU）/ 中央网关汇聚，域控到 T-Box 之间不存在多根独立的专用物理线。VLAN 是手段，不是目的；若物理网口充裕，直接用物理口同样可行，对 SDK 完全等价。
3. 配置方式
SDK 装在域控制器上，业务进程在同一台域控内通过 127.0.0.1:9801 调用 SDK。interfaces 填 VLAN 子接口名：
curl -X POST 'http://127.0.0.1:9801/api/v2/client/mp-speeder' \\-H 'Content-Type: application/json' \\-d '{"dataKey": "<从腾讯云控制台获取的设备密钥>","interfaces": ["eth0.75", "eth0.76"],"scheduleMode": "bonding"}'
4. 落地前提清单
形态二涉及跨硬件单元的网络配置，通常由域控底软供应商落地。开工前请逐项确认：
1. T-Box 侧将各自蜂窝链路映射为不同 VLAN ID（验证：T-Box 侧配置确认）。
2. 车载以太网各跳（域控 ↔ ZCU ↔ T-Box）VLAN Trunk 透传打通（验证：端到端连通性测试）。
3. 每个 VLAN 子接口在域控 OS 中拥有独立 IP（验证：ip addr show eth0.75 有地址）。
4. 每个 VLAN 子接口拥有独立下一跳网关且可被感知（验证：ip route 可见对应 default 路由）。
5. 域控 OS 支持多条 default 路由，可按 metric 优选或支持 ECMP（验证：路由表检查）。
6. 域控满足 SDK 硬件与软件要求（验证可参见 硬件适配要求）。
第 3、4 项是最关键的两条。SDK 的策略路由建立在"接口源 IP + 下一跳网关"之上，任一项缺失，该链路都无法参与聚合。需特别注意：SDK 管理策略路由的前提是多条线路的对应网关要能被感知到。
若域控 OS 的路由由客户统一管理、不希望 SDK 介入，可关闭 SDK 内置策略路由模块，由底软自行实现上述策略路由——此时必须确保引流的策略路由优先级高于系统其他路由。开关方式见 API 概览 > SDK 内置策略路由管理。
5. 域控侧环境要求摘要
内核：≥ 4.4，且固件编译时必须打开 TUN 模块。
iptables：必须支持，否则无法引流。
策略路由：系统必须支持；必须支持多条 default 路由。
CPU：需支持 AES 指令加速；MIPS 架构无法运行；Cortex-A72/A53/A7 性能偏弱。
内存：建议预留 > 100MB（最小 50MB）。
存储：建议预留 > 200MB。
持久化：/usr/local/etc/mp-speeder（配置）与 /var/log（日志）需为非易失，固件升级或重启后内容保持不变。
进程管理：支持 systemd / procd / rc.local 之一，或由厂商自行编写启动脚本。
两种形态对比
维度 | 形态一：T-Box 内集成 | 形态二：域控制器集成 |
SDK 运行位置 | T-Box OS | 域控制器 Linux SOC |
interfaces 填写 | 物理蜂窝网卡，如 ["rmnet_mhi0","rmnet_mhi1"] | VLAN 子接口，如 ["eth0.75","eth0.76"] |
硬件前提 | T-Box 为 DSDA / 双模组，且算力权限满足 | 域控算力权限满足；车载以太网支持 VLAN Trunk |
支持 2 × T-Box | 不支持 | 支持 |
T-Box 换型影响 | 需重新集成验证 | 端侧方案不变 |
网络配置工作量 | 低（链路本地可见） | 中（需跨单元 VLAN 映射与策略路由） |
业务侧改造 | 无（T-Box 作为网关透明接管） | 业务进程需调用本机 SDK API |
主要责任方 | T-Box 供应商 | 域控底软供应商 + 业务方 |
云侧无差异：两种形态在云端完全一致——SDK 均将业务流量封装为 QUIC 隧道送至腾讯云聚合网关，由网关终结隧道并回源。部署形态的差异只在车端，不影响云侧接入方式、计费方式与设备管理方式。
interfaces 字段填写速查
形态一（T-Box 内集成）：填物理蜂窝网卡名，示例：
"interfaces": ["rmnet_mhi0", "rmnet_mhi1"]
形态二（域控制器集成）：填 VLAN 子接口名，示例：
"interfaces": ["eth0.75", "eth0.76"]
两种形态下，接口名均以设备实际情况为准，可通过 ip addr 确认。填写要求只有一条：列表中每个接口都必须持有独立 IP 与独立下一跳网关。
常见误区
误区一：把双卡双待（DSDS）当成双卡双通（DSDA）
这是形态一最容易踩的坑。双卡双待同一时刻只有一张卡在跑数据业务，OS 内只存在一张可用数据网卡，聚合无从谈起。
判断标准不是"设备有两张 SIM 卡"，而是：执行 ip addr，两张蜂窝网卡同时 UP，且各自持有独立 IP——满足这一条才是可聚合的双链路。
误区二：interfaces 填了 VLAN 的物理父接口
形态二下填 ["eth0"] 而不是 ["eth0.75","eth0.76"]，SDK 只会识别到一条链路，多链路策略路由也无法建立，加速退化为单链路。必须填子接口名。
误区三：VLAN 子接口没有独立网关
子接口配了 IP 但没有对应的下一跳网关，或网关不可被 SDK 感知，该链路无法参与聚合。检查方式：
ip route # 每条链路应有对应的 default 路由ip rule # 开启 SDK 策略路由后应出现 from <接口IP> lookup <表ID> 规则
误区四：车端使用全量引流
全量引流会配置在 LAN 口上，要求网卡名中含 lan 字样。车端网卡通常没有 lan 前缀，此时全量引流会回退到查找第一个 bridge 口，行为不可控。
curl -X POST 'http://127.0.0.1:9801/api/v2/route/businessRoute' \\-H 'all: false' -H 'Content-Type: application/json' \\-d '[{"srcIP":"192.168.1.0/24","dstIP":"10.0.0.0/24","protocol":"TCP","dstPorts":"443"}]'
引流是否命中可通过计数器验证：
iptables -t mangle -nvL # 观察对应规则的 pkts/bytes 是否持续增长
误区五：忽略 MTU 与 MSS
VLAN 标签额外占用 4 字节，加速隧道本身也存在封装开销。需要注意：
车载以太网各跳 MTU 保持一致（域控 ↔ ZCU ↔ T-Box），避免中间节点分片
UDP 业务需控制发包大小：建议 IPv4 不超过 1289 字节，IPv6 不超过 1277 字节
UDP 报文分片会导致报文数量翻倍，显著影响端侧与网关侧转发性能，在弱网环境下容易丢包，极端情况可能使多网加速出现负优化。
误区六：改完配置直接调 start
配置变更（更换 dataKey、调整 interfaces、修改引流规则等）后，需调用重启加速接口使新配置生效.
curl -X POST 'http://127.0.0.1:9801/api/v2/client/mp-speeder/restart'
配置会持久化到 /usr/local/etc/mp-speeder/，SDK 重启后自动加载，无需重复配置。
验证加速通道是否可用
SDK 启动后会创建虚拟网卡 mp_tun0，可直接指定该接口验证通道连通性。
curl --interface mp_tun0 https://www.qq.com
正常返回 HTML 即表示加速通道可达。同时应轮询状态接口直到 ready == true:
curl 'http://127.0.0.1:9801/api/v2/client/mp-speeder'
文档反馈