透過共置 (Colocation) 降低延遲

在前兩個章節中，《Latency》一書從延遲是什麼，到如何測量延遲，概覽式地介紹了延遲。從這個章節開始，作者把焦點轉向如何最佳化延遲；而在這個章節中，作者會從「共置 colocation」的角度來談如何最佳化。

什麼是共置? 為何對延遲有幫助?

想像一下，假如今天有個網頁應用程式，客戶端在亞洲，而伺服器在美洲，伺服器背後呼叫的資料庫又在歐洲；當使用者做某個操作時，客戶端發送的請求要先走一萬公里到伺服器端，伺服器的請求往返資料庫要各走五千公里，最後伺服器端回傳給客戶端要再走一萬公里。

因為資料傳輸需要時間，即使用光纖網路，上面這些多走的距離，至少會增加 150 毫秒的延遲 (還不算上海底電纜通常不是直線距離，而是會彎曲繞路)。但如果今天把伺服器與資料庫都放在亞洲，甚至在亞洲當中，把伺服器與資料庫都放在跟客戶端同一個區域，就能因為少走的這些距離，伺服器與資料庫之間的網路延遲有機會壓到 10 毫秒以下；如果連應用程式本身也部署得更靠近使用者，完整請求的網路延遲還能進一步下降。

換句話說，僅僅是把不同機器的物理位置放靠近，就能夠大幅降低延遲。而這種把元件放得靠近一點的方式，就是共置。而之所以要共置，是因為當系統分散於不同節點時，節點之間的通訊延遲，可以透過拉近而降低。

事實上，共置的概念不僅侷限在跨不同的機器，在單一機器的內部，同樣可以透過共置來降低延遲。作者舉了 CPU 為例，在同一台機器當中，資料離 CPU 有多遠，也會影響到延遲。以 CPU 快取來說，如果資料在快取中，CPU 可以拿很快 (10 奈秒內)；但假如不在快取，CPU 必須去 DRAM 主記憶體拿，就得花比較多時間 (100 奈秒左右)，兩者在延遲的差距可能大到十倍。

以邊緣運算為例

在實務上提到共置，相信多數人會想到邊緣運算 (edge computing) 這個概念。邊緣運算是很典型地把運算與資料，共同移到更靠近終端使用者的方法，藉此來降低延遲。邊緣運算透過縮短節點之間的距離，能協助降低通訊造成的延遲。

這類延遲主要可以分成兩種，一種是地理延遲 (geographical latency)，另一種被稱為最後一哩延遲 (last-mile latency)。

地理延遲是指兩個節點之間的地理距離會帶來延遲，也就是上面有提到的，從亞洲發請求到美洲，以及從美洲回傳資料到亞洲這種往返所致的延遲。要降低地理延遲，除了上面提到的，把伺服器與資料庫放同一個地方外，把這兩者都放在與終端使用者比較近的區域，也是一種能降低延遲的手段。這種把伺服器端部署得更靠近客戶端的做法，也是共置的一種體現。

在實務上要做到這樣，CDN (content delivery network 內容傳遞網路) 是最廣泛被使用的手段。CDN 把伺服器部署在全球各地的資料中心中，當開發者把經常會被網頁存取的腳本、圖片、影片放在 CDN 的節點中，能確保這些內容在物理距離上更靠近客戶端，藉此降低資料傳輸所需的時間。我們先前在 系統設計必備知識點 — CDN (Content Delivery Network)? 一文中有提到更詳細談 CDN 相關的概念，推薦讀者們可以回顧。

最後一哩延遲則是網路封包從最近的骨幹網路到裝置之間的這段延遲。如果從距離來看，這段延遲理論上應該不到 1 毫秒，然後因為各種因素，最後一哩的延遲可能會到數十毫秒，因此也不容忽視。

節點內部延遲 (Intranode Latency)

前一段落談到的延遲，是屬於節點之間延遲（internode latency），意即延遲的主要來源，是分散式系統中不同節點之間的通訊。除了節點之間的延遲，節點內部延遲 (intranode latency) 意即單一節點內部各種延遲所造成的影響，包含軟體堆疊與硬體架構，也能夠透過共置來加速。

當兩台機器透過網路來溝通時，中間會經過一層又一層的抽象，在每一層抽象中都有不同的協定來處理，藉此規範資料如何被傳送與接收。舉例來說，對於前後端工程師來說很熟的 TCP/IP 與 HTTP 就是屬於不同層級的協定。

當客戶端送出 HTTP 請求後，應用層的資料會交給 TCP，再封裝進 IP 封包；如果底層使用乙太網路，還會進一步封裝成乙太網路幀。在這當中的不同層級，也不只有一種協定能選擇。對應用程式來說，TCP 之外也可以選擇 UDP。

UDP 比起 TCP，會更適合在資料中心內部的低延遲網路。雖然延遲比較低，但因為協定本身屬於不可靠通訊，如果某個路由器丟棄了包含 UDP 資料報的網路封包，網路堆疊不會嘗試重新傳送，如果是在傳輸上相對不可靠的公開網路，則需要確保應用層容忍資料遺失，不然可能不是好的選擇。

對比起來，TCP 提供可靠且有序的傳輸機制，遇到資料遺失時會進行重傳。但這也意味著對於許多延遲敏感的應用程式來說，TCP 可能不是最佳選擇。因此，業界現在有不少方案 (例如 Aeron) 試圖在 UDP 上建立可靠性；維持 UDP 的低延遲，同時趨近於 TCP 的可靠。

進一步說，上面提到的這些流程，即使在同一台機器中的不同行程 (process) 互相溝通，仍會走過部分的流程。例如即使伺服器與資料庫位於同一台機器，只要它們分屬不同的行程，彼此仍需要透過行程間通訊機制交換資料。以 TCP 連線到本機 PostgreSQL 為例，資料仍會經過作業系統的 TCP/IP 網路堆疊，因此會讓延遲更高一點。

加入 E+ 會員方案

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

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