T-Box双SIM卡的"幻觉"：为什么有两张卡却还在断连？

高速公路的监控大屏上，一排绿色图标中间忽然跳出一个红色感叹号——某辆测试车的控制信号中断了。工程师小李盯着大屏，心里默数：一秒、两秒……五秒后，红色图标又变回绿色。他打开日志，发现这已经是今天第七次了，每次持续 2 到 8 秒不等，间隔 3 到 5 分钟，规律得像闹钟。

他拿起对讲机问现场："T-Box 信号怎么样？""两张卡都满格。"前排的测试工程师拿着手机比划，4G 信号和 5G 信号显示都是五格。

这个 bug 卡了两周。每次排查都绕进同一个死循环：车端信号正常、网络层抓包没丢包、重启 T-Box 无效、换路段无效。直到后来用 ip monitor address 盯着网卡 IP 变化，才找到了真正的凶手——不是信号，不是网络，是传输层的一个根本性缺陷。而最终的解法，和所有人最初的直觉完全相反。

---

第一章：双卡的三种典型组合，以及为什么信号格骗了你

1.1 T-Box 双卡的三种常见部署方式

T-Box 上的双 SIM 卡不是简单地插两张卡那么简单，不同的运营商组合决定了完全不同的信号行为。工程上常见三种：

说明：以下提到的"5G"均指5G/4G自适应模组/SIM卡——模组会根据信号强度在 5G NR 和 4G LTE 之间自动切换，上层看到的是一张"5G卡"，但底层随时可能在跑 4G。这个细节在后续 IP 变化分析中至关重要。

组合一：移动5G + 联通5G（最常见）

两张卡来自不同运营商，分别是移动和联通的 5G/4G 自适应模组。这是覆盖互补最好的组合——移动覆盖农村和高速，联通覆盖城区和地铁，两家的 5G 基站建设侧重点不同，双卡叠加后盲区最少。

但"不同运营商"意味着两张卡处于两家完全独立的 CGNAT 网络，每张卡都有自己的 IP 地址，IP 地址空间互不重叠。这是后续一切问题的根源。

组合二：移动5G + 联通4G（准确说：5G卡 + 4G模组）

两张卡的套餐都是 5G 卡，但联通侧的 T-Box 硬件槽位用的是 4G 模组，而不是 5G 模组。4G 模组比 5G 模组便宜约 50%，在硬件 BOM 成本敏感的 T-Box 设计里，这是常见的降本选择。5G 卡插入 4G 模组，只能跑 4G 速率，但覆盖范围和组合一一样好。

这里顺带给出两种制式的性能参考：

制式	空口理论延迟	实测延迟	下行实测带宽
4G LTE	~30-50ms	40-80ms	10-50Mbps
5G NR	~1-10ms	10-30ms	20-100Mbps

注意：5G 的实测带宽上限（100Mbps）并没有宣传的那么夸张，在城区密集覆盖区才能跑到高值，高速公路上通常在 30-60Mbps 区间。对控制信号（<50Kbps）来说，两种制式的带宽都绰绰有余，真正的差异在延迟。

组合三：移动4G + 联通4G

两个槽位都用 4G 模组，成本最低。信号行为最稳定，但峰值带宽和延迟都受限于 4G。

---

重要说明：三种组合的业务场景完全相同。 这不是"不同场景选不同方案"——而是业界不同厂商根据成本和硬件供应链做出的不同选型，最终跑在车上的业务都一样：云控指令、OTA 升级、诊断数据、日志上报，一个都不少。本文后续分析的断连问题，三种组合都会遇到，只是组合一的 5G 路径延迟更低、信号降级概率略有差异。

三种组合的共同点：两张卡属于不同运营商，IP 地址可能在你没有察觉的情况下悄悄变化。

---

实测关键发现（深圳，5G/4G自适应模组）

这里有一个被大多数文章忽略的细节，直接影响断连根因分析。

在深圳的实测结果：

• 4G → 5G 升级：模组内网口 IP 不变，TCP 连接通常能保持
• 5G → 4G 降级：模组内网口 IP 会变，TCP 连接必然断开

两个关键数字：5G 降级到 4G 的概率并不高，在深圳这种 5G 覆盖较好的城市，实测约在 1% 以下。但一旦发生，断连率是 100%——没有例外。

这个组合意味着什么？绝大多数时候，车辆稳定跑在 5G 上，一切正常。但每次进入 5G 覆盖空洞（隧道口、高架桥下、地下道附近），降级发生，IP 变化，连接断。工程师小李遇到的"每隔 3-5 分钟断一次"，正好对应测试路段上几个固定的 5G 弱覆盖点——不是随机的基站切换，是可预测的地理位置触发的降级事件。

换句话说：断连不是随机的，是确定性的。 只要路线固定，断连点也固定。这个特征让问题看起来"规律得像闹钟"。

这个发现改变了排查方向：与其监控基站切换事件，不如直接监控模组内网口 IP 变化：

# 监控模组内网口 IP 变化（rmnet0 是移动模组网卡，rmnet1 是联通模组网卡）
ip monitor address | grep -E 'rmnet[01]'
# 看到 IP 变化的时间戳，和控制信号断连日志对比，几乎一一对应

1.2 信号格是"路"，TCP 连接是"车牌号"

要理解为什么信号满格但连接断，需要先把两个概念分开。

信号格衡量的是无线电信号强度，告诉你"这里有没有路"。四格信号意味着手机和基站之间有良好的无线链路，数据包可以在空气中传输。

TCP 连接是完全不同的东西。一个 TCP 连接由五个字段标识：源 IP、源端口、目标 IP、目标端口、协议。这就是所谓的"五元组"。服务端用五元组来区分不同客户端的连接，就像快递公司用"寄件地址+收件地址+单号"来追踪包裹。

现在问题清楚了。当 T-Box 从基站 A 切换到基站 B，运营商 CGNAT 重新分配了一个新的公网 IP，比如从 121.4.0.1 变成了 221.7.0.2。信号依然满格——路还在。但 TCP 连接的源 IP 变了，五元组不再匹配了——旧的"车牌号"在新路上不认。

服务端还在等来自 121.4.0.1:45678 的数据，T-Box 却在用 221.7.0.2:45678 发包。服务端把这些包当成陌生连接，不理。T-Box 也不知道 IP 变了，还在用老连接发心跳，收不到 ACK。双方陷入沉默，直到 keepalive 超时，才触发重连。

这个过程就像你开车换了号牌，收费站系统还在等旧号牌过闸，两边都在原地等。

用命令眼见为实：

# 在 T-Box 上实时观察 IP 地址变化（rmnet0 是 4G 模组网卡，rmnet1 是 5G 模组网卡）
ip monitor address

# 同时在另一个终端观察已建立的 TCP 连接
watch -n 1 'ss -tn state established'

# 可以看到：ip monitor 显示 IP 变化的那一刻，ss 里的连接还在，但几十秒后会消失

---

第二章：传输层切换机制的根本缺陷

2.1 TCP 五元组失效的完整时序

4G/5G 公网环境下，IP 变化的概率有多高？这里要区分两个维度：

维度一：降级事件本身发生的频率

• 在深圳这种 5G 覆盖较好的城市，5G 降级到 4G 的概率约 1% 以下（按时间占比）

维度二：降级发生后 IP 变化的概率

• 4G → 5G 升级：模组内网口 IP 基本不变，IP 变化概率 <10%，TCP 连接通常能保持
• 5G → 4G 降级：模组内网口 IP 大概率变化，IP 变化概率 60%-80%，TCP 连接必然失效

把两个维度合起来：日常行驶中 99% 的时间一切正常，但每次进入 5G 弱覆盖区发生降级，断连概率高达 60-80%。断连不频繁，但一旦发生就是确定性的，而且发生在固定的地理位置——这就是为什么问题"规律得像闹钟"。

失效之后发生什么？这里有一个被很多工程师忽视的延迟链：

IP 变化（t=0）
  ↓
T-Box 继续用旧连接发包（服务端不响应）
  ↓
应用层心跳超时（默认 30-60s，t=30s 到 60s）
  ↓
应用层触发重连
  ↓
TCP 三次握手（1 RTT ≈ 100ms）
  ↓
TLS 握手（1-2 RTT ≈ 200-400ms，取决于会话复用）
  ↓
应用层重新建立上下文（认证、状态同步）
  ↓
控制信号恢复发送（t = 30s 到 90s 后）

这就是为什么断连会持续 30 秒甚至更长。IP 变化这件事本身只有几百毫秒，但上层感知到这件事，需要等 keepalive 或者心跳超时。

有些团队把心跳间隔调到 5 秒，断连感知时间降到了 5 秒，但仍然不够。控制信号的 SLA 要求端到端 <200ms，感知延迟 5 秒是不可接受的。

2.2 现有方案为什么都不够好

面对这个问题，工程上通常会先试几个"直觉上合理"的方案。以下是真实踩过的坑：

方案	工作原理	表面上看	实际缺陷
双卡冷备份	主卡断了切备卡，换 default route	有备用路径	切换感知 2-8s，期间控制信号中断；还要处理路由切换带来的连接重建
应用层心跳	每 5s 发一个 ping，超时触发重连	简单可靠	只能感知断连，不能预防；最差 5s 感知 + 重连时间，共 6-7s
MPTCP 内核多路径	内核维护多条子流，路径失效自动切换	内核原生支持，零改造	移动公网 APN 中间设备剥离 TCP Options，MP_CAPABLE 握手失败；公网 APN 上成功率难以保证，工程上不可依赖。 云端需要改造支持对应的mptcp协议。
SO_KEEPALIVE	内核级 TCP 保活	比应用层心跳更底层	Linux 默认 keepalive_time = 7200s；调小也只是感知快一些，IP 变化后 keepalive 包也是无效的

MPTCP 这条路是最反直觉的坑。工程师通常会这样想：MPTCP 是内核原生的多路径传输，应该最可靠——为什么在 4G 公网不好用？

原因很简单：MPTCP 的多路径协商依赖 TCP Options 字段（MP_CAPABLE、MP_JOIN 等扩展头），而移动运营商公网 APN 上的 NAT 和 DPI 设备，对不认识的 TCP Options 直接清零。握手包发出去，Options 被剥掉，服务端收到的是普通 TCP 连接，MPTCP 特性根本不生效。

这是一个很重要的结论，我们后面还会展开：MPTCP 是内核态协议，反而比用户态 QUIC 更难部署在 4G 公网。

2.3 应用层重连风暴：一个被忽视的放大效应

上面讨论的是单个连接的断连问题。真实场景更糟糕：T-Box 上同时跑着多个服务——云控指令通道、OTA 升级通道、诊断数据上报、日志采集。IP 变化的那一刻，这些连接全部同时失效。

然后，每个服务各自感知到断连，各自触发重连，同时发出 TCP SYN 包。服务端在同一秒内收到来自同一个 T-Box 的四五个 SYN 包，每个包还要做 TLS 握手、身份认证、状态同步。这个瞬间的请求峰值可以比正常流量高出 10 倍以上。

如果车队有 100 辆测试车同时过了一个基站切换点，服务端的 SYN 风暴会更严重。这是一个被很多团队忽视的级联故障风险。

# 在 T-Box 上抓 SYN 包，观察重连风暴
tcpdump -i rmnet0 'tcp[tcpflags] & tcp-syn != 0' -n -l | \
  awk '{print $1}' | cut -d. -f1 | uniq -c
# 输出格式：每秒的 SYN 包数量
# 正常：每秒 0-1 个
# 重连风暴：每秒 5-10 个

# 同时抓所有网卡，观察是否同时触发
tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0' -n 2>/dev/null | head -50

---

第三章：QUIC 为什么天然适合这个场景

3.1 Connection ID：把连接从四元组里解放出来

QUIC 解决 IP 变化问题的方式从根本上不同于 TCP。

TCP 连接的标识是五元组，这是写死在协议设计里的。IP 地址不仅是路由地址，还是连接标识的一部分——这在 1981 年 TCP 诞生的时候是合理的，那时候 IP 地址不会变。但移动互联网时代，IP 地址随时会变。

QUIC 引入了 Connection ID（CID）。CID 是一个独立于 IP 地址和端口之外的连接标识符，由双方协商生成，嵌在 QUIC 包头里。服务端用 CID 来识别连接，不用 IP 地址。

用类比来说：TCP 连接像"车牌号+车道"绑定的通行证，换了车道（IP 变了）通行证就作废了。QUIC 的 CID 像"车辆识别码（VIN 码）"，换了车道甚至换了城市，服务端还认得出这辆车。

IP 变化时发生什么：

T-Box IP: 121.4.0.1 → 221.7.0.2（IP 变化）
  ↓
T-Box 继续用相同的 CID 发 QUIC 包
  ↓
服务端收到来自新 IP 的包，但 CID 一致
  ↓
服务端触发连接迁移（Connection Migration）流程
  ↓
Path Validation：双方确认新路径可用
  ↓
连接无缝继续（总耗时通常 <100ms，IP 切换感知可以做到 <50ms）

这个过程对应用层完全透明，控制信号无需中断。

# 验证 QUIC 连接迁移：用 Wireshark/tcpdump 观察 IP 变化前后的 Connection ID
# QUIC 包都是加密的，但可以从 packet number 的连续性判断连接是否迁移成功
tcpdump -i rmnet0 'udp port 443' -n -v 2>/dev/null | grep "length"
# 连接迁移前后，包长度分布应保持一致（没有握手包的大包突现）

3.2 MPTCP 在 4G 公网为什么更难部署

现在可以展开解释这个反直觉的结论。

MPTCP 协议的多路径特性，依赖 TCP 头部的 Options 字段来传递协商信息。具体地说，MPTCP 的 MP_CAPABLE 选项在三次握手时携带 Key，用来建立多路径连接。这个过程完全在内核协议栈内完成，不需要应用层感知。

问题在于，移动运营商公网 APN 网络里有大量中间设备——NAT 网关、DPI（深度包检测）、负载均衡器——这些设备对不认识的 TCP Options 处理方式因厂商而异：有的透传、有的清零、有的报错。

移动公网 APN 的工程实践情况：

• 移动 CMNET（公网 APN）：CGNAT 设备对未知 TCP Options 处理激进，MP_CAPABLE 在多数省份被剥离，工程上不能依赖 MPTCP 建连
• 联通 3gnet/uninet（公网 APN）：部分省份中间设备相对宽松，但同样无法保证稳定透传
• 运营商专线 APN（车载专用）：不经过公网 CGNAT，中间设备干扰极少，MPTCP 可用性高

这里没有精确的运营商级统计数字——目前没有公开的学术论文专门测量中国各运营商 APN 对 MPTCP 的干扰率。全球范围内最权威的测量（Honda et al., IMC 2011）显示约 29% 的互联网路径会修改 TCP Options，而移动运营商公网 APN 的中间设备密度更高，工程经验判断干扰率远高于这个全球均值。

T-Box 通常用公网 APN，成本考虑——专线 APN 每月费用是公网 APN 的 10 倍以上。在公网 APN 上，MPTCP 能否生效是运气问题，工程上不可依赖。

更讽刺的是：MPTCP 是操作系统内核级别的协议，需要双端内核都支持（Linux 5.6+ 合入主线），对应用层完全透明。但恰恰是因为它在内核里、在 TCP 层，它的扩展信息暴露在中间设备面前，被随意处置。

QUIC 的情况完全不同。QUIC 头部是加密的。 QUIC 使用 AEAD 加密，包头（包括任何扩展信息）对中间设备不透明，中间设备只能看到 UDP 包，看不到里面是什么。MPQUIC（QUIC 的多路径扩展）的协商信息同样受到加密保护，运营商 DPI 无法识别也无法剥离。

这就是 QUIC 相对于 MPTCP 的关键部署优势——不是因为协议设计更好，而是因为在运营商网络里活得更好。

# 验证 T-Box 的 4G 网络是否剥离 TCP Options
# 抓 TCP SYN 包，检查 Options 字段
tcpdump -i rmnet0 -v 'tcp[tcpflags] & tcp-syn != 0' 2>/dev/null | \
  grep -A 2 "options"
# 如果 MPTCP 生效：会看到 "mptcp unknown-76" 或 "MP_CAPABLE" 之类的 options
# 如果被剥离：只会看到标准的 MSS/WScale/SACK/Timestamp options

# 对比：QUIC 包对中间设备完全不透明
tcpdump -i rmnet0 'udp port 443' -n -v 2>/dev/null | head -20
# 只能看到 UDP 头部信息，内容全是加密数据

3.3 QUIC 的另一个优势：更快的握手

顺带提一下，QUIC 的握手效率本身也比 TCP+TLS 快。

TCP 连接需要 1 RTT 三次握手，然后 TLS 1.3 需要 1 RTT，合计 2 RTT 才能发送第一个应用数据包。如果 RTT 是 100ms，重连代价就是 200ms——已经超过了控制信号的 SLA 边界。

QUIC 的 1-RTT 握手把 QUIC 层和 TLS 层合并，首次连接 1 RTT 就能发应用数据。更重要的是，QUIC 支持 0-RTT 会话恢复——如果 T-Box 之前连接过同一台服务器，可以直接把第一个请求附在握手包里，握手延迟降到接近 0。

控制信号重连场景（IP 变化后触发）用 0-RTT 恢复，重连耗时约 10-30ms，比 TCP+TLS 的 200-600ms 快一个数量级。

---

第四章：不做切换，做冗余——架构决策的推导

4.1 切换思维 vs 冗余思维

到这里，工程师通常会问：既然 QUIC 支持连接迁移，IP 变化时自动迁移到新路径，问题不就解决了吗？

还不够。连接迁移是"被动的"——必须等到 IP 变化、新路径建立、Path Validation 完成之后才能恢复。这个过程虽然比 TCP 重连快很多，但在迁移完成之前，还是有一段窗口期会丢包或者延迟上升。

真正的解决思路，是把问题从"如何快速切换"变成"如何不需要切换"。

切换思维的逻辑链是：

主路径失效 → 检测到失效（有延迟）→ 切换到备路径（有耗时）→ 恢复

中间总有一段不可压缩的感知+切换窗口。

冗余思维的逻辑链是：

两条路径同时发送 → 云端取先到者 → 任一路径失效 → 另一条已经到了

没有感知窗口，没有切换耗时，从应用层看从未中断。

这个转变的关键洞察是：对于控制信号，带宽不是瓶颈，延迟确定性才是。

控制信号的典型数据量：每秒 10-50 条指令，每条 <1KB，总带宽 <50Kbps。双发之后翻倍到 100Kbps。4G 网络带宽是 10-50Mbps，弱网环境下实际可用带宽在 2-10Mbps——100Kbps 只占 1%-5%，完全可以接受。

4.2 冗余发送的工作原理与量化收益

冗余发送（Redundant Scheduling）的架构如下：

T-Box
  ├── SIM1 (移动 5G/4G自适应) → QUIC MPQUIC 路径 A ──┐
  └── SIM2 (联通 5G/4G自适应) → QUIC MPQUIC 路径 B ──┤→ 云控网关去重 → 应用层
                                                      └── 丢弃重复包（按 QUIC Packet Number 去重）

T-Box 端，QUIC 库的 MPQUIC 冗余模式会把每个 QUIC 包同时在两条路径上发送，两份包携带相同的内容和相同的 Packet Number。

云控网关收到两份包后，用 Packet Number 做去重——先到的处理，后到的丢弃。这个去重窗口一般设为 200ms（具体推导见第 02 篇《云控 SLA 的数学》）。

延迟收益的计算很直接：

单路径方案：延迟 = 路径 A 的延迟（唯一路径）
冗余发送方案：延迟 = min(路径 A 延迟, 路径 B 延迟)

假设路径 A RTT 均值 80ms，路径 B RTT 均值 120ms，各自 P99 150ms 和 200ms：

• 单路径 P99：150ms（走路径 A）
• 冗余发送 P99：约 90-100ms（哪条快用哪条）

更重要的是尾延迟和断连概率。当路径 A 在基站切换时出现 2-8 秒断连，冗余发送方案中路径 B 还在正常工作，控制信号从未中断。这才是真正解决了开头的问题。

4.3 为什么需要专门的 QUIC 库支持冗余发送

实现 MPQUIC 冗余发送，需要一个支持 MPQUIC 的 QUIC 库。

市场上主流的 QUIC 实现大多还不支持 MPQUIC，或者支持程度不够——MPQUIC 至今没有正式 RFC，只有草案（draft-ietf-quic-multipath），各库的实现进度不一。选型时需要重点考察：MPQUIC 草案支持程度、ARM 交叉编译可行性、C/C++ 集成接口是否完整。

选型细节（各库的功能对比、T-Box ARM 编译踩坑）见本系列第 04 篇。

4.4 冗余发送的适用边界——它不是万能的

诚实地说，冗余发送不是所有场景的正确答案。

适合用冗余发送的场景：

• 控制信号：小包（<1KB）、低频（10-50次/秒）、高可靠要求、延迟 <200ms SLA
• 关键状态同步：心跳、位置上报

不适合用冗余发送的场景：

• 视频回传：每秒几十 MB，双发会直接把 4G 带宽打满，这是不可接受的。视频走独立通道（见第 03 篇《为什么控制信号和视频走不同的传输通道》）
• OTA 升级：文件大，双发带宽代价高，而且 OTA 不要求低延迟，断点续传就够用
• 日志上报：大量数据，对延迟不敏感

两路都断的情况：

进隧道、地下停车场、或者两家运营商同时网络故障时，两条路径都断了，冗余发送也没用。这时需要降级策略——本地缓存指令、切换到 WiFi 或短距离通信。这个场景在第 12 篇专门讨论。

# 在 T-Box 上验证双路径是否同时在发包
# 方法：同时抓两个网卡，看是否有相同内容的 UDP 包

# 终端 1：抓 SIM1（4G）的 QUIC 包
tcpdump -i rmnet0 'udp port 443' -n -l -w /tmp/cap_rmnet0.pcap &
PID1=$!

# 终端 2：抓 SIM2（5G）的 QUIC 包
tcpdump -i rmnet1 'udp port 443' -n -l -w /tmp/cap_rmnet1.pcap &
PID2=$!

# 等 30 秒
sleep 30
kill $PID1 $PID2

# 对比两个抓包文件的包大小分布
# 如果冗余发送生效：两个文件的包大小分布应高度相似
tcpdump -r /tmp/cap_rmnet0.pcap -n | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10
tcpdump -r /tmp/cap_rmnet1.pcap -n | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

---

第五章：把所有方案放在一起比较

经过前面四章的分析，我们可以给出一张完整的方案对比表。

方案	切换感知时间	部署难度	运营商兼容性	带宽代价	适合云控？
双卡冷备份	2-8 秒	低（路由脚本）	好	无额外	❌ 感知太慢
应用层心跳 + 重连	5-30 秒	低（应用改造）	好	无额外	❌ 感知太慢
TCP + SO_KEEPALIVE	10-120 秒	低（sysctl）	好	无额外	❌ 更慢
MPTCP 内核多路径	<500ms（理论）	高（内核版本+双端支持）	差（公网 APN 不可依赖）	无额外	❌ 运营商兼容性差
QUIC 连接迁移	<100ms	中（QUIC 库集成）	好（UDP 加密）	无额外	勉强可用
QUIC MPQUIC 冗余发送	0ms（无感知）	中（QUIC 库 + 服务端去重）	好（UDP 加密）	2x 控制信号带宽	✅

"感知时间 0ms"不是夸张，是架构上的精确描述：冗余发送不需要感知路径失效，因为另一条路径已经先到了。

---

结尾

回到高速公路上的那个场景。测试车的控制信号为什么每隔 3-5 分钟断一次？因为高速公路上每隔几公里就有一次基站切换，切换时 CGNAT 重新分配 IP，TCP 五元组失效，应用层要等 30 秒才感知到，然后再花 500ms 重连。信号格一直是五格，但 TCP 连接已经死了。

最终的解法，是把 T-Box 上的云控指令通道换成 QUIC MPQUIC 冗余发送模式——4G 和 5G 双路同时发，云端网关去重取先到者。某条路径切换的那段时间，另一条路径的包已经到了，控制信号从未中断。

这个解法改变了问题的思路框架：不是"切换多快"，而是"需不需要切换"。

但这只是解决了"控制信号会不会断"的问题。下一个问题是：就算连接不断，200ms 的端到端 SLA 传输层能保证吗？实际上，传输层在延迟预算里能用的空间可能只有 20-60ms——因为 qdisc 队列和进程调度才是真正的大头。这个延迟分解，见下一篇：《云控 SLA 的数学：200ms 端到端延迟预算怎么分配给传输层？》。

如果你也遇到过类似的断连问题，欢迎在留言区分享你们的排查思路——是什么帮你找到了根因？