Turbo VPN焕新发布：TurboLink自研协议亮相
2026 年 10 月 11 日，Turbo VPN 9.8.0 正式发布，这一次的主角不是节点数量，而是我们自研的传输协议 TurboLink。它把建立连接所需的握手往返从 4 次压缩到 2 次，首连耗时中位数从 1.8 秒降到 0.7 秒；在 30% 随机丢包的模拟弱网环境中，断线重连时间从 3.4 秒缩短到 1.3 秒，降幅 63%。
过去三年我们一直基于成熟开源协议做调优，能改的空间越来越小。跨境链路的现实是：往返时延动辄 150 毫秒，握手多一个来回就多 150 毫秒的等待；丢包 20% 以上时，传统拥塞控制会把窗口压到极低，恢复速度很慢。TurboLink 就是针对这两个具体问题写的。
一、握手两次往返，密钥协商并入首包
TurboLink 把身份校验与密钥协商合并进首个数据包，服务端回包即完成参数确认，因此完整握手只需 2 次往返。协议沿用 X25519 密钥交换与 AES-256-GCM 加密，安全性没有降级，改动集中在报文编排：客户端首包携带临时公钥、节点标识与会话随机数，服务端在同一回包中返回会话密钥材料与转发路径。
首包体积从 1,412 字节压到 968 字节，减少的部分主要来自证书链的替代方案：客户端预置节点公钥指纹，通过指纹校验替代每次传输完整证书。指纹随客户端版本更新下发，节点轮换密钥时指纹同步失效，避免中间人复用旧凭据。
罗雪（安全工程师）：「压缩握手的难点不是少发几个包，而是不能少任何一次校验。我们把证书链换成预置指纹加签名挑战，安全边界没变，只是把可缓存的部分提前放到了客户端。」
二、30% 丢包下的重连与吞吐测试
测试使用 Linux 流量整形工具在客户端侧注入丢包与延迟，分别模拟地铁隧道、跨境卫星链路与拥堵校园网三种场景。基线为上一版本使用的开源协议，对照组为 TurboLink，每组重复 100 次取中位数。
30% 丢包环境下，TurboLink 重连中位数 1.3 秒，基线 3.4 秒；20% 丢包下分别为 0.9 秒与 2.6 秒；5% 丢包下差距缩小到 0.4 秒与 0.7 秒。吞吐方面，30% 丢包时 TurboLink 维持 6.8MB/s，基线为 3.1MB/s；无丢包环境两者接近，分别为 82.4MB/s 与 81.7MB/s。
延迟表现同样有改善：首连 0.7 秒对 1.8 秒，节点切换 0.5 秒对 1.4 秒。对移动端用户来说，切换 Wi-Fi 与蜂窝网络时的重连体感差异最明显——以前要等三四秒，现在基本是「看一眼状态栏就已经连上」。CPU 占用没有明显上升，安卓中端机型单核占用增加 1.2 个百分点，桌面端增加 0.6 个百分点。
三、灰度节奏与旧版兼容
TurboLink 采用分批灰度：10 月 11 日先向 5% 的桌面端用户开放，10 月 16 日扩大到 30%，10 月 21 日覆盖全部桌面端，移动端在 10 月底跟进。灰度期间如遇连接异常，客户端会自动回退到原有协议，用户也可以手动在设置中关闭 TurboLink。
兼容性上，8.x 客户端仍可正常连接，只是无法使用新协议；节点侧同时保留旧协议入口，直到 2027 年 3 月完成全量迁移。协议参数已在客户端诊断面板中可视化，遇到问题时导出的诊断包会包含握手阶段耗时，便于客服定位是网络抖动还是节点异常。
「协议换新不应该是黑盒。」协议研发负责人何思远在内部评审会上说，「我们把握手耗时、重连次数、回退原因都做进了诊断面板，用户能自己看到链路发生了什么，这比宣传参数更有说服力。」下一步，团队计划在 2027 年第一季度把多路径聚合加入 TurboLink，让客户端同时走 Wi-Fi 与蜂窝链路。
想体验新协议，更新到 9.8.0 后在设置中把协议切到「TurboLink」即可，默认仍为自动模式。
用户评论（5）
高铁上用变化最明显，过隧道断一下马上就回来了，以前要等好几秒才恢复。
诊断面板能看到握手耗时这点很好，之前网络慢根本不知道卡在哪一步，现在有据可查。
老笔记本跑起来没什么负担，CPU 占用和之前差不多，切换节点确实快了一截。
刚开始灰度就试了，有一次连不上自动回退也没提示，希望回退时给个轻提示。
自研协议能理解，但希望公开更多技术文档，尤其指纹校验那部分，讲清楚我会更放心。