天极传媒：天极网全国分站
您现在的位置：
& >>开发者面对移动应用
开发者面对移动应用：选iOS还是Android
天极网开发频道
作者：王健楠
责编：王健楠
　　2011年对移动应用商店来说是大丰收的一年。几乎所有商店都呈现出快速增长，并且在2011年所有商店的规模都至少翻了一倍。
　　据移动程序分析机构Flurry最新的研究，通过分析各国中产阶级的成人人口数量和各国市场的成熟度发现，最后得出2012年移动应用程序最大的潜在目标市场为、、以及印度。
　　游戏类应用是很多商店中最大的一类应用，下载量也是最高的。目前，三大游戏类应用商店是App Store()(79077个游戏)、谷歌 Market(46045个游戏)以及苹果App Store for(28683个游戏)。
　　在最新的调查中发现，排名前25的应用发布商中，只有一家不是游戏公司。而在排名前25的Android发布商中，只有一半为游戏公司。移动应用搜索公司Xylogic的一份研究得出上述结论。
　　2011年Android市场中排行前150的应用中，有85款是应用，其余为游戏。次数达到9150万，有下载次数为3342万。而在iOS下载量排名中，前150名中有100款是游戏。[游戏下载量为7157万次，应用只有2564万次。
　　在Android应用市场中名列前茅的Facebook和Google都没有进入iOS排行榜。
　　2011年11月，iOS应用下载量排行第一的是Words With Friends Free，下载量为302.3万。排名前六的都是游戏，Instagram排第七，Pinterest排第九。
　　相比之下，上月Android市场十强中只有一款游戏入选：Defender by Droid，下载量为141.4万，排第八。排第一的Facebook下载量为533.5万次。
　　由此可见，iOS平台更像是游戏类应用的摇篮，而Android平台更加适合的应用，据调查显示，应用程序开发者从iOS上获得的收入约是Android的三到四倍。尽管Android的市场份额有所提高，但其应用商店的营收仍然远远不及苹果App Store。苹果App Store(iPad)的营收是谷歌Android Market的两倍多，而苹果App Store(iPhone)的营收是谷歌Android Market的近四倍。
（作者：王健楠责任编辑：王健楠）
天极新媒体&最酷科技资讯扫码赢大奖
* 网友发言均非本站立场，本站不在评论栏推荐任何网店、经销商，谨防上当受骗！
办公软件IT新闻整机移动端IM开发需要面对的技术问题 - 知乎专栏
{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"title":"移动端IM开发需要面对的技术问题","author":"nan-ren-2600","content":"1、前言这两年多一直从事网易云信 iOS 端 IM SDK的开发，期间不断有兄弟部门的同事和合作伙伴过来问各种技术细节，干脆统一介绍下一个IM APP的方方面面，包括技术选型（包括通讯方式，网络连接方式，协议选择）和常见问题。（原文链接：）分享者：项望烽，毕业于浙江大学，目前是网易云信 iOS 端研发负责人。2、学习交流- 即时通讯开发交流群： [推荐]- 移动端IM开发推荐文章：《》3、P2P还是服务器中转？IM通讯方式无非两种选择：设备直连(P2P)和通过服务器中转。3.1 P2P方式P2P多见于局域网内聊天工具，典型的应用有:飞鸽传书、天网Maze(你懂的)等。这类软件在启动后一般做两件事情：[1] 进行UDP广播:发送自己信息和接受同局域网内其他端信息；[2] 开启TCP监听:等待其他端进行连接。详细的流程可以参考飞鸽传书源码。但是这种方式在有种种限制和不便:一方面它只适合在线的点对点消息传输，对离线，群组等业务支持不够。另一方面由于 NAT 的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。3.2 服务器中转方式几乎所有互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，它有如下的优点:[1] 能够支持更多P2P无法支持或支持不好的业务，如离线消息，群组，聊天室服务；[2] 方便业务逻辑的拓展和新旧版本的兼容。[3] 当然它也有自己的问题:服务器架构复杂，并发要求高。4、该选择什么样的网络通讯技术？IM主流网络通讯技术有两种:[1] 基于TCP的长连接；[2] 基于HTTP短连接PULL的方式。后者常见于WEB IM系统(当然现在很多WEB IM都是基于WebSocket实现)，它的优点是实现简单，方便开发上手，问题是流量大，服务器负载较大，消息及时性无法很好地保证，对大规模的用户量支持不够，比较适合小型的IM系统,如小网站的客户系统。基于TCP长连接则能够更好地支持大批量用户，问题是客户端和服务器的实现比较复杂。当然也还有一些变种，如下行使用MQTT进行服务器通知/消息的下发，上行使用HTTP短连接进行指令和消息的上传。这种方式能够保证下行消息/指令的及时性，但是在弱网络下上行慢的问题还是比较严重。早期的来往就是基于这种方式。5、协议如何制定？IM协议选择原则一般是：易于拓展，方便覆盖各种业务逻辑，同时又比较节约流量。后一点的需求在移动端IM上尤其重要。常见的协议有：XMPP、SIP、MQTT、私有协议。（更多关于即时通讯应用的协议选择，请参见《如何选择即时通讯应用的数据传输格式》：）5.1 XMPP优点：协议开源，可拓展性强，在各个端(包括服务器)有各种语言的实现，开发者接入方便；缺点：缺点也是不少，XML表现力弱、有太多冗余信息、流量大，实际使用时有大量天坑。5.2 SIPSIP协议多用于VOIP相关的模块，是一种文本协议，由于我并没有实际用过，所以不做评论，但从它是文本协议这一点几乎可以断定它的流量不会小。5.3 MQTT优点：协议简单，流量少；缺点：它并不是一个专门为IM设计的协议，多使用于推送。5.4 私有协议市面上几乎所有主流IM APP都是是使用私有协议，一个被良好设计的私有协议优点非常明显。优点：高效，节约流量(一般使用二进制协议)，安全性高，难以破解；缺点：在开发初期没有现有样列可以参考，对于设计者的要求比较高。5.5 结论一个好的协议需要满足如下条件:高效，简洁，可读性好，节约流量，易于拓展，同时又能够匹配当前团队的技术堆栈。基于如上原则，我们可以得出:如果团队小，团队技术在IM上积累不够可以考虑使用XMPP或者MQTT+HTTP短连接的实现。反之可以考虑自己设计和实现私有协议。6、该如何设计私有通信协议？6.1 序列化与反序列化移动互联网相对于有线网络最大特点是:带宽低，延迟高，丢包率高和稳定性差，流量费用高。所以在私有协议的序列化上一般使用二进制协议，而不是文本协议。常见的二进制序列化库有protobuf和MessagePack，当然你也可以自己实现自己的二进制协议序列化和反序列的过程，比如蘑菇街的TeamTalk。但是前面二者无论是可拓展性还是可读性都完爆TeamTalk(TeamTalk连Variant都不支持，一个int传输时固定占用4个字节)，所以大部分情况下还是不推荐自己去实现二进制协议的序列化和反序列化过程。6.2 协议格式设计基于TCP的应用层协议一般都分为包头和包体(如HTTP)，IM协议也不例外。包头一般用于表示每个请求/反馈的公共部分，如包长，请求类型，返回码等。 而包头则填充不同请求/反馈对应的信息。一个最简单的包头可以定义为：struct PackHeader\n\n{\n\n
length_;//包长度\n\n
serial_;//包序列号\n\n
command_;//包请求类型\n\n
code_;//返回码\n\n};\n以心跳包为例，假设当前的serial为1，心跳包的command为10，那么使用MessagePack做序列化时:length=4，serial=1，command=10，code=0，每个字段各占一个字节，包体为空，仅需要4个字节。当然这是最简单的一个例子，面对真正的业务逻辑时，包体里面会需要塞入更多地信息，这个需要开发根据自己的业务逻辑总结公共部分,如为了兼容加入的协议版本号,为了负载均衡加入的模块id等。7、其他不可忽视的问题上面的内容就是一个IM系统大致的选型过程：服务方式，网络通讯协议，数据通信协议选择、协议设计。但是实际开发过程中还有大量的问题需要处理。7.1 协议加密为了保证协议不容易被破解，市面上几乎所有主流IM都会对协议进行加密传输。常见的流程和HTTPS加密相似:建立连接后，客户端和服务器进行进行协商，最终客户端获得一个当前Sessino的秘钥，后续的数据传输都通过这个秘钥进行加解密。一般出于效率的考虑都会采用流式加密，如RC4。而前期协商过程则推荐使用RSA等非对称加密以增加破解难度。7.2 快速连接（即掉线重连机制）对iOS APP而言，因为没有真后台的存在，APP每次启动基本都需要一次重连登录(短时间内切换除外)，所以如何快速重连、重登就非常重要。常见优化思路如下:[1] 本地缓存服务器IP并定期刷新。移动网络调优可以参考《》；[2] 合并部分请求。如加密和登录操作可以合并为同一个操作，这样就可以减少一次不必要的网络请求来回的时间；[3] 简化登录后的同步请求，部分同步请求可以推迟到UI操作时进行，如群成员信息刷新。7.3 连接保持（即心跳机制）一般APP实现连接保持的方式无非是采用应用层的心跳，通过心跳包的超时和其他条件(网络切换)来执行重连操作。那么问题来了:为什么要使用应用层心跳和如何设计应用层心跳。众所周知TCP协议是有KEEPALIVE这个设置选项，设置为KEEPALIVE后，客户端每隔N秒(默认是7200s)会向服务器发送一个发送心跳包。但实际操作中我们更多的是使用应用层心跳。原因如下:[1] KEEPALIVE对服务器负载压力比较大(服务器大大是这么说的...)；[2] socks代理对KEEPALIVE并不支持；[3] 部分复杂情况下KEEPALIVE会失效，如路由器挂掉，网线(移动端没有网线...)直接被拔除。[4] 移动端在实际操作时为了节约流量和电量一般会在心跳包上做一些小优化：[5] 精简心跳包，保证一个心跳包大小在10字节之内；[6] 心跳包只在空闲时发送；[7] 根据APP前后台状态调整心跳包间隔 (主要是安卓)。7.4 消息可达（即QoS机制）在移动网络下，丢包，网络重连等情况非常之多，为了保证消息的可达，一般需要做消息回执和重发机制。参考易信，每条消息会最多会有3次重发，超时时间为15秒，同时在发送之前会检测当前连接状态，如果当前连接并没有正确建立，缓存消息且定时检查(每隔2秒检查一次，检查15次)。所以一条消息在最差的情况下会有2分钟左右的重试时间，以保证消息的可达。因为重发的存在，接受端偶尔会收到重复消息，这种情况下就需要接收端进行去重。通用的做法是每条消息都戴上自己唯一的message id(一般是uuid)。7.5 文件上传优化IM消息(包括SNS模块)内包含大量的文件上传的需求，如何优化文件的上传就成了一个比较大的主题。常见有下面这些优化思路:[1] 将上传流程提前:音频提供边录边传。朋友圈的图片进行预上传，选择图片后用户一般会进行文本输入，在这段时间内后台就可以默默将选好的图片进行上传；[2] 提供闪电上传的方式:服务器根据MD5进行文件去重；[3] 优化和上传服务器的连接(参考快速连接)，提供连接重用的功能；[4] 文件分块上传:因为移动网络丢包严重，将文件分块上传可以使得一个分组包含合理数量的TCP包，使得重试概率下降，重试代价变小，更容易上传到服务器；[5] 在分包的前提下支持上传的pipeline，避免不必要的网络等待时间；[6] 支持断点续传。（原文链接：）更多IM技术文章[1] 网络编程基础资料：《-》《-》《-》《-》《》《》《》《》《》《》《》《》&&[2] 有关IM/推送的通信格式、协议的选择：《》《》《》《》《》《》《》《》&&[3] 有关IM/推送的心跳保活处理：《》《》《》《》《》《》《》&&[4] 有关WEB端即时通讯开发：《》《》《》《》《》《》&&[5] 有关IM架构设计：《》《》《》《》《》《》《》《》《》《》&&[6] 有关IM安全的文章：《》《》《》《》《》《》《》《》&&[7] 有关实时音视频开发：《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》&&[8] IM开发综合文章：《》《》《》《》《》《》《》《》《》&&[9] 开源移动端IM技术框架资料：《》《》《》&&[10] 有关推送技术的文章：《》《》《》《》《》《》《》《》《》《》&&[11] 更多即时通讯技术好文分类：作者：(点击作者姓名进入Github)出处：交流：欢迎加入即时通讯开发交流群讨论：Jack Jiang同时是和的作者，可前往下载交流。","updated":"T10:14:34.000Z","canComment":false,"commentPermission":"anyone","commentCount":1,"collapsedCount":0,"likeCount":3,"state":"published","isLiked":false,"slug":"","lastestTipjarors":[],"isTitleImageFullScreen":false,"rating":"none","titleImage":"","links":{"comments":"/api/posts//comments"},"reviewers":[],"topics":[{"url":"/topic/","id":"","name":"即时通讯 (IM)"}],"adminClosedComment":false,"titleImageSize":{"width":0,"height":0},"href":"/api/posts/","excerptTitle":"","column":{"slug":"helloim","name":"即时通讯(IM)技术开发"},"tipjarState":"activated","tipjarTagLine":"真诚赞赏，手留余香","sourceUrl":"","pageCommentsCount":1,"tipjarorCount":0,"annotationAction":[],"hasPublishingDraft":false,"snapshotUrl":"","publishedTime":"T18:14:34+08:00","url":"/p/","lastestLikers":[{"bio":"喜欢捣鼓科技的Programmer","isFollowing":false,"hash":"c0aac998b1","uid":80,"isOrg":false,"slug":"laizuling","isFollowed":false,"description":"","name":"赖祖灵","profileUrl":"/people/laizuling","avatar":{"id":"v2-487b54e44a724cd0aafcb","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":null,"isFollowing":false,"hash":"dd407c01d6bdf1f2a344d1fe66d44b98","uid":225000,"isOrg":false,"slug":"yao-yao-85-52","isFollowed":false,"description":"","name":"姚尧","profileUrl":"/people/yao-yao-85-52","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"青年阳光IT民工","isFollowing":false,"hash":"acedfbc58fb4","uid":80,"isOrg":false,"slug":"kongwu-","isFollowed":false,"description":"一只还会修电脑的程序汪","name":"蒋信","profileUrl":"/people/kongwu-","avatar":{"id":"31e7e1033e3ccb27376fcdd","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false}],"summary":"1、前言 这两年多一直从事网易云信 iOS 端 IM SDK的开发，期间不断有兄弟部门的同事和合作伙伴过来问各种技术细节，干脆统一介绍下一个IM APP的方方面面，包括技术选型（包括通讯方式，网络连接方式，协议选择）和常见问题。（原文链接：…","reviewingCommentsCount":0,"meta":{"previous":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/c26fbf8e9b61eb99aeea70a0f0aa176d_r.jpg","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"即时通讯 (IM)"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"http://www.52im.net","isFollowing":false,"hash":"40a86ae1cf34e7cdb14d9","uid":937500,"isOrg":false,"slug":"nan-ren-2600","isFollowed":false,"description":"","name":"男人","profileUrl":"/people/nan-ren-2600","avatar":{"id":"fe4de9c0c18fb389c1b1385","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"helloim","name":"即时通讯(IM)技术开发"},"content":"前言即时通讯应用（包括IM聊天应用、实时消息推送应用等）开发的前期技术选型时，关于数据传输格式的选择，在即时通讯开发者同行的眼里，是个极富争议话题。精略分析一下，大概的原因在于：[1] 可选择的协议或封装格式多种多样：可选择的余地很大：XMPP、Protobuf、JSON、私有2进制、MQTT、定格化XML、Plain text等等；[2] 同一种格式并不能适用于大多数的场景：不同的场景有同的考虑而协议的选择往 跟这是挂钩在一起的，比如：移动端IM或推送技术用XMPP这样的协议时，多数情况下都会被喷；[3] 开发者对所选格式有各自的偏好：有的人或团队对某种或某几种格式有不一样的经验和技术积累，也促成了他们对某种或某几种协议的偏好。其实总结以上原因就可以知道，之所以对于即时通讯应用的数据传输格式有不同的声音，根本原因还在于应具体事情具体分析，该选什么协议由场景决定、由团队的技术积累决定、甚至由项目的周期和成本决定，这里不存在唯一解，只有最适合的数据传输格式，不存在最好的格式一说。当然，本文内容中对即时通讯传输格式的选择，是原作者的一家之言，可能存在很大争议，但如能为你的即时通讯应用开发的技术选型带来些许启发，我相信这才符合作者的本意。（本文同步发布于：）学习交流- 即时通讯开发交流群： [推荐]更多资料移动端IM开发，推荐阅读：《》。数据格式的选型需要考虑的方面[1] 网络数据大小：占用带宽，传输效率虽然对单个用户来说，数据量传输很小，但是对于服务器端要承受众多的高并发数据传输（尤其现时高并发、大用户量的IM聊天应用和实时推送服务端等场景），必须要考虑到数据占用带宽，尽量不要有冗余数据，这样才能够少占用带宽，少占用资源，少网络IO，提高传输效率。[2] 网络数据安全性：敏感数据的网络安全对于相关业务的部分数据传输都是敏感数据，所以必须考虑对部分传输数据进行加密。这通常出现在银行等数据安全性要求很高的应用行业和场景里，当然传统的即时通讯应用里基于用户隐私考虑，数据加密也是同样是个必须考虑的问题。安全性是应用的基础条件，需求是一样的，只是加密程度、安全性级别要求有不同而已。[3] 编码复杂度编码复杂度包括序列化和反序列化复杂度、效率、数据结构的可扩展性和可维护性。对于平台相关业务的代码实现也需要考虑到数据发送方和数据接收方数据处理的复杂度和数据结构的可扩展性，可维护性，人力成本和实施复杂度也必须考虑在内。通常情况下，即时通讯应用（比如IM聊天应用）在开发的前期，为了方便调试，很多团队会用简单的文本协议、JSON等能直观查看的方式，但后期生产部署后，为了流量等考虑，可能会转用Protobuf等更省流量的协议。但总之，协议的定义不可能永远一成不变，但如果在实现的时候就有这些预见性，相性会大大减轻未来的运营风险。[4] 协议通用性、大众规范数据类型必须是跨平台，数据格式是通用的，大家普遍能接受上手的。当然，现在已经迈入移动互联网时代，多端、多平台、异构平台的数据通讯是先决条件，而协议的选择，通用性也最多只是应用层有区别。当然，无论如何，异构平台的一致性，是毫无争议的必备条件。不同类别的数据传输协议（格式）的比较[1] 自定义二进制优点：信息体积小，对应以上”1“缺点：编码复杂度高（自己定义消息格式，自己编写序列化和反序列化方法，自己进行容错处理，可扩展性不强，比如添加个字段，就必须改两端的逻辑处理），对应以上”3“；[2] 提供序列化和反序列化库的开源协议比如，，优点：是一种流行的通用数据格式，扩展相当方便，序列化和反序列化相当方便（有相应库），错误处理方便（库支持）。[3] 文本化协议比如xml，json优点：序列化，反序列化容易（库支持），调试方便，可视化强；缺点：相对于二进制存储占用体积大。你会选择哪种格式？我会选择JSON（PS: 文中的“我”指原作者），因为他是“提供序列化和反序列化库的开源协议还是文本化的协议”，原因如下：[1] 自定义二进制格式的复杂性：自定义二进制格式进行传输的工作，整个过程在定义消息，write，read的过程过于复杂，还很容易出错，对于很多数据交互的程序，会花费大量的时间在上面；[2] 自定义二进制格式的扩展性：不便于扩展，但json可以很好地解决这种问题；[3] json相比较二进制的数据量也不是问题：json的占用空间稍大，但是我们可以通过网络数据压缩来解决，况且json本身也是轻量级的，传输效率也很高；[4] 去看《unix编程艺术》吧：《第5章--文本化，好协议产生好实践》、《第6章--透明性：来点儿光》会告诉你使用文本化协议的好处。结语文字看完了，原文作者选择JSON作为即时通讯应用的数据传输格式（协议），到底该怎么选，相信你也已经找到答案了。（推荐看看另一篇《》）相关技术资料分类[1] 网络编程基础资料：《-》《-》《-》《-》《》《》《》《》《》《》《》《》&&[2] 有关IM/推送的通信格式、协议的选择：《》《》《》《》《》《》《》《》&&[3] 有关IM/推送的心跳保活处理：《》《》《》《》《》《》《》&&[4] 有关WEB端即时通讯开发：《》《》《》《》《》《》&&[5] 有关IM架构设计：《》《》《》《》《》《》《》《》《》《》&&[6] 有关IM安全的文章：《》《》《》《》《》《》《》《》&&[7] 有关实时音视频开发：《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》《》&&[8] IM开发综合文章：《》《》《》《》《》《》《》《》《》&&[9] 开源移动端IM技术框架资料：《》《》《》&&[10] 有关推送技术的文章：《》《》《》《》《》《》《》《》《》《》&&[11] 更多即时通讯技术好文分类：（本文同步发布于：）作者：(点击作者姓名进入Github)出处：交流：欢迎加入即时通讯开发交流群讨论：Jack Jiang同时是和的作者，可前往下载交流。","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T16:26:23+08:00","url":"/p/","title":"如何选择即时通讯应用的数据传输格式","summary":"前言 即时通讯应用（包括IM聊天应用、实时消息推送应用等）开发的前期技术选型时，关于数据传输格式的选择，在即时通讯开发者同行的眼里，是个极富争议话题。精略分析一下，大概的原因在于：[1] 可选择的协议或封装格式多种多样：可选择的余地很大：XMPP、P…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0},"next":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/fabea6d0e79f24c6b7e9_r.png","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"即时通讯 (IM)"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"http://www.52im.net","isFollowing":false,"hash":"40a86ae1cf34e7cdb14d9","uid":937500,"isOrg":false,"slug":"nan-ren-2600","isFollowed":false,"description":"","name":"男人","profileUrl":"/people/nan-ren-2600","avatar":{"id":"fe4de9c0c18fb389c1b1385","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"helloim","name":"即时通讯(IM)技术开发"},"content":"1、前言对于有过网络编程经验的开发者来说，使用何种数据传输层协议来实现数据的通信，是个非常基础的问题，它涉及到你的第一行代码该如何编写。从PC时代的IM开始，IM开发者就在为数据传输协议的选型争论不休（比如：《》这样的问题，隔一段时间就能在社区里看到）。到了移动互联网时代，鉴于移动网络的不可靠性等特点，再加上手机的省电策略、流量压缩等，为这个问题的回答增了更多的不确定因素。对于有选择困难证的人来说，基于以上因素，加上UDP和TCP协议的本质差异，这样的选择确实很纠结。本文将从作者的实践总结，给出自已的观点，如有异议还请理性回复，不为找喷，仅供参考。说明：本文引用了DDPush的技术资料，感谢原作者。 （本文同步发布于：）2、学习交流- 即时通讯开发交流群： [推荐]- 移动端IM开发推荐文章：《》3、参考资料《》《》《》《》《》《》《》4、UDP vs TCPTCP还是UDP？长连接如何实现？如何实现心跳机制？心跳的间隔如何确定？这些问题都是讨论移动端IM、消息推送等类似话题时，几乎一定被问到的问题。这里尝试正本清源一下。5、互联网、移动互联网网络环境在分析到底应该使用UDP还是TCP之前，有必要先讨论一下互联网与移动互联网的网络环境特点。互联网的网络基础建设，经过十几年长期的发展，已经较为稳定和成熟，PC终端、操作系统的能力也达到了较高的水平。而移动互联网，由于涉及到无线电话网络基站、2G、3G和4G技术的不断发展，其稳定性、带宽、资源分配等各方面虽日趋完善，但当前终究还有不少问题的存在。另外，由于移动互联网其“移动”的本质，加上智能终端设备（智能手机、平板电脑）的发展较晚，目前还在不断演变的情况，与互联网相比，移动互联网还是低速、不稳定、终端能力稍弱的情况。而且由于其“移动”本质，短时间内很难达到互联网的质量。所以，在互联网的环境里面，网络应用程序由于网络设施、操作系统的成熟，开发使用起来比较容易，资源也较为充足。而移动互联网还是要“斤斤计较”。6、智能终端电池续航能力，系统休眠智能终端设备的电池续航能力始终是技术瓶颈。在连续使用的情况下，绝大部分智能设备电池无法支持两个小时以上。所以在没有外部电源的情况，智能终端设备必须频繁、长时间休眠，这将极大地影响两种网络环境下的网络应用场景。7、IPv4资源、端口资源这个话题往往被很多人忽略，但它有着至关重要的影响。虽然大部分人都很清楚IP地址的紧缺导致的动态IP分配的必然，却忽略了由于IP地址不足引起的端口资源不足。由于需要动态分配IP地址（这里不仅仅指互联网入口的IP，还包括局域网内部的IP），路由器的工作原理都是经过端口映射，把内部网络（包括PC、手机、平板、Wifi、2G、3G、4G）IP与端口映射成外部IP（通常是公网IP）和对应的端口，并维持这个映射关系，才能正常地修改、转发报文信息，保证内部各个ip、端口与外部的各个ip、端口的通信。然而，单个IP地址的端口资源是有限的，理论上限是65535个端口。对于普通宽带路由器来说，这个已经很充足了。但是！对于大型的网络服务、网络主干接入点等来说，如果IP资源不足，每个IP几万个端口的资源很快会耗尽，从而影响正常通讯。（有关NAT技术原理，请参见《》）8、端口映射老化时间正因为如此，所有的路由器都会为每个端口映射关系设置老化时间，如果老化时间倒数到0，则端口映射关系失效，该端口被释放给其他连接使用。如果端口全部耗尽，则无法再新建内部与外部的网络连接。端口映射老化时间，比很多人想象中的要短很多。一般的家用宽带路由器，老化时间一般是两三分钟；在有线宽带运营商接入部分，老化时间可能少于两分钟。在无线电话网络运营商接入部分（例如GPRS连接），老化时间甚至不超过一分钟！也就是说，任何一个网络通讯（不管是TCP或UDP），如果几分钟之内没有网络报文传输，其占用的IP地址端口将被路由器回收。这个时候该次通信必将终止，不管TCP还是UDP，神马都是浮云。更残酷的事实是，互联网可认为是由无数个路由器连接而成的，一个网络通信往往需要通过n个路由器，每个路由器都会为一次通信建立自己的端口映射。只要其中一个路由器回收其端口，则整个通讯中断。这也是很多人疑惑为什么TCP的KeepAlive参数无法保证长连接的原因。TCP的KeepAlive默认是两个小时（而且该参数还是TCP的可选实现，不是必然实现），在路由器端口映射老化时间的影响下，必然无法发挥其作用。实际上，该参数在单一的局域网内才可能被使用上，还要依赖具体的操作系统。由于路由器端口映射的存在，加上智能终端频繁、长时间的休眠，TCP长连接的实用性在移动互联网情况下极大地打了折扣。也因为如此，移动端IM、推送系统必须实现所谓的心跳包机制，以保持端口映射关系的老化时间不会减少到0而被回收，从而避免连接中断。（有关TCP协议下的心跳问题，请参见：《》）9、服务端承载能力不管是UDP还是TCP，最终都是应用服务端的设备去提供服务的。而TCP由于提供了安全可靠的流服务，其对计算机、网络资源的消耗是远远大于UDP协议的。对于配置较好的主流服务器，配备大量的内存（数十G至上百G内存），与高速的磁盘、网卡，是能同时支持数百万个TCP连接的。不过这里需要较专业的服务器设置，需要调整不少系统参数，再加上服务程序的配合。另外，TCP连接的建立、维持与释放，都是需要较昂贵的计算、网络资源的。终端在线服务，若是一个较为简单的服务，未必使用上TCP众多的高级功能，但承受TCP的昂贵成本，未必值得。如果能用UDP来提供服务，单服务器的承载能力，是可以去到TCP服务的数十倍，甚至上百倍的增长。这也是为什么DNS这种并发数巨大的服务器提供UDP接口的原因。另外，上百万TCP连接的网络服务，其编程的难度、程序复杂度、调试难度、服务器运维成本、网络成本等都远远高于UDP。而UDP编程，与上百万个终端通讯的难度与成本则低很多。如果提供的网络服务不是基于流的服务，也允许一定的失败机率（例如P2P），则UDP往往是更适合的方式。10、高级应用网络通讯要求不过，移动端IM系统、推送系统一方面提供终端在线服务，另外一方面也需要考虑内容信息的完整性和安全性。毕竟信息的丢失，或者通讯的被窃听，都是难以接受的。而TCP不管在网络层的可靠性控制，还是在应用层的安全支持（例如HTTPS），都为应用提供无法替代的强大功能和便利。11、结论综合以上所述，其实答案也呼之欲出。现在的移动端IM、推送系统，既面对移动互联网的不确定性，又面对智能终端频繁的系统休眠、网络切换，还要考虑服务端的承载成本，对于在线服务而言UDP是比TCP更适合的方式。但是由于数据完整性、安全性的需要，又不应完全放弃TCP的可靠与安全。所以，个人认为，更恰当的方式应该是：两种通信协议同时使用，各有侧重。UDP用于保持大量终端的在线与控制，应用与业务则通过TCP去实现。这个和FTP服务控制与数据分离，采取不同的连接，有异曲同工之处。事实上，这个也是即时通讯巨头QQ所采用的方式。早期的时候，QQ还是主要使用TCP协议，而后来就转向了采用UDP的方式来保持在线，TCP的方式来上传和下载数据。现在，UDP是QQ的默认工作方式，表现良好。相信这个也被沿用到了微信上。简单的考证：登录PC版QQ，关闭多余的QQ窗口只留下主窗口，并将其最小化。几分钟过后，查看系统网络连接，会发现QQ进程已不保有任何TCP连接，但有UDP网络活动。这时在发送聊天信息，或者打开其他窗口和功能，将发现QQ进程会启用TCP连接。（本文同步发布于：）作者：(点击作者姓名进入Github)出处：交流：欢迎加入即时通讯开发交流群讨论：Jack Jiang同时是和的作者，可前往下载交流。","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T17:28:51+08:00","url":"/p/","title":"移动端IM系统的协议选型：UDP还是TCP？","summary":"1、前言 对于有过网络编程经验的开发者来说，使用何种数据传输层协议来实现数据的通信，是个非常基础的问题，它涉及到你的第一行代码该如何编写。从PC时代的IM开始，IM开发者就在为数据传输协议的选型争论不休（比如：《…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":1,"likesCount":2}},"annotationDetail":null,"commentsCount":1,"likesCount":3,"FULLINFO":true}},"User":{"nan-ren-2600":{"isFollowed":false,"name":"男人","headline":"","avatarUrl":"/fe4de9c0c18fb389c1b1385_s.jpg","isFollowing":false,"type":"people","slug":"nan-ren-2600","bio":"http://www.52im.net","hash":"40a86ae1cf34e7cdb14d9","uid":937500,"isOrg":false,"description":"","profileUrl":"/people/nan-ren-2600","avatar":{"id":"fe4de9c0c18fb389c1b1385","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false,"badge":{"identity":null,"bestAnswerer":null}}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"helloim":{"following":false,"canManage":false,"href":"/api/columns/helloim","name":"即时通讯(IM)技术开发","creator":{"slug":"nan-ren-2600"},"url":"/helloim","slug":"helloim","avatar":{"id":"889dd38b3beea5e0359ea2","template":"/{id}_{size}.jpeg"}}},"columnPosts":{},"columnSettings":{"colomnAuthor":[],"uploadAvatarDetails":"","contributeRequests":[],"contributeRequestsTotalCount":0,"inviteAuthor":""},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[],"next":{}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{}}}