參考鏈接：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()操作，和本機網絡核心進行通訊