狗急加速器焕新发布：多协议并行传输架构完成重构

在 v3.2.0 版本中，狗急加速器完成了传输层架构的重构：同一条会话不再绑定单一协议，而是同时打开 UDP 与 TCP 两条通道，由调度器根据实时丢包反馈动态决定每个数据包走哪条路。重构从 6 月启动，历经两个月的灰度验证，覆盖了 3.7 万名测试用户。

安全研究员郑一鸣在发布说明中强调，这次改动只涉及传输调度，加密层完全沿用原有实现——握手依然是 Curve25519 密钥交换，数据段依然是 AES-256-GCM，会话密钥依然是每 24 小时轮换一次。“协议可以并行，密钥不能降级”，这是他给出的底线。

重构目标：让两条通道同时工作

旧版本的处理方式是二选一：游戏与音视频走 UDP，下载与网页走 TCP，选择依据是应用类型而非网络质量。问题在于，网络质量是变的——晚高峰的 UDP 可能被运营商限速，而某段链路的 TCP 重传代价又高得离谱。重构后两条通道始终处于待命状态，调度器只负责分流量。

• UDP 主通道：承载实时性敏感的数据包，不等待重传，首包时间控制在 12 毫秒以内。
• TCP 备用通道：承载完整性敏感的数据包，连续丢包时自动提高分流比例。
• 调度器：每 200 毫秒读取一次两条通道的丢包率与往返时延，据此调整分流比例。

分流比例不是简单的开关，而是一个连续值。在链路质量良好时，UDP 承载约 92% 的流量；当 UDP 方向丢包率超过 3%，比例会在 1 秒内逐档下调，最低可以降到 40%，剩余流量交给 TCP。

200 毫秒的调整节奏是怎么定的

调整太频繁会让两条通道都跑不满，调整太慢又赶不上网络变化。团队在灰度阶段试过 500 毫秒、300 毫秒与 200 毫秒三档，最终选定 200 毫秒：更短的间隔带来的收益已经很小，却会让客户端的调度开销上升约 9%。

为了配合这个节奏，FEC 前向纠错与重传做了明确分工：零星丢包按 5% 冗余比例的纠错包直接修复，不触发任何重传；只有连续 3 个包以上丢失时才动用 TCP 通道。这样既保住了实时性，也避免了在弱网下反复重传放大拥塞。

加密层没有做任何妥协

双通道并行最容易踩的坑是密钥与序列号的管理。两条通道各自维护独立的序列空间，但共用同一套会话密钥；调度器在分包时保证同一数据段的完整性不被拆分到不同通道，避免出现半包在 UDP、半包在 TCP 的情况。会话密钥每 24 小时轮换一次，轮换过程由 UDP 通道完成，TCP 通道在轮换完成后重新同步。

资源占用与兼容性

并行调度并非没有成本。相比上一版本，客户端的常驻内存增加约 6 MB，而由于减少了无效重传，CPU 占用在弱网场景下反而下降了 18%。在低配设备上这一升一降基本相互抵消，安卓端在 3 GB 内存机型上的前台驻留表现与旧版本持平。

兼容性方面，v3.2.0 客户端向下兼容 v2.x 的服务端配置，但只有服务端也升级到 v3.2.0 之后才能启用双通道并行。旧版本客户端连接新服务端时会自动退回单通道模式，功能与体验不受影响。

“传输层可以同时跑两条路，但加密层只能有一条底线。所有涉及密钥的代码这次一行都没有改动。”

—— 郑一鸣，安全研究员

“弱网场景的投诉量是这次重构最直接的回报，灰度期间这块工单少了将近七成。”

—— 陈锐，技术负责人

如何升级

Windows、macOS、Linux 客户端在启动时会自动检测并提示升级，下载安装包覆盖安装即可，登录状态与自定义规则完整保留。Android 与 iOS 客户端通过应用商店更新，版本号需达到 v3.2.0。路由器配置包需要重新导入一次，导入后原有的按 MAC 分流规则会自动继承。

返回资讯列表