为什么会提上述的标题？我们知道 “KVM” 虚拟机网络底层是基于 “br0网桥 + tap0设备” 为虚拟机提供网络支撑的，但令人两难的是如何基于它该方案实现 “软件路由网关服务器”？

从理论上该解决方案是可以实现的，然而人们之所以考虑这种相对复杂架构的方案，仅仅只是调用系统接口直接控制 “物理以太网卡” 来读写 “二层网络，链路层，以太网帧”，人们适用 C/C++ 应用层上高度优化，吞吐峰值上限仍被被卡死 75~150Mbps，相对看上去软件网关吞吐性能已经很快了，但物理以太网卡是1GE端口速率，其巨大的带宽吞吐浪费，令人们务必难以忍受，想一想1GE能同时为多少个设备提供流畅的8K/60FPS音视频流媒体带宽保证吞吐？

如果我们采取 eth0+br0+tap0 架构，那么我们可以令应用层写以太网帧到 “eth0物理网卡” 的带宽吞吐，可拉满最大峰值“即上GE级带宽吞吐”，PING testing RTT <= 1ms，这似乎是极度令人振奋的讯息，然现实往往非常的骨感且令人感到无尽的痛苦。

为什么让人痛苦且无奈？因为 “BR网桥” 于驱动层代码实现还包含 “IP网关路由” 的功能，举例：

设：

br0: 192.168.0.80 网桥IP地址

eth0: 0.0.0.0

tap0:0.0.0.0 虚拟化IP 192.168.0.88（不要为 “tap0” 设置IP/netmask）

那么访问局域网其它网络设备跟踪 192.168.0.88 的路由途径，则其路由途径为：

TTL #1: 192.168.0.80

TTL #2: 192.168.0.88

当然这也包括来自双方IP报文会被“br网桥”做TTL生命周期检查及重设TTL及帧校验和，它并不是一个单纯的以太网虚拟二层交换机。

这意味着，我们无法通过 tap0+br0+eth0 的方案实现 “应用层超高性能-软件路由网关服务器”，因为人们知道一个发向网关服务器的 “IP帧”，IP目标地址不是网关服务器IP地址，否则IP路由器将无法实现，而发向该方案网关服务器的报文在 “br网桥” 驱动层代码实现之中将被丢弃，不会路由转发到tap0设备上面，tap0永远也无法收到来自其它主机通过网关上网发送的IP帧协议报文。