Pushing the Limits: How Netflix Serves Video Traffic at 800Gb/s
Pushing the Limits: How Netflix Serves Video Traffic at 800Gb/s
向數百萬名同時在線用戶提供高畫質影片，不僅僅需要快速的磁碟和寬頻，更需要精細地消除每一個對將位元從儲存裝置移動到網路中沒有貢獻的 CPU 週期和記憶體複製。在 NAB Show 的一場詳細技術演講中，Netflix 工程師揭示了為了將單台伺服器的吞吐量推向 800Gb/s 所需的架構演進。
在此規模下，主要的敵人不是原始運算能力，而是記憶體頻寬和作業系統核心的開銷。為了達到這些速度，Netflix 專注於一個特定的工作負載：使用基於 FreeBSD-current 和 NGINX 的技術棧來提供預編碼的靜態媒體檔案。
The Evolution of the Data Path
要理解 Netflix 如何達到 800Gb/s，觀察他們實施的優化時間線以減少對 CPU 和記憶體匯流排的「稅收」會很有幫助。
1. Asynchronous Sendfile (2014)
傳統上，提供檔案涉及將數據從磁碟複製到核心，然後到使用者空間，最後再傳回核心以透過網路發送。Netflix 利用了 sendfile(2)，它允許核心直接從檔案描述符將數據傳輸到 TCP socket，完全繞過使用者空間。
然而，標準的 sendfile 可能會在磁碟讀取緩慢時阻塞 NGINX worker。Netflix 實施了 asynchronous sendfile，將此操作轉變為一種「發射後不管」的機制。當磁碟讀取完成時，中斷處理程序會通知 TCP stack，數據已準備就緒，從而防止 worker 執行緒停滯，並在舊硬體上將吞吐量從 23Gb/s 提高到 36Gb/s。
2. Kernel TLS (kTLS) (2016)
加密對於現代流量是強制性的，但 TLS 通常會破壞 sendfile 的流水線。在標準的 TLS 設定中，數據必須從核心複製到使用者空間，由 CPU 進行加密，然後再傳回核心以發送。
Netflix 解決了這個問題，將 TLS 對稱加密移入核心。雖然初始握手仍保留在使用者空間，但大量加密工作由 sendfile 流水線的一部分來處理。這恢復了零複製數據流，並消除了因核心與使用者空間之間重複複製而導致的大量記憶體頻寬激增。
3. Mastering NUMA (2019)
隨著網路速度攀升，Netflix 遇到了 Non-Uniform Memory Architecture (NUMA) 的限制。在多插槽系統中，記憶體和 I/O 裝置與特定的 CPU 核心「較近」。如果位於 Node 0 的 CPU 需要加密存儲在連接到 Node 1 的記憶體中的數據，並透過連接到 Node 0 的 NIC 傳送，數據必須多次跨越 NUMA fabric（插槽之間的互連結構）。
在最壞的情況下，一個封包可能會跨越 NUMA 匯流排四次：
- 磁碟到記憶體
- 記憶體到 CPU（用於加密）
- CPU 傳回記憶體（已加密）
- 記憶體到 NIC
這種擁塞會導致 CPU 停滯。Netflix 實施了 Disk Centric Siloing，確保讀取、加密和傳輸的過程發生在數據所在的 NUMA node，從而避免了數據在不同 node 之間移動。透過轉向「Strict Disk Centric Siloing」，他們完全消除了大量數據跨越 NUMA 匯流排的情況，顯著降低了 fabric 飽和度。
The Final Leap: Inline Hardware kTLS (2022)
即使有了 NUMA 優化，基於軟體的 kTLS 也會消耗將近一半的可用 CPU 週期。為了突破 400Gb/s 的障礙，Netflix 與 NVIDIA (Mellanox) 合作，使用 ConnectX-6 Dx NIC 實施了 Inline Hardware kTLS。
透過硬體卸載，核心直接將加密金鑰傳遞給 NIC。數據從磁碟流向記憶體，然後以明文形式直接傳送到 NIC；NIC 在數據進入線路時即時進行加密。
其影響是雙重的：
- CPU 減輕負擔： 主機 CPU 不再參與大量加密過程。
- 記憶體頻寬減少： 記憶體頻寬需求減半（對於 800Gb/s 的串流，從 ~400GB/sec 降低到 ~200GB/sec），因為 CPU 不再需要為了加密而讀取和寫入數據。
Experimental Results at 800Gb/s
使用一台配備雙 AMD EPYC 7713 CPU 和四個 Mellanox ConnectX-6 Dx NIC 的 Dell R7525 伺服器，Netflix 測試了此架構的極限。他們達到 720Gb/s 的過程經歷了多次迭代：
- Initial Result (420Gb/s): 受限於 AMD 在插槽間 xGMI 連結的動態連結寬度管理 (DLWM)。
- Forced Link Width (500Gb/s): 在將 xGMI 強制設定為 x16 和 18GT/s 後，由於 NVMe quadrant 之間不均勻的 I/O 分佈，他們遇到了瓶頸。
- Disk Centric Siloing (670Gb/s): 透過改變 DMA 處理方式改進了 xGMI hashing，雖然這對 page daemon 造成了一些壓力。
- Strict Disk Centric Siloing (720Gb/s): 透過確保出口 NIC 位於與磁碟相同的 NUMA node，他們達到了 720Gb/s。此時，瓶頸已從 CPU 轉向由內容熱度引起的 NIC 輸出掉包（某些 NIC 被推向 94Gb/s，而其他 NIC 則停留在 84Gb/s）。
Technical Synthesis and Community Perspective
此架構突顯了高性能網路中的一個根本性轉變：向「卸載一切」的邁進。透過將數據平面推入核心並進一步推入硬體，Netflix 將 CPU 的角色從數據處理器轉變為協調者。
從社群觀點來看，一些觀察者質疑對於靜態、已加密的 DRM 內容，使用 TLS 的必要性。然而，業界「TLS 到處都是」的趨勢表明，安全性與隱私的益處——以及使用標準化硬體卸載的能力——超過了開銷。此外，在此技術棧中使用 FreeBSD 在這點上強調了 BSD kernel 在處理專業化、高吞吐量網路任務時的持續相關性，因為在這些任務中，對網路棧的精細控制至關重要。