對于模擬器而言，讓模擬器中的客戶 Android 系統內的進程連接外部網絡，與通過 adb forward 的方式，讓外部網絡的程序，連接模擬器的客戶 Android 系統內的服務相比，網絡拓撲結構有著非常大的不同。這種拓撲結構的差異，對模擬器內的客戶 Android 系統中的進程與外部應用進程之間的網絡連接的許多方面都有著非常大的影響，如連接的穩定性，性能等等。

模擬器連接外部網絡時的情況

首先來看模擬器的客戶 Android 系統內部的進程與外部服務之間建立 TCP 連接的情況。

首先啟動一個服務，讓它監聽 TCP 的 18960 端口，以接受連接。然后在模擬器的客戶 Android 系統內啟動一個進程，連接前面啟動的 TCP 服務。查看此時主機上網絡端口的打開情況，將看到如下的情形：

hanpfei0306@ThundeRobot:~/emu-2.4-release/external/qemu$ lsof -i | grep 18960 qemu-syst 13159 hanpfei0306 47u IPv4 13995747 0t0 TCP 10.240.209.153:44658->10.240.209.153:18960 (ESTABLISHED) EventServ 24086 hanpfei0306 4u IPv4 13991611 0t0 TCP *:18960 (LISTEN) EventServ 24086 hanpfei0306 10u IPv4 13991620 0t0 TCP 10.240.209.153:18960->10.240.209.153:44658 (ESTABLISHED)

可以看到，qemu 進程與客戶 Android 系統中的進程的連接目標建立了一條 TCP 連接。不難想象，在這種場景下，網絡拓撲結構將像下面這樣：

模擬器內客戶 Android 系統內的進程 <——-> emulator 進程 <——-> 連接目標（事件服務器）

外部應用通過端口轉發連入客戶 Android 系統

通過 adb forward 做端口轉發，將宿主機上的某個端口映射到客戶 Android 系統內的某個端口上，如將宿主機上的 TCP 10977 端口，映射到客戶 Android系統內的 TCP 10977 端口上。此時我們查看宿主機上與 10977 端口相關的網絡連接，將如下面所示這樣：

hanpfei0306@ThundeRobot:~/emu-2.4-release/external/qemu$ lsof -i | grep 10977 adb 3041 hanpfei0306 29u IPv4 13726863 0t0 TCP localhost:10977 (LISTEN) adb 3041 hanpfei0306 31u IPv4 14035891 0t0 TCP localhost:10977->10.240.209.153:51168 (ESTABLISHED) telnet 24980 hanpfei0306 3u IPv4 14041367 0t0 TCP localhost:51168->localhost:10977 (ESTABLISHED) hanpfei0306@ThundeRobot:~/emu-2.4-release/external/qemu$ lsof -i | grep adb | grep 10977 adb 3041 hanpfei0306 29u IPv4 13726863 0t0 TCP localhost:10977 (LISTEN) adb 3041 hanpfei0306 31u IPv4 14035891 0t0 TCP localhost:10977->10.240.209.153:51168 (ESTABLISHED)

可以看到，端口轉發實際上是讓 adb 起一個 server socket，如上圖，adb 作為外部進程和客戶 Android 系統內的 server 進程通信的中轉橋梁。

再通過 adb shell 查看客戶 Android 系統內，與 10977 端口相關的網絡連接。不難想象，在這種場景下，網絡拓撲結構將像下面這樣：

模擬器內客戶 Android 系統內的進程 <——-> 模擬器內客戶 Android 系統內的 adbd <——-> emulator 進程 <——-> 宿主系統中的 adb 守護進程 <——-> 連接目標（事件服務器）

外部應用通過端口轉發連入客戶 Android 系統內進程的情形下，整個網絡連接鏈路要不內部連接外部長得多，這么長的鏈路，難免會使這種連接的穩定性大為降低。端口轉發還有一個比較嚴重的問題，無論外部應用連接的目標模擬器是哪一個，這些連接都必定要先經過 adb 守護進程，adb 守護進程難免常常會成為一個性能瓶頸；此外，連接的發起應用，對于連接狀態的感知也將變得沒有那么靈敏，如客戶 Android 系統內連接的目標應用進程已經死掉，這種狀態要通過客戶 Android 系統內的 adbd，模擬器進程本身，以及 adb 守護進程三個環節才能傳達給發起連接的應用。

打賞

Done.

總結

以上是生活随笔為你收集整理的QEMU 网络虚拟化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。