Windows遗产之RPC/DCOM:还在用吗，内部又有什么区别？

最新推荐文章于 2022-01-16 22:53:06 发布

weixin_34216196

最新推荐文章于 2022-01-16 22:53:06 发布

阅读量1.5k

点赞数

文章标签：操作系统网络 shell

原文链接：https://my.oschina.net/osexp2003/blog/606866

版权

本文探讨了RPC和DCOM在Windows操作系统中的角色，它们作为跨进程通信的技术，虽然逐渐退居幕后，但仍然在系统中扮演重要角色。RPC是基础，而DCOM是其C++实现。在本机上，RPC/DCOM依赖LPC Port，跨机器通信主要通过SMB协议。DCOM组件如DllHost.exe用于组件隔离，提高安全性。跨机器的DCOM使用复杂，通常涉及认证和权限问题。COM+作为COM的扩展，提供组件独立化、接口监视和事务管理等功能，但现代环境中应用较少。

摘要由CSDN通过智能技术生成

2019独角兽企业重金招聘Python工程师标准>>>

从原理和使用程度上看，微软没有必要，也的确没有要废弃RPC/DCOM的迹象，但是显然这些技术会长期退入幕后当作基础设施了。

他们都是跨进程间的通信的（跨机器自然也算是也），无非就是寻找接口，数据序列化反序列化，但他们的确是最高效的。

广为人知的point：

RPC是基础。DCOM可以看成RPC的C++版。
RPC/DCOM在本机使用时主要是依靠LPC Port（而他又使用共享内存，queue等东西）。用WinObj工具能够看到各种ALPC类型的东西，其中就有很多是RPC/DCOM生成的。
这类东西，别的系统里也有，例如Android里的Binder，非常类似于DCOM，只不过仅限于本机而已。而Mac OS X里也有XPC Service，NSProxy/NSConnection之类的。

不够广为人知的point：

RPC可以通过文件共享协议(SMB)来调用，也就是TCP端口445。这是SMB协议为RPC开的一个扩展。这时，RPC的认证也就委托给SMB了，这其实很方便实用。
RPC在本机的使用非常频繁，但在跨机器间的使用较少，几乎只限于微软做的服务(例如计算机管理，远程注册表...)。
通过注册表把普通组件升级成DCOM组件的使用方式实际存在很多。
在跨机器场景里，DCOM和RPC的认证方式，通信端口不一样。RPC/DCOM本身的认证方式不方便。
每次看到DllHost.exe启动了，就说明有DCOM组件被启动了，而且是Dll组件升级的那种。

本机内RPC/DCOM使用例

各种服务通过原始RPC提供基本控制接口，就是sc命令那套。还有很多系统服务提供额外接口，例如Registry，Netlogon，Firewall，Service Control，SQL Server... ，具体RPC接口信息可以在msdn里有(检索rpc找到相应的服务，然后可以概括看看idl，例如