> 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-tw/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-tw/concepts/what-is-webrtc.md).

**串流影片最先被頻寬毀掉，而延遲只會稍微造成影響。** 影片播放器會先緩衝幾秒鐘，所以很容易吸收抖動和中等程度的延遲。它無法吸收的是頻寬不足：它會降低畫質；如果情況更糟，就會停住重新緩衝。多出幾秒的啟動延遲是延遲症狀；畫面在播放中途變模糊則是頻寬症狀。

**一般網頁瀏覽主要是延遲問題。** 一個頁面會載入數十個不同的資源，每個都需要一次請求和一次回應。延遲會一次次累積，所以高延遲連線即使原始頻寬充足，感覺仍然遲鈍。超過大約 50 Mbps 之後，額外頻寬幾乎不會再改變頁面感受到的速度。

## 常見誤解

**「更多 Mbps 就能修好延遲。」** 不會。延遲卡頓就是延遲。頻寬和延遲是路徑上彼此分離的特性。

**「必須零封包遺失。」** 偶爾遺失是正常的，而且通常看不出來。持續高於百分之一或百分之二的遺失，才會讓狀況惡化——而且如果在 traceroute 裡只出現在某一跳的遺失，往往只是那台路由器把自己的回應優先順序調低，不是真正影響你流量的遺失。

**「單一次測試就能告訴我連線品質。」** 一次測量只是某個時間點、某條路徑的快照。要先在不同時間、對不同地點重複測試，再下結論。

**「某個網站 ping 很高就代表我的連線很差。」** 那可能只是那個網站離你很遠，或是某條路徑壅塞。測試多個目的地，才能把本地問題和路徑問題區分開來。

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

該 [速度測試](/knowledge-base/zh-tw/network-tests/speed-test.md) 不只回報下載與上傳數值：它也顯示延遲、抖動，以及在連線負載時測得的延遲 *在連線負載時* —— 然後把所有這些轉換成串流影片、遊戲和視訊聊天的品質分數。最後一列就是這一頁的重點，一眼就能看出來。

要看這些數字如何隨距離變化， [全域延遲測試](/knowledge-base/zh-tw/network-tests/global-latency-test.md) 會從世界各地的探測點對你的位址進行 ping。當某條特定路徑看起來很糟時， [MTR 測試](/knowledge-base/zh-tw/network-tests/mtr-test.md) 會把路徑拆成各個跳數，並回報每一跳的延遲與遺失，讓你看出問題從哪裡開始。
{% endhint %}

## 相關概念

* [什麼是 ASN？](/knowledge-base/zh-tw/concepts/what-is-an-asn.md) —— 為什麼路由會決定你的延遲
* [什麼是 WebRTC？](/knowledge-base/zh-tw/concepts/what-is-webrtc.md) —— 為什麼通話對抖動這麼敏感
* [公共、私有與 CGNAT 位址](/knowledge-base/zh-tw/concepts/public-private-cgnat.md) —— 你和網際網路之間多出來的跳數
* [為什麼我的網路這麼慢？](/knowledge-base/zh-tw/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-tw/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.