感知引擎:如何让客户端像传感器一样灵敏

感知算法白皮书 · 5 篇深度技术文章,拆解快连如何在毫秒级完成网络环境感知、自适应调整与本地决策。

① 20+监测指标:我们感知了哪些网络参数

分类:监测指标体系 更新: 阅读:≈ 8 分钟
快连感知引擎监测指标仪表盘示意图,展示延迟、抖动、丢包、带宽等20余项网络参数的实时采集面板
图1 · 快连感知引擎监测指标仪表盘(示意)

感知引擎的首要问题是"测什么"。我们把网络环境参数划分为四大维度、共 24 项核心指标。这套指标体系不是一次性设计完成的,而是经过三年迭代、淘汰了早期 13 项无效指标后保留下来的"最小完备集"。

第一维度:连通性指标(5项)

第二维度:质量指标(8项)

第三维度:上下文指标(7项)

第四维度:行为指标(4项)

设计这 24 项指标时,我们参考过学术文献、IETF RFC、运营商监测工具,但更多来自真实用户反馈。一位用户说"在高铁上视频会议卡顿",我们才发现"基站切换频率"这个指标必须纳入;另一位说"公共 WiFi 总断",我们才补上"门户检测"。指标体系是用户用脚投票出来的,不是工程师坐办公室想出来的。

指标采集的"反作弊"原则

每个指标都设计有冗余验证。例如延迟不能只看 RTT,还要看 TCP 握手时长;丢包不能只看 UDP 探测,还要看实际 TCP 重传率。任何单一指标异常都不直接触发决策,必须多指标交叉印证。这一原则让我们误判率从早期的 8% 降到了现在的 0.4%。

快连感知指标四大维度划分示意图:连通性、质量、上下文、行为四象限结构,每象限列出对应监测参数
图2 · 24项监测指标的四大维度划分
看看这些感知能力在真实网络故障中的表现 →

② 分层探测策略:猎豹模式的蛰伏与爆发

分类:探测架构 更新: 阅读:≈ 7 分钟
快连分层探测策略时序图,横向展示休眠态、候选池监测、全节点探测三层的触发时机与耗时
图3 · 猎豹模式三层探测时序图(示意)

如果每秒钟都对全部 200+ 节点做一次完整探测,客户端的流量和电量都会爆掉。但如果不探测,又无法及时发现节点质量变化。我们的解法是分层探测——把探测行为划分为三个层级,像猎豹一样平时蛰伏,关键时刻才爆发。

第一层:心跳探活(每秒)

对当前正在使用的节点,每秒发送一次轻量心跳包(32字节),只确认"通不通"。这一层消耗几乎可以忽略,平均每小时 110KB。

第二层:候选池监测(每5秒)

维护一个 3-5 个节点的"候选池",每 5 秒对池内节点做一次完整质量探测(延迟、抖动、丢包、带宽)。这一层流量约为每小时 1.2MB。

第三层:全节点探测(按需触发)

只在以下情况才触发全节点(200+)探测:

  1. 首次启动连接
  2. 候选池整体质量下降到阈值以下
  3. 用户主动刷新节点列表
  4. 检测到地理位置/运营商大跨度变化

全节点探测耗时 8-15 秒,流量约 4.5MB,但平均一天只触发 0.7 次。

设计感知引擎时,我们争论最激烈的问题是:探测频率定多少?有人建议每秒10次,说这样响应最快;有人建议每10秒一次,说这样最省电。最后我们写了三种策略,找了100个用户做了一周A/B测试。结果是每秒2次的平衡版综合评分最高。这个结果谁也没猜对,但它成了我们后来所有决策的依据——不去猜,去测。
三层探测策略每小时流量消耗对比柱状图,展示心跳探活、候选池监测、全节点扫描三档耗流差异
图4 · 三层探测策略的流量与电量消耗对比

猎豹模式的工程实现

三个层级使用同一个探测引擎,但触发条件、采样参数、决策权重都不同。心跳层只用 TCP keep-alive;候选池层走完整探测协议;全节点层走带分片的并发探测。三个层级的结果统一进入"质量评分模型",由评分模型统一决策是否切换节点。

看看这些感知能力在真实网络故障中的表现 →

③ 环境上下文识别:WiFi/蜂窝/公共网络如何区分

分类:环境识别 更新: 阅读:≈ 6 分钟
快连环境识别流程图,从系统接口到WiFi、蜂窝、公共网络、以太网四大类环境的决策树分类逻辑
图5 · 网络环境上下文识别决策流程(示意)

环境识别是感知引擎最容易被低估的部分。很多人以为"连上 WiFi 就是家用 WiFi",但实际上网络环境的差异直接决定了快连应该用什么加密策略、什么端口、什么协议。把公共 WiFi 当作家用 WiFi 处理,等同于在火车站办公而把房门敞开。

识别的四大类环境

  1. 信任环境(Trusted):家庭、办公内网。SSID 在白名单内,无 Captive Portal,IP 固定段。
  2. 半信任环境(Semi-trusted):朋友家、小型咖啡馆。SSID 未在白名单,但加密方式强(WPA2/WPA3)。
  3. 公共环境(Public):机场、酒店、商场。开放 WiFi 或 Captive Portal,或 SSID 含公共热点特征。
  4. 不可信环境(Untrusted):未知开放网络,探测到 SSL Strip、DNS 劫持等异常。

识别的多维特征

环境识别不是单一特征判断,而是综合 7 个特征做分类:

不同环境下的策略差异

识别出环境后,客户端会立即调整以下参数:

环境识别有个反直觉的发现:开放 WiFi(无密码)并不一定危险,公共 WiFi 的真正危险在于 Captive Portal——因为它强制把 HTTP 流量重定向到登录页,任何明文 Cookie、表单数据都会被同一网络的人看到。快连在检测到 Captive Portal 时,会强制等认证完成才发送任何业务流量,避免凭据泄漏。
看看这些感知能力在真实网络故障中的表现 →

④ 自适应灵敏度:不同场景下的探测频率调节

分类:灵敏度调节 更新: 阅读:≈ 5 分钟

固定探测频率看起来简单,但既不省电也不灵敏。咖啡馆里坐着不动,每秒探测一次是浪费;高铁上飞驰而过,每 10 秒探测一次又跟不上。快连的解法是自适应灵敏度——根据场景自动调节探测频率。

灵敏度的三个档位

自动切换灵敏度的 6 个触发条件

  1. 检测到高速移动:连续 3 个基站切换 → 自动升级到灵敏档。
  2. 检测到公共网络:默认切换到灵敏档,提高安全监测频率。
  3. 检测到高质量需求应用:视频会议、游戏启动 → 临时升级。
  4. 电池电量低于 20%:自动降到节能档,延长续航。
  5. 应用进入后台:降到节能档,前台立即恢复平衡档。
  6. 用户手动设置:用户在客户端可选强制档位,覆盖自动调节。

灵敏度调节的工程边界

自适应不是无限制地调高——灵敏档每秒探测 3.3 次是上限,再高会被路由器 QoS 标记为异常流量。我们做过测试,某些家用路由器会对每秒 10 次以上的 UDP 包做丢包处理,反而影响探测准确性。灵敏度的上限由"对端容忍度"决定,不由客户端单方面决定。

自适应灵敏度上线后,用户的电池投诉减少了 67%,但有一个意外发现:一些用户在地铁里反而希望"高灵敏",因为地铁的带宽下降很快,需要频繁切换节点。于是我们加了一条规则:检测到运营商为地铁合作运营商时,自动进入"灵敏+"档位。规则越来越细,但都来自真实场景。
看看这些感知能力在真实网络故障中的表现 →

⑤ 本地决策架构:为什么感知数据不上传云端

分类:隐私与架构 更新: 阅读:≈ 6 分钟

很多用户问:"你们能不能把感知数据上传到云端,用 AI 模型做更好的决策?"答案是不能,而且我们坚持不能。这不是技术问题,是架构原则问题。

为什么不上传

  1. 隐私红线:感知数据包含网络环境、地理位置、运营商等强关联信息,即使匿名化也有重识别风险。
  2. 延迟不可接受:云端决策往返至少 200ms,而本地决策平均 12ms,差 16 倍。
  3. 离线可用:本地决策让感知引擎在断网时仍能工作,这是自愈能力的基础。
  4. 法规合规:GDPR、中国《个人信息保护法》对网络环境数据的收集有严格限制。

本地决策引擎的工作方式

决策引擎是一个嵌入客户端的轻量级规则引擎,核心是 200+ 条 if-then 规则。这些规则不是硬编码,而是从快连三年的故障处理经验中提炼出来的"专家知识库"。每条规则都有"触发条件 + 决策动作 + 风险评估"三部分。

规则库的迭代机制

规则库通过 OTA 灰度更新。新规则先在 5% 用户中灰度,观测是否带来切换频率异常、投诉率上升等指标,逐步推广到 100%。规则版本与客户端版本绑定,任何规则的回滚都伴随客户端提示。

云端做了什么

云端只接收两类数据:①匿名聚合的节点质量统计(国家/地区/运营商级,无个人标识);②用户主动反馈(开关中的"上报问题")。这两类数据用于优化节点部署和发现新的故障模式,但绝不参与单用户的实时决策。

有用户提议:"能不能把我的决策数据拿来训练你们的大模型?"我们的回答是:"不能,但可以训练一个规则模板供你本地使用。"这就是本地决策架构的边界:算法可以升级,数据不出设备。这条边界不会因为任何商业理由松动。
看看这些感知能力在真实网络故障中的表现 →

读完了感知算法,想看看它在真实故障中的表现?

我们故意搞坏网络,看快连多久能恢复 —— 自愈实验室全实测数据开放。

进入自愈实验室 下载快连客户端