知识卡片
IM应用层协议三种范式的取舍对比,及移动端为何应避开XMPP
内容
IM系统应用层协议大致有三种范式,各自在可读性、扩展性、解析效率和二进制支持之间做出了不同取舍。文本协议(如MSN、HTTP)贴近人类书面语言,可读性好、便于调试,扩展性也好(key:value形式),但一行行读取再按分隔符解析的方式导致解析效率一般,且天然不擅长承载语音、视频这类二进制数据。二进制协议(如IP协议、QQ采用的方案)用定长包头+可扩展变长包体的设计,字段含义完全固定,解析几乎没有代价、效率极高,但可读性差、难以调试,且一旦要扩展字段就必须靠Version字段做版本兼容,旧版本协议天然不兼容新字段。流式XML(以XMPP协议为代表,Gtalk、校内通都基于它)继承了XML的可读性和扩展性优点,还支持通过JID的域标识实现跨域互通,但DOM解析代价极高、大量标签导致有效数据传输率极低。这个对比揭示了协议设计里一个反复出现的三角权衡:可读性/可调试性、扩展性、传输解析效率三者很难同时拿满分,选型时要先想清楚系统更在乎哪一个。基于这个权衡,移动端IM应当特别警惕XMPP——流量本就宝贵的无线场景下,XMPP解析代价高、有效数据传输率低的缺点会被显著放大,如果确实要用,必须自己额外做压缩来弥补这个先天缺陷,否则会直接体现在用户的流量消耗上。
参考来源
- 位置:《高可用架构(第1卷)》第2章《高可用架构原理与分布式实践》"2.4 从零开始搭建高可用IM系统"节,"2.4.2 协议设计"(源文件:_epub-src/OEBPS/Text/Chapter2_4_3.xhtml)
- 结论依据:原文分别列出文本协议、二进制协议、流式XML三者的特点对比,并明确建议"我个人强烈建议不要使用XMPP,特别是无线端IM……如果要用,一定要自己做压缩,减少网络流量",直接支撑本卡片结论。
- 原始内容:文本协议……可读性好、便于调试。扩展性也好……解析效率一般……二进制协议……可读性差、难于调试。扩展性不好……解析效率超高……XMPP协议……解析代价超高(DOM解析)。有效数据传输率超低……我个人强烈建议不要使用XMPP,特别是无线端IM。