Linux systemd.socket Accept 怎样选择每连接服务实例

在 Linux 的 socket activation 配置里，Accept= 决定的不是“要不要接收连接”这么简单，而是决定连接由谁拆分、服务拿到哪一个文件描述符，以及服务单元是不是模板实例。实际选择可以先记成一句话：需要一个进程统一管理监听队列时用 Accept=no；希望每条流式连接进入独立服务进程、把处理逻辑写成 inetd 风格时才考虑 Accept=yes。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html

如果你写的是高吞吐、长期运行的新服务，优先从 Accept=no 开始；如果服务天然“一次只处理一个连接”，并且需要按连接隔离资源，再使用 Accept=yes，同时配好模板服务和实例回收。

先区分监听套接字与连接套接字

systemd.socket 负责监听并在有流量时触发服务。真正影响服务代码的是 systemd 传递的文件描述符：Accept=no 时，服务拿到监听套接字，程序自己负责继续 accept() 并管理多条连接；Accept=yes 时，systemd 为每个连接创建一个服务实例，只把已经接受的连接套接字交给该实例。

这也解释了为什么两种模式的服务命名规则不同：Accept=no 默认寻找同名的 foo.service；Accept=yes 则要求模板 foo@.service，每次连接对应一个实例名。若把普通服务文件误用于 Accept=yes，问题通常不是端口没监听，而是触发目标和服务接收方式不匹配。

按服务模型选择 yes 或 no

对性能敏感的服务通常选 Accept=no。它只需要启动一个服务单元，后续连接由服务进程自行接收，不会为每个连接重复支付服务实例的启动和沙箱成本。代价是程序必须正确处理监听套接字、并发、连接退出和资源回收。

Accept=yes 更适合零星使用的服务、一次处理一个连接的旧式 inetd 程序，或者确实需要按连接划分权限和资源的场景。每个实例只看到自己的连接套接字，配置 sandbox 选项时可以把并行连接隔离开；但连接越多，实例创建、日志、内存和退出清理的压力越明显。

用匹配的 unit 名称表达服务模型

下面是一组最小配置的写法。配置中的注释说明了为什么服务文件必须使用模板名；它不是可直接复制的生产端口方案，部署时应替换监听地址、用户和权限策略。

# /etc/systemd/system/line-worker.socket
[Unit]
Description=Per connection line worker socket

[Socket]
# Accept=yes 让每个进入的流式连接对应一个 line-worker@.service 实例。
ListenStream=127.0.0.1:9100
Accept=yes

# Accept=yes 场景建议回收已结束或失败的实例，避免失败单元长期留存。
CollectMode=inactive-or-failed

[Install]
WantedBy=sockets.target

# /etc/systemd/system/line-worker@.service
[Unit]
Description=One line worker connection (%i)

[Service]
# 模板实例只处理 systemd 已经传入的这一条连接，不要再次把它当监听套接字。
ExecStart=/usr/local/libexec/line-worker --single-connection
# 让服务进程在退出时释放自身资源，具体超时应按程序行为调整。
TimeoutStopSec=15s

# 生产环境按实际最小权限改写 User、ProtectSystem 等边界。
User=line-worker
NoNewPrivileges=yes

如果改成 Accept=no，socket 单元应触发普通的 line-worker.service，程序则需要通过 systemd 的文件描述符传递接口接收监听套接字并自行管理连接。不要只把 Accept=yes 改成 no，却保留“单连接后退出”的服务逻辑。

为每连接实例设置并发边界和回收策略

Accept=yes 的并发上限应当显式考虑。MaxConnections= 限制同时运行的服务实例数量，官方默认值是 64；超过上限的新连接会被拒绝，直到已有连接结束。若需要按来源进一步限制，可使用 MaxConnectionsPerSource=，它按 IPv4/IPv6 地址、AF_VSOCK 的来源 CID 或 AF_UNIX 的来源 UID 计算。

# 追加到 line-worker.socket 的 [Socket] 段。
# 只允许有限数量的实例并发，避免每个连接都无限扩张进程数。
MaxConnections=32

# 设为正数时按来源地址或 UID 再做一层限制；0 表示不启用该限制。
MaxConnectionsPerSource=8

实例退出策略也要和连接模型一起看。官方建议为 Accept=yes 激活的服务实例设置 CollectMode=inactive-or-failed，这样已经结束或失败的实例可以被清理，不会只因为失败记录而持续占用管理器内存。

发布前检查几个容易误配的边界

1. 先确认 socket 类型。Accept= 对数据报 socket 和 FIFO 不按每个连接拆分实例，这些类型由单个服务统一处理。不要用 TCP 流式连接的经验推断到 UDP。
2. 不要滥用 Service=。在当前 systemd.socket 文档中，Service= 只允许用于 Accept=no 的 socket；Accept=yes 依赖与 socket 同名的模板服务。
3. 不要删除 AF_UNIX 节点。服务可以按模式关闭收到的套接字，但不应自行 unlink 文件系统中的 AF_UNIX socket。节点的生命周期应由 socket unit 管理。
4. 区分环境变量和业务协议。IPv4/IPv6 连接的实例可以读取 REMOTE_ADDR、REMOTE_PORT；Accept=yes 还会提供 SO_COOKIE。这些字段方便记录连接来源，不代表应用层认证已经完成。
5. 把触发限流纳入发布检查。连接非常密集时，还要结合 TriggerLimitIntervalSec= 与 TriggerLimitBurst= 检查 socket unit 的激活节奏，避免把实例上限误当成全部限流策略。

实践中，我会把“服务是否自行 accept”作为第一判断，把“每连接是否需要独立权限和故障边界”作为第二判断，最后才用 MaxConnections 和回收策略收口。只要服务是长期高频的多连接程序，Accept=no 通常更稳；只要服务是偶发、单连接、需要模板实例隔离的处理器，Accept=yes 才有清晰收益。

相关问题

Accept=yes 为什么必须用 @.service？

因为 systemd 要为每条连接启动一个服务实例，模板服务才有实例名可以承载这条连接。socket 名为 foo.socket 时，默认匹配的是 foo@.service，而不是普通的 foo.service。

Accept=no 是否不能并发处理连接？

不是。它只是把监听套接字交给一个服务进程，程序仍然可以自行创建 goroutine、线程或事件循环来处理多个连接；并发模型由程序负责。

MaxConnections=0 是否代表无限并发？

不要把它当成通用的“解除所有限制”开关。应以当前 systemd.socket 文档对该选项的说明和本机版本行为为准；发布时至少同时检查触发限流、进程资源和服务自身的连接上限。