# 111-2專題研究筆記Week9-10

## tcpdump

繼上次使用大量封包測試效能因為設備問題受阻後，這次想要研究該paper另一種測試方式：測試latency。較為理想的狀態為使用timestamp，這個之前有做過類似的，但測試結果較為受限。
詳見 https://hackmd.io/@nemoz/HJ4J3RNG5 。
由於是在Sender端傳出時就打上timestamp，所以會吃到Sender端network stack、連線的狀況及品質等，因此想在"Reciever NIC接收到封包後"第一時間打上timestamp，也就是將latency指代的data path從
轉變為

因此第一時間就想到正仁學長在課堂時分享的bcc專案：[BPF Compiler Collection](https://github.com/iovisor/bcc)，對照上面的圖找到了可以監聽封包的最底層的工具：tcpdump，此工具可以讀取driver送上kernel的封包資訊及timestamp。
但結果是若開啟了XDP類型的firewall，tcpdump就收不到封包了，原因為下圖：
tcpdump是運用libpcap，將function hook在nwetwork stack的中段，因此是比XDP程式還要更上層的，必須要能夠在XDP進行過濾前先行打上timestamp。

**為了要比XDP早取得封包的資料並標上timestamp，必須也使用XDP來標記timestamp。**
## XDPdump
https://github.com/xdp-project/xdp-tools
此專案之前正仁學長也有用過，他分為兩個主要我們會用到的部分：
- XDPfilter，主要是command line類型的簡單filter，能過濾指定的port、IP。
- XDPdump，可以tracing"進出"上述XDPfilter的封包以及相對應的timestamp，因此我們終於能夠在有一個latency with "包含XDP及IPtables"的datapath了。

我們先透過

$ sudo ./xdp-filter load enp0s3 -f ipv4 -m skb

將xdpfilter程式load進driver，並標明透過ipv4來過濾封包。
再透過

$ sudo ./xdp-filter ip 192.168.69.9 -m src

告訴xdpfilter我們所要濾掉來自192.168.69.9的所有封包。

接著我們開啟xdpdump程式。

$ sudo ./xdpdump -i enp0s3 --rx-capture entry

透過--rx-capture來嗅出即將"進入"xdpfilter的封包資訊及timestamp。

這時候我們透過ip 192.168.69.9的機器來對其進行ping的動作：
可以看到封包全部都被drop掉了，但我們觀察xdpdump的視窗：
可以看到xdpdump仍然有秀出封包，證明這條datapath是開始於xdpfilter之前的，因此我們可以開始進行latency的實驗了，以下為實驗的拓樸：
整個datapath除了最底層開始打上timestamp的xdpdump，userspace也撰寫了接收封包並秀出最終timestamp的udp socket program，sender一樣使用ostinato產生udp封包。
先測試在什麼rule都不加的情況下，此條datapath的基準latency。
| XDP timestamp | Userspace timestamp| Latency |
| :-----:| :----: | :----: |
| 1650830369.503261649 | 1650830369.6520882 | 149ms |
| 1650830374.659241607 | 1650830374.8080854 | 149ms |
| 1650830380.769574781 | 1650830380.918455 | 149ms |
| 1650830384.386681104 | 1650830384.5355697 | 149ms |
| 1650830387.134427942 | 1650830387.2833288 | 148.9ms |

因此基準值約為149ms。

## Testing with iptables、XDPfilter
接著我們安裝iptables，為其插入32個無用rule進行測試：
| XDP timestamp | Userspace timestamp| Latency |
| :-----:| :----: | :----: |
| 1650831160.560912882 | 1650831161.1921768 | 632ms |
| 1650831164.396997172 | 1650831165.0282958 | 632ms |
| 1650831167.654823612 | 1650831168.286106 | 632ms |
| 1650831168.808675143 | 1650831169.4399452 | 631ms |
| 1650831169.872805632 | 1650831170.5040414 | 632ms |

約為632ms，可見iptables對於效能的影響十分顯著。
接下來我們分別測試32、64...256、512個無用rule對效能的影響。


可以看到，當rule數量上升對於latency的影響並不大。
再來我們測試xdpfilter對於latency的影響。先簡單開啟xdpfilter，將其load進driver，並加入一個簡單的ip rule。
| XDP timestamp | Userspace timestamp| Latency |
| :-----:| :----: | :----: |
| 1650832552.789719874 | 1650832552.9692104 | 180ms |
| 1650832553.305622792 | 1650832553.4851184 | 179ms |
| 1650832553.897888837 | 1650832554.0774055 | 179ms |
| 1650832554.369722774 | 1650832554.5492766 | 180ms |
| 1650832554.883567726 | 1650832555.0630856 | 179ms |

latency約為179ms。接著試著同樣加入無用rule，測試xdpfilter的latency變化。
這是最後測試的結果，可以看到在500個rule的級距下，xdpfilter在latency上與iptables相比有顯著的提升。