管道、IPC、Socket：你以为的三种技术，其实是同一件事

从内核 fd 模型出发，揭示管道、IPC 与网络 Socket 的底层统一本质。

引子：一个让人困惑的问题

面试中被问到"管道和 Socket 有什么区别"，大多数人的回答是：管道用于父子进程，Socket 用于网络通信。

这个答案不算错，但只触及了表象。

如果你追问：网络通信算不算 IPC？TCP loopback（127.0.0.1）和 Unix Domain Socket 有什么本质差异？为什么 Node.js 的 net.Socket 可以同时处理 TCP 连接和 Unix Socket？

回答这些问题，需要回到操作系统最核心的抽象------文件描述符（fd）。

一、万物皆 fd

操作系统给每个进程发了一张"资源入场券"------fd 表。fd 编号只是数组下标，背后指向内核中的各类资源对象：

scss 复制代码

进程 fd 表              内核资源对象
─────────              ──────────────
fd 0 ──────────────────→ /dev/tty (终端)
fd 3 ──────────────────→ pipe_inode (匿名管道)
fd 4 ──────────────────→ socket_inode (TCP 连接)
fd 5 ──────────────────→ socket_inode (Unix Socket)
fd 6 ──────────────────→ ext4_inode (普通文件)

关键事实：无论 fd 背后是管道、Socket 还是文件，内核都用同一套接口操作：

c 复制代码

read(fd, buf, len);   // 读
write(fd, buf, len);  // 写
close(fd);            // 关

read() 不关心也不想知道 fd 背后是什么------它只调用 f_op->read() 从对应的内核资源取字节。这就是 Unix "一切皆文件"的真实含义：不是比喻，而是内核用 struct file + f_op 函数表做的统一抽象。

一个直接推论 ：epoll/kqueue/IOCP 可以同时监听 pipe fd 和 socket fd，因为它们在内核看来都是 fd。Node.js 的事件循环正是基于这个统一性工作的。

二、管道：最原始的进程通信

匿名管道

调用 pipe() 时，内核在内存里划出一块 64KB 的环形缓冲区，返回两个 fd------一个读端，一个写端：

css 复制代码

写端 fd ──→ [环形缓冲区 64KB] ──→ 读端 fd

它没有名字，不能跨机器，只能通过 fork() 让子进程继承。

Shell 管道的本质

bash 复制代码

cat file.txt | grep "hello" | wc -l

Shell 做了三件事：创建两条管道，fork 三个子进程，用 dup2() 把每个进程的 stdin/stdout 重定向到对应的管道端点。

bash 复制代码

cat → [管道 A] → grep → [管道 B] → wc

这就是 pipe 作为 IPC 的全部秘密：fork() 继承 fd + dup2() 重定向，让不同进程的 fd 指向同一个内核 pipe_inode。

Node.js 中的管道

spawn({ stdio: ['pipe'] }) 底层就是创建匿名管道，然后 libuv 把 pipe fd 包装成 uv_pipe_t，Node.js 再包一层 net.Socket 暴露给你：

c 复制代码

内核 pipe_inode → libuv uv_pipe_t → Node.js net.Socket → child.stdin/stdout

三、Socket：管道的泛化

Socket 是对"通信端点"的泛化抽象。它不再局限于父子进程，支持任意进程、任意机器通信：

ini 复制代码

Socket = 通信端点 + 寻址方式 + 传输协议

三种地址族，同一个内核对象：

地址族	寻址方式	用途	数据传输
`AF_UNIX`	文件路径	同机 IPC	内核内存直接拷贝
`AF_INET`	IP:Port	网络通信	TCP/IP 协议栈
`AF_INET6`	$IPv6$ :Port	网络通信	TCP/IP 协议栈

一个关键对比

Unix Domain Socket 和 TCP Socket 即使在同一台机器上通信，走的路径也完全不同：

Unix Socket（同机）：

scss 复制代码

进程A ──write()──→ 内核缓冲区(内存拷贝) ──read()──→ 进程B

TCP loopback（同机）：

scss 复制代码

进程A ──write()──→ TCP协议栈(校验/序号/拥塞) ──loopback──→ TCP协议栈(校验/重组/ACK) ──read()──→ 进程B

即使用的是 127.0.0.1，TCP 也会走完整个协议栈------校验和、序号、拥塞控制一个不少。而 Unix Socket 直接在内核内存里搬字节，零协议开销。

这就是为什么同机高性能通信首选 Unix Domain Socket------Nginx、Redis、Docker daemon 都这么干。

四、网络通信是 IPC 吗？

是的。网络通信就是跨机器的 IPC。 这不是类比，是内核设计的真实情况。

三个层面的证据：

1. 内核层面 ：TCP socket fd 和 pipe fd 都是 struct file，通过同一个 f_op 操作。read(fd) 不区分它们。

2. 事件循环层面 ：libuv 的 epoll_wait() 同时监听 pipe fd 和 TCP fd，回调结构完全一致------都是"某个 fd 可读了"。

3. API 层面 ：Node.js 的 net.Socket 同时用于 TCP 和 Unix Socket，写法一模一样：

javascript 复制代码

// TCP
const tcp = net.connect(8080, '127.0.0.1');
tcp.write('hello');

// Unix Socket
const unix = net.connect('/tmp/app.sock');
unix.write('hello');

// 同一套 API，因为底层都是 stream.Duplex

网络通信与本地 IPC 的唯一区别是传输介质：本地 IPC 在内核内存里拷贝，网络通信经过协议栈和物理网络。但"让进程 A 的字节到达进程 B"这个目标从未改变。

五、一张图看清关系

scss 复制代码

管道 (pipe)
  │ 是 IPC 的最简形式
  ▼
IPC ← 目标：进程间交换数据
  ▲
  │ 实现方式之一
Socket (套接字)
  ├── AF_UNIX → 同机 IPC
  ├── AF_INET TCP → 网络通信 (跨机器 IPC)
  └── AF_INET UDP → 网络通信 (无连接)

从 pipe 到 Unix Socket 到 TCP Socket，是一条清晰的演进线：

管道：父子进程、单向、无名字
Unix Socket：同机任意进程、双向、有路径名
TCP Socket：跨机器、双向、IP:Port 寻址

它们在内核中都是 fd，在 libuv 中都是 uv_stream_t，在 Node.js 中都是 net.Socket。层次不同，统一性不变。

六、句柄传递：IPC 的杀手锏

普通管道只能传字节。Unix Domain Socket 有一个独有能力------通过 SCM_RIGHTS 把 fd 本身"发送"给另一个进程。

原理是这样的：进程 A 通过 Unix Socket 告诉内核"我要把 fd 5 传给进程 B"，内核在进程 B 的 fd 表里找一个空位（比如 fd 7），让它指向 fd 5 同一个内核资源，然后告诉进程 B"你的 fd 7 现在可用了"。

css 复制代码

进程A fd 5 ──→ TCP连接到8.8.8.8
    │ sendmsg(SCM_RIGHTS)
    ▼
进程B fd 7 ──→ 同一个TCP连接到8.8.8.8

这就是 Node.js cluster 模块让多个 Worker 共享端口的核心机制------Primary 进程把 TCP 监听句柄通过 IPC 管道传给每个 Worker，所有 Worker 的 fd 都指向同一个 socket inode，内核负责在它们之间分配连接。

七、Node.js 的统一抽象

Node.js 在四层架构上保持了这种统一性：

scss 复制代码

用户代码         → stream.Duplex (write/on('data'))
  ↓
Node.js 层       → net.Socket (TCP + Unix Socket + Pipe 共用)
  ↓
C++ Binding 层   → LibuvStreamWrap → ConnectionWrap
                     ├─ TCPWrap  (uv_tcp_t)
                     └─ PipeWrap (uv_pipe_t)
  ↓
libuv 层         → uv_stream_t (统一流式接口)
  ↓
内核             → struct file + f_op (统一 fd 操作)

TCPWrap 和 PipeWrap 共享 LibuvStreamWrap 的全部读写逻辑，差异仅在底层 libuv 类型。这就是 net.Socket 能同时处理 TCP 和 Unix Socket 的根本原因。

实战选型速查

场景	用什么	底层 fd
父子进程字节流	`spawn({stdio:['pipe']})`	`uv_pipe_t`
父子进程结构化消息 + 句柄传递	`fork()` → `process.send()`	`uv_pipe_t(ipc)`
同机高性能通信	`net.connect('/path.sock')`	`uv_pipe_t`
跨机器通信	`net.connect(8080, host)`	`uv_tcp_t`
Cluster 多 Worker	`cluster.fork()` + `listen()`	pipe + tcp

结语

下次有人问你"管道和 Socket 的区别"，你可以这样回答：

它们是同一个内核抽象在不同场景下的具体形态。 管道是最简的 IPC，Unix Socket 是管道的泛化，TCP Socket 是 Unix Socket 的跨机器扩展。从内核的 fd 表到 libuv 的事件循环再到 Node.js 的 net.Socket，统一性贯穿始终。

理解了这一点，你对 Node.js 网络编程、子进程通信、cluster 多进程架构的认知，就不再是三块孤立的知识，而是一张完整的图。