修正 MTU 测试的过时断言（1500 -> 1400）

test_net_tune.py 原来断言 net-tune.sh 里写着 mtu 1500，依据是更早一次实测「接口 MTU 降到 1400 会掉到 50%」。那个结论后来被推翻了 —— 当时漏了一件事： **MSS 钳制只管 TCP，QUIC 走 UDP 完全不受保护。** 路径 MTU 实测 1472（1500 的包不通），QUIC 默认发 ~1452 的包会被中间设备静默丢掉，而 UDP 丢了不回 ICMP，只能等超时。把接口 MTU 压到 1400 之后，QUIC 建齐 10 条连接从 28 秒缩到 12 秒。所以现在是**故意**设 1400。断言跟着改，不然它会永久假失败，还会诱导后人把真正的改进改回 1500。顺带记录：全量回归 38 个阶段全部通过。新增的三个阶段（局域网优化 / 手表局域网切换 / 编码与换行 / 管理页设备控制）都是这轮加的。
2026-10-18 13:40:45 +00:00 · 2026-10-07 18:10:30 +08:00
parent 8880e7033d
commit aac43e559d
16 changed files with 1033 additions and 206 deletions
@@ -85,7 +85,82 @@ QUIC 建齐 6 条连接   28 秒 -> 13 秒
 dial 失败次数         2 -> 1
 ```

-### 2.4 异常长轮询（126 秒）是隧道重启造成的
+### 2.5 周期性 QUIC 崩溃：每 8~10 分钟一次
+
+长测期间观察到一个反复出现的模式：**QUIC 的连接数会突然从 8 掉到 1，几秒后又回到 8。**
+
+连接数采样（每 60 秒）里抓到的几个瞬间：
+
+```
+17:30:53  quic=7  h2=2
+17:31:59  quic=1  h2=2   <- QUIC 塌了
+17:33:04  quic=8  h2=2   <- 自己回来了
+...
+17:55:33  quic=8  h2=2
+17:57:06  quic=1  h2=2   <- 又塌
+17:58:12  quic=8  h2=2
+```
+
+**关键观察：QUIC 塌到 1 条时，HTTP/2 那 2 条始终存活。**
+
+也就是说：
+* 这是**链路级**的突发事件（不是单条连接的问题），QUIC 对它特别敏感
+* 而 HTTP/2 over TCP 靠内核的 SYN/重传扛住了
+
+watchdog 日志同时段记录：
+
+```
+17:56:39  公网不通（HTTP 000，quic=1, h2=2）   连续第 1 次
+17:56:59  公网不通（HTTP 000，quic=7, h2=2）   连续第 2 次   <- 自己回来了
+17:57:09  公网不通（HTTP 502，quic=6, h2=2）   连续第 3 次
+17:57:09  公网连续 3 次不通，但连接健康（合计 8 条）—— 再等等，不重启
+17:57:11  公网不通（HTTP 502，quic=1, h2=1）   连续第 4 次   <- 又塌，且 h2 也掉了
+17:57:11  连续 4 次公网不通 —— 重启 [两个实例]
+17:57:37  本次已建齐（合计 10 条）                <- 26 秒恢复
+```
+
+**这次重启是对的**：连接总数掉到 2 条，属于确认故障。
+而且**重启把中断缩短到 26 秒** —— 比等 QUIC 自然恢复（可能要几分钟）更划算。
+
+**一个值得后续验证的改进方向**：
+QUIC 塌掉时只剩 http2=2 在扛，容量很薄。把 HTTP/2 从 2 条提到 4 条，
+可能能在这种窗口里多撑一会儿。但注意第 2.2 节的配比对照是
+**2 分钟的短样本**，抓不到这种 9 分钟周期的事件 —— 要验证得跑更长的对照。
+
+### 2.6 故障不集中在某个时段
+
+把 watchdog 记录的"公网不通"按小时分桶，全天分布是均匀的，
+**没有出现"运营商某时段抖动"的特征**：
+
+```
+16:14 / 16:21 / 16:22 / 16:30 / 16:34 / 16:40 / 16:41 / 16:42
+16:49 / 16:50 / 17:00 / 17:10 / 17:11 / 17:12 / 17:13 ...
+```
+
+多数是 1 秒内自愈（`公网不通` 紧接着 `公网恢复`）。
+真正造成可见中断的只有三次：
+
+```
+16:30:19 -> 16:34:28   (4 分 09 秒)
+16:50:39 -> 16:53:04   (2 分 25 秒)
+17:00:20 -> 17:02:27   (2 分 07 秒)
+```
+
+### 2.7 客户端与设备同时故障 = 源站侧问题
+
+PC 侧长测（WiFi/宽带，与设备完全不同的网络）在同一个窗口也失败了：
+
+```
+PC 侧:   17:56:57  code=0    42093ms
+         17:57:13  code=502    674ms
+         17:58:57  code=0    25818ms
+
+设备侧:  17:56:46  code=000  25000ms
+         17:57:06  code=502   4652ms
+```
+
+**两个独立网络同时受影响，说明问题在 Cloudflare 边缘或隧道这一侧，
+不是某一端的本地链路。**

 30 次长轮询里出现两次 ~126.7 秒（正好是 2 倍 hold + 开销）：

@@ -152,7 +227,46 @@ dial 失败次数         2 -> 1

 ## 四、实测数据

-（待 2 小时长测结束后填入）
+### 4.1 长轮询：30 次真实 poll（每次挂 60 秒）
+
+```
+成功 29/30 = 96%
+失败 #22（000，130001ms —— 撞上 17:57 那次隧道重启，客户端 130 秒超时）
+
+耗时分布（成功的）:
+  最小 60920   P50 61439   P90 126604   P99 126716   最大 126716 ms
+  理想值 = 60000 + 隧道开销 ≈ 61000
+```
+
+**分布是双峰的**：
+
+| 档位 | 次数 | 说明 |
+|---|---|---|
+| 61 秒 | 26 | 正常，开销只有 1~1.5 秒 |
+| 126 秒 | 3 | 约 2 倍 hold，**全部对齐到隧道重启窗口** |
+
+对照三次异常的时间线：
+
+```
+#1  17:30:42 开始 -> 17:31:40 watchdog 重启两个实例   -> 126604ms
+#10 17:40:59 开始 -> 17:41:56 公网 000、17:42:46 重启 h2 -> 126716ms
+#18 17:50:17 开始 -> 17:50:42~17:51:25 连续三次不通     -> 126363ms
+#22 17:55:28 开始 -> 17:57:11 重启两个实例              -> 超时 130001ms
+```
+
+**结论：稳态下长轮询极其干净（61~62 秒，抖动 < 2 秒）；
+126 秒那种是隧道被重启打断造成的，不是协议或中转的问题。**
+
+### 4.2 设备侧公网可用率（2 小时长测，每 15 秒一次）
+
+数据见第 4.4 节的最终汇总。
+
+### 4.3 PC 侧（真实用户视角）
+
+PC（WiFi/宽带）发起，只有"边缘 -> 隧道 -> 设备 4G"这一跳是慢的。
+这与真实用户的情况一致（用户也是好网络）。
+
+### 4.4 待 2 小时长测结束后填入

 ## 五、受链路物理条件限制、做不到 100% 的部分