只提供有价值的信息，杜绝冗余。
SMPP的工作原理，逐步解析
ESME开启一个TCP（理想情况下为TLS）连接，并发送带有system_id和密码的bind_transceiver。绑定完成后，它将每条消息作为submit_sm PDU提交；SMSC通过携带message_id的submit_sm_resp进行确认。状态报告通过同一个套接字以deliver_sm PDU的形式异步到达，并由message_id进行匹配。每30秒一次的enquire_link心跳包可保持会话活跃，unbind操作则可干净地关闭连接。详见/answers/what-is-smpp和/answers/what-is-esme.
绑定类型与版本
ESME可绑定为发送端（仅发送）、接收端（仅接收）或收发端（在单个连接上实现双向）。基于SMPP 3.4的收发端是现代默认标准。SMPP 5.0增加了Unicode清晰报头和小区广播支持，但几乎无人部署 —— 目前的装机量绝大多数仍为3.4。BroadNet接受SMPP 3.4绑定；主机、端口和凭据将在您申请测试权限时提供。详见 /answers/smpp-3-4-vs-5-0.
相比REST API的优势
一旦建立持久绑定，每条消息的成本几乎为零，因此在持续的大业务量下，SMPP消耗的CPU仅为按需请求式HTTPS的十分之一，带宽仅为四分之一。这是实现向SMSC提供低于100ms p99延迟的唯一方法——关键路径上没有HTTP握手——并且可以实时流式传输DLR。请参阅/compare/sms-api-vs-smpp.
限制与注意事项
SMPP是一种必须由您操作的二进制协议：绑定管理、带有指数退避机制的重连、序列号追踪，以及通过message_id进行的DLR匹配（在某些SMSC上返回十六进制，在其他设备上返回十进制）均需由您负责。错误处理非常简练——提交失败会返回一个您必须解码的数字command_status。请使用/tools/smpp-error-codes查询将这些代码转换为具体操作。一个生产级的SMPP客户端拥有数千行代码；建议直接购买而非自行开发。
您应该在何时选择SMPP而不是REST？
当您的每秒发送量达到数百条消息，或需要持久绑定（每个绑定的容量由您的客户团队协商确定），或者需要运行对延迟极度敏感、每一毫秒都至关重要的 OTP，或者需要集成到已广泛支持 SMPP 的运营商/聚合商生态系统中时，请选择 SMPP。否则，使用 REST SMS API（BroadNet 无固定的单账户速率限制）运行更简单，且通过相同的路由进行交付。请参阅 /developers/smpp 和 /products/sms-api。
SMPP使用哪个端口，2026年还会继续使用吗？
SMPP没有单一的预留端口；2775是历史性的明文默认端口，且运营商通常会在专用端口上开放TLS（BroadNet会根据您的账户提供其TLS端口）。是的——SMPP依然完全适用：它是几乎所有A2P互联合同中定义的协议，且BroadNet通过1,000多个运营商连接运行着1,000多个活动绑定，自2003年以来，以99.99%的正常运行时间每天承载超过3亿条消息。