先说一个结论Unix Domain Socket本地域套接字下文统一叫 UDS是同一台机器上两个进程之间通信最顺手的通道之一。这次分享的是它的 SOCK_STREAM 形态也就是流式连接习惯上可以叫它 UDS 的“TCP 篇”——它长着 TCP 那样的接口做的是比 TCP 更“近”的本地传输。它能解决的问题很具体本地服务之间高频调用、低延迟数据交换、跨进程命令通道。典型场景包括后端服务连接本机的数据库代理、Web 服务与本地中间件通信、监控采集数据上报等。对于正在做服务端开发、中间件开发或者单纯想把本机内进程通信延迟压到最低的同学这篇都值得看看。我会从原理、核心 API、完整 Demo、踩坑记录到性能选型按一套能直接复现的路径讲清楚。1. Unix Domain Socket 到底是什么先弄懂它的“本地 TCP”身份1.1 一个类比和一个关键区别我习惯把 UDS 想象成“同一个大楼内部的自有管道”。TCP 跨机器通信像是走城际物流要打包、安检、上高速、走红绿灯到了还得拆包验收。UDS 则是在同一栋楼里拉了一根专用管道两个房间的人直接对着管道说话不走外部网络也不会遇到“路上堵车”的问题。这个类比基本能解释 UDS 最核心的优势快、稳、不折腾。关键区别在于UDS 压根不经过网络协议栈。它在内核层面把数据从发送进程的内存搬进接收进程的缓冲区没有 IP 地址、没有端口、没有 TCP 头、没有 SYN 和 ACK也不需要路由选择和重传。它只是“长得像 TCP”接口形态用了一模一样的 socket 系列 API但在底层它走的是进程间通信机制而不是网络协议栈。这一点经常被忽略。很多人以为 UDS 就是“本机上面的 TCP”于是拿调优 TCP 的思路去调 UDS结果踩了一堆没必要的坑。比如去设 TCP_NODELAY想关掉 Nagle 算法——这个选项对 AF_UNIX 的 socket 根本没有意义因为压根不走 TCP。正确的心态是把它当做一个“用 socket 接口封装的本地管道”API 熟悉但背后的模型要重新理解。1.2 TCP 篇和 UDP 篇各指什么UDS 也有两种主要形态分别对应用户态接口里的 SOCK_STREAM 和 SOCK_DGRAM。SOCK_STREAM有连接、面向流的通道。数据像水流一样连续写入和读出契通信双方先建立连接再全双工地互相读写。语义上有序、不丢、不重复和 TCP 的“应用层体验”几乎一致。这篇文章大部分内容围绕它展开。SOCK_DGRAM无连接的数据报模式。每次发送都是一整条报文接收方一次 recv 取回一条完整消息。它更像 UDP但如果走 Linux 本机路径消息不会丢、不会乱序可靠性比网络 UDP 高不少。这个属于“UDP 篇”本篇只讲流式形态。这里有一个容易误解的点既然 SOCK_STREAM 叫“流”读者自然会问它会不会像 TCP 一样出现粘包、半包问题答案是会但这不是 UDS 的问题而是流式模型的天然属性。使用流式通道时应用层必须自己设计消息边界要么固定长度要么在消息头里带长度要么用特殊分隔符。很多第一次用 UDS 的朋友在这个地方掉进坑里后面我会专门讲。2. 核心 API 解析从 socket 到 connect 的完整表单2.1 第一步socket() 与 sockaddr_un 的坑在 Linux 上创建一个流式 UDS 只需要一行int fd socket(AF_UNIX, SOCK_STREAM, 0);第三个参数传 0 就可以因为这只选协议族内默认的流式协议。注意这里也可以用PF_UNIX它和AF_UNIX在大多数系统上等价让读者统一用AF_UNIX就行语义更清晰。下一步是准备地址结构这里坑比较密集struct sockaddr_un addr; memset(addr, 0, sizeof(addr)); addr.sun_family AF_UNIX; strncpy(addr.sun_path, /tmp/app.sock, sizeof(addr.sun_path) - 1);表面上和 TCP 那套结构很像但关键在于sockaddr_un里存的是一个文件系统路径而不是 IP 和端口。路径本身有几个隐藏约束路径长度有限。在 Linux 上sun_path只有 108 字节macOS 上更短。如果服务想拉一个很深的目录很可能悄悄被截断客户端连一个不存在的路径报错还很诡异。所以路径尽量短比如/tmp/xxx.sock或/run/xxx.sock。路径不能太“硬”。很多人习惯直接在程序里拼接/run/myapp/cache/data.sock这种长路径一旦目录权限不对或者目录不存在bind 阶段就失败。更好的做法是短路径、固定权限目录、启动时确保目录存在。sizeof(addr)这个参数值得注意。bind 和 connect 时传的第二个参数是指向 sockaddr_un 的指针第三个参数是长度。正确做法是传sizeof(addr)而不是strlen(path)或sizeof(sun_path)。因为内核需要完整读取整个结构体来确定地址类型和路径字段的边界。传小了在某些内核实现下会出现 creack 态的诡异行为。2.2 bind / listen / accept服务端三步走服务端流程和 TCP 服务端几乎一致socket → bind → listen → accept。但有几处必须单独说。bind 之前一个绕不开的问题是“文件已经存在”。UDS 只要 bind 成功文件系统里就会出现这个 socket 文件并且 bind 一个已经存在的路径会被内核拒绝报Address already in use。这和 TCP 的端口占用不完全是同一回事。对应的处理方式也简单在 bind 之前先unlink(path)清掉上一次运行可能残留的旧文件。因为正常情况下上次进程退出时如果忘了清理文件会留在原地。listen 那一步backlog 参数决定了还没被 accept 的等待队列长度。这个数字可以按预估并发稍微放大一点比如 128 或者 256没必要追求极致地大。对 UDS 来说因为不经过网络连接建立本来就很轻backlog 的瓶颈效应不像 TCP 那么明显给个合理值就够了。accept 的返回值是一个新的 fd代表一条已建立的连接。这里要特别注意服务端原来的监听 fd 和这个新连接 fd 是两个完全独立的东西。监听 fd 继续负责接新连接新连接 fd 负责读写数据。很多新手容易在 accept 之后误关监听 fd结果第二波客户端直接连不上。2.3 connect 与流式 I/O客户端视角客户端流程更简单socket → connect → read/write。连接前必须确认服务端的监听 socket 文件已经创建好否则 connect 会报No such file or directory。流式连接建立后读写可以用 read/write也可以用 recv/send。在本地 UDS 场景下我通常直接推荐 read/write没必要用带 flags 的网络 I/O 函数——除非你需要处理MSG_DONTWAIT这类 mark 才能完成的行为。有一个在 TCP 里很常用、但在 UDS 里容易忽略的操作半关闭shutdown()。流式 UDS 也支持 shutdown可以单独关掉发送方向或接收方向。当业务协议约定“客户端发送完请求后就不再写只等响应”时客户端执行shutdown(fd, SHUT_WR)服务端就能通过 read 返回 0 感知到“消息边界”这在流式协议里是一个非常实用的设计手法。比在消息头里抠长度省事得多前提是协议约定得很清楚。3. 手写一个 UDS 流式服务从 C 到 Python 都跑一遍3.1 C 语言服务端核心骨架直接给一个能跑的最小服务端逻辑是接收客户端文本原样回显给客户端。#include sys/socket.h #include sys/un.h #include stdio.h #include string.h #include unistd.h #define SOCK_PATH /tmp/demo_uds.sock int main(void) { int srv_fd, cli_fd; struct sockaddr_un addr; char buf[1024]; srv_fd socket(AF_UNIX, SOCK_STREAM, 0); if (srv_fd 0) { perror(socket); return 1; } memset(addr, 0, sizeof(addr)); addr.sun_family AF_UNIX; strncpy(addr.sun_path, SOCK_PATH, sizeof(addr.sun_path) - 1); unlink(SOCK_PATH); if (bind(srv_fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); return 1; } if (listen(srv_fd, 128) 0) { perror(listen); return 1; } printf(listening on %s\n, SOCK_PATH); while (1) { cli_fd accept(srv_fd, NULL, NULL); if (cli_fd 0) { perror(accept); continue; } ssize_t n read(cli_fd, buf, sizeof(buf) - 1); if (n 0) { buf[n] \0; printf(recv: %s\n, buf); write(cli_fd, buf, n); } close(cli_fd); } close(srv_fd); unlink(SOCK_PATH); return 0; }这套骨架有一个典型特征单线程、一次只处理一个连接。作为 Demo 足够但线上服务基本不会这么写因为 accept 之后如果 read 阻塞后续连接全部排队。要支持并发至少把连接处理丢到独立线程去或者用 epoll 多路复用。第 5 章我会专门展开这个方向。3.2 C 语言客户端连接、发送、收回声#include sys/socket.h #include sys/un.h #include stdio.h #include string.h #include unistd.h #define SOCK_PATH /tmp/demo_uds.sock int main(void) { int cli_fd; struct sockaddr_un addr; char buf[128]; cli_fd socket(AF_UNIX, SOCK_STREAM, 0); if (cli_fd 0) { perror(socket); return 1; } memset(addr, 0, sizeof(addr)); addr.sun_family AF_UNIX; strncpy(addr.sun_path, SOCK_PATH, sizeof(addr.sun_path) - 1); if (connect(cli_fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(connect); return 1; } const char *msg hello uds; write(cli_fd, msg, strlen(msg)); ssize_t n read(cli_fd, buf, sizeof(buf) - 1); if (n 0) { buf[n] \0; printf(echo: %s\n, buf); } close(cli_fd); return 0; }这里有一个细节值得注意客户端 read 拿到的是服务端回显的内容但如果服务端一次性回了多个报文客户端可能只 read 到其中一部分。流式通道没有消息边界read 返回多少取决于当前缓冲区里有多少数据。对于 Demo 没问题但真正做协议时客户端必须在下层实现“读满一个完整消息”的逻辑否则就是经典的“半包 bug”。3.3 Python 版本十分钟快速验证如果只是想快速验证连接流程或者拿 UDS 做自动化测试Python 标准库的 socket 模块可以直接干同样的事。服务端import os import socket SOCK_PATH /tmp/py_demo.sock def main(): if os.path.exists(SOCK_PATH): os.unlink(SOCK_PATH) srv socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) srv.bind(SOCK_PATH) srv.listen(128) while True: conn, _ srv.accept() data conn.recv(1024) if data: print(recv:, data.decode()) conn.sendall(data) conn.close() if __name__ __main__: main()客户端也极短import socket SOCK_PATH /tmp/py_demo.sock cli socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) cli.connect(SOCK_PATH) cli.sendall(bhello from python) data cli.recv(1024) print(echo:, data.decode()) cli.close()从测试到生产Python 这套写法的解释成本极低非常适合当第一版“冒烟测试”工具。不过生产环境里走 Python 做长连接、高吞吐还是要三思——GIL 和全局解释器执行模型会限制并发吞吐作为验证工具绰绰有余作为高并发服务就不推荐了。4. 踩坑实录路径、权限、生命周期和连接状态4.1 bind 报 Address already in use 的真相这是 UDS 新手最常见的报错。其实原因无非三种之前进程崩溃退出socket 文件残留在磁盘上。另一个进程还在监听同一个路径。路径命名冲突别的服务用了同一个 socket 文件。第三点比想象中隐蔽。多个服务共用一个目录随手起了个server.sock结果和其他服务撞车谁也不理谁。排查时第一眼去看文件存在性第二眼去看是谁占用了这个文件用后面 4.4 里的命令查最彻底。既然残留文件是核心原因处理策略也有讲究在 bind 前无脑unlink(path)这能解决大部分情况但也引入一个新的风险——如果当前还有一个老进程正在监听同一个路径你把文件卸载了老进程继续用已经 bind 的 socket 句柄那么新进程 bind 到同一个路径会成功但新连接究竟进入哪个进程取决于内核怎么分发最终结果就是两个“服务”互相打架数据流七零八落。所以生产环境里不要无脑 unlink。比较稳的做法是启动前判断文件是否存在于检查是否真的没人监听没人监听才 unlink。这个检查可以通过后续ss -lx完成。4.2 socket 文件权限与目录权限的双重限制UDS 的 socket 文件是有所有者和权限位的。ls 看一眼srwxr-xr-x 1 app app 0 Jul 4 10:32 /tmp/demo.sock第一个字符是 s表示这是一个 socket 文件。后面的权限位和普通文件一样起作用。默认情况下bind 创建的 socket 权限是0777再按进程 umask 收敛比如 umask 是 022最终文件就是0755。如果客户端进程和服务端进程不是同一个用户就要特别注意权限设置。这里有两个独立的坑socket 文件本身的写权限。connect 一个 socket 文件需要什么权限其实对 socket 文件而言连接行为不仅要求有写权限很多场景还要求有读权限Linux 上实际测试下来要求226这样的权限组合很常见。真到线上组内共享时直接chmod 770最省心或者用chown 用户组统管。所在目录的执行权限。socket 文件路径必须在客户端有搜索权限的目录里否则即使文件权限全放开了客户端也跨不进目录。这一点和普通文件访问完全一致但经常被忽略。一个典型故障服务端把 socket 放在某用户的 home 目录客户端没权限进去connect 报Permission denied。4.3 stale socket 文件与诡异的“假死”现象“假死”是 UDS 生产环境里比较难查的问题之一。表面现象服务进程还活着客户端 connect 却长时间卡住或者立刻失败。一种常见病因是客户端连接 backlog 满了。虽然 UDS 不经过网络但它同样有 backlog 限制listen 参数设成多少未处理连接队列就大概是多少。客户端并发蜂拥而来服务端 accept 不及时后续 connect 请求就会排队甚至触发失败。网络编程里应对突发连接靠 backlog 能解一部分但根治还是得让服务端有足够的并发处理能力。另一种假死是文件残留造成的“连到了静默的旧进程”。自己写的服务如果 bind 逻辑不健壮大概率遇不到但如果你在管理一个老服务盲目 unlink 再 bind就可能让新客户端连上已经失去业务能力的旧监听出现“连接成功但永远等不到数据”的灵异现象。排查它靠错觉靠猜没有用唯一靠谱的是先掌握全量连接状态。4.4 观察 UDS 状态ss -lx 才靠谱想确认本机有哪些 UDS 在监听、谁连着谁一条命令搞定ss -lx输出大致长这样Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port u_str LISTEN 0 128 /tmp/demo_uds.sock * 0 u_str ESTAB 0 0 /tmp/demo_uds.sock 12345u_str表示流式 UDSLISTEN表示当前有监听者ESTAB表示有已建立连接。排查 4.1 里的文件残留问题时ss -lx能直接告诉你“这个路径到底还有没有进程在监听”比 ps 翻进程然后猜路径可靠得多。线上环境做故障诊断我第一步永远是ss -lx它能同时回答“谁在”“谁连了”“队列有多长”这三个问题。5. 性能对比与选型建议什么时候该选 UDS5.1 实测印象UDS 比 TCP loopback 快多少没有精确到千分位的 benchmark但一个稳定的结论我可以说对于本机内的短连接和小消息吞吐UDS 通常比 TCP 走 loopback 快 30% 到 80%延迟也能低 30% 以上。如果消息体只有几十字节、连接建立频繁差距会更明显因为 TCP loopback 也要走完整的协议栈处理而 UDS 直接在内核内存中搬运数据省掉了一整段开销。具体数值会受机器、内核版本、连接模型影响。但“性能高一个档次”这个判断经历过本机压测的人都容易复现。如果你在做一个本地高频调用组件UDS 几乎是必选的优化项不需要犹豫。需要强调的是压测时要小心两个坑压测如果跑在同一个进程里比如用协程反复 send/recv测出来的其实是“内核转运速度”而不是真实并发场景速度结果虚高。压测要区分“连接建立开销”和“单次消息传输开销”。UDS 连接建立已经不贵但建立连接仍然有上下文切换成本长连接模型下测出的性能会远好于短连接模型。所以场景结论更可靠长连接、高频小消息UDS 的收益最大短连接、低频请求收益会被连接成本稀释。5.2 不能用 UDS 的场景UDS 再快也只在“同一台机器”这个前提下成立。一旦跨机器、跨网络UDS 就完全不可用。所以它在分布式系统里通常只承担本地入口的角色充当“本机代理”的接入层后面再走真正的 TCP 转发到其他节点。另一个限制是UDS 依赖本地文件系统路径命名某些容器和网络文件系统环境对 socket 文件的支持不稳定。比如在共享存储上创建 socket 文件行为可能和预期截然不同。按经验UDS 应该放在本地 tmpfs、内存盘或/run目录下不要放在网络挂载或持久化存储上。放在 tmpfs 上还有个附带好处重启自动清空残留文件。还有一点想通过 UDP 组播、广播或者要跨设备路由的就别考虑 UDS 了老老实实走网络协议族。5.3 进阶玩法fd 传递、凭证与多路复用UDS 的能力上限比大多数人想得高。既然都看到这一节我顺手把几个进阶方向列出来文件描述符传递。通过 sendmsg 配合 SCM_RIGHTS服务端可以把一个已经打开的文件 fd、管道 fd、另一个 socket fd 直接传给客户端客户端拿到之后共享同一个内核对象。这是很多优雅重启和权限剥离方案的地基。进程凭证传递。借助 SCM_CREDENTIALS 或 SO_PASSCRED内核会带上发送端的 PID、UID、GID接收进程可以信任这份身份信息。这在本地权限控制里很有用比如只允许特定用户的操作请求。多路复用。UDS 的 fd 可以照常放进 epoll 或 poll 里管理。一个 epoll 服务可以同时监听 TCP 连接和本地 UDS 连接然后走同一套事件循环逻辑上完全统一。真正的生产级 UDS 服务几乎都是这个模型。还有一个和流式 UDS 高度相关的工具socketpair()。它直接创建一对已经连接好的 UDS 流式 fd常用于父子进程间双向通信或者协程之间的唤醒通道不需要 bind 任何路径性能也很理想。如果只是进程间“自己人”通信socketpair 往往比 bind 一个路径更干净。6. 最后分享我自己的几个习惯我自己的项目里UDS 的落地顺序通常是先用 Python 写一套冒烟测试验证协议再用 C 或者 C 做真正的服务进程最后用ss -lx做一轮全量连接检查。协议边界一定在第一天就定义好用固定长度头加 payload 的方式设计比依赖 shutdown 或者临时补分隔符靠谱得多。还有一个容易提升体验的小技巧把 socket 路径统一放到一个独立目录比如/run/myapp/启动时单独创建和授权。这样排查问题时会非常清爽——你只需要看这一个目录里的 socket 文件不会和系统里其他服务撞名也不会在各种 /tmp 残留里翻得焦头烂额。在这个题目上踩过的坑其实比写出来的多。最贵的一条经验是本地通信再快也快不过“少一次通信”。如果能把两个进程合并成一个由调用变成函数执行那比任何 IPC 优化都有效。UDS 是很好的工具但它不该被当成万能的解药。它的定位是在“必须拆进程”的前提下把本地通信的代价压到最低。