短信API与SMPP对比：该用哪种连接方式？

本指南面向正在决定如何连接短信服务商的工程师和技术负责人：通过HTTP/REST短信API、通过SMPP，还是两者兼用。文中解释二者在网络传输层和运维层面的真实差异，帮助您为每类流量选择合适的接口，并在初始选择不够用时规划迁移。

想进一步了解包括Webhook和幂等性在内的对接模式，请参阅我们的消息API对接指南。

短信API与SMPP有什么区别？

REST短信API把每条消息作为独立的HTTPS请求发送，并返回一个消息ID。SMPP（Short Message Peer-to-Peer）则保持一个长期存在、经过身份验证的会话，并在其中双向交换称为PDU的二进制消息。REST为简单而优化，SMPP为持续的短信发送量而优化。

REST短信API是如何工作的？

您携带token和JSON请求体发起一个HTTPS POST，服务商返回一个ID。每个请求都是独立的，因此您可以从任何服务器、函数或容器发送，而无需管理连接。

使用我们的API，典型的发送请求如下：

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "971500000000",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

响应是200 OK，消息ID以纯文本形式返回。最终状态稍后会通过Webhook以SUBMITTED、SENT、DELIVERED、FAILED或REJECTED的形式到达。字段名称和选项见短信API参考。

REST的优势：

• **熟悉的工具：**任何语言、任何HTTP客户端，以及RFC 9110所定义的标准状态码。
• **安全易做：**全程TLS，并在Authorization头中携带token。
• **无需连接的批量发送：**一次请求即可上传收件人文件，而无需建立会话。
• **一个API覆盖多个渠道：**同样的模式可以发送WhatsApp模板或RCS卡片。

REST的局限：每条消息或每批消息都要付出一次HTTP往返，并且在碰到运营商限制之前，您会先碰到每秒请求数的限制。对大多数应用流量来说，这一点从来不重要。

SMPP是如何工作的？

SMPP是由SMPP v3.4规范定义的二进制协议，该规范由SMPP开发者论坛（后来的SMS Forum）发布，至今仍是部署最广泛的版本。您的系统称为ESME（External Short Message Entity），它连接到服务商的SMSC（Short Message Service Centre，短信服务中心），并打开一个称为bind的会话。

bind类型

• Transmitter（TX），使用bind_transmitter：仅提交消息。
• Receiver（RX），使用bind_receiver：仅接收送达回执和上行消息。
• Transceiver（TRX），使用bind_transceiver：在一个会话上两者兼备。这是通常的选择。

会话生命周期

1. 向服务商提供的主机和端口建立TLS连接。
2. 用您的system_id和密码发送bind_transceiver，并等待command_status为0的响应。
3. 用submit_sm发送消息。每个submit_sm_resp都会返回一个message_id。
4. 以deliver_sm形式接收送达回执，并对每一条回复deliver_sm_resp。
5. 空闲时定期发送enquire_link，让双方都知道会话仍然存活。
6. 用unbind关闭，并等待unbind_resp。

每个PDU都带有序列号，响应携带相同的序列号，您就是靠它把submit_sm_resp与发出的消息匹配起来。我们的SMPP文档结合我们的配置逐步说明了每一步。

什么是SMPP窗口机制？为什么重要？

窗口机制是指在响应返回之前先发送多个submit_sm PDU。允许在途的未确认PDU数量就是窗口。这是SMPP能比逐个HTTP请求维持更高吞吐量的主要原因。

窗口为1时，您的客户端发送一条消息，等待完整的一次往返响应，再发送下一条。吞吐量受网络延迟的限制，而不是您约定的速率。窗口更大时，响应返回期间连接始终保持繁忙。

经验法则：

• 使用服务商与您约定的窗口大小，绝不要超过；多出的PDU可能被拒绝。
• **遵守每个bind约定的速率。**如果收到ESME_RTHROTTLED，请放慢速度并退避重试。
• 跟踪未完成的序列号，这样断线时不会丢失哪些消息已被接受的信息。
• 通过增加bind数量来扩展（上限为您账户约定的数量），而不是不断增大窗口。

我们REST API和SMPP bind的默认限制列在错误与限制中；您账户的具体限制在开通访问权限时确认。

送达回执有何不同？

在REST上，服务商向您的Webhook推送一个JSON事件。在SMPP上，回执以deliver_sm PDU的形式出现在会话上，esm_class中设置了回执位。两者都是异步的；无论200 OK还是submit_sm_resp，都不意味着手机收到了消息。

SMPP v3.4规范以示例的形式给出回执文本格式，并把确切格式留给SMSC厂商，但大多数服务商都遵循它：

id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code

如果您的系统同时使用两种接口，请把SMPP状态映射到统一的状态模型。典型映射如下：

比格式更重要的是两个实际差异：

• **确认。**SMPP客户端必须回复每一条deliver_sm。未确认的回执会被重发，还可能拖慢bind。Webhook处理器也出于同样原因需要迅速回复2xx。
• **恢复。**如果SMPP客户端断线，回执会等待下一次bind，也可能在服务商的队列中过期。在REST上，服务商可能提供按日期范围重新推送回执的功能。请询问两者各自如何运作。

关于每种状态的含义，请阅读消息送达状态详解。

编码是如何处理的？

两种接口都必须在GSM-7和Unicode之间选择，也都会把长消息拆成多个分段。区别在于由谁来做这项工作。

• **REST：**您把messageType之类的字段设置为TEXT或UNICODE，由平台对长消息分段。我们的API还提供POST /sms/identify，可先统计字符数和分段数。
• **SMPP：**您设置data_coding（默认GSM-7字符集为0，UCS-2为8），并自行对字节编码。对于长消息，您要么为每个部分添加User Data Header并把esm_class设为0x40，要么在服务商支持时，把整段文本放进message_payload字段发送。

根据3GPP TS 23.040，一条短信承载140个八位字节：160个GSM-7字符或70个UCS-2字符；加入头部后每个部分降为153或67个。哪怕只有一个阿拉伯字母或一个emoji，整条消息就会变成Unicode。编码错误是最常见的SMPP集成故障，所以请用阿拉伯语、emoji和长文本做测试。请参阅我们的字符限制指南。

两者的安全模型如何比较？

REST依靠TLS和每次请求携带的bearer token。SMPP v3.4自身不带加密，并在bind中发送凭证，因此要依赖周边的传输层和网络控制。

对于SMPP：

• 使用TLS（RFC 8446定义了TLS 1.3）或专线；绝不在公共互联网上使用明文SMPP。
• 登记源IP地址，使只有您的服务器能够bind。
• 将system_id和密码作为密钥存放，各环境分开，泄露时立即轮换。
• 监控bind失败，它可能意味着配置错误或凭证被滥用。

对于REST：

• token只放在服务器端，绝不要放进移动应用或浏览器代码。
• 避免把用户名和密码放在URL里的旧式HTTP接口，它们会最终落入日志。
• 用HTTPS、不可猜测的路径和严格的请求体校验保护Webhook。

两种方案各自的运维成本是什么？

REST几乎不增加运维负担：请求要么成功，要么返回一个可以重试的错误。SMPP则增加了一个需要您监控和维护的长期运行组件。

SMPP客户端需要：

1. 连接管理，使用带退避和抖动的重连，而不是紧凑的循环；
2. 保活，以及对静默的半开连接的检测；
3. 每个bind的窗口和速率控制；
4. 序列号跟踪，以及断线后的对账；
5. 回执的确认与存储；
6. 编码与分段拼接逻辑；
7. 监控bind状态、吞吐量、限流错误和回执延迟。

成熟的开源库能处理协议本身，但围绕它的行为，包括服务商在凌晨3点的维护窗口期间，依然由您的团队负责。

各自应该在什么时候使用？

除非有明确的理由增加SMPP，否则请使用REST。

在以下情况选择REST短信API

• 您从应用发送验证码、告警、通知或营销活动；
• 除短信外，您还需要WhatsApp、RCS或其他渠道；
• 您的平台运行在无服务器函数或短生命周期的容器上；
• 您的团队没有SMPP经验，也没有构建它的必要。

在以下情况选择SMPP

• 您的短信发送量大且持续，并且已触及REST的限制；
• 您已经在运行SMPP网关或消息平台；
• 您是聚合商、运营商或转售商，要接入自己客户的短信流量；
• 您需要在多个上游服务商之间使用同一种协议。

混合方案是什么样的？

许多企业在一个账户上同时使用两者：多渠道和应用流量走REST，批量短信走SMPP。陷阱在于最终出现两套送达模型。

• **按使用场景路由，**而不是随机：例如验证码和WhatsApp走REST，批量的账单短信走SMPP。
• 将来自Webhook和deliver_sm的状态标准化，写入以消息ID为键的同一张表。
• 由于无论使用哪种接口，报备都同样适用，因此在两者上使用同一套Sender ID策略。
• 统一报告，让跨两个接口发送的活动呈现一份结果。

如何从短信API迁移到SMPP？

循序渐进，在两种接口同时运行的情况下，先衡量，再转移流量。

1. **确认需求：**记录REST无法满足的发送量或吞吐量。
2. **申请开通：**提供目的国家、Sender ID、预期峰值吞吐量和源IP地址。
3. 在您的技术栈中选择一个成熟的客户端库，并用自己的发送接口封装它。
4. **先构建回执处理，**并映射到与Webhook相同的状态模型。
5. **测试编码：**在真机上测试GSM-7、阿拉伯语、emoji和多段消息。
6. **测试故障：**在发送过程中切断连接、触发限流并检查对账。
7. **并行运行：**把某类流量的一小部分迁到SMPP，对比送达情况和回执。
8. 分步转移流量，并保留REST作为回退路径。

示例bind配置如下。主机、端口和限制均为占位符，真实值随您开通的凭证一并提供。

host:                 <provided with your bind>
port:                 <TLS port provided with your bind>
bind type:            transceiver
system_id:            <your system_id>
password:             <your password>
system_type:          (empty unless told otherwise)
interface_version:    0x34
source_addr_ton/npi:  5 / 0   (alphanumeric sender ID)
dest_addr_ton/npi:    1 / 1   (international number)
registered_delivery:  1       (request delivery receipts)
data_coding:          0 (GSM-7) or 8 (UCS-2)
enquire_link:         every 30 seconds while idle
window:               as agreed for your account

实战示例：一家区域零售商为账单短信引入SMPP

“Souq Rafiq”（虚构）是一家在阿联酋、埃及和约旦运营的线上零售商，通过REST API发送验证码和订单更新，WhatsApp模板也通过同一个API发送。向全体客户群发送的每月账单短信，增长到了REST任务耗时超出业务期望的程度。

• **决定：**验证码、订单更新和WhatsApp继续使用REST。每月账单短信迁移到SMPP transceiver bind。
• **开通：**团队登记了两个源IP，确认各国的Sender ID，并约定吞吐量和bind数量。
• **开发：**一个小型SMPP服务使用开源库，把回执写入Webhook所用的同一张状态表，并对外提供与REST路径相同的内部发送接口。
• **测试：**在多款手机上确认阿拉伯语账单为UCS-2编码，且分段拼接正确。
• **上线：**先迁移一个国家。把送达情况和回执时间与REST基线对比之后，其他国家依次跟进，并保留REST作为回退。

常见错误

• **为了面子而选SMPP。**如果REST已满足您的发送量，SMPP只会增加工作量。
• **窗口设为1，**然后怪服务商吞吐量低。
• **不确认deliver_sm，**导致回执被重发和限流。
• 断线后**在紧凑循环里重连，**可能看起来像攻击。
• 在同一个PDU中**混用short_message和message_payload，**导致长度错误。
• **在互联网上使用明文SMPP，**暴露凭证和内容。
• 混合方案中**两套状态模型，**导致报表互相矛盾。
• **局限：**本指南描述的是通行做法。窗口大小、速率、TLS端口和回执细节因服务商和账户而异；请在开通时确认。

OmniChannels.ai 如何提供帮助

OmniChannels.ai两种方式都提供。位于https://api.broadnet.me的REST API使用Bearer token，在短信之外还覆盖WhatsApp、RCS、Messenger、Instagram、Telegram、邮件和推送，送达状态以统一格式推送到您的Webhook。对于高并发短信，按账户开通基于TLS的SMPP 3.4 bind，限定白名单源IP，并使用BroadNet运营商直连网络上相同的短信线路。代理商和批发合作伙伴可获得专用bind。请从SMPP文档或快速入门开始，或查看开发者概览。