Android-Framework：Binder全解析，实现原理分析

最新推荐文章于 2023-06-23 23:54:48 发布

Android戏中戏

最新推荐文章于 2023-06-23 23:54:48 发布

阅读量210

点赞数

分类专栏： Android 文章标签： android linux 移动开发

本文链接：https://blog.csdn.net/m0_61418377/article/details/120036954

版权

Android 专栏收录该内容

22 篇文章 0 订阅

订阅专栏

共享内存 顾名思义，共享内存就是允许两个不相关的进程访问同一个逻辑内存。共享内存是在两个正在运行的进程之间共享和传递数据的一种非常有效的方式。不同进程之间共享的内存通常安排为同一段物理内存
套接字 套接字是更为基础的进程间通信机制，与其他方式不同的是，套接字可用于不同机器之间的进程间通信。

Linux上IPC原理

首先我们需要理解**User space（用户空间）**和 Kernel space（内核空间）。

为了保护用户进程不能直接操作内核，保证内核的安全，操作系统从逻辑上将虚拟空间划分为用户空间和内核空间。Linux 操作系统将最高的1GB字节供内核使用，称为内核空间，较低的3GB 字节供各进程使用，称为用户空间。

内核空间是Linux内核的运行空间，用户空间是用户程序的运行空间。为了安全，它们是隔离的，即使用户的程序崩溃了，内核也不会受到影响。内核空间的数据是可以进程间共享的，而用户空间则不可以。

那万一用户空间需要用到内核空间的数据或者需要访问内核空间怎么办呢？那这就需要借助系统调用了。系统调用是用户空间访问内核空间的唯一方式，保证了所有的资源访问都是在内核的控制下进行的，避免了用户程序对系统资源的越权访问，提升了系统安全性和稳定性。

好，基本知识了解了，我们看一下Linux上IPC是怎么实现的。

首先发送进程通过copy_from_user方法将发送的数据发送到内核缓存区，这期间会发生一次内存拷贝。

然后内核空间再通过copy_to_user方法将发送进程发送的数据传给接收进程，这期间会再一次发生内存拷贝。注意这两个方法是关键：

copy_from_user：将用户空间的数据拷贝到内核空间。
copy_to_user：将内核空间的数据拷贝到用户空间。

这就完成了一次跨进程通信，是不是感觉很简单？没错，确实不复杂，但是这个方式有两个问题，就是发送一次数据需要内存拷贝两次。第二个就是接收进程不知道发送进程要发送多大的数据，所以只能尽可能地往大了开辟内存或者事先在读取一次消息头来知晓数据大小，不是浪费空间就是浪费时间。那么Binder是怎么解决这个问题的呢？

Binder原理

emmmm看不懂，什么是映射？这都是啥?

先来讲一下这个映射，什么是映射呢？映射就是内存映射（mmap），是一种内存映射文件的方法，即将一个文件或者其他对象映射到进程的地址空间，实现文件磁盘地址和应用程序进程虚拟地址空间中一段虚拟地址的一一映射关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。

说得好，不过什么意思？

简单地说就是存在映射关系的双方，只要修改其中一方的内容，另一方也会发生改变。这个实现的手段是通过mmap方法来实现的。

**Binder没有物理介质，Binder是基于内存映射来实现的。**Binder这么做目的就是为了跨进程通信。如上图

Binder首先在内核空间创建了一个内核缓存区，然后又创建了一个数据接收缓存区。然后将内核缓存区和数据接收缓存区进行映射。
Binder再将接收缓存区和接收进程的用户空间地址建立映射关系。
发送进程通过copy_from_user发送了数据到内核缓存区，这里进行了一次内存拷贝。由于映射关系的存在，数据立马被同步到了接收进程的内存空间。完成跨进程通信。整个过程只进行了一次内存拷贝。

哇塞，看起来好像是这样啊。Google果然是牛X，这么好的方法都能想得到，Linux发展这么多年怎么搞不出来Binder呢？其实也不是，Linux上也很早就有Binder了，Android系统之所以采用Binder机制来进行跨进程通信是有原因的。

Android为什么使用Binder

性能上 Binder内存拷贝只需要一次，除了共享内存一次也不需要以外，Binder的性能是最高的。
稳定性 Binder是基于C/S架构的，这个架构通常采用两层结构，在技术上已经很成熟了，稳定性是没有问题的。共享内存没有分层，难以控制，并发同步访问临界资源时，可能还会产生死锁。从稳定性的角度讲，Binder是优于共享内存的。
安全传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份；而Android作为一个开放的开源体系，拥有非常多的开发平台，App来源甚广，因此手机的安全显得额外重要；对于普通用户，绝不希望从App商店下载偷窥隐射数据、后台造成手机耗电等等问题，传统Linux IPC无任何保护措施，完全由上层协议来确保。Android系统中对外只暴露Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行。
语言 Linux是基于C语言(面向过程的语言)，而Android是基于Java语言(面向对象的语句)，而对于Binder恰恰也符合面向对象的思想，将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中
开源协议 Linux内核是开源的系统，所开放源代码许可协议GPL保护。该协议具有“病毒式感染”的能力，只要进行了系统调用，调用到内核，那么也必须遵守GPL开源协议。Android 之父 Andy Rubin对于GPL显然是不能接受的，为此，Google巧妙地将GPL协议控制在内核空间，将用户空间的协议采用Apache-2.0协议。同时在GPL协议与Apache-2.0之间的Lib库中采用BSD证授权方法，有效隔断了GPL的传染性

Binder作用

好吧，你说的很多确实很有道理，可是Binder到底有什么作用呢，我日常开发也没用到Binder 啊。

不不不，你错了，你的日常开发肯定用到了Binder，只不过你不知道而已。就以最常见的startActivity来说吧，经过层层调用，最后还是通过Binder来实现的。所以学习好Binder原理，更有利于我们了解Android系统的构建，也能开发出更高质量的APP。也是我们迈向高级Android开发工程师的必经之路~

Binder架构设计

Binder架构也是采用分层架构设计, 每一层都有其不同的功能。分为Java Binder，Native Binder，Kernel Binder 。

Binder进程间通信采用的是C/S架构，也就是常说的客户端，服务端模式。这是一个简化版的示意图

[图片上传中…(image-47e7ce-1599468127798-13)]

可以看到的是，除了clien端和serve端，还多出了一个ServiceManager。ServiceManager用于管理系统中的各种服务。首先，Server需要向ServiceManager中注册服务，然后client如果想要使用Server提供的服务，需要向ServiceManager中查询，查询到了就可以使用服务。需要注意的是，上面这个简化图中client并不能直接使用服务，而是通过Binder跨进程通信的方式间接的使用服务。

这是一个稍微复杂一点的图：

Client端和Server端直接全部都是通过虚线来连接的，也就表示虽然有调用关系，但是并不是直接调用。而是通过Binder实现的间接调用。需要注意的是此处的Service Manager是指Native层的ServiceManager（C++），并非指framework层的ServiceManager(Java)。

Client/Server/ServiceManage之间的相互通信都是基于Binder机制。既然基于Binder机制通信，那么同样也是C/S架构，则图中的3大步骤都有相应的Client端与Server端。

注册服务：首先Server注册到ServiceManager。该过程：Server所在进程是客户端，ServiceManager是服务端。
获取服务：Client进程使用Server前，须先向ServiceManager中获取Server的代理类BpBinder。该过程：BpBinder所在进程(app process)是客户端，ServiceManager是服务端。
使用服务： app进程根据得到的代理类BpBinder,便可以直接与Server所在进程交互。该过程：BpBinder所在进程(app process)是客户端，BBiner所在进程(system_server)是服务端。

这3大过程每一次都是一个完整的Binder IPC过程。

既然第一步是注册服务，那我们先从注册服务开始看起，看看服务到底是如何注册到系统中的。

服务注册

以MediaServer为例，看看它是如何注册的。为了方便阅读，全部剔除了Log等代码。

首先是MediaServer的入口函数：

//frameworks/av/media/mediaserver/main_mediaserver.cpp
int main(int argc __unused, char **argv __unused)
{
    signal(SIGPIPE, SIG_IGN);
    //获取ProcessState实例
    sp<ProcessState> proc(ProcessState::self());
    //获取BpServiceManager对象
    sp<IServiceManager> sm(defaultServiceManager());

    InitializeIcuOrDie();
    //注册MediaPlayerService
    MediaPlayerService::instantiate();//1
    ResourceManagerService::instantiate();
    registerExtensions();
    //启动Binder线程池
    ProcessState::self()->startThreadPool();
    //当前线程加入到线程池
    IPCThreadState::self()->joinThreadPool();
}

第二行代码是获取ProcessState，ProcessState是何许人也？ProcessState从名称就可以看出来，用于代表进程的状态

我们看一下ProcessState::self()这个方法：

//frameworks/native/libs/binder/ProcessState.cpp
sp<ProcessState> ProcessState::self()
{
    Mutex::Autolock _l(gProcessMutex);
    if (gProcess != NULL) {
        return gProcess;
    }
    gProcess = new ProcessState("/dev/binder");//1
    return gProcess;
}

这是一个单例模式用于获取ProcessState，每个进程只有一个。眼尖的小伙伴应该发现了一个熟悉的字符串，没错就是这个/dev/binder，这就是没有物理介质的Binder驱动。那么ProcessState的构造方法又做了哪些事情呢？

ProcessState

//frameworks/native/libs/binder/ProcessState.cpp
ProcessState::ProcessState(const char *driver)
    : mDriverName(String8(driver))
    , mDriverFD(open_driver(driver))//1 这一行很重要，打开了Binder驱动
    , mVMStart(MAP_FAILED)
    , mThreadCountLock(PTHREAD_MUTEX_INITIALIZER)
    , mThreadCountDecrement(PTHREAD_COND_INITIALIZER)
    , mExecutingThreadsCount(0)
    , mMaxThreads(DEFAULT_MAX_BINDER_THREADS)
    , mStarvationStartTimeMs(0)
    , mManagesContexts(false)
    , mBinderContextCheckFunc(NULL)
    , mBinderContextUserData(NULL)
    , mThreadPoolStarted(false)
    , mThreadPoolSeq(1)
{
    if (mDriverFD >= 0) {
        //2 mmap内存映射
        mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
        if (mVMStart == MAP_FAILED) {
            // *sigh*
            ALOGE("Using %s failed: unable to mmap transaction memory.\n", mDriverName.c_str());
            close(mDriverFD);
            mDriverFD = -1;
            mDriverName.clear();
        }
    }
    LOG_ALWAYS_FATAL_IF(mDriverFD < 0, "Binder driver could not be opened.  Terminating.");
}

注释1处，ProcessState的构造方法首先调用了open_driver()方法，这个方法一看名字就知道，是打开驱动嘛，它的参数不就是我们刚才看到的传进去的/dev/binder，也就是说ProcessState在构造方法处打开了Binder驱动。看看它是怎么打开驱动的吧

open_driver

//frameworks/native/libs/binder/ProcessState.cpp
static int open_driver(const char *driver)
{
    int fd = open(driver, O_RDWR | O_CLOEXEC);//1
    if (fd >= 0) {
        ...
        size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;
        result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);//2
        if (result == -1) {
            ALOGE("Binder ioctl to set max threads failed: %s", strerror(errno));
        }
    } else {
        ALOGW("Opening '%s' failed: %s\n", driver, strerror(errno));
    }
    return fd;
}

注释1处用于打开/dev/binder设备并返回文件操作符fd，这样就可以操作内核的Binder驱动了。

Linux 系统中，把一切都看做是文件，当进程打开现有文件或创建新文件时，内核向进程返回一个文件描述符，文件描述符就是内核为了高效管理已被打开的文件所创建的索引，用来指向被打开的文件，所有执行I/O操作的系统调用都会通过文件描述符。

注释2处的ioctl函数的作用就是和Binder设备进行参数的传递，这里的ioctl函数用于设定binder支持的最大线程数为15（maxThreads的值为15）。

在用户空间，使用ioctl方法系统调用来控制设备。这是方法原型：
/*
fd:文件描述符
cmd:控制命令
...:可选参数:插入*argp，具体内容依赖于cmd*/
int ioctl(int fd,unsigned long cmd,...);
用户程序所作的只是通过命令码告诉驱动程序它想做什么，至于怎么解释这些命令和怎么实现这些命令，这都是驱动程序要做的事情。所以在用户空间我们想做什么事情都是通过这个方法以命令的形式告诉Binder驱动，Binder驱动收到命令执行相应的操作。

mmap

在刚才的注释2处就是大名鼎鼎的内存映射。内存映射函数mmap，给binder分配一块虚拟地址空间。它会在内核虚拟地址空间中申请一块与用户虚拟内存相同大小的内存，然后再申请物理内存，将同一块物理内存分别映射到内核虚拟地址空间和用户虚拟内存空间，实现了内核虚拟地址空间和用户虚拟内存空间的数据同步操作。

这是函数原型：

//原型
/*
addr: 代表映射到进程地址空间的起始地址，当值等于0则由内核选择合适地址，此处为0；
size: 代表需要映射的内存地址空间的大小，此处为1M-8K；
prot: 代表内存映射区的读写等属性值，此处为PROT_READ(可读取);
flags: 标志位，此处为MAP_PRIVATE(私有映射，多进程间不共享内容的改变)和 MAP_NORESERVE(不保留交换空间)
fd: 代表mmap所关联的文件描述符，此处为mDriverFD；
offset：偏移量，此处为0。

此处 mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
*/
void* mmap(void* addr, size_t size, int prot, int flags, int fd, off_t offset)

总的来说，ProcessState做了两件事情，一是打开Binder驱动并返回文件操作符fd，二是通过mmap为Binder分配了一块虚拟内存空间，以达到内存映射的目的。

MediaPlayerService::instantiate

这个方法呢就是注册服务：

void MediaPlayerService::instantiate() {
    //注册服务
    defaultServiceManager()->addService(String16("media.player"), new MediaPlayerService());
}

defaultServiceManager返回的是BpServiceManager，这里先不讲BpServiceManager，你只需要知道BpServiceManager它实现了IServiceManager，并且通过内部有一个变量mRemote= BpBinder，BpBinder用来实现跨进程通信。故此处等价于调用BpServiceManager->addService。

BpBinder是Client端与Server交互的代理类，而BBinder则代表了Server端。BpBinder和BBinder是一一对应的。BpBinder会通过handle来找到对应的BBinder。在ServiceManager中创建了BpBinder，通过handle(值为0)可以找到对应的BBinder。

来看一下具体代码

//frameworks/native/libs/binder/IServiceManager.cpp
virtual status_t addService(const String16& name, const sp<IBinder>& service, bool allowIsolated) {
    Parcel data, reply; //Parcel是数据通信包
    //写入头信息"android.os.IServiceManager"
    data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());   
    data.writeString16(name);        // name为 "media.player"
    data.writeStrongBinder(service); // MediaPlayerService对象
    data.writeInt32(allowIsolated ? 1 : 0); // allowIsolated= false
    //remote()指向的是BpBinder对象
    status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
    return err == NO_ERROR ? reply.readExceptionCode() : err;
}

服务注册过程：向ServiceManager注册服务MediaPlayerService，服务名为”media.player”。addService函数的作用就是将请求数据打包成data，然后传给BpBinder的transact函数。

data.writeStrongBinder(service)这行代码中，将Binder对象进行了扁平化，转换成flat_binder_object对象。

对于Binder实体，则cookie记录Binder实体的指针；
对于Binder代理，则用handle记录Binder代理的句柄；(句柄这个翻译真的是脑残，你可以直接理解为ID或者编号)

BpBinder::transact

我们看一下transact函数:

// frameworks/native/libs/binder/BpBinder.cpp
status_t BpBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    if (mAlive) {
        status_t status = IPCThreadState::self()->transact(
            mHandle, code, data, reply, flags);
        if (status == DEAD_OBJECT) mAlive = 0;
        return status;
    }

    return DEAD_OBJECT;
}

Binder代理类调用transact()方法，真正工作还是交给IPCThreadState来进行transact工作。先来看看IPCThreadState::self的过程。

IPCThreadState::self

//frameworks/native/libs/binder/IPCThreadState.cpp
IPCThreadState* IPCThreadState::self()
{
    if (gHaveTLS) {
restart:
        const pthread_key_t k = gTLS;
        IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k);
        if (st) return st;
        return new IPCThreadState;  //初始IPCThreadState 
    }

    if (gShutdown) return NULL;

    pthread_mutex_lock(&gTLSMutex);
    if (!gHaveTLS) { //首次进入gHaveTLS为false
        if (pthread_key_create(&gTLS, threadDestructor) != 0) { //创建线程的TLS
            pthread_mutex_unlock(&gTLSMutex);
            return NULL;
        }
        gHaveTLS = true;
    }
    pthread_mutex_unlock(&gTLSMutex);
    goto restart;
}

TLS是指Thread local storage(线程本地储存空间)，每个线程都拥有自己的TLS，并且是私有空间，线程之间不会共享。通过pthread_getspecific/pthread_setspecific函数可以获取/设置这些空间中的内容。从线程本地存储空间中获得保存在其中的IPCThreadState对象。这里可以得知IPCThreadState::self()实际上是为了创建IPCThreadState.

IPCThreadState

//frameworks/native/libs/binder/IPCThreadState.cpp
IPCThreadState::IPCThreadState()
    : mProcess(ProcessState::self()),
      mMyThreadId(gettid()),
      mStrictModePolicy(0),
      mLastTransactionBinderFlags(0)
{
    pthread_setspecific(gTLS, this);
    clearCaller();
    mIn.setDataCapacity(256);
    mOut.setDataCapacity(256);
}

pthread_setspecific函数用于设置TLS，将IPCThreadState::self()获得的TLS和自身传进去。每个线程都有一个IPCThreadState，每个IPCThreadState中都有一个mIn、一个mOut,它们都是Parcel对象。成员变量mProcess保存了ProcessState变量(每个进程只有一个)。

mIn 用来接收来自Binder设备的数据，默认大小为256字节；
mOut用来存储发往Binder设备的数据，默认大小为256字节。

那这里构造完了，看一下IPCThreadState的transact函数：

IPCThreadState::transact

status_t IPCThreadState::transact(int32_t handle,
                                  uint32_t code, const Parcel& data,
                                  Parcel* reply, uint32_t flags)
{
    status_t err = data.errorCheck(); //数据错误检查
    flags |= TF_ACCEPT_FDS;
    ....
    if (err == NO_ERROR) { // 传输数据
        err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
    }
    ...

    if ((flags & TF_ONE_WAY) == 0) {
        if (reply) {
            //等待响应 
            err = waitForResponse(reply);
        } else {
            Parcel fakeReply;
            err = waitForResponse(&fakeReply);
        }

    } else {
        //oneway，则不需要等待reply的场景
        err = waitForResponse(NULL, NULL);
    }
    return err;
}

IPCThreadState进行transact事务处理分3部分：

errorCheck() //数据错误检查
writeTransactionData() // 传输数据
waitForResponse() //等待响应

其中writeTransactionData函数用于传输数据，其中第一个参数BC_TRANSACTION代表向Binder驱动发送命令协议，向Binder设备发送的命令协议都以BC_开头，而Binder驱动返回的命令协议以BR开头。

我们就要看看到底是怎么写进去数据的：

IPCThreadState.writeTransactionData

//frameworks/native/libs/binder/IPCThreadState.cpp
status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,
    int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer)
{
    binder_transaction_data tr;
    tr.target.ptr = 0;
    tr.target.handle = handle; // handle = 0
    tr.code = code;            // code = ADD_SERVICE_TRANSACTION
    tr.flags = binderFlags;    // binderFlags = 0
    tr.cookie = 0;
    tr.sender_pid = 0;
    tr.sender_euid = 0;

    // data为记录Media服务信息的Parcel对象
    const status_t err = data.errorCheck();
    if (err == NO_ERROR) {
        tr.data_size = data.ipcDataSize();  // mDataSize
        tr.data.ptr.buffer = data.ipcData(); //mData
        tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t); //mObjectsSize
        tr.data.ptr.offsets = data.ipcObjects(); //mObjects
    } else if (statusBuffer) {
        ...
    } else {
        return (mLastError = err);
    }

    mOut.writeInt32(cmd);         //cmd = BC_TRANSACTION
    mOut.write(&tr, sizeof(tr));  //写入binder_transaction_data数据
    return NO_ERROR;
}

binder_transaction_data结构体是binder驱动通信的数据结构，该过程最终是把Binder请求码BC_TRANSACTION和binder_transaction_data结构体写入到mOut。其中handle的值用来标识目的端，注册服务过程的目的端为service manager，此处handle=0所对应的是binder_context_mgr_node对象，正是service manager所对应的binder实体对象。

transact方法中执行完writeTransactionData方法后，接下来就会执行waitForResponse()方法

IPCThreadState.waitForResponse

//frameworks/native/libs/binder/IPCThreadState.cpp
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
    uint32_t cmd;
    int32_t err;
    while (1) {
        if ((err=talkWithDriver()) < NO_ERROR) break;//1
        err = mIn.errorCheck();
        if (err < NO_ERROR) break;
        if (mIn.dataAvail() == 0) continue;
        cmd = (uint32_t)mIn.readInt32();
        switch (cmd) {
        case BR_TRANSACTION_COMPLETE:
            if (!reply && !acquireResult) goto finish;
            break;

        case BR_DEAD_REPLY:
            err = DEAD_OBJECT;
            goto finish;
       ...
        default:
            //处理各种命令协议
            err = executeCommand(cmd);
            if (err != NO_ERROR) goto finish;
            break;
        }
}
finish:
    ...
    return err;
}

这里开启了一个死循环，然后从talkWithDriver()方法中发送并读取数据。在waitForResponse过程, 首先执行BR_TRANSACTION_COMPLETE；另外，目标进程也就是Server端收到事务后，处理BR_TRANSACTION事务。然后发送给当前进程也就是Client端，再执行BR_REPLY命令。这是通信的具体流程：

[图片上传中…(image-683419-1599468127794-12)]
T;
goto finish;
…
default:
//处理各种命令协议
err = executeCommand(cmd);
if (err != NO_ERROR) goto finish;
break;
}
}
finish:
…
return err;
}


这里开启了一个死循环，然后从`talkWithDriver()`方法中发送并读取数据。在`waitForResponse`过程, 首先执行`BR_TRANSACTION_COMPLETE`；另外，目标进程也就是Server端收到事务后，处理`BR_TRANSACTION`事务。 然后发送给当前进程也就是Client端，再执行`BR_REPLY`命令。这是通信的具体流程：

[图片上传中...(image-683419-1599468127794-12)]

Android戏中戏

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Android-Framework：Binder全解析，实现原理分析

共享内存顾名思义，共享内存就是允许两个不相关的进程访问同一个逻辑内存。共享内存是在两个正在运行的进程之间共享和传递数据的一种非常有效的方式。不同进程之间共享的内存通常安排为同一段物理内存套接字套接字是更为基础的进程间通信机制，与其他方式不同的是，套接字可用于不同机器之间的进程间通信。Linux上IPC原理首先我们需要理解**User space（用户空间）**和 Kernel space（内核空间）。为了保护用户进程不能直接操作内核，保证内核的安全，操作系统从逻辑上将虚拟空间划分为用..
复制链接

扫一扫