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

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

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

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

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

一、万物皆 fd

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

进程 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 还是文件，内核都用同一套接口操作：

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——一个读端，一个写端：

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

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

Shell 管道的本质

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

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

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 暴露给你：

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

三、Socket：管道的泛化

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

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

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

一个关键对比

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

Unix Socket（同机）：

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

TCP loopback（同机）：

进程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，写法一模一样：

// TCPconst tcp = net.connect(8080, '127.0.0.1');tcp.write('hello');// Unix Socketconst unix = net.connect('/tmp/app.sock');unix.write('hello');// 同一套 API，因为底层都是 stream.Duplex

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

五、一张图看清关系

管道 (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 现在可用了"。

进程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 在四层架构上保持了这种统一性：

用户代码 → 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 的根本原因。

实战选型速查

结语

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

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

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