快网CloudXNS授权转发简述
有幸全程参与了基于DPDK[^1]下一代高性能CloudXNS[^2]服务器开发，从未知到慢慢熟悉，其中也走了些弯路也踩过一些坑，一路走来有些感受与心得体会，在此进行梳理下，以对这一阶段做下些小的总结，也可以与同僚们进行交流学**。
背景
上一代XNS服务器是基于Linux内核进行开发，单机性能达到数百万级别QPS[^3]，相对于BIND[^4]来说已经高了很多,平常处理正常毫无压力，但在受大量DDOS攻击时服务质量**降低,虽然我们采用了远端清洗与近地防御的安措施，与受攻击时调度其他应急服务器来抗，但增加了服务器与人工干预成本。为了更好的抗DDOS攻击与服务更多的用户，需求单机处理千万级别的替代方案呼之欲出。
目标设定
单机处理能力千万级别。
性能，性能，性能。(重要的事重复三遍)
稳定压倒一切。(此话不是我说的)
社区活跃，已有商用案例。
需求调研
按照上述的目标设定需求，要达到单机处理千万级别的只能采用轮询而非中断方式，在市面上的可实现技术方案有DPDK/pf_ring/netmap等。
其中DPDK为Intel公司主推，并有BAT之类的大型公司进行商用，而且也比较适合处理UDP类型协议。经过权衡之下，我们决定采用DPDK进行下一代XNS的替代方案。
优点
性能高
用户态开发
死后易重启
缺点
无网络协议栈
开发困难，周期长
参考资料相对还匮乏
DPDK核心思想组织结构
DPDK 的组成架构如下图所示,相关技术原理概述如下:
在最底部的内核态(Linux Kernel)DPDK 有两个模块:KNI 与 IGB_UIO。其中,KNI 提供给用户一个使用 Linux 内核态的协议栈,以及传统的 Linux 网络工具(如ethtool, ifconfig)。IGB_UIO(igb_uio.ko 和kni.ko. IGB_UIO)则借助了 UIO 技术,在初始化过程中将网卡硬件寄存器映射到用户态。
DPDK 的上层用户态由很多库组成,主要包括核心部件库(Core Libraries)、平台相关模块(Platform)、网卡轮询模式驱动模块(PMD-NativesVirtual)、QoS 库、报文转发分类算法(Classify)等几大类,用户应用程序可以使用这些库进行二次开发。
用户态模式下的PMD Driver
去除了中断影响，减少了操作系统内核的开销，消除了IO吞吐瓶颈；
避免了内核态和用户态的报文拷贝；用户态下软件崩溃，不会影响系统的稳定性；
Intel提供的PMD驱动，充分利用指令和网卡的性能；
HugePage和m_buf管理
提供2M和1G的巨页，减少了TLB Miss，TLB Miss严重影响报文转发性能；
高效的m_buf管理，能够灵活的组织报文，包括多buffer接收，分片/重组，都能够轻松应对；
Ring
无锁化的消息队列，实际验证，性能充足；
82599 SR-IOV NIC
实现虚拟化下高速吞吐；
Vector Instance /向量指令
明显的降低内存等待开销，提升CPU的流水线效率。
项目规划
为了使DPDK更好的在我司使用与发扬光大，我大致规划了初期、中期与长期三步走策略实现目标。
初期目标
实现一个最简单的DNS demo.
需求：
网络可达。
Dig示例域名可正确响应。
中期目标
实现一个高性能高并发的DNS服务
需求:
单机性能提高5倍以上。
形成完整DNS产品服务(XNS、public DNS)。
平台与服务逻辑分离。
长期目标
实现高性能高并发的网络加速平台与应用体系
需求：
平台具有可移植性。
可透明承载多种业务(UDP/TCP)服务。
平台与服务物理分离。
可承载其他高级语言与虚拟化。
开发初试
为了验证其的可行性，我们对它进行了最小原型开发，实现了一个最简单的DNS服务程序，使其网络可达，dig能正确响应。
由于刚开始对DPDK一无所知，为了网络可达首先要面对的问题是服务器IP在哪儿配置的问题(这也许是一些初学者会面对的幼稚问题)，还好已有前辈在QQ大致网上了解一些原理与其源码示例，采用其源码examples目录下l3fwd为基础进行最小原型开发demo。
为了使网络可达，我们做了如下开发：
先在simpleDNS服务端中临时配置一个服务IP进行过滤.
在DNS客户端通过手工配置ARP表使得客户端ping/dig操作的请求包可达服务端，
在simpleDNS服务端做解析请求包，如果是DNS请求构造响应包，其他类型如ARP/ICMP请求则通过KNI入接口ingress()重入Linux内核由
其来处理后再通过KNI的egress()接口响应给客户端。
经过上述编码调试后，最简单的原型验证通过了，为下面的全面开发提供了参考依据。
架构设计
由于此项目是在基于DPDK进行二次开发，我一般对开源项目的使用原则是：
应使开源项目融入到项目工程中，而不是项目工程融入到开源项目中
因此我对它们进行分3层设计与实现：
内核层
主要为Linux内核本身与**igb_uio.ko与rte_kni.ko.
平台层
分为DPDK原生库与fastNP扩展库，分别在不同目录进行隔离。
DPDK源码树本身，没有任务的修改，是为了更好的升级、开发与维护。
对DPDK某些接口进行二次封装与业务所需的公共库，一般各种业务应用调用。
业务层
业务应用的各种实现，可直接调用fastNP平台层与DPDK原生层的API。
全面开发源码组织管理
为了所有源码可以一键编译、一键打包，编写一套符合所需的Makefile进行源码管理。
fastNP扩展库开发
扩展库源码不在DPDK源码目录中，需要很好的理解DPDK下面mk/目录下的各种Makefile原理，使其的各种编译选项与属性能够传递到扩展库中。
扩展库主要实现如下部分功能：
基础数据结构库。
如：高效双链表、用户态RCU接口等。
轻量级用户态协议栈
目前主要实现轻量级简易型UDP协议栈，以实现二三层转发为主。
HOOK挂载与处理机制
仿造了Linux netfilter框架实现5个点钩子挂载与处理。
高性能日志库
参考了目录主流高性能日志与线程安全，实现了一个数百万行打印的高性能日志系统。
等等…
业务层开发
第一个应用主要是把原有内核版本的KANS源码移植到用户态的SANSD中。
控制查看命令开发
为了方便对平台与业务层的查看与控制，我们基于Libcmdline库开发了sansctl命令，可支持命令补全等。
发包工具开发
为了能进行千万级别的高性能测试，基于pktgen-dpdk进行开发使其可以构造DNS请求与控制发送速率功能的spktgen，主界面如下图：
抓包工具开发
由于现有tcpdump不能抓取DPDK接管的网卡数据，也在其基础上开发可在DPDK下抓包的spktdump，以便调试与定位。
其他开发
从略。
踩过的坑架构模式选择
DPDK提供了两种模式可供选择：Run-to-completion与pipeline模式。在官网文档与DPDK开发者大会中都提到了这两种模式，但都没说哪种模式更好，要看场景而定。我们在最初设计时，不仅考虑DNS服务器还考虑以后负载均衡设备的使用，选择了可支持这两种模式。
在测试性能时，发现某种情况下不同模式都有优缺点，经常在这两种模式中来回切换测试，造成了一些干扰与浪费了点时间。
编译选项一致
在测试性能时一定使用-O3选项并且编译选项需与DPDK本身app编译选项一致。否则会影响很大的性能。
DPDK本身app编译选项可以在编译目录下的.XXX.o.cmd文件查看到。
变量percore化
所用的全局变量尽量percore化，这样可以防止cache miss。例如统计部分要用percore化，计算或显示时再把他们加到一起，这个也影响不小的性能。
代码逻辑简化
由于业务层代码是从内核版本中移植过来的，老早功能就通过了，但性能一直上不来，后来经过代码review发现很多影响性能点，又重新优化或精简了下代码逻辑，去掉了不少冗余代码。
RCU锁占用性能
扩大RCU临界区
域名压缩占用性能
应答区中的域名不压缩。
有待完善DPDK 缺少配置文件
现在DPDK代码与核数越来越多,依然使用命令行参数的方式进行启动，可配置与阅读性比较差，应该有自己的配置文件进行解析即可。
尤其是网卡、队列、逻辑核配置序列太难配置了，尤其是使用核数比较多的情况。
例如：(0,0,2),(0,1,4),(0,2,6),(0,3,8),(0,4,10),(0,5,12),(0,6,14),(0,7,16),(0,8,18),(0,9,20),(0,10,22),(0,11,24),(0,12,26),(0,13,28)
不知道各位同学知不道有什么国际规范的缩写方式配置,请麻烦告知一下，OK？
pktgen-dpdk驱动bug
当使用pktgen-dpdk进行测试时，频繁的启停可能会使万兆光纤网卡处于DOWN状态，重启命令或reboot系统都不管用，必须对服务器进行冷重启才行，这对测试比较浪费时间或者远程调试操作堪忧。
examples下编码质量参差不齐
DPDK库本身的编码质量还是比较规范统一的，而其examples下的示例代码编码质量参差不齐。
fastNP本身
BOND与多网卡有待支持。
邻居发现与路由功能有待支持。
TCP协议栈有待支持。
虚拟化功能有待支持。
更高级语言功能有待支持。
Libc与系统调用劫持功能有待支持。
总结
经过这一段时间的开发，使得我对DPDK、内存、CPU、用户态网卡驱动有了更深的了解，使得性能达到了万兆网卡线速水平，单机抗攻击能力为1300万QPS，收发平衡能力为1000万QPS的预期目标，总之DPDK框架代码写得还是挺不错的，值得仔细研究，现在我只是对它怎么使用与部分源码有了一定的认识，很多精华部分有待深入剖析。
Footnotes
[^1]: DPDK: intel dpdk(Data Plane Development Kit,数据面开发套件)是 intel 公司发布的一款数据包转发处理套件；
[^2]: CloudXNS: 面向云计算的权威智能DNS。
[^3]: QPS: 每秒查询率(Query Per Second).
[^4]: BIND: Bind是一款开放源码的DNS服务器软件,Bind由美国加州大学Berkeley分校开发和维护的,全名为Berkeley Internet Name Domain, 它是目前世界上使用最为广泛的DNS服务器软件.
近期技术活动 ，期待与你线下相见
「北京、上海」 技术风暴强势来袭，4月22号北京上海双城联动
「北京」你离优秀架构师有多远？
商务合作，请加微信yunweibang555
