mirror of
https://gitee.com/xmz7891/ykxmz.git
synced 2026-10-18 13:40:45 +00:00
xmz7891
b1119d0da6
用户报两个问题：
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 分钟对照确认。
66 lines
2.7 KiB
Plaintext
66 lines
2.7 KiB
Plaintext
修「局域网连接被中转劫持」+ 长轮询 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 分钟对照确认。
|