Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 504, comments - 13, trackbacks - 0, articles - 1

     摘要: 1、引言网络优化对于移动端App产品的用户体验至关重要,也与公司的运营和营收息息相关。这里列举两个公开的数据:“《页面加载超过3秒,57%的用户会离开》”“《Amazon页面加载延长1秒,一年就会减少16亿美金营收》”网络性能对于用户体验的影响,将非常直接地反馈到业务的运营上。而且,移动网络固有的弱网问题、DNS问题、连接性能等等都无法跟传统的固定网...  阅读全文

posted @ 2020-05-29 12:06 Jack Jiang 阅读(324) | 评论 (0)编辑 收藏

     摘要: 1、引言网络优化对于移动端App产品的用户体验至关重要,也与公司的运营和营收息息相关。这里列举两个公开的数据:“《页面加载超过3秒,57%的用户会离开》”“《Amazon页面加载延长1秒,一年就会减少16亿美金营收》”网络性能对于用户体验的影响,将非常直接地反馈到业务的运营上。而且,移动网络固有的弱网问题、DNS问题、连接性能等等都无法跟传统的固定网...  阅读全文

posted @ 2020-05-29 12:05 Jack Jiang 阅读(274) | 评论 (0)编辑 收藏

1、引言

IM应用的初学者们,在补全了各种基础技术知识后(如果您仍不具备这些知识,建议马上阅读《新手入门一篇就够:从零开发移动端IM》),在动手编码实践时,很多时候纠结的并不是功能该如何实现,而是这个功能该实现成什么样(没有经验,我特玛能找谁问问?)。

比如,最常见的纠结有以下这些:

  • 1)离线聊天消息该保存多久?
  • 2)好友请求应该保存多久?
  • 3)短视频消息中的视频时长设为多大合适?
  • 4)图片、短视频、语音这些多媒体消息中,未读的文件数据保存多久?
  • 5)群管理的逻辑该怎么弄?参考微信?还是参考QQ?(关键是参考资料哪里有?)
  • 6)朋友圈限制最多发几张照片合适?
  • ... ...

嗯,这些问题,老板认为并不是问题,因为可以“参考微信”啊!

然而,微信又不会亲口说出来它的这些规则到底是多少?难不成要一个一个去试?那太扯了!

本文将根据微信官方目前已公开的资料,将它的一些常用功能参数和逻辑规则资料进行了汇总整理,希望能助力你的IM开发!(本文已发布于:http://www.52im.net/thread-3008-1-1.html

学习交流:

- 即时通讯/推送技术开发交流5群:215477170[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》

本文已同步发布于“即时通讯技术圈”公众号,欢迎关注:

▲ 本文在公众号上的链接是:https://mp.weixin.qq.com/s/F-pVE9vN21h0Vm8LwnYplg

2、资料来源

本文中整理的所有内容均来自微信官方知识库,如果存在不全或不准确的情况,请在评论中回复,我会逐条核实并修订。

* 特别申明:本文内容仅供研究和学习使用,请勿用作其它用途。如有不妥之处,请指出,我会及时处理。

3、阅读对象

本文适合作为新老IM开发者的备查资料。本文不适合不懂技术的普通用户阅读,因为所有内容都尽量以技术人员的视解整理和表述。

移动端IM产品中,微信是标杆,也是事实的用户体验标准。所以,无论是被老板或产品经理怼,直接说“微信也这样”,能省去很多口水仗(经验啊)。这也是整理本文的初衷,以及价值所在。

4、相关资源

微信本地数据库破解版(含iOS、Android),仅供学习研究 [附件下载]》(* 推荐研究)

仿微信的IM聊天时间显示格式(含iOS/Android/Web实现)[图文+源码]

5、微信的好友关系规则汇总

5.1 好友验证请求有效期限

有效期限为 3 天。

* 补充规则:微信的好友验证请求只保存在手机本地,当卸载重装后,好友请求会消失且无法找回。

5.2 通讯录分组/好友排序

微信通讯录分组、好友排序,是根据微信通讯录朋友昵称的首字母(或首个汉字拼音首字母)由A-Z排序。

* 补充规则:如果好昵称是特殊符号、数字或Emoji表情(比如爱心、气球等),将会归到#类中。

 

5.3 好友验证规则

  • 1)当开启“加我为朋友时需要验证”后,需你同意接受请求后,才能成为好友;
  • 2)未开启“加我为朋友时需要验证”时,任何人都能添加你为好友(无需你确认)。

* 补充规则:如果不想被他人添加好友时搜索到,微信中可以设置关闭“微信号/手机号/QQ号”等搜索方式。

 

5.4 微信有4种添加好友方式

1)搜索加好友:

输入对方的微信号/QQ号/手机号搜索添加即可,但不支持搜索昵称。

* 补充规则:如果对方将关闭了“通过QQ/手机号/微信号搜索到我”,则没有办法通过此种方法添加好友。

2)雷达加朋友:

当被添加者物理距离很近时,一起按住手机,就可以添加对方为朋友。

3)扫二维码加朋友:

扫描对方的二维码名片,就可以添加对方为朋友。

4)手机联系人:

绑定手机联系人的微信帐号,可以查看到手机通讯录联系人已开通了微信的朋友,并直接添加对方为微信好友。

5.5 好友人数上限

微信最多可以添加 5000 个好友。

5.6 通讯录黑名单功能逻辑

将对方加入黑名单后,与对方的关系逻辑如下:

  • 1)在自己的会话列表不再显示与其聊天记录,解除黑名单后会重新出现在会话列表中;
  • 2)在对方的通讯录好友列表中仍然会显示;
  • 3)将不再接收到对方的消息;
  • 4)对方无法给你发消息,会提示“对方拒绝接收您的消息”,自己可以给对方正常发送消息;
  • 5)互相无法查看更新后的头像、个性签名;
  • 6)对方将无法查看你的微信个人相册和对照片进行评论;
  • 7)互相看不到朋友圈更新,拉黑之前在朋友圈分享的照片也不在对方朋友圈展示。

5.7 当被对方删除或“拉黑”后的聊天效果

当好友将你删除或加入黑名单后,你给他发消息时,微信将出现以下提示。

对方将我加入黑名单后,我发消息时的微信提示:

对方把我删除后,我发消息时的微信提示: 

6、微信的群聊规则汇总

6.1 微信群的功能定位

微信群相当于QQ中的讨论组,所以没有QQ里的群号码这种东西。

6.2 群主规则

群的创建者默认是群主。

* 补充规则:当创建者退出该群时,群成员列表中的第一位(也就是建群以来第2个加群的人)将自动成为新群主(好奇葩的规则!)。

另外:当原群创建者(即原群主)再次加群时,身份将会是普通群员。

6.3 群员邀请规则

群成员可以拉其他人加入群,群主不能取消普通群员的这个能力。

* 补充规则:群主可以设置邀请需确认,即需群主确认后才可以让被邀请的好友加到群内。

6.4 群名称规则

每个人(不只是群主)都可以修改群名称。

* 补充规则:当群超过 100 人时,只有群主可以修改群名称。

6.5 群公告规则

只有群主可编辑群公告。

* 补充规则:群公告字数限制为最大 2000 个字(即4000字节)。

6.6 群保存规则

微信群需要手动添加到通讯录才会永久保存,否则它只会保存在本地,一旦你卸载APP后,它就会消失。除非有群内成员发送消息,你才能再次看到,除次之外,你没有别的方法可以找回它。

6.7 群人数限制

微信群最大上限为 500 人。而且,100 人以上的微信群只有已通过实名验证的微信用户才能加入。

6.8 加群验证规则

  • 1)当群人数小于40人时,好友可以自由加入或被邀请加入;
  • 2)当群人数超过40人时,加群邀请需要对方同意;
  • 3)当群人数超过100人时,对方需要通过实名验证才能接受邀请(微信中可以通过绑定银行卡进行实名验证)。

6.9 解散或退出群规则

微信没有像QQ那样的“一键解散群”功能。

可以通过中列方法实现解散群或退出群的能力:

1)如果是群主(创建者或群成员列表第一位),可以将群成员全部删除;

2)如果是普通群员,可以退出群聊。

6.10 群二维码的有效期限

微信群的二维码有效期为 7 天(从二维码生成时开始计算),失效后的2维码扫描时将提示“该二维码已过期”。

6.11 微信群消息屏蔽规则

微信没有屏蔽群聊消息的功能,如果要达到这样的效果,你只能设置不提醒新消息或退出此群。

7、微信的朋友圈规则汇总

7.1 照片数和文字数限制

  • 1)朋友圈照片单次最多可添加 9 张照片,上传照片没有文件数量限制,也没有存储容量限制。
  • 2)最多可输入 1500 个汉字(即 3000 个字节)。

7.2 朋友圈新动态提醒规则

如果关闭了朋友圈更新提醒,当好友有发布新的朋友圈动态时,“发现”按钮上将不会再出现红点提示,否则将提示。

 

7.3 朋友圈查看权限规则

当你未作任何权限设置的情况下:

  • 1)你的所有朋友可以,查看到你在朋友圈发表的所有动态;
  • 2)陌生人可以查看你最近的10条动态。

发新朋友圈时,可以设置回避的人(即设置“谁可以/不可以看”):

  • 1)公开:所有朋友可见;
  • 2)私密:仅自己可见;
  • 3)部分可见:可在通讯录中选择哪些好友可见;
  • 4)不给谁看:可在通讯录中选择哪些好友不可见。
 

可以允许或禁止陌生人查看:

可以允许或禁止陌生人(可能来自扫码但未添加好友、附近的人、摇一摇、群聊时)看到10张最近发的照片。

可以设置朋友圈查看时间范围:

可选择允许好友查看朋友圈最近三天、最近半年或者全部的内容。

可以关闭朋友圈功能:

之前通过朋友圈发表的照片,可在个人相册里查看。但好友仍可以看到。

7.4 朋友圈的评论可见规则

  • 1)评论时,只会通知发布者;
  • 2)当评论时“@”某评论者,只会通知被回复者;
  • 3)评论者只能看到朋友的所有评论(当该条朋友圈的回复者不是朋友时,是看不到他的回复的)。

7.5 朋友圈隐私规则

1)陌生人查看十张照片:

当禁止“允许陌生人查看十张照片”时,陌生人将看不到你发布的任何朋友圈动态。微信默认是允许。

2)不看他(她)的朋友圈(即屏蔽好友的朋友圈):

在您的朋友圈中不会显示对方发送的朋友圈消息。

3)不让他(她)看我的朋友圈(即内容不更新给好友):

对方查看您的朋友圈显示是空白的,不会显示您发送过的任何朋友圈消息。

 

8、微信的聊天消息规则

8.1 聊天记录保存规则

  • 1)微信聊天记录保存在本地手机,一旦卸载微信,则聊天记录永久消失;
  • 2)微信不支持聊天记录漫游功能,一旦更新手机,新手机上无法看到之前手机上的聊天记录。

点评:这里有份完整的微信本地数据库样本,可以用来研究和学习:《微信本地数据库破解版(含iOS、Android),仅供学习研究 [附件下载]》。

8.2 离线消息保存规则

  • 1)微信服务器只保存 72 小时内的离线普通消息(从对方发消息时间开始算起),过期会被服务端清理;
  • 2)微信服务器只保存 72 小时内的多媒体数据(图片、短视频、大文件),即使你的手机已收到该条消息,只要未点击查看,即被视为未读,服务器会在此期限后清理掉多媒体数据。

8.3 “对方正在输入”的显示规则

给对方发送消息后,对方在 10 秒内回复才可以看到该提示。

 

8.4 聊天消息撤回时限

微信的规则是可以撤回2分钟内发送的消息。

8.5 消息已读回执规则

微信不支持已读回执功能。微信认为已读或未读状态属于个人隐私,不希望打破这种自由沟通的感觉。

8.6 语音消息规则

  • 1)最长可录制为 60 秒的语音消息;
  • 2)语音文件格式为:AMR;
  • 3)语音文件压缩比率:60秒语音文件约为45KB。

点评:如果你的IM中,语音文件大大超过微信的这个数据量,就表达存在较大优化空间,可以从采样率等方面进行设置。

8.7 短视频消息规则

  • 1)最长可录制为 10 秒的语音消息;
  • 2)语音文件格式为:MP4;
  • 3)语音文件压缩比率:10秒短视频约文件红为1.5MB至2.0MB。

点评:如果你的IM中,短视频文件大大超过微信的这个数据量,就表达存在较大优化空间,可以从采样率等方面进行设置。

8.8 文件消息规则

微信限制最大可以上传的文件大小为 25 MB。

8.9 聊天消息时间显示规则

  • 1)当天的消息,以每5分钟为一个跨度显示时间(即格式:HH:mm);
  • 2)超过1天、小于1周的消息,将显示“星期+收发消息的时间”;
  • 3)超过1周的消息,将显示手机收发时间的日期(即格式:yyyy-MM-dd)。

点评:这里有一份仿微信的聊天界面时间显示规则代码,可以下载用一用:《仿微信的IM聊天时间显示格式(含iOS/Android/Web实现)[图文+源码]》。

9、微信的其它规则

9.1 收藏功能规则

  • * 收藏的内容:可以收藏文字、语音、图片、视频、地理位置等。
  • * 保存的位置:收藏里面的内容是保存在服务器中的,只要你不主动删除,会一直存在。
  • * 单个文件大小限制:可以收藏的单个文件大小不能超过 25 M。
  • * 存储总容量限制:微信限制收藏数据的总容量为 2 GB,当总收藏容量超出2G后,超出容量的内容,将不能再上传。

9.2 “附近的人”功能规则

  • * 技术实现:当你查看附近的人功能时,微信将通过手机GPS获取你的位置信息,同时会被保留一段时间。
  • * 位置缓存:当你使用过“附近的人”时,服务器就会留下您的地理位置信息一段时间,周围的人可以再次搜到您。

9.3 “摇一摇”功能规则

当距离很近的两个同时“摇一摇”时,不一定能摇到对方。因为微信的“摇一摇”没有距离限制,而且是由服务器随机匹配。

10、电脑版微信的特殊规则

10.1 可以发送的消息类型

微信电脑端,可以发送文字、默认表情、符号表情、动画表情(兔斯基表情)、截图、图片消息,并能同步手机上已收藏的表情并发送。

10.2 可能接收的消息类型

可以接收文字、默认表情、emoji表情、动画表情、图片、文件、语音、视频、公众号消息、名片类型消息、小视频、地理位置消息、转账消息、合并转发的聊天记录消息。

10.3 可以接收但不能查看的的消息类型

红包消息、AA收款消息(收到此类消息会提示请在手机上查看)。

10.4 发送文件的大小限制

微信电脑端,上传文件大小最大为 100 MB,一次最多可以选择10个文件同时发送。

* 补充规则:如果发送的是视频,则文件大小不能超过 25 MB。

附录:微信团队分享技术资料汇总

微信朋友圈千亿访问量背后的技术挑战和实践总结

微信团队分享:微信移动端的全文检索多音字问题解决方案

微信团队分享:iOS版微信的高性能通用key-value组件技术实践

微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?

微信团队原创分享:iOS版微信的内存监控系统技术实践

iOS后台唤醒实战:微信收款到账语音提醒技术总结

腾讯技术分享:社交网络图片的带宽压缩技术演进之路

微信团队分享:视频图像的超分辨率技术原理和应用场景

微信团队分享:微信每日亿次实时音视频聊天背后的技术解密

微信团队分享:微信Android版小视频编码填过的那些坑》 

微信手机端的本地数据全文检索优化之路》 

企业微信客户端中组织架构数据的同步更新方案优化实战

微信团队披露:微信界面卡死超级bug“15。。。。”的来龙去脉

月活8.89亿的超级IM微信是如何进行Android端兼容测试的

一篇文章get微信开源移动端数据库组件WCDB的一切!

微信客户端团队负责人技术访谈:如何着手客户端性能监控和优化

微信后台基于时间序的海量数据冷热分级架构设计实践

微信团队原创分享:Android版微信的臃肿之困与模块化实践之路

微信后台团队:微信后台异步消息队列的优化升级实践分享

微信团队原创分享:微信客户端SQLite数据库损坏修复实践》 

腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率》 

腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)》 

腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(上篇)》 

微信Mars:微信内部正在使用的网络层封装库,即将开源》 

如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源》 

开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》 

微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解》 

微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)》 

微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)》 

Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》 

微信团队原创分享:Android版微信从300KB到30MB的技术演进》 

微信技术总监谈架构:微信之道——大道至简(演讲全文)

微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]》 

如何解读《微信技术总监谈架构:微信之道——大道至简》

微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]

微信异步化改造实践:8亿月活、单机千万连接背后的后台解决方案》 

微信朋友圈海量技术之道PPT [附件下载]》 

微信对网络影响的技术试验及分析(论文全文)》 

一份微信后台技术架构的总结性笔记》 

架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]》 

快速裂变:见证微信强大后台架构从0到1的演进历程(一)

快速裂变:见证微信强大后台架构从0到1的演进历程(二)》 

微信团队原创分享:Android内存泄漏监控和优化技巧总结》 

全面总结iOS版微信升级iOS9遇到的各种“坑”》 

微信团队原创资源混淆工具:让你的APK立减1M》 

微信团队原创Android资源混淆工具:AndResGuard [有源码]》 

Android版微信安装包“减肥”实战记录》 

iOS版微信安装包“减肥”实战记录》 

移动端IM实践:iOS版微信界面卡顿监测方案》 

微信“红包照片”背后的技术难题》 

移动端IM实践:iOS版微信小视频功能技术方案实录》 

移动端IM实践:Android版微信如何大幅提升交互性能(一)

移动端IM实践:Android版微信如何大幅提升交互性能(二)

移动端IM实践:实现Android版微信的智能心跳机制》 

移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)

移动端IM实践:iOS版微信的多设备字体适配方案探讨》 

腾讯信鸽技术分享:百亿级实时消息推送的实战经验

IPv6技术详解:基本概念、应用现状、技术实践(上篇)

IPv6技术详解:基本概念、应用现状、技术实践(下篇)

微信多媒体团队访谈:音视频开发的学习、微信的音视频技术和挑战等

腾讯技术分享:微信小程序音视频技术背后的故事

微信多媒体团队梁俊斌访谈:聊一聊我所了解的音视频技术

腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践

手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)

微信团队分享:Kotlin渐被认可,Android版微信的技术尝鲜之旅

社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进

社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节

社交软件红包技术解密(四):微信红包系统是如何应对高并发的

社交软件红包技术解密(五):微信红包系统是如何实现高可用性的

社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

QQ设计团队分享:新版 QQ 8.0 语音消息改版背后的功能设计思路

微信团队分享:极致优化,iOS版微信编译速度3倍提升的实践总结

IM“扫一扫”功能很好做?看看微信“扫一扫识物”的完整技术实现

微信团队分享:微信支付代码重构带来的移动端软件架构上的思考

IM开发宝典:史上最全,微信各种功能参数和逻辑规则资料汇总

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-3008-1-1.html

posted @ 2020-05-21 13:23 Jack Jiang 阅读(348) | 评论 (0)编辑 收藏

本文引用了公众号“鲜枣课堂”的《5G消息(RCS),到底是什么?》和公众号“InfoQ”的《5G消息来了,它会干掉微信还是变成另一个飞信?》两篇文章的部分内容,感谢原作者的分享。

1、引言

上个月3大运营商(移动、电信、联通)发布了《5G消息白皮书》(此白皮书PDF版 ▶ 点此附件下载),宣布将共同启动5G消息业务。

 

简单理解,5G消息相当于是原先短消息服务的全新升级。与以前的短消息相比,5G消息具有多媒体、能互动服务的能力,不仅有文字、图片,还能发视频、位置,甚至进行支付。

嗯,听起很熟悉——这不就是微信、支付宝们现在干的活吗?

没错!在移动互联网时代已经沦为微信这类IM巨头的管道工的运营商们,正在试图通过5G消息这个新工具抢回失去的话语权。

那么,5G消息到底是什么?是完全的创新技术还是旧式短信技术的新瓶装旧酒?它是否真的具有可以取代现时移动端主流IM产品的能力?请跟着本文,一起读懂5G消息的前世今生!

学习交流:

- 即时通讯/推送技术开发交流5群:215477170[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

本文已同步发布于“即时通讯技术圈”公众号,欢迎关注: 

▲ 本文在公众号上的链接是:https://mp.weixin.qq.com/s/BF3ja1Uui6Pn32z0zI0H2g

2、5G消息是全新技术?

No,并不是!

“5G消息”,其实和5G并没有什么关系。它既不是5G特有的功能,也不是5G时代新开发出来的业务。它的真实身份,是诞生已有 10 多年的 RCS 技术。

3大运营商之所以要把它名名为“5G消息”,很大原因应该还是想借5G这个热点,从营销推广的角度进行的考虑,与技术无关。

RCS,全称是“Rich Communication Suite”,中文翻译过来就是“富媒体通讯套件”。

什么是“富媒体(Rich Media)”?传统电话只有语音,传统短信只有文本。而“富媒体”,包括文本、语音、图片、视频、动画、表情、位置等多种媒体形式。我们天天在用的微信,就是一种富媒体通信工具。

 

RCS,也被称为融合通信。所谓“融合”,既可以理解为多种媒体形式融合,也可以理解为IP业务和传统电信网业务的融合。

大白话来说,RCS可以理解为它是升级了传统的短信产品,使“短信”丰富化。

3、RCS技术的发展历程

我们先了解一下RCS技术的发展历程。

3.1 传统PC端IM的兴起,让电信厂商们蠢蠢欲动

我们把时间拨回到20多年前。当时,PC互联网以惊人的速度发展壮大,给人类带来了前所未有的信息大爆炸。

尤其是ICQ、MSN、OICQ(即QQ)等即时通讯工具的出现,让人们见识到多媒体通讯的无限乐趣。

 

▲ 能认全这3个IM的,都是老网民

于是,人们想到,这么有趣的通讯方式,是不是可以移植到手机上?

3.2 IMS的出现

3G移动通信标准,就是在这样的背景下建立起来的(2000年5月)。从3G起,手机的重点发展方向变成了数据业务,以满足人们日益增长的多媒体通信需求。

3G向4G的发展过程中,负责牵头标准制定的3GPP组织,考虑到传统语音通话及短信业务也需要向多媒体演进。于是,在2002年的3GPP Release 5版本中正式提出了IMS。

搞通信的读者一定对IMS这个词非常熟悉。如果是非通信专业的读者,我可以告诉你另外一个和IMS密切相关的词,那就是这几年特别火的VoLTE(Voice over LTE)。

是的,VoLTE业务,就是基于IMS实现的。

IMS的全称,叫做IP多媒体子系统(IP Multimedia Subsystem)。它包括了一系列不同的通信设备网元。

IMS的网络结构和业务流程非常复杂。对于IMS的作用,我们可以这么理解——它帮助4G LTE这个纯数据网络,实现对语音通话和短信的支持,并对它们进行强化(升级为多媒体形式)。

 

▲ IMS就是4G LTE网络的一个“插件”。有了它,4G才能打电话和发短信

在IMS的基础上,才有了VoLTE和RCS。

 

3.3 RCS的出现

2007年,RCS由一小部分GSMA(全球移动通信系统协会)成员提出,目的是为了运营商之间的多媒体消息互通。

2008年2月,GSMA正式成立RCS项目,并将其命名为“home”。此后,GSMA发布了多个版本的RCS、RCS-e(enhance,增强型)规范。

 

▲ GSMA,可以理解为全球运营商协会,主要代表运营商利益

RCS发布之后,得到了全球众多运营商的拥护。尤其是2008年4G LTE标准发布之后,RCS成为运营商们建设4G的标配。

3.4 RCS在移动端IM的挤压下持续演进

同样是2008年前后,iPhone和安卓相继问世,移动通信进入智能机时代,移动互联网市场开始井喷。

2011年左右,以WhatsApp、LINE、Facebook Message为代表的OTT通讯工具出现并迅速崛起,大量蚕食了传统运营商的语音、短信收入。

 

于是,海外运营商更加仰仗RCS,希望借此与OTT软件进行竞争。当时Vodafone、Orange、SKT、Verizon、O2等海外知名运营商都推出了自己的RCS解决方案和品牌。

2016年,为了进一步推动RCS的产品开发及全球部署,GSMA推出了RCS Universal Profile(通用配置文件,简称UP,相当于是一个规范标准),并陆续更新了多个版本。目前最新的版本,就是2019年10月发布的Version 2.4。

 

▲ RCS和UP的版本演进

3.5 RCS在国内的发展

我们回过头来看看RCS在国内的发展。

中国的3G和4G建设启动普遍晚于欧美日韩。3G就不用说了,晚了8年。4G是晚了5年。2013年底,工信部才发放了LTE商用牌照。

作为LTE的积极建设者,中国移动在2014年LTE大规模建网的同时,就非常看重IMS、VoLTE、RCS的商业价值。

因为飞信的前车之鉴,中国移动已经充分意识到传统运营商正在出现管道化的趋势,利润空间将不断被挤压,急需和OTT抢占流量入口,寻找新的业务增长点。

 

2015年,就在国内LTE网络覆盖初具规模之后,中国移动大幅提前了国内各省IMS和VoLTE网络的建设进度,并积极推动广州研究院的RCS业务验证和测试。

其实国内的三大运营商也都没有闲着,在 2017 年 4 月就完成了 RCS 三方(3大运营商)互通测试规范编制。其中,中国移动较为积极,在 2017 年 12 月即商用 RCS,包含 Native、App、PC 以及 SDK 四种终端形态。2019 年中移终端公司要求,所有在终端公司入库销售的机型都要支持 RCS Native 功能。

随着5G的到来,情况又发生了不同。

为了给5G网络腾挪更多的频谱空间,运营商必须加速2/3G网络的退网。而依附在2/3G网络上的传统语音和短信业务,必须尽快迁移到LTE和IMS网络上。(国内LTE网络的成熟覆盖,IMS的建设完成,使得RCS的推出具备了很好的时机。)

与此同时,面对OTT业务的持续打压,运营商也希望通过RCS进行最后一搏。于是,就有了这次“5G消息”业务的联合发布。

之所以叫“5G消息”,主要是希望借助5G的品牌,体现RCS业务和传统消息业务之间的代差。

4、RCS到底能实现什么样的功能和体验?

接下来我们讲讲RCS到底能实现什么样的功能,以及用户体验,何以让3大运营商重燃对搞微信等IM巨头的信心。

4.1 运营商对RCS的功能定位

中国移动在2014年曾经基于RCS提出了「三新」目标。这里面的三新,指的是:新通话、新消息以及新联系,分别指代了手机上的电话,短信,通讯录这三大入口。

  1. “新通话”以VoLTE为核心,增强用户通话质量和体验;
  2. “新消息”无缝融合多种媒体和消息格式,无缝与传统短/彩信互通;
  3. “新联系”以真实手机号码为前提,构建全新的社交、公众信息服务入口。

其实,这已经很明确地给出了RCS的功能和定位。

从总体上来看,运营商对RCS的应用场景定位分为两种:

  • 一种是个人用户与个人用户之间的消息交互;
  • 一种是企业用户与个人用户之间的消息交互。
 

4.2 RCS在普通用户间的消息交互与微信等IM相比,优势并不明显

针对场景1(即个人用户与个人用户之间的消息交互),RCS支持点对点消息,支持群发、群聊,支持语音、图片、视频多媒体消息,还支持发送位置、名片等,甚至还支持消息云备份和阅后即焚。

RCS的个人用户聊天时可以支持以下消息类型(跟IM很像): 

这些功能和我们目前的微信都差不多,RCS并没有体现出什么优势。考虑到用户习惯等原因,RCS估计很难撬动微信的霸主地位,未来可能主要是处于一个辅助性的地位。

更受运营商及整个产业关注的,其实是场景2(即企业用户与个人用户之间的消息交互)。

4.3 RCS在企业与个人的消息交互场景下,有很大的想象空间

2017年,GSMA在UP2.0规范中引入MaaP,还发布了MaaP白皮书,明确提出了面向A2P(Application to Person)行业消息的“RCS商业富媒体消息(RCS Business Messaging)”,也就是我们所说的场景2。

 

▲ RCS商业富媒体消息

MaaP,就是Messaging as a Platform,消息即平台。

RCS商业富媒体消息,为企业和个人用户之间提供消息交互接口,在图片和视频等基础上增加了交互能力,方便企业向用户输出个性化服务。

例如机票酒店预订查询、物流查询、网购订单查询等一系列轻应用功能,都可以通过RCS商业富媒体消息实现。

 

RCS商业富媒体消息的价值在于,它为企业和用户提供了一条新通道。借助这条通道,企业可以触达用户。用户也可以触达服务。

从某种意义上来说,它很像小程序、微信公众号(服务号),甚至电话客服中心。

为了实现RCS商业富媒体消息,运营商在自身网络上架设了MaaP能力增强开放平台和Chatbot聊天机器人。平台面向企业开放API接口,以提供服务。

技术架构大概是这样的: 

4.4 RCS拥有普通IM所不具备的优势

运营商对于“5G消息”(即RCS技术)这么有信心,源码它的一些独特的优势。

4.4.1)RCS优势1:它需要单独安装APP

它不需要单独安装第三方APP,手机原生就可以支持。这大幅降低了用户使用门槛,也节约了推广成本。

 

▲ 每个人的手机,都少不了这三个图标

虽然目前大部分手机并不支持5G消息,但后续各大厂商对手机进行软件升级,支持RCS UP 2.4规范之后,都可以支持。即使你不是5G手机(但至少是4G手机),也可以支持。

4.4.2)RCS优势2:无需注册账号

RCS业务和手机号码直接关联,用户号码就是账号,无需注册。

这同样降低了用户使用业务的复杂度,不仅解决了身份认证问题,还打通了“平台孤岛”(无需在每个商户单独注册账号)。

 

▲ 手机号即账号,一号通用

4.4.3)RCS优势3:无需添加好友

RCS牢牢掌握住了用户通信录这个社交金钥匙,无需添加好友,即刻就能建立社交网络。

尽管RCS拥有以上优势,但真正决定它能否走向成功的,并不是这些优势,而是它的生态和商业模式。

RCS的产业链既包括运营商、设备商、终端厂商,也包括平台服务商、内容提供商等。

设备商和终端厂商还好说,关键是平台服务商和内容服务商。它们愿不愿意投入,平台和应用该如何开发,开发能不能获得回报,如何吸引商户,要不要收费,如何收费,商户愿不愿意买单,这些都是未知数。

如果生态不能做大做强,就无法孵化更多的5G消息应用场景,也就谈不上商业价值回报。

5、现在才统一起来做“5G消息”,是否有点迟了?

从 3G 时代开始,全球电信运营商就受到 OTT(“OverTheTop”的缩写,指通过互联网向用户提供各种应用服务)厂商的冲击,国内三大运营商也不例外,传统的话音和短信业务收入大幅下降,OTT 服务虽然能带来流量收入,但也难以掩盖其增量不增收的尴尬。

随着微信等移动端IM互联网应用的不断扩张,运营商虽手握数亿用户,期间也有过大大小小的尝试与挣扎,例如中国移动的飞信、中国联通的沃友以及中国电信的易信,但最终都被边缘化。对 RCS 也有不少投入和试点,却还是雷声大雨点小,掀不起水花。三大运营商依然沦为主要提供语音、短信、流量等基础通信服务的“管道工”。

 

似乎,过度的竞争是导致运营商们错失机遇的主因之一。

某运营商直言:“过去,移动披靡一切。但后来对内‘弄不死’电信和联通,对外干不过阿里腾讯,对上交代不了国资委的考核。”。三大运营商终于联手便是 5G 消息的最大意义。

与采用私有协议的 App“孤岛式”的现状相比,由于三家运营商基于同一的国际标准(GSMA RCS UP 2.4),5G 消息在互联互通上的优势更为明显。

对比过去传统的短信业务,5G 消息可快速迭代——相关技术标准在 3 年内已迭代 5 大版本,从 UP1.0(2016 年 Q4)到最新的 UP2.4(2020 年 Q4)。

6、RCS看起来很美,但并非无懈可击

RCS确实具体先天优势,但也并非无懈可击。

RCS 仍面临三大挑战:

  • 1)用户的服务体验不一致,也给终端互联互通带来挑战(它无法做到像微信这样的IM一样,每款手机上安装的都是同一个应用);
  • 2)消息业务将会不断创新演进,需要终端快速跟进和支持,传统的技术研究、标准制定,终端研发,运营商测试等运营商长周期的流程,难以适应 RCS 快速发展;
  • 3)行业客户对 RCS 业务仍不熟悉,开发门槛较高。

另一方面,要培养用户使用短信入口的服务也不是件易事。

5G 时代,是多终端连接的物联网时代,小程序也被视为物联网众多的入口之一,谁都不会想放过这个机遇。

但 5G 消息能否拿回被微信这种IM应用抢走的市场,又或者在新的物联网增量市场分得一杯羹,尚需时日见证。可以肯定的是,对于客户来说,尤其是行业客户,多了一个选择。一个不是腾讯系,不是阿里系,也不是头条系的选择。

7、虽有不确定性,但RCS未来可期

目前,国内运营商的5G消息业务还处于试点大区联调测试阶段。

2020年4月10日,中兴通讯助力中国移动在杭州成功打通了基于GSMA UP2.4标准的5G消息first call,标志着国内5G消息商用进入正式倒计时。

据业内消息,2020年6月份国内就可以推出5G消息的正式商用。国内手机的升级支持,估计需要3个月到1年的时间。

相信随着5G建设的深入,RCS很快会成为大家手机中的标配。

“5G消息”到底会发展成什么样,作为IM开发者和普通用户来说,商业终究不是普通人该考虑的。从功能和体验上来说,多一种选择也未偿不是件好事,我们期待它早日到来!

 

8、最新动态:中国移动已于2020年5月10日上线“5G消息”APP

“5G消息”App是中国移动基于国际RCS标准打造的一款通讯及服务软件,支持发送文本、图片、音视频、地理位置等丰富消息;还可与商户的聊天机器人进行交互,获取7*24小时的智能服务。已于5月10日上线到苹果App store。

 

不幸的是,“5G消息”App上线仅一天就被下架(下架时间为5月11日)。

中国移动回应下架事件时说:因当前一些终端尚未支持5G消息功能,中国移动开发了“5G消息”APP,可以让开发者完成Chatbot(智能聊天机器人)应用开发后,真实体验消息交互服务,吸引广大开发者积极参与5G消息的合作生态构建,并非面向客户商用发布的产品。

中国移动表示:由于前期三家运营商联合发布5G消息白皮书,引发较高舆论关注,为保护“5G消息”名称不被恶意抢占,中国移动近日在应用市场进行上线(指的就是上线“5G消息”App)。因存在一些技术问题,该APP目前临时下线,稍后会重新上线。

在过去数年里,运营商与苹果公司的沟通讨论一直在进行中。目前通过安装App体验的做法,可以帮助苹果公司和苹果手机用户体验和使用5G消息。

9、《“5G消息”白皮书》附件下载

(附件无法上传,请从此链接下载:http://www.52im.net/thread-3001-1-1.html

10、参考资料

[1] 5G消息白皮书

[2] 中国移动率先发布5G消息APP:支持iOS/Android

[3] “5G消息”来了,App小心了!

[4] 中国移动、中国电信、中国联通联合发布《5G消息白皮书》

[5] 5G消息(RCS),到底是什么?

[6] 5G消息来了,它会干掉微信还是变成另一个飞信?

附录:更多IM产品方面的文章

技术往事:微信估值已超5千亿,雷军曾有机会收编张小龙及其Foxmail

QQ和微信凶猛成长的背后:腾讯网络基础架构的这些年

闲话即时通讯:腾讯的成长史本质就是一部QQ成长史

腾讯开发微信花了多少钱?技术难度真这么大?难在哪?

技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史》 

开发往事:深度讲述2010到2015,微信一路风雨的背后》 

开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)》 

微信七年回顾:历经多少质疑和差评,才配拥有今天的强大

前创始团队成员分享:盘点微信的前世今生——微信成功的必然和偶然

QQ的成功,远没有你想象的那么顺利和轻松

[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗?》 

QQ和微信止步不前,意味着即时通讯社交应用创业的第2春已来?

那些年微信开发过的鸡肋功能,及其带给我们的思考

为什么说即时通讯社交APP创业就是一个坑?

即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

老罗最新发布了“子弹短信”这款IM,主打熟人社交能否对标微信?

盘点和反思在微信的阴影下艰难求生的移动端IM应用

QQ现状深度剖析:你还认为QQ已经被微信打败了吗?

那些年微信开发过的鸡肋功能,及其带给我们的思考

渐行渐远的人人网:十年亲历者的互联网社交产品复盘和反思

中国互联网社交二十年:全民见证的互联网创业演义

读懂微信:从1.0到7.0版本,一个主流IM社交工具的进化史

王欣回应微信封禁,解释为何取名“马桶MT”

同为IM社交产品中的王者,QQ与微信到底有什么区别

还原真实的腾讯:从最不被看好,到即时通讯巨头的草根创业史

知识科普:IM聊天应用是如何将消息发送给对方的?(非技术篇)

QQ设计团队分享:新版 QQ 8.0 语音消息改版背后的功能设计思路

社交应用教父级人物的张小龙和马化腾的同与不同

技事往事:你知道IM聊天软件中的“对方正在输入…”功能的起源吗?

盘点移动互联网时代的社交产品进化史(上篇):谁主沉浮

盘点移动互联网时代的社交产品进化史(下篇):大浪淘沙

IM热门功能思考:为什么微信里没有消息“已读”功能?

IM热门功能思考:聊天中加入“对方正在输入…”真的好吗?

别做梦了,社交产品哪有那么容易成功

微信那么牛,为什么海外成功的却是抖音?

专访马化腾:首次开谈个人经历、管理心得、技术创新、微信的诞生等

一文读懂微信之父张小龙:失败天才、颠覆者、独裁者、人性操控师

新技术展望:5G消息能取代IM应用?一文读懂5G消息的前世今生!

>> 更多同类文章 ……

欢迎关注我的“即时通讯技术圈”公众号:

(本文同步更新于:http://www.52im.net/thread-3001-1-1.html

posted @ 2020-05-14 11:47 Jack Jiang 阅读(393) | 评论 (0)编辑 收藏

本文引用了后端技术指南针公众号“浅谈RPC那些事儿1”和即时通讯网的“即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途”两篇文章的部分内容。

1、引言

经常有开发者在纠结怎么开发IM集群,虽然真正的使用人数,可能用个人电脑单机都能支撑。

你也许会说,明明不需要用到IM集群,干吗要自找麻烦?答曰:“老板说这个得有!”、“万一产品做成了,用户量达到百万、千万级呢?”,各种回答,反此种种。总之,IM集群就是得整一个(先甭管用不用的上...)。

当然,玩笑归玩笑,真正要做到可投入到生产级别的IM集群系统,难度还是相当大的。必竟IM这种长连接应用相比传统Http这种短连接应用太不标准。

我们以一个典型的IM聊天消息传输为例:

假设存在两个正在聊天的用户(用户A和用户B),当A连接的是IM集群中的IM实例1、B连接的是IM集群中的IM实例2,此时当用户A向用户B发送一条聊天消息时,这条消息应该如何传递呢?

我们梳理一下上面这个例子的消息流转过程:

  • 1)IM聊天消息首先会由用户A发往IM实例1;
  • 2)IM实例1会将此条消息转交给IM实例2;
  • 3)IM实例2会将此条消息最终投递给连接在本实例上的用户B。

如上述流程所示,这就是一个IM集群系统中典型的聊天消息投递过程。

那么,这其中涉及到一个关键步骤:即第2)步中如何实现“IM实例1会将此条消息转交给IM实例2”?

此时,RPC技术出场了!

 

▲ 上图是个典型的分布式IM架构,注意中间的“RPC通信”字样本图引用自《基于Go的马蜂窝旅游网分布式IM系统技术实践

本文将以通俗易懂的白话形式,帮你快速理解IM集群中的关键技术——RPC。

推荐阅读:另一篇RPC基础知识文章也值得一读《即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途》。

本文已同步发布于“即时通讯技术圈”公众号,欢迎关注:

▲ 本文在公众号上的链接是:https://mp.weixin.qq.com/s/0RXTUWHXDmMddsPVWej2Qg

2、相关文章

▼ 以下两篇文章有助于您对RPC和IM集群有个初步的概念:

即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途》(推荐)

即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?

▼ IM开发干货系列文章(本文是其第24篇):

IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

IM消息送达保证机制实现(二):保证离线消息的可靠投递

如何保证IM实时消息的“时序性”与“一致性”?

IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?

IM群聊消息如此复杂,如何保证不丢不重?

一种Android端IM智能心跳算法的设计与实现探讨(含样例代码)

移动端IM登录时拉取数据如何作到省流量?

通俗易懂:基于集群的移动端IM接入层负载均衡方案分享

浅谈移动端IM的多点登陆和消息漫游原理

IM开发基础知识补课(一):正确理解前置HTTP SSO单点登陆接口的原理

IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?

IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

IM群聊消息的已读回执功能该怎么实现?

IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?

IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

一个低成本确保IM消息时序的方法探讨

IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!

IM里“附近的人”功能实现原理是什么?如何高效率地实现它?

IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路

IM开发基础知识补课(八):史上最通俗,彻底搞懂字符乱码问题的本质

IM的扫码登功能如何实现?一文搞懂主流应用的扫码登陆技术原理

IM要做手机扫码登陆?先看看微信的扫码登录功能技术原理

IM开发基础知识补课(九):想开发IM集群?先搞懂什么是RPC!》(本文)

如果您是IM开发初学者,强烈建议首先阅读《新手入门一篇就够:从零开发移动端IM》。

3、正文概述

限于篇幅原因,本文不会深入展开RPC的底层技术原理,会尽量用通俗白话的方式对概念性的东西进行讲解。

通过本文你将主要了解到以下内容:

  • 1)什么是RPC;
  • 2)为什么需要RPC;
  • 3)RPC的重要组件;
  • 4)常见RPC框架和各自特点。

4、什么是RPC?

RPC 是1984年代由 Andrew D. Birrell & Bruce Jay Nelson 提出的(见二位大佬的论文《Implementing Remote Procedure Calls),所以它并不是最近才有的技术概念。

关于RPC的介绍,正经的资料上大概是这样介绍的:

RPC(Remote Procedure Call)远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。也就是说两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。

大白话理解RPC就是:RPC让你用别人家的东西就像自己家的一样。

看得我似懂非懂,于是我不得不问几个问题:

  • 1)为啥要用别人家的东西——请求其他服务);
  • 2)我怎么可以借到别人家的东西——其他服务调用;
  • 3)要是借用的话哪种形式更好——确定一个合适的调用方法);
  • 4)怎么让我用别人东西像自己的一样——屏蔽底层细节透明通信)。

在解答这些问题之前,我们必须达到一个共识问题:RPC只是一种通信模式,和http并不冲突对立,相反http可以作为RPC传输数据的一种协议,把RPC当作一种模式和思想,我们才能更好地理解它。

更严谨的RPC基础知识介绍,请阅读:《即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途》。

5、为什么需要RPC?

以大家最熟悉的电商系统为例,这样规模的分布式系统,需要拆分出用户服务、商品服务、优惠券服务、支付服务、订单服务、物流服务、售后服务等等。这些服务之间都相互调用,这时内部调用最好使用 RPC ,同时每个服务都可以独立部署,独立上线。 

也就说当我们的项目太大,需要解耦服务,扩展性强、部署灵活,这时就要用到 RPC ,这主要是解决了分布式系统中,服务与服务之间的调用问题。

 

▲ 上图中的分布系统内部,就是用RPC实现的本图引用自《从新手到架构师,一篇就够:从100到1000万高并发的架构演进之路

对于IM集群这样的分布式系统来说,不同IM实例间的用户聊天消息,就是通过RPC进行流转的。

6、为什么不直接使用HTTP,而要搞RPC?

在日常业务中我们可以把功能封装成静态库、动态库、sdk、独立服务等,最常见也最方便的还是HTTP这种形式的调用。

HTTP服务把需要提供的服务暴露成接口(也就是通常所说的http rest接口啦),使用方直接按约定的HTTP方法和URI进行数据交互。

我们都知道HTTP协议是应用层协议,是个非常标准的协议,在HTTP协议之下还有网络层、传输层、数据链路层等,一个数据包packet除了净荷payload之外还有很多header,由于标准和通用性的设计目标也使得HTTP一次数据交互真正传输的payload只是其中一部分。

 

HTTP是我们用的最多最熟悉的交互模式,在系统内部各个服务之间接口较少,交互不多的情况下工作得还不错。

但如果在内部系统调用很复杂的前提下,HTTP调用的效率和安全性就不那么理想了。

 

以IM系统为例,单个IM实例的吞吐效率至少可以达到几万甚至数十万QPS,使用HTTP这种短连接(调用时建立socket连接,完成后释放连接)方式显的相当低效(每次调用都要重新经历TCP的3次握手、4次挥手过程),在分布式的情况下势必拉低整个IM集群的吞吐效率。而对于RPC,这种socket长连接方式对于高性能场景来说,效果是显而易见的。

更重要的是面对众多的服务我们需要的不仅仅是一个通信方式,而是一个内部服务的管理系统,这也就是我们今天说的RPC框架。注意:RPC是一种模式策略和框架,并不是单纯的通信协议。

题外话:实际上,HTTP在RPC系统中,并不是个你死我活的关系,必竟HTTP只是个通信协议,而HTTP有某些性能要求不敏感的场景来说,是完全可以作为RPC的具体实现协议之一来使用的。

7、RPC的调用过程是什么样的?

 

▲ 典型的RPC调用过程

如上图所示,一个典型的RPC调用过程是这样(过程序号对应上图中的数字):

  • 1)客户端(client)以本地调用方式调用服务;
  • 2)客户端存根(client stub)接收到调用后,负责将方法、参数等组装成能够进行网络传输的消息体(将消息体对象序列化为二进制);
  • 3)客户端通过 sockets 将消息发送到服务端;
  • 4)服务端存根(server stub)收到消息后进行解码(将消息对象反序列化);
  • 5)服务端存根(server stub)根据解码结果调用本地的服务;
  • 6)本地服务执行并将结果返回给服务端存根(server stub);
  • 7)服务端存根(server stub)将返回结果打包成消息(将结果消息对象序列化);
  • 8)服务端(server)通过 sockets 将消息发送到客户端;
  • 9)客户端存根(client stub)接收到结果消息,并进行解码(将结果消息发序列化);
  • 10)客户端(client)得到最终结果。

RPC的作用,其实就是要把上述2、3、4、7、8、9 这些步骤都封装起来。是不是很神奇?

8、关于HTTP和RPC的一些争议

HTTP和RPC是两个很容易混淆的概念,对于刚开始接触RPC的人来说,通常都会困惑:有HTTP了为什么还要用RPC?

在知乎上看到了这个很有趣的问题:《既然有http请求,为什么还要用rpc?

其中一个大佬的回答感觉很有意思: 

换个角度来说:HTTP 与 RPC 的关系就好比普通话与方言的关系。要进行跨企业服务调用时,往往都是通过 HTTP API,也就是普通话,虽然效率不高,但是通用,没有太多沟通的学习成本。但是在企业内部还是 RPC 更加高效,同一个企业公用一套方言进行高效率的交流,要比通用的 HTTP 协议来交流更加节省资源。整个中国有非常多的方言,正如有很多的企业内部服务各有自己的一套交互协议一样。虽然国家一直在提倡使用普通话交流,但是这么多年过去了,你回一趟家乡探个亲什么的就会发现身边的人还是流行说方言。

如果再深入一点说,普通话本质上也是一种方言,只不过它是官方的方言,使用最为广泛的方言,相比而言其它方言都是小语种,小语种之中也会有几个使用比较广泛比较特色的方言占比也会比较大。这就好比开源 RPC 协议中 Protobuf 和 Thrift 一样,它们两应该是 RPC 协议中使用最为广泛的两个。

总之:RPC是一种编程模式和概念,并不是非常具体的一种技术,实际上和HTTP没有明确的冲突,HTTP可以作为RPC传输协议,原因还是RPCpid际上是一种内部服务框架而不是一个具体的通信协议,它可以涉及服务注册、服务治理、服务发现、熔断机制、负载均衡等。

9、典型的RPC框架

一个典型RPC框架中,包含了服务发现、负载、容错、网络传输、序列化等组件,其中“RPC 协议”就指明了程序如何进行网络传输和序列化。

 

▲ 一个典型的 RPC 架构原理图本图引用自《即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途

 

▲ 著名RPC框架Dubbo的架构图本图引用自《即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途

一个 RPC 最重要的功能模块,就是上图中的”RPC 协议”部分: 

其中的序列化和反序列化的意思是:

  • 1)序列化:将数据结构或对象转换成二进制串的过程;
  • 2)反序列化:将序列化中所生成的二进制串转换成数据结构或者对象的过程。

在网络消息传输中可以基于TCP、UDP、http来实现,各自都有各自的特点。

基于 TCP 实现的 RPC 调用,能够灵活对协议字段进行定制,减少网络开销提高性能,实现更大的吞吐量和并发数,但要关注底层细节,在进行数据解析时更加复杂一些(比如最受欢迎的Protobuf的使用)。

基于 HTTP 实现的 RPC 可以使用 JSON 和 XML 格式的请求或响应数据,解析工具很成熟,在其上进行二次开发会非常便捷和简单。但是 HTTP 是上层协议,所占用的字节数会比使用 TCP 协议传输所占用的字节数更高。

对于其他部分,本文不再展开。

10、市面上常见的RPC框架及其特点

常见 RPC 技术和框架有:

  • 1)应用级的服务框架:阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
  • 2)远程通信协议:RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。
  • 3)通信框架:MINA 和 Netty。

目前流行的开源 RPC 框架还是比较多的,有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。

下面重点介绍当前最流行的三种RPC框架主要特点:

  • 1)gRPC:是 Google 公布的开源软件,基于最新的 HTTP 2.0 协议,并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的,底层使用到了 Netty 框架的支持;
  • 2)Thrift:是 Facebook 的开源 RPC 框架,主要是一个跨语言的服务开发框架。用户只要在其之上进行二次开发就行,应用对于底层的 RPC 通讯等都是透明的。不过这个对于用户来说需要学习特定领域语言这个特性,还是有一定成本的;
  • 3)Dubbo:是阿里集团开源的一个极为出名的 RPC 框架,在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是极其鲜明的特色。

11、本文小结

小结一下,简单地理解RPC就是:

RPC 就是从一台机器(客户端)上通过参数传递的方式调用另一台机器(服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。

RPC 会隐藏底层的通讯细节(不需要直接处理Socket通讯或Http通讯)。

RPC 是一个请求响应模型。客户端发起请求,服务器返回响应(类似于Http的工作方式)。

RPC 在使用形式上像调用本地函数(或方法)一样去调用远程的函数(或方法)。

12、参考资料

[1] 什么是 RPC 框架

[2] 谁能用通俗的语言解释一下什么是 RPC 框架?

[3] 浅谈RPC那些事儿[1]

[4] 即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途

[5] 即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?

附录:有关IM架构设计的文章

浅谈IM系统的架构设计

简述移动端IM开发的那些坑:架构设计、通信协议和客户端

一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

一套原创分布式即时通讯(IM)系统理论架构方案

从零到卓越:京东客服即时通讯系统的技术架构演进历程

蘑菇街即时通讯/IM服务器开发之架构选择

腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT

微信后台基于时间序的海量数据冷热分级架构设计实践

微信技术总监谈架构:微信之道——大道至简(演讲全文)

如何解读《微信技术总监谈架构:微信之道——大道至简》

快速裂变:见证微信强大后台架构从0到1的演进历程(一)

17年的实践:腾讯海量产品的技术方法论

移动端IM中大规模群消息的推送如何保证效率、实时性?

现代IM系统中聊天消息的同步和存储方案探讨

IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?

IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

WhatsApp技术实践分享:32人工程团队创造的技术神话

微信朋友圈千亿访问量背后的技术挑战和实践总结

王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等

IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

以微博类应用场景为例,总结海量社交系统的架构设计步骤

快速理解高性能HTTP服务端的负载均衡技术原理

子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路

IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)

新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路

社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等

社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进

社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节

社交软件红包技术解密(四):微信红包系统是如何应对高并发的

社交软件红包技术解密(五):微信红包系统是如何实现高可用性的

社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

社交软件红包技术解密(七):支付宝红包的海量高并发技术实践

社交软件红包技术解密(八):全面解密微博红包技术方案

社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等

社交软件红包技术解密(十):手Q客户端针对2020年春节红包的技术实践

即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?

即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途

多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了

从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路

从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结

IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!

瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)

阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处

从游击队到正规军(三):基于Go的马蜂窝旅游网分布式IM系统技术实践

微信后台基于时间序的新一代海量数据存储架构的设计实践

IM开发基础知识补课(九):想开发IM集群?先搞懂什么是RPC!

>> 更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号,欢迎关注:


(本文同步发布于:http://www.52im.net/thread-2996-1-1.html

posted @ 2020-05-09 11:54 Jack Jiang 阅读(305) | 评论 (0)编辑 收藏

     摘要: 本文为开源工程:“github.com/GuoZhaoran/fastIM”的配套文章,原作者:“绘你一世倾城”,现为:猎豹移动php开发工程师,感谢原作者的技术分享。0、引言阅读提示:本文适合有一定网络通信技术基础的IM新手阅读。如果你对网络编程,以及IM的一些理论知识知之甚少,请务必首先阅读:《新手入门一篇就够:从零开发移动端IM》,按需补充相关...  阅读全文

posted @ 2020-04-28 12:05 Jack Jiang 阅读(475) | 评论 (0)编辑 收藏

阿里巴巴技术团队于2020年04月22日发布《Java开发手册v1.6.0-泰山版》。

1、概述

2017年开春之际,阿里诚意献上重磅大礼:《阿里巴巴Java开发手册(规约)》,首次公开阿里官方Java代码规范标准。这套Java统一规范标准将有助于提高行业编码规范化水平,帮助行业人员提高开发质量和效率、大大降低代码维护成本。

《阿里巴巴Java开发手册(规约)》是阿里内部Java工程师所遵循的开发规范,涵盖编程规约、单元测试规约、异常日志规约、MySQL规约、工程规约、安全规约等,这是近万名阿里Java技术精英的经验总结,并经历了多次大规模一线实战检验及完善。这是阿里回馈给Java社区的一份礼物,希望能够帮助企业开发团队在Java开发上更高效、容错、有协作性,提高代码质量,降低项目维护成本。

另外,《作者谈《阿里巴巴Java开发手册(规约)》背后的故事》一文,可以看看作者怎么说。

下载方式:详见文末 “6、历史版及最新版下载地址” !

2、价值意义

《阿里巴巴Java开发手册(规约)》的愿景是码出高效,码出质量。它结合作者的开发经验和架构历程,提炼阿里巴巴集团技术团队的集体编程经验和软件设计智慧,浓缩成为立体的编程规范和最佳实践。众所周知,现代软件行业的高速发展对开发者的综合素质要求越来越高,因为不仅是编程相关的知识点,其他维度的知识点也会影响软件的最终交付质量,比如,数据库的表结构和索引设计缺陷可能带来软件的架构缺陷或性能风险;单元测试的失位导致集成测试困难;没有鉴权的漏洞代码易被黑客攻击等。所以,本手册以开发者为中心视角,划分为编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约七个维度,每个条目下有相应的扩展解释和说明,正例和反例,全面、立体、形象地帮助到开发者的成长和团队代码规约文化的形成。

从严格意义上讲,《阿里巴巴Java开发手册(规约)》超越了Java语言本身,明确作为一名合格开发者应该具备的基本素质,因此本手册适合计算机相关行业的管理者和研发人员、高等院校的计算机专业师生、求职者等阅读,希望成为大家如良师益友般的工作手册、工具字典。

3、最新动态

关于泰山版(v1.6.0):

此版发布于2020年04月22日,此版升级内容包括:

1)发布错误码统一解决方案,详细参考手册的“附表 3”。

2)新增 34 条新规约。如:日期时间的闰年、闰月问题,三目运算的自动拆箱,SQL查询的表别名限定,Collectors 类的 toMap()方法使用注意等。

3)修改描述 90 处。如:阻塞等待锁、建表的小数类型等。

4)完善若干处示例。如:ISNULL 的示例等

4、主要作者

杨冠宝: 

杨冠宝:花名孤尽,取自《笑傲江湖》中风清扬的“独孤九剑,破尽天下武功”之意,是《阿里巴巴Java开发手册》的主要作者。在阿里巴巴集团历任研发、架构师、技术主管等不同的角色,承担过双11、国际化、代码中心等大型项目,有着丰富的一线编程经验,目前是研发协同平台Aone代码中心负责人。乐于分享与总结,在阿里巴巴集团内部大型分享多达30余次,不懈地追求技术创新,勇于挑战技术难度,在大数据、高并发、研发效能领域均有较深的造诣。

2016年3月,孤尽带领约码项目组编写《阿里巴巴Java开发手册(规约)》,码出高效,码出质量,推动阿里系与业界一起进步,让代码变得更舒服,更清澈,更好维护。

5、部分内容截图预览

 
 
 

6、历史版及最新版下载地址

请从此下载:阿里技术结晶:阿里巴巴Java开发手册-v1.6.0-泰山版》[附件下载]

posted @ 2020-04-23 11:44 Jack Jiang 阅读(1044) | 评论 (0)编辑 收藏

本文原始内容由爱奇艺技术产品团队原创分享,本次有修订和改动。

1、引言

由于移动网络的复杂性特点,编写高质量、体验好的具备网络通信能力的移动端应用(尤其是即时通讯这类网络质量高度敏感的应用)有很大的挑战性。

我们平时看到的移动网络主要有如下三个典型特点:

1)移动状态网络信号不稳定,高时延、易抖动丢包、通道狭窄;

2)移动状态网络接入类型和接入点变化频繁;

3)移动状态用户使用高频化、碎片化、非WIFI流量敏感。

(▲ 上述文字,引用自《移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”》)

正是由于上述特点,移动端应用在进行网络数据通信时会面临各种复杂多变的问题。

无论后面的技术有多复杂,但对于普通用户使用APP来说,能顺畅的完成网络请求,是理所当然的事。换句话说,APP网络请求成功率,重要性直接体现在它能直接决定APP服务的可用性,直接影响到数据通信、视频播放、广告展现、支付便捷等服务质量。

本文将以爱奇艺的iOS端APP为例,分享对移动网络请求成功率优化方面的技术实践之路。

本文将同时发布于“即时通讯技术圈”公众号,欢迎关注:

(本文已同步发布于:http://www.52im.net/thread-2981-1-1.html

2、相关文章

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”》(* 必读好文

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等

美图App的移动端DNS优化实践:HTTPS请求耗时减小近半

百度APP移动端网络深度优化实践分享(一):DNS优化篇

百度APP移动端网络深度优化实践分享(二):网络连接优化篇

百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇

3、导致移动端网络请求失败的因素

想要优化移动端网络请求成功率,先来了解移动端网络请求全链条可能导致请求失败的环节有哪些。

这些环节往往由以下两类因素导致:

 
 

第一类:不可改善因素:

1)iOS系统对APP的网络访问权限控制、飞行模式或者无网络连接。检测和识别这三种情况,通过适当方式提示用户;

2)路由器故障。

第二类:可以改善因素:

1)蜂窝/Wifi信号的强弱、连接拥堵的假连接状态;

2)DNS故障(比如DNS劫持等);

3)运营商局部节点故障;

4)自有运营负载均衡故障;

5)业务服务器故障:HTTP响应错误,对应APM的HTTP响应错误率;

6)业务逻辑错误:监控子类解析结果,对应APM的解析错误率监控。

对于不可改善因素:目前只能通过网络诊断识别出故障类型,引导用户手动去授权访问网络或者连接可用网络。

其中,如果是路由器故障,可以引导用户重启路由器或者切换4G。通过爱奇艺APP的数据监控,大致可以看到用户无网连接的时长占比有3.8%左右,这说明提供好的无网提示变得十分重要,而从用户使用蜂窝信号的弱信号(0格和1格信号)时长占比有9%左右时长,也可以看出移动端网络环境的复杂性。

 
 

针对可以改善的因素,解决方法可大致分为三类:

1)网络层错误,对应因素1到4。主要体现为超时报错;

2)HTTP响应错误,对应因素5。HTTP状态码为400及以上;

3)解析错误,对应因素6。由基线网络库定义的重载接口进行监控。

为了提高网络请求成功率,首先需要建立监控体系,从而使得基线网络库能够通过网络统计模块向APM投递各种维度的网络请求数据。有了APM的数据统计后,才能有效的发现导致端上网络失败的原因,进而解决问题。

除此之外,由于端上网络请求数据巨大,存储空间的限制使得APM只能采样2%的用户,因此针对重点业务的网络请求(比如首页)则进行了全量采集,从而对成功率的优化实现更客观全面的评估。

4、在基线网络库这一层针对不同业务提供不同的补偿思路

在优化之前,通过APM的归类分析可以得出:请求失败的主要报错是超时(-1001)的占比达到九成,与此同时SSL错误,DNS解析错误占比紧随其后。根据这一数据统计,重试成为最主要的请求成功率优化的措施。

经过不断探索和实践总结,基线网络库针对不同业务需求提供了四种不同的重试手段。

1)IP直连重试,通过配置直连IP数来控制重试次数:

Scheme不变,Host改为直接使用IP(消除域名解析风险)。由于此举需要各个业务线自己提供直连的IP,目前接入的业务主要是登录等强制要求HTTPS连接的业务。

2)超级管道重试,可以配置1~3次重试:

公司自研基于HTTP的网关代理服务(类似于远程charles代理)。Host改为代理IP(消除域名解析风险),Scheme改为HTTP(消除SSL风险,h2降级为HTTP1.1)。由于该措施需要付出流量成本,目前接入的业务都是关键核心业务,比如首页等。

3)HTTP重试,可以配置1~3次重试:

Scheme修改为HTTP(消除SSL风险,h2降级为HTTP1.1),其他不变。鉴于其为普惠性重试手段,目前接入非关键核心的一般业务。

4)原url重试,可以配置1~3次重试:

Scheme和host等都不变,通常意义上理解的重试,单纯的再请求一次。此举目前不是推荐重试手段,由业务方自主决定。

 
 

除了单个重试手段可以重试多次,基础网络库也支持多种重试手段的组合,四种重试手段的优先次序为:IP直连重试 > 超级管道重试 > HTTP重试 > 原URL重试。扣除无网情况,首页推荐页CARD接口成功率通过组合重试在2020第一季度末达到了99.76%。

 

5、其它影响移动端网络请求成功率的因素

除了重试,还有以下因素对网络请求成功率有直接影响。

1)HTTP/2 vs HTTP/1.1:推荐的请求策略是首次请求走H2,当失败重试时走HTTP/1.1:

HTTP/2对HTTP/1.1最大改进是共用一个TCP连接(详见《从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路》),其在网络顺畅时,为HTTP/2带来了速度上的优势。但当网络变坏时,TCP包的绝对顺序编号会导致一个包的丢失而堵住后面所有的请求。这样单TCP连接反而扩大了拥堵,增大了请求失败的可能性。

NSURLSession是HTTP协议自适应的,不能控制请求使用HTTP/2或者HTTP/1.1。不过由于业界事实上的标准要求HTTP/2必须是HTTPs的,这样通过将URL Scheme改为HTTP可以间接降级到HTTP/1.1。

2)适当的超时设置是一个重要影响因素:

NSURLSession的超时实际上是TCP的包间超时,并不是整体请求耗时的超时。

 

推荐的超时设置策略是:首次请求的超时可以小一点,而重试的超时应该大一些。

3)接口请求过于密集并发可能降低请求成功率:

比如播放记录的upload接口在加上多次重试后,成功率仍然只有98.2%。APM监控此接口在IPv4环境失败率只有0.47%,而IPv6失败率高达7.07%。通过端上优化请求策略,降低接口的并发密度后,IPv6环境和IPv4环境同时提高到99.85%的成功率。

4)接口数据体积越小,请求成功率越高:

HTTP/2和HTTP/1.1都是基于TCP连接的,接口数据体积越小,需要传输的TCP包越少,传输失败的概率也就降低了。目前爱奇艺APP正在从gzip转向压缩率更高的br(指的是Brotli压缩算法,详见:《启用 Brotli 压缩算法,对比 Gzip 压缩 CDN 流量再减少 20%)。

6、提高鲁棒性并防止故障的优化措施

在经过各种优化措施提高网络成功率后,我们还通过下面几个措施成功的防止线上故障造成的成功率瞬时下降,提高了网络请求的鲁棒性。

1)超级管道本身的鲁棒性:

下面案例显示使用了超级管道重试的接口错误率只有3.95%,而没有使用超级管道重试的接口错误率高达28.96%。这个案例的时间点还没有使用异地容灾IP,在叠加异地容灾IP之后,错误率曲线几乎可以抹平。

 
 

2)HTTP重试和原URL重试在v4v6双栈环境下,优先IPv4:

由于IPv6仍在建设中,有些接口在IPv6的表现弱于IPv4,那么可以指定重试走IPv4。

3)TLS1.3– 1RTT的节省:

TLS1.3将SSL握手2个RTT降为1个RTT,降低了SSL握手失败的概率。iOS12.2开始,NSURLSession支持TLS1.3。只需要服务器升级支持TLS1.3即可,端上无须改动。

4)IP复合连接竞速:

使用TCP连接测速,目的是剔除坏IP,选择最优IP,从而提高请求的成功概率。

经上述措施的持续优化,爱奇艺APP在2020Q1末,扣除无网情况后,业务成功率达到了99.7%,而网络层成功率达到了99.77%。

▲ 业务成功率 = 网络层成功率+HTTP响应成功率+解析成功率

在完成优化后,爱奇艺APP基础网络库的构成如下:

 

如上图所示,基础网络库各模板的功能作用如下:

1)统一网络库:提供一个网络接口层,所有业务接口都对接使用网络接口层;

2)统一网络库:提供一个网络封装层,对接了iOS系统网络层NSURLSession、ASIHTTPRequest(基于CFNetwork)、和公司自研的长连接网关;

3)网络统计模块:将从业务调用开始到回调给业务方的各个环节的耗时及状态值,变成统计数据,上传到APM汇合;

4)网络诊断模块:对关键业务进行诊断,包括dns解析,ping,tcpconnect,trace等工具对具体IP进行分析,分析结果上传到APM汇合;

5)弱网检测模块:通过借鉴Facebook的弱网检测是基于网速拟合的网络等级分级,分为网络情况非常差(2G或者无网)、网络情况较差(3G)、网络情况一般、网络情况较好、网络情况非常好五个等级;

6)HTTPDNS模块:有效的解决了运营商劫持问题;

7)超级管道重试:基于HTTP的网关代理,具有异地容灾代理能力;

8)ipv4/ipv6模块:识别端上是ipv4 only环境、v4/v6双栈还是ipv6 only环境;

9)复合连接模块:可以在server IP缓存池选出最佳IP,手段包括目标IP连接竞速,IP历史请求统计数据排序;

10)网络日志模块:记录了最近发生的失败网络请求详细数据和网络诊断数据。随反馈一并提交,可以便捷的排查线上网络问题。

7、未来的目标与可能的优化措施

为了持续优化网络成功率,下一步目标是扣除无网情况,重点业务成功率达到99.9%。后续考虑的优化措施如下。

1)Multipath:

当Wifi假连接的时可以走蜂窝流量,iOS 7开始支持Multipath特性(详见:《揭开 iOS 7 之 Multipath TCP 的面纱》)。

2)QUIC:

QUIC是基于UDP的,由于运营商对UDP有针对性的丢包,实测QUIC并没有体现出优势。然而,考虑到libcurl在2019已提供完整QUIC能力,NSURLSession不久也会支持QUIC。随着运营商对UDP包的干扰减少,QUIC的优势将得到体现。

如果对QUIC协议感兴趣,可以读一读下面这些文章:

网络编程懒人入门(十):一泡尿的时间,快速读懂QUIC协议

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

让互联网更快:新一代QUIC协议在腾讯的技术实践分享

七牛云技术分享:使用QUIC协议实现实时视频直播0卡顿!

3)智能调度并发:

更精准更灵敏的弱网识别,弱网下对关键核心业务进行倾斜。

4)HTTPDNS的push能力:

HTTPDNS打通APM的质量监控体系后,通过push及时下线故障IP。

关于移动端DNS问题上的优化,业内已经有了很多总结,有兴趣可以深入研究:

全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等

美图App的移动端DNS优化实践:HTTPS请求耗时减小近半

百度APP移动端网络深度优化实践分享(一):DNS优化篇

移动端网络优化之HTTP请求的DNS优化

附录:更多网络通信方面的技术资料

TCP/IP详解 - 第11章·UDP:用户数据报协议

TCP/IP详解 - 第17章·TCP:传输控制协议

TCP/IP详解 - 第18章·TCP连接的建立与终止

TCP/IP详解 - 第21章·TCP的超时与重传

技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)

通俗易懂-深入理解TCP协议(上):理论基础

通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理

理论经典:TCP协议的3次握手与4次挥手过程详解

理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程

计算机网络通讯协议关系图(中文珍藏版)

UDP中一个包的大小最大能多大?

P2P技术详解(一):NAT详解——详细原理、P2P简介

P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解(基本原理篇)

P2P技术详解(三):P2P中的NAT穿越(打洞)方案详解(进阶分析篇)

P2P技术详解(四):P2P技术之STUN、TURN、ICE详解

通俗易懂:快速理解P2P技术中的NAT穿透原理

高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少

高性能网络编程(二):上一个10年,著名的C10K并发连接问题

高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了

高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索

高性能网络编程(五):一文读懂高性能网络编程中的I/O模型

高性能网络编程(六):一文读懂高性能网络编程中的线程模型

Java的BIO和NIO很难懂?用代码实践给你看,再不懂我转行!

不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)

不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)

不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT

不为人知的网络编程(四):深入研究分析TCP的异常关闭

不为人知的网络编程(五):UDP的连接性和负载均衡

不为人知的网络编程(六):深入地理解UDP协议并用好它

不为人知的网络编程(七):如何让不可靠的UDP变的可靠?

不为人知的网络编程(八):从数据传输层深度解密HTTP

不为人知的网络编程(九):理论联系实际,全方位深入理解DNS

网络编程懒人入门(一):快速理解网络通信协议(上篇)

网络编程懒人入门(二):快速理解网络通信协议(下篇)

网络编程懒人入门(三):快速理解TCP协议一篇就够

网络编程懒人入门(四):快速理解TCP和UDP的差异

网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势

网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门

网络编程懒人入门(七):深入浅出,全面理解HTTP协议

网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接

网络编程懒人入门(九):通俗讲解,有了IP地址,为何还要用MAC地址?

网络编程懒人入门(十):一泡尿的时间,快速读懂QUIC协议

网络编程懒人入门(十一):一文读懂什么是IPv6

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

让互联网更快:新一代QUIC协议在腾讯的技术实践分享

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

聊聊iOS中网络编程长连接的那些事

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

IPv6技术详解:基本概念、应用现状、技术实践(上篇)

IPv6技术详解:基本概念、应用现状、技术实践(下篇)

从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手

脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?

脑残式网络编程入门(三):HTTP协议必知必会的一些知识

脑残式网络编程入门(四):快速理解HTTP/2的服务器推送(Server Push)

脑残式网络编程入门(五):每天都在用的Ping命令,它到底是什么?

脑残式网络编程入门(六):什么是公网IP和内网IP?NAT转换又是什么鬼?

脑残式网络编程入门(七):面视必备,史上最通俗计算机网络分层详解

脑残式网络编程入门(八):你真的了解127.0.0.1和0.0.0.0的区别?

以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

迈向高阶:优秀Android程序员必知必会的网络基础

全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等

美图App的移动端DNS优化实践:HTTPS请求耗时减小近半

Android程序员必知必会的网络通信传输层协议——UDP和TCP

IM开发者的零基础通信技术入门(一):通信交换技术的百年发展史(上)

IM开发者的零基础通信技术入门(二):通信交换技术的百年发展史(下)

IM开发者的零基础通信技术入门(三):国人通信方式的百年变迁

IM开发者的零基础通信技术入门(四):手机的演进,史上最全移动终端发展史

IM开发者的零基础通信技术入门(五):1G到5G,30年移动通信技术演进史

IM开发者的零基础通信技术入门(六):移动终端的接头人——“基站”技术

IM开发者的零基础通信技术入门(七):移动终端的千里马——“电磁波”

IM开发者的零基础通信技术入门(八):零基础,史上最强“天线”原理扫盲

IM开发者的零基础通信技术入门(九):无线通信网络的中枢——“核心网”

IM开发者的零基础通信技术入门(十):零基础,史上最强5G技术扫盲

IM开发者的零基础通信技术入门(十一):为什么WiFi信号差?一文即懂!

IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!

IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!

IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!

IM开发者的零基础通信技术入门(十五):理解定位技术,一篇就够

百度APP移动端网络深度优化实践分享(一):DNS优化篇

百度APP移动端网络深度优化实践分享(二):网络连接优化篇

百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇

技术大牛陈硕的分享:由浅入深,网络编程学习经验干货总结

可能会搞砸你的面试:你知道一个TCP连接上能发起多少个HTTP请求吗?

知乎技术分享:知乎千万级并发的高性能长连接网关技术实践

5G时代已经到来,TCP/IP老矣,尚能饭否?

爱奇艺移动网络优化实践分享:网络请求成功率优化篇(iOS端)

>> 更多同类文章 ……

欢迎关注我的“即时通讯技术圈”公众号:

(本文已同步发布于:http://www.52im.net/thread-2981-1-1.html

posted @ 2020-04-21 14:20 Jack Jiang 阅读(323) | 评论 (0)编辑 收藏

本文同时发布于“即时通讯技术圈”公众号,链接是:https://mp.weixin.qq.com/s/cS5xB2DrjF52rmz6EGVJ6A

本文参考了公众号鲜枣课堂的“IPv6,到底是什么?”一文的部分内容,感谢原作者。

1、引言

现在IPv6的技术应用已经越来越普及了,很多应用都开始支持IPv6。

 

▲ 去年开始,支付宝的官网上就已出现“支持IPv6”标识

对于即时通讯技术(尤其是IM应用)的开发者来说,新产品上架苹果的App Store因IPv6问题被拒的情况,很常见。每次也都能根据网上的资料一一解决,并顺利通过审核。

然而几次下来,到底什么是IPv6,还是有点云里雾里。

那么,IP协议在TCP/IP体系中到底有多重要?看看下图便知(原因清晰版:从此处进入下载)。

 

▲ 红圈处就是IP协议,它几乎是整个TCP/IP协议簇的支撑(图引用自《计算机网络通讯协议关系图》)

总之,IP协议在TCP/IP体系中,是非常重要的一环(可以认为,没它,也就没有了互联网),作为IPv4的下一代协议,了解IPv6非常有必要。而作为即时通讯开发者来说,了解IPv6就显的尤为迫切,说不定某天你的IM就会因为IPv6问题而导致无法通信的局面出现。

本文将用浅显易懂的文字,带你了解到底什么是IPv6。

(本文同步发布于:http://www.52im.net/thread-2979-1-1.html

2、系列文章

本文是系列文章中的第11篇,本系列文章的大纲如下:

网络编程懒人入门(一):快速理解网络通信协议(上篇)

网络编程懒人入门(二):快速理解网络通信协议(下篇)

网络编程懒人入门(三):快速理解TCP协议一篇就够

网络编程懒人入门(四):快速理解TCP和UDP的差异

网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势

网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门

网络编程懒人入门(七):深入浅出,全面理解HTTP协议

网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接

网络编程懒人入门(九):通俗讲解,有了IP地址,为何还要用MAC地址?

网络编程懒人入门(十):一泡尿的时间,快速读懂QUIC协议

网络编程懒人入门(十一):一文读懂什么是IPv6》(本文)

3、复习一下什么是IPv4?

IPv4是Internet Protocol version 4的缩写,中文翻译为互联网通信协议第四版,通常简称为网际协议版本4。

IPv4使用32位(4字节)地址,因此地址空间中只有 4,294,967,296(即2^32) 个地址。

IPv4地址可被写作任何表示一个32位整数值的形式,但为了方便人类阅读和分析,它通常被写作点分十进制的形式,即四个字节被分开用十进制写出,中间用点分隔。

通常IPv4地址的地址格式为 nnn.nnn.nnn.nnn,就像下面这样:

172.16.254.1

下图看起来更清晰一些:

4、IPv6又是什么?

IPv6是Internet Protocol version 6的缩写,中文翻译为互联网通信协议(TCP/IP协议)第6版,通常简称为网际协议版6。IPv6具有比IPv4大得多的编码地址空间,用它来取代IPv4主要是为了解决IPv4地址枯竭问题,同时它也在其他方面对于IPv4有许多改进。

其实,IPv6并不是新技术,从IPv6最早的工作组成立1992年到现在,已过去27年。在互联网技术的发展历程中,IPv6年龄甚至有些太大了。

IPv6的“6”表示的是TCP/IP协议的第六个版本,IPv4的“4”表示的是TCP/IP协议的第四个版本。其实除了这两个版本,当然还有其它版本,TCP/IP协议其实从IPv1开始,到现在IPv10都已经出现了,这些不同版本之间并没有关联,也不是简单IP地址长度的长短。

IPv6地址由八组、每组四位16进制数字组成,每组之间由":"来分隔。

看个简单的例子:

2610:00f8:0c34:67f9:0200:83ff:fe94:4c36,每个“:”前后都是4位16进制的数字,共分隔成8组。

如下图所示: 

 

小知识:如何查看手机或者电脑的网络是否支持IPv6呢?

可以在你手机或者电脑上的浏览器中打开:Ipv6-test.com,就像下图这样: 

5、为什么要使用IPv6?

最主要的原因,就是地址数量不够用了。

IPv4迄今为止已经使用了30多年。最早期的时候,互联网只是设计给美国军方用的,根本没有考虑到它会变得如此庞大,成为全球网络。

尤其是进入21世纪后,随着计算机和智能手机的迅速普及,互联网开始爆发性发展,越来越多的上网设备出现,越来越多的人开始连接互联网。这就意味着,需要越来越多的IP地址。

IPv4的地址总数是2的32次方,也就是约42.9亿个。而全球的网民总数早已超过这个数目。

 

所以说,IPv4地址池接近枯竭,根本无法满足互联网发展的需要。人们迫切需要更高版本的IP协议,更大数量的IP地址池。(有点像固定电话号码升位。)

6、IPv6会带给我们什么?

首先,最重要的一点,就是前面所说的地址池扩容。IPv4的地址池是约42.9亿,IPv6能达到多少呢?

数量如下:

340282366920938463463374607431768211456个…

不用数了,太多了… 简单说,是2的128次方。

这个数量,即使是给地球上每一颗沙子都分配一个IP,也是妥妥够用的。

 

▲ 这图你看懂了吗?嗯,我也没看懂,反正就是很多的样子

这个数量值是怎么得来的呢?还是它的地址位长决定的。

如果以二进制来写,IPv6的地址是128位。不过,这样写显然不太方便(一行都写不下)。所以,通常用十六进制来写,也就缩短成32位(32位会分为8组,每组4位)。 

下面就是一个标准、合法的IPv6地址示例:

2001:0db8:85a3:08d3:1319:8a2e:0370:7344

注意:IPv6的地址是可以简写的,每项数字前导的0可以省略。

例如,下面这个地址:

2001:0DB8:02de:0000:0000:0000:0000:0e13

粉红的“0”就可以省略,变成:

2001: DB8:2de:0:0:0:0:e13

如果有一组或连续几组都是0,那么可以简写成“::”,也就是:

2001: DB8:2de::e13

注意:一个IPv6地址,只能有一个“::”。

为什么?很简单,你看下面这四个地址,如果所有0全都缩写,会变成什么样?

2001:0000:0000:0000:0000:25de:0000:cade

2001: 0000: 0000:0000:25de:0000:0000:cade

2001: 0000: 0000:25de:0000:0000:0000:cade

2001: 0000: 25de:0000:0000:0000:0000:cade

是的,都是2001::25de::cade,冲突了。所以,这个地址是非法的,不允许存在的。

关于IPv6还有很多技术细节,因篇幅原因,不再赘述。

除了地址数量之外,IPv6还有很多优点,例如:

1)IPv6使用更小的路由表。使得路由器转发数据包的速度更快;

2)IPv6增加了增强的组播支持以及对流的控制,对多媒体应用很有利,对服务质量(QoS)控制也很有利;

3)IPv6加入了对自动配置的支持。这是对DHCP协议的改进和扩展,使得网络(尤其是局域网)的管理更加方便和快捷;

4)IPv6具有更高的安全性。用户可以对网络层的数据进行加密并对IP报文进行校验,极大地增强了网络的安全性;

5)IPv6具有更好的扩容能力。如果新的技术或应用需要时,IPV6允许协议进行扩充;

6)IPv6具有更好的头部格式。IPV6使用新的头部格式,就简化和加速了路由选择过程,提高了效率;

……

7、IPv6的优点这么多,为什么之前普及却这么慢?

IPv6优点这么多,为什么它问世已经20年了,还是没有完全替代IPv4呢?这里面的水就很深了。。。说白了,主要还是和利益有关。

7.1 NAT这类技术,让IPv4得以续命

如果按照本世纪初专家们的预测,我们IPv4的地址早已枯竭几万次了。但是,一直挺到现在,大家仍然还在用IPv4,对老百姓来说,并没有因为地址不够而无法上网。

这是为什么呢? 就是因为除了IPv6之外,我们还有一些技术,可以变相地缓解地址不足。

例如NAT(Network Address Translation,网络地址转换)。

NAT是什么意思?当我们在家里或公司上网时,你的电脑肯定有一个类似192.168.0.1的地址,这种地址属于私网地址,不属于公共的互联网地址。

▲ 一个典型的NAT应用场景(图自《IPv6,到底是什么?》)

每一个小的局域网,都会使用一个网段的私网地址,在与外界连接时,再变换成公网地址。这样一来,几十个或几百个电脑,都只需要一个公网地址。

甚至还可以私网套私网,NAT套NAT,一层一层套。这样一来,大大节约了公网IP地址数量。正因为如此,才让我们“续命”到了今天,不至于无法上网。

但是,NAT这种方式也有很多缺点,虽然私网地址访问互联网地址方便,但互联网地址访问私网地址就困难了。很多服务,都会受到限制,你只能通过复杂的设置才能解决,也会影响网络的处理效率。

▲ NAT内网的计算机是不能被外网直接访问的(图自《IPv6,到底是什么?》)

7.2 升级IPv6涉及运营商的利益

物以稀为贵,地址越稀缺,就越值钱。掌握地址的人,就越开心。谁开心?运营商和ISP(互联网服务提供商)。

他们就像是经销商,从上游(互联网域名与号码分配机构,即ICANN)申请到IP地址,再卖给下游用户。稀缺没关系,反正,他一定能赚取更多的差价。

如果大家去找运营商或ISP买带宽,或者租赁云服务,带公共地址的,一定比不带公共地址的贵很多很多。

除了地址可以赚钱之外,如果升级支持IPv6,对运营商和ISP来说,也意味着很大的资金投入。现在新设备基本都是支持的,但毕竟还是有一些老设备,如果在使用寿命到期之前就换,就是亏钱。

所以,运营商和ISP都没有动力去启用IPv6。 

至于设备商或手机电脑厂商,出于提前考虑,早已普遍支持了IPv6,意见并不是很大,也决定不了什么。必竟,提供基础设施服务的运营商们更强势。

8、IPv6未来会怎样

随着5G时代的到来,有了IPv6的加持,万物互联或许会成为现实。对于我等实时通信类软件的开发人员来说,某些场景下,或许再也不需要为“P2P打洞”这种事情烦恼了。 

▲ 5G+IPv6,万物互联不是梦

未来已来,你准备好了吗?

9、参考资料

[1] IPv6入门教程

[2] IPv6,到底是什么?

[3] 关于IPv6的发展史!IPv6的秘密史!

[4] 科普:一文读懂IPv6是什么?

[5] 漫话:全球IPv4地址正式耗尽?到底什么是IPv4和IPv6?

附录:更多网络编程基础知识文章

TCP/IP详解 - 第11章·UDP:用户数据报协议

TCP/IP详解 - 第17章·TCP:传输控制协议

TCP/IP详解 - 第18章·TCP连接的建立与终止

TCP/IP详解 - 第21章·TCP的超时与重传

技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)

通俗易懂-深入理解TCP协议(上):理论基础

通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理

理论经典:TCP协议的3次握手与4次挥手过程详解

理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程

计算机网络通讯协议关系图(中文珍藏版)

UDP中一个包的大小最大能多大?

P2P技术详解(一):NAT详解——详细原理、P2P简介

P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解(基本原理篇)

P2P技术详解(三):P2P中的NAT穿越(打洞)方案详解(进阶分析篇)

P2P技术详解(四):P2P技术之STUN、TURN、ICE详解

通俗易懂:快速理解P2P技术中的NAT穿透原理

高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少

高性能网络编程(二):上一个10年,著名的C10K并发连接问题

高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了

高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索

高性能网络编程(五):一文读懂高性能网络编程中的I/O模型

高性能网络编程(六):一文读懂高性能网络编程中的线程模型

Java的BIO和NIO很难懂?用代码实践给你看,再不懂我转行!

不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)

不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)

不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT

不为人知的网络编程(四):深入研究分析TCP的异常关闭

不为人知的网络编程(五):UDP的连接性和负载均衡

不为人知的网络编程(六):深入地理解UDP协议并用好它

不为人知的网络编程(七):如何让不可靠的UDP变的可靠?

不为人知的网络编程(八):从数据传输层深度解密HTTP

不为人知的网络编程(九):理论联系实际,全方位深入理解DNS

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

让互联网更快:新一代QUIC协议在腾讯的技术实践分享

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

聊聊iOS中网络编程长连接的那些事

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

IPv6技术详解:基本概念、应用现状、技术实践(上篇)

IPv6技术详解:基本概念、应用现状、技术实践(下篇)

从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手

脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?

脑残式网络编程入门(三):HTTP协议必知必会的一些知识

脑残式网络编程入门(四):快速理解HTTP/2的服务器推送(Server Push)

脑残式网络编程入门(五):每天都在用的Ping命令,它到底是什么?

脑残式网络编程入门(六):什么是公网IP和内网IP?NAT转换又是什么鬼?

脑残式网络编程入门(七):面视必备,史上最通俗计算机网络分层详解

脑残式网络编程入门(八):你真的了解127.0.0.1和0.0.0.0的区别?

以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

迈向高阶:优秀Android程序员必知必会的网络基础

全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等

美图App的移动端DNS优化实践:HTTPS请求耗时减小近半

Android程序员必知必会的网络通信传输层协议——UDP和TCP

IM开发者的零基础通信技术入门(一):通信交换技术的百年发展史(上)

IM开发者的零基础通信技术入门(二):通信交换技术的百年发展史(下)

IM开发者的零基础通信技术入门(三):国人通信方式的百年变迁

IM开发者的零基础通信技术入门(四):手机的演进,史上最全移动终端发展史

IM开发者的零基础通信技术入门(五):1G到5G,30年移动通信技术演进史

IM开发者的零基础通信技术入门(六):移动终端的接头人——“基站”技术

IM开发者的零基础通信技术入门(七):移动终端的千里马——“电磁波”

IM开发者的零基础通信技术入门(八):零基础,史上最强“天线”原理扫盲

IM开发者的零基础通信技术入门(九):无线通信网络的中枢——“核心网”

IM开发者的零基础通信技术入门(十):零基础,史上最强5G技术扫盲

IM开发者的零基础通信技术入门(十一):为什么WiFi信号差?一文即懂!

IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!

IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!

IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!

IM开发者的零基础通信技术入门(十五):理解定位技术,一篇就够

百度APP移动端网络深度优化实践分享(一):DNS优化篇

百度APP移动端网络深度优化实践分享(二):网络连接优化篇

百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇

技术大牛陈硕的分享:由浅入深,网络编程学习经验干货总结

可能会搞砸你的面试:你知道一个TCP连接上能发起多少个HTTP请求吗?

知乎技术分享:知乎千万级并发的高性能长连接网关技术实践

5G时代已经到来,TCP/IP老矣,尚能饭否?

>> 更多同类文章 ……

欢迎关注我的“即时通讯技术圈”公众号: 

(本文同步发布于:http://www.52im.net/thread-2979-1-1.html

posted @ 2020-04-17 11:21 Jack Jiang 阅读(402) | 评论 (0)编辑 收藏

本文已同时发布于我的“即时通讯技术圈”公众号。

1、引言

哈罗,大家好,我是Jack Jiang。。。(一股浓浓的自媒体视频旁白味道)。

对于经常看我文章的即时通讯开发者来说,今天要讨论的这个话题,貌似有点不着边际。

是的,自从我整理完《IM开发者的零基础通信技术入门》系列文章之后,对于网络编程的理解,开始有点飘了。

言归正传。现在,5G技术离我们的生活越来越近了,号称网络延迟1ms、下行速度10Gb/s的5G,在这样逆天的网络性能指标下,老骥伏枥的TCP/IP是否仍能Hold的住?带着这个思考,便有了本文的内容。

 

▲ 5G网速有多快?看图感受一下(图自《零基础,史上最强5G技术扫盲》)

(本文已同步发布于:http://www.52im.net/thread-2976-1-1.html

2、学好TCP/IP够用吗?

对于即时通讯技术的开发者,从技术栈来说,一条最普通的聊天消息的送达,肯定要涉及到网络编程技术,而网络编程最核心的也就是TCP/IP协议(准确的说是TCP/IP协议簇,见《TCP/IP详解》),毫无疑问深入的学习TCP/IP协议肯定是非常有必要了。

基本上,对于普通的IM或消息推送系统开发来说,对TCP/IP相关的计算机网络基础比较熟悉的话,完全够用了。

 

▲ 这本书很多人都读过

3、移动网络问题,只能赖我代码烂?

亲手写过即时通讯的网络通信层的同学都很清楚,在移动网络中(我说的移动网络具体指的是运营商的2g/3g/4g/5g这些),因为无线通信的介质和技术实现特殊性,出现了很多传统有线互联网不曾有过的网络通信问题。

就拿IM在移动弱网中出现的各种问题来说,多数开发者都不自信的认为这应该是自已的网络层代码写的不够优秀,是的,很多时候也确实是这样。

我收集整理的下面这几篇资料,就讨论的是这些,有兴趣可以读一下:

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇

微信移动端应对弱网络情况的探索和实践PPT [附件下载]

YY直播在移动弱网环境下的深度优化实践分享(视频+PPT)[附件下载]

其实,很少有人会去思考,在TCP/IP协议被发明出来的50年后,对于现代的移动网络来说,是否仍然能工作的好?以弱网问题为例,难道我写的IM总是丢消息、掉线就仅仅是“我”的代码太烂? 

没错,这不仅仅是应用层的代码编写问题,它或许涉及到TCP/IP的设计局限,甚至移动网络的底层设计也并不是最完美的。

下面这两篇文章,对于弱网问题思考,已经深入到运营商的通信技术这一层,强烈建议读一读:

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

如果你的认知,已经开始对底层的网络通信技术有所困惑,下面这几篇就是为你准备的:

IM开发者的零基础通信技术入门(六):移动终端的接头人——“基站”技术

IM开发者的零基础通信技术入门(七):移动终端的千里马——“电磁波”

IM开发者的零基础通信技术入门(八):零基础,史上最强“天线”原理扫盲

IM开发者的零基础通信技术入门(九):无线通信网络的中枢——“核心网”

IM开发者的零基础通信技术入门(十):零基础,史上最强5G技术扫盲

IM开发者的零基础通信技术入门(十一):为什么WiFi信号差?一文即懂!

IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!

IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!

IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!

4、简单复习一下TCP/IP

从字面意义上讲,有人可能会认为 TCP/IP 是指 TCP 和 IP 两种协议。实际生活当中有时也确实就是指这两种协议。

然而在很多情况下,它只是利用 IP 进行通信时所必须用到的协议簇的统称。

具体来说,IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都属于 TCP/IP 协议。他们与 TCP 或 IP 的关系紧密,是互联网必不可少的组成部分。TCP/IP 一词泛指这些协议,因此,有时也称 TCP/IP 为网际协议簇。

互联网进行通信时,需要相应的网络协议,TCP/IP 原本就是为使用互联网而开发制定的协议簇。因此,互联网的协议就是 TCP/IP,TCP/IP 就是互联网的协议。 

▲ 上图反映了TCP/IP协议族的关系(图片引用自《计算机网络通讯协议关系图》)

5、TCP/IP或许太老了

对于现代移动网络来说,TCP/IP或许太老了。我们简单了解一下TCP/IP协议的产生过程。

1973年:卡恩与瑟夫开发出了TCP/IP协议中最核心的两个协议:TCP协议和IP协议。

1974年:卡恩与瑟夫正式发表了TCP/IP协议并对其进行了详细的说明。同时,为了验证TCP/IP协议的可用性,使一个数据包由一端发出,在经过近10万km的旅程后到达服务端。在这次传输中,数据包没有丢失一个字节,这充分说明了TCP/IP协议的成功。

1983年:TCP/IP协议正式替代NCP,从此以后TCP/IP成为大部分因特网共同遵守的一种网络规则。

1984年:TCP/IP协议得到美国国防部的肯定,成为多数计算机共同遵守的一个标准。 

是的,你没有看错,TCP/IP协议设计于距今50年前!

 

▲ 罗伯特·卡恩(左者)与文特·瑟夫(右者)(图片引用自《技术往事:改变世界的TCP/IP协议》)

6、TCP/IP原本是为固定网络设计的

虽然TCP/IP自上世纪70年代发明以来,连接了无数的计算机,推动了互联网的蓬勃发展。

但不可回避的现实是,基于TCP/IP的互联网,它的初衷是为固定网络和网络互连而设计,而今天我们已经发展到了移动互联时代。

再往后看,未来5G将面临AR/VR、超高清视频、物联网、车联网等各种应用、用例纷呈,加之网络安全的紧迫性越发凸显,TCP/IP或许难以适应未来。

7、TCP/IP或许并不适合移动网络

7.1 TCP/IP设计之初无法预见高速移动网时代

在TCP/IP刚被设计的年代,即传统固定互联网的公元元年,主机是固定的,用于编址的IP也是固定的,世界是平的。

可是随着应用程序以及芯片技术的活力涌现,设备越来越小,App越来越丰富,当你觉得浑身憋得慌的时候,移动互联网时代来了。

但传统的TCP/IP并不适合移动网络,以TCP/IP协议簇中我们最常用的TCP协议来说,传统的TCP基于TCP/IP协议头字段的五元组,而标识设备的IP地址仅仅标识了设备位置,并没有标识设备本身(实际上不管到了什么年代,IP地址都不应该标识设备本身,它就是标识位置的!问题是,TCP不应该用一个标识位置的元素来标识设备)。

而对于移动互联网来说,一旦移动设备(比如智能手机)换了位置(通信基站切换了),其IP地址也会改变,进而既有的TCP连接将全部中断。

 

▲ 运营商的基站是有覆盖范围的,而且覆盖范围并不大

对于底层的移动网络通信技术有所了解的开发人员或许知道,手机的通信是由基站进行代理的,而基站是固定的。换句话说,当你移动到下一个基站的位置时,手机就得自动切换到新的基站,进而重新进行一系列的跟运营商的无线体系进行连接建立的过程。

这在日常生活中使用并没有什么问题,但在时速达到350公里每小时的复兴号高铁上用手机上网时,这就会导致严重的问题。因为基站的信号覆盖范围有限,在手机移动速度如此之快的情况下,基站的切换也将频繁到让网络工程师们崩溃(有兴趣可以读一下《IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!》)。

TCP/IP和网络的关系,可以作个有趣的类比。

假设互联网是公路,那么TCP/IP这就是这条公路上的一套交通规则。这套规则在制定时,可能考虑到的只是普通的市场内道路(最多是高速公路使用),而现在的5G时代,就好比时速350公里的高速铁路,试想普通的市内交通规则套用在高速铁路上,那难道不算是灾难吗。

必竟普通的市内交通速度不会很快,各种规则的制定误差和余量可以比较大,但高速铁路上,速度飞快、交通信号控制精确无比的情况下,这套规则,对于开高铁的司机来说,肯定是胆颤心惊。而TCP/IP对于5G来说,就好比这套老的交通规则,用它来驾驭这么快速的5G快车,是不是很疯狂?

 

7.2 TCP/IP与电信网的基因不同

基于TCP/IP的互联网原本是为固定网络和网络互联设计,而运营商的移动网络是为移动性连接而生。互联网的连接是分布式的,而移动通信网络是集中控制的。

这两者的技术基因确实有很大不同,在早期移动网络网络性能较慢的情况下,这两者的结合,矛盾似乎并不突出。

实际上,在传统电信网(就是大家最常用的电话、短信网络)与IT互联网是两拨人各自有玩耍(电信网为代表的就是3GPP标准化组织,互联网为代表的就是IETF标准化组织)。

在那个移动网还不发达的年代,这两拨人各自玩各自的,大家谁也不用鸟谁。

随着人们对移动上网需求越来越旺盛,搞电信网的这拨人只能想办法接入传统的互联网,必竟在当时传统互联网太强势,而移动网的应用场景还在摸索阶段,为了能快速解决移动上网的问题,与是也不好麻烦IETF这拨人,所有痛苦默默承受——虽然TCP/IP在移动网上的实施并不合适,但只能想办法缝缝补补,把移动网的标准制定,往它上面靠。

这就好比,TCP/IP这辆车已经造好了,至于你搞移动网的人,是修一条普通马路(2G)、还是一条高速公司路(3G)、或者是现在的高速铁路(5G),反正你只能将就这辆车。原本应该是什么路上跑什么车,而现在是不管你什么路,只能跑这辆车。反正车子跑不好,不怪车子,怪路。。

好奇葩的逻辑,而这个逻辑就好比是现在的TCP/IP跟移动网的关系。

所以,在5G,甚至未来的6G、7G时代,这种“勉强”的结合,抛必带来网络低效、基础设施成本高昂等问题。

8、移动运营商们已经意识到问题

是的,大佬们已经意识到了问题的严重性,正在着手解决。

2020年4月初,欧洲电信标准协会(ETSI)已成立了一个新的行业规范工作组“Non-IP Networking”(ISG NIN),以解决新服务、尤其是5G服务面临的老式网络协议所存在的问题。

▲ 详细新闻内容《点此查看

该工作组的目标是为5G网络研究开发新的网络协议,以替代TCP/IP。

是的,这些移动运营商已经发现在4G、甚至5G网络中使用的基于TCP/IP的技术存在一些问题。

由于TCP/IP协议最初是为互联网设计,而非为移动通信网络而生,当移动通信网络引入TCP/IP后,增加了移动性、安全性、QoS等功能,这使得网络更复杂,频谱使用效率较低。为了解决这些问题,后续的修补和替代方案又导致了成本、时延和功耗增加。

大佬们终于承认,对于5G的某些高级服务,TCP/IP确实被认为不是最佳的。

9、移动网络未来会怎样?

虽然TCP/IP可能越来越难以适应移动网络的发展,但不可否认,短期内TCP/IP的不可替代性。

必竟,基于TCP/IP的传统互联网所构建的软件和硬件世界(尤其是硬件)并不是一朝一夕的事,而替换掉这些,无论是从成本还是各方利益来说,都是个需要反复权衡和博弈的事。

一个很好的例子是,IPv4和IPv6,虽然谁都知道IPv4的困境,但IPv6喊了这么多年目前想要普及,仍然还比较遥远,要知道IPv6已经喊了10年了。因为这小小的IP地址,牵涉的是互联网从硬到软几乎所有环节,影响之大,无出其右。

对于IM开发者来说,因为移动网络的特殊性,而技术改朝换代也并不鲜见。

比如众所周之的XMPP协议,设计之初也是野心勃勃——“要让上IM就像打开网页一样简单!”。确实,XMPP无论是肉眼可读性,还是数据结构的优雅,都非常优秀,但悲剧的是,设计者们从来没有想过移动网会发展成今天这样,或者说设计者们从未考虑过XMPP在移动网下的使用。于是,后面的故事,大家都很清楚——每个人都在抱怨XMPP臃肿、冗余(是的,这里我收集了一大堆这样的文章),这算个是把优点做成缺点的典型案例了。

或许,未来会有那么一天,移动网络终有属于为自已定制的网络协议标准。而对于搞网络通信的程序员来说,如果这套新的标准让能基于移动网络的代码编写,变的愉快起来,那真是谢天谢地了!

10、参考资料

[1] TCP/IP 已完 ?New IP 之后,又来一个 Non-IP

[2] 5G:再见,TCP/IP

[3] 重新设计TCP/IP协议栈以支持设备移动性

[4] 5G要抛弃TCP/IP?

[5] ETSI LAUNCHES NEW GROUP ON NON-IP NETWORKING ADDRESSING 5G NEW SERVICES

附录:更多网络编程基础资料

TCP/IP详解 - 第11章·UDP:用户数据报协议

TCP/IP详解 - 第17章·TCP:传输控制协议

TCP/IP详解 - 第18章·TCP连接的建立与终止

TCP/IP详解 - 第21章·TCP的超时与重传

技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)

通俗易懂-深入理解TCP协议(上):理论基础

通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理

理论经典:TCP协议的3次握手与4次挥手过程详解

理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程

计算机网络通讯协议关系图(中文珍藏版)

UDP中一个包的大小最大能多大?

P2P技术详解(一):NAT详解——详细原理、P2P简介

P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解(基本原理篇)

P2P技术详解(三):P2P中的NAT穿越(打洞)方案详解(进阶分析篇)

P2P技术详解(四):P2P技术之STUN、TURN、ICE详解

通俗易懂:快速理解P2P技术中的NAT穿透原理

高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少

高性能网络编程(二):上一个10年,著名的C10K并发连接问题

高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了

高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索

高性能网络编程(五):一文读懂高性能网络编程中的I/O模型

高性能网络编程(六):一文读懂高性能网络编程中的线程模型

Java的BIO和NIO很难懂?用代码实践给你看,再不懂我转行!

不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)

不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)

不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT

不为人知的网络编程(四):深入研究分析TCP的异常关闭

不为人知的网络编程(五):UDP的连接性和负载均衡

不为人知的网络编程(六):深入地理解UDP协议并用好它

不为人知的网络编程(七):如何让不可靠的UDP变的可靠?

不为人知的网络编程(八):从数据传输层深度解密HTTP

不为人知的网络编程(九):理论联系实际,全方位深入理解DNS

网络编程懒人入门(一):快速理解网络通信协议(上篇)

网络编程懒人入门(二):快速理解网络通信协议(下篇)

网络编程懒人入门(三):快速理解TCP协议一篇就够

网络编程懒人入门(四):快速理解TCP和UDP的差异

网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势

网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门

网络编程懒人入门(七):深入浅出,全面理解HTTP协议

网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接

网络编程懒人入门(九):通俗讲解,有了IP地址,为何还要用MAC地址?

网络编程懒人入门(十):一泡尿的时间,快速读懂QUIC协议

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

让互联网更快:新一代QUIC协议在腾讯的技术实践分享

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

聊聊iOS中网络编程长连接的那些事

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

IPv6技术详解:基本概念、应用现状、技术实践(上篇)

IPv6技术详解:基本概念、应用现状、技术实践(下篇)

从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手

脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?

脑残式网络编程入门(三):HTTP协议必知必会的一些知识

脑残式网络编程入门(四):快速理解HTTP/2的服务器推送(Server Push)

脑残式网络编程入门(五):每天都在用的Ping命令,它到底是什么?

脑残式网络编程入门(六):什么是公网IP和内网IP?NAT转换又是什么鬼?

脑残式网络编程入门(七):面视必备,史上最通俗计算机网络分层详解

脑残式网络编程入门(八):你真的了解127.0.0.1和0.0.0.0的区别?

以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

迈向高阶:优秀Android程序员必知必会的网络基础

全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等

美图App的移动端DNS优化实践:HTTPS请求耗时减小近半

Android程序员必知必会的网络通信传输层协议——UDP和TCP

IM开发者的零基础通信技术入门(一):通信交换技术的百年发展史(上)

IM开发者的零基础通信技术入门(二):通信交换技术的百年发展史(下)

IM开发者的零基础通信技术入门(三):国人通信方式的百年变迁

IM开发者的零基础通信技术入门(四):手机的演进,史上最全移动终端发展史

IM开发者的零基础通信技术入门(五):1G到5G,30年移动通信技术演进史

IM开发者的零基础通信技术入门(六):移动终端的接头人——“基站”技术

IM开发者的零基础通信技术入门(七):移动终端的千里马——“电磁波”

IM开发者的零基础通信技术入门(八):零基础,史上最强“天线”原理扫盲

IM开发者的零基础通信技术入门(九):无线通信网络的中枢——“核心网”

IM开发者的零基础通信技术入门(十):零基础,史上最强5G技术扫盲

IM开发者的零基础通信技术入门(十一):为什么WiFi信号差?一文即懂!

IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!

IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!

IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!

IM开发者的零基础通信技术入门(十五):理解定位技术,一篇就够

百度APP移动端网络深度优化实践分享(一):DNS优化篇

百度APP移动端网络深度优化实践分享(二):网络连接优化篇

百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇

技术大牛陈硕的分享:由浅入深,网络编程学习经验干货总结

可能会搞砸你的面试:你知道一个TCP连接上能发起多少个HTTP请求吗?

知乎技术分享:知乎千万级并发的高性能长连接网关技术实践

5G时代已经到来,TCP/IP老矣,尚能饭否?

>> 更多同类文章 ……

欢迎关注我的“即时通讯技术圈”公众号: 

(本文已同步发布于:http://www.52im.net/thread-2976-1-1.html

posted @ 2020-04-13 23:41 Jack Jiang 阅读(500) | 评论 (0)编辑 收藏

仅列出标题
共51页: First 上一页 29 30 31 32 33 34 35 36 37 下一页 Last 
Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang