551 与 CyberCash
551 的登记名是 cybercash，对应 CyberCash 支付服务，其协议规范即 RFC 1898。它是 1990 年代电商支付网关的先驱：用户在客户端安装钱包软件，商户把支付请求交给 CyberCash 网关，网关再与银行侧网络交互完成授权与扣款。把支付抽象成独立服务的分层思路与今天的支付网关一致，但当时浏览器 SSL 已能覆盖传输安全，钱包模式又要求用户额外安装软件，推广难度大；公司经营失败后被收购，服务随之停运，551 只剩名称登记。
基本信息
| 服务名 | cybercash |
|---|---|
| 传输层 | TCP/UDP |
| 规范 | RFC 1898 |
| 业务模型 | 客户端钱包 + 支付网关 + 银行网络 |
| 现状 | 服务停运，属历史登记 |
典型使用场景
- 支付类资产核查：排查仍标注 CyberCash 组件的历史中间件与端口
- 合规审计：说明历史支付通道的现状与替代方案，形成书面结论
- 架构参考：理解支付网关分层与钱包式客户端的取舍
- 安全基线：历史支付端口不应保留在可被外网访问的范围
- 变更评估：下线前确认没有后台对账或代扣任务仍依赖老通道
现状核查
现状核查
ss -lntu | grep ':551 ' # 是否还有监听
getent services cybercash # 系统名称登记查询
sudo lsof -i :551 # 占用进程与路径
# 遗留支付中间件：先用流量采样确认对端与协议特征
# 再核对业务是否仍依赖该通道，最后排替换窗口；确认完成前不要直接断开支付网关路线对照
| 方案 | 集成方式 | 结果 |
|---|---|---|
| CyberCash | 专用网关 + 客户端钱包 | 用户需装软件，推广失败，服务停运 |
| 浏览器 SSL 表单 | 服务端集成 | 成为行业基线 |
| 3-D Secure | 发卡行参与验证 | 兼顾风控与责任转移 |
| 现代聚合支付 | API 与回调 | 服务端集成，支持多通道 |
CyberCash 的失利常被归因于市场时机，本质是安全模型与用户成本的平衡：要求用户先装钱包才能付款，等于把成交率交给客户端兼容性。做支付方案评估时这类成本要提前算进去。
处置顺序与其他历史支付通道一致：先做流量采样确认对端与协议特征，再核对业务依赖，最后排替换窗口并灰度下线。跳过前两步容易造成对账中断且不易及时发现。