# 2025q1 Homework1 (ideas)
> contributed by < ginsengAttack>

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

## Linux 核心專題: 透過 Netfilter 自動過濾廣告
> 執行人: gawei1206

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

### 2020 專案
[ZhuMon](https://hackmd.io/@ZhuMon/2020q1_final_project) 實做過將網域 mapping 到 local host，概念應該是利用 DNS 的機制，在本地端就將域名對應到本機，避免向遠端主機發送廣告請求。

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

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

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

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

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

這個問題[Steven Lin](https://https://hackmd.io/@steven523/ryTuvqVUR)曾經遇到過，因為 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 溝通，硬生生多了許多系統呼叫的開銷。而此缺點也在如上之「效能評測表格」中反映出來。