XDP(eXpress Data Path)防御DDoS攻击

本文主要是介绍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防御方案。