具名管道實務 ── 從設計到安全性，整理 Windows 的標準 IPC

「想讓常駐服務和設定畫面交換指令。」「只想把需要系統管理員權限的工作隔離到另一個處理程序。」「想讓同一台 PC 上的工具彼此傳遞資料。」── Windows 上需要這種行程間通訊（IPC）時，應優先考慮的標準就是具名管道。

Windows 行程間通訊選擇的文章把具名管道定位為「同一機器 IPC 的第一候補」。本文是各論。為什麼是第一候補、模式與伺服器形態怎麼選、特權服務使用時必須守住什麼──以在 Windows 上撰寫業務應用程式與服務的開發者為對象，依一次資訊整理這些設計判斷的材料。

1. 先講結論

• 具名管道是名稱空間為 \\.\pipe\name 的雙向行程間通道。同一個名稱下可建立多個執行個體，同時接受多個用戶端。¹
• 成為同一機器 IPC 第一候補的理由是安全性模型。可用 ACL 控制誰能連線，伺服器也能檢查並借用（偽裝）用戶端的 Windows 帳號。localhost TCP 兩者都沒有。²
• 若想把「一次寫入＝一則訊息」來處理，用訊息模式；若已有自備框架，用位元組模式。即使是訊息模式，緩衝區過短時仍要處理分割讀取（ERROR_MORE_DATA）。³
• 多用戶端用「多個執行個體＋overlapped I/O」或「.NET 的 async/await」處理。官方範例示範了以單執行緒處理多個執行個體的形態。⁴
• 安全性最低限度有四點：拒絕遠端（PIPE_REJECT_REMOTE_CLIENTS）、明確指定 ACL、用 FILE_FLAG_FIRST_PIPE_INSTANCE 偵測劫持，以及在用戶端把偽裝層級降到最小。⁵⁶
• ImpersonateNamedPipeClient 的生命線是檢查傳回值。忽略失敗，處理就會以伺服器權限繼續跑。⁶

2. 具名管道是什麼 ── 名稱空間、執行個體、連線方式

具名管道是以 \\.\pipe\MyCompany.MyApp.Control 這類名稱識別的通道。伺服器用 CreateNamedPipe 建立，用戶端用 CreateFile 開啟同一個名稱。開啟之後雙方都以 ReadFile / WriteFile 讀寫──特色是能用和檔案 I/O 相同的形態來使用。¹

重要概念是執行個體。同一個名稱的管道可建立多個執行個體，一個執行個體就是與一個用戶端的一條通道。第一次呼叫 CreateNamedPipe 時決定最大執行個體數（或無上限）。³

用戶端連線有一套標準做法。當所有執行個體都在使用中，CreateFile 會以 ERROR_PIPE_BUSY 失敗，因此用 WaitNamedPipe 等待空出來的執行個體再重試。此外，開啟時指定的存取必須符合伺服器建立時的方向──雙向管道用讀或寫都可以開啟，但伺服器只寫的輸出管道必須以唯讀開啟，伺服器只讀的輸入管道必須以唯寫開啟，否則 CreateFile 會失敗。⁷

flowchart TB
    accTitle: 管道方向與用戶端的存取指定
    accDescr: 用戶端可用讀或寫開啟雙向管道，但伺服器只寫的輸出管道必須唯讀開啟，伺服器只讀的輸入管道必須唯寫開啟
    q{"伺服器建立的方向？"} -->|"雙向"| dc["讀或寫都可以"]
    q -->|"輸出"| oc["以唯讀開啟"]
    q -->|"輸入"| ic["以唯寫開啟"]

圖 1: 方向與存取指定不一致會變成 CreateFile 失敗。調查連線錯誤時先看這裡。

flowchart TB
    accTitle: 具名管道的基本結構
    accDescr: 伺服器建立同名的多個管道執行個體，以 ConnectNamedPipe 等待連線；各用戶端用 CreateFile 開啟該名稱，與一個執行個體形成一對一雙向通道
    s["伺服器"] --> i1["執行個體 1"]
    s --> i2["執行個體 2"]
    s --> i3["執行個體 3"]
    c1["用戶端 A"] <--> i1
    c2["用戶端 B"] <--> i2
    c3["用戶端 C"] <--> i3

圖 2: 持有同名的多個執行個體，一台伺服器就能同時與多個用戶端一對一交談。

具名管道也能經由 SMB 遠端開啟（\\server\pipe\name），但在現代設計裡幾乎沒有積極使用的理由；問題反而在於沒用到時不要把它留著開著（第 5 章）。

3. 位元組模式與訊息模式

管道有兩種傳輸模式。³

• 位元組模式（PIPE_TYPE_BYTE）：像 TCP 一樣的「沒有斷點的位元組串流」。一則訊息在哪裡結束由你自己決定（自行設計長度前置碼等框架）。
• 訊息模式（PIPE_TYPE_MESSAGE + PIPE_READMODE_MESSAGE）：一次寫入被當成一則訊息，讀取端依該單位接收。這對要求／回應的交換較輕鬆。

訊息模式還有方便的搭配函式 TransactNamedPipe，一次呼叫就能送出要求並收到回應。⁸ 不過有陷阱。若接收緩衝區小於整則訊息，讀取會傳回 ERROR_MORE_DATA，變成分割讀取。不要假設訊息模式就等於「一次 Read 一定拿完整則」；仍要寫一個讀剩餘部分的迴圈。注意讀取模式是每個控制代碼的設定，CreateNamedPipe 只決定伺服器端。用戶端在 CreateFile 之後用 SetNamedPipeHandleState 指定（.NET 則在連線後設定 ReadMode）。⁷

flowchart TB
    accTitle: 訊息模式的分割讀取迴圈
    accDescr: ReadFile 成功則訊息完整；若傳回 ERROR_MORE_DATA 就讀取緩衝區裝不下的剩餘部分並串接；其他錯誤視為斷線
    read["以 ReadFile 讀取"] --> r{"結果？"}
    r -->|"成功"| done["訊息完整"]
    r -->|"ERROR_MORE_DATA"| more["讀剩餘部分並串接"]
    more --> read
    r -->|"其他錯誤"| dis["視為斷線"]

圖 3: 即使是訊息模式也需要「讀剩餘部分的迴圈」；沒有它，只有大訊息會壞掉。

flowchart TB
    accTitle: 位元組模式與訊息模式的差異
    accDescr: 位元組模式中三次寫入會變成沒有斷點的位元組串流，接收端必須自己切分；訊息模式保留每次寫入的單位，原樣到達接收端
    bw["位元組模式：寫入 AAA、BB、CCCC"] --> br["收到位元組串流 AAABBCCCC"]
    br --> bf["框架由自己設計"]
    mw["訊息模式：同樣三次寫入"] --> mr["收到三則訊息：AAA、BB、CCCC"]
    mr --> mf["寫入單位被保留"]

圖 4: 訊息模式保留「一次寫入的單位」並送達。框架設計變得不必要；只要別忘了處理分割讀取。

實務上怎麼選，規則很單純。交換形態是「要求與回應」就用訊息模式。若承載的形式本身已內建框架（帶長度的序列化資料或串流傳輸），用位元組模式。在 .NET 中，指定 PipeTransmissionMode.Message 對應前者。⁹

4. 伺服器設計 ── 每個用戶端一條執行緒，還是 Overlapped？

伺服器的基本操作是「建立執行個體 → 用 ConnectNamedPipe 等用戶端 → 讀寫 → 斷線再接下一個用戶端」這個迴圈。同時和多個用戶端交談有兩種形態。

同步、每個執行個體一條執行緒。每個執行個體分配一條執行緒，各自用同步 I/O 與自己的用戶端交談。程式碼直觀，但每個用戶端消耗一條執行緒，整套關閉時也需要能從阻塞 I/O 脫身的方法。

Overlapped（非同步）。用 FILE_FLAG_OVERLAPPED 建立執行個體，非同步發出 ConnectNamedPipe / ReadFile / WriteFile，由少數執行緒處理所有執行個體的完成。Microsoft 官方範例示範了一個用 WaitForMultipleObjects 等待事件陣列、以單執行緒處理多個執行個體的伺服器。⁴ 非同步 I/O 的一般說明見I/O 系列文章，規模再大也可掛上 IOCP 或執行緒集區 I/O。

flowchart TB
    accTitle: Overlapped 伺服器的結構
    accDescr: 各執行個體非同步操作的完成由事件陣列接收，少數執行緒以 WaitForMultipleObjects 等待並推進已完成的執行個體，使執行緒數與用戶端數脫鉤
    i1["執行個體 1 非同步操作"] --> ev["事件陣列"]
    i2["執行個體 2 非同步操作"] --> ev
    i3["執行個體 3 非同步操作"] --> ev
    ev --> wait["以 WaitForMultipleObjects 等待完成"]
    wait --> proc["推進已完成的執行個體"]
    proc --> wait

圖 5: Overlapped 形態讓執行緒數與用戶端數脫鉤。官方範例用單執行緒轉動這個循環。

.NET 幾乎消掉了這個選擇。把 NamedPipeServerStream 的 WaitForConnectionAsync / ReadAsync / WriteAsync 搭配 async/await，就能用和同步形態一樣直觀的程式碼得到 overlapped 的效率。⁹

// C#: skeleton of a server that accepts multiple clients
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();        // dispose yourself when leaving before a connection
        throw;
    }
    _ = HandleClientAsync(server, token);   // ownership after connect goes to the handler
}

PipeOptions.CurrentUserOnly 是「只允許同一使用者的處理程序連線」的指定，方便又安全的預設，省下自己寫 ACL。¹⁰ 跨使用者的配置（服務 ↔ 使用者工作階段中的應用程式等）不能用它，那種情況就進入下一章的 ACL 設計。

flowchart TB
    accTitle: .NET 非同步伺服器的接受迴圈
    accDescr: 接受迴圈建立 NamedPipeServerStream，以 WaitForConnectionAsync 等待連線，到達後非同步卸下用戶端處理並立刻回到下一次接受，因此並行連線可用直觀程式碼處理
    mk["建立伺服器串流"] --> wc["以 WaitForConnectionAsync 等待"]
    wc --> got["連線到達"]
    got --> hd["非同步卸下用戶端處理"]
    hd --> mk

圖 6: 接受迴圈只守「等待 → 卸下 → 下一個」這個循環，各用戶端的處理並行推進。

5. 安全性 ── 特權服務使用管道時必須做的四件事

具名管道成為同一機器 IPC 第一候補的最大理由是安全性模型，但那只在設定正確時成立。尤其在「系統管理員權限服務＋低權限 UI 應用程式」的仲介設計裡，管道本身就是權限邊界。要釘死四點。

(1) 拒絕遠端。本意是本機 IPC 的管道卻能從網路開啟，本身就是攻擊面。在 CreateNamedPipe 指定 PIPE_REJECT_REMOTE_CLIENTS，遠端用戶端連線就會自動被拒絕。⁵

(2) 明確指定 ACL。在 SECURITY_ATTRIBUTES 傳入安全性描述元，縮小允許連線的使用者和群組。不要給用戶端 GENERIC_WRITE──其中包含的 FILE_CREATE_PIPE_INSTANCE 權限，會讓已授權的用戶端自己建立同名的伺服器執行個體並偷走後續連線。把讀與寫當成個別權限授予，不要傳入建立執行個體的權限。¹¹

(3) 防止名稱劫持。管道名稱是先到先贏。惡意處理程序若先建立同名管道並等待，用戶端就會連上假伺服器。伺服器在建立第一個執行個體時指定 FILE_FLAG_FIRST_PIPE_INSTANCE，保證「我是第一個」，失敗就懷疑被劫持並停止。這個旗標只給宣告名稱的第一個執行個體；加在第二個以後的執行個體上會讓建立失敗。³

伺服器端的身分檢查與權限借用是 ImpersonateNamedPipeClient。從管道讀完要求後呼叫它，呼叫執行緒就開始以最後讀到的訊息傳送者的安全性脈絡執行。用用戶端權限開啟檔案，存取檢查就對用戶端進行──這就是特權服務執行「被要求的操作，但用要求者的權限」的機制。⁶ 使用它的絕對條件是檢查傳回值。偽裝失敗後繼續，後續操作會以伺服器自身的高權限執行。官方文件明確寫道「失敗時不得執行用戶端的要求」。做完後的 RevertToSelf，以及偽裝權杖文章中的做法，原樣適用。

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: 回覆結果

圖 7: 確認偽裝成功與確實的 RevertToSelf 是一套。失敗後繼續就會以伺服器權限執行。

flowchart TB
    accTitle: 保護特權服務管道的四點
    accDescr: 伺服器端以拒絕遠端、明確 ACL、第一個執行個體保證來加固入口；用戶端指定所需的最小偽裝層級，讓假伺服器無法借用權限（設計不讓伺服器借用權限時縮到識別層級）
    subgraph sv["伺服器端"]
        r1["PIPE_REJECT_REMOTE_CLIENTS"]
        r2["以 ACL 限制連線者"]
        r3["FIRST_PIPE_INSTANCE（僅第一個）"]
    end
    subgraph cl["用戶端"]
        r4["指定最小偽裝層級"]
    end
    sv --> safe["作為權限邊界的管道"]
    cl --> safe

圖 8: 管道即權限邊界的設計中，伺服器端三點加上用戶端一點要成套實作。

6. 實務上的陷阱

啟動順序的競態。伺服器還沒建立管道，用戶端就來連線，會得到「管道不存在」的錯誤。用戶端端要內建「不存在 → 稍等再重試」。反過來說，伺服器端的原則是在用戶端啟動前就用 ConnectNamedPipe 開始聽。⁸

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

圖 9: 用戶端連線處理區分「不存在」與「已滿」兩種失敗，兩者都接回重試。

偵測斷線。對方結束時，Read/Write 會以 ERROR_BROKEN_PIPE 等失敗。那不是異常，而是日常通訊。伺服器偵測斷線、對執行個體做 DisconnectNamedPipe、準備下一次連線；用戶端重新連線──睡眠／恢復文章所說「冪等重連」的想法在這裡也適用。

對訊息大小的假設。除了訊息模式的分割讀取（第 3 章）之外，若沒有把「一則訊息最多幾位元組」定進協定，惡意（或有缺陷）的對方就能用巨大訊息浪費你的記憶體。決定上限，超過就斷線；這才是安全做法。

寫入完成與對方收到是兩回事。WriteFile 成功不代表對方應用程式已處理資料。需要確定性的操作，要用回應訊息確認、並把要求與回應的對應寫進協定這類設計來擔保。

7. 總結

• 具名管道是同一機器 IPC 的第一候補。理由是與檔案 I/O 相同的易用性，以及與 ACL、偽裝這套 Windows 安全性模型的整合。
• 模式選擇是「要求與回應用訊息模式，已有自備框架就用位元組模式」。即使是訊息模式仍要處理分割讀取（ERROR_MORE_DATA）。
• 多用戶端是多個執行個體＋overlapped，或 .NET 的 async/await。新工作以 .NET 非同步形態最直觀。
• 作為權限邊界的管道，要把拒絕遠端、明確 ACL、FIRST_PIPE_INSTANCE（僅第一個執行個體）、以及最小化用戶端偽裝層級當成一套。
• ImpersonateNamedPipeClient 的生命線是檢查傳回值與 RevertToSelf。
• 把啟動順序、斷線、訊息上限、回應確認這些「通訊的日常」織進協定設計。

具名管道是舊 API，但對「讓同一台機器上的處理程序在尊重 Windows 帳號邊界的前提下交談」這個用途，它仍是最自然的工具。設計判斷點幾乎都收斂在本文範圍內。之後，先把自備協定寫成一張紙，再開始實作。

相關文章

• Windows 的行程間通訊該怎麼選 ── 具名管道 / TCP / gRPC / 共享記憶體 / COM 判斷表
• Windows 應用程式中把「僅需要系統管理員權限的處理」分離出來的具體寫法
• 正確處理 Windows 偽裝權杖 - 執行緒層級的權限借用與安全還原方式
• Windows I/O 的深層(第 2 回) ── 同步 I/O 與非同步 I/O：OVERLAPPED 的真正含義
• 使用共享記憶體時的陷阱與最佳實踐 - 先整理同步、可見性、壽命、ABI、安全性

相關諮詢領域

小村軟體有限公司承接涉及行程間通訊的設計與實作──把服務與 UI 應用程式分開、隔離系統管理員權限等──以及把既有 IPC（共享記憶體、自製通訊端、COM 等）換成具名管道，還有特權服務管道通訊的安全性審查。從一起討論協定設計開始諮詢也歡迎。

• Windows 應用程式開發
• 技術諮詢 & 設計審查
• 故障調查 & 根本原因分析
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

具名管道與 TCP（localhost 通訊端）該怎麼選？

同一台機器上的行程間通訊，具名管道是第一候補。理由在安全性模型。管道可用 Windows 安全性描述元（ACL）在作業系統層級控制「誰可以連線」，伺服器也能用 ImpersonateNamedPipeClient 檢查並借用連線對方的 Windows 帳號。相對地，localhost 的 TCP 連接埠任何人都能連上，必須靠自備的驗證才能確認對方是誰。另一方面，若日後很可能發展成遠端通訊、也要和其他作業系統上的處理程序交談，或想沿用 gRPC 這類既有協定資產，TCP 為基礎的選項較有利。這項判斷也整理在 Windows 行程間通訊選擇的文章裡。

該用位元組模式還是訊息模式？

若想把「一次寫入＝一個意義單位」來處理，訊息模式（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，讓假伺服器無法借用（偽裝）自己的權限。在伺服器要以用戶端權限實際存取的仲介（broker）設計中，必須允許偽裝，因此這項限制要依「設計是否讓伺服器借用權限」來取捨。

使用 ImpersonateNamedPipeClient 有什麼要注意？

最重要的是檢查傳回值。偽裝失敗後若繼續處理，後續操作會以伺服器處理程序自身（往往較高）的權限執行，本不該允許用戶端做的操作就會通過。官方文件也明確寫道：失敗時不得執行用戶端的要求。此外必須先讀過某些內容再呼叫──偽裝是在「最後從管道讀到的訊息」這個脈絡下進行──做完後要以 RevertToSelf 確實回到原本的脈絡。偽裝周邊的機制（權杖、偽裝層級、SeImpersonatePrivilege）在偽裝權杖的文章裡有詳細說明。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。