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

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

答案当然是可以。

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

首先看一个图:
超猛tuntap虚拟网卡实现超猛UDP隧道_第1张图片

上周末写了点代码,这周贴上去:
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目录。

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

你可能感兴趣的:(tun驱动,虚拟网卡)