详细回答
只提供有价值的信息，杜绝冗余。
§01
为什么3.4能赢得装机量
SMPP 3.4的发布正值SMS A2P兴起的时刻。每一家主要的SMSC供应商都构建了深度且稳定的3.4实现方案。该协议非常精简（大约只有30种PDU类型，且你发送的所有指令仅包含八条命令），易于理解，并能穿透路径上的所有NAT和防火墙。二十七年后，SMPP 3.4规范依然是每一份A2P互联合同中核心的协议标准。
§02
5.0版本新增功能
SMPP 5.0优化了多个细节：原生支持UTF-8 message_payload、完善的service_type注册机制、用于小区广播的broadcast_sm / query_broadcast_sm / cancel_broadcast_sm、可选的计费TLV，以及通过congestion_state实现的更严密的拥塞控制。此外，它还引入了message_state机器的概念，允许SMSC代表ESME进行驱动。
§03
为什么几乎没有人运行5.0
三个原因。首先，SMSC供应商并没有获得升级资金——运营商已经拥有可用的3.4协议栈。其次，5.0版本针对的小区广播用例是面向专用小区广播中心（CBC）的，而非SMSC。第三，5.0修复的问题（Unicode处理、计费TLV）通常在应用层通过基于3.4协议之上的TLV即可解决。结果是：在BroadNet，我们只有一个5.0绑定。而我们拥有超过1,000个活跃的3.4绑定。
§04
实用建议
作为收发器绑定在SMPP 3.4上，并在账户提供的端口上使用TLS。当接收端SMSC支持时，对于长短信，请使用带有message_payload TLV的submit_sm（而非UDH分段）。每30秒协商一次enquire_link，并干净地解绑。如果您的聚合商强制使用5.0，请询问原因——在商业A2P通道上，这并不会带来送达率方面的收益。
SMPP 3.4与SMPP 5.0概览
| SMPP 3.4 | SMPP 5.0 | |
|---|---|---|
| 已发布 | 1999 | 2003 |
| 生产环境部署基数 | 几乎每个A2P绑定 | 罕见——极少部署 |
| 原生Unicode标头 | — | |
| 支持小区/广播 | — | |
| 拥塞控制 | 基础 | congestion_state信令 |
| 提升送达率 | 基准 | 商业A2P通道均无此问题 |
| 今日推荐 | 是的 — 通过TLS进行收发 | 仅在交易对手有要求时 |