如何測量網路延遲：開發者的實用指南

想要測量網路延遲？你可以從簡單、內建的命令列工具開始，例如 ping 和 traceroute，快速獲取 往返時間 (RTT) 的初步數據。或者，你可以開啟瀏覽器的開發者工具，查看延遲如何影響使用者實際體驗到的內容。

這些方法能讓你快速掌握數據封包從來源傳送到目的地、再返回的所需時間，提供有用且即時的快照。

為何測量延遲不可或缺

在我們深入「如何」之前，先來談談「為何」。對開發者和網路工程師而言，延遲不只是螢幕上的一個數字；它是塑造整體使用者體驗的隱形之手。在今天的應用程式中，毫秒至關重要。即使是微小的延遲，也可能讓服務感覺即時流暢，或感覺故障難用。

想想實際可能造成的後果：

• API 回應速度： 單一緩慢的 API 呼叫可能引發骨牌效應，從載入使用者資料到處理關鍵付款的所有環節都會延遲。
• 即時數據串流： 對於線上遊戲、直播影片或金融交易，低且穩定的延遲是絕對基礎。沒有它，這些應用根本無法運作。
• 使用者留存率： 網站和應用載入緩慢與較高的跳出率、放棄購物車之間，有著直接關聯。這點對營收影響甚鉅。

區分關鍵延遲概念

要精確測量網路延遲，你必須明白測量的是什麼。兩個最基本的概念是 往返時間 (RTT) 和 單向延遲.

RTT 是信號從 A 點到 B 點 再返回 所需的總時間。這是你會見到最常見的指標，因為測量方式直接——只需能存取連線的一端即可。

單向延遲 如其名所示，測量的是數據僅單向傳輸所需的時間。這是個更難以精確測量的指標，因為它要求兩端的時鐘必須完美同步。然而，對於上傳和下載路徑行為差異極大的非對稱連線，它是更精確的指標。

當你進行嚴格的 負載效能測試 時，所有這些的重要性會變得非常明確——這正是理論遇見現實、瓶頸暴露之處。

舉例來說，網路監控專家通常將延遲分類如下：

• 低延遲：低於 50 毫秒
• 中等延遲： 50-150 ms
• 高延遲： 超過 150 ms

根據我的經驗，對附近伺服器的快速測試可能會顯示一個完全可接受的 20-40 ms。但對於需要跨越海洋的流量，這個數字很容易膨脹到超過 200 ms，這可能成為您應用程式效能的關鍵因素。

為了理解您會遇到的術語，這裡有一個快速參考指南。

關鍵延遲概念一覽

等工具的首選指標。

概念	衡量內容	重要性
延遲 (Ping)	單一數據包從來源傳輸到目的地再返回所需的時間。以毫秒 (ms) 為單位進行測量。	這是延遲的原始衡量指標。低延遲對於遊戲、VoIP 和視訊會議等即時應用程式至關重要。
往返時間 (RTT)	本質上與延遲相同，這是信號傳輸的總持續時間，加上收到確認所需的時間。	RTT 是從單一地點測量延遲最常用且最實用的方法，使其成為 ping.
單向延遲	資料包從來源到目的地單向傳輸所需的時間。	提供更細粒度的視圖，特別適用於上行和下行路徑具有不同延遲的非對稱網路。
抖動	延遲隨時間的變化。它衡量資料包到達時間的不一致性。	對於串流媒體和線上通話，高抖動與高延遲一樣糟糕，會導致卡頓、緩衝和故障。
頻寬	在給定時間內，透過網路連線可以傳輸的最大數據量。以 Mbps 或 Gbps 為單位進行測量。	常與速度混淆，頻寬是關於容量。您可能有高頻寬，但仍會受到高延遲的影響。

這些概念是理解任何網路效能問題的基礎。

這就是為何易用、整合的工具如此重要。現代的瀏覽器擴充功能與開發工具，能讓你在不離開工作流程的情況下獲得所需洞察力，免去執行複雜診斷套件的麻煩。重點在於將延遲測量變為建構與維護優質軟體時毫不費力的例行工作。

動手實作命令列延遲工具

要真正體會網路效能，必須打開終端機。命令列是取得連線原始未處理數據的基本工具所在。重點在於觀察您與目的地之間傳輸封包的真實動態，這是任何認真進行延遲測量的開發者必備的第一步。

經典首選工具是 ping。它運作原理極其簡單：向伺服器發送小型數據封包（ICMP 回送請求），然後等待回應。這個簡單的往返過程正是計算往返時間（RTT）的基礎，能即時檢驗連線狀態。

使用 Ping 進行首次延遲檢查

執行 ping 測試再簡單不過。開啟終端機或命令提示字元，輸入 ping，後接要測試的網域名稱。

預設情況下，ping 在 macOS 和 Linux 上會持續執行，而 Windows 僅發送四個封包即停止。若需進行實際分析，建議手動控制數量。發送十至二十個封包能比少數幾個封包更可靠地呈現連線穩定性。

測試完成後，將顯示包含關鍵數據的簡潔摘要：

• 已傳送/已接收封包數： 此數據可顯示傳輸過程中是否有資料遺失。即使少量的封包遺失都是網路異常的重大警訊。
• 往返時間最小/平均/最大/偏差： 這些是您的核心延遲統計數據。您可以看到最佳時間（min）、平均值（avg）和最差時間（max）。mdev（平均偏差）是您衡量抖動的指標——即延遲在不同封包之間的波動程度。

請密切注意最小與最大往返時間之間的差距。如果差距很大，即使平均值看起來還可以，您的連線仍然不穩定。這種抖動對視訊通話或遊戲等即時應用程式的干擾，可能遠大於一個稍微持續偏慢但穩定的連線。

一個常見的錯誤是只粗略查看平均往返時間。50毫秒的平均值看起來可能沒問題，但如果最小值是20毫秒而最大值是250毫秒，使用者體驗將會感覺斷斷續續且不可靠。務必查看完整範圍以理解抖動。

使用 Traceroute 和 MTR 追蹤路徑

那麼，當ping顯示高延遲或封包遺失時，您該怎麼辦？您的下一個任務是找出問題在哪裡。這就是traceroute（或在 Windows 上使用tracert）的用途。它會繪製出封包傳輸的完整路徑，顯示從您的機器到最終目的地之間的每一個「躍點」（每一台路由器）。

traceroute輸出中的每一行都是一個躍點，它通常會顯示到該點的三個獨立延遲測量值。這讓您能夠精確找出路徑中某個特定路由器是否造成了嚴重的速度減慢或封包丟失。

但是traceroute只是一個一次性的快照。為了進行更具動態性和持續性的觀察，我認識的大多數網路專業人士都信奉MTR（My Traceroute）。MTR 就像一個增強型工具，它結合了ping和traceroute的功能。它會持續向路徑上的每一個躍點發送封包，為您提供即時更新的視圖，顯示每個點的延遲和封包遺失情況。這使得它在捕捉單次traceroute可能遺漏的間歇性問題上，具有極高的 effectiveness。

工具選擇為何重要

您選擇的工具及其配置方式會顯著影響您的結果。在雲端資料中心等超高速、低延遲的環境中尤其如此。

數字之間的差異其實相當令人驚訝。在一項由 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 讓您能以程式碼方式取得與開發者工具中相同的詳細效能數據。這非常適合收集真實用戶監測 (RUM) 數據，以了解您的網站在全球實際訪客面前的表現。

只需幾行程式碼，即可在瀏覽器控制台中取得這些指標。例如，要獲取主頁面載入的核心效能時間數據，您可以使用 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 點大家上線時，那項結果就毫無用處。

要獲得真正的基準，你需要持續一段時間進行測試。可以混合安排：

• 在尖峰營業時段運行測試。
• 安排部分測試在夜間維護時段。
• 別忘了週末，因為流量模式可能完全不同。

透過重複取樣數據，你可以平滑隨機的高峰和低谷。這就是你發現重複性問題的方法，例如每天午餐後網路出現擁塞。

別忘了抖動問題

平均延遲是一個堅實的起點，但它常常隱藏了一個更惡性的問題：抖動。抖動 simply 是指你的延遲隨時間產生的 波動。想想看——一個穩定的連線，具有可預測的 80毫秒 延遲，對於即時應用程式來說，通常遠比平均 50毫秒 但在 10毫秒 和 200毫秒.

抖動是任何即時應用（如 VoIP 通話、視訊會議或線上遊戲）用戶體驗的隱形殺手。高抖動會導致音訊斷斷續續、畫面卡頓，以及令人沮喪的延遲尖峰，即使平均延遲在數字上看起來很好，應用程式也會感覺完全失靈。

理解抖動（jitter）意味著必須超越平均值的視野。它是那個未被歌頌的反派角色，因為它揭示了為何單靠平均值會如此具有誤導性。例如，來自 Pandora FMS 的數據顯示，當抖動超過 30ms 時，遊戲中的封包遺失率可能會飆升至 15% — 足以讓遊戲無法進行。測量你延遲結果的標準差，是量化這種不穩定性的第一步。

延遲測試設計檢查清單

為了整合以上所有要點，這裡提供一個快速的檢查清單來引導你。遵循這些步驟將有助於確保你收集的數據既準確又真正有用。

檢查項目	重要性說明	可行動建議
定義清晰目標	你無法衡量未經定義的事物。你是在診斷特定問題，還是在建立基線？	在開始之前，寫下你的目標。「診斷東南亞用戶的延遲問題」比「檢查延遲」是更好的目標。
選擇多樣化的端點	單一路徑無法代表你全球用戶的體驗。	選擇 3-5 個地點：一個在本地，一個在另一個大陸，以及幾個在你的主要用戶市場。
建立測試節奏	一次性測試會錯過基於時間的模式，例如尖峰時段的擁塞。	安排測試每小時自動運行，持續一周，以捕捉完整的網路行為週期。
測量抖動	平均值會隱藏那些毀掉即時應用程式的不穩定表現。	不要只看平均 RTT。計算標準差，或使用像 mtr 這樣的工具，它能顯示最小/最大/平均延遲。
使用正確的工具	ping 適合快速檢查，但像 mtr 或 iperf 這樣的工具能提供更深入的見解。	對於網站效能，使用瀏覽器開發者工具。對於原始的網路路徑，mtr 是一個很好的選擇。
記錄所有內容	六個月後，你就會忘記當初進行這項測試的「原因」。	保持簡單的記錄：日期、時間、使用的端點與工具，以及你觀察到的簡要說明。

透過有系統的方法，你將從單純測量延遲，轉變為真正理解延遲。這種深思熟慮的方法，正是區分隨機數字與可靠性能指標的關鍵。

解讀數字的意義（以及應避免的陷阱）

好的，你已經完成測試並獲得一堆數據。現在才是真正開始工作的地方——將那些原始數字轉化為有意義的資訊。這些數據正訴說著關於你網路健康狀況的故事；你只需學會如何解讀它。

例如，traceroute上的往返時間突然飆升就是一個典型線索。如果在第三個跳躍點延遲激增且持續到最後，那麼你很可能已經找到問題所在：就是第三個路由器或其後的鏈路。但要小心。如果只有單一跳躍點顯示高延遲，而最終目的地仍然快速，那可能只是路由器被設定為降低你測試所使用的那類流量的優先順序。這是一個常見的誤報，可能會讓你陷入徒勞無功的困境。

解碼抖動與封包遺失

超越簡單的往返時間分析，你會發現最關鍵的見解。高抖動（這個花俏的詞彙指的是不一致的延遲）可能比持續的高延遲更具破壞性。這對於任何即時應用尤其如此。

如果你的結果顯示平均往返時間為40毫秒，但最小值是10毫秒，最大值卻是150毫秒，表示你的連線不穩定。這種巨大的變異正是造成視訊通話中惱人卡頓和線上遊戲中令人憤怒的延遲尖峰的原因。

封包遺失則是更大的警訊。即使1%的封包遺失率，也足以嚴重削弱基於TCP的應用程式，迫使它們不斷重新傳送資料，導致整體運作變得極為緩慢。當你查看測試結果時，任何傳送封包與接收封包之間的實際差異都必須立即進行調查。

我看到許多人犯的最大錯誤之一，就是以為單次測試就能呈現全貌。網路狀況瞬息萬變。凌晨三點進行的測試結果，會與下午三點尖峰時段的測試完全不同。要獲得真正的效能基線，唯一方法就是透過持續且重複的測試。

要預防問題於未然，值得深入研究專用的 網路效能監控工具。這能讓你的策略從被動地搶修故障，轉變為主動維護網路健康狀態。

最常見的測量錯誤

即使擁有世上最優良的工具，幾個簡單的錯誤也可能讓你的測試結果完全失去參考價值。若想獲得真正可信賴的數據，絕對必須避免這些常見陷阱。

• 透過 Wi-Fi 進行測試： 真的，請別這樣做。無線連線眾所周知極不穩定，容易受到從微波爐到鄰居路由器等各種因素的干擾。任何嚴謹的延遲測試，都應該使用乙太網路線實體連線。這是獲得穩定可靠基線的唯一方法。
• 忽略 VPN 的額外負荷： VPN 在安全性上表現優異，但會為流量傳輸路徑增加額外節點與加密過程。這必定會增加延遲。若要診斷使用者連線緩慢的問題，你首要問的問題之一應該是：「你是否正在使用 VPN？」分別在使用與不使用 VPN 的情況下測試，就能確切了解它增加了多少延遲。
• 忽略本地網路擁塞： 如果你進行測試時，網路上其他人佔用了所有頻寬，測試結果就會產生偏差。當同事正在串流 4K 影片或下載大型檔案時進行測試，你的延遲數值會被放大，最後你會去追查一個根本不存在的問題。

另一個微妙但關鍵的因素是你選擇的工具。如同我們曾提到的，不同的工具測量延遲的方式各異。務必使用相同的工具進行比較測試，並確實理解每個工具實際上測量的內容——無論是簡單的 ICMP 回顯請求，還是複雜的應用程式層級請求。請記住，效能可能受到多個層級的影響；例如，若你正在研究網頁效能，我們關於 Cookie Editor Chrome 擴充功能的指南，就能說明客戶端元件如何發揮作用。

透過以正確的脈絡解讀你的測試結果，並避開這些常見錯誤，你將不再只是收集數字。你將開始理解網路效能背後的 原因，而這正是建構更快速、更可靠系統的關鍵。

關於網路延遲的常見問題

即便使用合適的工具，當您開始深入研究網路延遲時，總會浮現一些常見問題。讓我們來探討幾項我最常聽見的疑問，以助您解讀測試結果。

「良好」的延遲數值究竟為何？

這是典型的「視情況而定」問題，但我們確實能設定一些明確的基準。所謂「良好」的延遲完全相對於您想要達成的目標。

• 一般網頁瀏覽：對大多數人而言，往返時間低於 100毫秒 的延遲感受上會相當順暢。網頁載入迅速，您不會察覺任何明顯的遲滯。
• 競技類電子遊戲：在此情況下，每毫秒都至關重要。嚴謹的玩家和高頻交易者尋求的是遠低於 20毫秒 的延遲。這往往是勝負的關鍵。
• 視訊通話與 VoIP：此處首要的是穩定性。您需要維持低於 150毫秒 的穩定延遲，以及低抖動（小於30毫秒），以避免畫面卡頓、音畫不同步的感覺，或更糟的通話中斷。

一般而言，我認識的多數網路專家會將低於 50毫秒 的延遲歸類為低延遲。50-150毫秒 屬於中等延遲，一旦超過 150毫秒，您將開始在大多數互動式應用中感受到明顯的延遲感。

為什麼我的 Ping 指令測試和瀏覽器速度測試結果總是不一致？

這是個絕佳的問題，也是極為常見的困惑點。發生這種情況是因為命令列中的 ping 與瀏覽器的速度測試本質上是測量不同事物的不同工具。

首先，它們幾乎肯定連線至不同的伺服器。當您執行 ping 一個網域時，您是連線到特定目標。而網頁速度測試則是從其自身網路中尋找地理位置最近的伺服器，以提供您最佳情境下的結果。

使用的協定也完全不同。Ping 使用一種稱為 ICMP 的輕量級協定。大多數瀏覽器測試則透過 TCP 運作，而 TCP 需要完整的設定過程（「三次交握」）才能建立連線。這個初始的往返過程會在真正的測試開始前增加一些時間。

最後，瀏覽器測試通常包含的不僅僅是純粹的網路傳輸時間。它們的「延遲」數值可能包含伺服器處理時間，甚至是瀏覽器本身內部的小延遲，這會使最終數字相比於原始的 ICMP ping 看起來較高。

如何實際降低我的網路延遲？

降低延遲的關鍵在於找出並消除瓶頸，無論它們是在您的辦公室內，還是在整個網際網路上。

首先檢查您的直接環境。您能做出的最有效改變，就是從Wi-Fi切換到有線乙太網路連接。這對穩定性和速度來說是遊戲規則改變者。如果必須使用Wi-Fi，請靠近路由器，並盡可能連接到5GHz頻段——這個頻段通常較不擁擠。

除了本地網路之外，有時更換DNS伺服器也能有所幫助。使用更快的DNS伺服器可以在查詢網站時，減少初始連接時間的數毫秒。

如果您試圖改善對自己控制之服務的存取，內容傳遞網路（CDN）就是答案。它的運作方式是將您內容的副本實體放置在更接近使用者的位置。而如果您正在使用VPN，請嘗試將其關閉。額外的跳轉和加密層幾乎總是會增加延遲。

我曾見過企業VPN為往返時間增加了多達70毫秒。這會讓一個極佳的連接變得令人沮喪地緩慢。請務必在使用和不使用VPN的情況下進行測試，以了解您實際承受的效能損失。

延遲與頻寬的真正區別是什麼？

正確理解這一點是了解網路效能的基礎。它們很容易被混淆，但它們衡量的是兩種截然不同的東西。

這是我一直使用的類比：將其想像成一條高速公路。

• 頻寬是高速公路有幾條車道。車道越多，表示可以同時通行更多汽車（資料）。
• 延遲是速限。它決定了一輛汽車（一個資料封包）從A點到B點能有多快。

您可能有一條寬闊的十車道高速公路（巨大的頻寬），但速限是每小時20英里（高延遲）。您最終可以移動大量資料，但即時應用如視訊通話會慢得令人痛苦。另一方面，一個延遲極低的連接，即使其頻寬不是非常巨大，也會讓人感覺非常快速且反應靈敏。您確實需要兩者兼顧，才能獲得良好的體驗。

---

準備好讓效能測試成為您日常工作流程中無縫的一部分嗎？ShiftShift Extensions套件將強大的速度測試、JSON格式化工具以及數十種其他開發者工具直接內建於您的瀏覽器中，只需一個指令即可存取。停止在分頁間來回切換，開始更聰明地工作。免費下載 ShiftShift Extensions，立即提升您的生產力.