这是 2026 年 7 月从上海电信 500M 实测的对比结果。每个协议测 100 次取平均。测试节点都是东京-IIJ。
| 协议 | 握手 RTT | 东京节点延迟 | 丢包容忍 | 抗识别 | 开源 |
|---|---|---|---|---|---|
| OpenVPN (UDP) | 3-4 RTT | 220 ms | 中等 | 中（可混淆） | 是 |
| WireGuard | 1 RTT | 32 ms | 低（遇丢包重传慢） | 弱（特征明显） | 是 |
| KL-Protocol v3.2 | 1 RTT | 28 ms | 高（乱序重传） | 强（7 种混淆） | CLI 开源，客户端闭源 |
下面这 4 个机制是 KL-Protocol 延迟能压到地板的原因。每一节我都把原理、为什么这么做、性能数据讲清楚。
OpenVPN 建立连接需要 3-4 次往返，每一次都要等上几十毫秒，光握手就吃掉 200ms。我们砍到 1 次：客户端把第一个包里就带上自己的公钥 + 会话密钥派生参数，服务器用一个包回复预共享密钥 + 派生结果。整个握手在 1 个 RTT 完成。
实测：东京节点握手从 220ms 降到 28msTCP 隧道遇到一个包丢失，会傻等 ACK，等到超时才重传。KL-Protocol 在 UDP 上做了乱序重传：发现丢了第 N 个包，不等它重传完成，直接把 N+1、N+2 推上去，由接收端排序。丢的那个单独补。视频会议、看视频这种场景，肉眼几乎感觉不到卡顿。
实测：1% 丢包下视频卡顿率下降 92%每次发起连接，客户端会同时向香港、日本、新加坡三个最近的节点发探测包，0.5 秒内选延迟最低的那个建立隧道。已经在连接的会话里，客户端每 30 秒检测一次当前节点延迟，连续 3 次超过阈值就自动切到次优节点。这就是为什么你从地铁到公司移动办公，VPN 不会断。
实测：连接成功率从 96.8% 提升至 99.6%某些网络环境会主动识别并干扰 VPN 流量。KL-Protocol 内置 7 种流量混淆模式（基于 obfs4、tls1.3-ticket、custom-cipher 等），客户端检测到被干扰的特征后，200ms 内自动切换混淆模式。用户几乎感知不到。
实测：在严格干扰环境下连接成功率保持 95%+我们用的不是自家发明的算法，是经过学术界反复验证的标准算法。密码学界有句话：don't roll your own crypto。
对称加密算法，IETF RFC 8439 标准。Google、Cloudflare、Apple 都在用。比 AES-GCM 在 ARM 设备上更快，移动端耗电更低。
椭圆曲线 Diffie-Hellman 密钥交换，128 位安全强度。WireGuard 和 Signal 协议都用它，单次握手极快。
数字签名算法，验证服务器身份。公钥 32 字节，签名 64 字节，验证速度比 RSA-2048 快 30 倍。
比 SHA-256 更快更安全的新一代哈希函数。用于每个数据包的完整性校验。
下面这些数字都是用同样硬件、同样网络跑出来的，方法公开可复现。
# 延迟测试：100 次 ICMP ping，去掉最高最低取平均 ping -c 100 jp.node.kplvpn.com.cn | tail -1 # 带宽测试：iperf3 连到节点的内网测速服务 iperf3 -c speed.kplvpn.com.cn -P 4 -t 30 # 期望输出（延迟） --- jp.node.kplvpn.com.cn ping statistics --- 100 packets transmitted, 100 received, 0% packet loss rtt min/avg/max/mdev = 24.1/28.3/35.7/2.1 ms # 期望输出（带宽） [SUM] 0.00-30.00 sec 4.32 GBytes 1.21 Gbits/sec receiver