集中管理客户端配置的尝试
674 对应 acap，即应用配置访问协议，规范是 RFC 2244，登记人是 Chris Newman。它的设计目标是把邮箱客户端里的服务器地址、订阅列表与地址簿等配置集中存放在服务端，用户换设备时无需重新配置。它和常用的邮箱访问协议出自同一批设计思路，但因为客户端生态与同步方案选择了别的路径，这套协议没有形成规模部署。
基本信息
| 服务 | acap（应用配置访问协议） |
|---|---|
| 协议 | TCP 与 UDP 均有注册 |
| 规范 | RFC 2244 |
| 登记属主 | Chris Newman |
| 现状 | 部署极少，多数场景改用其他同步机制 |
典型使用场景
- 协议对照：理解配置集中管理这一需求的多种实现路径
- 资产核对：确认该端口是否存在历史服务残留
- 安全巡检：发现监听时核实进程来源
- 排障参考：客户端配置漂移问题应转向当前使用的同步机制
- 策略回收：无依赖时关闭端口并清理放行规则
配置管理方式对照
| 方式 | 覆盖范围 | 当前主流程度 |
|---|---|---|
| 应用配置访问协议 | 客户端配置与名册 | 几乎不再使用 |
| 目录服务 | 账号与组织信息 | 企业内部广泛使用 |
| 客户端管理平台 | 设备与账号策略 | 企业终端管理常用 |
| 手动或脚本配置 | 单机少量设置 | 小型环境仍在用 |
定位占用进程
定位占用进程
# Linux：查看该端口是否被监听
ss -lntup 'sport = :674'
# 交叉验证进程信息
sudo lsof -i :674
# Windows：查看占用与进程号
netstat -ano | findstr :674
# 确认是否仍有客户端连接
sudo tcpdump -i any -n port 674 -c 10配置集中管理带来的副作用是身份信息集中：一旦该服务的凭据被泄露，攻击者可以读取或改写大量用户的配置。审核这类服务时，除了看端口是否可达，还要看账号权限划分是否过粗。
该端口无主流实现，出现监听通常说明环境里存在自研或改造过的组件。这类组件的维护者往往已经离职，补丁与配置变更无人跟进，属于需要优先登记并评估的对象。
核实要点
- 确认监听进程与配置来源
- 确认服务是否仍被客户端依赖
- 确认账号权限是否按最小范围划分
- 确认无依赖后下线并回收放行规则