444 与 SNPP
444 的登记名是 snpp，对应 Simple Network Paging Protocol（RFC 1568）。它把短消息投递到寻呼机以及后来出现的短信网关：客户端连上服务端，用命令提交接收方标识与消息正文，服务端负责后续投递，还支持查询接收方状态与设置优先级。设计思路与 SMTP 类似但报文更精简，是当年把通知送出去的主流手段。寻呼业务退场后，该协议基本只用于历史研究，或对接少量仍在服役的老系统。
基本信息
| 服务名 | snpp（Simple Network Paging Protocol） |
|---|---|
| 传输层 | TCP/UDP |
| 标准 | RFC 1568 |
| 用途 | 向寻呼机或短信网关投递短消息 |
| 现状 | 寻呼时代结束，仅历史系统对接 |
典型使用场景
- 告警通道迁移：把老的寻呼通道换成短信、邮件或告警平台，先评估存量依赖
- 历史系统对接：极少数仍在运行的监控系统需要用 SNPP 把告警送出
- 资产清理：盘点网内监听 444 的主机与对应业务方
- 安全基线：无业务依赖时按未使用端口收敛
- 技术参考：理解消息投递被抽象成独立服务的早期实践
核查命令
核查命令
ss -lntup 'sport = :444' # 是否监听
getent services snpp # 名称登记查询
sudo lsof -i :444 # 占用进程与路径
nc -v pager.example.com 444 # 连通性测试（成功仅说明 TCP 可达）
# 老系统侧：核对告警脚本里的接收方 ID 与 SNPP 服务器地址是否仍有效通知通道演进
| 通道 | 典型协议 | 特点 |
|---|---|---|
| 寻呼 | SNPP 等寻呼协议 | 单向、时延不可控、覆盖有限 |
| 短信网关 | SMPP（运营商侧） | 覆盖好，需网关对接与计费 |
| 邮件 | SMTP | 通用、异步、可能被忽略 |
| 现代告警平台 | Webhook / API | 可组合升级策略与值班机制 |
迁移告警通道时先在测试环境用相同消息量验证到达率与时延，再切生产。老通道往往每年只发几条消息，切换后才发现限流或格式不兼容的情况很常见。
该协议的历史意义是把消息投递抽成独立服务：发送方只负责提交，投递细节交给网关。现代告警平台沿用同样的分层思路，只是把传输换成了 API。