> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/zh/concepts/latency-jitter-packet-loss.md).

# 延迟、抖动与丢包

你的网速测试显示 500 Mbps。你的视频通话却还是会卡断。两者怎么可能都是真的？

因为速度只是连接的一个维度，而且往往并不是最重要的那个。通常有另外三个数字能解释这种差异。

## 用通俗的话说，这三个指标

想象寄出一封信并等待回信。

**延迟** 指的是往返需要多长时间。你发出，对方回复，回复到达。以毫秒（ms）为单位。ping 测试报告的就是这个。低延迟意味着连接响应灵敏。

**抖动** 指的是往返时间变化有多大。如果回复分别在 20 ms、22 ms、21 ms 返回，说明传递很稳定。如果回复分别在 20 ms、90 ms、15 ms 返回，那就说明有些不一致——尽管平均值看起来还不错。抖动就是这种变化幅度，同样以毫秒为单位。

**丢包** 指的是那些根本没有到达的信件。数据以称为数据包的小块形式传输，其中一部分可能会在途中丢失。以百分比表示。丢失的数据通常会被重发，这会耗费时间；对于实时音频和视频来说，没有时间重发，所以空缺就会直接听出来。

而 **带宽**，也就是测速结果标题里最醒目的那个数字，指的是一次能承载多少数据——像是道路有多宽，而不是一辆车通过得有多快。

| 指标 | 它回答的问题      | 单位   | 糟糕体验            |
| -- | ----------- | ---- | --------------- |
| 延迟 | 要多久我才能收到响应？ | ms   | 一切都感觉很慢；游戏根本没法玩 |
| 抖动 | 延迟有多稳定？     | ms   | 卡顿、机械感明显的语音通话   |
| 丢包 | 有多少根本到不了？   | %    | 卡顿、冻结、掉线        |
| 带宽 | 一次能放进多少？    | Mbps | 下载很慢；视频质量低      |

## 为什么延迟不是速度

这是整页里最有用的一个概念。

带宽和延迟是相互独立的。卫星链路可以提供巨大的带宽，但每次往返都要半秒，因为信号必须实际飞到轨道再返回。通往附近服务器的普通家庭连接，可能延迟很低而带宽一般。

延迟主要由 **距离和跳数**决定，而不是由你花了多少钱决定。光在光纤中的传播速度大约是每毫秒 200 公里，而且每一个路由器、每一段中间网络、每一个队列都会再增加一点。跨越海洋的一次往返，无论你买什么套餐，都不可能快过物理极限。

所以，升级到更快的套餐，并不能修复连接远端服务器时的游戏卡顿。它只会让大文件下载更快完成。那是两个不同的问题。

## 什么才算好

对于任何一组阈值都要谨慎，包括下面这些。可接受的范围很大程度上取决于你在做什么、另一端离你有多远，以及你使用什么连接技术。往返另一大洲的服务器 60 ms 已经很出色；而同样的 60 ms 如果是连到你所在城市的服务器，就说明可能有问题。移动网络和卫星连接的范围与光纤完全不同。

不过如果是连接到一个相对较近的服务器的固定家庭网络，可以粗略参考以下标准：

|    | 良好        | 可用          | 有问题        |
| -- | --------- | ----------- | ---------- |
| 延迟 | 低于约 30 ms | 约 30–100 ms | 高于约 150 ms |
| 抖动 | 低于约 10 ms | 约 10–30 ms  | 高于约 30 ms  |
| 丢包 | 0%        | 低于约 1%      | 高于约 2–3%   |

有两件事比精确数字更重要。

第一， **和你自己之前的表现比较**。一个平时显示 18 ms、今天却显示 90 ms 的连接，不管表格怎么说，都说明有问题。你自己的基线是你手头最有价值的基准。

第二， **在负载下测量**。在空闲连接上测得的延迟可能很好看，但当有人开始上传时就会崩掉——这就是所谓的缓冲膨胀（bufferbloat）：网络设备里过大的队列会让大传输后面的所有数据都被延迟。在连接繁忙时测得的延迟，才更接近你实际体验到的情况。

## 延迟究竟来自哪里

一次往返并不是一个延迟，而是多个延迟叠加在一起。

* **距离。** 这是无法避免的部分。信号以有限速度传播，而真实的光纤线路比地图上的直线更长。
* **跳数。** 沿途的每个路由器都要花一点时间检查并转发每个数据包。经过三十跳的路径比经过八跳的路径要花更多时间。
* **排队。** 当链路比它能服务的流量更忙时，数据包就会在队列中等待。这是拥塞连接中最主要、也是最不稳定的因素，同时也是抖动的主要来源。
* **最后一公里。** 连接你所在建筑的技术很重要。光纤增加的延迟很少；老旧的铜线和有线技术更多；移动网络和卫星则会多得多。
* **另一端。** 服务器本身在回复之前也需要思考时间。一个慢应用看起来和慢网络完全一样。

这几项里，只有第一项是固定的。其他都可以改进——这就是为什么今天看起来很慢的连接，明天可能会没问题，而你这边什么都没变。

## 各自会破坏什么

**游戏最先被延迟破坏，然后才是丢包。** 竞技游戏要求你的操作先到达服务器，并且结果要在时机过去之前返回。带宽几乎无关紧要——游戏传输的数据量很小。这也是为什么，离服务器近、连接一般的玩家，能打败离得远、网速很快的玩家。丢包会表现为橡皮筋现象，也就是画面突然弹回原来的位置。

**语音和视频通话最先被抖动破坏，然后才是丢包。** 音频必须以稳定的速度播放。应用会保留一个小缓冲区来吸收变化，但如果到达时间太不规律，缓冲区就会耗尽，于是你就会听到熟悉的、机械感很强的断裂语音。丢失的数据包无法及时重发，所以会变成短暂的静音。通话所需带宽其实少得惊人，所以即使测速很快的连接也可能通话失败。参见 [什么是 WebRTC？](/knowledge-base/zh/concepts/what-is-webrtc.md).

**流媒体视频最先被带宽破坏，而延迟只会轻微影响它。** 视频播放器会提前缓冲好几秒，所以它很容易吸收抖动和中等程度的延迟。但它无法吸收带宽不足：它会降低画质，如果情况继续恶化，就会停下来重新缓冲。开头多等几秒是延迟问题；播放到一半画面变糊是带宽问题。

**普通网页浏览主要是延迟问题。** 一个页面会加载几十个单独的资源，每个都需要一次请求和一次响应。延迟会被反复支付，所以即使原始带宽很充足，高延迟连接也会让人感觉迟钝。大约超过 50 Mbps 之后，额外的带宽几乎不会再改变网页的“速度感”。

## 常见误解

**“更多 Mbps 就能解决卡顿。”** 不行。卡顿指的是延迟。带宽和延迟是路径上彼此独立的属性。

**“必须做到零丢包。”** 偶尔的丢包是正常的，而且通常察觉不到。持续高于一两个百分点的丢包才会造成影响——而且如果丢包只出现在 traceroute 的某一跳，通常是那个路由器在降低自己回复的优先级，而不是真正影响你流量的丢包。

**“一次测试就能告诉我连接质量。”** 一次测量只是某一时刻、某一路径的快照。要想得出结论，应该在不同时间、针对不同地点重复测试。

**“对一个网站 ping 很高就说明我的连接很差。”** 这可能只是说明那个网站离你很远，或者那条路由很拥塞。测试多个目的地，才能把本地问题和路径问题区分开来。

{% hint style="info" %}
**在 MyIP 上亲自看看**

这个 [测速](/knowledge-base/zh/network-tests/speed-test.md) 报告的不只是下载和上传数值：它还显示延迟、抖动，以及在 *连接负载下测得的延迟* ——然后把这些都换算成视频流、游戏和视频聊天的质量评分。最后一行就是这页内容的一眼重点。

要看看这些数字如何随距离变化， [全局延迟测试](/knowledge-base/zh/network-tests/global-latency-test.md) 会从全球各地的探测点向你的地址发起 ping。 [MTR 测试](/knowledge-base/zh/network-tests/mtr-test.md) 而当某条特定路径看起来很糟时，
{% endhint %}

## 相关概念

* [什么是 ASN？](/knowledge-base/zh/concepts/what-is-an-asn.md) ——为什么网络之间的路由决定你的延迟
* [什么是 WebRTC？](/knowledge-base/zh/concepts/what-is-webrtc.md) ——为什么通话对抖动如此敏感
* [公网、私网与 CGNAT 地址](/knowledge-base/zh/concepts/public-private-cgnat.md) ——你和互联网之间多出来的跳数
* [为什么我的网速这么慢？](/knowledge-base/zh/diagnose/why-is-my-internet-slow.md) ——一步一步的诊断


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/zh/concepts/latency-jitter-packet-loss.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.