# IM 2000 人群聊 r6 复测分析

日期：2026-09-28

Run ID：`group2k-r6-20260928-01`

## 1. 结论

r6 比 r5 有改善，但仍未通过。A 去掉 Fake-IP 后 ACK 数从 426 增加到 758，统计窗口断线从 657 降到 213；然而 `api.118im.com` 的真实公网 IP 仍经 `utun4`，A 在正式开始前就发生 28 次连接抖动，正式开始后继续成批断线。后续排查确认该 `utun4` 由 OpenVPN Connect 的全局路由持有，而不是 LightXtreme。B 也出现 2 次断线和 1 次发布结果未知，不再是完全零错误。

历史落库仍然可靠：ACK 台账和未 ACK 观测台账合计核验 1870/1870，持久化丢失为 0。FD 修复已验证生效，A 的存活连接从 1000 降至 787 时，open FDs 从约 1013 同步降至约 799，不再滞留断开的 socket。

历史限速和退出行为仍会污染服务端队列指标：历史查询阶段约产生 436 次 Topic 队列满；A 结束时一次性关闭大量群订阅连接，又集中产生约 598 次队列满。

总体结论：**落库正确性通过；FD 修复通过；实时可靠性失败；A 的 OpenVPN/TUN 链路仍未绕过；历史回放与集中断连仍需改进。**

## 2. 汇总结果

| 指标 | A | B | 合计 |
|---|---:|---:|---:|
| READY | 1000 | 1000 | 2000 |
| 发送尝试 | 1000 | 1000 | 2000 |
| ACK | 758 | 999 | 1757 |
| ACK 超时 | 122 | 0 | 122 |
| socket/连接结果未知 | 120 | 1 | 121 |
| 实际明确拒绝 | 0 | 0 | 0 |
| 断线 | 213 | 2 | 215 |
| ACK 台账内应收 | 1757000 | 1757000 | 3514000 |
| ACK 台账内实收 | 1468873 | 1756514 | 3225387 |
| ACK 台账内实时缺失 | 288127 | 486 | 288613 |
| ACK 台账外额外投递 | 94965 | 112984 | 207949 |
| 历史核验 | 1870/1870 | 0/0 | 1870/1870 |
| 未 ACK 观测消息核验 | 113/113 | 0/0 | 113/113 |

服务端实际处理消息至少为 `1757 + 113 = 1870` 条。其余 130 条结果未知没有 ACK 或实时观测证据，不能证明服务端接受。

## 3. 报告口径修正

合并报告当前显示 91 次明确拒绝和 152 次结果未知，这是错误分类：

- A 的 91 次 `use of closed network connection` 被归类为 `other`。
- 该错误是连接关闭后的写失败，应该归类为 `socket` 结果未知。
- 修正后本轮明确拒绝为 0，结果未知为 243。

此外，群历史只由 A 执行。A 已证明全部 1757 条 ACK 消息落库，但 B 的 `realtime_lost_but_persisted` 无法读取 A 的历史结果，因此 B 的 486 次实时缺失没有计入“实时缺失但已落库”。合并报告需要共享全局历史核验结果后再计算该字段。

## 4. A 网络与 FD

本轮 DNS 返回真实地址：

```text
64.118.158.131
216.236.31.189
216.236.31.191
```

但到真实地址的系统路由仍为：

```text
gateway: 172.27.240.1
interface: utun4
```

这说明 Fake-IP 已关闭，但流量仍进入 VPN/TUN。A 在 barrier 提交前持续掉线重连，正式开始后约 50 秒开始掉线，最终只剩约 787 个连接。后续确认 OpenVPN Connect 下发了 `0/1` 和 `128.0/1` 两条全局路由；LightXtreme 的 DIRECT 规则无法绕过另一套 OpenVPN TUN。r7 前已为 `api.118im.com` 当前三个 IP 添加经 `192.168.1.1/en1` 的 `/32` 主机路由，保留 OpenVPN 内网访问的同时让压测 HTTP/WS 直连。

FD 时间序列证明 read loop 修复有效：

- READY 1000 时 open FDs 约 1013。
- READY 901 时 open FDs 约 913。
- READY 787 时 open FDs 约 799。

连接每减少一个，FD 基本同步减少一个。

## 5. Topic 队列满

实时发送和 drain 阶段仍没有 Topic/Proxy 满队列。`im-server-2` 的 1034 次 `topic's broadcast queue is full` 分为：

- `00:35:59–00:36:11 UTC`：约 436 次，发生在历史回查阶段。
- `00:37:19 UTC`：约 598 次，发生在 A agent 完成后批量关闭连接阶段。

20 条/500ms 虽有改善，但 Topic 历史数据仍以突发方式回送。建议：

1. 历史每页进一步降至 10 条，查询间隔保持 500ms。
2. 每页请求后等待本页目标消息全部收到或超时，再发送下一页，而不是只按固定时间节流。
3. agent 退出时按 10–20ms 间隔分批关闭连接，避免 1000 个群订阅同时离线。

## 6. 后续修复

1. 已将 `use of closed network connection` 分类为 socket 结果未知。
2. 已在 coordinator 共享两机历史命中 ID，使 B 也能正确计算实时缺失但已落库。
3. 历史回查已改为每页 10 条：同一 Topic 每页完成确认后再请求下一页，不同 Topic 最多 12 路并行。
4. agent 已改为在 10 秒窗口内渐进关闭 WebSocket。
5. r7 开始前重新解析 `api.118im.com`，确认每个 IP 都通过 `/32` 主机路由走 `en1`；OpenVPN 重连、DNS 变更或机器重启后必须重新核验。