解读

在国内运营商普遍采用“对称型 NAT + 短老化”策略的 4G/5G 网络里，IoT 网关一旦 30~60 秒没有出站流量，公网端口就会被回收，导致云端 CouchDB 无法回连。CouchDB-Lite 的 replicator 虽然默认带心跳，但心跳包发的是 WebSocket Ping，很多运营商对“Ping 帧”不做保活判定，必须让 HTTP 请求体 真正产生出站字节。因此，面试官想确认两点：

1. 你是否知道 CouchDB-Lite 的心跳参数与底层协议细节；
2. 能否在嵌入式 Linux/RTOS 资源受限场景下，把心跳与 TCP Keep-alive、NAT 老化时间三者对齐，做到“30 秒一次真实流量”。

知识点

• CouchDB-Lite replicator 配置键：heartbeat, autoPurge, maxRetries, enableAutoHeartbeat
• 协议分层：HTTP/1.1 chunked → WebSocket → WebSocket Ping；运营商只认 IP 层五元组 的出站字节，不认 Ping 帧
• NAT 老化表：国内移动核心网默认 UDP 30s、TCP 120s，但部分省份 TCP 也缩到 60s
• 心跳对齐公式：heartbeat ≤ (NAT 老化时间 − 10s)，取 30s 是安全值
• 平台差异：Android/iOS 版 CouchDB-Lite 在系统层走 OS WebSocket，而嵌入式 Linux 版用 LiteCore C API，参数名大小写不同
• 省电/省流量：30 秒心跳比默认 60 秒多一倍流量，面试需权衡“保活成本”与“掉线重连成本”

答案

在 IoT 网关侧，用 CouchDB-Lite-C（LiteCore）的 C++ 或 C API 创建 replicator 时，把 “heartbeat” 显式写到 options 字典，并强制走 HTTP/1.1 long poll 而不是 WebSocket，确保每 30 秒产生一次 chunked 响应 的出站 ACK。示例代码（C++）：

C4ReplicatorParameters params = {};
params.heartbeat = 30;  // 单位秒，**必须小写**
params.enableAutoHeartbeat = true;
params.channels = {"device_data"};
params.push = kC4OneShot;
params.pull = kC4Continuous;
c4repl_start(repl, &params);

同时，在 Linux 内核层 把 TCP Keep-alive 提前到 25 秒，防止运营商把 TCP 端口回收：

echo 25 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 3  > /proc/sys/net/ipv4/tcp_keepalive_probes
echo 5  > /proc/sys/net/ipv4/tcp_keepalive_intvl

最后，在 云端 nginx/haproxy 反向代理里关闭 proxy_request_buffering，保证 chunked 响应实时下发，完成 双向 30 秒心跳 穿透。

拓展思考

如果面试官追问“30 秒还是掉线怎么办”，可继续给出 阶梯式心跳 策略：

1. 先降回 25 秒；
2. 再叠加 UDP 打洞通道 做 双通道冗余（CouchDB-Lite 支持自定义消息拦截器，可插 MQTT-over-UDP 保活）；
3. 最后把 replicator 的 maxRetries 设成 无限重连，并在本地 SQLite 缓存失败序列，等网络恢复后 增量回溯，保证 “离线优先” 语义不丢数。