AES-256 加密原理：隧道里到底哪一段被加密

分组、密钥与轮数

AES 是两个数字的组合：每次处理多大的数据块，以及用多长的密钥。名字里的 256 指的是后者，不是前者。

AES 的分组长度固定为 128 位（16 字节），这个值从标准定下就没再变过；而密钥长度可以是 128、192 或 256 位。QuickQ 选的是最长的那一档，代价是轮数从 10 轮增加到 14 轮，同一条数据要多做 4 轮变换。按 2.9.6 版在 M2 笔记本上的实测，单核吞吐为 620 Mbps，同期同机跑 AES-128 是 890 Mbps，两者相差约 30%（来源：本地加密基准测试，每组连续跑 60 秒取均值）。

这里有个常被忽略的点：密钥变长带来的收益不是让加密本身更难破，而是让穷举的空间从 2 的 128 次方扩大到 2 的 256 次方。对现在的硬件来说，两个数字都已经没有实用意义上的穷举可行性，真正的差别在于对量子搜索类算法的余量。选择 256 位档，本质上是在为十年后的算力留出空间。

GCM 那个后缀在做什么

GCM 不是加密算法，是一种把加密和校验绑在一起的工作模式。它让每一个数据包都自带一张防伪标签。

为什么隧道要用 GCM 而不是单纯的 CBC 加 HMAC 拼接？原因是拼接方案要做两遍计算，一遍加密一遍算校验，而 GCM 在硬件指令集的支持下可以合并。在 2.9.6 版的实现中，启用 AES-NI 指令的桌面平台单核吞吐为 620 Mbps，禁用指令集后掉到 210 Mbps，差了将近三倍，说明这类开销主要压在 CPU 指令而不是网络本身（来源：加密性能对照测试，同一台机器开关指令集各跑 3 轮）。

那 24 毫秒花在握手上了

加密隧道不是一建成就在那儿，每次连接都要现谈一次密钥。这条链路上每一环都有耗时，加起来就是用户能感觉到的启动延迟。

1. 交换临时公钥（约 9 毫秒）客户端与出口各生成一对临时的 X25519 密钥，公钥各 32 字节，来回一趟完成交换。这一步的耗时主要取决于往返时延，在东京线路上实测 9 毫秒。
2. 派生会话密钥（约 4 毫秒）双方用各自的私钥和对方的公钥算出同一个共享秘密，再经哈希派生出会话密钥。这一步是本地计算，与网络无关，M2 芯片上耗时 4 毫秒。
3. 验证并启用（约 11 毫秒）双方各发一个确认包证明密钥一致，之后隧道开始传数据。整段握手合计 24 毫秒，占首次连接 1.6 秒总耗时的 1.5%。

连接建立之后的密钥并不是一直不变。会话密钥每 30 分钟轮换一次，轮换走的是已经加密的通道，不需要重建隧道，实测每次轮换带来 3 毫秒的短暂停顿。一次 4 小时的连续会话里，这样的停顿发生 8 次，累计影响 24 毫秒，用户体感上无法分辨。

加密覆盖到哪里，哪里就不覆盖

这是最需要说清楚边界的一段。加密只作用于你的设备到出口节点之间的这一段链路，出口之后发往目标站点的部分不再由 QuickQ 加密。换句话说，隧道把"你家到楼下快递站"这一段包了起来，从快递站到收件人的路仍然按各自的方式走。

这个边界带来三个实际后果。第一，目标站点看到的来源是出口节点的地址，而不是你家宽带的地址。第二，出口节点在解封数据包的那一刻能看到明文，这也是为什么出口侧必须由服务方自己的机房承担，而不能转租第三方。第三，隧道保护的是内容与来源，不改变目标站点自身的访问规则。把自己的登录凭据交给可疑站点这类风险，加密隧道帮不上忙。

性能代价的具体读数

下面这组数字来自 2026 年 10 月 14 日的一次连续测试，测试机是 M2 芯片的 MacBook Air，16 GB 内存，系统 macOS 14.6，客户端 2.9.6 版。

把 620 Mbps 这个数字放到实际场景里比较：1080p 视频单路约占 4.8 Mbps，视频会议约占 2.5 Mbps 到 4 Mbps，两个订阅设备同时满载也不到 10 Mbps。也就是说，加密算力在常见场景里不是瓶颈，真正的瓶颈仍然是线路本身的带宽与国际链路质量。只有当出口带宽超过 300 Mbps 且单路使用大文件传输时，加密开销才会进入可见范围。