如何测量网络延迟：开发者实用指南
通过本综合指南学习如何测量网络延迟。我们涵盖了诸如 ping 和 traceroute 等基本工具以及基于浏览器的测试技术。
推荐的扩展
想要测量网络延迟吗？你可以从简单的内置命令行工具开始，比如 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，然后跟上你想测试的域名。
默认情况下，ping 在 macOS 和 Linux 上会一直运行，而 Windows 只发送四个数据包后停止。对于任何实际分析，你需要控制这一点。发送十个或二十个数据包比仅发送几个数据包能更可靠地反映连接的稳定性。
完成后，你会得到一个整洁的摘要，包含关键数字：
- 传输/接收的数据包： 这告诉你在传输过程中是否有数据丢失。即使是少量的数据包丢失也是网络问题的重大警告。
- 往返时间最小/平均/最大/均方根偏差：这些是您的核心延迟统计数据。您可以获得最佳情况时间（
min）、平均时间（avg）和最坏情况时间（max）。mdev（均方根偏差）是您对抖动的衡量——延迟在每个数据包之间变化的程度。
请密切关注您的最小和最大RTT之间的差距。如果差距很大，即使平均值看起来不错，您的连接也是不稳定的。这种抖动对实时应用程序（如视频通话或游戏）的影响可能远比连接始终稍慢要大得多。
一个常见的错误是仅仅看平均RTT。平均值50ms可能看起来不错，但如果您的最小值是20ms，最大值是250ms，用户体验将会显得不流畅且不可靠。始终查看完整范围以了解抖动。
使用Traceroute和MTR追踪路径
那么，当ping显示高延迟或数据包丢失时，您该怎么办？您的下一个任务是找出问题出在哪里。这就是traceroute（在Windows上为tracert）的用途。它绘制了数据包经过的整个路径，显示您机器与最终目的地之间的每一个“跳跃”——每个路由器。
traceroute输出中的每一行都是一个跳跃，通常显示到该点的三个独立延迟测量。这使您能够确定路径上的特定路由器是否导致了重大延迟或数据包丢失。
但是traceroute只是一次性的快照。对于更动态、持续的观察，我认识的大多数网络专业人士都推荐MTR（我的Traceroute）。MTR就像一个超级增强的工具，结合了ping和traceroute。它不断向路径上的每个跳跃发送数据包，实时更新每个点的延迟和数据包丢失情况。这使得它在捕捉间歇性问题方面非常有效，而单次的traceroute可能会错过这些问题。
为什么工具的选择很重要
您选择的工具及其配置方式可以极大地改变您的结果。这在超快、低延迟的环境中（如云数据中心）尤其如此。
实际上，数字的差异可能会让人感到震惊。在Google Cloud进行的一项详细实验中，标准的ping测试报告的平均RTT为146微秒。但当他们使用另一种工具进行连续交易而不暂停时，RTT降至仅66.59微秒——速度快了两倍多！
这是一个完美的例子，说明ping有时会高估延迟。它表明，理解工具的工作原理对于获取可信的测量结果至关重要。
使用iperf查找连接的最高速度
延迟并不总是整个情况。有时您需要知道您的连接实际能够传输的最大数据量——带宽。为此，您需要的工具是iperf。
虽然ping测量延迟，但iperf则专注于吞吐量。它通过建立客户端-服务器连接，然后在设定的时间内尽可能多地传输数据。
要使用iperf，您需要两台机器：
- 在一台机器上，您以服务器模式运行
iperf。它将静静地等待连接。 - 在另一台机器上，您以客户端模式运行
iperf，指向服务器的地址。
客户端将连接并开始测试。输出将告诉您传输的总数据量，以及最重要的，比特率（您的带宽），以兆比特或千兆比特每秒为单位。这是对网络链接进行压力测试并找出其真正能力的完美方法。
从用户的角度测量延迟
虽然命令行工具为您提供了网络的原始、未过滤的视图，但对于Web应用程序而言，真正重要的延迟是最终用户实际体验到的延迟。这时我们将焦点从终端转向浏览器本身。浏览器内部发生的事情讲述了一个更丰富、更相关的性能故事。
这不仅仅是单个数据包的往返时间。用户感受到的延迟是DNS查找、TCP握手、TLS协商、服务器处理时间，以及当然，还有实际在屏幕上呈现内容所需的时间的复杂组合。幸运的是，现代浏览器配备了强大的内置工具，帮助我们剖析整个过程。
深入浏览器开发者工具
每个主要浏览器——Chrome、Firefox、Edge、Safari——都配备了一套开发者工具。这些工具中的“网络”选项卡是您理解网站加载情况的指挥中心。它以瀑布图的形式展示所有内容，这是浏览器为呈现页面所做的每个请求的可视化分解。
这种瀑布视图是无价的。您可以准确看到每个资源下载所花费的时间，从初始HTML文档和CSS样式表到图像和API调用。更重要的是，它将每个请求的生命周期分解为不同的阶段：
- DNS查找：将域名解析为IP地址所需的时间。
- 初始连接：与服务器建立TCP连接所花费的时间。
- SSL/TLS握手：建立安全连接所需的开销。
- 首字节时间（TTFB）：这是一个重要的指标。它测量浏览器在接收到来自服务器的第一个字节数据之前等待的时间。
- 内容下载：实际下载资源所花费的时间。
例如，高TTFB是后端缓慢或服务器端处理问题的经典迹象——这是简单的ping测试永远无法发现的。通过分析这个瀑布图，您可以快速找出哪些资源阻碍了渲染或加载时间过长。
根据我的经验，一个关键的收获是，不仅要关注总加载时间，还要寻找瀑布图中最长的条形。单个未优化的图像或缓慢的第三方API可能会使整个页面处于停滞状态，即使网站的其他部分速度飞快，也会造成糟糕的用户体验。
使用Timing API进行编程测量
为了获得更自动化和精确的测量，您可以利用浏览器内置的JavaScript API。导航时间API和资源时间API为您提供对开发者工具中看到的相同详细性能数据的编程访问。这非常适合收集真实用户监控（RUM）数据，以了解您的网站在全球实际访客中的表现。
您可以通过几行JavaScript在浏览器控制台中获取这些指标。例如，要获取主页面加载的核心性能时间，您可以使用performance.getEntriesByType('navigation')。这将返回一个包含有价值时间戳的对象。
从这些数据中，您可以计算出重要的指标：
- DNS查找时间：
domainLookupEnd - domainLookupStart - TCP握手时间：
connectEnd - connectStart - 首字节时间（TTFB）：
responseStart - requestStart - 总页面加载时间：
loadEventEnd - startTime
通过遵循这个清单，你将能够设计出有效的延迟测试，收集到有价值的数据，进而优化用户体验。
通过有条理的方法，你可以从简单地测量延迟转向真正理解它。这种深思熟虑的方法使随机数字与可靠的性能指标之间产生了区别。
理解数字的意义（以及需要避免的事项）
好吧，你已经运行了测试并收集了一堆数据。这时真正的工作开始了——将这些原始数字转化为实际有意义的东西。数据正在讲述你网络健康状况的故事；你只需要学习如何解读它。
例如，在traceroute中，往返时间（RTT）的突然激增是一个经典线索。如果在第三跳时延迟突然上升并且一直保持高位，那么你很可能找到了问题所在：就是那第三个路由器或其后面的链接。但要小心。如果只有那一个跳显示高延迟，而最终目的地仍然很快，那么这可能只是一个配置为降低你测试所用流量优先级的路由器。这是一个常见的误报，可能会让你陷入困境。
解码抖动和数据包丢失
超越简单的RTT，你会发现最关键的见解。高抖动，即不一致的延迟，可能比持续高的延迟更具破坏性。这对于任何实时应用尤其如此。
如果你的结果显示平均RTT为40ms，但最小值为10ms，最大值为150ms，那么你的连接是不稳定的。这种巨大的波动正是导致视频通话中令人烦恼的卡顿和在线游戏中愤怒的延迟尖峰的原因。
数据包丢失是一个更大的红旗。即使1%的数据包丢失也会严重影响基于TCP的应用程序，迫使它们不断重发数据，导致一切变得缓慢。当你查看测试结果时，发送的数据包和接收的数据包之间的任何真实差异都需要立即调查。
我看到的最大错误之一是人们假设单次测试就能讲述整个故事。网络状况是不断变化的。凌晨3点进行的测试与下午3点在高峰时段进行的测试会完全不同。获得真实性能基线的唯一方法是通过一致的重复测试。
为了提前发现问题，值得关注专用的网络性能监控工具。这将你的方法从在故障时慌忙修复转变为主动保持网络健康。
最常见的测量错误
即使拥有世界上最好的工具，几个简单的错误也可能使你的结果完全无用。如果你想要可以信任的数据，避免这些常见的陷阱是不可谈判的。
- 通过Wi-Fi进行测试：说真的，别这样做。无线连接 notoriously fickle，容易受到微波炉到邻居路由器等各种干扰。对于任何严肃的延迟测试，请使用以太网电缆连接。这是获得稳定、可靠基线的唯一方法。
- 忘记VPN开销：VPN在安全性方面很棒，但它们为你的流量增加了额外的停靠和加密。这将始终增加延迟。如果你试图诊断用户的慢连接，你的第一个问题应该是：“你在使用VPN吗？”测试有无VPN将清楚显示它增加了多少延迟。
- 忽视本地网络拥塞：如果网络上其他人占用了所有带宽，你的测试结果将会失真。如果同事在你测试时正在流式传输4K视频或下载大文件，你的延迟数字将被抬高，而你最终会追逐一个并不存在的问题。
另一个微妙但关键的因素是你选择的工具。正如我们所讨论的，不同的工具以不同的方式测量延迟。始终保持使用相同的工具进行比较，并确保你理解每个工具实际测量的内容——无论是简单的ICMP回显还是复杂的应用层请求。请记住，性能可能受到许多层的影响；例如，如果你正在深入研究网络性能，我们关于Cookie Editor Chrome Extension的指南可以展示客户端元素如何发挥作用。
通过在正确的上下文中解读结果并避免这些常见错误，你将超越仅仅收集数字。你将开始理解网络性能背后的原因，这就是构建更快、更可靠系统的关键。
关于网络延迟的常见问题
即使拥有正确的工具，当你开始深入研究网络延迟时，总会出现一些常见问题。让我们逐一走过一些我听到的最频繁的问题，以帮助你理解你的结果。
什么才算是“好”的延迟数字？
这是经典的“这要看情况”的问题，但我们绝对可以设定一些可靠的基准。“好”的延迟完全取决于你想要实现的目标。
- 休闲网页浏览：对于我们大多数人来说，任何低于100ms的RTT都感觉很好。页面加载迅速，你不会注意到任何真正的延迟。
- 竞争性在线游戏：在这里，每毫秒都至关重要。严肃的玩家和高频交易者希望延迟远低于20ms。这就是胜负的区别。
- 视频通话和VoIP：在这里，一致性是关键。你需要稳定的延迟低于150ms和低抖动（低于30ms），以避免那种卡顿、不同步的感觉，或者更糟糕的是，通话中断。
作为经验法则，我认识的大多数网络专业人士会将任何低于50ms的延迟归类为低延迟。从50-150ms为中等，一旦超过150ms，你会开始感受到大多数交互式应用程序的拖延。
为什么我的Ping和浏览器速度测试结果从不匹配？
这是一个很好的问题，也是一个非常常见的困惑点。这是因为命令行ping和基于浏览器的速度测试是根本不同的工具，测量的内容也不同。
首先，它们几乎肯定是在与不同的服务器通信。当你ping一个域时，你是在击中一个特定的目标。另一方面，网络速度测试旨在从其自身网络中找到一个地理位置接近的服务器，以给你最佳的结果。
协议也完全不同。Ping使用一种非常轻量级的协议，称为ICMP。大多数浏览器测试通过TCP运行，这需要一个完整的设置过程（“三次握手”）才能建立连接。这个初始的往返会在真正的测试开始之前增加一些时间。
最后，浏览器测试通常不仅仅计算纯网络传输时间。它们的“延迟”数字可能包括服务器处理时间，甚至是浏览器内部的小延迟，这可能会使最终数字与原始ICMP ping相比膨胀。
我该如何实际降低网络延迟？
减少延迟的关键在于寻找并消除瓶颈，无论它们是在您的办公室还是在互联网上。
首先要查看的是您的直接环境。您可以做的最有效的改变是从 Wi-Fi 切换到有线以太网连接。这对稳定性和速度来说是一个游戏规则的改变。如果您必须使用 Wi-Fi，请靠近路由器，并尽可能使用 5GHz 频段——通常这个频段人少。
在查看本地网络之外，有时更换 DNS 也能有所帮助。使用更快的 DNS 服务器可以在您查找网站时减少初始连接时间的毫秒数。
如果您想改善对您控制的服务的访问，内容分发网络（CDN）是答案。它通过将您的内容的副本物理上放置在离用户更近的地方来工作。如果您正在使用 VPN，尝试将其关闭。那额外的跳转和加密层几乎总是会增加延迟。
我见过企业 VPN 将往返时间增加多达 70ms。这可能会将一个良好的连接变成令人沮丧的慢速连接。始终测试使用和不使用 VPN 的情况，以查看您实际承受的性能损失。
延迟和带宽之间的真正区别是什么？
弄清楚这一点对于理解网络性能至关重要。它们容易混淆，但测量的是两种非常不同的东西。
这是我总是使用的类比：把它想象成一条高速公路。
- 带宽 就是高速公路有多少 车道。车道越多，越多的汽车（数据）可以同时行驶。
- 延迟 是 限速。它决定了一辆汽车（一个数据包）从 A 点到 B 点的速度。
您可以拥有一条巨大的十车道高速公路（巨大的带宽），但限速只有 20 mph（高延迟）。您最终可以传输大量数据，但实时的东西，比如视频通话，会非常缓慢。相反，延迟非常低的连接即使带宽不大，也会感觉非常灵敏和响应迅速。您确实需要两者之间的良好平衡，以获得良好的体验。
准备好让性能测试成为您日常工作流程的无缝部分吗？ShiftShift Extensions 套件将强大的速度测试、JSON 格式化工具和数十种其他开发者工具直接放在您的浏览器中，只需一个命令即可访问。停止在标签页之间切换，开始更聪明地工作。免费下载 ShiftShift Extensions，今天就提升您的生产力。