Web Push 与 1001 端口
1001 端口的 IANA 登记名是 webpush，即 HTTP Web Push，规范见 RFC 8030，由 IESG 于 2016 年登记，消息加密方案见 RFC 8291。它定义浏览器与推送服务之间的订阅与投递流程：页面向推送服务订阅，业务服务端加密消息后提交给浏览器厂商的推送端点，由端点唤醒 Service Worker。实际推送端点普遍运行在 443 上，1001 属协议语义层面的注册端口。
基本信息
| IANA 登记名 | webpush（HTTP Web Push） |
|---|---|
| 端口/协议 | TCP 1001，UDP 1001 保留 |
| 规范 | RFC 8030，加密方案见 RFC 8291 |
| 参与方 | 页面、浏览器厂商推送服务、业务服务端 |
| 关键机制 | 订阅端点加按键加密，由推送服务转发 |
| 处置原则 | 业务不需要时无需放行，真实推送走 443 |
典型使用场景
- 站点通知：把新内容或提醒推送给已授权的订阅者
- 客户端消息送达：借助浏览器推送能力保持到达率
- 运维告警落地：把告警推送到值班人员的浏览器
- 排查投放问题：确认订阅端点变更与密钥轮换是否正确
- 合规评估：核对推送数据流是否满足隐私要求
推送与排障
推送与排障
# 服务端推送示意：向订阅端点提交加密负载
curl -v -X POST https://push.example.net/push/JzLQ3raZ -H 'TTL: 60' --data-binary @payload.bin
ss -lntup 'sport = :1001' # 本机一般无监听，1001 属协议语义端口
# 排查顺序：先看端点可达性与返回码，再核对加密密钥与 TTL 设置关键返回码读法
| 返回码 | 含义 | 处置 |
|---|---|---|
| 201 | 推送已被推送服务接收 | 正常，等待端点投递 |
| 404 或 410 | 订阅已失效或端点变更 | 清理订阅记录并引导重新订阅 |
| 413 | 负载过大 | 压缩内容或减少载荷 |
| 429 | 推送过频被限流 | 降低频率并做退避重试 |
运维要点
- 清理失效订阅要落到定时任务，避免列表越积越大
- 密钥与订阅信息按用户维度存储，支持轮换与失效处理
- 推送频率设置退避策略，被限流后不要立即重试
- 把投递成功率纳入监控，骤降通常意味着厂商端点策略变化
- 测试环境使用独立订阅集合，避免污染真实用户数据
Web Push 的注册端口是协议层面的约定，浏览器厂商的推送端点几乎都走 443。企业网络按域名与 443 规划放行即可，不必专门为 1001 开洞。
推送载荷必须按规范加密并合理设置 TTL：TTL 过短会被离线设备直接丢弃，过长则可能把消息投递到已经失效的会话上。