 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
|
7b7830d8c5
|
阶段3+4+5：管理页白色化 + 局域网诊断 + 全量验收
阶段3 管理页
- 清掉全部深色主题残留（地址框 #0b1220、按钮悬停 #262c36、
删除按钮 #2d1214 等 11 处），现在 0 处深色
- 接口全部正常：health / downloads / netcheck
阶段4 局域网诊断
- 查清楚"电脑不在同一网络"是怎么回事：被控端是**对的**
（lan_ips() 报 ['192.168.2.64', '169.254.83.107']，真实地址排第一），
是手表当时真不在 192.168.2.x —— 可能连了 5G 频段的另一个路由器，或开着移动数据
- 所以改了手表的提示：不再只说"不在同一网络"，
而是把**双方地址都打出来**，用户一眼能看出是网段不同还是连错 WiFi
- 端到端验证局域网路径：认证 1 ms，功能列表 207 项
阶段1 结论修正（一天内推翻自己两次，如实记录）
- 第一次判断"优选 IP 无用"：错。半小时内确实能避开超时 IP
- 第二次固定优选 IP：也错。那些实测 138ms 的 IP 半小时后全不通了
—— Cloudflare anycast 可达性随运营商路由变化，固定 IP 等于钉死到会失效的地址
- 最终：不固定，靠 GeoDNS + cloudflared 重试 + ha-connections 2 冗余
- 撤销后立即变好：连接稳定 2 条、超时告警 0 次、设备侧延迟 4.40s -> 1.66s
- **真正的瓶颈**：分段实测发现本机到 Cloudflare 的**裸 RTT 就 1439 ms**，
比经隧道的请求（1215 ms）还慢。说明瓶颈是这条网络的 4G 上行本身，
不是设备的隧道。公网侧已无优化空间。
- 局域网 118 ms vs 公网 1215 ms，快 10 倍 —— 这才是该走的路
阶段5 验收
- 全量回归 29 项全通过
- 设备侧验收 38 项全通过
- 成品：setup exe 14.37 MB / server zip / watch apk，已同步到设备下载区
|
2026-10-07 00:13:10 +08:00 |
|
|
xmz7891
|
81e923a0aa
|
1.7.1：修白屏 + 配对 + 官网管理页分家
手表端
- 修「连上后一片白屏」：initTabs() 从来没被调用过，
导致 tabDefs 为 null、selectTab 直接 return，
标签栏里只剩一个孤立的滑动指示器
- 应用名改成 ykxmz
被控端
- 修「设备已关闭新设备配对」：配对码本身就是密钥，
拿着正确的码就该放行。老逻辑"首台配对后自动关窗"会把
手表重装的人永久挡在外面
- 应用名改成 ykxmz
服务器端
- / 改成官网（公开，简洁介绍 + 下载）
- /zhingzhuanzhan 中转站管理（要登录），/admin 自动跳转
- 管理账号 xmz7891，可改
- 官网 / 登录页 / 管理页都加上 favicon
|
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 |
|