# SMPP 与 HTTP：企业短信该选哪种连接

SMPP 保持一条长会话，每条绑定带一个吞吐窗口。HTTP 每次请求都要认证，回执走回调。两者运送的是同一批短信，报告的是同一组送达状态。选择要看流量形态，也要看团队能处理哪种故障。

- SMPP 保持一条会话，每条绑定带一个在途请求窗口。

- HTTP 每次发送都发起一次带认证的请求，回执走回调。

- 两种模型返回相同的送达状态，只是到达方式不同。

- 故障不同。SMPP 是绑定窗口占满，HTTP 是回调变慢。

## 一段话讲清选择

量不大、流量呈波峰、团队已经在运维 Web 端点，就先上 HTTP。流量是稳定流、每次请求的认证和建连成本开始显眼，或者回执必须和发送走同一条 transceiver 会话，就转 SMPP。很多平台两者并用。SMPP 走发送流，HTTP 收回调。
协议不是产品。路由、发送方注册和真机测试才决定短信到不到。SMPP 和 HTTP 只是通向同一个短信中心的两种方式，哪一种都可能被用好，也可能被用坏。
真正该问的是哪种故障您的团队看得见、修得动，并且修得过来。凌晨两点的静默绑定和凌晨两点的失败回调，都是运维问题。选工具能诊断的那一种。

### 同一件事，两种形态

|  | SMPP | HTTP |
| --- | --- | --- |
| 会话 | 认证后保持打开的绑定 | 每次请求都带密钥 |
| 窗口 | 每条绑定固定的在途窗口 | 并发由客户端和连接池决定 |
| 送达回执 | 在 transceiver（或独立的 receiver）绑定上收 deliver_sm PDU | 回调到您的端点 |
| 上行短信 | 在 receiver 或 transceiver 绑定上收 deliver_sm | 回调到您的端点 |
| 重试 | 客户端管窗口和退避 | 客户端重试请求，服务商重试回调 |

这张表讲的是传输，不是某家服务商的实现。细节在接入时确认。

## 吞吐跟着形态走

SMPP 绑定按吞吐速率和窗口开通。会话一旦建立，一次提交就是一条 PDU 加一个响应，不需要重新握手。所以 SMPP 适合稳定流，容量也好算：数绑定、看配额、让在途请求保持在窗口以内。
HTTP 每次请求都要付认证和建连的成本，复用连接能压低一部分。容量来自并发，不来自绑定窗口，所以客户端可以先打一波高峰，然后撞上速率限制或排队。这种弹性适合活动和低量应用。如果客户端不限制并发，峰值也更难算清。速率限制和窗口是两种不同的控制。一个限每秒请求数，一个限在途请求数。逐请求的成本在高量时才显眼，每天几千条还看不出来。

改速率和窗口，规划器在浏览器里计算。

[Open the tool](/zh/tools/tps-planner/?src=learn-smpp-vs-http&scenario=campaign-50tps&tps=50&windowMin=60)

## 回执和上行决定接入方式

SMPP 在 receiver 或 transceiver 绑定上送回执和上行短信。客户端必须保持会话存活才能收到，按存下的 message ID 匹配回执，再用 deliver_sm_resp 确认。这里没有回调端点要保护，但有会话要监控：绑定开着却不说话，本身就是故障。
HTTP 把回执和上行短信送到一个 URL。接收方验签、快速响应，再异步处理事件。回调变慢是最常见的故障。服务商超时、重试，同一个事件被处理两次。幂等键和快速确认是接入的一部分，不是优化项。
不管回执走哪条路，原始报文都要留下。服务商的解释可能变，工单往往就靠原始状态或错误码定位。把它和 message ID、路由、时间存在一起。

### 要提前设计的故障

| 故障 | 表现 | 怎么处理 |
| --- | --- | --- |
| 绑定窗口占满 | 超时和重试一起上升，队列越积越长 | 停止重试，等窗口排空，再加一条绑定 |
| 会话静默 | 绑定开着，但没有响应回来 | 发 enquire_link，超时后关闭会话，退避重连 |
| 回执错配 | 状态挂到了错误的短信上 | 按 message ID 匹配，不按到达顺序 |
| 回调变慢 | 服务商重试，出现重复 | 快速响应，异步处理，加幂等键 |
| 缺少幂等 | 一次网络重试造出两条短信 | 带上客户端参考号，按它去重 |
| 编码漂移 | 长短信分段到达，或字符出错 | 明确设成 GSM-7 或 UCS-2，并验证分段数 |

这些修法都是运维动作，换传输方式免不了。

## 怎么选，怎么接

发送流稳定、服务商给的窗口您能算清、团队能运维会话（管绑定、发心跳、重连、看 PDU 日志），就选 SMPP。量中等、团队已经在运维安全的 Web 端点、回调能融进架构，就选 HTTP。发送和上行由不同团队负责，就两条都用。
不管选哪种，要的证据一样：测试路由、吞吐配额、回执格式、错误码清单和重试策略。[SMPP 详解](/zh/resources/learn/what-is-smpp/)讲会话，[接入指南](/zh/resources/guides/smpp-http-connection/)讲上线路径。
把选择写成数字：峰值速率、每条绑定的窗口、回调超时和重试预算。没有这些数字的决定只是偏好。峰值或团队变了，就重新看一遍。

### Check what you learned

**一场活动稳定在每秒 40 条，回执必须走同一条 transceiver 会话。选哪种传输？**

SMPP，用 transceiver 绑定，绑定数量要够，窗口按速率配置。HTTP 也能承载这个量，但回执走回调，不走 SMPP 会话。

**回调端点要八秒才响应，会出什么问题？**

服务商超时后重试，同一个事件会再送一次。先快速响应，再处理事件。

**为什么静默绑定比掉线绑定更难处理？**

掉线是看得见的失败。静默绑定看起来还开着，客户端会一直发到超时才发现。心跳能更早发现。

## FAQ

**可以两种都用吗？**

可以。很多平台在迁移期用 SMPP 发送，用 HTTP 收回调。

**哪种接起来更快？**

HTTP，通常一个下午。流量稳定到值得维护长会话时，SMPP 才划算。

**哪种更可靠？**

单靠协议都不可靠。可靠性来自路由、重试策略和周边的运维。

**HTTP 能扛高吞吐吗？**

能，靠并发、连接池和异步回调。稳定流通常还是 SMPP 更省，因为会话和回执通道本来就是开着的。

**需要固定 IP 吗？**

SMPP 往往需要，因为服务商要给客户端 IP 开白名单。HTTP 接入通常用 TLS 和密钥。动手前先确认要求。

## Sources

- [smpp.org：SMPP 会话、PDU 操作与送达回执](https://smpp.org/) — Accessed: 2026-10-19
- [IETF RFC 9110：HTTP 语义](https://datatracker.ietf.org/doc/html/rfc9110) — Accessed: 2026-10-19
- [3GPP TS 23.040：短消息业务的技术实现](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19