用户态TCP协议栈的调研

一、各种用户态socket的对比
1、MTCP
简单介绍:
韩国高校的一个科研项目,在DPDK的2016年的技术开发者大会上有讲,所以intel将这个也放到了官方上,所以一般搜索DPDK的用户态的协议栈的时候就能够搜索到了这个;
特点:
有准确的测试数据,我们本地也测试了其性能:在EP的单核上可以达到4W connect/sec 。然后因为内存限制,连接数当时是60W连接占用了18G的内存;
优点:
1。有准确的性能测试数据
2。有一定的关注度,有开源社区;
3. 自己实现了一套epoll+socket。与内核的epoll在同一个线程不能同时使用。
4.协议栈全面,包含了二三层的逻辑
5. 基本兼容传统的socket操作。代码改动不算大;
缺点:
1。稳定性不高,中途出现了多次异常退出;
2。内部代码逻辑清晰度还有些欠缺;
3。内存占用太大,例如接受的buff都是每一个连接一个、
4。内部有大量的锁操作~逻辑比较复杂;
5。只支持TCP协议
6.内部有很多内存copy操作。网卡数据到协议栈copy一次,协议栈缓存时copy一次,协议栈到用户态又需要copy一次数据;

目前如果要嵌入系统中需要做一下几个方面的工作:
1。因为我们已经有自己的二三层逻辑,所以需要将MTCP原来的二三层给拆除,只保留TCP;
2。需要针对其稳定性进行优化,解决各种异常退出的问题;
3。需要针对其内存占用进行优化;
4。如果需要支持系统epoll和mtcp epoll兼容需要进行逻辑框架的改进~
5。如果需要支持其他socket的时候,需要重新设计并加入udp+raw一类的socket的支持;
6. 如果需要支持多个应用同时使用MTCP的时候也需要改进MTCP
总结:
MTCP不支持多进程模型,而且在稳定性差有一些问题,然后对UDP与RAW不支持;需要进行一系列的修改后才能进入我们系统;
2.libuinet BSD协议栈用户态的库
libuinet是开源社区维护的一个使用openbsd内核协议栈编译出来的一个协议栈的库,使用的bsd的原生协议栈。
优点:
1。来源于BSD协议栈,功能支持全面,所以socket,ipv4 ipv6都支持;
2。来源于BSD协议栈,稳定性与社区活跃性都是不错的;
3。bsd协议栈提供接口与linux socket编程接口兼容性好;
缺点:
1。代码太复杂,因为是从bsd代码中porting过来的,所以有大量对我们来说无用的代码;
2。不支持DPDK。而且二三四层绑定比较紧密~想拆出来不太容易;
3。也是线程模型~与MTCP有同样的缺点;
4。除了协议栈还有大量中间代码(例如协议栈创建了4个线程,而且这个线程不是用标准的pthread创建,也就是它自己还带了一套线程库)
5. 性能没有测试数据,以及内存占用等都没有对应的数据~而且如果一旦出现性能问题~因为代码过与复杂,优化上风险比较大;
总结:bsd用户态协议栈功能强大,社区活跃,但是复杂度太高,而且没有现成的与dpdk对接的例子,移植成本比较高,性能上没有准确数据~如果有性能问题,优化难度较大;
3. 中国人写的tcp协议栈
通过不断的搜索和对比代码,找到了一个简洁版本的 TCP,是中国的一个热爱开源事业的人写的~
Xiaochen Wang <wangxiaochen0@gmail.com> 搜索过内核提交PATCH 华人中排100+
通过分析代码与其实现:
优点:
1。代码简洁,代码实现逻辑简单,没有太多复杂的信息,实现原理与内核一致;
2。代码量较少,总共TCP的代码连注释就在4K行左右~公司私有维护可以hold住。
3。功能全,支持TCP SOCKET UDP SOCKET RAW socket;
4。兼容性好~设计的api接口基本与原来的socket接口一致,便于迁移;
5。通过代码优化可以做到网卡到用户态0 copy,提升效率;
6。内存占用小~测试过1W连接不足1M的内存占用。
缺点:
1。有些查找算法需要优化~;例如查找流表;
2。也不支持DPDK(目前已经修改好DPDK对接的demo)
3。不支持多线程的协议栈(数据结构的设计的时候没有考虑线程安全)
4。只支持阻塞模型的socket。不支持epoll和非阻塞的socket调用(目前已经有设计思路移植epoll)
5。作者已经不维护,性能还没有测试过。
总结:
代码简单,便于自己维护,优化,开发~但是因为没有开源社区的支持,需要自己熟悉代码,测试过程中没有出现异常挂掉的情况,但需要自己移植epoll上去,才可以实现多路IO复用;
4.其他用户态socket
调研了其他用户态的socket;
主要有
1。mirage-tcpip 这种不是C/C++语言实现;
2。net-next-nuse linux kernel stack的用户态实现;类似于bsd 的stack而且依赖于netmap;
3。LWIP UIP完全的嵌入式设计模式~没有socket这层概念;而且代码效率没有考虑,查找全部都是链表比较。
4。picotcp 与上面的lwip与UIP类似,但代码简洁~支持socket,但socket的使用风格与linux socket的风格差别很大;
总结:其他用户态的socket使用上差别与原来linux风格的差别较大~不方便兼容原来的程序;而且都需要修改才能支持DPDK,其中picotcp还是比较活跃的开源项目;
二、关于用户态socket使用上的总结
目前所有的用户态的socket程序,都一样都是协议栈是通过一个线程来支持的。所以APP都需要运行自己的tcp协议栈(四层协议栈),然后通过线程间通信方式将数据传输到用户的业务线程中;
总结起来都有大致如下的问题:
1。都是线程协议栈模型,而且这个协议栈线程包含了二三层;
2。目前对于多进程模型都没有较好的解决方案;
3。epoll与系统的epoll不能同时使用,有些多路复用没有实现;
三、关于用户态socket模型的思考
其实我们二三层转发(其中包含NAT)都有了自己的解决方案;所以我们不需要在用户态socket这一层去再实现一次二三层~;
如果有多进程模型更好的支持,应用程序编写的时候就可以完全不用关心到底是用户态的socket,还是kernel太的socket,使用成本将会更低~
所以我提出这样的模型:

1。用户态socket是一个单独的进程,它通过ring与dpdk server进行数据交互~
2。app通过信号量与ring与用户态socket进行交互,通过dpdk的ring,可以做到数据共享,减少copy;
3。通过信号量实现数据通知机制~从而实现epoll。
优势:应用程序本身只启动应用程序的业务,而不需要启动自己的协议栈。编程模型与之前linux kernel态的编程模型一直,应用开发者无需关心用户态socket的实现;而且通过动态库的方式可以实现,一个bin加载不同的so~就可以实现用户态socket与kerenl socket自由切换~;
层次分明,不用每个app一个协议栈,可以节省cpu的消耗;
缺点:目没有现有模型支持,需要大量的代码修改开发工作;开发周期较长;

另一种思路,继续继承原来类似于MTCP这种模型。所有的进程都有一个用户态socket协议栈的线程,每个用户态socket线程一个ring,与dpdk server进行数据交互;

优点:
1。修改代码量会比之前的方案少点儿~。就可以支持多进程的模型;
2。代码逻辑更加简单;
3。性能上可以保证,因为每个app一个协议栈,而这个协议栈线程会绑定cpu,所以性能上,不同APP他们的协议栈性能是不会互相干扰的;
缺点:
1。因为每个app一个协议栈线程,app挂了,协议栈也要对应重启;
2。每个app一个协议栈线程,协议栈线程会绑定CPU,所以比较浪费CPU的资源;
3。编程模型与之前的kernel socket编程模型有差别了,需要添加额外的启动socket线程的方法;
总结:
两种方法各有优缺点,主要看具体的应用场景。而且通过修改代码可以支持epoll多路I.O的机制。多个socket可以在一个线程中进行处理~
四、关于用户态socket epoll与系统epoll兼容的思考
现在的用户态的epoll与系统的epoll不能同时使用主要原因在与epoll_wait这个函数是一个阻塞的函数,在同一个线程中不可能同时处理两个阻塞的请求;
所以思路有两种:
1。把用户态socket epoll模拟成系统的epoll。
用户态epoll实现,是通过系统的信号量来实现的阻塞与唤醒,如果把这种信号量的通知机制改成fd实现,例如用户态socket事件通知是通过unix socket来实现的,就可以使用系统的epoll监听;从而把用户态的epoll变成系统态的epoll。
2。把系统态的epoll变成用户态的epoll;
系统态的epoll的阻塞。事件等待是通过系统的epoll_wait来实现的事件等待,如果我们启动一个线程来专门监听epoll_wait的事件。等epoll_wait成功以后通过信号量通知到用户态的epoll事件来实现,系统态epoll转换成用户态的epoll;
五、关于流表查询加速的优化的思考
现在我们有的产品的server中其实已经有了流表,可以在dpdk server 把报文送上来的时候,在mbuf的私有字段中就可以带上来流表hash的结果(index)。可以减少用户态socket查询flow的时间,提高速度,目前只是一种思路;


发布了146 篇原创文章 · 获赞 369 · 访问量 43万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览