对于模拟器而言，让模拟器中的客户 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 网络虚拟化相关推荐

网络虚拟化——QEMU虚拟网卡
写在前面网络虚拟化曾经只是内核虚拟化功能开发者才会关注的技术.但随着云计算模式和云原生概念的推广,云上业务的部署形态都已转向了虚拟机和容器,而两者都依赖网络虚拟化技术提供高性能网络功能,因此虚拟网络 ...
qemu网络配置-桥接-IOT固件模拟
QEMU网络策略在进行IOT固件模拟的过程中,我们需要进行poc的验证需要能够启动系统级的qemu模拟,这时候需要将固件文件系统传到qemu虚拟机中,我们需要通过qemu网络通信的方法去串通本机和q ...
网络虚拟化——SR-IOV
之前的多篇文章介绍了网络虚拟化常见的技术实现,特别是virtio/vhost技术的实现.虽然virtio/vhost架构显著改善了虚拟网络的性能,但virtio网卡仍然是软件模拟的设备,其性能稳定性和 ...
网络虚拟化——vhost-user
在上一篇文章(网络虚拟化--vhost_dillanzhou的博客-CSDN博客)中,介绍了vhost技术和vhost-net内核模块的原理.通过将virtio设备后端的数据面功能转移到内核中,vho ...
网络虚拟化——virtio
前言在上一篇文章(网络虚拟化--QEMU虚拟网卡)中,讨论了经典的网络设备全虚拟化技术.这种技术不需要guest内核对虚拟网络设备有任何的感知和特殊处理,但性能较差,一次读写操作可能会产生多次需要H ...
网络虚拟化——vhost
在上一篇文章(网络虚拟化--virtio)中,我们讨论了virtio技术的由来.原理和实现.virtio为虚拟IO设备提供了一套标准的接口和实现.同时由于其半虚拟化的特质,virtio驱动在设计和实现 ...
网络虚拟化——vduse
在上一篇文章<网络虚拟化-vDPA_dillanzhou的博客-CSDN博客>中,我们讨论了vDPA技术.通过vDPA技术,guest/host上的用户态/内核态virtio驱动都可以通过 ...
KVM 网络虚拟化基础 - 每天5分钟玩转 OpenStack（9）
网络虚拟化是虚拟化技术中最复杂的部分,学习难度最大. 但因为网络是虚拟化中非常重要的资源,所以再硬的骨头也必须要把它啃下来. 为了让大家对虚拟化网络的复杂程度有一个直观的认识,请看下图这是 Open ...
华为dra路由方式分为relay和proxy_华为云计算（3）——网络虚拟化
关注微信公众号IT小组,获取更多干货知识~ 一.网络虚拟化网络虚拟化在介绍网络虚拟化之前,需要考虑一个问题--为什么需要网络虚拟化呢?之所以要对网络进行虚拟化,是因为在没有进行虚拟化之前,每个服务 ...

QEMU 网络虚拟化

模拟器连接外部网络时的情况

外部应用通过端口转发连入客户 Android 系统

打赏

QEMU 网络虚拟化相关推荐

最新文章

热门文章