Article · 测速指标:延迟、吞吐、丢包与 UDP NAT · 延迟类指标解读

TLS RTT 和普通 RTT 有什么不同:为什么同一节点两个数相差很多

TLS RTT 通常把 TCP 握手与 TLS 握手一起计时,普通 RTT 只计一次往返,所以同一节点的 TLS RTT 明显更大是正常的。本文按测量口径拆解两者的计时范围、合理差距的判断思路,以及本站两套测速界面为何不能混比。

发布 最近更新 品牌资料整理日期 搜索意图 信息

差距来自计时范围:TLS RTT 多算了握手

同一个节点上,TLS RTT 明显大于普通 RTT,大多数情况下是测量口径造成的,而不是节点变差。普通 RTT 通常只计一次“发出—返回”;TLS RTT 则一般从发起连接开始计时,直到 TLS 握手完成,中间至少包含 TCP 建连与 TLS 协商两段往返,还叠加了加密运算与证书处理时间。

因此,判断两个数“差得正不正常”,要先看清各自从哪里开始、到哪里结束,而不是直接比较数值大小。本文是 测速指标:延迟、吞吐、丢包与 UDP NAT 下的口径说明,所在二级专题页为 测速指标专题。

普通 RTT 的几种测法

“RTT”这个词在不同工具里可能对应不同的测法。常见的有三类:

测法 计时起止 特点
ICMP Ping 发出回显请求到收到回显应答 只到入口服务器;部分服务器会降低 ICMP 优先级或直接不响应
TCP 连接计时 发出 SYN 到收到 SYN-ACK 一次往返,比 ICMP 更接近真实连接,但不含加密
经代理的往返 通过节点发出请求到收到首个响应 包含代理转发路径,数值通常更大

很多测速工具把“延迟 RTT”定义为多次 Ping 的统计值,例如多次测量后取平均或中位数。本站截图中采用 MAI-TEST-BOT 界面的那一套,按 brands.ts 记录的测试条件为“Ping 5 次”,指标名为延迟 RTT 与 HTTP 延迟,具体计算方式以图内底栏为准。

TLS RTT 额外计入了哪些步骤

TLS RTT 的常见计时方式,是从开始建立连接一直算到 TLS 握手完成。拆开来看,可能包括:

  1. TCP 三次握手:客户端发 SYN,服务器回 SYN-ACK,计为一次往返。
  2. TLS 协商:客户端发送 ClientHello,服务器返回证书与密钥参数。TLS 1.3 在常见情况下需要一次往返,TLS 1.2 通常需要两次往返。
  3. 证书校验与密钥计算:属于本地和服务器的计算开销,网络往返之外的时间也被计入。
  4. 工具自身的处理时间:包括调度、并发排队等,具体取决于实现。

用一个理论下限来理解:如果某条路径的单次往返时间为 R,那么“TCP 建连 + TLS 1.3 握手”至少需要约 2R,“TCP 建连 + TLS 1.2 握手”至少需要约 3R。也就是说,在其他条件理想的情况下,TLS RTT 是普通 RTT 的两到三倍左右都在合理区间;再加上计算与排队开销,实测比值更大也很常见。这只是帮助判断的估算思路,不同工具的计时细节以其说明为准。

协议层面的握手差异(例如 VLESS 依赖外层 TLS、Shadowsocks 在协议内部加密)属于另一个话题,本文不展开,原理请看 代理协议:VLESS、Trojan 与 Shadowsocks。

差距多大才值得留意

既然两个数天然不同,怎样判断差距是否异常?可以用下面的思路代替比较绝对值:

观察到的现象 更可能的解释 建议动作
TLS RTT 约为普通 RTT 的两到三倍,多次测量稳定 正常的握手开销 无需处理
比值远高于三倍,但只出现一次 偶发排队、证书处理慢或瞬时拥塞 重复测量后再判断
比值持续偏高,同地区其他节点没有这种情况 该节点握手环节耗时较长 换同地区节点对照,记录时段
两个数都很高且同步波动 路径本身拥塞,与口径无关 关注时段因素与丢包
TLS RTT 显示超时,普通 RTT 正常 握手失败,可能是配置或证书问题 转到客户端排查

表中所有判断都要求“同一工具、同一时段、多次测量”。单次截图里的比值只能说明那一刻的情况。

本站两套界面为什么不能混比

本站在各品牌页发布的测速截图,按 brands.ts 的记录分属两套测试条件:

  • MAI-TEST-BOT 界面:测试后端珠海联通 5Gbps,32 线程,Ping 5 次,延迟指标为 RTT 与 HTTP 延迟;
  • 主端/喵速界面:测试后端珠海联通 9Gbps,32 线程,延迟指标为 TLS RTT 与 HTTPS 延迟。

使用主端/喵速界面的有三张:宇宙云、快狸和微风网络(微风网络属于 2026-07-19 的另一批次)。其余品牌的截图使用 MAI-TEST-BOT 界面。由于 TLS RTT 天然包含更多步骤,把宇宙云截图里的 TLS RTT 与另一品牌截图里的普通 RTT 放在一起比较,得出的“谁延迟更高”没有意义。本站正文不转写这些数值,读者可以在 宇宙云品牌页的测速报告 或 快狸品牌页的测速报告 查看原图和条件说明。

两套界面之间其他口径的差异,例如后端带宽和延迟类型,在 两套测速界面的口径差异 中有更完整的对照。

在自己的测试里避免混记两种 RTT

如果你自己动手测速,建议按下面的方式记录,避免日后对照时混淆:

  1. 在记录表的指标列写全名称,例如“TLS RTT”或“ICMP RTT”,不要只写“延迟”。
  2. 同一轮比较只使用一种工具和一种指标,中途更换工具就重新开一张表。
  3. 每个节点至少测量多次,记录中位数和波动范围。
  4. 同时记下协议类型。同为 TLS RTT,不同协议和传输方式的握手开销也不同。
  5. 遇到超时,原样记录,不要用重试成功的那次替换掉。

完整的自测流程与记录项,可以参考 自己动手测速的方法。

围绕两种 RTT 的疑问

关于“比普通 RTT 大好几倍是否异常”:按前面的理论下限,两到三倍属于常见范围;计算与排队开销会让比值继续变大。只有在可重复的条件下持续异常,才值得把它当作节点问题看待。

关于本站截图的两种延迟:这是工具口径不同造成的,不代表品牌之间的差异,也不能据此推断线路类型。

关于该记哪一个:选定一种并保持一致即可。如果节点走 TLS 封装,TLS RTT 更接近每次新建连接的实际等待。

测速与使用机场服务时,请遵守所在地法律法规与平台条款。

常见问题

TLS RTT 比普通 RTT 大好几倍,是节点有问题吗?

不一定。TLS RTT 通常包含 TCP 建连和 TLS 握手,至少相当于两次往返,再加上加密计算和证书处理,数值明显更大属于口径差异。只有在同一工具、同一时段多次测量时差距持续异常扩大,才值得进一步排查。

本站的测速截图为什么有的显示 RTT,有的显示 TLS RTT?

本站发布的截图来自两套测速界面。按 brands.ts 记录,MAI-TEST-BOT 界面显示延迟 RTT 与 HTTP 延迟,主端/喵速界面显示 TLS RTT 与 HTTPS 延迟。两者计时范围不同,因此不同界面的截图之间不能比较延迟高低。

自己测试时应该记录 RTT 还是 TLS RTT?

两者都可以,关键是整个测试周期只用一种口径,并在记录表里写明指标名称和工具。如果你的节点使用 TLS 封装,TLS RTT 更贴近建立连接时的实际等待。

文中提到的品牌

以下品牌在本文中作为资料示例出现(依据品牌资料,不是排名)。注册入口为推广链接,可能包含邀请码。

宇
宇宙云
14.9 元/月(月付价)· 100GB
15 元档 / VLESS / IEPL / 性价比

注册/推广链接:可能包含邀请码,本站可能因此获得佣金;不改变本站数据标注规则。套餐与价格以官网实时页面为准。披露说明

狸
快狸
25 元/月(月付价)· 150GB
25 元档 / 150GB / 综合型 / VLESS / IEPL

注册/推广链接:可能包含邀请码,本站可能因此获得佣金;不改变本站数据标注规则。套餐与价格以官网实时页面为准。披露说明

微
微风网络
约 7 元/月(年付折算)· 50GB
低价小流量 / 年付 / IEPL / 轻度用户

注册/推广链接:可能包含邀请码,本站可能因此获得佣金;不改变本站数据标注规则。套餐与价格以官网实时页面为准。披露说明

来源与更新

品牌字段来自本站品牌数据文件(整理自 2026-09-04 品牌清单,Vendor Data,官网待核实);测速截图为 2026-10-18 复核后发布的单次 Measured Data;AI 与流媒体均为 Not Tested。发布 2026-10-18,最近更新 2026-10-18。本页不承诺任何平台的收录、排名或引用。