2025q1 Homework1 (ideas)

contributed by < ginsengAttack>

研讀 2024 年課程期末展示及完整期末專題列表，搭配 2024 年課程回顧影片，從去年的期末專題中選出至少 7 項題目，紀錄過程中的認知、遇到的疑惑，以及你認為如何改進。

Linux 核心專題: 透過 Netfilter 自動過濾廣告

執行人: gawei1206

Netfilter

是 Linux 核心中的一個框架，用於處理封包內容修改及過濾，我們可以透過 iptables 告訴 Netfilter 如何處理接收到的或是準備發送出去的封包。

2020 專案

ZhuMon 實做過將網域 mapping 到 local host，概念應該是利用 DNS 的機制，在本地端就將域名對應到本機，避免向遠端主機發送廣告請求。

用手動設定讓域名沒辦法正確的被解析成廣告伺服器的位置，這邊提供一個思路：

並不是將廣告伺服器傳輸的封包阻擋在外面，而是阻擋本機向廣告伺服器傳輸的請求。

2023 專案

所以在將規則寫入 netfilter 的時候，要新增到 OUTPUT chain 中。

為什嘛不是在 post_routing 處理？因為在 post_routing 的時候顧名思義已經進行完路由判斷了，決定 IP 位置當然要在這之前。

提問：

作者提到，有些網域即使我把他加入到了規則中，但卻無法阻止與他的連線。

這個問題Steven Lin曾經遇到過，因為 https 的封包會在 TCP 上進行 TLS 加密，保護封包不受竄改。

如果要對 https 封包進行阻擋，可能必須使用 eBPF 在 Kernel space 對封包進行過濾和處理。

但是 eBPF 也是在核心中執行，所以應該也沒辦法讀取被 TLS 加密的訊息才對？而且無法讀取的是傳輸層的訊息，跟 IP 有啥關係？

這邊我有誤解，無法讀取的是"域名"，這個訊息是寫在 TLS 當中的，並不是無法得到 IP 。

我最直接的想法，是那就改為全部阻擋 ip ，不使用無法解析的域名作為阻擋條件，這個方法原則上應該可行。但是目前網路架構很多採用 CDN ，也就是域名可能會被解析為不同 ip，所以這招治標不治本。

這也就是提出使用 eBPF 的理由，該技術有 map 作為核心和 user space 的橋樑，能夠更靈活的變更域名的解析，即使核心仍然無法得知域名，但直接知道必須阻擋的 ip。

以 eBPF 打造 TCP 伺服器

執行人：SuNsHiNe-75

eBPF 的概念：

把寫好的 BPF 程式碼在 User mode 轉換成 Bytecode 後，注入到 Kernel 。並且會先經過 Verifier 防止注入有害的東西。

像是將程式碼交給 Kernel 執行的概念。

User 端可以透過 System call 來存取 Map 資料。

使用 eBPF 建構 echo server

正常架構下的封包，會在 Kernel space 完成接收後，交給 User space 處理，但是如果透過 eBPF 將處理程序交給 Kernel space ，就可以省略切換模式的各種成本。

伺服器比較：

kecho

將伺服器掛載進 kernel space 運行的專案，跟上述的技術一樣具有減少 context switch 的效果。

user-echo-server

透過 epoll 監測事件發生。

ebpf-tcp-server

用 map 作為 Userspace 和 Kernel space 的溝通橋樑。

所以還是會將資訊傳輸到 User space ?

效能分析：

kecho 和 user-echo-server 的時間差距很大，部份原因是執行的層級不同，user-level echo server 的串行處理方式，在負載較高時，每個客戶端的請求都會受到之前請求的處理時間影響，造成 Response time 顯著增加。還有cho server 不是並行處理的伺服器。在同時收到多個客戶端事件時，使用 epoll 機制會依據 file descriptor 在 epoll_ev 陣列中的位置依序處理每個事件。代表每個事件的處理是「串行 (Serial)」的，會導致總處理時間變長。

核心模式下執行則有以下優勢：

1. 並行能力：Kecho 通過使用 CMWQ（Consolidated Work Queue）來提高並行處理能力。這允許伺服器同時處理多個客戶端的請求，避免了串行處理所帶來的效能瓶頸。
2. Locality 優勢：在核心模式下執行的伺服器可以更佳地利用 CPU 的 Locality 優勢，減少 Context-switch 和資料在 Userspace 和 Kernel space 之間的複製，從而提升處理效率。
3. 多執行緒：因應 CMWQ 技術，Kecho 可以更有效地利用「可用的多個執行緒」來處理不同的客戶端請求，進一步提升整體效能。

同網域之其他機器測試 echo server 之平均效能分析

執行於「核心層級」之 kecho 由於無「基於 eBPF 之 socket redirect」的輔助，即使伺服器不需要跨到 Userspace 去運行，但相比 ebpf-tcp-server，其仍須呼叫 send/recv 等 System call 以便與 Client 溝通，硬生生多了許多系統呼叫的開銷。而此缺點也在如上之「效能評測表格」中反映出來。