ExplainThis 全端開發雙週報 #84 延遲 (latency) 是什麼? 為什麼很重要?
延遲 (latency) 是什麼? 為什麼很重要?
嗨～歡迎閱讀第 84 期 ExplainThis 全端開發雙週報！
在進到正式的內容前想與大家分享，上個月 ExplainThis 的 E+ 會員方案 (連結)，有超過一半的新會員是透過所任職公司的教育訓練補助購買。感謝這些讀者，也感謝那些願意為員工成長提供資源與補助的公司。
如果你覺得 ExplainThis 的分享有幫助，想閱讀更深入的內容，歡迎加入 E+ 會員。除了有會員專屬的深度文與影片，探討前後端開發、AI 工程、職涯發展，同時有 Discord 社群一同交流與成長。
如果所任職的公司有教育補助，透過補助購買，E+ 會開立有統編的發票。不用花自己的錢，也能每週透過深度主題文與社群交流，拓展技術視野、加速職涯成長。
延遲 (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 的展示，讓人感受到低延遲的世界對於時間真的很敏感。如果能讓機器距離近一點、資料傳輸時少繞路一點，都可能帶來極爲顯著的改善。
閱讀更多
如果你對於更多經典軟體書籍導讀的內容感興趣，歡迎加入 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》一文介紹網址如何保存搜尋條件、分頁、排序、檢視模式與目前選取的內容 (連結) 。文章透過具體例子，整理哪些狀態適合放進網址，讓頁面可以分享、收藏、重新整理，也能正常使用上一頁與下一頁