延遲 (latency) 是什麼? 為什麼很重要?

在做系統設計時，低延遲 (low latency) 是對許多系統重要的非功能需求。最近有讀者來信詢問能否導讀《Latency》一書，在初步讀過後覺得這本書寫得非常有洞見，書中提供思考架構、實務方法來協助讀者打造出低延遲的系統。對此，接下來我們也會在主題文中逐篇導讀這本書。

在這一篇文章，我們會先從延遲究竟是什麼討論起，以及延遲這個主題對軟體工程師來說為什麼重要，最後也會討論延遲與其他技術面向的取捨。

延遲 (latency) 是什麼?

多數人平常在口語討論時，可能會用「很快」或者「很卡」來描述一個系統；但在做系統設計時，延遲這個詞會是更精準的描述，因此比起「很快」，會更常聽到「低延遲」這個描述。

所謂的延遲，是指某件事情發生後，到我們看到它產生的結果，中間隔了多久。

舉例來說，在日常生活中用電燈，按下開關到燈泡亮起來，中間的時間就是開燈的延遲。如果使用傳統的電燈，延遲會低到讓大家難以察覺；不過如果是使用智慧型燈泡，從手機的 App 中按下開啟按鈕後，可能就會等一小段時間才會亮。這種明顯的「慢一拍」的感覺，就是高延遲的表徵。

傳統電燈跟智慧電燈在延遲上會有差異，是因為智慧電燈在使用者按下開關時，會先經過好幾層關卡，例如要先經過無線網路的傳輸到控制中心，然後再透過藍牙等通訊方式傳到電燈，這中間的傳輸所需的額外時間，讓延遲變得比傳統電燈更高。

而對於現代軟體系統來說也是一樣，當使用者在瀏覽器輸入網址然後按下 Enter 按鍵，到畫面實際顯示出來會需要一段時間，而這段時間就是延遲。之所以會有這段延遲，是因為在使用者按下 Enter 鍵之後，背後發生了很多事。瀏覽器先查 DNS，把域名解析成 IP，接著建立連線，必要時完成 TLS 握手，然後送出 HTTP 請求；收到回應後瀏覽器要把拿到的 HTML、CSS、JavaScript 渲染出來。

這一步步的疊加都會使延遲增加，因此當使用者覺得「這網站跑好慢」，背後可能不是單一原因，而是 DNS 解析、網路、伺服器、資料庫、前端渲染等等的因素累加在一起的結果。對此，當開發者要檢視延遲時，不能只看單一段的程式碼，而是要展開整體路徑並逐一檢視，藉此判斷真正導致延遲過高的原因。

為什麼低延遲很重要?

在對延遲有最基本的理解後，接著讓我們來討論為什麼低延遲重要。不管在實務上的系統設計，或者是面試中，都很常會遇到「如何降低延遲」這個問題。為什麼不論實務或面試，延遲都這麼重要呢? 作者從幾個角度切入來談這個問題。

使用者體驗

首先，延遲會直接影響使用者體驗。假如進到一個網站後，要等 10 秒才會看到內容，相信多數人可能等不下去會直接關掉網站。Amazon 和 Google 都有做相關研究，指出降低延遲會直接提升顧客購買行為，以及使用者對服務的互動程度。舉例來說，Amazon 的研究中發現，每 100 毫秒的延遲，就可能造成約 1% 的銷售影響。因此，從轉換率的角度來看，讓系統的延遲降低，將能帶來相當程度的商業影響力。

不過值得注意的是，人類對延遲的感受不是線性的，而是超過某個門檻後使用者體驗會瞬間變不好。具體來說，100 毫秒內的變化，對人來說都像是一瞬間 (所以 100 毫秒跟 60 毫秒可能不會有顯著的知覺差異)。而跨過這個門檻後的延遲，就會變得有感。在 Akamai 的研究報告中發現，53% 的行動網站訪客會離開載入超過 3 秒的頁面。

因為從使用者角度來說，延遲跟體驗有關，所以系統可以透過一些方式，在總體延遲不變的狀況下，提供更好的體驗。舉例來說，現在大型語言模型 (LLM) 的回覆通常需要一點時間；因此在業界中常見的方式，是透過串流形式 (streaming)，只要一有新的回應就馬上傳給客戶端。所以比起等 30 秒後一次看到完整回覆，使用者可以在第 1 秒就看到回覆，然後在後續 1 到 30 秒逐步看到更多回覆。這種方式，能讓使用者更願意停留在應用程式中。

即時需求與效率

除了使用體驗外，在某些特定的系統與應用程式中，對於即時性有極高的要求，在這種狀況下，盡可能地降低延遲會成為系統的重要目標。舉例來說，如果心律調節器或者自動駕駛車輛的感測器有高延遲，很可能會造成攸關人命的問題。

作者在書中還進一步提到，優化延遲本身在做的事情就是讓程式變得更有效率。過去幾十年隨著摩爾定律 (晶片上的電晶體數量指數成長，讓 CPU 能有更多平行執行單元)，讓軟體在不變動的狀況下，因為硬體升級而獲得更低的延遲。但當電晶體變太小，功率密度上升，CPU 的頻率會趨於停滯。在這個脈絡下，軟體端不能再單純期待硬體下一代自然變快，而是要更主動減少不必要的計算、網路呼叫與資料轉換，讓軟體運作得更有效率，延遲也更低。

如何描述延遲?

在理解完延遲的重要性後，接著讓我們來談該如何描述延遲。一般來說，我們會透過時間單位來描述延遲。舉例來說，存取 SSD 中資料的延遲約是 100 微秒，而從紐約到倫敦的網路來回延遲是 60 毫秒。

在書中，作者列出了常見的延遲數字，這些也是在工程做估算時很常會用到的數字 (不熟這概念的讀者，推薦回顧 工程師都該知道的數字與估算方法 一文)。

這些數字背後有幾點特別值得討論的。第一個是延遲終究有極限。光速每秒可以走三十萬公里，這是理論上能做到的物理下界。在實體世界中，用來傳輸光訊號的光纖，因為不是在完全真空的環境，所以傳播速度還會比理論值更低。當意識到這個極限值時，就要思考如何在這個限制下優化，例如每秒能走的距離有限，那麼可以透過縮短機器之間的距離來降低延遲。

第二個值得思考的點，是延遲之間的尺度是以十倍數在衡量，所以快與慢的差距可能是數十倍。不過，在看上面這些數字時，多數人可能不太會有感覺。下方我們附上 Grace Hopper 當年在麻省理工學院 (MIT) 的經典演講。在演講中 Hopper 透過實體電線呈現出電訊號在一奈秒 (十億分之一秒) 能走的距離 (約 30 公分)，同時對比電訊號在一微秒 (百萬分之一秒) 內能走的距離。

如果在談一奈秒或一微秒的差距時，無法感受到差異，在做延遲優化時自然也不會太放在心上。但透過 Hopper 的展示，讓人感受到低延遲的世界對於時間真的很敏感。如果能讓機器距離近一點、資料傳輸時少繞路一點，都可能帶來極爲顯著的改善。

延遲與其他指標之間的取捨

延遲雖然重要，但不是系統中唯一重要的指標。在這個章節的最後段落，作者談了延遲與其他指標之間的取捨。

延遲與吞吐之間的取捨

在系統的效能指標當中，吞吐量 (throughput) 也是很重要的一項。吞吐量是指系統在每單位時間下，成功處理了多少東西。例如每秒成功處理多少個請求、每分鐘成功傳送多少筆訊息、每小時完成多少個任務。

白話一點理解，延遲是在問「一件事情要多久才能完成」，而吞吐量則是「實際上每秒、每分、每小時完成多少量」。以生活中常見的例子來說，假如要從台灣寄送物品到美國，選擇海運的吞吐量高，想要載送大型物品也沒問題，但是延遲比較差，因為要好幾週才會到。反之，選擇空運的吞吐量比較低，飛機單次能送的量沒有貨輪多，但是延遲比較低，可以幾天就到。

有些時候延遲與吞吐量之間需要做取捨，作者以洗衣服為例，來類比 CPU 的管線化 (pipelining)。假設今天洗衣服要 30 分鐘，而烘衣服要 60 分鐘，且要衣服洗完才能開始烘乾。這時有幾種不同的設計。

第一種設計是每次洗完一批，就馬上烘乾該批。從下圖可以看到，這樣單批衣服完成洗烘的延遲是 90 分鐘，而吞吐量則是每分鐘 1/90 批衣服。然而，如果採取類似 CPU 管線化的做法，在洗完第一批衣服後，洗衣機有空就馬上洗第二批衣服，烘乾一完成就馬上烘乾下一批，就會像下圖的第二個版本這樣。這時，吞吐量變成每分鐘 1/60 批，但延遲則變高，要 120 分鐘才會完成 (以第二批為例，30 分鐘開始洗，但要到 150 分鐘才完成，所以要等 120 分鐘)。

上面的例子就是延遲與吞吐量之間的取捨。一種方式讓單一任務更快完成，另一種則是整體完成更多任務。在工程實務上沒有哪個比較好，更重要的是當下的情境適合哪一種做法。

加入 E+ 會員方案

如果你覺得這篇分享有幫助，想閱讀更深入的內容，歡迎加入 E+ 會員。除了有會員專屬的深度文與影片，探討前後端開發、AI 工程、職涯發展，同時有 Discord 社群一同交流與成長。

許多 E+ 會員透過所任職公司的教育訓練補助 (E+ 會開立有統編的發票)，不用花自己的錢，也能每週透過深度主題文與社群交流，拓展技術視野、加速職涯成長。