如何測量網路延遲：開發者的實用指南
了解如何使用這本全面的指南來測量網路延遲。我們涵蓋了像是 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。平均50毫秒看起來可能還不錯，但如果您的最小值是20毫秒，最大值是250毫秒，用戶體驗將會感覺到卡頓和不可靠。始終查看完整範圍以了解抖動。
使用Traceroute和MTR追蹤路徑
那麼，當ping顯示高延遲或數據包丟失時，您該怎麼辦？您的下一步是找出問題出在哪裡。這就是traceroute（在Windows上為tracert）的用途。它映射了您的數據包所經過的整個路徑，顯示您機器與最終目的地之間的每一個“跳點”——每一個路由器。
traceroute輸出的每一行都是一個跳點，通常顯示到該點的三個獨立延遲測量。這使您能夠確定路徑上的特定路由器是否導致了重大延遲或丟包。
但traceroute是一個一次性的快照。對於更動態、持續的觀察，我認識的大多數網絡專家都堅信MTR（My 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可以使整個頁面陷入困境，即使網站的其他部分速度飛快，也會造成不良的用戶體驗。
使用計時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測試：認真地，真的不要。無線連接以其不穩定而著稱，容易受到微波爐到鄰居路由器等各種干擾。對於任何嚴肅的延遲測試，請使用以太網線連接。這是獲得穩定、可靠基準的唯一方法。
- 忘記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 英里每小時（高延遲）。您最終可以傳輸大量數據，但即時的事情，如視頻通話，將會非常緩慢。相反，延遲非常低的連接即使帶寬不大，感覺也會非常靈敏和響應迅速。您真的需要兩者之間的良好平衡，以獲得良好的體驗。
準備好讓性能測試成為您日常工作流程的一部分了嗎？ShiftShift Extensions 套件將強大的速度測試、JSON 格式化工具和數十個其他開發者工具放在您的瀏覽器內，只需一個命令即可訪問。停止在標籤之間切換，開始更智能地工作。免費下載 ShiftShift Extensions，今天就提升您的生產力。