技术条目 01
公司与团队
深圳快连智能科技有限公司，核心成员来自运营商骨干网运维与数据中心网络方向，长期处理路径质量、拥塞控制与跨域互联问题。
- 不做深度包检测。
- 不记录访问目标。
- 不在客户端内嵌广告。
- 不宣传没有实测支撑的数字。
技术条目 02
为什么把不断线放在第一位
用户对网络的评价往往不是「平均速度多少」，而是「刚才那几分钟卡没卡」。平均值掩盖了最差的那几百毫秒，而体感恰恰由最差的那几百毫秒决定。
所以我们把资源优先投在冗余与切换上，而不是一味追求峰值带宽。这也是双协议栈双通道这个设计存在的理由。
技术条目 03
了解产品边界的三步确认
先明确边界，再判断是否适合你的场景，可以省掉大量试错。
- 确认加速对象：只优化网络路径与连接质量，不改变目标服务的可用性与政策。
- 确认不做的事：不做明文审计、不做内容留存、不提供绕过合规管控的能力。
- 确认平台差异：桌面端支持进程级分流，移动端按应用，路由器插件按域名与地址段。
能力与边界对照
| 项目 | 能力 | 边界 |
|---|---|---|
| 路径优化 | 多候选路径与故障切换 | 无法改善目标服务端自身问题 |
| 分流粒度 | 桌面端进程级 | 路由器插件不支持进程级 |
| 审计能力 | 不提供 | 需要明文审计应使用企业级网关 |
| 数据留存 | 仅连接元信息 | 不记录访问内容 |
为什么强调边界？
把不适用的场景写清楚，能避免用户在错误方向上投入时间。
企业合规场景适用吗？
需要审计或固定出口审计能力的场景不适用，应选择企业级方案。
可以用于正式生产环境吗？
可以，但建议先做一次冗余自检并记录基线。
技术条目 04
实现细节与参数取值
双协议栈双通道的核心是冗余。客户端同时维护两条独立协议路径，每条路径各自完成握手、密钥协商与心跳，互不干扰。任何一条出现异常时，流量在数据面瞬时切换到另一条，不需要重新建连。
切换发生在数据面而非控制面，这是能做到毫秒级的关键。重新建连意味着一次完整的握手往返，通常需要数百毫秒到数秒；数据面切换只需要重定向现有的数据流。
| 层级 | 机制 | 触发条件 | 切换耗时 |
|---|---|---|---|
| 第一层 | 双协议栈双通道切换 | 单通道瞬时劣化 | 毫秒级 |
| 第二层 | 智能节点调度 | 节点整体质量下滑 | 百毫秒级 |
| 第三层 | 强化学习链路预测 | 区域性故障 | 秒级 |
三层兜底的设计逻辑是从快到慢：第一层处理瞬时抖动，第二层处理节点级劣化，第三层处理区域性故障。层次之间不互相等待，先触发的先执行。
技术条目 05
性能数据与测量方法
≤200ms切换中断
99.95%单通道可用性
≥85%劣化预判准确率
三层兜底机制
强化学习模型用于预测路径劣化。模型输入是链路质量指标（延迟、抖动、丢包、带宽），不含任何用户访问内容。当模型预判某条路径即将劣化时，系统会提前建立备用连接，把切换中断进一步压缩。
以上数据的测量方式统一为：同一台设备、同一时段、同一目标服务，开关对应功能各测三轮并取稳定段均值。我们公开测量方法的原因很简单——没有方法的数字无法验证，也无法复现。
技术条目 06
边界条件与已知限制
| 限制 | 原因 | 影响 | 缓解方式 |
|---|---|---|---|
| 同源劣化 | 两条路径共享上游 | 多路径同时失效 | 切换出口区域 |
| 切换频繁 | 本地网络波动大 | 体验受影响 | 固定到更稳定出口 |
| 预判偏差 | 训练数据未覆盖该场景 | 切换稍晚 | 持续补充样本 |
模型只使用链路质量指标，不涉及用户访问目标。这是我们与「行为分析型优化」的根本区别。
技术条目 07
为什么把公司放在深圳
深圳的网络条件对我们这类业务有实际意义。跨境线路的物理起点、运营商的互联资源、以及供应链的响应速度，都直接影响到我们能不能快速调整线路。
更重要的是人才结构。我们的核心工程师来自运营商骨干网运维与数据中心网络方向，这类背景在深圳相对集中。
| 维度 | 具体情况 | 对业务的直接影响 |
|---|---|---|
| 网络资源 | 跨境出口资源集中 | 线路调整周期短 |
| 人才结构 | 网络与底层开发人才集中 | 协议与驱动层开发能力强 |
| 供应链 | 硬件与带宽采购响应快 | 节点扩容周期短 |
技术条目 09
相关阅读