饿饭加速器多协议传输全新升级：AES-256加密与0.8秒切换

2026 年 9 月 20 日，饿饭加速器完成多协议传输模块的年度升级。新版本在原有 UDP 多路复用基础上加入冗余补发通道，在 8% 丢包的弱网环境下，实测有效下行带宽由此前的 38.6 Mbps 提升至 49.0 Mbps，涨幅 27%。同时，全链路加密升级为 AES-256-GCM，密钥每 15 分钟自动轮换一次，线路协议切换耗时由 1.6 秒缩短到 0.8 秒。

传输层的改造目标有两个：一是让数据在质量不佳的链路上也能尽可能完整地到达，二是让安全机制的开销保持在用户几乎察觉不到的水平。这两件事在过去往往互相拉扯——加密越严密，处理耗时越高；冗余越多，带宽浪费越大。本轮升级的关键，是在两者之间找到更精确的平衡点。

多路复用传输如何降低丢包影响

多路复用传输把一条逻辑连接拆成若干条并行的数据流，各自独立编号并在接收端重组。这样的好处是，某条流出现丢包时，其他流的数据仍能继续到达，不会因为单个数据包的缺失而阻塞整条连接。客户端会根据实时探测到的丢包率动态调整并行流数量：链路健康时使用 4 条流以降低开销，丢包率超过 3% 时自动扩展到 8 条流提高冗余度。

本次新增的冗余补发通道，则是在检测到某条流连续两个包未确认时，立即通过备用路径重发一份副本。副本与原文使用相同的序列号，接收端一旦收到任意一份即可完成重组并丢弃重复数据。测试显示，这一机制让 8% 丢包环境下的重传等待时间从平均 142 毫秒降至 63 毫秒，视频与游戏场景中的卡顿次数明显减少。

并行流数量的调整同样需要考虑设备差异。移动端的处理能力与电量预算有限，扩展流数量会增加处理器唤醒次数，因此手机端把上限设为 6 条流，并在屏幕关闭或电量低于 20% 时回落到 4 条；桌面端则维持在 8 条的上限，在检测到有线连接时允许进一步扩展。所有调整都在客户端本地完成，服务端只需配合接收与重组。

「冗余补发的本质是拿一点带宽换稳定性。」饿饭加速器安全传输负责人曾亦航解释道，「冗余比例是可调的，网络好的时候几乎不启用，网络差的时候才会升高，所以我们不担心它会白白吃掉用户的带宽。」—— 饿饭加速器安全传输负责人 曾亦航

AES-256 加密与密钥轮换机制

加密层升级为 AES-256-GCM 模式后，每条数据包在加密的同时附带完整性校验，任何篡改都会在接收端被直接识别并丢弃。密钥由客户端与服务端在建立连接时通过密钥交换协议协商生成，此后每 15 分钟轮换一次，历史密钥即时销毁，即使某一段流量被完整记录也无法用它推导后续通信内容。

用户较为关心的加密开销问题，实测数据同样给出了答案：启用 AES-256-GCM 后，客户端 CPU 占用在普通电脑上平均增加 1.8 个百分点，在移动端增加约 2.4 个百分点；同等网络条件下，加密带来的带宽损耗为 3.2%，远低于用户对网速变化的可感知阈值。团队同时保留了 DNS 防泄漏功能，避免域名查询请求在隧道之外以明文形式暴露。

密钥协商过程也做了优化。旧实现需要在连接建立前完成一次完整的密钥交换，弱网下这一步偶有超时导致连接失败。新版本采用预协商机制：客户端在空闲时提前与常用的两到三个节点完成密钥协商并缓存结果，真正发起连接时直接使用缓存密钥，连接建立时间在弱网环境下由平均 1.3 秒缩短到 0.6 秒。

协议切换耗时缩短至 0.8 秒

协议切换指的是客户端在不同传输协议或不同接入方式之间迁移连接的过程。旧实现需要先断开当前连接、再重新握手，完整流程平均耗时 1.6 秒，期间用户的下载或对局会短暂中断。新版本改为「先建后拆」：客户端在后台预先与目标协议完成握手并建立备用通道，确认可用后再平滑地把流量迁移过去，最后回收旧通道。

通过这种方式，切换期间的数据中断窗口被压缩到 0.8 秒以内，实测最快的一次切换为 0.47 秒，过程中已建立的下载任务不会中断重连。团队表示，后续会继续优化跨协议切换在移动网络下的表现，并计划开放协议优先级的手动设置，相关进展将在饿饭加速器新闻中心发布。

切换的稳定性同样依赖客户端与服务端的协同。为避免过程中出现两端状态不一致，新版本引入了切换令牌机制：客户端发起迁移前先向目标节点申请令牌，只有令牌确认后才会真正转交流量，若目标节点在 2 秒内未确认，客户端会保留原通道并重新评估。灰度期间共完成 18.6 万次切换，其中因令牌未确认而回退的比例为 0.7%，回退过程用户无感知。