 xmz7891
|
25e7780272
|
单次请求失败不再立刻判离线，改成连续 3 次
实测单个请求有 2~4% 的偶发失败（4G 丢包打在一条隧道连接上，
或者那条连接正在重连）。原逻辑是一失败就 online = false，
于是界面上会闪一下已断开 —— 用户点按钮时正好撞上那一闪，
看起来就像又连不上了。
而链路其实 1.5~15 秒就自己恢复（客户端本来就有退避重试）。
改成连续失败 3 次才判离线（手表至少 4.5 秒、电脑至少 6 秒）：
* 单次抖动完全不影响界面
* 真的断了仍然如实显示
这不是掩盖问题，而是把是否可用的判断从一次采样改成连续采样 ——
单点采样在有丢包的链路上噪声太大。
两边同步改：
android .../RelayTransport.java failStreak + OFFLINE_AFTER
windows/lanremote/relay.py _fail_streak + OFFLINE_AFTER
顺带记录 PC 端基准（真实用户视角，之前都是在设备上量的，
那等于把设备 4G 算了两遍）：
公网可用率 98% 耗时 中位 911 P90 1889 P99 23868 ms
长轮询 5/6 耗时 60.8~62.1 秒
对比设备端（中位 1344 / P90 2563）—— 用户实际体验比设备端量出来的好。
|
2026-10-07 16:16:50 +08:00 |
|
|
xmz7891
|
bf15a2ee61
|
静态资源交给 Cloudflare 边缘缓存（下载提速 41 倍）
实测基线：
ykxmz-setup-1.8.1.exe 只下到 237568/15067199 字节就停（17 KB/s）
ykxmz-watch-1.8.1.apk 201523 字节 / 66.8 秒 = 3 KB/s
ykxmz-server-1.8.1.zip 214900 字节 / 3.1 秒 = 67 KB/s
原因：relay 给所有响应都发 Cache-Control: no-store，
Cloudflare 完全不缓存 —— 每次下载/每张图都要穿隧道回 4G 源站。
改动：
/download/* no-store -> public, max-age=604800, immutable
文件名带版本号，同一名字内容永不改变，可以长缓存
/ -> public, max-age=60（挡住刷新重复回源）
/favicon.ico 已是 max-age=86400，保持不变
/shot/* 已是 max-age=86400，保持不变
/v1/* 保持 no-store（接口必须实时）
顺带修两个自己踩的坑：
1. _send() 无条件先发 no-store，再追加 extra 里的 Cache-Control，
结果是**两个 Cache-Control 头**，客户端只认第一个 ——
调用方传的缓存策略被吃掉。改成 extra 里有就不再发默认值。
2. do_HEAD 和 do_GET 的缓存头不一致：HEAD 对非 /shot/ 一律报 no-store。
下载器/代理用 HEAD 探测时会误判文件不可缓存。
现在 _head_info 给每个路由带上和 GET 完全相同的缓存头，
do_HEAD 也不再盲目覆盖。
结果（同一个测试口径）：
setup.exe 17 KB/s（截断） -> 695 KB/s 完整 15 MB 41 倍
watch.apk 3 KB/s -> 101 KB/s 33 倍
server.zip 67 KB/s -> 87 KB/s
三个文件全部 cf-cache-status=HIT（不再穿隧道回源）
排查过程记一笔：我一开始用 curl -I 验证，
看到的全是 no-store —— 因为 **-I 发的是 HEAD**，
而 HEAD 走的是另一个分支。查了半天才发现是验证方法错了。
|
2026-10-07 15:44:48 +08:00 |
|
|
xmz7891
|
b1119d0da6
|
修「局域网连接被中转劫持」+ 长轮询 15s→60s
用户报两个问题：
1. 局域网能搜到电脑，IP/端口/配对码都对，点连接**没有任何反应**
2. 走中转 1426ms 延时，一会儿就 502
========== 一、局域网被劫持（真 bug）==========
MainActivity.connect() 里：
boolean usedLan = !relayUrl().isEmpty() ? false : true;
if (!relay.isEmpty()) {
reply = client.connectViaRelay(...); // 走中转
} else {
reply = client.connect(host, port, ...); // 才走局域网
}
**只看「中转设置里填没填地址」，填了就一律走中转，
完全无视用户填的局域网 IP 和端口。**
而中转单次超时是 40 秒 —— 用户点完就卡在「正在连接…」
四十秒，在他看来就是"没有任何反应"。
影响两条路：
* 「局域网连接」页面填 IP 直连（connectLanTyped）
* 首页「已配对的电脑」点一下重连（quickConnect）
修法：给 connect() 加 preferLan 参数。明确要走局域网时
**先直连（6 秒超时，局域网本该是毫秒级），失败再退回中转**，
保证最终能连上。
顺带两个体验改进：
* 设备列表里，保存的 IP 和手表不同网段时标「⚠ 地址可能已过期」
（用户截图里那个 192.168.2.64 就是过期地址，电脑早换成
192.168.10.103 了）
* quickConnect 判断出地址过期就跳过直连，直接走中转查最新地址 ——
省掉那 6 秒白等
========== 二、长轮询 15 秒 -> 60 秒 ==========
实测隧道每次请求要多花 1~2 秒（CF 边缘路由 + 回源）：
本机直连 60 秒的 poll -> 60.0s
走公网同一个 poll -> 61.5~62.0s
这个开销是**按次数**收的：
15 秒一循环 -> 一天 5760 次/端，光路费 2.4~3.2 小时
60 秒一循环 -> 一天 1440 次/端，光费 0.6~0.8 小时
而且请求越频繁，撞上丢包/重连窗口的概率越大。
**不会让命令变慢**：长轮询是"有数据立刻返回"（device.event 唤醒），
拉长只是减少空转重开。实测 60 秒长轮询穿隧道 4/4 通过；
Cloudflare 单请求上限 100 秒，留了 40 秒余量。
三层同步改（客户端超时必须显著大于服务端 hold）：
* relay/relay.py RELAY_POLL 默认 25 -> 60
* windows/lanremote/relay.py POLL_TIMEOUT 40 -> 90
* android .../RelayTransport.java POLL_TIMEOUT_MS 40000 -> 90000
========== 三、A/B 实测（还在跑更严谨的一轮）==========
短测发现基线 http2+4 虽然 100% 成功，但 **P90 是 16.8 秒**
（每 10 次有 1 次卡十几秒 —— 正是用户说的"没反应"），
而 quic+6 的 P90 只有 2.8 秒。正在用真实长轮询模式
跑 10 分钟对照确认。
|
2026-10-07 14:11:33 +08:00 |
|
|
xmz7891
|
4c88ca901f
|
1.6.2：常规发布
- 版本号 1.6.2 -> 1.6.2
- 重建三端并打包
- 关键测试全过
|
2026-10-06 23:08:07 +08:00 |
|
|
xmz7891
|
b62ac865ea
|
ykxmz 1.5.0：修复手表端 TLS 证书校验 + MTU 修复网络稳定性
被控端
- 修复 MTU 问题：夹 MSS + 路径 MTU 探测（公网可用率 48% -> 100%）
- 复用 HTTP 连接（免掉每次新建 TLS 的 30% 握手失败）
- 每分钟回头找局域网，自动切回快 400 倍的路径
- 画面心跳帧：静止时省流量，客户端仍知道流是活的
- 锁屏时给出可操作的提示
手表端
- 内置 GTS Root R4 / GlobalSign Root CA，修 SSLHandshakeException
- 连接错误翻译成人话（证书/时间/解析/超时分别提示）
- 经中转连上后用服务器报的地址刷新已配对记录
- 新增局域网连接页面、服务器延迟检测
服务器端
- 支持 chunked 请求体（修每 16 秒一次的连接错乱与大面积 502）
- 网络调优脚本 net-tune.sh（开机自动应用）
- 管理页：批量删除、网络体检、下载区
- 隧道改 HTTP/2 + 双连接
文档
- 许可协议 / 安装前必读 / 安装后须知（作者：小麦子）
|
2026-10-06 19:01:05 +08:00 |
|