纳秒级网络库【三】架构设计

https://github.com/QuarkCloud/quark-daemon.git发布的第一个版本作为基准。虽然没有实现我们最终的目标纳秒级网络库，但是大部分思想已经具备，后续将继续调整和优化。

在讨论整个架构设计之前，我们需要厘清几个问题：

第一、哪些因素会影响到延迟，这个论题在之前的文章《高性能服务系列》已经做了大量讨论。

第二、哪些因素可以降低延迟，这些因素主要是围绕新兴出现的软硬件技术来设计。首先是RSS，这个特性出现得比较早，所以不少网卡都支持。其次是offload，将CPU处理的操作卸载到网卡。

第三、新兴软件技术。linux在近些年为解决C10M问题，已经在内核中集成了xdp技术。英特尔在他的网卡芯片中集成dpdk技术，这个问题，我们在技术选型那篇文章已经讨论过，也许未来会发生改变，目前不再继续。微软也开始支持xdp技术，在github有个xdp-for-windows项目，该技术还没有成熟，还在实验阶段，留待未来支持。

围绕以上谈到的技术特征，我们设计一个新的网络库架构。

第一，基于RSS特性，我们建立一个master线程，多个io线程。master线程主要负责管理类操作，包括网络监听、连接创建和释放；而io线程只负责单纯网络IO。除了利用RSS避免跨核之间的内存缺页问题，还有一个重要的原因，内存分配也是相当耗时，这一点在低延迟实践中，非常重要。

第二，基于xdp技术，直接从网卡拷贝数据包到用户层，直接绕过linux内核。这个技术是一个关键点，因为网络IO的单次系统调用，都在微秒级别，只要使用传统的网络API，send/recv，基本不可能实现纳秒级的网络库。xdp技术基于ebpf，有三个级别，general,native,offload，offload需要网卡支持。

第三，无锁技术。可以参考liburing，该技术很有意思，关键数据架构是提交队列(SQ)和完成队列(CQ)。看到这两个名字，是不是很熟悉，完全就是IOCP的模样。IOCP和epoll差别在于，IOCP直接在内核中完成数据拷贝，再通知用户层，就很容易实现DMA，从网卡内存直接拷贝数据到用户层，实现ZeroCopy；而epoll需要在内核中先缓存好，再通知用户层，就必然存在一次拷贝。

纳秒级网络库实现极为困难，涉及到很多的技术细节，任何一个节点阻塞，都会导致整个流程的延迟提升。留待后续优化补充。