ExplainThis 全端開發雙週報 #84 延遲 (latency) 是什麼? 為什麼很重要?

嗨～歡迎閱讀第 84 期 ExplainThis 全端開發雙週報！

在進到正式的內容前想與大家分享，上個月 ExplainThis 的 E+ 會員方案 (連結)，有超過一半的新會員是透過所任職公司的教育訓練補助購買。感謝這些讀者，也感謝那些願意為員工成長提供資源與補助的公司。

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

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

在做系統設計時，低延遲 (low 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 的展示，讓人感受到低延遲的世界對於時間真的很敏感。如果能讓機器距離近一點、資料傳輸時少繞路一點，都可能帶來極爲顯著的改善。

如果你對於更多經典軟體書籍導讀的內容感興趣，歡迎加入 E+ 成長計畫 (連結)，我們除了會陸續導讀更多《Latency》章節外，目前 E+ 也有多本其他書籍的導讀。所有完整深度文章外，也可觀看所有 E+ 的線上課程與過去所有的直播回放。

• Linus Torvalds 在 Linux 核心郵件列表中，回應一段他對於 AI 工具介入核心開發的討論。他提到自己知道有些人真的很討厭 AI，但在身為 Linux 最高層級的維護者，他明確不退讓的立場是「Linux 不是反 AI 的專案」。原文與我們對這段回覆的觀點可以看這邊 (連結)

• 最近被 Anthropic 收購的 Bun 團隊，分享了如何在 11 天內，透過大量 AI 代理，把原本超過五十萬行的 Zig 程式碼遷移到 Rust 語言。Bun 團隊把這個經驗寫成一篇部落格文章，非常推薦大家一讀 (連結)

• 上面提到的遷移文章發表一天後，Zig 語言的作者 Andrew Kelley，寫了一篇《My Thoughts on the Bun Rust Rewrite》引發社群更廣大的論戰。讀完該文我們也有一些心得，有同意的部分，也有覺得不應該的部分，寫了一篇貼文跟大家聊聊 (連結)

• 《Engineering High-Performance Parsers with Data-Oriented Design》拆解如何用 Zig 打造高效能 JavaScript 解析器 Yuku，該文不只談解析演算法，而是深入記憶體配置、快取命中與資料結構設計 (連結)

• 《Most Apps Are Slower Than They Need to Be》一文比較 JavaScript、WebAssembly 與 WebGPU 面對大量運算時的效能差異，在文章中可以直接動手玩展示，也能看懂哪些工作留給一般網頁技術就好 (連結)

• 《To Make Software Is To Translate Human Intent Into Computational Precision》中，把軟體開發形容成將模糊的人類意圖，翻譯成精確且可執行的規則，藉此談 AI 時代工程師仍有哪些工作內容是不可取代的 (連結)

• 《Your URL Is Your State》一文介紹網址如何保存搜尋條件、分頁、排序、檢視模式與目前選取的內容 (連結) 。文章透過具體例子，整理哪些狀態適合放進網址，讓頁面可以分享、收藏、重新整理，也能正常使用上一頁與下一頁