im即时通讯开发：如何选择数据传输格式
作者：互联网
即时通讯应用（包括IM聊天应用、实时消息推送应用等）开发的前期技术选型时，关于数据传输格式的选择，在即时通讯开发者同行的眼里，是个极富争议话题。
精略分析一下，大概的原因在于：
可选择的协议或封装格式多种多样：
可选择的余地很大：XMPP、Protobuf、JSON、私有2进制、MQTT、定格化XML、Plain text等等；
同一种格式并不能适用于大多数的场景：
不同的场景有同的考虑而协议的选择往 跟这是挂钩在一起的，比如：移动端IM或推送技术用XMPP这样的协议时，多数情况下都会被喷；
开发者对所选格式有各自的偏好：
有的人或团队对某种或某几种格式有不一样的经验和技术积累，也促成了他们对某种或某几种协议的偏好。
数据格式的选择需要考虑的方面
1网络数据大小：占用带宽，传输效率
虽然对单个用户来说，数据量传输很小，但是对于服务器端要承受众多的高并发数据传输（尤其现时高并发、大用户量的IM聊天应用和实时推送服务端等场景），必须要考虑到数据占用带宽，尽量不要有冗余数据，这样才能够少占用带宽，少占用资源，少网络IO，提高传输效率。
2网络数据安全性：敏感数据的网络安全
对于相关业务的部分数据传输都是敏感数据，所以必须考虑对部分传输数据进行加密。这通常出现在银行等数据安全性要求很高的应用行业和场景里，当然传统的即时通讯应用里基于用户隐私考虑，数据加密也是同样是个必须考虑的问题。安全性是应用的基础条件，需求是一样的，只是加密程度、安全性级别要求有不同而已。即时通讯开发
3编码复杂度
编码复杂度包括序列化和反序列化复杂度、效率、数据结构的可扩展性和可维护性。
对于平台相关业务的代码实现也需要考虑到数据发送方和数据接收方数据处理的复杂度和数据结构的可扩展性，可维护性，人力成本和实施复杂度也必须考虑在内。通常情况下，即时通讯应用（比如IM聊天应用）在开发的前期，为了方便调试，很多团队会用简单的文本协议、JSON等能直观查看的方式，但后期生产部署后，为了流量等考虑，可能会转用Protobuf等更省流量的协议。但总之，协议的定义不可能永远一成不变，但如果在实现的时候就有这些预见性，相性会大大减轻未来的运营风险。
4协议通用性、大众规范
数据类型必须是跨平台，数据格式是通用的，大家普遍能接受上手的。当然，现在已经迈入移动互联网时代，多端、多平台、异构平台的数据通讯是先决条件，而协议的选择，通用性也最多只是应用层有区别。当然，无论如何，异构平台的一致性，是毫无争议的必备条件。
不同类别的数据传输协议（格式）的比较
1自定义二进制
优点：信息体积小，对应以上”1“
缺点：编码复杂度高（自己定义消息格式，自己编写序列化和反序列化方法，自己进行容错处理，可扩展性不强，比如添加个字段，就必须改两端的逻辑处理），对应以上”3“；
2提供序列化和反序列化库的开源协议
比如谷歌的protocol buffers，json，Thrift
优点：是一种流行的通用数据格式，扩展相当方便，序列化和反序列化相当方便（有相应库），错误处理方便（库支持）。
3文本化协议
比如xml，json
优点：序列化，反序列化容易（库支持），调试方便，可视化强；
缺点：相对于二进制存储占用体积大。
你会选择哪种协议？
我会选择JSON（PS: 文中的“我”指原作者），因为他是“提供序列化和反序列化库的开源协议还是文本化的协议”，原因如下：
自定义二进制格式的复杂性：
自定义二进制格式进行传输的工作，整个过程在定义消息，write，read的过程过于复杂，还很容易出错，对于很多数据交互的程序，会花费大量的时间在上面；
自定义二进制格式的扩展性：
不便于扩展，但json可以很好地解决这种问题；
json相比较二进制的数据量也不是问题：
json的占用空间稍大，但是我们可以通过网络数据压缩来解决，况且json本身也是轻量级的，传输效率也很高；
标签：协议,复杂度,即时通讯,json,im,格式,数据传输,序列化 来源： https://www.cnblogs.com/keyunshiwo/p/16336679.html