TUN/TAP虚拟网卡在25Gbps物理网卡的环境下可以接近25Gbps的转发能力吗？
答案当然是可以。
实现简单到让你怀疑人生！
首先看一个图：
上周末写了点代码，这周贴上去：
https://github.com/marywangran/golang-HiPac-tunnel
为什么人们总是觉的tun网卡性能弱鸡？答案很简单， 因为tun太简单，而且太老旧。 简单和老旧是互联网杨格(younger)们所不认可的。简单陈旧的东西，不出KPI，显示不出自己的牛逼。
没有人在 当下时兴的虚拟化 领域(virtio？)之外使用multiqueue-tun网卡。tun/tap早已被人遗忘，很少有人知道multiqueue-tun如何使用，没人追求它们的极致。
有几个小tips值得注意：
-
tun+udp处理数据报文的时延是固定的，在我测试机上大概4ms左右，如果你用直连环境，物理网卡rtt仅仅0.00x级别，而tun处理则达到0.4级别，看上去是弱了几十上百倍，但实际上，tun的处理延时不会随着rtt的增加而增加，现实情况是，在50ms的rtt情形，物理网卡处理延时为50ms，而tun处理延时则是50.3ms。
-
小包情形若想高性能，必须全双工！但是TCP本质上是半双工的，TCP虽然宣称两个方向全双工，但是在任意一个方向，由于存在data和ack两个路径，它就是半双工的！在中间节点处理上，必须区分两个方向，实现全双工。
-
中断是可恶的，但也是没有办法的，所以要用busy poll。DPDK可以这么玩，实际上使用内核协议栈也可以。
这就是全部了。
对了，现如今，内核实现的tun驱动依然将TCP两个方向绑定到了同一个CPU上，所以我把这个给改了。详见代码kmod目录。
浙江温州皮鞋湿，下雨进水不会胖。