应用程序可以在收件人手机尚未可达时提交一条短信。SMPP 连接承载该提交操作以及后续报告结果的操作。
连接承载什么？
SMPP 在已连接的系统之间承载消息提交、来信和投递报告。
你的应用程序可以连接到一个网关，由网关将流量进一步路由。如果提供商支持，也可以直接连接到消息中心。
SMPP 参考文档描述了这些角色和操作。消息中心存储短信并将其转发给收件人。
应用程序与消息中心之间的网关增加了一个路由步骤。仅凭协议名称无法判断有多少系统参与处理消息。
SMPP 会话如何工作？
客户端打开连接，对会话进行身份验证，并保持连接可用以执行消息操作。
身份验证步骤称为 bind。发送方会话发送消息，接收方会话接收消息，收发方会话支持双向操作。
使用你的工作流所需的会话类型。当你需要接收操作时，仅发送连接无法替代接收会话。
客户端必须从连接断开中恢复，还必须确认收到的操作。跟踪等待响应的请求，以便将延迟的响应匹配到正确的请求。
提交响应能证明已投递吗？
提交响应报告的是所连接的服务是否接受了提交，而非手机是否已收到短信。
submit_sm 操作提交一条消息。其对应的 submit_sm_resp 报告该请求的结果。
来信和投递回执可以通过 deliver_sm 到达。投递回执参考文档说明了回执操作及其内容。
在你的应用程序中，将提交结果与投递结果分开处理。消息可能被接受后因收件人持续不可达而最终失败。
改用 HTTP API 会有什么变化？
HTTP 提供请求和响应操作，无需你的应用程序管理 SMPP bind。
你的应用程序仍然需要处理重试，也必须处理后续的投递结果。HTTP 不会将运营商的异步投递变成同步保证。
使用 Bird 时，你通过 POST /v1/sms/messages 提交并跟踪返回的消息标识符。发送指南说明了 202 接受响应。SMS 事件提供后续的投递报告。
这些 API 职责与管理到提供商的 SMPP 连接是分开的。API 与网关说明了各层的关系。
使用 SMPP 能让提供商互换吗？
提供商不会仅因为共享同一协议就可以互换。它们可能支持不同的操作、编码和限制。
在迁移流量之前，测试你的应用程序所使用的功能。bind 成功并不意味着该提供商支持所有必需的操作。
网关参考文档建议测试实现支持和性能。更换连接时保留你的投递检查，而不要将新端点视为完整的迁移。
何时应选择 SMPP？
当现有系统需要持久 bind 或 SMPP 特有的接收操作时，选择 SMPP。
- 如果新应用程序没有特定的 SMPP 需求，使用 HTTP。
- 当现有系统需要持久 bind 或 SMPP 特有的接收操作时，使用 SMPP。
- 在迁移生产流量之前，测试提供商支持和投递结果。
简而言之
客户端需要管理会话。
它负责对连接进行身份验证，并在连接失败时进行恢复。
提交和投递是不同的操作。
成功的提交响应并不意味着终端设备已收到消息。
提供商之间的支持各不相同。
测试操作、编码和容量，而不要假设协议使提供商可以互换。
HTTP 可以免去 SMPP 会话管理。
HTTP 免去了管理 SMPP bind 的工作，但你的应用程序仍需处理投递事件。