pipe / fifo / unix socket —— 进程间通信入门
ls | grep foo 是怎么把一个进程的输出送到另一个进程的？答案是 管道（pipe） —— Unix 最经典的 IPC 机制。这篇把 pipe（匿名管道）、fifo（命名管道）、unix domain socket（双向、能传 fd）这三种最常用的进程间通信方式讲清楚。
0. 引言：ls | grep foo 的底层
ls 写到 stdout 就是写到 pipe 的写端；grep 读 stdin 就是读 pipe 的读端。整个过程不落盘、不走网络、纯内核内存。
1. pipe（匿名管道）
#include<unistd.h>intpipe(int pipefd[2]);/* pipefd[0] = 读端 * pipefd[1] = 写端 */
最小例子：父子进程通信
#include<unistd.h>#include<stdio.h>#include<string.h>#include<sys/wait.h>intmain(void){ int fd[2]; pipe(fd); pid_t pid = fork(); if (pid == 0) { /* 子进程：写入 */ close(fd[0]); /* 不用读端 */ const char *msg = "hello from child\n"; write(fd[1], msg, strlen(msg)); close(fd[1]); _exit(0); } else { /* 父进程：读出 */ close(fd[1]); /* 不用写端 */ char buf[100]; ssize_t n = read(fd[0], buf, sizeof buf - 1); buf[n] = 0; printf("parent got: %s", buf); close(fd[0]); wait(NULL); } return 0;}
1.1 pipe 的特点
| |
|---|
| 数据只能从写端流向读端，反向通信要再开一个 pipe |
| 没有路径名，只能在有亲缘关系的进程间使用（fork 共享 fd） |
| |
| 默认 64KB（Linux 可用 fcntl + F_SETPIPE_SZ 调整） |
| |
1.2 关闭"不用的端"是关键
每个进程都拿到一对 fd，但通常只用一端。必须 close 不用的端，否则：
| |
|---|
| 写端 close 后，读端还能读到缓冲数据；但 EOF 永远不来 |
| 读端 close 后，写端 write 会触发 SIGPIPE |
口诀：fork + pipe 后，先关掉"自己用不到的那端"再开始读/写。
1.3 pipe 的特殊行为
/* 写端全关 → 读端 read 返回 0 (EOF) */close(fd[1]);char buf[100];ssize_t n = read(fd[0], buf, sizeof buf);/* n = 0 表示对方关闭了写端，没数据再来了 *//* 读端全关 → 写端 write 触发 SIGPIPE */close(fd[0]);write(fd[1], buf, len); /* 默认 SIGPIPE → 进程被杀 *//* 网络代码常见做法：signal(SIGPIPE, SIG_IGN); 改为返回 -1 + errno=EPIPE */
1.4 pipe2：原子设置 flags
intpipe2(int pipefd[2], int flags);/* flags: O_NONBLOCK | O_CLOEXEC */
pipe2 是 Linux 扩展，可以一步设非阻塞、close-on-exec，避免 race window。多线程程序首选 pipe2(fd, O_CLOEXEC)，否则其他线程恰好在 fork+exec 期间，pipe fd 可能泄漏到子进程。
2. FIFO（命名管道）
pipe 只能在亲缘进程间用。要让任意两个进程通信？用 FIFO（First-In-First-Out，命名管道）。
#include<sys/stat.h>intmkfifo(constchar *pathname, mode_t mode);
FIFO 在文件系统里是一个特殊文件（type 是 ‘p’），但不占磁盘空间（数据走内核缓冲）。
2.1 例子：解耦的生产者消费者
终端 1（消费者，先开）：
终端 2（生产者）：
$ echo "hello FIFO" > /tmp/myfifo
终端 1 立刻输出 hello FIFO，命令结束。
代码版生产者：
int fd = open("/tmp/myfifo", O_WRONLY);write(fd, "hello\n", 6);close(fd);
代码版消费者：
int fd = open("/tmp/myfifo", O_RDONLY);char buf[100];ssize_t n = read(fd, buf, sizeof buf);write(STDOUT_FILENO, buf, n);close(fd);
2.2 FIFO 的特点
| |
|---|
| |
| |
| 默认 open(O_RDONLY) 会阻塞直到有人 open 写端，反之亦然（除非用 O_NONBLOCK） |
| unlink("/tmp/myfifo") 删除文件名；已 open 的 fd 还能用直到 close |
2.3 FIFO 的限制
| |
|---|
| |
| |
| N 个读者同时 read，每条数据被随机一个收到，不能广播 |
3. Unix Domain Socket（最强大的 IPC）
Unix Domain Socket（UDS）是"socket API 在本机内的特化"，跟 TCP/UDP socket 用同一套 socket/bind/listen/accept/connect/send/recv 接口，但不走网络协议栈。
#include<sys/socket.h>#include<sys/un.h>/* 创建：第一个参数是 AF_UNIX（不是 AF_INET） */int sock = socket(AF_UNIX, SOCK_STREAM, 0);/* SOCK_STREAM - 像 TCP，可靠有序字节流 * SOCK_DGRAM - 像 UDP，但本机内不丢包 * SOCK_SEQPACKET - 保留消息边界的可靠流（pipe + 边界） */
3.1 服务端 + 客户端最小例子
服务端：
#include<sys/socket.h>#include<sys/un.h>#include<unistd.h>#include<stdio.h>intmain(void){ int srv = socket(AF_UNIX, SOCK_STREAM, 0); struct sockaddr_un addr = {0}; addr.sun_family = AF_UNIX; strcpy(addr.sun_path, "/tmp/mysock"); unlink("/tmp/mysock"); /* 防止旧文件残留 */ bind(srv, (struct sockaddr*)&addr, sizeof addr); listen(srv, 5); int conn = accept(srv, NULL, NULL); /* 阻塞等连接 */ char buf[100]; ssize_t n = read(conn, buf, sizeof buf - 1); buf[n] = 0; printf("server got: %s", buf); write(conn, "ack\n", 4); close(conn); close(srv); unlink("/tmp/mysock"); return 0;}
客户端：
int s = socket(AF_UNIX, SOCK_STREAM, 0);struct sockaddr_un addr = {0};addr.sun_family = AF_UNIX;strcpy(addr.sun_path, "/tmp/mysock");connect(s, (struct sockaddr*)&addr, sizeof addr);write(s, "hello\n", 6);char buf[100];ssize_t n = read(s, buf, sizeof buf - 1);buf[n] = 0;printf("client got: %s", buf);close(s);
3.2 UDS 的杀手锏：传文件描述符
最强大的特性 —— 进程之间能传 fd（管道、socket、文件、shm 都行）。被传过去的 fd 在接收端可以直接读写。
/* 发送方 */struct msghdr msg = {0};struct iovec iov = { .iov_base = "x", .iov_len = 1 }; /* 必须发一字节占位 */msg.msg_iov = &iov;msg.msg_iovlen = 1;char cbuf[CMSG_SPACE(sizeof(int))];msg.msg_control = cbuf;msg.msg_controllen = sizeof cbuf;struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg);cmsg->cmsg_level = SOL_SOCKET;cmsg->cmsg_type = SCM_RIGHTS;cmsg->cmsg_len = CMSG_LEN(sizeof(int));*(int *)CMSG_DATA(cmsg) = fd_to_send; /* 要传的 fd */sendmsg(uds_fd, &msg, 0);
/* 接收方 */char buf[1];struct iovec iov = { .iov_base = buf, .iov_len = 1 };struct msghdr msg = {0};msg.msg_iov = &iov;msg.msg_iovlen = 1;char cbuf[CMSG_SPACE(sizeof(int))];msg.msg_control = cbuf;msg.msg_controllen = sizeof cbuf;recvmsg(uds_fd, &msg, 0);struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg);int new_fd = *(int *)CMSG_DATA(cmsg);/* 现在 new_fd 在接收端可用 —— 可以读、写、close */
实际应用：
- nginx master + worker：master 把 listen fd 传给 worker
- 容器运行时：把 console fd 从 init 传给 shim
- Wayland：合成器和客户端共享 graphics buffer fd
3.3 UDS 的特点
| | |
|---|
| | |
| ✅ accept 一个新 fd 一个 client | |
| ✅ SOCK_DGRAM/SOCK_SEQPACKET | |
| | |
| ✅ SCM_CREDENTIALS（uid/gid/pid） | |
| | |
| | |
3.4 抽象命名空间（Linux 扩展）
普通 UDS 必须在文件系统里有路径，要 unlink 清理。Linux 提供"抽象命名空间"（路径以 \0 开头）：
struct sockaddr_un addr = {0};addr.sun_family = AF_UNIX;addr.sun_path[0] = 0;strcpy(addr.sun_path + 1, "myabstractsocket");socklen_t len = sizeof(sa_family_t) + 1 + strlen("myabstractsocket");bind(srv, (struct sockaddr*)&addr, len);
好处：
只有 Linux 支持。
4. 三者对比
5. 选哪个？
先用一张决策树定方向：能明确落到 pipe / FIFO 的简单场景就选它们；只要出现双向、多客户端、传 fd、鉴权或服务端架构，直接选 UDS。
| | |
|---|
| 有 fork 亲缘关系，且只需要单向字节流 | pipe | 最快、最简单，天然适合 shell 管道和父子进程通信 |
| 没有亲缘关系，但只需要单向字节流 | FIFO | 通过路径名做 rendezvous，适合解耦生产者和消费者 |
| 需要双向通信、多客户端、传 fd、传凭证或服务端架构 | Unix Domain Socket | |
经验法则：除非你能明确证明 pipe / FIFO 已经够用，否则默认选 UDS。它最强大、最灵活，开销对多数本机 IPC 场景可以忽略。
6. 一些工程细节
6.1 SIGPIPE 永远忽略
任何写 socket / pipe / fifo 的代码都应该：
signal(SIGPIPE, SIG_IGN);/* 之后写关闭的对端，write 返回 -1, errno=EPIPE，不会被杀 */
或者每次发送都加 MSG_NOSIGNAL：
send(fd, buf, len, MSG_NOSIGNAL);
6.2 PIPE_BUF：原子写大小
POSIX 保证 write(pipe_fd, buf, n) 在 n <= PIPE_BUF（Linux 上 4096）时是原子的 —— 多个 writer 写不会交错。超过 PIPE_BUF 就可能切碎。
并发写 pipe 时记得每条消息 ≤ 4KB。
6.3 文件锁（advisory locks）vs UDS
文件锁 fcntl(F_SETLK) 也算一种"协调" IPC，但只是占有标记，不传数据。需要传数据用 UDS。
6.4 socketpair：双 pipe 的替代
int sv[2];socketpair(AF_UNIX, SOCK_STREAM, 0, sv);/* sv[0] 和 sv[1] 是一对相连的全双工 fd * fork 后两端各拿一个 → 父子双向通信 */
比"开两条 pipe 反向各一条"简洁。Python multiprocessing.Pipe 内部就是 socketpair。
7. 跟其他 IPC 对比
Linux 还有更多 IPC 方式，简单提一下：
后续会有专题讲共享内存、消息队列。
8. 几个最容易踩的坑
8.1 fork + pipe 不关 fd → EOF 永远不来
int fd[2]; pipe(fd);if (fork() == 0) { /* 子进程要写 */ /* close(fd[0]); ← 漏了 */ write(fd[1], "x", 1); close(fd[1]); _exit(0);}/* 父进程要读 */close(fd[1]);char buf[10];read(fd[0], buf, 10); /* 读到 1 字节 */read(fd[0], buf, 10); /* 永远阻塞！子进程关了写端但父进程还有，EOF 不来 */
关掉所有不用的 fd，包括自己开的另一端。
8.2 SIGPIPE 没忽略
写关闭 socket → 进程被杀。生产代码必须 SIG_IGN。
8.3 UDS path 残留
bind 失败 EADDRINUSE：上次进程崩溃留的 socket 文件还在。bind 前 unlink 掉旧文件。或者用抽象命名空间。
8.4 传 fd 时 iov 必须有数据
SCM_RIGHTS 控制消息单独发不行，必须搭配至少 1 字节的普通数据。否则接收端 recvmsg 拿不到 cmsg。
8.5 close-on-exec
fork+exec 链路上多个 fd，pipe 默认会被 exec 后的程序继承。要么用 pipe2(fd, O_CLOEXEC)，要么 fcntl(F_SETFD, FD_CLOEXEC)。
9. 总结
| |
|---|
| pipe | |
| fifo | |
| unix domain socket | 几乎所有其他场景；尤其需要全双工、多客户端、传 fd |
技术演进的视角：
- 90 年代 socket API 统一，UDS 成为最强大的本机 IPC
- 现代框架（gRPC、D-Bus、systemd）大量基于 UDS
掌握这三种基础 IPC，就能理解 nginx 的 worker 通信、Docker shim 与 daemon 的 RPC、systemd 的 socket activation、PostgreSQL 的连接、Wayland 的 buffer 共享 …… 几乎所有现代 Linux 服务的底层。
10个月宝宝每天需要喝多少奶粉？
