--- title: "短信API与SMPP对比：该用哪种连接方式？" description: "短信API与SMPP全面对比：会话与bind、窗口机制、吞吐量、送达回执、编码方式、TLS安全、运维成本以及迁移步骤，帮助工程团队判断该用REST、SMPP还是两者混合使用，找到最适合自己业务量和团队能力的短信对接方案，少走弯路。" canonical: "https://omnichannels.ai/zh/blog/sms-api-vs-smpp/" language: "zh" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "integration" primaryQuery: "sms api vs smpp" keywords: ["SMPP和HTTP API区别", "REST短信API", "SMPP bind transceiver", "SMPP窗口吞吐量", "SMPP送达回执 deliver_sm", "SMPP over TLS", "从HTTP迁移到SMPP", "SMPP 3.4"] published: "2026-10-10" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 12 answer: "验证码、告警和通知等应用类流量，以及同时还需要WhatsApp、RCS或其他渠道的场景，请使用REST短信API：它是无状态的HTTPS，易于做好安全防护，开发也快。如果您的短信发送量大且持续、已经在运行SMPP客户端或在转售短信，则使用SMPP，因为带窗口机制的持久bind能让大量消息同时在途。许多企业会在一个账户上两者并用。" takeaways: ["REST短信API把每条消息作为独立的HTTPS请求发送；SMPP则保持一个称为bind的长连接会话，并在其上交换二进制PDU。", "SMPP的吞吐量取决于窗口机制：如果客户端每发一条都要等到submit_sm_resp才发下一条，就会浪费大部分连接能力。", "REST的送达状态通过Webhook到达；SMPP的送达回执则以deliver_sm PDU的形式在同一会话上到达，每一条都必须确认。", "SMPP v3.4没有内置加密，所以生产环境的bind应当运行在TLS上，并只允许白名单中的源IP地址。", "SMPP只承载短信，因此用REST处理多渠道流量、用SMPP处理批量短信的混合方案，是常见的长期架构。"] faq: - q: "SMPP比短信API更快吗？" a: "SMPP能维持更高的吞吐量，因为一个持久会话可以让大量消息同时在途，而不必为每条消息发起新的HTTP请求。对于单条验证码，差异很少能被察觉，因为运营商的送达时间才是主导因素。两种接口的吞吐量都由您的账户限制决定，所以请向服务商索取文档化的限制，而不要想当然地认为SMPP总是更快。" - q: "可以通过SMPP发送WhatsApp消息吗？" a: "不可以。SMPP是用于短信及相关短消息服务的协议。WhatsApp、RCS、Messenger、Instagram、邮件和推送都使用HTTP API。如果需要多个渠道，请对它们使用REST API，仅在需要时再为高并发短信增加SMPP。" - q: "什么是SMPP bind？" a: "bind是您的客户端（称为ESME）与服务商SMSC之间经过身份验证的SMPP会话。您先建立TCP或TLS连接，再用system_id和密码发送bind_transmitter、bind_receiver或bind_transceiver。transceiver bind在一个会话上既提交消息又接收送达回执，这是通常的选择。" - q: "SMPP安全吗？" a: "SMPP v3.4本身不加密流量，凭证在bind请求中发送。生产环境的bind请运行在TLS上，把连接限制在已登记的源IP地址，将system_id和密码作为密钥存放，一旦泄露立即轮换。应避免在公共互联网上使用明文SMPP。" - q: "SMPP和REST的送达回执有什么不同？" a: "在SMPP上，回执以deliver_sm PDU的形式到达，文本中带有类似stat:DELIVRD的内容，您的客户端必须以deliver_sm_resp作为回复。在REST上，服务商会向您的Webhook推送一个JSON事件，带有DELIVERED或FAILED之类的标准化状态。两者都是异步的：已被接受的提交永远不是送达的证明。" - q: "从短信API迁移到SMPP需要多长时间？" a: "如果使用成熟的SMPP库，慢的部分并不是写代码。开通配置更耗时：约定吞吐量和bind数量、登记源IP，以及测试回执和编码。在把流量迁过去之前，请规划一段并行运行期，先让一小部分流量走SMPP。" sources: - title: "Short Message Peer to Peer协议规范v3.4（SMPP.org）" url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf" - title: "SMPP.org：Short Message Peer-to-Peer协议资源" url: "https://smpp.org/" - title: "RFC 8446：传输层安全（TLS）协议1.3版" url: "https://www.rfc-editor.org/rfc/rfc8446" - title: "RFC 9110：HTTP语义" url: "https://www.rfc-editor.org/rfc/rfc9110" - title: "3GPP TS 23.040：短消息服务（SMS）技术实现" url: "https://www.3gpp.org/dynareport?code=23040" --- # 短信API与SMPP对比：该用哪种连接方式？ Canonical: https://omnichannels.ai/zh/blog/sms-api-vs-smpp/ Language: zh Publisher: OmniChannels.ai by BroadNet Technologies 本指南面向正在决定如何连接短信服务商的工程师和技术负责人：通过HTTP/REST短信API、通过SMPP，还是两者兼用。文中解释二者在网络传输层和运维层面的真实差异，帮助您为每类流量选择合适的接口，并在初始选择不够用时规划迁移。 想进一步了解包括Webhook和幂等性在内的对接模式，请参阅我们的[消息API对接指南](/blog/messaging-api-integration-guide/)。 ## 短信API与SMPP有什么区别？ REST短信API把每条消息作为独立的HTTPS请求发送，并返回一个消息ID。SMPP（Short Message Peer-to-Peer）则保持一个长期存在、经过身份验证的会话，并在其中双向交换称为PDU的二进制消息。REST为简单而优化，SMPP为持续的短信发送量而优化。 | | REST短信API | SMPP v3.4 | |---|---|---| | 传输方式 | HTTPS请求与响应 | 持久TCP会话，生产环境用TLS封装 | | 状态 | 无状态；每个请求独立 | 有状态的bind，带序列号和保活 | | 鉴权 | 请求头中的Bearer token | bind中的`system_id`和密码，外加IP白名单 | | 渠道 | 短信，以及通过多渠道API支持的WhatsApp、RCS等 | 仅短信 | | 吞吐模型 | 每秒请求数，外加批量接口 | 每个bind每秒消息数，借助窗口机制让大量消息在途 | | 送达回执 | 带标准化状态的JSON Webhook | 会话上的`deliver_sm` PDU，文本回执格式 | | 编码 | 类似`messageType`（`TEXT`或`UNICODE`）的字段 | `data_coding`（GSM-7为0，UCS-2为8），长消息使用UDH | | 工具 | 任意HTTP客户端、SDK、OpenAPI | SMPP客户端库 | | 运维成本 | 低 | 中等：连接、重连、窗口、回执 | | 最适合 | 应用、验证码、通知、多渠道 | 聚合商、代理商、有SMPP经验的高发送量用户 | ## REST短信API是如何工作的？ 您携带token和JSON请求体发起一个HTTPS `POST`，服务商返回一个ID。每个请求都是独立的，因此您可以从任何服务器、函数或容器发送，而无需管理连接。 使用我们的API，典型的发送请求如下： ```bash 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参考](/developers/sms/)。 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文档](/developers/smpp/)结合我们的配置逐步说明了每一步。 ## 什么是SMPP窗口机制？为什么重要？ 窗口机制是指在响应返回之前先发送多个`submit_sm` PDU。允许在途的未确认PDU数量就是窗口。这是SMPP能比逐个HTTP请求维持更高吞吐量的主要原因。 窗口为1时，您的客户端发送一条消息，等待完整的一次往返响应，再发送下一条。吞吐量受网络延迟的限制，而不是您约定的速率。窗口更大时，响应返回期间连接始终保持繁忙。 经验法则： - **使用服务商与您约定的窗口大小**，绝不要超过；多出的PDU可能被拒绝。 - **遵守每个bind约定的速率。**如果收到`ESME_RTHROTTLED`，请放慢速度并退避重试。 - **跟踪未完成的序列号**，这样断线时不会丢失哪些消息已被接受的信息。 - **通过增加bind数量来扩展**（上限为您账户约定的数量），而不是不断增大窗口。 我们REST API和SMPP bind的默认限制列在[错误与限制](/developers/errors-and-limits/)中；您账户的具体限制在开通访问权限时确认。 ## 送达回执有何不同？ 在REST上，服务商向您的[Webhook](/developers/webhooks/)推送一个JSON事件。在SMPP上，回执以`deliver_sm` PDU的形式出现在会话上，`esm_class`中设置了回执位。两者都是异步的；无论`200 OK`还是`submit_sm_resp`，都不意味着手机收到了消息。 SMPP v3.4规范以示例的形式给出回执文本格式，并把确切格式留给SMSC厂商，但大多数服务商都遵循它： ```text id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code ``` 如果您的系统同时使用两种接口，请把SMPP状态映射到统一的状态模型。典型映射如下： | SMPP `stat` | 含义 | 标准化状态 | |---|---|---| | `ACCEPTD` | 已接受，中间状态 | SENT | | `DELIVRD` | 已送达手机 | DELIVERED | | `UNDELIV` | 无法送达 | FAILED | | `EXPIRED` | 有效期已结束 | FAILED | | `REJECTD` | 被拒绝，例如发件人被封 | REJECTED | | `DELETED` | 在送达前被删除 | FAILED | | `UNKNOWN` | 无状态信息 | 保留最后一个已知状态 | 比格式更重要的是两个实际差异： - **确认。**SMPP客户端必须回复每一条`deliver_sm`。未确认的回执会被重发，还可能拖慢bind。Webhook处理器也出于同样原因需要迅速回复`2xx`。 - **恢复。**如果SMPP客户端断线，回执会等待下一次bind，也可能在服务商的队列中过期。在REST上，服务商可能提供按日期范围重新推送回执的功能。请询问两者各自如何运作。 关于每种状态的含义，请阅读[消息送达状态详解](/blog/message-delivery-status-explained/)。 ## 编码是如何处理的？ 两种接口都必须在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和长文本做测试。请参阅我们的[字符限制指南](/blog/sms-character-limits-unicode-arabic/)。 ## 两者的安全模型如何比较？ 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配置如下。主机、端口和限制均为占位符，真实值随您开通的凭证一并提供。 ```text host: port: bind type: transceiver system_id: 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文档](/developers/smpp/)或[快速入门](/developers/quickstart/)开始，或查看[开发者概览](/developers/)。