mirror of
https://gitee.com/xmz7891/ykxmz.git
synced 2026-10-18 13:40:45 +00:00
xmz7891
cc5891e6d0
这个基准一直是红的（中转那条路报「连接阶段失败: timed out」），
而且报告里写着"这是中转链路的产品 bug"。**查下来不是产品的问题。**
== bug 1：两条路用了同一个配对码 ==
基准为了排除互相干扰，给两条路**各起一台全新被控端**（设计是对的），
但两台都用了写死的 code="246813"。
中转有「一个配对码只属于一台设备」的规则：
第 1 台（跑局域网）注册成功
-> stop_agent 杀掉进程，但**中转还以为它在线**（last_seen 没过期）
第 2 台（跑中转）用同一个码注册 -> **被拒**
中转日志：配对码 246813 已被 ... 占用，拒绝 ...
而 start_agent 只检查"有没有设备在线" —— 第 1 台僵尸还挂着，
于是**以为新的一台登记成功了**
-> 没有任何进程在回包 -> 超时
对照实验（新增 _build/verify_code_reuse.py）：
场景 A 同一个码 -> **不通**
场景 B 各用不同码 -> 通
修法：两条路各用不同码；start_agent 的判据从"有没有在线设备"
改成"有没有**配对码正好是这一台要用的码**的在线设备"。
== bug 2：attach 用的还是旧码（我第一版补丁也漏了这处）==
relay_connect() 里 `client.attach(code)` 用的还是局域网那个码 ——
attach 到一台已经死掉、但中转以为在线的设备上，pair 自然没人回。
修成 `attach(relay_code)`。
== 顺带更新一段过时注释 ==
原文写着「当前版本经中转只稳定支撑前 1~2 次交互……这是中转链路的
产品 bug」，并据此把中转的轮数调小、超时调短。
那个 bug **已经修好了**（根因：一条 HTTP/1.1 连接被长轮询和发命令
两个线程同时用，撞状态机抛 CannotSendRequest("Idle")，
异常冒到 _client_loop 外面把 client-relay 线程打死）。
注释不更新会误导后人以为产品还有这个问题。
== 修好之后的实测（本地中转，30 次/路）==
局域网 握手 16ms 成功 30/30 (100%) 中位 0ms P90 0ms 最大 1ms
中转 握手 46ms 成功 30/30 (100%) 中位 15ms P90 29ms 最大 32ms
这是本地中转，量的是**协议本身的开销**（长轮询往返 vs 直连 TCP）；
真实跨网络那条腿的 1.0~1.5 秒来自隧道和 4G，是另一回事。
结论：局域网确实是"毫秒级、不耗流量"的那条根本路径 ——
中位 0ms vs 15ms，而且不走任何外网。
踩坑记录：这两处都是"看起来像产品 bug、实际是测试自己的 bug"。
先怀疑测量工具，比先怀疑产品更省时间 ——
上一次（管理页缓存头）也是我拿 curl -I 测 GET 白查了半天。
58 lines
2.7 KiB
Plaintext
58 lines
2.7 KiB
Plaintext
修局域网/中转对比基准：它自己有两个 bug，害产品背了黑锅
|
||
|
||
这个基准一直是红的（中转那条路报「连接阶段失败: timed out」），
|
||
而且报告里写着"这是中转链路的产品 bug"。**查下来不是产品的问题。**
|
||
|
||
== bug 1：两条路用了同一个配对码 ==
|
||
|
||
基准为了排除互相干扰，给两条路**各起一台全新被控端**（设计是对的），
|
||
但两台都用了写死的 code="246813"。
|
||
|
||
中转有「一个配对码只属于一台设备」的规则：
|
||
第 1 台（跑局域网）注册成功
|
||
-> stop_agent 杀掉进程，但**中转还以为它在线**（last_seen 没过期）
|
||
第 2 台（跑中转）用同一个码注册 -> **被拒**
|
||
中转日志：配对码 246813 已被 ... 占用，拒绝 ...
|
||
而 start_agent 只检查"有没有设备在线" —— 第 1 台僵尸还挂着，
|
||
于是**以为新的一台登记成功了**
|
||
-> 没有任何进程在回包 -> 超时
|
||
|
||
对照实验（新增 _build/verify_code_reuse.py）：
|
||
场景 A 同一个码 -> **不通**
|
||
场景 B 各用不同码 -> 通
|
||
|
||
修法：两条路各用不同码；start_agent 的判据从"有没有在线设备"
|
||
改成"有没有**配对码正好是这一台要用的码**的在线设备"。
|
||
|
||
== bug 2：attach 用的还是旧码（我第一版补丁也漏了这处）==
|
||
|
||
relay_connect() 里 `client.attach(code)` 用的还是局域网那个码 ——
|
||
attach 到一台已经死掉、但中转以为在线的设备上，pair 自然没人回。
|
||
|
||
修成 `attach(relay_code)`。
|
||
|
||
== 顺带更新一段过时注释 ==
|
||
|
||
原文写着「当前版本经中转只稳定支撑前 1~2 次交互……这是中转链路的
|
||
产品 bug」，并据此把中转的轮数调小、超时调短。
|
||
|
||
那个 bug **已经修好了**（根因：一条 HTTP/1.1 连接被长轮询和发命令
|
||
两个线程同时用，撞状态机抛 CannotSendRequest("Idle")，
|
||
异常冒到 _client_loop 外面把 client-relay 线程打死）。
|
||
注释不更新会误导后人以为产品还有这个问题。
|
||
|
||
== 修好之后的实测（本地中转，30 次/路）==
|
||
|
||
局域网 握手 16ms 成功 30/30 (100%) 中位 0ms P90 0ms 最大 1ms
|
||
中转 握手 46ms 成功 30/30 (100%) 中位 15ms P90 29ms 最大 32ms
|
||
|
||
这是本地中转，量的是**协议本身的开销**（长轮询往返 vs 直连 TCP）；
|
||
真实跨网络那条腿的 1.0~1.5 秒来自隧道和 4G，是另一回事。
|
||
|
||
结论：局域网确实是"毫秒级、不耗流量"的那条根本路径 ——
|
||
中位 0ms vs 15ms，而且不走任何外网。
|
||
|
||
踩坑记录：这两处都是"看起来像产品 bug、实际是测试自己的 bug"。
|
||
先怀疑测量工具，比先怀疑产品更省时间 ——
|
||
上一次（管理页缓存头）也是我拿 curl -I 测 GET 白查了半天。
|