如何测量网络延迟：开发者实用指南

想要测量网络延迟？你可以从简单的内置命令行工具入手，比如 ping 和 traceroute，快速获取 往返时间 (RTT) 的大致数据。或者，你可以打开浏览器开发者工具，查看延迟如何影响用户的实际体验。

这些方法能为你提供数据包从源点发出、到达目的地并返回所需时间的快速而有用的快照。

为何测量延迟至关重要

在我们深入探讨“如何做”之前，先聊聊“为什么”。对于开发者和网络工程师而言，延迟不仅仅是屏幕上的一个数字；它是塑造整个用户体验的无形之手。在当今的应用中，毫秒之差至关重要。即使微小的延迟，也可能让一个服务感觉是瞬时响应的，或者感觉是故障的。

想想其现实影响：

• API 响应性： 一次缓慢的 API 调用可能会引发连锁反应，阻塞从加载用户资料到处理关键支付的所有操作。
• 实时数据流： 对于在线游戏、直播视频或金融交易来说，低且稳定的延迟是绝对的基础。没有它，这些应用根本无法运行。
• 用户留存率： 加载缓慢的网站和应用与较高的跳出率和放弃的购物车之间存在直接联系。这会严重打击营收。

区分关键延迟概念

要准确测量网络延迟，你必须清楚你在测量什么。两个最基本的概念是 往返时间 (RTT) 和 单向延迟.

RTT 是指信号从 A 点到 B 点 再返回 的总时间。这是你最常见的指标，因为它测量起来很直接——你只需访问连接的一端即可。

单向延迟，顾名思义，测量的是数据仅在一个方向上传输所需的时间。这种测量要准确得多，因为它要求两端的时钟完美同步。然而，对于上传和下载路径行为差异很大的非对称连接来说，它是更精确的指标。

当你进行严肃的 负载性能测试 时，所有这些的重要性就会变得一目了然——这正是理论与现实交汇、瓶颈暴露无遗的时刻。

具体量化来说，网络监控专家通常这样对延迟进行分类：

• 低延迟： 低于 50 毫秒
• 中等延迟： 50-150 毫秒
• 高延迟： 超过 150 毫秒

根据我的经验，对附近服务器的快速测试可能显示完全可以接受的 20-40 毫秒。但对于必须跨越海洋的流量，该数字很容易飙升至超过 200 毫秒，这可能对你应用程序的性能产生决定性影响。

为了解您可能遇到的术语，这里提供一个快速参考。

核心延迟概念一览

等工具的首选指标。

概念	衡量什么	重要性何在
延迟 (Ping)	单个数据包从源到目的地再返回所需的时间。以毫秒 (ms) 为单位。	这是延迟的原始度量。对于游戏、VoIP 和视频会议等实时应用，低延迟至关重要。
往返时间 (RTT)	本质上与延迟相同，这是信号发送加上确认接收所需的总时间。	RTT 是从单点测量延迟最常用且最实用的方法，使其成为 ping.
单向延迟	数据包单向从源传输到目的地所需的时间。	提供更细致的视图，特别是在上传和下载路径具有不同延迟的不对称网络中。
抖动	延迟随时间的变化。它衡量数据包到达时间的不一致性。	对于流媒体和在线通话，高抖动与高延迟同样糟糕，会导致卡顿、缓冲和故障。
带宽	在给定时间内可以通过网络连接传输的最大数据量。以 Mbps 或 Gbps 为单位。	常被误认为是速度，带宽关乎容量。你可能有很高的带宽，但仍遭受高延迟之苦。

这些概念是理解任何网络性能问题的基础。

这就是拥有易用、集成化的工具变得如此重要的原因。无需运行复杂的诊断套件，现代浏览器扩展和开发工具就能让你无需离开工作流程即可获得所需洞察。关键在于让延迟测量成为构建和维护优秀软件过程中轻松、常规的一部分。

动手实践命令行延迟工具

要真正感受网络的性能，你必须打开终端。命令行里蕴含着能为你提供连接原始、未过滤数据的基础工具。这关乎看清你和目标之间移动的数据包究竟发生了什么，也是任何认真对待延迟测量的开发者必须迈出的关键第一步。

经典且首选的工具是 ping。它非常简单：向服务器发送一个微小的数据包（ICMP回显请求），然后等待其返回。这个简单的往返过程就是计算往返时间 (RTT)的基础，并能让你即时检查连接的健康状况。

使用 Ping 进行你的首次延迟检查

运行 ping 测试再简单不过了。打开你的终端或命令提示符，输入 ping，后面跟上你想测试的域名。

默认情况下，在 macOS 和 Linux 上，ping 会持续运行，而 Windows 只发送四个数据包就停止。要进行任何实际分析，你需要控制这一点。发送十个或二十个数据包能比仅发几个提供更可靠的连接稳定性概况。

完成后，你会得到一个包含关键数据的清晰摘要：

• 已发送/已接收数据包： 这告诉你是否有数据在传输过程中丢失。即使少量的数据包丢失也是网络问题的严重警示。
• 往返时间 最小值/平均值/最大值/平均偏差： 这是你的核心延迟统计数据。你能看到最佳情况时间（min）、平均值（avg）和最差情况时间（max）。mdev（平均偏差）是衡量 抖动的指标——即每个数据包之间的延迟变化程度。

请密切关注最小和最大RTT之间的差距。如果差距很大，即使平均值看起来正常，你的连接也可能不稳定。与持续稍慢的连接相比，这种抖动对实时应用（如视频通话或游戏）可能造成更大的干扰。

一个常见错误是只看平均RTT。平均值为 50ms 可能看起来不错，但如果你的最小值为 20ms，最大值为 250ms，用户体验将会感觉断断续续、不可靠。要理解抖动，必须查看完整的范围。

使用 Traceroute 和 MTR 追踪路径

那么，当 ping 显示高延迟或丢包时，你该怎么办？你的下一个任务是找出问题出在 哪里。这就是 traceroute（在 Windows 上为 tracert）的用途。它映射了你的数据包所走的完整路径，显示了从你的机器到最终目的地之间的每一个"跳数"——即每个路由器。

在 traceroute 输出中，每一行代表一个跳数，并且通常显示对该点进行的三次单独延迟测量。这使你能够精确定位路径上的某个特定路由器是否正在造成严重的减速或丢包。

但 traceroute 只是一个一次性的快照。为了更动态、连续地查看，我认识的大多数网络专业人士都极力推荐 MTR (My Traceroute)。MTR 就像一个增强工具，它结合了 ping 和 traceroute。它持续向路径上的每个跳数发送数据包，为你提供实时更新的、关于每个点的延迟和丢包情况的视图。这使得它在捕捉间歇性问题方面非常有效，而单个 traceroute 很可能会遗漏这些问题。

为什么工具的选择很重要

你选择的工具及其配置方式会极大地改变你的结果。这在像云数据中心这样的超高速、低延迟环境中尤其如此。

实际上，数字之间的差异如此之大，着实令人惊讶。在一个由 Google Cloud进行的详细实验中，一项标准 ping 测试报告显示平均 RTT 为 146 微秒。但当他们使用另一个连续发送交易而无停顿的工具时，RTT 降到了仅 66.59 微秒——速度提高了两倍多！

这正是一个完美例证，说明为何 ping 有时会高估延迟。它表明，理解 工具 的工作原理，对于获得可信的测量结果至关重要。

使用 iperf 测量网络连接的最高速率

延迟并非网络性能的全部。有时我们需要了解连接实际能够传输的最大数据量——即带宽。要完成这项任务， iperf.

虽然 ping 主要用于测量延迟， iperf 主要关注吞吐量。它的工作原理是建立一个客户端-服务器连接，然后在设定的时间内尽可能多地传输数据。

要使用 iperf，你需要两台机器：

1. 在一台机器上，你运行 iperf 以 服务器模式运行。它将仅在那里等待并监听连接。
2. 在另一台机器上，您运行 iperf 以 客户端模式运行，并指向服务器地址。

客户端将连接并开始测试。输出结果会显示传输的总数据量，最重要的是 比特率 （您的带宽）以兆比特或吉比特每秒为单位。这是对网络链路进行压力测试并了解其真实性能的绝佳方式。

从用户角度测量延迟

虽然命令行工具能为您呈现网络最原始、未经修饰的一面，但对于网络应用而言，唯一真正重要的延迟是最终用户实际体验到的延迟。因此，我们需要将关注点从终端转移到浏览器本身。浏览器内部发生的事情，能更丰富、更贴切地反映性能状况。

这从来都不只是关于单个数据包的往返过程。用户所 感知到的 延迟，是DNS查询、TCP握手、TLS协商、服务器处理时间，当然，还包括实际将内容渲染到屏幕上的时间，这众多因素交织而成的复杂混合体。所幸的是，现代浏览器内置了强大的工具，能帮助我们剖析这整个过程。

深入浏览器开发者工具

所有主流浏览器——Chrome、Firefox、Edge、Safari——都内置了一套开发者工具。其中的"网络"标签页是分析网站加载情况的核心控制台，它通过瀑布图将浏览器渲染页面时的所有请求以可视化方式清晰呈现。

这种瀑布图视角极具价值。从初始HTML文档、CSS样式表到图像和API调用，您可以精确查看每个资源下载耗时。更重要的是，它能将每个请求的生命周期分解为不同阶段：

• DNS查询： 域名解析为IP地址所需时间。
• 初始连接： 建立与服务器的TCP连接所耗时间。
• SSL/TLS握手： 建立安全连接所需的额外开销。
• 首字节时间（TTFB）： 这项指标尤为关键，它衡量浏览器等待接收服务器首字节数据的时长。
• 内容下载： 实际下载资源本身所花的时间。

例如，较高的TTFB通常预示着后端响应迟缓或服务器处理问题——这是简单的ping测试难以发现的。通过分析瀑布图，您可以快速识别哪些资源阻塞了页面渲染或加载耗时过长。

根据我的经验，关键不仅在于观察总加载时间，更要定位瀑布图中最长的条目。即使网站其他部分加载飞快，单张未优化的图片或缓慢的第三方API都可能拖累整个页面性能，导致用户体验不佳。

通过Timing API实现程序化测量

若要进行自动化精确测量，可以利用浏览器内置的JavaScript API。Navigation Timing API与Resource Timing API能让您以编程方式获取开发者工具中展示的详细性能数据。这非常适合收集真实用户监控数据，从而了解全球实际访问者体验到的网站性能表现。

仅需几行JavaScript代码即可在浏览器控制台中提取这些指标。例如，要获取主页面加载的核心性能计时，可使用performance.getEntriesByType('navigation')，该命令将返回包含宝贵时间戳的对象。

基于这些数据，可以计算关键指标：

• DNS查询耗时： domainLookupEnd - domainLookupStart
• TCP握手时间： connectEnd - connectStart
• 首字节时间（TTFB）： responseStart - requestStart
• 页面总加载时间： loadEventEnd - startTime

这种方法允许您构建自定义仪表板或向分析工具发送性能数据，从而持续掌握应用程序在真实环境中的性能表现。在网页开发中，优化图像是提升这些指标的常见方式；对此感兴趣的读者，可以参考我们的实用指南：如何为网站选择 最佳图像格式.

通过集成工具简化检查流程

在终端、浏览器开发者工具和自定义脚本之间来回切换很快就会令人厌倦。而集成式浏览器扩展可以通过统一这些检查来真正优化您的工作流程。例如，ShiftShift Extensions 套件内置了 Speed Test 工具，您可以从任何标签页立即调出它。

这为您提供了一种快速、注重隐私的方式来测量连接的下载速度、上传速度和延迟，无需导航到单独的网站或打开终端。由于它属于更大的工具集的一部分，您可以从同一个统一命令面板运行速度检查、格式化 JSON 响应并检查 cookie。这种集成使性能检查成为日常开发工作中自然且无障碍的一环。

如何设计一个真正能提供有效信息的延迟测试

任何人都可以执行 ping 命令并得到一个数字。但如果您想要可以真正信任的数据——能够帮助您做出实际决策的数据——您需要更加审慎。单一、孤立的测量只是一瞬间的快照。要真正理解网络行为，您需要像侦探一样思考，考虑测试地点、测试频率以及您真正要寻找的是什么。

设计良好的测试能将原始数字转化为可操作的见解。而设计不佳的测试？它只是噪音。

下图分解了所有导致用户加载网页时 感觉到 的微小延迟。这很好地提醒我们，简单的网络 ping 根本无法完全揭示整个过程。

如图所示，从最初的 DNS 查询到最后的渲染，多个步骤共同导致了总的等待时间。

选择测试端点

可靠测试的第一条规则是 地理位置至关重要。从您位于纽约的办公室到新泽西一路之隔的服务器进行测试，完全无法反映您在东京的客户的真实体验。要获得符合实际的评估结果，必须从能真实代表您用户群体的不同地点进行测试。

您的端点列表应覆盖几个关键区域：

• 您的主要用户集群： 您的大部分客户位于哪里？从那里开始测试。
• 跨洲路径： 观察数据跨越海洋时会发生什么。在欧洲与北美，或亚洲与美国之间进行测试，以了解长距离传输性能。
• 您的云区域： 如果您使用AWS、Azure或GCP，请测试与以下服务的连接 到 和 之间 你所依赖的特定数据中心区域之间。

通过这种方式分散测试，能创建出更精确的全球性能地图。它能帮助你发现那些原本会完全忽略的区域性瓶颈。这也是仔细检查你域名设置的好时机；你可以在 如何检查域名是否可用 及相关配置，以确保一切正常。

寻找合适的测试节奏

网络条件始终处于变化之中。它们会在一天、一周甚至一分钟内发生改变。周二凌晨3点的测试结果可能看起来很出色，但如果您的流量高峰出现在周五下午2点（那时所有人都在线），该结果就毫无用处。

为了获得真实的基准，您需要在一段时间内持续测试。可以这样操作：

• 在业务高峰期运行测试。
• 将部分测试安排在夜间维护时段进行。
• 别忘了周末，因为流量模式可能完全不同。

通过反复采样数据，可以平滑随机的高峰和低谷。这样就能发现重复出现的问题，比如网络每个工作日下午刚过午餐时间就会出现拥堵。

不要忘记抖动

平均延迟是一个可靠的起点，但它常常掩盖了一个更隐蔽的问题： 抖动。抖动就是 波动 你的延迟会随时间变化。试想一下——一个具有可预测 80ms 延迟的稳定连接，对于实时应用来说，通常比平均 50ms 但在 10ms 和 200ms.

对于任何实时应用，例如 VoIP 通话、视频会议或在线游戏而言，抖动是用户体验的隐形杀手。高抖动会导致音频卡顿、视频冻结以及令人沮丧的延迟峰值，即使平均延迟数据看起来很好，也会让应用感觉完全不可用。

理解抖动意味着要超越平均值。它是隐藏的罪魁祸首，因为它揭示了为何仅凭平均值会如此具有误导性。例如，来自 Pandora FMS 的数据显示，抖动超过 30ms 可能将游戏中的数据包丢失率提高到 15%——足以使游戏无法进行。测量延迟结果的标准差是量化这种不稳定性的第一步。

延迟测试设计检查清单

为了将所有内容整合起来，这里提供一个快速检查清单来指导您。遵循这些步骤将有助于确保您收集的数据既准确又真正有用。

清单项目	为何重要	可操作的建议
明确目标	无法衡量未定义的内容。您是在排查特定问题，还是建立基准？	在开始之前写下您的目标。例如“诊断东南亚用户的延迟问题”比“检查延迟”更明确。
选择多样化的端点	单一路径无法代表您的全球用户体验。	选择3-5个地点：一个本地，一个在另一大洲，还有几个在您关键用户市场。
建立定期测试	一次性测试会错过诸如高峰时段拥堵等时间性模式。	安排测试每小时自动运行一周，以捕捉完整的网络行为周期。
测量抖动	平均值会掩盖破坏实时应用的不稳定性能。	不要只看平均往返时间。计算标准差或使用像 mtr 这样的工具来显示最小/最大/平均延迟。
使用合适的工具	ping 适合快速检查，但像 mtr 或 iperf 这样的工具能提供更深入的洞察。	要优化网页性能，可以使用浏览器的开发者工具。对于原始网络路径， mtr 是一个绝佳的选择。
记录一切	六个月后，你很可能已经忘记当初测试的“初衷”。	建议保持一份简洁的日志：记录日期、时间、测试端点、所用工具，以及观察到的简要说明。

通过系统化的方法，你就能从单纯的延迟测量，转变为真正理解延迟。这种深思熟虑的方式，正是将一个随机数字转化为可靠性能指标的关键。

解读数字（以及需要避免的陷阱）

好了，你已经完成了测试并积累了一堆数据。现在真正的工作开始了——将这些原始数字转化为有意义的信息。数据正在讲述你网络健康状况的故事；你只需学会如何解读它。

例如，在某个traceroute上看到往返时间突然飙升，就是一个典型的线索。如果延迟在第三跳处激增并持续到终点，你很可能找到了问题所在：就是第三个路由器或其后的链路。但需谨慎：如果只有该单跳延迟高，而最终目标依然快速，那可能只是因为路由器配置上降低了你测试所使用的特定类型流量的优先级。这是常见的误报，可能让你钻进牛角尖。

解读抖动与丢包

超越简单的往返时间，你才能发现最关键的洞察。高抖动（这只是延迟不一致的一个花哨说法）有时比持续高延迟更具破坏性，对于实时应用尤其如此。

如果你的测试结果显示平均往返时间为40毫秒，但最小值仅为10毫秒，最大值却达到150毫秒，这表明你的连接极不稳定。这种巨大的波动正是导致视频通话卡顿和在线游戏出现让人抓狂的延迟峰值的原因。

丢包则是一个更严重的危险信号。即使1%的丢包率，也完全可能使基于TCP的应用程序陷入瘫痪，迫使它们不断重传数据，从而让一切运行得如同蜗牛般缓慢。查看测试结果时，任何发送数据包与接收数据包数量之间的显著差异，都必须立即进行调查。

我常看到人们犯的一个大错，就是认为单次测试就能说明一切。网络状况是持续变化的。凌晨3点的测试结果与下午3点高峰期的测试结果会截然不同。获取真实性能基线的唯一方法，是通过持续、重复的测试。

要防患于未然，值得研究专用的 网络性能监控工具。这能将您的策略从设备故障时的匆忙修复，转变为主动维护网络的健康运行。

最常见的测量误区

即使拥有世界上最优秀的工具，一些简单的错误也可能让您的结果完全失效。如果您希望获得可信的数据，避免这些常见陷阱至关重要。

• 在Wi-Fi下测试： 说真的，别这样做。无线连接出了名的不稳定，容易受到从微波炉到邻居路由器等各种设备的干扰。对于任何严肃的延迟测试，请务必使用以太网线连接。这是获得稳定、可靠基线的唯一方法。
• 忽略VPN开销： VPN对安全很有帮助，但它们为流量路径增加了一个额外节点和加密过程。这总是会增加延迟。如果您试图诊断用户连接缓慢的问题，您首先应该问的问题之一就是：“您使用VPN了吗？” 分别在使用和不使用VPN的情况下进行测试，就能准确看出它增加了多少延迟。
• 忽略本地网络拥塞： 如果网络中的其他人占用了所有带宽，您的测试结果就会产生偏差。如果同事在您测试时正在流式传输4K视频或下载大文件，您的延迟数字就会被夸大，最终您会去追踪一个并不存在的问题。

另一个微妙但关键的因素是您选择的工具。正如我们所讨论的，不同的工具以不同的方式测量延迟。在比较时，请始终使用相同的工具，并确保您理解每个工具实际测量的是什么——无论是简单的ICMP回显，还是复杂的、应用层级的请求。请记住，性能可能受到多个层面的影响；例如，如果您深入研究网页性能，我们关于 Cookie Editor Chrome扩展 的指南可以展示客户端元素如何发挥作用。

通过结合正确的背景信息来解读结果，并避免这些常见错误，您将超越仅仅收集数字的阶段。您将开始理解网络性能背后的 原因，而这正是构建更快、更可靠系统的关键。

关于网络延迟的常见问题

即使你拥有正确的工具，深入探讨网络延迟时，似乎总会浮现几个常见问题。让我梳理一下我常听到的一些疑问，帮助你更好地理解你的测试结果。

怎样的延迟数值才算“良好”？

这是经典的“视情况而定”问题，但我们可以设定一些可靠的基准。一个“良好”的延迟完全取决于你试图达成什么目标。

• 日常网页浏览： 对我们大多数人来说，RTT（往返时间）低于 100毫秒 会感觉完全正常。页面加载迅速，你不会察觉到任何明显的延迟。
• 竞技类在线游戏： 这是每一毫秒都至关重要的领域。硬核玩家和高频交易员寻求的是远低于 20毫秒 的延迟。这往往是胜负之分。
• 视频通话与网络电话： 在此场景下，稳定性至关重要。你需要稳定的延迟低于 150毫秒 且抖动（Jitter）较小（低于30毫秒），以避免卡顿、音画不同步的感觉，或更糟的通话中断。

根据经验法则，我认识的大多数网络专家会将低于 50毫秒 的延迟归类为低延迟。从 50到150毫秒 属于中等延迟，一旦超过 150毫秒，你就会在大多数交互式应用中开始感到拖沓。

为什么我的 Ping 命令和浏览器测速结果总是不一致？

这是一个绝佳的问题，也是非常常见的困惑点。其原因在于，命令行工具 ping 和基于浏览器的测速工具本质上是不同的工具，测量的东西也不同。

首先，它们几乎肯定连接的是不同的服务器。当你在命令行中 ping 一个域名时，你是在访问一个特定的目标。而网页测速工具则旨在从其自身网络中找到一个地理上较近的服务器，以提供最佳情况下的结果。

使用的协议也完全不同。命令行 Ping 使用一种名为 ICMP 的非常轻量级的协议。而大多数浏览器测速运行在 TCP 协议上，后者需要完整的建立连接过程（即“三次握手”）。这最初的来回交互在真正的测试开始之前就会增加一点时间。

最后，浏览器测速往往包含的不仅仅是纯粹的网络传输时间。它们的“延迟”数值可能包括了服务器处理时间，甚至是你浏览器内部的小延迟，这会导致最终数字相比纯粹的 ICMP Ping 被放大。

我该如何真正降低我的网络延迟？

降低延迟的关键在于找出并消除瓶颈，无论这些瓶颈是在你的办公室内还是在互联网上。

首先检查你的即时环境。你能做出的最有效的单一改变，就是从Wi-Fi切换到有线以太网连接。这对提升稳定性和速度有立竿见影的效果。如果必须使用Wi-Fi，请靠近路由器，并尽量连接5GHz频段——它通常干扰更少。

除了本地网络，有时更换DNS服务器也能带来帮助。使用更快的DNS服务器，可以在你访问网站时，将初始连接时间缩短若干毫秒。

如果你想改善对自己所控制的服务的访问，内容分发网络（CDN）是解决方案。它的工作原理是将你的内容副本物理放置到离用户更近的地方。另外，如果你正在使用VPN，尝试关闭它。额外的跳转和加密层几乎总会增加延迟。

我见过企业VPN给往返时间增加多达 70毫秒的情况。这会把一个良好的连接变得令人沮丧地缓慢。务必在开启和关闭VPN时分别测试，以了解你实际承受了多大的性能损耗。

延迟与带宽的真正区别是什么？

正确理解这一点对于理解网络性能至关重要。它们容易被混淆，但衡量的是两个截然不同的东西。

这里有一个我一直使用的类比：把它想象成一条高速公路。

• 带宽就是这条高速公路有多少条车道。车道越多，同时能通行的车辆（数据）就越多。
• 延迟就是限速。它决定了单辆车（一个数据包）从A点到B点能有多快。

你可以有一条非常宽阔的、十车道的高速公路（巨大的带宽），但限速只有20英里每小时（高延迟）。你最终可以移动大量数据，但像视频通话这样的实时应用将会慢得令人痛苦。另一方面，延迟极低的连接，即使其带宽不是特别大，也会让人感觉异常迅速和响应灵敏。要想获得出色的体验，你确实需要在这两者之间取得良好的平衡。

---

准备好让性能测试成为你日常工作流中无缝的一部分了吗？ ShiftShift Extensions 套件将一个强大的速度测试工具、JSON格式化器以及数十种其他开发者工具直接置于你的浏览器中，只需一个命令即可访问。停止在各个标签页之间来回切换，开始更智能地工作。 立即免费下载 ShiftShift Extensions，大幅提升你的工作效率.