默认
打赏 发表评论 3
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
如何选择即时通讯应用的数据传输格式
阅读(130349) | 评论(3 收藏8 淘帖2
微信扫一扫关注!

编者点评


即时通讯应用(包括IM聊天应用、实时消息推送应用等)开发的前期技术选型时,关于数据传输格式的选择,在即时通讯开发者同行的眼里,是个极富争议话题。

精略分析一下,大概的原因在于:

  • 可选择的协议或封装格式多种多样:
    可选择的余地很大:XMPP、Protobuf、JSON、私有2进制、MQTT、定格化XML、Plain text等等;
  • 同一种格式并不能适用于大多数的场景:
    不同的场景有同的考虑而协议的选择往 跟这是挂钩在一起的,比如:移动端IM或推送技术用XMPP这样的协议时,多数情况下都会被喷;
  • 开发者对所选格式有各自的偏好:
    有的人或团队对某种或某几种格式有不一样的经验和技术积累,也促成了他们对某种或某几种协议的偏好。

其实总结以上原因就可以知道,之所以对于即时通讯应用的数据传输格式有不同的声音,根本原因还在于应具体事情具体分析,该选什么协议由场景决定、由团队的技术积累决定、甚至由项目的周期和成本决定,这里不存在唯一解,只有最适合的数据传输格式,不存在最好的格式一说。

当然,本文内容中对即时通讯传输格式的选择,是原作者的一家之言,可能存在很大争议,但如能为你的即时通讯应用开发的技术选型带来些许启发,我相信这才符合作者的本意。

推荐阅读:Protobuf通信协议详解:代码演示、详细原理介绍等》。论坛里有另一个篇关于即时通讯数据传输格式选择的文章,也可以参考一下:《强列建议将Protobuf作为你的即时通讯应用数据传输格式》。

更多资料


移动端IM开发问题:http://www.52im.net/thread-133-1-1.html
即时通讯综合性资料:http://www.52im.net/forum.php?mod=collection&action=view&ctid=10
即时通讯安全性资料:http://www.52im.net/forum.php?mod=collection&action=view&ctid=6
实时音视频开发资料:http://www.52im.net/forum.php?mod=collection&action=view&ctid=4
即时通讯的架构设计:http://www.52im.net/forum.php?mod=collection&action=view&ctid=7
更多资料精选请查看:http://www.52im.net/forum.php?mod=collection&op=all

数据格式的选择需要考虑的方面


1网络数据大小:占用带宽,传输效率


虽然对单个用户来说,数据量传输很小,但是对于服务器端要承受众多的高并发数据传输(尤其现时高并发、大用户量的IM聊天应用和实时推送服务端等场景),必须要考虑到数据占用带宽,尽量不要有冗余数据,这样才能够少占用带宽,少占用资源,少网络IO,提高传输效率。

2网络数据安全性:敏感数据的网络安全


对于相关业务的部分数据传输都是敏感数据,所以必须考虑对部分传输数据进行加密。这通常出现在银行等数据安全性要求很高的应用行业和场景里,当然传统的即时通讯应用里基于用户隐私考虑,数据加密也是同样是个必须考虑的问题。安全性是应用的基础条件,需求是一样的,只是加密程度、安全性级别要求有不同而已。

3编码复杂度


编码复杂度包括序列化和反序列化复杂度、效率、数据结构的可扩展性和可维护性。

对于平台相关业务的代码实现也需要考虑到数据发送方和数据接收方数据处理的复杂度和数据结构的可扩展性,可维护性,人力成本和实施复杂度也必须考虑在内。通常情况下,即时通讯应用(比如IM聊天应用)在开发的前期,为了方便调试,很多团队会用简单的文本协议、JSON等能直观查看的方式,但后期生产部署后,为了流量等考虑,可能会转用Protobuf等更省流量的协议。但总之,协议的定义不可能永远一成不变,但如果在实现的时候就有这些预见性,相性会大大减轻未来的运营风险。

4协议通用性、大众规范


数据类型必须是跨平台,数据格式是通用的,大家普遍能接受上手的。当然,现在已经迈入移动互联网时代,多端、多平台、异构平台的数据通讯是先决条件,而协议的选择,通用性也最多只是应用层有区别。当然,无论如何,异构平台的一致性,是毫无争议的必备条件。

不同类别的数据传输协议(格式)的比较


1自定义二进制


优点:信息体积小,对应以上”1“              
缺点:编码复杂度高(自己定义消息格式,自己编写序列化和反序列化方法,自己进行容错处理,可扩展性不强,比如添加个字段,就必须改两端的逻辑处理),对应以上”3“;

2提供序列化和反序列化库的开源协议


比如 谷歌的protocol buffersjson,  Thrift
优点:是一种流行的通用数据格式,扩展相当方便,序列化和反序列化相当方便(有相应库),错误处理方便(库支持)。

3文本化协议


比如xml,json
优点:序列化,反序列化容易(库支持),调试方便,可视化强;
缺点:相对于二进制存储占用体积大。

你会选择哪种协议?


我会选择JSON(PS: 文中的“我”指原作者),因为他是“提供序列化和反序列化库的开源协议还是文本化的协议”,原因如下:

  • 自定义二进制格式的复杂性:
    自定义二进制格式进行传输的工作,整个过程在定义消息,write,read的过程过于复杂,还很容易出错,对于很多数据交互的程序,会花费大量的时间在上面;
  • 自定义二进制格式的扩展性:
    不便于扩展,但json可以很好地解决这种问题;
  • json相比较二进制的数据量也不是问题:
    json的占用空间稍大,但是我们可以通过网络数据压缩来解决,况且json本身也是轻量级的,传输效率也很高;
  • 去看《unix编程艺术》吧:
    《第5章--文本化,好协议产生好实践》、《第6章--透明性:来点儿光》会告诉你使用文本化协议的好处。

结语


文字看完了,原文作者选择JSON作为即时通讯应用的数据传输格式(协议),到底该怎么选,相信你也已经找到答案了。(推荐看看另一篇《移动端IM开发需要面对的技术问题》:http://www.52im.net/thread-133-1-1.html

全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择:
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
WebSocket详解(一):初步认识WebSocket技术
socket.io实现消息推送的一点实践及思路
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
>> 更多同类文章 ……

[7] 有关实时音视频开发:
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、V8的前世今生
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM系统中如何保证消息的可靠投递(即QoS机制)
谈谈移动端 IM 开发中登录请求的优化
完全自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Android客户端开发指南
开源移动端IM技术框架MobileIMSDK:Java客户端开发指南
开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南
开源移动端IM技术框架MobileIMSDK:Server端开发指南
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

(原文链接:http://yaocoder.blog.51cto.com/2668309/995210,有所删节和修订)

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

标签:即时通讯
上一篇:访谈WebRTC标准之父:WebRTC的过去、现在和未来下一篇:强列建议将Protobuf作为你的即时通讯应用数据传输格式

本帖已收录至以下技术专辑

推荐方案
评论 3
关于Protobuf,不过既然看到了就稍微补充下:
1. proto文件虽然是二进制的,但想要看的话用python写个脚本3行就可以搞定。而在生产环境中,流量就意味着成本,要调试爽还是成本低看自己;
2. proto压缩优势主要在于对integer的压缩,甚至有符号无符号都采用了不同的编码方式,能够提供极高的压缩比。而字符串对象目前据我所知是没有编码的,不过可以对pb再次进行压缩;

pb的不利之处在于:
1. 对数组类型不能随机访问,必须从头开始解,因此发送大量数组型数据时推荐自己做一下wrapper;
2. 对嵌套数组类型会消耗大量内存,跟它的内存分配机制有关;(这第一点据说新版有fix,但后边没去了解)
3. 典型的cpu换空间,自己判断使用场景。
很棒,非常感谢,很清晰~
妙哉
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部