外观
延迟指标：ICMP、TCP 与 HTTP 延迟的区别
三种延迟测的不是同一件事：ICMP 延迟反映网络层往返时间，TCP 延迟反映建立传输层连接所需的时间，HTTP 延迟包含发出请求到收到响应的整个过程。比较两个数字之前，先确认它们是同一种延迟，否则对比没有意义。
本站所有品牌延迟字段当前均为 Not Tested。
核心结论与适用条件
- 如果你看到一个“延迟”数字，那么先问它是 ICMP、TCP 还是 HTTP，是否包含域名解析，是冷连接还是热连接。这四个问题决定了数字的含义。
- 如果 ping 与实际体验不一致，那么这是正常现象：ping 只覆盖链路的底层部分，不包含握手与服务端处理。
- 如果你要比较两个节点，那么必须使用同一种延迟、同一个目标、同一时段，并记录多次样本，参考本站测速协议的整体口径。
- 如果你只想选一个指标，那么对代理使用场景，通常 HTTP 或 TCP 计时更接近真实体验，ICMP 更适合做链路是否连通的快速判断。这是通用方法上的倾向，不是对任何品牌的评价。
- 如果你想知道某个品牌的延迟，那么本站目前没有数据，全部为 Not Tested。
适用边界：本页讲通用测量原理，不涉及具体软件的菜单与默认设置，也不给出任何速度或延迟数值。读者应在自己的网络中测量并记录。
延迟是什么：先把“往返”说清楚
延迟指一个数据包从发出到收到对应回应所花的时间，通常以毫秒计。严格说，日常说的延迟大多是“往返时间”，包含去程、对端处理和回程三部分。影响它的因素可以分成四类：
- 物理距离与线路路径：数据要经过多少跳、走了什么样的路由。
- 链路拥塞：途中某一跳排队，会让数据包等待。
- 对端处理：服务器接收并回应所花的时间。
- 本地因素：Wi-Fi 重传、设备繁忙、系统调度。
这四类因素在不同类型的延迟里权重不同。ICMP 延迟主要受前两类影响，HTTP 延迟则把后两类也算了进来。这就是为什么同一个节点上三种延迟可以差别很大。
三种延迟的对照表
| 指标 | 单位 | 测量层次 | 包含的环节 | 常见干扰 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| ICMP 延迟 | ms | 网络层 | 一次回声请求与应答的往返 | 目标可能屏蔽或限速 ICMP | 多次探测取分布，注明目标 | 读者或本站测量 | 2026-10-18 |
| TCP 延迟 | ms | 传输层 | 三次握手完成所需时间 | 握手被中间设备处理、端口策略 | 对固定端口多次握手计时 | 读者或本站测量 | 2026-10-18 |
| HTTP 延迟 | ms | 应用层 | 请求发出到响应到达，可能含解析与加密握手 | 服务端处理、缓存、冷热连接 | 注明是否含解析、是否复用连接 | 读者或本站测量 | 2026-10-18 |
| 当前全部品牌 | — | — | — | — | Not Tested / 待核实 | — | 2026-10-18 |
这张表的重点在“包含的环节”一列。越往应用层走，包含的环节越多，数字通常越大，也越接近用户的真实感受，但同时受影响的因素更多，数字更不容易归因。
逐层拆解：每种延迟到底测了什么
ICMP 延迟：最底层的探路
ICMP 是网络层的控制消息协议，常见的 ping 就基于它：发出一个回声请求，等待对端回应。它的优点是简单、快速，几乎不依赖具体应用，适合判断“这个地址在网络上是否可达”。
它的局限同样明显。第一，部分网络设备或服务器会屏蔽或限速 ICMP，ping 不通不代表服务不通。第二，ICMP 数据包与实际业务流量可能走不同的处理路径，低延迟的 ping 并不保证业务流量同样快。第三，对于经过代理的情况，ping 目标往往是代理服务器本身，测到的是你到代理入口的往返，而不是你通过代理到目标网站的往返。
TCP 延迟：握手需要多久
TCP 延迟通常用三次握手的耗时来衡量：发送连接请求，收到确认，再确认。它测的是传输层，比 ICMP 更接近真实业务流量，因为大多数应用都建立在 TCP 之上，而且握手需要对端真实地接受连接。
TCP 延迟能暴露一些 ICMP 看不到的问题，比如某个端口被限制、握手需要重试。它也适合在 ICMP 被屏蔽时作为替代。需要注意的是，握手成功只说明连接可以建立，不说明后续传输顺畅。
HTTP 延迟：一次请求的总耗时
HTTP 延迟最贴近网页访问的体验。它可能包含域名解析、传输层握手、加密握手、请求发出、服务端处理以及首字节返回等环节，具体包含哪些取决于测量工具和是否复用连接。
正因为包含的环节多，HTTP 延迟的读数必须附带条件：目标是什么、是否复用连接、是否含解析。同一个节点，首次请求和后续请求的耗时可能相差很大，因为后续请求可以复用已建立的连接。把冷连接和热连接的数字混在一起比较，是常见的错误。
三者之间为什么会“打架”
出现下面几种情况时，三种延迟会给出看似矛盾的结论，其实各有原因：
- ICMP 很快、HTTP 很慢：链路本身通畅，但服务端处理慢、加密握手耗时或目标站点本身响应慢。
- ICMP 不通、HTTP 正常：目标屏蔽了 ICMP，不代表线路有问题。
- TCP 握手快、HTTP 偏慢：连接容易建立，但请求处理或内容返回耗时较长。
- 平均延迟相近、体验差别大：抖动不同，需要看分布而不是平均值。
经过代理时延迟怎么算
测代理延迟比测直连复杂，因为路径多了一段。一次通过代理的访问大致分为：本地到代理入口、代理入口到落地节点、落地节点到目标站点。
不同的测量方式覆盖的路段不同：
| 测量方式 | 覆盖的路段 | 容易误解的点 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 直接 ping 代理服务器地址 | 本地到代理入口 | 不包含落地到目标的部分 | 读者测量 | 2026-10-18 |
| 客户端内置延迟测试 | 通常是通过代理访问某固定地址 | 目标地址与计时方式因客户端而异，需查文档 | 读者测量 | 2026-10-18 |
| 通过代理访问目标并计时 | 完整路径 | 包含目标站点的响应速度 | 读者测量 | 2026-10-18 |
本站不对具体客户端的内置测试实现下断言，因为不同客户端、不同版本的做法可能不同。读者应在设置中找到延迟测试相关选项，并查看其说明；记录结果时写明客户端名称，并把它视为一种特定口径，而不是普适的“延迟”。若想了解测速时有哪些公开工具及其适用的指标，可以继续阅读测速工具的选择与局限。
协议层带来的额外环节
代理协议本身也会引入额外的握手与封装。例如使用基于 TLS 的传输时，首次连接需要完成加密握手；使用多路复用时，后续请求可能复用同一条连接，从而降低首字节延迟。这些属于协议原理层面的通用知识，具体表现取决于客户端与服务端的实现和配置，本站不给出任何数值。关于协议的原理，可以回到协议与传输层的通用说明。
几个让数字失真的变量
域名解析
如果测试目标是域名，则解析时间可能混入读数。第一次解析慢、之后有缓存而变快，会让同一个目标在不同时间读数不同。要排除这一变量，可以改用固定地址，或者在记录里注明是否包含解析。
冷连接与热连接
冷连接指第一次建立连接，需要完整的握手流程；热连接指复用已有连接，省去部分环节。测试时应固定一种，并在记录里写明。如果两种都想了解，应分别记录，不要混合。
抖动与分布
单次读数没有太大意义。同一条线路连续多次测量，延迟会上下波动，这种波动称为抖动。抖动大的线路，即使平均值不高，实时语音、视频会议或在线游戏的体验也会很差。记录时保留每次样本，再看范围和最差值，细节参考样本方差与分布的读法。
时段与拥塞
晚高峰期间链路更容易排队，延迟会出现不同于平时的特征。同一节点要在晚高峰与非高峰分别采样，不能合并求平均。
本地网络
Wi-Fi 信号弱、重传多，会把延迟拉高并增加抖动；设备资源紧张也会影响计时精度。测量前应先测一次不开代理的本地基线，详见本地网络如何影响测速读数。
延迟与体验：不同场景关心什么
| 使用场景 | 更关心的延迟特征 | 同时需要关注的其他指标 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 网页浏览 | 首字节延迟、多个小请求的累计耗时 | 丢包、解析时间 | 通用技术资料 | 2026-10-18 |
| 视频播放 | 起播延迟影响较小，持续下载更重要 | 下载速率、丢包 | 通用技术资料 | 2026-10-18 |
| 语音与视频通话 | 低延迟与低抖动 | 丢包 | 通用技术资料 | 2026-10-18 |
| 在线游戏 | 低延迟与低抖动 | 丢包 | 通用技术资料 | 2026-10-18 |
| 大文件下载 | 延迟影响较小 | 下载速率、连接稳定性 | 通用技术资料 | 2026-10-18 |
| AI 工具与流媒体 | 品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准 | 取决于具体操作 | 品牌公开资料/用户提供清单 | 2026-10-18 |
这张表说明，延迟的重要性因场景而异。看视频时，延迟本身很少是瓶颈；打语音电话时，延迟与抖动却是核心。所以评估线路时，应先想清楚自己的使用场景，再决定看哪项指标。
记录延迟的模板与示例口径
要让延迟数字可以被他人对照，记录时至少要有下面这些字段。表中没有任何真实数值，仅说明每一列应当写什么。
| 字段 | 应当写什么 | 为什么需要 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 测试时间与时段 | 日期、时刻、晚高峰或非高峰 | 延迟随时段变化，没有时间的数字无法判断是否过期 | 测试者记录 | 2026-10-18 |
| 节点 | 客户端显示的节点名 | 同一品牌不同节点差异可能很大 | 测试者记录 | 2026-10-18 |
| 延迟类型 | ICMP、TCP 或 HTTP | 三者含义不同，不能混比 | 测试者记录 | 2026-10-18 |
| 测试目标 | 域名或固定地址，位置大致在哪 | 目标不同，路径不同 | 测试者记录 | 2026-10-18 |
| 是否含解析 | 是或否 | 解析时间可能混入读数 | 测试者记录 | 2026-10-18 |
| 连接状态 | 冷连接或复用连接 | 首次与后续请求耗时不同 | 测试者记录 | 2026-10-18 |
| 样本分布 | 每次读数，而非只有平均值 | 抖动要看分布才能发现 | 测试者记录 | 2026-10-18 |
| 本地基线 | 不开代理时同类目标的延迟 | 区分本地因素与线路因素 | 测试者记录 | 2026-10-18 |
| 数据状态 | Measured Data 或 Not Tested | 说明数据来源 | 本站规则 | 2026-10-18 |
示例口径：假设有两位读者各自发布了“某节点延迟”，甲写的是对固定地址做 TCP 握手计时，乙写的是通过代理访问某个网页的 HTTP 计时。两人的数字不应被放在一起比较，除非先把它们换成同一种类型。这里的关键不是谁的数字大，而是两人是否在回答同一个问题。再假设丙在记录里同时给出了本地基线，那么丙的数字就能被读者放在上下文里理解：线路的表现与本地网络的表现，各占多少，一目了然。以上情形均为假设，没有任何数值。
常见误读与更正
把客户端里的延迟数字当成“速度”
客户端节点列表里常见的延迟数字，很容易被理解为这个节点“快不快”。它只是一次计时的结果，不包含下载速率，也不包含持续使用中的波动。把它当成综合评分，会忽略丢包和带宽的作用。
把一次读数当成稳定值
同一个节点连续点几次延迟测试，读数往往不同，有时差别明显。如果只截取数字最漂亮的一次，等于选择性展示。多次读数的范围，比任何一个单点都更有信息。
用 ICMP 结果否定整条线路
ICMP 被屏蔽或被限速时，ping 的结果会很差或根本没有响应，这并不说明业务流量也受影响。遇到这种情况，应改用 TCP 或 HTTP 计时复核，再下结论。
用 HTTP 结果归因于线路
HTTP 延迟包含目标站点自己的响应时间。如果目标站点当时负载较高，HTTP 延迟会升高，但线路本身可能没有问题。要区分两者，可以对不同目标各测一次，看是否只在某个目标上偏高。
忽略时段差异
在非高峰测到的数字，不能用来说明晚高峰的表现。反过来也一样。两个时段的数字应当分开陈述。
当三种延迟互相矛盾时怎么排查
遇到矛盾读数，可以按下面顺序排查，而不是直接下结论。
- 确认类型一致：比较的是否是同一种延迟。不同类型的数字本来就不该放在一起比较。
- 确认目标一致：是否对同一个目标测量，目标的位置与负载是否相近。
- 确认连接状态：是冷连接还是复用连接，首次请求通常会更慢。
- 确认是否含解析：域名解析耗时是否被算进去了。
- 确认时段：两次测量是否处于同一类时段。
- 确认本地基线：测量期间本地网络是否出现波动，可比较测试前后的基线。
- 增加样本：把样本数增加，看矛盾是否只是偶然噪声。
如果七步之后矛盾依然存在，才有理由怀疑节点本身的问题，并且结论仍应限定在“所记录的时间与节点”。需要进一步了解测速本身怎样组织时，可以回到本站测速协议的时段与样本规则。
品牌宣传里的延迟表述怎么读
品牌资料里可能出现“低延迟”“高速线路”之类的描述。按本站口径，这类内容归入 Vendor Data，读的时候要问四个问题：
- 它说的是哪一种延迟，ICMP、TCP 还是 HTTP？
- 对哪个目标、在哪个时段测的？
- 是单次读数还是多次的分布？
- 有没有给出可以复现的方法？
大多数宣传表述回答不了这四个问题，所以只能作为了解品牌定位的线索，不能代替测量。更系统的做法见数据解读集群中关于品牌资料表述的文章，也可以先在选型清单里把“延迟表述的口径”作为一项核对内容。
为什么延迟数字不能直接换算成“快慢”
最后补充一个常见的思维陷阱：把延迟数字线性地换算成快慢感受。人对延迟的感受并不是线性的。低于某个感知阈值的差别，用户几乎察觉不到；而一旦出现偶发的长尾，即少数请求耗时远高于多数请求，用户却会明显感到卡顿。所以相比平均值，长尾和抖动往往更能解释“为什么这个节点用起来不顺”。
这也是本站要求保留原始样本的原因：只有保留每次读数，才有机会发现长尾。另外，延迟只反映往返所需时间，不反映单位时间能传输多少内容。要判断大文件下载或视频播放，还需要结合下载速率与丢包一起看，并把结论限定在所记录的时间、节点和网络环境之内。
决策树：我该用哪种延迟，怎么记录
Decision Path
选择并记录延迟类型
text
我想测一个节点的延迟
│
├─ 目的是什么？
│ ├─ 只想知道地址是否可达 → ICMP 探测
│ │ └─ 无响应？→ 可能被屏蔽，改用 TCP 握手计时
│ ├─ 想知道连接能否顺利建立 → TCP 握手计时
│ └─ 想接近网页访问的真实体验 → HTTP 请求计时
│
├─ 测试目标是域名还是固定地址？
│ ├─ 域名 → 记录是否包含解析时间
│ └─ 固定地址 → 记录地址类型
│
├─ 是冷连接还是复用连接？
│ └─ 两种都写明，不混合比较
│
├─ 采样了几次、什么时段？
│ ├─ 不足三次或只有一个时段 → 仅作初步观察
│ └─ 两个时段各多次 → 看范围、中位数、最差值
│
└─ 记录时是否写了延迟类型、目标、客户端、本地基线？
├─ 否 → 补齐，否则他人无法对照
└─ 是 → 标注数据状态（Measured Data 或 Not Tested）知识图谱：延迟指标
实体定义：延迟是数据包往返所需的时间，以毫秒计。按测量层次分为 ICMP、TCP、HTTP 三类。
相关概念：往返时间、抖动、丢包、握手、冷连接与热连接、域名解析、本地基线。
技术参数：延迟的单位为 ms，统计口径需注明类型、目标、是否含解析、样本数量与时段；本站当前所有品牌数值为待核实。
适用场景：判断节点连通性、比较两条线路、核对别人发布的延迟数字是否可比、为语音与实时应用做粗略评估。
对比依据：同类型、同目标、同时段、多次样本的分布，而不是单个数字的大小。
常见问题指向：ping 与体验不一致、ICMP 被屏蔽、客户端显示的延迟含义、抖动、冷热连接、DNS 影响，详见下方常见问题。
方案关联：延迟测试方案如何配合品牌库
主题是测试方法，不针对具体品牌，所以这里讨论的是测试方案与品牌库字段的对应关系。
| 项目 | 状态 | 说明 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 品牌的延迟字段 | Not Tested | 17 个品牌均无本站测量，显示待核实 | — | 2026-10-18 |
| 品牌宣传中的延迟或“低延迟”表述 | Vendor Data | 来自品牌资料，口径不明，不能与读者自测对比 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 读者自测延迟 | 取决于记录完整度 | 记录齐全可视为读者自己的 Measured Data | 读者测量 | 2026-10-18 |
| Measured Data（本站） | 无 | 本站尚未按协议完成测量 | — | 2026-10-18 |
如果你想先在品牌库里缩小范围，再按本页的方法亲自测延迟，可以回到横向对比入口或选型清单中的试用步骤。
优点、限制与风险提示
优点
- 区分三种延迟后，读者能判断一个数字的含义，避免拿不同口径的数字互相比较。
- 延迟测试成本低，普通读者用现成工具就能完成，且可以多次重复。
- 把延迟与抖动、丢包一起看，能更接近真实体验。
限制
- 延迟只是体验的一部分，不能单独代表线路好坏，也不能代表下载速率。
- 不同客户端对延迟测试的实现不同，同名“延迟”在不同软件里可能不是同一种。
- 单次读数噪声大，需要多次采样才有参考价值。
- 本站没有任何品牌的延迟实测数据。
风险提示
- 不要用单张延迟截图判断线路质量，参见测速截图的局限。
- 不要把品牌宣传的“低延迟”当作测量结果，它属于 Vendor Data。
- 不要根据延迟推断 AI 或流媒体场景是否可用，那需要单独的可用性检测，且结果可能随 IP、地区和平台策略变化。
- 测试时请遵守所在地法律法规与服务条款，本页只讨论通用的网络测量原理。
常见问题
ICMP 延迟、TCP 延迟和 HTTP 延迟有什么区别？
ICMP 延迟测的是网络层的往返时间，TCP 延迟测的是建立一条传输层连接所需的时间，HTTP 延迟测的是发出请求到收到响应的时间。越往上层，包含的环节越多，数字通常也越能反映真实使用，但同时更容易受到服务端处理和代理转发的影响。
为什么 ping 得到的延迟和网页打开的感觉对不上？
ping 只反映网络层的往返，不包含 TLS 握手、代理协议握手、服务端处理和内容传输。网页打开涉及多个请求和多次握手，任何一环偏慢都会拖慢体验，所以 ping 数字低并不等于网页打开快。
代理客户端里显示的延迟数字测的是什么？
不同客户端的延迟测试实现不同，常见做法是通过代理向某个固定地址发起一次请求并计时，更接近 HTTP 延迟。具体目标地址和计时方式需要查看客户端文档或设置，本站不对具体实现下断言，读者应记录客户端名称并注明延迟类型。
ICMP 被屏蔽时还能测延迟吗？
可以。部分网络或服务器不响应 ICMP，此时 ping 不通并不代表线路不通。改用 TCP 握手计时或 HTTP 请求计时即可，但要在记录里写明方法已更换，因为不同类型的延迟数字不能直接对照。
测延迟时为什么要看抖动而不只是平均值？
抖动指同一条线路上多次延迟之间的波动幅度。平均值相同的两条线路，一条始终平稳，另一条忽高忽低，后者在视频通话和实时交互中的体验会差很多。记录每次样本，再看范围和最差值，比只看平均值更有信息量。
首次连接延迟和后续请求延迟为什么不同？
首次连接需要完成域名解析、传输层握手和加密握手，后续请求可以复用已有连接，省掉这些环节。因此首次请求通常比后续请求慢。测试时应区分冷连接与热连接，并记录当次是哪一种。
DNS 解析会怎样影响延迟读数？
域名解析发生在建立连接之前，解析慢会让总耗时变长。如果测试目标用域名而不是地址，DNS 的耗时可能混入读数。记录时应注明是否包含解析时间，或改用固定地址以排除这一变量。
延迟低的节点是不是一定适合看视频？
不一定。视频更依赖持续的下载速率和较低的丢包，延迟只是其中一个因素。延迟低而丢包高或带宽受限的线路，视频仍可能卡顿。具体可用性及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准。
本站现在公布了哪些品牌的延迟数据？
没有。17 个品牌的延迟字段全部为 Not Tested，显示待核实。本页只讲三种延迟的含义和记录方式，示例口径中没有任何真实数值，任何品牌宣传中的延迟表述属于 Vendor Data，不能当作测量结果。
读者自己记录延迟时，最少要写哪些信息？
至少写测试时间、时段、节点、延迟类型、测试目标、是否包含解析时间、客户端名称，以及不开代理的本地基线。缺少延迟类型和目标的数字，别人无法判断它与自己的结果能否对比。
延伸阅读与下一步
Cluster · method
测试方法
- 本站测速方法：时段、节点、工具与样本本站计划如何进行测速，口径是什么？
- 延迟指标：ICMP、TCP 与 HTTP 延迟的区别不同延迟测试方式测的是什么？
- 下载测速工具对比与误差来源常用测速工具的结果为什么不一致？
- 丢包率测试方法与解读如何测丢包率，多少算正常？
- 晚高峰采样：为什么单次测速不够为什么需要多次、分时段测速？
- 服务可用性测试：AI 与流媒体的检测口径AI 和流媒体的可用性应该怎么测？
- 数据状态标签说明：从 Operational 到 Measured Data本站的数据状态标签分别代表什么？
- 想回到专题总览，可以看测试方法与数据说明专题首页。
- 想看完整的采样与记录流程，可以看本站测速协议。
- 想知道哪些公开工具适合测哪些指标，可以看测速工具的选择与局限。
- 想了解为什么单张截图不够，可以看测速截图的局限。
- 想了解状态标签的含义，可以看七个状态标签的定义。
- 想先缩小候选范围，可以回到横向对比入口，或选型清单看价格口径与适用场景。
- 想了解路由层面的背景知识，可以看线路与路由的通用原理。
- 想查看品牌资料全貌再决定测哪些节点，可以进入品牌库；需要固定节点时参考桌面端客户端的设置说明。
信息来源与更新日期
- 信息来源：通用技术资料；品牌公开资料/用户提供清单。
- 数据核实日期：2026-10-18。
- 最近更新时间：2026-10-18。
- 说明：本页不含任何实测数字；所有品牌当前均为 Vendor Data，延迟为 Not Tested。