快连隐形穿梭协议与指纹消除白皮书
系统阐述快连的加密隧道、智能路由、多路径传输与无日志架构，并如实说明威胁模型与安全边界。
快连隐形穿梭协议与指纹消除白皮书
快连 是面向全球用户的网络加速与隐私保护产品。我们把公共互联网视为不可信传输环境，通过加密隧道、智能调度与数据最小化三类机制，在不改变用户既有应用的前提下改善连接质量并降低暴露面。设计目标按优先级排列为：
- 安全：传输内容加密、防篡改，密钥不落盘到节点；
- 稳定：通过多路径与自动故障转移降低中断率；
- 隐私：默认无浏览日志，运营数据最小化；
- 简单：零配置可用，复杂策略对用户透明；
- 可审计：数据处理清单、威胁模型与政策公开可核查。
快连整体长什么样
系统由三部分组成：
- 客户端：运行于用户设备，负责虚拟网卡、隧道封装、分流规则、链路探测与本地防护（Kill Switch）；
- 接入点网络：分布在各区域的转发节点，仅承担加密流量的解封与转发，不持久化用户流量内容；
- 控制面：负责账号、计费、节点列表下发与质量调度，与数据转发面逻辑隔离。
数据面与控制面隔离的意义在于：即使单个接入点被物理接触，攻击者也无法从节点上获得用户历史访问记录或长期密钥。
快连加密是怎么建的
客户端到接入点的隧道基于现代标准协议构建（正式版以 自研极速协议 协议族为主、兼容 IKEv2/IPsec 作为备选），数据报文使用 AES-256-GCM 或等效的现代认证加密算法，同时保证机密性与完整性，可检测到中途篡改。
快连密钥是怎么管的
- 会话密钥通过标准非对称协商在客户端与接入点间动态建立；
- 节点不长期保存用户私钥，重启即丢弃会话状态；
- 支持密钥轮换，降低单点密钥泄露的影响窗口。
快连数据会不会被人改
客户端内置接入点公钥校验机制，首次连接与节点更换时对服务端身份进行验证，防止在不可信网络中被中间人代理。
快连线路选择与并发传输
传统单一隧道把全部流量固定在一条路径上，一旦该路径拥塞，用户只能手动切换。快连的调度引擎采用「探测—评分—连接—切换」闭环：
- 客户端对候选接入点进行周期性轻量探测，得到延迟、抖动、丢包样本；
- 控制面汇总接入点负载与骨干网状态，输出节点综合评分；
- 客户端建立主隧道并维持备选隧道；
- 主路径指标劣化越过阈值时，在备选路径间迁移会话，业务无感知。
在具备多条上行链路（如有线宽带 + 移动热点）的设备上，客户端可进行多路径并发，利用带宽聚合提升吞吐，并在单链路中断时保持长连接业务（视频会议、远程桌面）不中断。
快连隐私是怎么被架构保证的
「无日志」不是一句口号，而是一组可核查的数据处理约束。快连处理的数据分为三类：
| 数据类别 | 具体内容 | 用途与保留策略 |
|---|---|---|
| 账户数据 | 邮箱、订阅与支付状态（支付明细由持牌机构处理） | 提供服务与计费必需，随账户注销按法定期限处理 |
| 运维计量 | 本次会话的字节总量、连接时长、接入点区域 | 仅用于计费与容量规划，不关联具体访问目标 |
| 不采集 | 访问的目标地址 / 域名、浏览内容、通信时间戳、DNS 明细 | 系统不持久化 |
接入点仅在内存中维护转发所需的会话状态，重启即清除。隐私政策会随版本迭代持续披露数据清单的任何变化。
快连我们防得住什么、防不住什么
我们如实说明快连能与不能解决的问题：
| 威胁 | 是否防护 | 说明 |
|---|---|---|
| 公共 Wi-Fi 窃听与篡改 | 是 | 隧道加密使局域网观察者只能看到加密报文 |
| 真实地址暴露于访问目标 | 是 | 目标侧看到的是接入点地址 |
| 隧道断连瞬间的流量泄露 | 是 | Kill Switch 在断连时阻断外联 |
| 终端自身已被植入恶意软件 | 否 | 系统级木马可读取设备明文，应使用安全设备并保持系统更新 |
| 用户主动泄露的凭据 | 否 | 钓鱼与密码复用需要通过多因素认证与安全习惯解决 |
| 支付与账户的完全匿名 | 部分 | 合规支付通道存在实名要求，不承诺完全匿名 |
快连承诺与透明度
- 仅在获得法律许可的国家与地区提供服务，用户须遵守所在地法律与可接受使用政策；
- 收到执法请求时按法律程序审查，仅在法定要求范围内提供数据，并在法律允许时通知用户；
- 定期发布透明度说明，公开数据请求的数量与类型（正式运营后）；
- 白皮书版本随架构演进更新，重大变更显著告知用户。
本白皮书对应 v0.9 技术规格，能力清单随版本迭代持续更新。
隐形穿梭协议工程实现细节补充
这一节是给我们技术评审委员会和好奇的工程师准备的——下面 8 个技术模块是过去三年我们团队反复打磨的工程重点。
快连一、协议分层：从应用层到物理层的指纹消除
我们的隐形穿梭协议不是一个单独的黑盒，而是一个分层体系，每一层都对应一种类型的指纹消除需求：
- 应用层：ChaCha20-Poly1305 流加密 + TLS 1.3 握手伪装，消除内容可读性和握手特征。
- 传输层：每包长度在 64-1400 字节之间随机抖动，心跳间隔用素数序列扰动，消除 packet size 分布和心跳周期特征。
- 网络层：每次连接从出口 IP 池随机抽取地址，跨会话无关联；TTL、TCP 窗口大小、MSS 等参数动态调整，消除网络栈指纹。
- 物理层（间接）：通过 BGP Anycast + 多入口接入，让用户连接到最近的物理节点，减少跨网关联的可能性。
这四层共同构成 全链路数据指纹消除 的实现基础——单独看任何一层都不够，只有四层叠加才能让用户在网络上的"身份"被彻底打散。
快连二、加密套件选择的工程权衡
为什么是 ChaCha20-Poly1305 而不是 AES-256-GCM？我们用一个决策矩阵来说明：
| 指标 | AES-256-GCM | ChaCha20-Poly1305 |
|---|---|---|
| 有 AES-NI 硬件加速时的吞吐 | 高（5-8 Gbps） | 中（1.5-2.5 Gbps） |
| 无 AES-NI 时的软件吞吐 | 低（200-400 Mbps） | 高（800 Mbps-1.5 Gbps） |
| ARM 处理器能效 | 中 | 高 |
| 侧信道攻击风险 | cache-timing 攻击（无 AES-NI 时） | 天然免疫 |
| 密码学安全等级 | 256-bit，认证加密 | 256-bit，认证加密 |
| 标准化状态 | TLS 1.3 推荐 | TLS 1.3 推荐 |
考虑到 95% 的移动设备和大量老款桌面设备都没有 AES-NI 硬件加速，ChaCha20-Poly1305 是更普适的选择。安全等级上两者等价。
快连三、0-RTT 与 1-RTT 的精细取舍
TLS 1.3 引入的 0-RTT 机制能把跨会话首包延迟从 1-RTT 降到 0-RTT，但代价是重放攻击风险。我们的策略是混合模式：
- 敏感操作走 1-RTT：登录、支付、修改密码、修改密钥、订阅变更——这些操作强制走完整握手，绝不启用 0-RTT。
- 读类操作走 0-RTT：服务器节点状态查询、订阅信息拉取、用户配置同步——这些操作即使被重放也不会产生副作用。
- 会话恢复材料：客户端在内存中保存最近 30 分钟的 PSK，超时自动失效；每次恢复都重新生成部分派生材料。
- 服务端二次防御：服务端为每个会话票据记录 single-use 状态，重复使用则强制升级到完整握手。
这是合规与体验的折中——技术上可以做更强的抗重放，但成本与延迟不划算。
快连四、量子安全：Kyber768 与 ECDHE 的混合方案
面向 2027 年及以后的量子威胁，我们在 0.9 实验分支里实现了 Kyber768 + ECDHE 的混合 KEM。具体步骤：
- 客户端发送 ClientHello 时，同时携带 ECDHE 共享参数和 Kyber768 公钥。
- 服务端用 Kyber768 加密一个随机种子返回给客户端，同时返回 ECDHE 共享秘密。
- 客户端用 Kyber768 私钥解密得到同一个种子。
- 双方把这个种子和 ECDHE 共享秘密一起喂给 HKDF 派生最终的会话密钥。
这样即使 ECDHE 被未来的量子计算机破解，攻击者仍然需要破解 Kyber768 才能恢复会话密钥——而 Kyber768 是 NIST 选定的抗量子算法，安全性基于模块格上 LWE 问题的难度。握手延迟增加约 30ms，对用户体验影响很小。
快连五、协议识别规避的工程化测试
我们每两周跑一次内部回归测试，工具链包括：
- Wireshark：抓完整会话，对比 ClientHello 的 SNI、ALPN、Cipher Suites 等特征与真实 Chrome/Firefox 的分布。
- nDPI / Zeek IDS / Hyperscan：三种开源 DPI 引擎，覆盖了大部分商业 DPI 的核心指纹识别能力。
- ooni：公开探测平台，可以从全球多个 vantage point 验证协议在不同网络环境下的表现。
- 自研回归套件：在 7 种主流 DPI 引擎（含商业版本 + 两个开源 fork）上跑指纹库比对，目标命中率 < 6%。
任何一次回归测试不达标，对应代码改动都不能合并到主分支。这是 协议识别规避 能力能够长期保持的工程基础。
快连六、隐私架构：日志不是营销话术，是架构约束
我们的无日志政策不是写在落地页上的一句话，而是架构层面的硬约束。具体执行：
- 客户端在内存里完成所有会话状态协商，会话结束 5 秒内统一擦除，不写盘、不写日志、不上报。
- 服务器端不存储原始连接时间戳和目标站点域名，只保留聚合到 5 分钟粒度的"过去 5 分钟通过 A 节点的流量总和"用于计费和容量规划。
- 客户端 SDK 不在本地写浏览历史文件，关闭客户端后操作系统级缓存里也不会留下流量明细。
- 账户中心查询时返回的是预聚合数据，而不是原始日志的实时查询结果。
"隐私保护"对我们来说不是营销文案，是写在架构评审 checklist 里的硬约束，每一次发版都要过这道关。
七、TLS 1.3 在隐形穿梭协议中的角色
TLS 1.3 是隐形穿梭协议的"外衣"——所有真实的握手过程都遵循 TLS 1.3 的状态机规范。这意味着：
- 客户端和服务端的状态机是标准化的、可审计的；
- 握手过程可以被任何 TLS 1.3 兼容的中间设备解析，但解析出来的是伪装后的 HTTPS 请求，不会被当作代理；
- 密码学套件、扩展、参数都符合 RFC 8446，未来升级路径清晰；
- 与现有网络基础设施（防火墙、CDN、负载均衡）兼容性好。
我们没有自创协议头或私有状态机——这不是为了合规好看，而是为了长期可维护性。隐形穿梭的所有"隐形"能力都在 TLS 1.3 的标准框架内实现，每一个改动都可以单独审计、回滚、复测。
快连八、面向未来：可演化架构
网络环境的威胁是持续演化的，我们的协议设计从一开始就把"可演化"作为核心目标：
- 协议层与混淆层解耦：可以独立升级混淆策略而不动协议状态机，反之亦然。
- 配置驱动的指纹库：新增 DPI 引擎识别模式只需更新配置文件，无需重新编译客户端。
- 客户端灰度发布：新版协议先对 1% 用户灰度，监测识别率和兼容性指标再逐步放量。
- 服务端多版本并存：同一节点同时支持 v0.8 / v0.9 / 实验分支，用户升级体验平滑。
这意味着当网络环境出现新变化时（比如某种新的 DPI 检测算法普及），我们可以在几小时到几天内推送修复，而不是被迫做大版本升级。这是 隐形流量伪装 能力长期保持的工程保障。