对微信、陌陌等进行了分析,发出来分享一下(时间有些久了)电量:对于移动设备最大的瓶颈就是电量了。因为用户不可能随时携带电源,充电宝。所以必须考虑到电量问题。那就要检查我们工程是不是有后台运行,心跳包发送时间是不是合理。流量:对于好多国内大部分屌丝用户来说可能还是包月30M,那么我们必须站在广大用户角度来考虑问题了。一个包可以解决的就一个包。
网络:这个也是IM最核心的内容了,我们要做到在任何网络下等顺畅聊天那就不容易了,好多公司都用的xmpp框架,如果在强网络环境下,xmpp完全没有问题。但是那种弱网络环境下xmpp就束手无策啦,用户体验就很垃圾了。个人觉得xmpp 可以玩玩(参考看这个RFC3920和RFC3921 ), 但是用来真正的产品就差远了。如果遇到一个做IM 的朋友张口闭口都说xmpp 的话,那么不用沟通了,肯定不是什么好产品。微信、QQ以前也曾用过xmpp,但是最后也放弃了xmpp,就知道xmpp有很多弊端了,还有就是报文太大,好臃肿,浪费流量。为了保证稳定,微信用了长链接和短链接相结合,例如:1 、两个域名微信划分了http模式(short链接)和 tcp 模式(long 链接),分别应对状态协议和数据传输协议long.weixin.qq.com dns check (112.64.237.188 112.64.200.218) short.weixin.qq.com dns check ( 112.64.237.186 112.64.200.240)2 说明2.1 short.weixin.qq.com 是HTTP协议扩展,运行8080 端口,http body为二进制(protobuf)。 主要用途(接口):用户登录验证;好友关系(获取,添加);消息sync (newsync),自有sync机制;获取用户图像;用户注销;行为日志上报。朋友圈发表刷新 2.2 long.weixin.qq.com tcp 长连接, 端口为8080,类似微软activesync的二进制协议。 主要用途(接口):接受/发送文本消息;接受/发送语音;接受/发送图片;接受/发送视频文件等。 所有上面请求都是基于tcp长连接。在发送图片和视频文件等时,分为两个请求;第一个请求是缩略图的方式,第二个请求是全数据的方式。 2.2.1 数据报文方面增量上传策略:每次8k左右大小数据上传,服务器确认;在继续传输。 图片上传:先传缩略图,传文本消息,再传具体文件 下载:先下载缩略图, 在下载原图下载的时候,全部一次推送。3 附录3.1 用户登录验证POST /cgi-bin/micromsg-bin/auth HTTP/1.1Accept: **User-Agent: Mozilla/4.0Content-Type: application/x-www-form-urlencodedHost: short.weixin.qq.comContent-Length: 174 3.3 消息sync (newsync)POST /cgi-bin/micromsg-bin/newsync HTTP/1.1Host: short.weixin.qq.comUser-Agent: Android QQMail HTTP ClientCache-Control: no-cacheConnection: Keep-AliveContent-Type: application/octet-streamaccept: **Content-Length: 206 3.5 用户注销POST /cgi-bin/micromsg-bin/iphoneunreg HTTP/1.1Accept: */*User-Agent: Mozilla/4.0Cotent-Type: application/x-www-form-urlencodedHost: short.weixin.qq.comContent-Length: 271 3.6 行为日志上报POST /cgi-bin/stackreport?version=240000a7&filelength=1258&sum=7eda777ee26a76a5c93b233eed504c7d&reporttype=1&username=jolestar HTTP/1.1Content-Length: 736Content-Type: binary/octet-streamHost: weixin.qq.comConnection: Keep-AliveUser-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)从现在互联网的发展而言,IM和视频(包括IM里面视频通话)是一个方向,这些都应该成为互联网的基础设施,就像浏览器一样。现在IM还没有一个很好的解决方案,XMPP并不能很好地做到业务逻辑独立开来。从IM的本质来看,IM其实就是将一条消息从一个地方传输到另外一个地方,这个和TCP很像,为什么不实现一个高级点的TCP协议了,只是将TCP/IP里面的IP地址换成了一个类似XMPP的唯一ID而已,其他的很多细节都可以照搬TCP协议。有了这个协议之后,将业务逻辑在现有HTTP server的基础上做,例如发送语音和图片就相当于上传一个文件,服务器在处理完这个文件后就发一条特殊的IM消息。客户端收到这个IM消息后,按照IM消息里面url去HTTP server取语音文件和图片文件。将HTTP server和IM server打通之后,可以做很多事情。但将这个两个server合并在一块并不是一个好事,不然腾讯也不会有2005年的战略转型了。从现在的情况来看,应用除了游戏,都没怎么赚钱,现在能够承载赚钱业务的还是以web为主。IM不可以赚钱,但没有却是不行的,就像一个地方要致富,不修路是不行的道理一样。
上面说到了protobuf ,就简单介绍下:
JSON相信大家都知道是什么东西,如果不知道,那可就真的OUT了,GOOGLE一下去。这里就不介绍啥的了。
Protobuffer大家估计就很少听说了,但如果说到是GOOGLE搞的,相信大家都会有兴趣去试一下,毕竟GOOGLE出口,多属精品。
Protobuffer是一个类似JSON的一个传输协议,其实也不能说是协议,只是一个数据传输的东西罢了。
那它跟JSON有什么区别呢?
跨语言,这是它的一个优点。它自带了一个编译器,protoc,只需要用它进行编译,可以编译成JAVA、python、C++代码,暂时只有这三个,其他就暂时不要想了,然后就可以直接使用,不需要再写任何其他代码。连解析的那些都已经自带有的。JSON当然也是跨语言的,但这个跨语言是建立在编写代码的基础上。
陌陌设计:陌陌发展刚开始由于规模小,30-40W的连接数(包括Android后台长连接用户),也使用XMPP;由于XMPP的缺点:流量大(基于XML),不可靠(为传统固定网络设计,没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景),交互复杂(登陆需5-6次,尤其是TLS握手);XMPP丢消息的根本原因:服务端和客户端处于“半关闭”状态,客户端假连接状态,服务端有收不到回执;Server端连接层和逻辑层代码没有解耦分离,常常重启导致不可用;
消息中转:
链接层:
逻辑层:
通讯协议设计:
高效:弱网络快速的收发可靠:不会丢消息易于扩展协议格式:
Redis协议:
负载均衡器(LVS...)的问题– 单点失效
单点性能瓶颈
负载均衡从客户端开始做起· 域名负载的问题
域名系统不可靠– 更新延迟大
WNS(wireless network services)
联系客服