超猛tuntap虚拟网卡实现超猛UDP隧道

女爷i 2022-10-14 14:59 152阅读 0赞

TUN/TAP虚拟网卡在25Gbps物理网卡的环境下可以接近25Gbps的转发能力吗？

答案当然是可以。

实现简单到让你怀疑人生！

首先看一个图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70]

上周末写了点代码，这周贴上去：  
[https://github.com/marywangran/golang-HiPac-tunnel][https_github.com_marywangran_golang-HiPac-tunnel]

为什么人们总是觉的tun网卡性能弱鸡？答案很简单， ***因为tun太简单，而且太老旧。*** 简单和老旧是互联网杨格(younger)们所不认可的。简单陈旧的东西，不出KPI，显示不出自己的牛逼。

没有人在 ***当下时兴的虚拟化*** 领域(virtio？)之外使用multiqueue-tun网卡。tun/tap早已被人遗忘，很少有人知道multiqueue-tun如何使用，没人追求它们的极致。

有几个小tips值得注意：

1.  tun+udp处理数据报文的时延是固定的，在我测试机上大概4ms左右，如果你用直连环境，物理网卡rtt仅仅0.00x级别，而tun处理则达到0.4级别，看上去是弱了几十上百倍，但实际上，tun的处理延时不会随着rtt的增加而增加，现实情况是，在50ms的rtt情形，物理网卡处理延时为50ms，而tun处理延时则是50.3ms。
2.  小包情形若想高性能，必须全双工！但是TCP本质上是半双工的，TCP虽然宣称两个方向全双工，但是在任意一个方向，由于存在data和ack两个路径，它就是半双工的！在中间节点处理上，必须区分两个方向，实现全双工。
3.  中断是可恶的，但也是没有办法的，所以要用busy poll。DPDK可以这么玩，实际上使用内核协议栈也可以。

这就是全部了。

对了，现如今，内核实现的tun驱动依然将TCP两个方向绑定到了同一个CPU上，所以我把这个给改了。详见代码kmod目录。

浙江温州皮鞋湿，下雨进水不会胖。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70]: /images/20221014/c2145f0630cc41d5ae1a154498f2483c.png
[https_github.com_marywangran_golang-HiPac-tunnel]: https://github.com/marywangran/golang-HiPac-tunnel