為了解決網路程式的收發效能，根據三個面向進行研究 分別是系統、程式、硬體三個面向 程式面向 程式處理邏輯優化，縮短處理下一包的時間 使用多核效能，更改成多進程或多執行序，同時以參考 Reactor、Proactor 等模型架構，不一定要採用 透過 SO_REUSEPORT 搭配 RSS 進行有效的 CPU 使用 系統面向 系統層的優化，分別針對收容能力及核心分配做處理 收容能力 不用無條件的往上增加，而是增對需求條件進行調校，因為不單單只有收容能力需要調整 1 2 3 4 5 6 # 增加對 NIC Ring Buffer 的抓取的 CPU 資源，預設 300 net.core.netdev_budget=900 # 寫入的 Socket Buffer net.core.wmem_max=20971520 # 接收的 Socket Buffer net.core.rmem_max=20971520 核心分配 若為多行程/多進程設計，並有搭配 REUSEPORT，則可以降低 CPU 分配 透過 taskset、isolation、cgroup 進行分配、隔離、綁定 硬體面向 透過支援的網卡設定 Receive Side Scaling (RSS)，並透過 SO_REUSEPORT 的搭配，使 CPU 有效分配 RSS 這邊簡端說明，NIC 隊列通道會是一個以上，預設可能只用一個 可以啟用多個通道進行接收並搭配多個 CPU，達到更高的接收、發送效能 有興趣的可以閱讀 Linux Network Scaling: Receiving Packets

前言 UDP 若發生丟包，往往會認為封包遺失在路上，然而需要因環境架構來進行判斷 若發生問題的在一個大量的高速 UDP 的環境，則狀況可能會更加複雜，但往往事實出乎意料 知識 接收 網卡接收封包存入 Ring Buffer 然後透過 Kernel 存入 Socket Buffer 然後 Application 再從 Socket Buffer 取出封包 傳出 APP 將封包透過系統調用執行 sendTo 經歷 UDP封裝、IP封裝後進入 Socket Buffer，然後經由 Traffic Control 的 Qdisc(Classless Queuing Disciplines)，而 Qdisc 會有一套傳輸的規則，符合規則才從 Ring Buffer 透過網卡送出 發生原因 傳送方 UDP 傳送速率太快受到 Qdisc 規則限制 TX Ring Buffer 太小 Socket Buffer 太小 接收方 RX Ring Buffer 太小 Socket Buffer 太小 App 處理太慢 檢查流程 確認網路協議統計 UDP 是否出現丟包 buffer errors 是否不為 0