一、Starward 的多进程架构#

先说项目本身。Starward 是一个用 WinUI 3 + .NET 10 写的桌面应用，目标是替代米哈游官方的 HoYoPlay 启动器。它的解决方案目录长这样：

1
src/
2
├─ Starward/              # WinUI 3 主进程（UI）
3
├─ Starward.Core/         # 核心业务模型，被多端引用
4
├─ Starward.Language/     # 本地化资源
5
├─ Starward.Launcher/     # 启动器子进程
6
├─ Starward.RPC/          # ASP.NET Core 后台服务
7
├─ Starward.Setup/        # 安装组件
8
└─ Starward.Setup.Core/

注意 Starward.RPC 这个项目。WinUI 3 只是 UI 框架，启动器本身却需要做一堆”重活”：

• 游戏下载/安装/校验/卸载（要写系统目录、长时间运行）
• 设置全局限速
• 管理生命周期、清理临时文件

这些活有的需要管理员权限，有的不希望被 UI 进程的崩溃带走。所以 Starward 把它们拆到了一个独立的后台进程里：

UI 进程不持有管理员权限，所有需要提权或大流量长任务的工作都丢给 RPC 后台进程。两个进程之间通过 gRPC over Named Pipe 通信。

有意思的来了。

二、gRPC over Named Pipe 的实现#

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>();

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;                                            // 必须管理员

1
private static GrpcChannel CreateChannel()
2
{
3
    var connectionFactory = new NamedPipesConnectionFactory(AppConfig.MutexAndPipeName);
4
    var socketsHttpHandler = new SocketsHttpHandler
5
    {
6
        ConnectCallback = connectionFactory.ConnectAsync,
7
        UseProxy = false,  // 防止系统代理污染本地连接
8
    };
9
    return GrpcChannel.ForAddress("http://localhost", new GrpcChannelOptions
10
    {
11
        HttpHandler = socketsHttpHandler
12
    });
13
}

1
public async ValueTask<Stream> ConnectAsync(SocketsHttpConnectionContext _, CancellationToken ct = default)
2
{
3
    var clientStream = new NamedPipeClientStream(
4
        serverName: ".",
5
        pipeName: this.pipeName,
6
        direction: PipeDirection.InOut,
7
        options: PipeOptions.WriteThrough | PipeOptions.Asynchronous,
8
        impersonationLevel: TokenImpersonationLevel.Anonymous);
9
    await clientStream.ConnectAsync(ct);
10
    return clientStream;
11
}

三、HTTP/2 不一定基于 TCP#

到这里很多人会本能反应：HTTP 不就是网络协议吗？它不就是基于 TCP 的吗？

这是一个非常常见的误区。下面我们慢慢拆。

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

四、为什么不裸用 Named Pipe#

回到 Starward 的设计。你可能会问：既然底层就是命名管道，为什么不裸用 Pipe，要套一层 gRPC？

裸 Named Pipe 当然能做 IPC，但你要自己解决一系列问题：

• 消息边界：Pipe 是字节流，要自己定帧（长度前缀、分隔符等）
• 序列化：发什么格式？JSON？自定义二进制？
• 接口契约：调用方和服务方靠什么对齐？口头约定？
• 多路复用：同时发多个请求怎么对应响应？
• 双向流：服务端持续推送怎么做？
• 超时/取消：每个调用的 deadline 怎么传？
• 错误码：失败了怎么区分网络错误和业务错误？

gRPC over Named Pipe 把这些全部解决了：

• .proto 文件就是接口文档，编译期生成强类型代码，加新接口改 proto 就行
• stream 关键字一个搞定服务端推送（Starward 用它来推送下载进度）
• 超时直接传 deadline: DateTime.UtcNow.AddSeconds(5)，框架处理
• 错误码用 RpcException + StatusCode

举个 Starward 的例子。GameInstall.proto 里有这么一条：

1
rpc GetTaskProgress (EmptyMessage) returns (stream GameInstallContextDTO);

UI 调用一次，后台不断推送下载速度、读写速度、百分比、剩余时间。裸 Pipe 要自己实现这套推送协议，gRPC 一个关键字搞定。

代价是引入了 Grpc.AspNetCore 这个不轻的依赖，以及 Kestrel 的启动开销。对 Starward 这个规模的项目，这个 tradeoff 是合理的——接口会持续增加，用 proto 管理省很多维护成本。

五、Windows 上 IPC 方案全景#

聊到这里有人会问：那是不是说 gRPC over Named Pipe 是 Windows 上”最简单最成熟”的 IPC 方案？

不是。“最简单”和”最成熟”是两件事，而且取决于需求复杂度。下面把 Windows 上的 IPC 方案按”复杂度从低到高 / 能力从弱到强”排一下：

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);

1
curl --unix-socket /var/run/docker.sock http://localhost/version

六、Starward 设计上的几个细节#

最后回到 Starward，把这套架构里几个值得借鉴的细节列一下：

启动流程也值得看一眼：UI 想用 RPC 时调 EnsureRpcServerRunningAsync：

1
if (!CheckRpcServerRunning()) {              // Mutex 探测
2
    Process.Start(new ProcessStartInfo {
3
        FileName = AppConfig.StarwardExecutePath,
4
        Verb = "runas",                       // ← UAC 提权
5
        UseShellExecute = true,
6
        Arguments = $"rpc {StartupMagic} {Environment.ProcessId}",
7
    });
8
}
9
var client = RpcClientFactory.CreateRpcClient<Env.EnvClient>();
10
await client.GetRpcServerInfoAsync(new EmptyMessage(),
11
    deadline: DateTime.UtcNow.AddSeconds(5)); // 5 秒握手超时
12
await SetEnviromentAsync();                   // 告诉 RPC: 我的 PID、是否后台保留、限速

注意：

• 启动参数三件套：rpc 子命令 + 魔术字 + 父进程 PID。RPC 拿到 PID 后监听 Exited 事件，UI 退出时跟着退（除非用户开了”后台保留下载”）。
• 用户在 UAC 弹窗点取消会抛 Win32Exception ERROR_CANCELLED (0x4C7)，被捕获后返回 false，UI 优雅降级。
• 同一个 EXE 既是 UI 也是 RPC server，靠首参数区分。避免了发布两个独立可执行文件。

七、总结#

把这次思考整理成几条要带走的结论：

1. gRPC ≠ 远程调用。gRPC 只是”序列化 + 协议层”，传输层可以是 TCP，也可以是 Named Pipe、Unix Socket、内存流。
2. HTTP 不一定基于 TCP。HTTP 规范要求”可靠有序的字节流”，TCP 只是最常见的实现。HTTP/3 直接就不基于 TCP。
3. 协议和传输是正交的，这种分层是计算机系统设计的通用套路。理解这一点，再看 Docker、Kubernetes、Service Mesh、X11、PostgreSQL 这些项目的本地连接方式，会清晰很多。
4. Windows 上的 IPC 方案选型要看需求。简单场景裸 Named Pipe 或 StreamJsonRpc 就够，复杂场景才上 gRPC over Named Pipe。Starward 选 gRPC 是因为它有 streaming 需求和较多的接口数量，不是因为”最简单”。
5. Stream 是个伟大的抽象。无论是 .NET 的 System.IO.Stream、Java 的 InputStream、还是 Go 的 io.Reader，本质都是”字节流”这个抽象。一旦有了它，上层协议就能不在乎下层是什么。

参考资料#

• Starward on GitHub
• ASP.NET Core gRPC for inter-process communication
• Use Named Pipes with Kestrel in ASP.NET Core
• 命名管道 - Win32 apps
• StreamJsonRpc
• HTTP/2 RFC 9113