XDP(eXpress Data Path)防御DDoS攻击
1.新的分層方法
很多人會把Linux協議棧的實現按照OSI模型或者TCP/IP模型分成對應的層次，比如什么鏈路層，IP層，TCP層。其實這根本不對，Linux協議棧實現從鏈路層通用處理到IP層路由，并沒有經過什么顯式的關卡一樣的門，僅僅支持一些函數調用而已。記住，OSI模型也好，TCP/IP模型也罷，所謂的分層僅僅是邏輯視圖上的分層，好在讓人們便于理解以及便于界定軟件設計的邊界和分工，所以可以說，邏輯上分層這些層次之間都是隱式的門，然而在性能攸關的實現領域，顯式的門處在完全不同的位置！
??如果談優化，我們就必須要找到顯式的門，找到了門，繞過它便是優化！
??所以說，我之前的那些想法，比如在Netfilter的PREROUTING上做更多的事，優化效果并不明顯，就是因為Netfilter并不是門，它也只是一些函數調用。
??那么，什么是門？所謂的門，就是那些開銷巨大，你必須花點代價才能過去的點。舉幾個例子，必須用戶態到內核態的系統調用，比如套接字處理的自旋鎖，比如內存分配，或者說現實中的深圳羅湖口岸，深圳布吉關，梅林關…
??按照以上的說法，我來重新把Linux協議棧來分層，有了這個新的層次，在哪里做優化就顯而易見了(紅色區域開銷巨大，是為”門“)：
我們看到數據包從接收一直到用戶態，主要經歷了兩個門，其中一個是skb分配，另一個是套接字鎖定，在之前那篇《SYNPROXY抵御DDoS攻擊的原理和優化》文章中，我采用的方法顯然是繞開了套接字鎖定，抗DDoS的性能便得到了很大的提升，然而縱觀我幾乎所有的文章，基本上都是繞此門而優化的。因為這是一種便宜的方案。
2.繞過更低層的門
早在2014年時，接觸過一段時間netmap，當時還調研了基于Tilera做網絡處理加速，不管怎樣，這些都是跟DPDK類似的方案，DPDK應該都聽說過，Intel的一個被吵得火熱燙手的專用框架。
??既然大家都一樣，Intel是老大，自然就沒有Tilera什么事了(它們的方案又貴，又晦澀)，這就是DPDK被炒火的原因，Intel之類的公司，放個屁都是香的。
??其實，類似DPDK的加速方案原理都非常簡單，那就是完全繞開內核實現的協議棧，把數據包直接從網卡拉到用戶態，依靠Intel自身處理器的一些專門優化，來高速處理數據包，你可知道在這類方案中，CPU可是專門處理數據包的，什么內核態，用戶態，都無關緊要，采用map機制，專門的處理程序可以非常高效地在任意時間讀取并處理數據包，想想CPU的處理速度換算成pps是什么概念吧，如果一個CPU什么都不干，專門處理數據包，那將是非常猛的線速處理了。
??DPDK沒什么大不了的，就跟當年的EJB一樣，全靠廠商推動，依賴的是一攬子方案，并非一個樸素通用的框架。你給DPDK做個手術跑在ARM上試試，就算能跑，很多功能也都是廢的。
??總之，在skb還未分配的網卡驅動層面做一些事情是必要的，至于怎么做，做什么，那花樣就多了去了。
附：澄清一個單位概念
注意，線速是一個指標單位，表征處理性能而不是傳輸性能，并不是像在網線上跑一樣，如果那樣，直接叫光速或者70%光速好了…同樣總是引起混淆的單位是年一遇，百年一遇并不是講一百年遇到一次，而是百(年一遇)，數值是百，單位是年一遇。
3.XDP
解釋一個名詞，XDP的意思是eXpress Data Path。它能做什么呢？很簡單，下圖說明：
其中，最顯而易見的是，竟然可以在如此低的層面上把數據包丟棄或者回彈回去，如果面臨DDoS攻擊，采用這種方式的話，數據包就沒有必要上升到Netfilter層面再被丟棄了。說白了，XDP允許數據包在進入Linux協議棧之前就能受到判決。
??別的不管，我只管DDoS防護，現在的問題是XDP靠什么機制知道這個數據包是不是要被丟棄的呢？
??答案太響亮了，竟然是eBPF！
??事實上，這相當于在網卡驅動層面運行了一個eBPF程序，該程序決定數據包何去何從。最簡單的想法是，假設1000個IP地址是已知的異常地址，我們將其封裝在一個高效的查找結構中，然后將這個結構包括查找過程編譯成eBPF字節碼并注入到網卡，網卡收到數據包后，運行該eBPF字節碼，如果數據包源IP地址被找到，則丟棄！
這不就是我那個n+1模型以及iptables的bpf match中需要的效果嗎:
《使用iptables的bpf match來優化規則集-HiPAC/ipset/n+1模型之外的方法》
《iptables高性能前端優化-無壓力配置1w+條規則》
更加令人興奮的是，這一切竟然本來就是存在的現成的東西。推薦幾個鏈接：
https://netdevconf.org/2.1/slides/apr6/bertin_Netdev-XDP.pdf
https://netdevconf.org/2.1/papers/Gilberto_Bertin_XDP_in_practice.pdf
https://github.com/netoptimizer/prototype-kernel
https://www.iovisor.org/technology/xdp
以往，我們認為內核是確定的程序，我們能喂給它的只有數據，雖然Linux內核大部分都跑在馮諾依曼架構為主(如今基本都是混合架構)的機器上，但這種認知反而更像是哈佛架構，馮諾依曼機器本來就是程序和數據統一存儲的，現在，eBPF程序可以被灌入網卡驅動了，這簡直就跟網卡硬件的Firmware一樣為網卡注入了新的功能。不管是你認為程序已經數據化了，還是這種方案真的回歸了馮諾依曼模型，都無所謂，重要的是，它提升了性能。
??請注意，XDP并沒有對數據包做Kernel bypass，它只是提前做了一點預檢而已，目前它也只能有三種Action，繼續去掛號，直接殺掉，或者打道回府，看來這只是減少了掛號服務生的負擔…這與DPDK這種半道黃牛是完全不同的，DPDK完全可能把你拉到一個黑診所…不過，XDP思路非常清晰，后續的可能性誰也無法預估，說不定真有一天XDP會直接接管路由查找甚至TCP握手處理呢。
??本節的最后，再一次提一下一個熟悉的朋友，那就是Cisco的ACL，我一直都覺得在Cisco的中低端設備上，ACL的匹配就是按照XDP的方式做的，把用戶輸入的ACL規則編譯成eBPF之類的字節碼，然后灌入到需要使能的網卡上，我想象不出除了這種方式，還能有什么更高效的方式，也希望Cisco的朋友能有機會告知究竟…
4.關于DDoS防御
曾經，我做過一個模塊，就是在內核里記錄訪問本機次數最多的前幾個IP，然后把它們列入黑名單，認為它們是攻擊者。然而，這是錯的。最終并沒有揪出攻擊者，反而記錄訪問次數這件事卻差點耗盡CPU…
??收斂點說吧，這件事做的并不全錯，記錄前n個訪問最多的IP并阻止它們確實能起到一定的防御效果，但是在做這件事之前，完全是有辦法做到更深層過濾的，那就是，把不請自來的數據包的源IP地址全部加入黑名單，這樣，nf_conntrack，iptables以及XDP三者聯動，將會是一個完美的DDoS防御方案。
5.怎么做？
很抱歉，什么也做不了！
??目前XDP并不是支持所有的網卡，我能接觸到的也就是Intel的網卡，截止到4.10內核，XDP也就支持Mellanox(mlx4和mlx5)和QLogic，另外還有cavium的網卡。
??這個局面讓我根本無法去動手實踐而只能紙上談兵…不過這好似卸載了我巨大的負擔，讓我滿懷著些許希望度過一個不用編程的周末，不然我可能又要在周末搞什么XDP測試了…但我仍然滿懷希望，等待內核升級后在e1000e的驅動里看到XDP的鉤子…
總結
以上是生活随笔為你收集整理的XDP(eXpress Data Path)防御DDoS攻击的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： x86服务器中网络性能分析与调优（高并发
- 下一篇： nvidia nvlink互联与nvsw