命名管道实务 ── 从设计到安全，吃透 Windows 进程间通信的标准方案

「想从设置界面向常驻服务下达命令」「想只把需要管理员权限的处理拆到另一个进程」——在 Windows 上构建这类进程间通信（IPC）时，最先值得考虑的就是命名管道（named pipe）。

它在同一台 PC 内的通信中成为第一候选，理由不只是读写方便。可以用 Windows 的 ACL 收窄连接者，必要时确认对方的 Windows 账户并以该权限执行处理，这才是最大的好处。不过，光是把管道建出来并不等于安全，连接与权限的设置还是要做。¹²³

本文按连接形态 → 消息边界 → 服务器结构 → 安全 → 故障时的行为的顺序梳理设计。读者对象是编写 Windows 业务应用和服务的开发者。进程间通信选型表的文章里给出的「同一机器 IPC 的第一候选」，这里要一路挖到实现时的判断。

1. 先说结论：设计上要定的有 5 件事

在挑 API 之前，先把通信对象、数据的单位、并发连接、权限、失败时的处理定下来。

命名管道可以把基于 ACL 的连接控制和对客户端的模拟当作 Windows 自带的机制来用。改用 localhost 的 TCP 时，就得另行设计一套认证来确认通信对方是谁。反过来，如果将来想扩展到远程通信、想和其他操作系统通信、想复用 gRPC 等既有资产，基于 TCP 的方案更有利。²³

尤其重要的一点是：模拟失败的请求不要执行。忽略失败，处理就会以服务器自身而不是客户端的权限继续跑下去。要做特权服务时，请不要只看代码示例，一定读到第 5、6 章。⁴

2. 连接机制：名称共用，通道按客户端各自一条

2.1 把创建、连接、读写的职责分开

命名管道是用 \\.\pipe\MyCompany.MyApp.Control 这类名称标识的单向或双向通道。服务器和客户端最先使用的 API 并不相同。¹

连接建立之后，双方都能以和文件 I/O 相同的方式处理。除了名称的指定之外，掌握下面关于实例和方向的思路，多连接和连接错误也会更容易理解。

2.2 一个实例负责一个客户端

同一名称的管道可以创建多个，一个实例就是与一个客户端之间的通道。名称相同，并不意味着所有客户端共用一条通道。最大实例数在第一次调用 CreateNamedPipe 时指定，上限也可以写成 PIPE_UNLIMITED_INSTANCES。¹⁵

flowchart TB
    accTitle: 命名管道的基本结构
    accDescr: 服务器创建多个同名的管道实例并用 ConnectNamedPipe 等待连接，各客户端用 CreateFile 打开该名称，与其中一个实例建立一对一的双向通道
    s["服务器"] --> i1["实例 1"]
    s --> i2["实例 2"]
    s --> i3["实例 3"]
    c1["客户端 A"] <--> i1
    c2["客户端 B"] <--> i2
    c3["客户端 C"] <--> i3

图 1：双向管道的例子。用同一名称准备多个实例，服务器就能分别与多个客户端一对一通信。

2.3 「方向」是以服务器一侧为准的说法

客户端指定的访问方式，要和服务器创建管道时的方向相符。不一致时 CreateFile 会失败。⁶

所有实例都在使用中时，客户端的 CreateFile 会得到 ERROR_PIPE_BUSY。这时用 WaitNamedPipe 等待空位，再调用一次 CreateFile。它和「服务器还没创建管道」是不同的失败，将在 7.1 连同启动顺序的竞态一起梳理。⁶

2.4 即便只在本机使用，也要定好远程连接怎么处理

命名管道也能以 \\server\pipe\名称 的形式经 SMB 用于远程连接。不过在如今的设计里几乎没有理由主动走这条路，本机 IPC 的关键是不要让用不到的路径一直敞着。用 5.1 的 PIPE_REJECT_REMOTE_CLIENTS 明确拒绝。¹⁷

3. 模式的选法：先定「到哪里算一条」

3.1 请求与响应用消息模式，已有边界机制用字节模式

传输模式的差别，在于管道是否保存写入的边界。⁵

flowchart TB
    accTitle: 字节模式与消息模式的区别
    accDescr: 字节模式下三次写入会变成没有断点的字节流，接收方必须自己划分边界；消息模式下每次写入的单位会被保存，原样送达接收方
    bw["字节模式：写入 AAA、BB、CCCC"] --> br["收到的是 AAABBCCCC 字节流"]
    br --> bf["边界（成帧）要自己设计"]
    mw["消息模式：同样的三次写入"] --> mr["收到 AAA、BB、CCCC 三条"]
    mr --> mf["写入的单位被保存下来"]

图 2：字节模式下由接收方管理边界。消息模式能保存写入的单位，但一次读取未必就拿得到整条消息。

如果还没有自己的边界机制，又想把「一次写入＝一条请求」来处理，消息模式很方便。如果已经在用带长度前缀的序列化格式之类，字节模式就够了。在 .NET 中，PipeTransmissionMode.Message 相当于消息型的指定。⁸

对消息型的双向管道，还有把请求发送与响应接收合成一次调用的 TransactNamedPipe。⁹

3.2 消息型和读取模式是两套设置

读取模式是按句柄设置的。即便在 CreateNamedPipe 里指定了 PIPE_READMODE_MESSAGE，那也只是服务器一侧的设置。客户端用 CreateFile 打开的句柄，默认仍是字节读取。⁶

关键在于，不要以为只把服务器做成消息型，客户端就能按同样的单位读取。

3.3 即便是消息模式，也会需要续读

消息的边界得以保留，和接收缓冲区放得下整条消息，是两回事。缓冲区太小时 ReadFile 会返回 ERROR_MORE_DATA，消息会被拆开。需要一个循环：留住已经收到的部分，把剩下的续读进来并拼接。⁵⁶

出现「小请求没事，只有大请求会坏掉」时，就检查这段续读处理。另外，也不是可以无限拼接下去。单条消息的最大长度同样要作为协议定下来，超过上限就断开，以免巨大的消息把内存吃光。

4. 服务器结构：把接待和客户端处理分开

4.1 比较同步线程型和 overlapped 型

服务器的基本动作，是创建实例 → 等待连接 → 读写 → 断开后进入下一轮的循环。要同时接纳多个客户端，就用多个实例并行推进这条流程。

Microsoft 的官方示例把各实例的事件放进数组，用 WaitForMultipleObjects 等待，是单线程处理多个连接的结构。这样客户端数和线程数就解耦了。规模再大一些，也可以接到 IOCP 或线程池 I/O 上。¹⁰

异步 I/O 本身的机制，请参阅同步 I/O 与异步 I/O 的文章。

4.2 新写的 .NET 实现，async/await 最直接

在 .NET 中可以使用 NamedPipeServerStream 的 WaitForConnectionAsync / ReadAsync / WriteAsync 配合 async/await。新写的实现如果没有特别理由，推荐这种异步形态。接待循环收到连接后交给单独的处理流程，然后回到下一个实例的接待。⁸

下面是那个接待循环的骨架。作为同一用户的进程之间使用的例子，这里指定了 PipeOptions.Asynchronous 和 PipeOptions.CurrentUserOnly。在 Windows 上，CurrentUserOnly 表示限定为同一用户且同一提升级别。它不是把不同账户下的服务和 UI 连起来的例子。那种场合需要 5.2 的 ACL 设计。¹¹

// C#: 接纳多个客户端的服务器骨架
while (!token.IsCancellationRequested)
{
    var server = new NamedPipeServerStream(
        "MyCompany.MyApp.Control",
        PipeDirection.InOut,
        NamedPipeServerStream.MaxAllowedServerInstances,
        PipeTransmissionMode.Message,
        PipeOptions.Asynchronous | PipeOptions.CurrentUserOnly);

    try
    {
        await server.WaitForConnectionAsync(token);
    }
    catch
    {
        await server.DisposeAsync();        // 在连接建立前退出时自行释放
        throw;
    }
    _ = HandleClientAsync(server, token);   // 连接建立后所有权交给处理方
}

若在连接建立前发生异常，就由接待一侧释放；连接建立之后，HandleClientAsync 一侧接过流的所有权。后者不仅包含读写，也包含结束时的释放。

这段代码略去了通信协议和处理器本体，只是骨架。实际运行时还要管理分离出去的任务的异常与结束，并把第 3 章的续读与长度上限、第 5、6 章的安全、第 7 章的断开与响应确认组合进来。CurrentUserOnly 是不用自己写 ACL 就能限定连接者的省事选项，但光靠它并不能构成面向特权服务的完整设计。

5. 安全：服务器侧三点，客户端侧一点

命名管道在安全上的好处，要正确设置之后才拿得到。特别是在「管理员权限的服务 + 低权限的 UI 应用」这种代理结构中，管道本身就是权限的边界。

5.1 服务器侧：拒绝不需要的远程连接

作为本机 IPC 使用时，要在 CreateNamedPipe 上指定 PIPE_REJECT_REMOTE_CLIENTS。远程客户端会被自动拒绝，从而堵上「本来是给同一台 PC 的应用做的，结果从网络上也打得开」这条路。⁷

5.2 服务器侧：用 ACL 收窄连接者和权限

把安全描述符传给 SECURITY_ATTRIBUTES，明确写出允许连接的用户和组。默认的 ACL 未必对你的用途足够严格。²

这里容易漏掉的，是给客户端的写入权限。在 ACL 里授予通用写入（GENERIC_WRITE / FILE_GENERIC_WRITE），就会把相当于 FILE_CREATE_PIPE_INSTANCE 的权限也一并带上。于是被允许的客户端自己就能创建同名的服务器实例，把后续的连接抢走。²

读写要用所需的单项权限来授予，不要把创建实例的权限交给客户端。ACL 的设计不只是「允许谁」，还包括「允许做什么」。

5.3 服务器侧：确认第一个实例没有被抢先创建

恶意进程抢先创建了同名的管道，客户端就会连到那个伪服务器上。服务器只在创建第一个实例时指定 FILE_FLAG_FIRST_PIPE_INSTANCE，以此保证自己是第一个。失败就要怀疑被抢先，停止处理。⁵

这个标志只用于占住名称的第一条实例。给第二条以后的实例也加上，创建就会失败。在面向多客户端的接待循环里，注意不要对所有创建都重复同样的指定。⁵

不过，这只是正规服务器在启动时检测异常的机制，并不是客户端对连接目标的认证。正规服务不在时，攻击者仍有先创建同名管道守在那里的余地。

5.4 客户端侧：定好让服务器借用权限到什么程度

作为对伪服务器的防备，客户端要把模拟级别压到必要的最低限。若设计上只允许确认身份，就在 CreateFile 上指定 SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION。这样服务器虽然能确认账户，却无法借用其权限去做实际的访问。³

停在识别级别上，就做不了以客户端权限进行实际访问的代理处理。反过来，不确认连接目标就允许模拟，则有被伪服务器借走权限的危险。

原则是：只在能通过服务的启动保证、或连接后的相互认证确认连接目标为正规一方时，才允许必要的模拟。不要以为有了 5.3 的抢先检测，客户端一侧就不必确认。

6. 模拟的用法：失败的请求不要执行

6.1 不是连上就模拟，而是读到请求之后再模拟

服务器确认客户端的身份并以其权限处理，用的 API 是 ImpersonateNamedPipeClient。它的对象，是从该管道最后读到的那条消息的发送方的安全上下文。所以要先读取请求，然后再调用。⁴

模拟作用于调用它的那条线程。在这个状态下打开文件，能否访问就以客户端的权限为准来判定。即便是特权服务，这也是「以委托者的权限执行被委托的操作」的机制。³

6.2 把读取、成功确认、恢复上下文当成一整套

必要的顺序是：读取请求 → 尝试模拟 → 确认成功 → 以客户端权限操作 → 回到原来的上下文。

sequenceDiagram
    accTitle: 使用模拟处理请求的流程
    accDescr: 服务器从管道读取请求，确认 ImpersonateNamedPipeClient 成功之后再以客户端的权限进行操作，并用 RevertToSelf 回到自己的上下文。模拟失败时不执行请求而是拒绝
    participant C as 客户端
    participant S as 服务器
    C->>S: 发送请求
    S->>S: 读取请求
    S->>S: ImpersonateNamedPipeClient
    Note over S: 失败则不执行请求，直接拒绝
    S->>S: 以客户端权限执行操作
    S->>S: 用 RevertToSelf 恢复
    S->>C: 返回结果

图 3：模拟失败就不要执行请求。即便成功，也要把「做完之后用 RevertToSelf 恢复」算进这一连串处理里。

不要在没有检查 ImpersonateNamedPipeClient 返回值的情况下就进入请求处理。失败时并没有切换到客户端的权限，用的是服务器进程自身的权限。服务器若是特权账户，就会把客户端本不该做的操作也放行。Microsoft 的文档同样明确写着，失败时不要执行客户端的请求。⁴

工作结束后，要用 RevertToSelf 可靠地回到原来的上下文。成功确认和收尾两样都要齐备。令牌、模拟级别、SeImpersonatePrivilege 等细节，在 Windows 模拟令牌的文章中有讨论。

7. 实务中的坑：按「通信会断」来设计

7.1 等待启动和等待空位，是两种不同的失败

连不上时，要分清是服务器还没创建管道，还是已创建的实例全都在使用中。⁶⁹

flowchart TB
    accTitle: 客户端连接的重试流程
    accDescr: 用 CreateFile 打开管道，管道不存在就稍等一会儿再重试，所有实例都在使用中的 ERROR_PIPE_BUSY 就用 WaitNamedPipe 等待空位后再重试，成功则进入通信
    cf["用 CreateFile 打开"] --> ok{"结果如何?"}
    ok -->|"成功"| go["开始通信"]
    ok -->|"管道不存在"| wait1["稍等一会儿（服务器未启动）"]
    ok -->|"ERROR_PIPE_BUSY"| wnp["用 WaitNamedPipe 等待空位"]
    wait1 --> cf
    wnp --> cf

图 4：「不存在」和「已满」是不同的状态。两者都要按各自的状态等待之后，再重试连接。

服务器一侧的原则，是在客户端启动之前就用 ConnectNamedPipe 开始等待。即便如此，启动顺序的竞态仍然可能发生，所以客户端一侧也要内建重试。⁹

7.2 把断开做成常规处理路径，而不是异常事态

对方的进程结束后，读写会以 ERROR_BROKEN_PIPE 之类失败。这要当作通信的日常来处理。

服务器检测到断开后，用 DisconnectNamedPipe 把实例摘下来，为下一次连接做准备。客户端则重新连接。休眠恢复的文章里讲过的、重复执行也不会破坏状态的「幂等重连」思路，在这里同样有效。

7.3 大消息既要「续读」也要「上限」

3.3 的 ERROR_MORE_DATA 是把消息分次读完的处理；而最大消息长度是限制接收数据量的约定。不要把这两件事混为一谈。

恶意的一方，或者带 bug 的一方发来巨大的消息时，无限续读的实现会把内存耗光。要在协议里定好上限，超过就断开。

7.4 区分写入成功和对方处理完成

WriteFile 成功，并不意味着对方的应用已经处理了数据。需要确知是否真的执行了的操作，要用响应消息来确认。

另外，为了能分辨响应对应的是哪一个请求，要把请求与响应的对应关系写进协议。把「发出去了」和「处理完了」分开，才谈得上业务上的完成确认。

8. 小结：通道、数据、权限分开来定

命名管道兼具与文件 I/O 相同的易用性，以及 ACL 与模拟这套 Windows 安全模型，是同一机器 IPC 的第一候选。不过，做出一条通道和做出一套安全、不易坏的协议，是两件事。

连接与数据的设计，以「一个实例负责一个客户端」为出发点。请求响应型选消息模式，已有成帧机制则选字节模式，而消息读取在客户端一侧也要设置。拆分读取的应对和最大长度同样必要。要接纳多个连接的新 .NET 实现，异步 I/O 加 async/await 最直接。

权限的设计，把拒绝远程、明确 ACL、保证第一个实例、把客户端侧的模拟级别降到最低配成一套。使用模拟时，先读请求再调用，失败就不执行，做完之后用 RevertToSelf 恢复。

最后，请把启动顺序、断开、消息上限、响应确认写成你自己的协议。实务的要点不是「反正在同一台 PC 里不会失败」，而是先定好即使通信中断，也能不越过对方权限地恢复的形态，然后再动手实现。

相关文章

• Windows 的进程间通信怎么选 ── 命名管道 / TCP / gRPC / 共享内存 / COM 选型表
• 在 Windows 应用里把「只有需要管理员权限的处理」分离出来的具体写法
• 正确处理 Windows 的模拟令牌 ── 线程级的权限借用与安全的恢复方式
• Windows I/O 的深层（第 2 回） ── 同步 I/O 与异步 I/O：OVERLAPPED 的真正含义
• 共享内存的陷阱与实务最佳实践

相关咨询领域

小村软件有限公司承接伴随进程间通信的设计与实现，例如服务与 UI 应用的分离、管理员权限的分离；也承接把既有 IPC（共享内存、自研套接字、COM 等）替换为命名管道，以及特权服务管道通信的安全评审。从协议设计的讨论阶段开始咨询也可以。

• Windows 应用开发
• 技术咨询・设计评审
• 故障调查・原因分析
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

命名管道和 TCP（localhost 套接字）该怎么分别使用？

只要是同一台机器内的进程间通信，命名管道就是第一候选。原因在于安全模型。管道可以用 Windows 的安全描述符（ACL）在操作系统层面控制「谁可以连接」，服务器一侧还能用 ImpersonateNamedPipeClient 确认并借用连接方的 Windows 账户。相比之下，localhost 的 TCP 端口谁都能连上，必须自己另做一套认证来确认对方是谁。反过来，如果将来很可能扩展到远程通信、要和其他操作系统上的进程对话、想复用 gRPC 等既有协议资产，那么基于 TCP 的方案更有利。这一判断在进程间通信选型表的文章里也做过梳理。

字节模式和消息模式该用哪一个？

如果想把「一次写入＝一个意义单位」来处理，消息模式（PIPE_TYPE_MESSAGE + PIPE_READMODE_MESSAGE）比较方便。接收方可以按发送方写入的单位读取，不必自己管理边界。字节模式和 TCP 一样是「没有断点的字节流」，需要自己设计长度前缀之类的边界（成帧）。如果承载的协议本身已有成帧（例如带长度前缀的序列化格式），用字节模式就没有问题。需要注意的地方是，即便在消息模式下，接收缓冲区比消息小时也会发生拆分读取（ERROR_MORE_DATA），这段处理还是要写。另外，读取模式是按句柄设置的，CreateNamedPipe 设置的只是服务器一侧。客户端必须在 CreateFile 之后用 SetNamedPipeHandleState 指定 PIPE_READMODE_MESSAGE。在 .NET 中，服务器指定 PipeTransmissionMode.Message，客户端则在连接后把 NamedPipeClientStream.ReadMode 设为 Message。

同时面对多个客户端的服务器该怎么写？

命名管道可以用同一名称创建多个实例，一个实例负责一个客户端。结构有两种。一种是给每个客户端分配一条线程的同步型，实现直接，但会按客户端数量消耗线程。另一种是用 FILE_FLAG_OVERLAPPED 做成异步 I/O，用少量线程处理所有实例的 ConnectNamedPipe、ReadFile、WriteFile；Microsoft 的官方示例中也给出了单线程处理多个实例的实现。用 .NET 的话，配合 NamedPipeServerStream 的 WaitForConnectionAsync 和 async/await，可以把异步型写得像同步型一样直接。新写的实现如果没有特别理由，我推荐 .NET 的异步型。

命名管道的安全方面至少要做哪些事？

有四点。第一，若不需要远程连接，就指定 PIPE_REJECT_REMOTE_CLIENTS，明确拒绝经网络的连接。第二，用 SECURITY_ATTRIBUTES 设置合适的 ACL，收窄允许连接的用户和组（默认的 ACL 对某些用途来说太宽松）。第三，创建第一个实例时指定 FILE_FLAG_FIRST_PIPE_INSTANCE，以检测同名管道被抢先创建的「名称劫持」（第二个以后的实例不要加）。第四，只想让服务器确认身份的客户端，应在 CreateFile 上指定 SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION，限制伪服务器借用（模拟）自己的权限。在服务器以客户端权限进行实际访问的代理结构中必须允许模拟，因此这条限制要按「设计上是否让服务器借用权限」来区别对待。

使用 ImpersonateNamedPipeClient 时有哪些需要注意的地方？

最重要的是检查返回值。模拟失败却继续处理，之后的操作就会以服务器进程自身（往往更高）的权限执行，本不该允许客户端做的操作也会放行。官方文档也明确写着：失败时不得执行客户端的请求。另外，模拟是在「最后从管道读到的那条消息」的上下文中进行的，所以务必先读取了什么之后再调用；工作结束后也要用 RevertToSelf 可靠地回到原来的上下文。模拟周边的机制（令牌、模拟级别、SeImpersonatePrivilege）在模拟令牌的文章中有详细讲解。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。