企业通信硬件选型时，短信网关与彩信网关的并发能力往往被混为一谈，但两者在协议栈、信令开销和媒体处理路径上有着本质差异。短信网关走的是SS7或SMPP协议，单连接可承载的TPS（每秒事务数）通常能到500-800；而彩信网关涉及MMS封装、内容编解码和存储转发，相同硬件条件下的并发峰值往往只有短信的1/3到1/2。这个差距不是靠堆服务器就能轻易抹平的。

并发瓶颈不在带宽，在信令与媒体分离

很多企业以为升级带宽就能提升并发，实际卡点在于信令处理。短信网关的每条消息只有几百字节，信令与内容在一条链路上完成，CPU开销集中在编解码和路由匹配上。彩信网关则不同，它的信令走HTTP或MM7接口，媒体内容需要额外的临时存储和内容类型检测——比如一张1MB的图片要先做格式校验、尺寸压缩，再进入投递队列。这就意味着，彩信网关的并发能力受限于媒体处理线程池的大小和磁盘IOPS，而非单纯的网络吞吐。我们测试过某主流品牌设备，在纯文本彩信（约3KB）场景下并发能到400TPS，但换成带附件的彩信后直接掉到120TPS。

预测拨号器与语音广播设备的并发参考

顺带提一句，预测拨号器和语音广播设备的并发模型又不同——它们依赖的是实时语音通道数，而非消息队列。预测拨号器单机支持的外呼并发通常按“每通道1路语音”计算，比如一台8口设备就是同时8路通话；语音广播设备则看广播分组数，比如同时向50个分机播放相同音频，占用的其实是50个语音通道。这类硬件选型时，别只看厂商标称的“最大用户数”，要问清楚并发通道数和信令处理能力这两个独立指标。

选型时要注意的三个坑

第一，别忽略长连接与短连接的差异。短信网关如果用SMPP长连接，能省去频繁建链的开销，并发能力轻松翻倍；但彩信网关的HTTP短连接在高峰期会大量占用TCP端口和文件描述符，需要预留至少20%的冗余资源。第二，彩信中心（MMSC）的返回码处理逻辑很关键。比如Retry-After字段如果被忽略，重试风暴可能直接打垮网关。第三，测试时一定要用真实业务负载，别用脚本循环发同一条消息——网关的缓存命中率会让测试结果虚高。

至于传真服务器，它的并发能力反而最容易估算：一条传真就是一路T.38或G3协议会话，跟语音通道类似。但传真服务器有个特殊之处——它和短信网关经常共用同一台物理机，此时需要确认两者是否有独立的资源隔离机制，否则传真的大文件传输会挤占短信的信令处理时间片。我们遇到过客户把传真服务器和短信网关部署在同一台低配服务器上，结果短信延迟从200ms飙升到1.2秒。

常见问题：并发数字到底怎么解读

• 问：厂商标称“支持1000并发”是峰值还是持续值？答：绝大多数是峰值，持续值通常要打6-7折。建议要求对方提供72小时压力测试报告，而不是一张截图。
• 问：彩信网关能否复用短信网关的硬件？答：可以，但必须增加独立存储和内容处理模块。如果只换软件不换硬件，并发会严重受限。
• 问：预测拨号器对短信网关有依赖吗？答：没有直接依赖。但很多企业会把预测拨号器产生的未接通记录通过短信网关下发通知，此时要考虑两条链路的峰值叠加。

回到最初的选型问题——如果业务以通知类短信为主，短信网关选型重点看SMPP连接数和路由表容量；如果涉及营销彩信，则要评估媒体处理模块的并发转码能力。对于同时需要传真服务器、语音广播设备和预测拨号器的企业，建议按“信令通道数×消息大小”来估算总负载，再留出30%的余量。润迅云呼在帮客户做硬件集成时，通常会先跑一轮混合负载测试（短信+彩信+传真同时跑），因为真实环境从来不是单一业务。

最后提醒一句：并发能力不是越高越好，而是要与业务峰值匹配。超出需求50%的冗余是保险，超出300%就是浪费——除非你预见到未来三年的增长曲线。选型时带上实际业务日志去测试，比任何厂商白皮书都可靠。