超猛tuntap虚拟网卡实现超猛UDP隧道_Netfilter,iptables/OpenVPN/TCP guard:-(

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

答案当然是可以。

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

首先看一个图：

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

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