不同协议在测速中的真实差距

凌晨两点，老周把咖啡杯往桌上一墩，盯着屏幕上跳动的数字骂了句脏话。

同一台VPS，同一个机房，同一条宽带，只因为切换了协议，Speedtest的下载数字从187Mbps掉到了43Mbps。他揉了揉眼睛，又重新跑了一遍。结果依旧。

老周是我认识七年的朋友，在一家跨境电商公司做运维。上周他们老板去新加坡出差，抱怨酒店WiFi连公司内网“慢得像拨号”，老周远程排查了三个晚上，最后发现问题根本不在带宽，而在协议选择。他拉着我一起做了这轮测试，于是有了下面这份带着咖啡渍和黑眼圈的记录。

一、先交代测试环境：别急着看数字，先看条件

老周的测试环境并不豪华，但足够干净：

• 客户端：一台装了Windows 11的迷你主机，千兆网卡，有线连接。
• 本地宽带：国内某二线城市电信千兆光纤，实测裸连Speedtest下载约940Mbps。
• 服务端：一台位于日本东京的VPS，KVM虚拟化，1Gbps共享带宽，配置为2核2G。
• 服务端软件：Xray-core 1.8.x，分别配置VLESS+TCP、VLESS+TCP+TLS、VLESS+WebSocket+TLS、Hysteria2、Shadowsocks-2022。
• 测速工具：Speedtest CLI（固定东京节点）、iperf3（服务端直连测TCP吞吐）、以及curl下载一个100MB的测试文件。
• 时间：凌晨1:30到3:00，避开晚高峰。

他特意强调：“所有测试都关闭了BBR以外的拥塞控制，服务端开启BBR，客户端默认CUBIC。每项跑三次取中位数，避免偶然抖动。”

我问他为什么不用那些一键测速脚本，他笑了笑：“脚本只告诉你结果，不告诉你为什么。我要的是差距背后的原因。”

二、第一轮：裸TCP、TLS、WebSocket，差距从第一跳就开始了

2.1 VLESS+TCP：最朴素的协议，跑出了最意外的数字

老周先配了最基础的VLESS+TCP，没有TLS，没有伪装。iperf3直连服务端，TCP吞吐稳定在680Mbps左右。Speedtest下载412Mbps，上传387Mbps。

“这个数字其实不差，”老周说，“但问题在于，它太‘裸’了。TCP特征明显，QoS识别起来一抓一个准。”

他给我看了抓包截图：VLESS+TCP的握手包和普通TLS握手在长度分布上有明显差异，中间设备只要做简单的流量指纹，就能把它和正常HTTPS区分开。换句话说，跑得快，但跑得不安稳。

2.2 VLESS+TCP+TLS：加了层壳，速度掉了两成

接着上TLS。同样的VLESS，套上TLS 1.3，iperf3吞吐降到540Mbps，Speedtest下载328Mbps。

“TLS握手和加密本身有开销，但这不是主要问题。”老周指着CPU占用曲线，“你看，服务端单核在TLS加解密时直接飙到70%。东京这台VPS是共享CPU，邻居一忙，你的TLS握手就要排队。”

他补了一句：“很多人以为TLS只是‘加个密’，实际上它把连接建立的RTT从1个变成了2到3个。对于短连接测速，这个差距会被放大。”

2.3 VLESS+WebSocket+TLS：伪装成网页，速度再砍一刀

然后是WebSocket+TLS。这是很多“机场”最爱用的方案，因为可以套CDN，伪装成正常网页流量。但老周的测试结果不太好看：iperf3吞吐390Mbps，Speedtest下载214Mbps。

“WebSocket本身有帧头开销，加上TLS，再加上服务端要处理HTTP升级请求，路径变长了。”他打开Xray的日志，“你看，每个数据包都要经过WS帧封装，小包场景下开销尤其明显。”

我问他：“那为什么还有人用？”他叹了口气：“因为能过CDN，能抗封锁。速度是代价，但有时候能连上比跑得快更重要。”

三、第二轮：当Hysteria2出场，前面三个都成了背景板

老周把Hysteria2的配置贴上来时，我注意到一个细节：他特意把up和down设成了200 Mbps和500 Mbps，而不是默认的100 Mbps。

“Hysteria2基于QUIC，自带拥塞控制，而且它的Brutal算法根本不讲武德。”他边说边启动服务端。

iperf3跑UDP测试，吞吐直接冲到920Mbps，几乎跑满VPS的1Gbps端口。Speedtest下载687Mbps，上传554Mbps。

“这还不是最狠的，”老周说，“你注意看延迟。”他打开ping测试，Hysteria2的RTT比VLESS+TCP+TLS低了18ms。在丢包率5%的模拟环境下，Hysteria2的吞吐还能保持在400Mbps以上，而VLESS+TCP+TLS直接掉到90Mbps。

“QUIC的多路复用和0-RTT握手，让它在弱网下优势巨大。”老周解释道，“但代价是CPU占用高，而且UDP流量在某些网络里会被QoS限速甚至阻断。”

他补充了一个关键点：“Hysteria2的Brutal算法本质上是‘抢带宽’，如果你的VPS邻居也在跑Hysteria2，你们会互相挤占。所以它快，但不一定公平。”

四、第三轮：Shadowsocks-2022，老牌协议的倔强

最后出场的是Shadowsocks-2022。老周说这是他“最后的保留项目”，因为SS-2022在加密和抗封锁上做了不少改进。

测试结果：iperf3吞吐610Mbps，Speedtest下载376Mbps，上传341Mbps。延迟比VLESS+TCP+TLS低7ms，但比Hysteria2高11ms。

“SS-2022的AEAD加密效率很高，而且没有TLS握手开销，所以比VLESS+TLS快。”老周说，“但它的问题在于，流量特征还是太明显。没有伪装，没有CDN，纯靠加密硬扛。”

他给我看了一段SS-2022的流量统计：“你看，它的包长分布和随机流量还是有区别。深度包检测（DPI）稍微升级一下，就能识别出来。”

五、差距背后的真正原因：不只是协议本身

测完五组数据，老周把结果汇总成一张表：

| 协议 | iperf3 TCP/UDP吞吐 | Speedtest下载 | 延迟（空闲） | 抗封锁能力 | |------|-------------------|---------------|-------------|-----------| | VLESS+TCP | 680 Mbps | 412 Mbps | 42 ms | 弱 | | VLESS+TCP+TLS | 540 Mbps | 328 Mbps | 48 ms | 中 | | VLESS+WS+TLS | 390 Mbps | 214 Mbps | 56 ms | 强 | | Hysteria2 | 920 Mbps | 687 Mbps | 30 ms | 中（UDP易被QoS） | | SS-2022 | 610 Mbps | 376 Mbps | 41 ms | 中偏弱 |

“但你别只看数字，”老周敲了敲桌子，“差距的来源分三层。”

5.1 第一层：协议栈开销

TCP+TLS需要三次握手加TLS握手，WebSocket还要额外一次HTTP升级。Hysteria2基于QUIC，0-RTT或1-RTT就能开始传数据。在测速这种短时间高吞吐场景下，握手开销被放大得很明显。

5.2 第二层：拥塞控制与丢包恢复

老周用tc模拟了5%丢包。结果：

• VLESS+TCP+TLS：吞吐从540Mbps掉到90Mbps，因为CUBIC把丢包当成拥塞信号，疯狂降窗。
• Hysteria2：吞吐从920Mbps掉到410Mbps，Brutal算法直接忽略丢包，继续猛发。
• SS-2022：掉到150Mbps，AEAD加密下重传效率一般。

“这就是为什么很多人觉得‘晚高峰卡’，”老周说，“不一定是带宽不够，而是协议在丢包面前太‘老实’了。”

5.3 第三层：中间设备的态度

老周还发现一个现象：同样的VLESS+TCP+TLS，在电信宽带上跑328Mbps，在移动宽带上只有190Mbps。而Hysteria2在移动宽带上反而能跑到520Mbps。

“移动的QoS策略对TCP大流量更敏感，UDP反而松一些。”他解释道，“但这不是绝对的，某些地区UDP QoS更狠，Hysteria2直接连不上。”

六、老周的实战建议：别问哪个协议最好，先问你要什么

测完最后一组数据，老周把咖啡一饮而尽，说了几句实在话：

“如果你只是在家里看4K视频，VLESS+TCP+TLS够用，别折腾。如果你要打游戏、开视频会议，Hysteria2的低延迟优势明显。如果你在公司内网，需要过防火墙，WebSocket+TLS最稳。如果你追求极致速度且不在乎CPU，Hysteria2是当前版本答案。”

他顿了顿，又补了一句：“但别忘了，协议只是工具。真正决定体验的，是服务端的位置、线路质量、以及你的运营商。同一台东京VPS，电信和联通跑出来的数字能差一倍。”

我问他：“那你最后给老板推荐了哪个？”

他笑了笑：“我给他配了Hysteria2做主通道，VLESS+WS+TLS做备用。白天用Hysteria2，晚上如果UDP被限速，自动切WebSocket。老板只关心能不能连上，我关心的是别半夜再被电话吵醒。”

凌晨三点，老周关掉测速窗口，屏幕上还留着最后一行数字：Hysteria2，687Mbps。他伸了个懒腰，说：“协议之间的差距，有时候比人和人之间的差距还大。但好消息是，你有的选。”

窗外的城市已经安静下来，只有路由器上的指示灯还在闪烁。那些跳动的数字背后，是协议栈里无数次的握手、加密、重传和妥协。而老周终于可以回去睡觉了——至少今晚，不会再有人抱怨网速慢了。