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，對照上面的圖找到了可以監聽封包的最底層的工具：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。

因此基準值約為149ms。

Testing with iptables、XDPfilter

接著我們安裝iptables，為其插入32個無用rule進行測試：

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

可以看到，當rule數量上升對於latency的影響並不大。
再來我們測試xdpfilter對於latency的影響。先簡單開啟xdpfilter，將其load進driver，並加入一個簡單的ip rule。

latency約為179ms。接著試著同樣加入無用rule，測試xdpfilter的latency變化。

這是最後測試的結果，可以看到在500個rule的級距下，xdpfilter在latency上與iptables相比有顯著的提升。