 xmz7891
|
490adbdba3
|
补充 2 小时长测的最终数据（361 样本 / 1 小时 44 分）
可用率 356/361 = 98.61%
耗时 最小 829 中位 1280 P90 2386 P99 14242
长测原定 2 小时，实际跑到 1 小时 44 分停了 ——
设备在 19:11 换网段（192.168.10.105 -> 192.168.2.156），
测量脚本随之断开。361 个样本足够说明问题。
改之前是 96~98%，现在 98.61%，且失败不集中在某个时段。
|
2026-10-07 20:29:58 +08:00 |
|
|
xmz7891
|
035c2cc4c5
|
补充连接数时间线证据：双协议兜底确实起作用
86 个采样点 / 约 1.5 小时：
QUIC: 最低 1 最高 8 平均 7.5
HTTP/2: 最低 1 最高 2 平均 2.0
QUIC 塌陷（<= 2 条）只有 2 次，占 2.3%
塌陷时 HTTP/2 一直是 >= 1 条（2/2 = 100%），归零 0 次
QUIC 连接数分布：
8 条 76.7%
7 条 15.1%
6 条 3.5%
5 条 2.3%
1 条 2.3% <- 塌陷（1.5 小时里约 2 分钟）
一次典型塌陷的时间线也记下来了（watchdog 日志）：
重启把中断从「可能几分钟」缩到 26 秒。
目标「0 掉线」做不到 —— 4G 链路上 QUIC 会周期性塌陷。
但影响被压到 2.3% 的窗口，而且 HTTP/2 全程兜住。
教训：多行中文提交信息里有引号时，PowerShell 的 -m 参数会被吃掉。
一律写进文件再用 -F 提交。
|
2026-10-07 19:03:45 +08:00 |
|
|
xmz7891
|
4cc368431c
|
新增 docs/优化实测数据.md：本轮所有优化的实测数字汇总
每一项都写清楚「改之前是多少、改之后是多少、怎么测的、受什么限制」，
以后有人问「这个改动到底有没有用」能直接翻数字，不用靠感觉。
内容包括：
* 测量方法上的两个坑（从哪台机器测差很多、curl -I 验证 GET 是错的）
* 下载吞吐 41 倍（含改之前/之后对照）
* 隧道稳定性：配比对照表、QUIC 72% 拨号率的真因、
MTU 1400 的效果、长时可用率
* 长轮询 30 次数据（中位 61439ms）
* 端到端延迟：局域网 0ms vs 本地中转 15ms
* 局域网优化的四个真问题
* 「按一下没反应」的完整证据链和根因
* 独立验证发现的 9 个问题
* 测试工具自己骗人的两次
* 服务端部署脚本的三套测试
* **没做到的部分**（98.5% 可用率的物理限制，如实记录）
这份是内部工程文档，已加进对外清洁度检查的允许清单
（和 docs/项目规矩.md、docs/双平台发布.md 同类）。
|
2026-10-07 19:02:57 +08:00 |
|