端口与体系
605 对应 IANA 登记的 soap-beep，规范为 RFC 4227，约定如何在 BEEP 框架上承载 SOAP 消息。它出现在 Web 服务依赖结构化消息的年代，目标是借助 BEEP 的多通道与异步特性改善消息传输效率。
现状
如今这类接口大多运行在标准 Web 协议之上，工具链与生态都更成熟，基于 BEEP 的形态基本退出使用，因此这个端口在现网很少见到，主要留存在规范与老项目的设计文档里。
基本信息
| 服务名称 | soap-beep |
|---|---|
| 传输协议 | TCP 与 UDP |
| 规范 | RFC 4227 |
| 所属体系 | BEEP 上的 SOAP 承载 |
| 当前状态 | 少见部署 |
典型使用场景
- 老项目接口梳理：确认是否还有基于该规范的调用链路
- 协议栈核对：区分消息格式与承载方式两件事
- 迁移评估：把历史接口迁到通行承载方式时的改动范围评估
- 扫描报告解读：扫描器标注 soap-beep，与实际进程比对
- 放行策略审计：历史接口通道应随系统下线一并回收
- 未知服务处置：无对应组件时按未知服务流程取证
定位占用进程
定位占用进程
# Linux：查看 605 的监听进程
ss -lntup 'sport = :605'
# 交叉验证可执行文件归属
sudo lsof -i :605
# 顺带核对当前实际在用的接口端口
ss -lntup | grep -E ':(80|443|8080|8443)\b'
# Windows：取 PID 后反查
netstat -ano | findstr :605
tasklist /FI "PID eq 1234"消息承载方式对照
| 承载方式 | 特点 | 现状 |
|---|---|---|
| 基于标准 Web 协议 | 工具链成熟、易调试 | 绝大多数接口的做法 |
| 基于 BEEP | 多通道与异步特性 | 未形成规模，逐步退出 |
| 判读依据 | 服务描述与配置文件 | 不要凭端口猜协议栈 |
消息格式与承载协议是两件事：同样的消息可以跑在不同承载之上，迁移时改动的是承载与调用方式，数据契约往往可以保留。把两者分开看，迁移评估的结论会清晰得多。
接口迁移的隐藏成本在于重试与超时语义：老承载的异步特性与新承载的同步特性不一致，直接平移会让重试逻辑变得不可预期，需要在设计阶段明确约定。