从 gRPC 看 Windows IPC

1. 服务端：Kestrel 监听命名管道#

一个 ASP.NET Core 应用。它的 Program.cs 关键代码：

1
builder.WebHost.ConfigureKestrel(serverOptions =>
2
{
3
    serverOptions.ListenNamedPipe(AppConfig.MutexAndPipeName, listenOptions =>
4
    {
5
        listenOptions.Protocols = HttpProtocols.Http2;
6
    });
7
}).UseNamedPipes(options =>
8
{
9
    var defaultSecurity = new PipeSecurity();
10
    var usersGroup = new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null);
11
    defaultSecurity.AddAccessRule(new PipeAccessRule(
12
        usersGroup,
13
        PipeAccessRights.ReadWrite | PipeAccessRights.CreateNewInstance,
14
        AccessControlType.Allow));
15
    options.PipeSecurity = defaultSecurity;
16
    options.CurrentUserOnly = false;
17
});
18

19
builder.Services.AddGrpc(...);
20
// ...
21
app.MapGrpcService<EnviromentController>();
22
app.MapGrpcService<GameInstallController>();

关键点：

• ListenNamedPipe 是 .NET 8 才加入的 API，让 Kestrel 直接监听 Windows 命名管道而不是 TCP 端口。
• PipeSecurity 给 BUILTIN\Users 读写权限，这样普通权限的 UI 进程才能连到管理员权限创建的管道。
• CurrentUserOnly = false 不是可选项，是必须显式关闭的默认行为。 Kestrel 的 NamedPipeTransportOptions 有一个 CurrentUserOnly 属性，默认值是 true——只有创建管道的当前用户能连接，这比 Win32 原始 API（CreateNamedPipe 传 NULL 安全描述符时默认对 Everyone 组开放读权限）严格得多。更关键的是，这两个参数是互斥的：一旦设置了自定义 PipeSecurity，CurrentUserOnly 必须显式设为 false，否则服务端启动时会抛异常，且报错信息具有一定误导性，容易让人以为是别的原因导致的。
• 上面的例子里，所有管道共用同一份 PipeSecurity。如果一个 Kestrel 应用要开多个管道端点、且每个端点需要不同的访问权限，从 .NET 9 起可以用 NamedPipeTransportOptions.CreateNamedPipeServerStream 这个选项，按管道名分别指定安全设置，不用再共用同一份规则。

服务启动还有几道安全闸：

1
if (args.Length < 2 || args[1] is not AppConfig.StartupMagic) return;     // 魔术字校验
2
using Mutex mutex = new(true, AppConfig.MutexAndPipeName, out bool createdNew);
3
if (!createdNew) return;                                                   // 单实例
4
if (!AppConfig.IsAdmin) return;                                            // 必须管理员

StartupMagic 是个硬编码的随机串，防止其他程序伪造命令行启动它来骗取管理员权限。

2. 客户端：替换 HttpClient 的连接回调，把底层连接换成命名管道#

UI 端的客户端代码是这样的：

1
var socketsHttpHandler = new SocketsHttpHandler
2
{
3
    UseProxy = false,  // 关键：见下方说明
4
    ConnectCallback = async (_, ct) =>
5
    {
6
        var stream = new NamedPipeClientStream(
7
            serverName: ".",
8
            pipeName: AppConfig.MutexAndPipeName,
9
            direction: PipeDirection.InOut,
10
            options: PipeOptions.WriteThrough | PipeOptions.Asynchronous,
11
            impersonationLevel: TokenImpersonationLevel.Anonymous);
12
        await stream.ConnectAsync(ct);
13
        return stream;
14
    }
15
};
16

17
using var channel = GrpcChannel.ForAddress("http://localhost", new GrpcChannelOptions
18
{
19
    HttpHandler = socketsHttpHandler
20
});
21

22
var client = new Greeter.GreeterClient(channel);
23
var reply = await client.SayHelloAsync(new HelloRequest { Name = "test" });

http://localhost 这个 URI 只是占位符，不代表真实网络地址。 设置了 ConnectCallback 后，SocketsHttpHandler 不会用它做 DNS 解析或 TCP 连接，实际传输由 ConnectCallback 返回的流决定。但”随便写”是有约束的：

1. 协议规范说了什么#

HTTP 是应用层协议，HTTP/2 标准（RFC 7540）本身没有规定必须使用 TCP，它只是定义了帧格式、流复用、头部压缩等应用层机制。

协议规定“说什么、怎么编码”，传输规定“字节怎么从 A 到 B”。两件事是正交的。

gRPC 的架构是：

当 gRPC 用 Named Pipe 时，替换的其实是操作系统提供的 socket 传输通道，也就是把“网络 socket”换成了“本地 IPC 通道”，但 HTTP/2 的帧格式、流复用、HPACK 头部压缩这些东西，跑在这条管道里的数据流本身，其实并不需要 TCP 的网络特性（IP 寻址、路由、拥塞控制）——它需要的只是一个可靠的、有序的字节流。

gRPC over Named Pipe 证明了 HTTP/2 不需要 TCP，它依赖的只是“可靠、有序的字节流传输”这个特性，只需要一个可靠有序的字节流传输，Named Pipe 满足这个条件，所以可以直接承载 HTTP/2 帧。HTTP/2 依赖的不是 TCP 这个具体协议，而是 TCP 所提供的那组特性：可靠、有序的字节流传输。TCP 只是提供这个特性最常见的一种方式，但不是唯一方式。任何能提供这组特性的通道都可以承载 HTTP/2 帧，包括：

• TCP（最常见，网络场景）
• Windows Named Pipe（本地 IPC，Windows 上的 gRPC 常用）
• Unix Domain Socket（本地 IPC，很多微服务框架用）

2. .NET 的 HTTP 栈是可以换底层的#

HttpClient 的架构是这样的：

ConnectCallback 的签名是：

1
Func<SocketsHttpConnectionContext, CancellationToken, ValueTask<Stream>>

它返回一个 Stream。.NET 的 HTTP/2 实现拿到这个 Stream 之后，就在上面跑 HTTP/2 的帧协议。它不知道也不关心这个 Stream 背后是什么——TCP socket、Named Pipe、Unix Domain Socket、内存流、串口都行，只要是双向字节流。

如果你用 Wireshark 抓包，会发现两个进程通信时完全没有 127.0.0.1 的 TCP 流量，只有 \Device\NamedPipe\... 的 IPC 操作。

3. 这种解耦其实到处都是#

一旦接受了这个分层观点，你会发现”协议和传输解耦”是计算机系统设计里非常常见的套路：

工程上这套解耦的红利包括：

• 测试：ASP.NET Core 的 WebApplicationFactory 在跑集成测试时，“HTTP 请求”根本不出进程，直接走内存。客户端代码用的还是 HttpClient。
• Docker：Docker CLI 和 Daemon 之间用的是 HTTP REST API。Linux 上走 /var/run/docker.sock，Windows 上走 \\.\pipe\docker_engine。同一套 API、同一个客户端代码。
• Kubernetes：kubelet 和容器运行时之间的 CRI 接口走 gRPC over Unix Socket。

类比一下：你可以把 HTTP 报文写在纸上用快递寄出去，快递不是 TCP，但内容还是 HTTP。

权限检查：DACL vs 文件权限位#

Named Pipe 的权限系统本质上和文件系统权限是同一套东西——安全描述符（Security Descriptor）里挂着一张访问控制列表（ACL），真正做判断的是其中的 DACL（Discretionary ACL，自主访问控制列表）。CreateNamedPipe 的 lpSecurityAttributes 参数就是这唯一的权限开关，且访问检查会发生两次：服务端 CreateNamedPipe 建管道时查一次，客户端 CreateFile/CallNamedPipe 连接时再查一次。

如果做跨平台对比：Linux 上对应的 Unix Domain Socket 走的是完全不同的权限哲学——没有细粒度的规则列表，就是普通文件的 rwx 权限位，chmod 怎么用这里就怎么用，连接一个 socket 需要对该 socket 文件拥有写权限。一个是 Windows 式的”精确到账户的规则表”，一个是 Unix 式的”属主/属组/其他”三段式，没有孰优孰劣，只是两种不同的设计传统。

权限被拒之后，看到的不是 PermissionDenied#

直觉上，DACL 拒绝了连接，catch 到的 RpcException 状态码应该是 StatusCode.PermissionDenied——但实际不是。DACL 检查发生在传输连接建立阶段，这时候 gRPC 层面还没有走到”识别调用方身份、判断这个身份有没有权限”这一步，连接本身就先失败了。grpc-dotnet 对这一类传输层建连失败，不管根因是什么，统一包装成 RpcException，状态码是 StatusCode.Unavailable，真正的原始异常（UnauthorizedAccessException）被塞进 DebugException 字段里，不会以”权限”的名义直接暴露出来。

官方 gRPC 状态码规范里写得很明确：如果调用方身份没能被识别，就不该用 PermissionDenied，这种情况该用 Unauthenticated。DACL 拒绝这个场景比这还要早一步——身份识别这一步压根没发生，连接都没建立起来，所以是更底层的 Unavailable。

选型建议#

90% 的小工具场景（纯 .NET 内部通信），下面两个之一就够了：

1
var server = new NamedPipeServerStream(
2
    "MyApp",
3
    PipeDirection.InOut,
4
    NamedPipeServerStream.MaxAllowedServerInstances,
5
    PipeTransmissionMode.Message);   // ← Message mode 帮你自动分帧
6
await server.WaitForConnectionAsync();

1
// 服务端
2
var rpc = JsonRpc.Attach(pipeServer, new MyService());
3

4
// 客户端
5
var client = JsonRpc.Attach<IMyService>(pipeClient);
6
await client.DoSomethingAsync(args);