最後更新：2026-06-24

延遲預算

網路延遲很少是單一數字。一個封包從路徑一端到另一端所經歷的延遲，是好幾種不同效應的總和，每一種都有自己的成因與自己的解方。延遲預算把總延遲視為這些部分的總和，讓你看清時間花在哪裡，以及當應用程式感覺遲鈍時該針對哪個組成下手。

四個組成

單向延遲是四個經典組成的總和，往返時間則是對稱路徑下單向延遲的兩倍：

其中 $t_{p}$ 是傳播延遲，$t_{s}$ 是序列化延遲，$t_{q}$ 是佇列延遲，$t_{d}$ 是處理延遲。

• 傳播延遲（$t_{p}$）。 訊號跨越實體距離所需的時間，由介質中的光速主宰。光在光纖中以其真空速度約三分之二行進，因此一條路徑每個方向每 1,000 公里約增加 5 ms 的傳播延遲。距離是唯一的槓桿。
• 序列化延遲（$t_{s}$）。 把一個封包的每個位元送上線路所需的時間，等於封包大小除以鏈路速率。一個 1,500 位元組訊框在 1 Gbps 鏈路上約需 12 微秒完成序列化。更快的鏈路與更小的封包會縮短它。
• 佇列延遲（$t_{q}$）。 一個封包在緩衝區中排在其他流量後方等待的時間。在閒置鏈路上接近於零，並隨使用率逼近 100% 而急遽攀升。這是變動最大的組成，也是抖動的常見成因。
• 處理延遲（$t_{d}$）。 每台裝置花在剖析表頭、查找路由與轉送上的時間。在現代硬體上它很小且穩定，每一跳通常是微秒等級。

計算範例

考慮一條路徑：20 ms 傳播延遲、1 ms 序列化延遲、5 ms 佇列延遲、2 ms 處理延遲。單向延遲為：

往返時間是其兩倍：

因此跨越這條路徑的 ping 約會讀到 56 ms，而單向串流會經歷 28 ms 的延遲。傳播延遲在此主導全局，這對中等距離的網際網路路徑而言相當典型。

哪個組成主導

組成的比例會隨情況改變，而這會告訴你該把心力花在哪裡。

在跨洲鏈路上，傳播延遲可達數十毫秒並淹沒其他一切，因此再快的硬體都幫不上忙——唯有把端點移得更近才行。在壅塞的鏈路上，佇列延遲可能飆到數百毫秒，而增加容量或採用主動佇列管理就是解方。

為什麼往返時間很重要

往返時間是多數協定真正在意的數字。一個請求必須抵達目的地，回覆必須傳回來，因此對對稱路由而言，一趟往返涵蓋了單向距離兩次——這就是那個乘以二的由來。TCP 確認資料的速度不可能快過一趟 RTT，這意味著高延遲鏈路即使頻寬充裕，仍會抑制吞吐量。延遲與吞吐量之間的這種耦合，正是為什麼又長又快的鏈路需要大的傳送視窗，也是本計算器與頻寬延遲乘積估算之間的連結。

真實路徑並不總是完全對稱：去程與回程路由可能不同，因此量測到的 ping 未必正好是單向量測的兩倍。這個乘以二是穩健的規劃假設，而非保證。

削減預算

一旦你知道哪個組成主導，補救之道也就隨之而來。傳播延遲只對更短的路徑有反應，實務上意味著用內容傳遞網路或邊緣節點把伺服器放在使用者附近。佇列延遲對更多容量、流量整形，以及讓緩衝區不致塞滿的佇列管理有反應。序列化延遲對更快的鏈路與更小的訊框有反應。處理延遲通常已經很小，但在繁忙的裝置上能受益於硬體轉送。先量測每個部分，才能確保你拉的是真正能撼動總和的那根槓桿。

相關計算器

一旦你知道往返時間，可用 頻寬延遲乘積計算機 計算器估算傳輸中資料量與 TCP 視窗。若想了解延遲如何在有遺失的鏈路上限制吞吐量，請使用 TCP 吞吐量計算機 計算器。若想估算一筆大量傳輸端到端要花多久，請參閱 資料傳輸時間計算機 計算器。