正文
TAP/TUN浅析
小程序：扫一扫查出行【扫一扫了解最新限行尾号】
复制小程序
转：http://www.cnblogs.com/yml435/p/5917628.html
参考链接：https://www.ibm.com/developerworks/cn/linux/1310_xiawc_networkdevice/
TAP 设备与 VETH 设备
TUN/TAP 设备是一种让用户态程序向内核协议栈注入数据的设备，一个工作在三层，一个工作在二层，使用较多的是 TAP 设备。VETH 设备出现较早，它的作用是反转通讯数据的方向，需要发送的数据会被转换成需要收到的数据重新送入内核网络层进行处理，从而间接的完成数据的注入。
图 3 .TAP 设备和 VETH 设备工作过程
如图所示，当备一个 TAP 设被创建时，在 Linux 设备文件目录下将会生成一个对应 char 设备，用户程序可以像打开普通文件一样打开这个文件进行读写。当执行 write()操作时，数据进入 TAP 设备，此时对于 Linux 网络层来说，相当于 TAP 设备收到了一包数据，请求内核接受它，如同普通的物理网卡从外界收到一包数据一样，不同的是其实数据来自 Linux 上的一个用户程序。Linux 收到此数据后将根据网络配置进行后续处理，从而完成了用户程序向 Linux 内核网络层注入数据的功能。当用户程序执行 read()请求时，相当于向内核查询 TAP 设备上是否有需要被发送出去的数据，有的话取出到用户程序里，完成 TAP 设备的发送数据功能。针对 TAP 设备的一个形象的比喻是：使用 TAP 设备的应用程序相当于另外一台计算机，TAP 设备是本机的一个网卡，他们之间相互连接。应用程序通过 read()/write()操作，和本机网络核心进行通讯。
VETH 设备总是成对出现，送到一端请求发送的数据总是从另一端以请求接受的形式出现。该设备不能被用户程序直接操作，但使用起来比较简单。创建并配置正确后，向 其一端输入数据，VETH 会改变数据的方向并将其送入内核网络核心，完成数据的注入。在另一端能读到此数据
TAP口的应用场景：
这是比较标准的网络流程图，报文从网卡被接收上来，当然这里的网卡是被内核给托管了。 也就是说网卡接收的报文都交给内核
进行了处理。内核收到报文后依次走preRoute,LocalIn将报文进行转发或者发到LocalIn。再到用户态被应用程序进行处理。当然，如
果是发送报文的话，那就是将报文走LocalOut，然后如果目的地址是本机就转发到本机，否则走路由，然后postRoute.再进入网卡。
这是在PC机上的流程，但是现在的转发设备如交换机，路由器，那就有点不一样了。假如用的是DPDK来接发数据报文。情况就有点不样了。
DPDK对网卡进行了托管，内核没有直接管理网卡。
如图所以，网卡被DPDK进行管理，DPDK接收和发送网卡的报文。然后报文的转发等处理流程，在用户态进行处理。
当然在这种情况下，如果报文不是从本机发出（指的是，不是由本机的内核态发出），而且接收的时候，也不是由
本机进行接收（意思是目的地址不是本机）。那么这套流程走起来完全是可以的。
但是你们平时用网页管理那个路由器是怎么个实现法，例如，你访问192.168.1.1，然后就会出现一个路由器配
置的页面（这里是指家用路由器哈，转发用的不是DPDK。。。。但是打个比方）。很明显，路由器上apache 的流量
是从路由器发出，也会接收流量。那这个如何实现。
这里就会用到TAP口了。
于是就变成了这个样子，也就是说，当用DPDK把这些报文都收上来，然后对目的IP进行判断（这部分在用户态）。
如是到本机的报文，那么它就交给TAP口，然后TAP收到这个报文后，就会走preRoute -----> LocalIn----->用户态。
然后用户态对应的socket就会收到你发的报文里面的内容。
如果是Apache产生的信息，那么它当然会调用socket进行发送了，也就是会先进入内核，但是无法直接进入网卡了。
现在只能通过TAP口进入用户态，然后在用户态进行转发，再用DPDK发送到对应的网卡。
使用 TAP 设备的应用程序相当于另外一台计算机，TAP 设备是本机的一个网卡，他们之间相互连接。应用程序通过 read()/write()操作，和本机网络核心进行通讯
