【最全资料汇总】如何12个月内成为数据科学家?

RoyalMail数据科学家Freddie Odukomaiya曾经用12个月的时间让自己成功的成为数据科学家,以下是他的经验分享和他所使用的学习资源。 以下内容译自:https://blog.usejournal.com/how-to-become-a-data-scientist-in-12-months-71aa9ee822d9 想成为数据科学家,以下8点非常重要 选择一种编程语言,坚持下去。 不要不断改变你选择的语言。如果这样做,你的进度将大大减慢。 明确你的动机。 这很重要,因为学习数据科学很难,所以在过程中很容易失去动力。如果你的动力清晰而强大,那么就更容易忍受和坚持。 不要迷失在课程中。 如果你只是不断的在学习教程,你很容易陷入一种自我欺骗“我知道自己在干什么”。最好的方法是在项目中学习。找一个你感兴趣的项目,把数据科学应用其中,比如,我的项目是预测英超联赛的冠军。 精准选择小部分资源。 现在有太多学习数据科学基础知识的资源。一个普遍的现象是,大家很难坚持使用一个资源学习,很多人使用一个资源开始学习,看到了一个更好的资源后立即就更换了学习资源,这样成本是非常高的,要尽量避免这种情况。相反,我们应该选择一组涵盖不同主题的资源(例如,construct a curriculum),坚持下去,知道你完成他们 让自己沉浸在社区中。 你需要让数据科学包围自己。可以通过以下几种方式:订阅DS简报,阅读数据科学文章和书籍,收听数据科学播客,在youtube上观看数据科学讲座,通过参加所有和任何数据科学活动,利用Meetup和Eventbrite等网站。查找在线DS社区并加入他们。 去黑客马拉松! 不要等到你“准备好”再去参加黑客马拉松,参加黑客马拉松的好处远远超过你认为你会经历的任何负面影响。黑客马拉松也可以在线参与,例如,Kaggle本质上就是一个永无止境的在线黑客马拉松。 寻找导师。 这对我来说是最困难的部分,因为我对导师的定义有些许误解。导师只是一位经验丰富且值得信赖的老师/辅导员。你可以拥有多个导师,甚至可能无法直接与他们互动。我最终的导师其实是哪些有影响力的数据科学家,我通过社交媒体关注他们,订阅他们的新闻通讯,阅读他们的书籍和听他们的谈话/播客。当我觉得我需要建议时,我通过电子邮件和社交媒体与他们联系,虽然不是每个人都回复了我,但那些确实帮助了我很多。 准备好牺牲你工作日的晚上和周末。 你必须投入大量的精修勤练,花费大量时间学习,你的社交生活会受到影响。努力工作很重要,但聪明地工作更有价值,请你准备一份时间表,关于你正在学习的课程,正在阅读的书籍以及正在开展的项目。 最全学习资源汇总 充分利用这些信息资源才能更好的学习数据科学哦。 【课程】 开源数据科学大师  - @clarecorthell制作了涵盖数据科学所有不同方面的课程,并附有相关课程,书籍等的链接。 Class Central  - 这是谷歌的在线课程。您可以通过简介和用户评分找到与任何主题相关的在线课程。 DataCamp  - 一家通过互动在线课程教授数据科学的EdTech公司。 【实践】 Kaggle  - Kaggle是预测建模和分析竞赛的平台。 #100DaysOfCode  - 这是一个挑战,初学者尝试每天至少编码一个小时,持续100天。 Codewars  - 通过与其他人一起训练真实代码的挑战来提高您的技能。 DrivenData  - DrivenData让众包成为世上最大的社会挑战和组织之一。 HackerRank  - 练习编码。参与竞争。找工作。 【书籍】 Machine Learning with Python Cookbook by Chris Albon An Introduction to Statistical Learning: with Applications in R Hands-On Machine Learning with Scikit-Learn and TensorFlow by Aurélien Géron Think Stats: Exploratory Data Analysis by by Allen B. Downey The Signal and the Noise: The Art and Science of Prediction by Nate Silver Prediction Machines: The Simple Economics of Artificial Intelligence How to Lie with Statistics by Darrell Huff Automate the Boring Stuff with Python by Al Sweigart 【通讯/博客】 Data Elixir — Data Elixir每周二会发送到您的收件箱,其中包含从网络上挑选的数据科学内容。 Data Science Roundup - 互联网上最有用的数据科学文章。由Tristan Handy策划。 FiveThirtyEight  - Nate Silver使用统计分析来解决政治和体育问题的热门博客。 Variance Explained  - David Robinson的数据科学博客,DataCamp的首席数据科学家,这是一家通过互动在线课程教授数据科学的EdTech公司。 Flowing Data  - FlowingData探索统计学家,设计师,数据科学家和其他人如何使用分析、可视化和探索去理解数据和我们自己。 The Pudding  -  The Pudding通过视觉论文解释了文化中争论的观点 Datacamp  - 帮助您成为数据科学家的数据科学博客。 Kaggle Blog  - Kaggle.com的官方博客 Machine Learning Mastery  - 即使你是从0开始,也可以在真实应用程序中使用它来掌握机器学习。 Chris Albon  - 流行的Machine Learning Flashcards背后的数据科学家和Machine Learning with Python Cookbook的作者。 KD Nuggets  - KDnuggets™是业务分析,大数据,数据挖掘,数据科学和机器学习的领先站点。 Analytics Vidhya  - 了解有关Data Analytics的所有信息。 【播客】 Linear Digressions  - 在每一集中,主持人通过有趣的应用程序探索机器学习和数据科学。 Partially Derivative  - 日常生活中每天的数据,由Data Science超级极客主持。 Data Skeptic  - 介绍与数据科学,机器学习,统计和人工智能相关的主题的访谈和教育讨论。 This Week In Machine Learning and Artificial Intelligence- 迎合热爱机器学习的观众和AI爱好者。 Software Engineering Daily  - 关于软件主题的技术访谈。 DataFramed  - 通过DataCamp,专注于探索数据科学可以解决的问题。 Talking Machines  - 机器学习正在改变我们可以提出的问题,我们探索如何提出最佳问题以及如何解决问题。 Becoming A Data Scientist Podcast  - 访问数据科学家,了解他们成功的方法。 AI in Industry- 每周Dan Faggella都会采访Top AI和ML高管,投资者和研究人员。 【Youtube频道】 3Blue1Brown  - 到目前为止最好的数学教程频道。以可视方式解释复杂概念。 Brandon Foltz  - 我第二喜欢的数学频道,主要侧重于从初级到高级教学统计。 Computerphile  - 关于计算机和计算机的视频。 PyData  - PyData为数据分析工具的用户和开发人员的国际社区提供了一个论坛,分享想法,相互学习。 Sentdex  - Youtuber和程序员会提供高质量的数据科学教程。 Siraj Raval  - 与Sentdex类似,可生成有趣且信息丰富的数据科学内容。 两分钟论文  - 在2分钟内解释最新的数据科学研究论文。 Enthought  - 从SciPy等流行的数据科学会议中寻找精彩的对话和讨论。 【大家要关注】 @BecomingDataSci  - HelioCampus的数据科学家Renee Teate和流行的Becoming A Data Scientist网站和播客的创建者。 @drob  - 大卫罗宾逊,DataCamp的首席数据科学家,Tidytext软件包和O'Reilly的书籍Text Mining with R的共同作者。 @chrisalbon  - Chris Albon,流行的Machine Learning Flashcards背后的数据科学家和Machine Learning with Python Cookbook的作者。 @frankchn  - Frank Chen,Google Brain的软件工程师,负责TensorFlow。 @fchollet  - Francois Chollet,Google的深度学习。神经网络库Keras的创造者。“Deep Learning with Python”的作者。 @goodfellow_ian  -Ian Goodfellow,Google脑研究科学家,领导一个研究人工智能对抗技术的团队。Deep Learning Book的主要作者。 @jakevdp  - Jake VanderPlas,华盛顿大学电子科学研究所数据科学家。访问Google的研究员; Python Data Science Handbook的作者。 @dataandme  - 来自Rstudio的Tidyverse Dev Advocate的Mera Averick。 @math_rachel  - Rachel Thomas,Fast.ai的联合创始人和旧金山大学教授。 【在线社区】 Python for Data Science FreeCodeCamp Data Science Room Reddit's Data Science Subreddit Kaggle’s online forum #100DaysOfCode  - #100DaysOfCode Challenge参与者的Slack频道。 Stack Overflow  - 全球最大的开发者社区。   数据科学的学习是一个永无止境的过程,有了方法和学习资源最重要的一定还是坚持。 享受学习,享受知识,享受进步,大家加油鸭!!     想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03

5分钟学会Java9-Java11的七大新特性

现在Java有多元化的发展趋势,既有JS又有C++还有C#的影子,不学习那是不行滴。 来来来,花5分钟看看Java9-Java11的七大新特性,还有代码样例。 Java11 发布了,然而很多公司还在用Java 8 ,这里简单介绍一下 Java 9 -11 引入的新语法和API。 本地变量类型推断 Java 10 就已经引入了新关键词var,该关键词可以在声明局部变量的时候替换类型信息。本地(local)是指方法内的变量声明。 Java 10之前,你需要这样声明一个String对象。 在Java10里头可以使用var替代String,表达式变成这样: 用var声明的变量仍然是静态类型的。 不兼容的类型无法重新分配给此类变量。 此代码段无法编译: 当编译器无法推断出正确的变量类型时,也不允许使用var。 以下所有代码示例都会导致编译器错误: 局部变量类型推断可以泛型。 在下一个示例中,Map <String,List <Integer >>类型,可以将其简化为单个var关键字,从而避免大量样板代码: 从Java 11开始,lambda参数也允许使用var关键字: HTTP Client Java 9开始引入HttpClient API来处理HTTP请求。 从Java 11开始,这个API正式进入标准库包(http://java.net)。 让我们来探索一下我们可以用这个API做些什么。 新的HttpClient可以同步或异步使用。 同步请求会阻止当前线程。 BodyHandlers定义响应体的预期类型(例如,字符串,字节数组或文件): 也可以使用异步来执行相同的请求。 调用sendAsync不会阻止当前线程,而是返回CompletableFuture来进行异步操作。 我们可以省略.GET(),因为它是默认的请求方法。 下一个示例通过POST将数据发送到给定的URL。 与BodyHandler类似,您使用BodyPublishers定义作为请求主体发送的数据类型,如字符串,字节数组,文件或输入流: 最后一个例子演示了如何通过BASIC-AUTH执行授权: Collections List,Set和Map等集合已经用新方法扩展。 List.of从给定的参数创建了一个新的不可变列表。 List.copyOf创建列表的不可变副本。 因为list已经是不可变的,所以实际上不需要实际创建list实例的副本,因此list和副本是相同的实例。 但是,如果你复制一个可变list,那么复制确实会生成一个新实例,因此保证在改变原始list时没有副作用: 创建不可变map时,您不必自己创建map条目,而是将键和值作为参数传递: Java 11中的不可变集合仍然使用Collection API中的老接口。 但是,如果尝试修改不可变集合,则会抛出java.lang.UnsupportedOperationException。 可喜的是,如果尝试改变不可变集合,Intellij IDEA会通过发出警告 Streams Streams是在Java 8中引入的,Java 9增加了三个新方法。 单个参数构造方法: 增加 takeWhile 和 dropWhile 方法,用于从stream中释放元素: 如果对Stream不熟,可以参考这篇文章[1]。 Optionals Optionals提供了一些非常方便的功能,例如 您现在可以简单地将Optional转换为Stream,或者为空Optinal提供另一个Optional作为备胎: Strings Java11 给String增加了一些辅助方法来修剪或检查空格等功能: InputStreams InputStream增加了transferTo方法,可以用来将数据直接传输到 OutputStream: 其他的一些VM特性 从Java 8 到 Java 11引入了很多新特性,以下是这些特性的列表: Flow API for reactive programming Java Module System Application Class Data Sharing Dynamic Class-File Constants Java REPL (JShell) Flight Recorder Unicode 10 G1: Full Parallel Garbage Collector ZGC: Scalable Low-Latency Garbage Collector Epsilon: No-Op Garbage Collector Deprecate the Nashorn JavaScript Engine 译者注:对于译者来说还是Application Class-Data Sharing(CDS),ZGC和Flight Recorder比较有吸引力一点。关于ZGC,可以参考前段时间高可用架构关于ZGC的文章。   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-19

三年深入探索,网易云信让在线医疗做到技术“在线”

在线医疗的模式已相伴人们走过多年。近期,国家卫健委和国家中医药管理局颁布的《远程医疗服务管理规范(试行)》等一系列政策使在线医疗再次受到关注。同时 ,作为共同探索“互联网+医疗”的技术品牌代表,网易云信在过往三年间,以自身扎实的IM和音视频技术为在线医疗的创新赋能,也在亲历着技术带给这一行业的变化。   几经沉浮  在线医疗一直处在特别的“风口·浪尖” 当下,快节奏与高压力导致的人群健康问题日益突出,加之人口老龄化等因素的影响,医疗行业供给侧的短板难以应对需求端的增长。线下医疗除了资源分配不均衡的问题,公立医院的就医体验一直被患者所诟病。不可否认的是,在线医疗模式打破了医疗资源的空间局限,在缓解看病难,提升医患沟通体验,以及帮助优质医疗资源优化分配等方面,能够起到一定的积极作用。正是看到了巨大的供给侧缺口以及在线医疗的正向价值,从2014年开始,BAT以及众多的机构纷纷通过资本运作布局,在线医疗成为新的“风口”。 另一方面,在线医疗之路走的颇有一些“路漫漫其修远兮”的意味。每一次的热度都将它推上“浪尖”。在线医疗不只是面临着监管、患者信任、盈利模式等方面的考验,技术门槛高、产品上线慢 、模式突破难,也使得在线医疗一直游走于线下医疗的边缘。幸运的是,第三方云服务模式和机构的介入,正在加速这一领域的创新步伐,让在线医疗的探索可以“轻装上阵”,甚至小步快跑起来。   拒绝浮躁  可靠的云服务让行业未来可期 每个行业的革新和转型都不是一朝一夕的,尤其是对于医疗行业,涉及民生健康大业,国家和百姓关注度高,需要去除资本表面的浮华,踏实走好每一步。对于在线医疗产品本身,尤其是远程问诊类平台而言,社交和视频通话功能已是刚需。其中,稳定可靠的架构、流畅的视频通话、安全的存储等要求都是此类产品的核心诉求,需要专业团队针对性地打磨技术,并将服务细致化。只有资源和技术同时“在线”,才能让概念落地,让行业未来可期。 作为国内领先的即时通讯与音视频技术厂商,网易云信体察到在线医疗领域对音视频技术的迫切需求,持续探索将PaaS云服务模式与在线医疗场景深度结合,为其提供稳定可靠且性能卓越的IM和音视频的底层技术支持。首先,拥有亿级架构能力的网易云信IM云可以承载高并发、高实时的信息点对点、多对多传输。视频云可承载多种方式视频流媒体的传输和海量分发,满足了在线医疗场景中的沟通这一核心诉求。其次,针对医疗服务的特殊性要求,网易云信实现了包括多终端访问、文档共享、自定义消息、语音识别等丰富功能,并且可提供弱网优化等策略的针对调整,还有足够强大且安全的数据库保护患者隐私并保证问诊全过程可追溯,以满足合规的硬性要求。   携手并进  网易云信三年深入探索在线医疗 和缓医疗专注于慢性病及康复管理,可同时覆盖B端和C端。通过接入网易云信的云服务,和缓视频医生App具备了强大的即时通讯与音视频能力。视频通话的同时,医生可通过接收患者上传的化验单图片,查看患者病历记录来辅助诊断。诊疗全程进行音视频混录,确保过程的可监控和可追溯。网易云信团队提供的解决方案不仅理顺了诊疗流程,也让医患双方均获得了高于面诊的使用体验。 图:和缓视频医生移动端界面   乐普医疗集团旗下的乐普心脑血管网络医院联合了国内知名三甲医院的专家资源,以互联网的方式提供在线问诊、慢病随访、健康咨询等服务,让患者不出社区也能看上知名专家。网易云信帮助乐普网络医院实现了以北京为坐诊中心,覆盖全国的远程视频看诊。鉴于偏远地区网络信号差的状况,技术团队通过部署全球节点优化通讯传输质量,提供了抗800ms的网络抖动和抗30%网络丢包技术优化。 图:乐普网络医院解决方案流程架构   快速问医生是一款医疗健康手机应用,患者通过手机可快速咨询全国各地有资质的专业医生。依托于网易云信的PaaS服务,产品实现了点对点在线健康咨询,群聊互动交流功能,以及自定义消息的医生评价等功能。此外,依托于网易云信的语音识别技术,大片段的语音识别减少了用户靠文本输入进行沟通的不便,成为了该软件的一大功能卖点。 图:快速问医生移动端界面   最后,一组数据表明,网易云信已为超过120家医疗机构提供相应的技术服务,使医生工作效率提高150%、患者看病时间减少70%。网易云信相信,在线医疗是有价值的探索。以精益求精的态度和扎实的技术能力让在线医疗的优势落到实处,进而助力这个利国利民行业的长足发展,是作为技术赋能者的使命与价值所在。   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-19

谈谈接入各种第三方推送平台的技术方案和一点经验

在移动互联网时代,为了运营好一个APP,消息推送是一个优质廉价的渠道。消息推送的使用场景简单来说,可以包括运营类的消息推送,如活动推广期间的推送等,还包括通知类的消息推送,如社交场景中的新消息提醒等。 对于APP来说,消息推送能够起到内容告知、提高日活,甚至召回用户的作用。那么如何接入第三方推送平台呢?本篇文章中,网易云信资深研发工程师将和大家聊聊接入各种第三方推送平台的技术方案,分享接入推送平台的一些实用经验。   如何接入第三方推送 推送的一般流程 推送是一种服务器主动push消息到设备端的行为,因此依赖于设备端和服务器的长连接。整体的架构和流程如下: 具体如下: 设备和推送服务器建立长连接 设备会根据某些规则生成或从推送服务器获取到一个DeviceToken,推送服务器可以根据DeviceToken定位到具体的设备 设备会上报DeviceToken到应用服务器(由应用自己完成) 应用服务器根据需要调用推送的服务端接口发起推送 推送服务器收到推送请求,根据请求中的DeviceToken定位到具体的设备,下发推送通知 设备收到推送消息,可以进行通知栏弹窗或者其他行为 IOS 苹果官方提供了APNS推送,有很高的推送送达率。早先的APNS推送提供了一套基于TCP协议的接口,但是该接口使用方式比较复杂,稍有不慎就会导致推送失败,但调用方还误以为推送成功。 后来苹果又提供了一套新的基于HTTP2协议的接口,新接口的一个好处是可以追踪到每个推送请求是被APNS服务器拒绝了还是成功了,再也不用去猜请求到底是被苹果服务器给丢了还是接受了。 安卓 谷歌官方最早提供了GCM推送,后来又推出了FCM推送来代替GCM,但由于国内的环境不适合使用,因此各个手机厂商又相继推出了各自的推送,推送的原理都是类似的,都是依赖于设备和推送服务器的长连接,但是厂商推送的优势在于这样的长连接可以和自己的手机系统绑定到一起,从而可以不同应用共享同一条长连接,节省了心跳的流量消耗,并且这样的系统级长连接可以不用担心应用被杀导致的应用内长连接断连导致消息推送不可达。 目前已经推出厂商推送的包括小米、华为、魅族、OPPO等,FCM也可以算安装了谷歌服务的设备的系统级推送。 不同于IOS,安卓阵营的推送服务器接口都是HTTPS接口,并且通过SecretKey的方式来进行安全校验。   一点经验 DeviceToken的管理 我们知道DeviceToken标识了一台具体的设备,但是推送服务本身是不知道应用本身的账号体系的,因此同一个APP,假设注销了A账号,改用B账号登录,此时DeviceToken一般来说是没有变化的,此时应用服务器需要去标识A账号的该设备属于注销状态,不然一条针对A账号的推送消息就会被B账号收到。 应用被卸载的情况 应用被卸载的时候(这时候登录的A账号),应用本身感知不到,此时针对A账号的该设备的推送还是会发出去,推送服务器收到推送消息,找不到对应的设备,此时没有问题,只是会消耗一些资源。假设此时设备上的应用又重新安装了,然后登录了另一个账号B,假设DeviceToken没有变化,此时针对A账号的推送将会被B账号收到。上面这种情况出现的前提条件是DeviceToken没有发生变化,测试发现华为推送存在这个问题(经过询问华为推送技术支持,2018年3月之后的设备不存在该问题),其他推送没有。为了解决这个问题,服务器必须自己管理DeviceToken-用户账号的映射关系,并在发现有DeviceToken冲突的情况下去把老的账号设置为注销状态。 IM场景下推送时机问题 IM场景下,应用服务器有自己长连接服务,此时第三方推送服务的作用是利用第三方厂商推送的系统级长连接来提高消息推送的送达率。 首先对于IOS端,应用无法常驻后台,我们会在应用切换前后台的时候通过IM长连接发送一个标记位,服务器会在设备离线或者处于后台的情况下触发APNS推送,从而减少设备在前台情况下APNS推送的流量消耗。 而对于安卓端,服务器会在设备处于离线的情况下触发第三方推送,否则会走IM长连接下发通知,当设备处于后台但还活着的时候,会在收到消息之后主动弹窗以便提醒用户有新消息。对于安卓端还有一个场景是这样的,安卓端在后台的某个时刻进程死了,此时过来一条需要推送的消息,服务器发现设备处于离线状态,尝试调用第三方推送(可能有也可能没有)。过了一会进程自己活回来了,重新连接到了IM服务器,拿到了未读消息,此时一般的逻辑下,进程会主动弹窗告知有消息到达,造成设备端的通知栏有两条推送。为了解决这个问题,需要IM服务器在设备重连的时候下发未读消息是否需要弹窗的信息。   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-19

浅谈实时音视频直播中直接影响用户体验的几项关键技术指标

前言 这两年互联网领域的一个热门关键词就是实时音视频直播,从刚开始的游戏直播和秀场娱乐开始,实时音视频直播带来了远超传统互动的用户体验,现在实时音视频直播已逐渐深入当今主流的互联网应用形态里。 本文将聊一聊实时音视频直播的几个关键技术: 清晰度: 4K、1080p、720p,这些概念被各大电视机厂商炒作了这么多年,已经地球人都懂了。4K在互联网视频直播里现在还不普及,主要是对网络数据传输要求太高了。1080p在一些对清晰度要求较高的场景如游戏直播里已经慢慢普及,要求的数据传输速率大约在4Mbps左右。720p是现在直播的主流清晰度,速率大约在1Mbps左右。在一些要求不太高的领域,还会有540p或者360p出现。 流畅度: 如果在直播时出现卡顿、转圈,就意味着不流畅。主播和观众的连接通道好比一根水管,流量是有限的,因此如果清晰度提升意味着观众收看直播的流畅度有可能会下降。 延时: 视频直播都是讲求互动性的,如果跟秀场妹妹聊天,讲了半天都没反应就略坑爹了。但是延时也不全是坏处,适当的延迟意味着在观众端能够有一定的视频流数据缓存,当出现网络不稳定时能够抵御小范围波动而使得观众无感知。 首屏时间: 当观众进入直播间算起,到出现第一个主播画面的时间叫做首屏时间。为了保证直播流畅,会缓存一段数据之后再开始播放,但这个也不是绝对的,后文会详细描述。 下面,我们将逐一分析和总结实时音视频直播中的这几个重要技术指标。 首屏秒开 先从观众进入直播间那一刻说起,这相当于整个直播生命周期的开始。当进入直播间后,播放器会向CDN请求数据。此时,假设主播已经发送视频流数据到了第100帧,由于数据传输的一些延时,CDN端最新收到的数据可能在第90帧。当CDN接收到拉取视频流请求时,他会做一件非常有意思的事情,即往前回溯一段数据,在图中显示的是回溯2秒钟,那就到了视频流的第五帧。CDN会把第五帧开始往后的数据,通过RTMP或其他直播协议源源不断的发送到播放器。那为什么要往回2秒钟呢,这可能算是目前视频直播技术中一个比较有特点的技术优化,能用于很好地平衡流畅度和首屏秒开时间。具体运作机制我们接下来再看。 流畅播放 接下去发生的事情,很好地可以说明回退2秒的作用。因为CDN是从第5帧开始发送数据,之后的数据全部缓存在CDN服务器中,因此可以源源不断地把数据发送到客户端,图中显示了从第5帧到50帧之间的数据,全部缓存在播放器内存中。这部分数据可以用于有效的抵抗网络波动造成的影响。当然,这样做的一个缺点是播放器相比于主播,延迟时间增加了2秒。所以说,视频直播所做的事情,就是在延时和流畅度之间找到一个很好的平衡点。 网络拥塞 网络拥塞是互联网上最常见的一个情景,接下去讨论当发生网络拥塞时发生的情景。假设当观众播放到第150帧时,用户下行网络出现问题,如果播放器没有新的数据到来,必然会画面卡住并开始转菊花。而此时,主播端并不会感知到这个事情,主播还在正常推送视频流数据。在经过了大概4秒左右的卡顿后,观众端的网络恢复,数据又会源源不断从CDN流向播放器。在图中看到网络流畅时,播放器的缓存中已经存放了第280帧数据,此时当前画面是150帧。这会产生一个什么问题?因为播放器播放数据是按照每一帧的时间戳匀速播放,因此如果不做任何优化就意味着每经过一次卡顿,直播的延迟就会增加一段时间,而增加的时间和被卡住的时间是一致的。 延时追赶 经过刚刚的描述,大家一定已经明白了延时累加是一个必须解决的问题。因此,播放器还需要做的事情就是延时追赶。播放器必须要实时侦测缓存中数据的情况,一旦大于某一阈值就启动延时追赶。追赶的方式,可以是直接扔掉多余数据也可以采用快进方式。快进模式相对来说用户体验会好一些,不会产生明显跳跃,处理时要注意声音不要因为快进而产生尖刺。最后再提一下,延时追赶不能太激进,还是应该在缓存中留一段数据,用于缓解以后可能再次发生的网络拥塞。 小结 前文描述了首屏启动、流畅播放、网络拥塞、延时追赶的基本概念和每个阶段内部所发生的事情,整个直播就在流畅、拥塞和延时追赶三个阶段中来回往复。看完本文,有兴趣读者可以尝试利用开源软件自己去写个直播APP,可以拿来练手娱乐,如果要上线还有各种其他奇葩的坑。 来源:即时通讯网 - 即时通讯开发者社区!   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-05

如何优化传输机制来实现实时音视频的超低延迟?

1、前言 要在语音视频 SDK 中实现超低延迟,实时的语音视频传输机制是必不可少的,而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石。 在语音社交、视频社交、游戏语音和互动直播等领域,关于在语音视频实时传输中实现低延迟这个议题,已经有不少的文章提出各种方案。绝大部分方案的思路都是“优化”,比如说,优化编码、推流、传输和播放等各个环节。 愚以为,要在实时语音视频传输中获得超低延迟,是不能单靠挖空心思去“优化”的,而是要依靠实时的传输机制。就像高铁和火车有着本质的区别一样,火车不管如何优化,也只是跑得更快的火车,永远达不到高铁的速度。没有一套实时的传输机制,再怎么在各个环节“优化”,也无法获得真正超低的延迟。 要实现超低延迟,信道 QoS 十分关键。首先要选择合适的网络传输协议,采用基于 UDP 的私有协议还是标准 RTMP 协议?然后根据网络环境采用合适的 QoS 技术,采用 FEC,ARQ,还是双管齐下? 如果采用 FEC 和 ARQ 双管齐下,那么一套智能的 QoS 策略就必不可少。没有任何一种 QoS 技术能解决所有问题,实时语音视频传输机制必须是多种 QoS 技术的有机结合。 2、传输层协议的选择 如果是视频直播 SDK,一般会选择 RTMP 协议,因为要能够普遍兼容 CDN 分发网络,从而向围观的广大用户进行直播。如果是音频社交 SDK、视频社交 SDK 或者游戏语音 SDK,一般会选择 RTP/RTCP 协议(或者类 RTP 的私有协议),因为不需要通过 CDN 网络向围观用户广播媒体流。是否要考虑兼容 CDN 网络,是语音视频通话 SDK 和视频直播 SDK 的重大区别。 RTMP 协议是基于 TCP 协议的,RTP 协议或者私有协议是基于 UDP 协议的,因此 RTMP 协议和 RTP 协议之争,本质就是 TCP 协议和 UDP 协议之争。 TCP 协议的特点: 1) 是通用的 IP 网络协议,不是为实时媒体传输而设计的,在弱网网络环境下延迟会增大; 2) 有内嵌的 ARQ,但没有 FEC,不允许开发者对 ARQ 策略进行控制,不能实现 FEC; 3) 不是从实时语音视频的角度进行设计的,更多考虑网络传输的公平性,内嵌的传输控制策略比较温和。 UDP 协议的特点: 1) 适合实时语音视频通讯,允许端到端全链条进行信道策略控制,在弱网环境下可控性更强; 2) 延迟时间的大小取决于丢包时候的 ARQ 和 FEC 策略,允许开发者深度控制 ARQ 和 FEC 策略; 3) 适合设计实时语音视频的通讯机制,根据网络状况自适应地选取 ARQ 和 FEC 策略,以及调整传输码率和报文的数量。 在网络环境好的情况下,只要语音视频编解码器相同,RTMP 协议和基于 UDP 的私有协议的传输效率是相当的,都可以实现低延迟、不卡顿和高品质的实时通讯效果。 在网络环境较差的情况下,特别是在跨网甚至跨国的情况下,基于 UDP 的私有协议对端到端全链条可控,包括流控码控、ARQ、FEC 和抖动缓冲等,对抗恶劣网络环境会更有保障。 3、信道保护 IP 网络是“尽力而为”地提供数据传输服务的,尽最大的可能性来发送报文,但对时延、可靠性等性能概不负责效果,传输的数据出错是避免不了的,因此对信道进行保护是必须的。 信道 QoS 技术主要包括前向纠错 FEC,丢包重传 ARQ 和混合型 ARQ。这几种算法都是成熟的技术,在最基础的算法上又衍生出多个变种,而且在实现的过程中也可以进行定制化。 在 FEC 和 ARQ 的基础上,为了更好地适应弱网环境,需要让码率自动适应网络环境的波动,这样能够更好地保障实时语音视频通话的可用性和流畅性。   ▲ 信道 QoS 的三大措施 1前向纠错 FEC FEC 全称是 Forward Error Correction,中文翻译为前向纠错,是一种通过增加冗余数据对丢失的数据包进行恢复的信道编码算法。具体地说,由发送端对原始数据进行 FEC 编码,生成冗余奇偶校验数据包,原始数据和冗余数据包合并称作 FEC 数据块,原始数据包和冗余数据包的数量比例是固定的。发送端发送 FEC 数据块。接收端接收到 FEC 数据块后,通过冗余数据包和原始数据包来恢复出丢失或者出错的数据包。 FEC 编解码算法推荐使用比较成熟的 RS(Reeds-Solomon) 算法、Raptor 算法和 Tornado 算法。使用 FEC 编码算法的时候要根据丢包率(PLR, Packet Lost Rate)来设置冗余度。 下面使用 RS 的一个例子来说明 FEC 编解码算法的使用方法。 因为在一个 FEC 数据块中,原始数据包的个数和冗余数据包的个数的比例是固定的,所以很容易根据丢包的个数和冗余包的个数来判断是否能够全部恢复丢失的数据包。RS (n, k) 表示通过 RS 算法把 k 个原始数据包进行编码,生成(n-k)个冗余数据包,总共是一个包含有 n 个数据包的 FEC 数据块。假设丢失了 m 个数据包,如果 m<=(n-k),那么 RS 算法可以完全恢复丢失的数据包;如果 m>(n-k),那么 RS 算法就无法恢复丢失的数据包,这时候就要进行发送请求要求重传丢失的数据包。 下图展示了通过 RS(6,4) 进行丢包恢复的过程。发送端有 4 个原始数据包,通过 RS 算法编码生成 2 个冗余包,形成了一个拥有 6 个数据包的 FEC 数据块。RS 算法最多能够恢复 2 个丢失的数据包。发送端把 FEC 数据块发出去,在传输过程中第 2 号原始数据包丢失了。接收端接收到 FEC 数据块以后,通过 r1 冗余包把已经丢失的第 2 号原始数据包恢复出来。 ▲ RS(6,4) 算法恢复出丢失的数据包 使用前向纠错 FEC 算法,优点是数据包只需要传输一次,传输延迟不会受到 RTT(Round Trip Time) 的影响,不会增加额外的延迟时间;缺点是需要增加冗余数据包,降低了传输信道的利用率。总的来说是一种“空间换时间”的策略。 下文将会综合对 FEC 和 ARQ 的特点进行全面对比。 2丢包重传 ARQ ARQ 全称 Automatic Repeat reQuest,中文意译为丢包重传,是一种通过重传关键数据包来纠错的信道保护算法。 具体地来说,发送端给每一个数据包都植入顺序号码和时间戳,顺序号码代表被发送数据包的顺序,允许接收端可以通过监测顺序号码来发现丢包事件;时间戳代表语音视频数据包解码的时间点。发送端发送数据包后,如果接收端没有收到,接收端将会通过 RTCP/TCP 信道发送一个重传请求。发送端维护一个缓冲队列,当收到重传请求的时候将会重传数据包。接收端也会维护一个缓冲队列,等待尚未收到的数据包以及对已经收到的数据包进行排序。在解码的 deadline 到来之前,接收端把缓冲区的数据包交给解码器进行解码。在解码 deadline 的时间点,接收端要么已经收齐了预期的数据包,要么已经决定放弃继续等待。 传统的丢包重传 ARQ 包括以下三种: 1)Stop-and-wait ARQ,也就是停止等待的 ARQ,发送端发送数据包后就停止并等待接收端的确认消息,在收到确认消息之前,信道处于空闲状态; 2)Go-Back-N ARQ, 也就是退回 N 步的 ARQ,发送端不需等待接收端的确认,不停地发送数据包,直到收到接收端的重传请求。发送端除了重传被要求重传的数据包以外,还会把该数据包时间戳后面已经被接收端成功接收到的一批数据包全部重传一遍; 3)Selective Repeat ARQ,也就是选择性重传的 ARQ,发送端不需等待接收端的确认,不停地发送数据包;接收端只会有选择性地对关键的数据包要求重传,而发送端只重传被要求重传的数据包。 第一种和第二种 ARQ 效率比较低下,第三种 ARQ 相对来说效率比较高。目前主流的丢包重传算法大部分是第三种 ARQ 的变种或者定制化版本。 选择性重传 ARQ 的优越性在于它能确定哪些关键的数据包需要重传,从而大大地提高重传的效率,降低造成重传风暴的风险。比如说,在出现花屏的时候,请求发送端立即编码视频关键帧发送过来,避免长时间花屏无法刷新的现象。选择要重传的数据包的算法十分关键,这里必须要有比较谨慎的策略,不能任何丢失的数据包都要求重传,那样就相当于又走了 TCP 协议内嵌 ARQ 模块的老路,必然引入不可控的延时。 选择性重传的 ARQ 要考虑实时性,要估算计划要重传数据包到达的时间(以 RTT 的倍数来估算),如果数据包预期的到达时间在解码的 deadline 之前,就要求重传,如果在 deadline 之后,就放弃重传。下面通过一个例子来说明选择性重传的 ARQ 这个实时策略。 下图展示了选择性重传的 ARQ 的实时策略: 1)发送端发送 #1、#2 和 #3 三个数据包,数据包 #2 丢失了; 2)N 倍 RTT<数据包 #2 解码 deadline, N=2,判断可以接受重传 2 次; 3)接收端通过 RTCP/TCP 信道请求重传; 4)发送端重传,数据包 #2 再次丢失; 5)接收端通过 RTCP/TCP 信道请求重传; 6)发送端重传,数据包 #2 成功到达; 7)接收端把 #1、#2 和 #3 三个数据包排序,交给解码器解码。 ▲ 选择性重传 ARQ 考虑 RTT 和编码 deadline 等实时因素 如果在 2 次以内能重传成功,那么就可以缩短接收端的缓冲时间,在解码 deadline 之前把数据包排序并交给解码器解码。如果在 2 次内不能重传成功,那么就放弃继续重传。因此,接收端总能维持解码的时间 t<= 解码 deadline,维持了传输的实时性。 使用选择性重传的 ARQ 算法,优点是只需要有选择性地传输关键的数据包,不会明显增加额外的带宽,带宽利用率十分高;缺点是需要请求和重传,增加了传输延迟时间。总的来说是一种“时间换空间”的策略。 下表对 FEC 和 ARQ 的特点进行综合对比。 ▲ FEC 和 ARQ 的特点对比 3码率自适应 ABC ABC 全称 Adaptive Bit-rate Control,中文意译为码率自适应,是服务端和推流端协作控制码率来自动适应网络环境变化的技术。码率自适应的目的是为了对抗弱网环境。在网络好的情况下,适当提高码率,提高语音视频的质量和降低延迟;在网络差的情况下,适当降低码率,保障语音视频通话的可用性和流畅性,适当牺牲音画质量。 码率自适应包含了带宽估算和码率控制: 1)带宽估算,服务端和推流端协作完成,推流端把网络环境统计信息上报给服务端,服务端通过带宽估算算法估计出当前带宽; 2)推流端按照估算出来的带宽进行推流,如果网络情况良好(没有检测到网络拥塞)则持续的地提高码率,试探网络带宽的上限,直到出现网络拥塞为止; 3)当网络拥塞出现的时候,推流端降低码率来保障可用性和流畅性,直到网络拥塞缓解为止; 4)当网络拥塞缓解的时候,转到 #2。 整个过程可以类比成驾驶汽车过程中控制方向盘的方法,偏左了就往右边调整一点,偏右了就往左边调整一点,来来回回的微调让驾驶处于安全和顺畅的状态。码率自适应也是一样的道理。 4错误隐藏 PLC PLC 全称 Packet Lost Concealment, 意译为错误隐藏,应用于实时语音通话的场景。语音数据包的丢失会造成语音的歪曲。为了减少语音数据包丢失造成对语音通话质量的伤害,错误隐藏 PLC 算法通过前一个语音数据包和后一个语音数据包的相关性来“推测出”当前丢失的语音数据包,从而“隐藏”了信道传输所造成的错误。错误隐藏 PLC 算法在接收端进行,不需要发送端参与。 4、智能 QoS 上面介绍了信道保护的各种 QoS 算法。没有哪一种算法能够解决所有问题,也不是把所有算法一起混着用就能实现通讯机制。如何综合使用这些算法对信道进行保护从而达到实时的效果?这里需要一套智能的 QoS 策略,既要能对抗网络损伤,又要能保持媒体数据传输的实时性。 1混合 FEC&ARQ FEC 和 ARQ 各有各的优点和缺点。FEC 虽然不会增加额外的延迟,但是会增加额外的带宽成本。ARQ 虽然算法相对简单而且几乎不增加带宽成本,但是会增加额外的延迟。因此,一般的做法是把 FEC 和 ARQ 混着通过智能的策略来使用,也就是混合型 HARQ(Hybrid ARQ)。 混合型 HARQ 的智能策略要充分考虑网络情况,也就是要根据 RTT 和 PLR 的数值来智能地决定使用 FEC 还是 ARQ,还是两者一起使用,哪个用多一点哪个用少一点? 下图是笔者和团队在工作经验中总结,仅供参考。 ▲ 即构的智能 HARQ 策略 上图中有三块区域,代表两个极端情形和一个中间情形: 1)较弱网络的极端情形:在 RTT>250ms 或者 PLR>10%, 网络延迟特别大或者丢包率特别高的情况下(蓝白色区域),不使用 ARQ 而使用 FEC,因为在延迟大或者丢包多的弱网情况下,ARQ 可能会进一步加大延迟; 2)较好网络的极端情形:在 RTT<70ms 或者 PLR<3%,网络延迟很小并且丢包率比较低的情况下(深蓝色区域),适合使用 ARQ,如果对成本不敏感,可以适当使用 FEC; 3)中间的情形:在 (RTT<=250ms 而且 PLR<=10%) 的前提下,RTT>=70ms 或者 PLR>=3% 的情况,可以根据成本和体验的考虑,智能地选择使用 FEC 和 ARQ 的权重。 语音数据可以适当地通过 PLC 来恢复,可以减低延迟时间和带宽成本。另外,由于语音数据比起视频数据小好多,与其通过 FEC 和 ARQ 复杂的算法处理,还不如在适当的网络情况下,在一定的时间间隔内发送两次同样的语音数据包,从而达到用冗余数据纠错的效果。 2带宽估算 无论是码率自适应、FEC 还是 ARQ,都要依赖带宽估算算法来工作。码率自适应根据带宽估算的结果来自动调节码率;FEC 和 ARQ 根据带宽估算的结果来分配冗余数据所占的带宽。 发送端和服务端协同对网络带宽进行检测和估算,发送端把网络带宽的统计信息上报给服务端,服务端把网络带宽的估算结果反馈给发送端。当然,也可以完全在推送端进行带宽估算。 除了带宽估算以外,网络拥塞探测对码率自适应也十分关键。比较传统的网络拥塞探测算法是根据网络丢包率来探测网络拥塞的。然而,当发生较大规模丢包的时候才提示网络拥塞,网络拥塞已经发生了,这时候才来调整码率已经太晚了。 拿地震预报举例子。如果等到发现桌子电灯摇晃的时候才“预报”说有地震,“预报”的时机太晚了。如果发现老鼠或者飞禽逃走等异常情况,或者探测到地震波,就真正做到预报地震。 现代的网络拥塞算法也是力求做到预报拥塞的效果。一般的做法是,发送端发送一些探测数据包,接收端监控数据包的延迟时间和缓冲队列长度。当探测数据包经过网络拥塞节点的时候,延迟时间会变长而且不稳定。如果发现探测数据包的延迟时间变大或者出现异常波动,或者缓冲队列变长了,那么网络拥塞很可能将要出现,相应地可以降低码率来适应网络情况的变化。另外,也有通过滤波器来进行网络拥塞预测,当滤波器的某些特征超过一定的阈值,就预示网络拥塞将要发生。 3带宽分配 码率自适应 ABC 模块估算出带宽以后,发送端把带宽分配给原始数据包、FEC 校验包和 ARQ 重传包,这里需要一个智能的带宽分配策略。带宽分配策略是根据网络情况,包括 RTT 和 PLR 等因素,来给原始数据包和冗余数据包分配带宽。冗余数据包的带宽分配得越多,QoS 信道保护算法的纠错能力就越强,然而原始数据包就相应分配得越少,语音视频的质量也就相对降低。相对而言,冗余数据包的带宽分配得越少,QoS 信道保护算法的纠错能力就越弱,然而原始数据包的带宽分配越多,语音视频的质量也就相对得到保障。因此,智能的带宽分配策略是要在语音视频的质量和 QoS 信道保护算法的纠错能力之间寻找平衡点。 一般来说,带宽分配的策略可以按照下面的方法进行: 1)总共的带宽由码率自适应 ABC 模块估算得出; 2)丢包重传 ARQ 的重传数据包所占带宽根据 RTT 和 PLR 估算得出; 3)前向纠错 FEC 的校验数据包所占带宽根据 RTT,ARQ 恢复后的 PLR,和总共的带宽估算得出; 4)原始数据包所占的带宽根据 ARQ、FEC 和总共的带宽计算得出。 下面是一个例子,展示随着 RTT 和 PLR 的增加,如何在原始数据包、ARQ 和 FEC 之间分配带宽。   ▲ 智能的带宽分配策略示例 上图中左边的坐标系中,纵坐标是带宽,横坐标是 RTT。在 RTT 比较小的网络情况下,ARQ 分配的带宽比较多,不采用 FEC;在 RTT 比较大的情况下,FEC 分配的带宽比较多,不采用 ARQ。不管使用 ARQ 还是 FEC 冗余数据包进行信道保护,原始语音视频数据所占的带宽都要适当牺牲。 上图中右边的坐标系中,纵坐标是带宽,横坐标是 PLR。在 PLR 比较小的网络情况下,ARQ 和 FEC 冗余包分配的带宽都比较小,甚至没有;在 PLR 比较大的网络情况下,逐渐给 ARQ 和 FEC 增加带宽来增强数据纠错能力,原始语音视频数据所占的带宽也相应降低。 5、本文小结 实时语音视频通话要获得超低延迟,不能仅仅依靠在各个环节不断地优化,而是要通过 FEC、ARQ 和码率自适应构建实时通讯机制。在这个基础上,还要充分考虑网络情况、实时要求和成本因素,以及需要大量经验数据的支撑(比如说,PLR 和 RTT 的关键阈值等)。要比较妥善的做到上面的要求,对语音视频技术团队绝对是一个严峻的考验。 (原文链接:有改动,https://mp.weixin.qq.com/s/ePmKVah1CbXdueHEW8n0vw) 来源:即时通讯网 - 即时通讯开发者社区!   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-05

简述实时音视频聊天中端到端加密(E2EE)的工作原理

前言 本文着重阐述端到端加密(E2EE),端到端加密是确保数据传输安全的可行方法之一。读完这篇文章,你可以了解这种加密方式的基本原理. 说到互联网的数据安全,一般用户可能认为,像端到端加密这类问题事不关己。确实,如果只是与亲朋好友聊聊家常,不涉及个人数据,那么确实不必担心消息的安全以及端到端加密问题。 但如今,通过互联网进行的数据交换包括网上银行和网上购物、发送个人文件/单据/证件的扫描版、机票信息等方方面面。因此,即使你没有在发送机密的商业数据,也仍有必要了解消息传送应用中的端到端加密原理。如果你希望避免可能存在的第三方攻击,丢失数据,那么在企业应用中支持此类功能至关重要。 什么是端到端加密? 信息安全领域的大多数专家都承认,端到端加密是确保数据交换安全的最可靠方法之一。按照这种方法,在端到端加密应用之间传送的消息只能由这些应用的用户读取,任何第三方都无法读取。通过使用唯一密钥进行数据加密和解密,可以实现此类功能。只有终端用户可以生成和存储这些密钥。 端到端加密系统旨在确保,即使不法分子得以访问传输的数据,其也无法破译数据内容。端到端加密的这项与众不同的特征还体现在所发送的消息可能存储到的服务器上。 由于服务器并不参与密钥生成过程,因此服务器所“看到”的只是在相互通信的用户间传送的加密消息。所以,即使在服务器端泄露了数据,也没有人能够读懂数据的具体内容。 我们来详细了解一下端到端加密的工作原理,以便更好地理解这种加密方式如何保证数据安全。(端到端加密技术详解请见《移动端安全通信的利器——端到端加密(E2EE)技术详解》) 端到端加密的工作原理 按照端到端加密方法,当聊天会话开始时,每个用户所使用的应用都会生成两个加密密钥。此类密钥可以使用PGP(Pretty Good Privacy,是一个基于RSA公钥加密体系的邮件加密软件)加密应用加以生成。自1991年PGP首次发布以来,至今尚无证据显示其被破解过。 1第一个密钥是公钥 端到端加密应用相互之间会交换这种密钥。 2第二个密钥是私钥 私钥并不会从设备中发送出去。利用公钥,用户只能对消息进行加密。要想解密这种经过加密的消息,按照端到端加密方法,应使用对应的私钥。 如果第三方可以获得公钥也无妨,因为公钥只能用于端到端数据加密。正因为此,你大可以通过开放的通信信道来传送公钥。 每一个端到端加密应用生成了一对密钥且应用间相互交换了公钥后,就可以开始进行安全的通信了。诸如消息、视频和音频文件等数据需要先在发送端经过端到端加密过程,然后才会发送到服务器。数据会先存储在服务器上,一直存储到接收方的应用可以接收数据为止。接收方通知服务器收到数据后,这些数据就可以从服务器中删除或者在服务器上保留一段时间。 下面我们用一个形象的比喻来帮助您理解端到端加密应用的工作原理。想象一下,有两个人在用某种外语交谈。第三个人由于不具备所需的语言能力(没有加密密钥),就无法从听到的消息中提取到任何有价值的信息。 这个概念十分简单,但却能够保证在两个或更多个终端之间能够安全地传输消息。对于现代设备来说,加密/解密过程并非难事。即使是移动应用,也能毫无困难地处理端到端加密。或许,唯一需要担心的情况是与多名用户聊天。 在这种情况下,如果您要发送一条消息,必须针对每个接收人都加密一次。参与对话的人数越多,端到端加密应用的工作量就越大。为了避免应用的处理工作可能出现延迟,开发人员需要付出一些额外的努力来确保端到端加密不会影响到用户体验。 WebRTC应用的安全标准 WebRTC是一项用来构建网上聊天应用的技术,目前正在快速流行起来。它之所以受到如此高的关注度,原因可能是:用户无需安装任何第三方插件即可使用WebRTC应用。另一个原因就是它支持端到端加密。 现代浏览器中添加了对WebRTC的支持后,它们就可以与Skype等通信软件进行竞争了。此类应用可以为用户提供他们需要的所有功能,包括消息加密。您直接从网络浏览器中就可以交换消息和进行视频通话了。 要利用对端到端加密的支持来开发基于WebRTC的软件,不需要使用任何框架。虽然这看起来很简单,但考虑到WebRTC应用所采用的安全标准,用户完全没有担心的必要。根据信道类型的不同,WebRTC应用采用DTLS(数据报传输层安全)协议或SRTP(安全实时传输协议)协议。 第一种协议用于数据流;第二种则是为媒体流而设计的。这两种安全协议可确保数据传输过程使用加密密钥进行保护。由于支持TLS/SSL标准,可以使用安全的HTTPS连接。通信双方之间采用端到端加密将可保证任何第三方都无法访问您的数据,对于企业应用来说这一点尤为重要。 本文小结 如果你关注聊天应用开发方面的趋势,就不难发现,对于用户和开发人员来说,安全问题都是让他们担心的方面。用户变得更加挑剔,而且日益关注自己所用的消息传送应用的安全程度。 开发人员为了满足用户的这些意愿,也在设法实现最为可靠、尖端的端到端加密技术来保障安全的数据传输。有了端到端加密应用,数据安全性可以达到所需的级别。E2EE最大的优势在于,即使第三方设法截获了你的消息,但没有存储在你自己设备上的密钥,他们也根本无法解密消息。 考虑到在企业中使用通信应用会涉及到与数据泄露有关的额外风险,选用端到端加密软件可能就显得至关重要。 来源:即时通讯网 - 即时通讯开发者社区!   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-05

访谈WebRTC标准之父:WebRTC的过去、现在和未来

前言 首届(WebRTC)网络实时通信大会期间,InfoQ 对 WebRTC 之父 Daniel C. Burnett 进行了专访,以下是专访实录。(注:Daniel 在访谈中的观点仅代表他本人及其在 W3C 所做的工作。) WebRTC的来历 2010年5月,Google 以6,820万美元收购 VoIP 软件开发商 Global IP Solutions 的 GIPS 引擎,将其开源并改为名为“WebRTC”。随即 WebRTC 被纳入万维网联盟的 W3C 推荐标准。2014年7月1日,WebRTC 浏览器 API 标准的1.0版由 W3C 发布。WebRTC 是一个由 Google、Mozilla和 Opera 主导的开源项目,通过在浏览器中调用简单的 JavaScript API 和标准的 HTML5 标签,浏览器、手机平台还有其他设备可通过一个通用的协议进行实时通信。 Q&A:回答关于前 Mozilla CTO对WebRTC的抱怨 问:JavaScript 之父 Brendan Eich(Mozilla 前 CTO)曾说过,“WebRTC is a new front in the long war for an open and unencumbered web.”,您怎么理解他的这句话? 答:在网络上如何自由地沟通一直存在着很大的空间。谷歌想把网页版应用的体验做的和 Native 应用一致,但是他们很快发现,谷歌自身的产品诸如 Google Docs、Gmail 等并没有解决通讯的问题,也就是说它们不能控制麦克风、摄像头以及人与人之间的通讯。所以我同意 Brendan Eich 的说法,这对互联网和 Web 来说是一件大事。 Q&A:关于WebRTC为何未将通讯信令纳入标准 问:据了解,WebRTC 联盟曾故意遗漏信令标准来避免冲突,但此举造成后来厂商使用各不相同的协议,包括 SIP、WebSockets 以及 HTTP 协议。您认为这个问题应该怎么解决? 答:哈哈,我认为这是 W3C 做的最好的决定。有的厂商想强制把 SIP 作为浏览器通讯的信令,但是这样的话,你想用 XMPP 或者 Jingle 就不可能了。与其抄袭过时的电话网络用 SIP 协议,不如把这一部分留白,让大家自己选择何种实现。有人诟病 SIP 信令层的借口是 SIP 层没有很好的 JavaScript 库。显然这个说法是错误的,事实上有很多很好的 JavaScript 库可以用。所以,如果你一定要用 SIP 做信令层,有很多很好的 JavaScript 库供你选择,但是你不会因此受限制,这才是互联网真正该有的样子。 blacker注释:从我们接触的这么多案例来看,信令完全没有必要统一,因为不同业务场景,不同系统用的的完全不一样,有的适合jason,有的适合xmpp,有的适合sip,等等)。 Q&A:关于WebRTC尚未正式定稿但各厂商已迫不及待的问题 问:随着企业云通信市场的发展,许多厂商和开发者并没有等 WebRTC 最终定稿便投入到产品研发中,这对未来 WebRTC 标准的制定有哪些不利的影响?在您看来有没有像 Flash 之于 HTML4 那样的产品或者技术来促成 WebRTC 标准的制定? 答:早期吃螃蟹的人,他们的反馈对 WebRTC 标准的制定也是至关重要的,这对未来标准的制定是很有帮助的。互联网本来就是快速迭代的过程,产品要不断试错,我们 WebRTC 标准的制定也遵循这样的规律。 HTML5 的多媒体标准分好几部分,WebRTC 是其中的一部分。一个好消息是,WebRTC 的标准制定比较超前,很多 HTML5 其他工作组的标准制定者对这一方面的工作十分关心,最终的结果是 HTML5 和 WebRTC 会很好地共存,两者之间的沟通其实是无缝的。举个例子好了,目前 HTML5 标准里没有很好地定义音频应该输出到麦克风还是扬声器,现在 WebRTC 已经作出了一些可选择的方案,HTML5 和 WebRTC 正在密切协作以改进这个标准,其结果是二者会很相似,于开发者而言将不再会面临两种标准的困扰。 Q&A:传统认知对 WebRTC 和云通信的束缚 问:开发者对实现通信受既有概念的束缚是对 WebRTC 和云通信的真实挑战,比如企业中的电话会议依然是很受信赖的形式。怎么改变这种局面? 答:有些协议和标准的制定者认为,标准或者说规范越少、越简单越好。但 WebRTC 标准制定者认为还是应该稍微多给定一些标准和规范,于是我们多给了一些,但这多给出的部分依然不够,这也是为什么我写了《WebRTC权威指南》这本书。 WebRTC 的目的就是打破常规的人们对电话的固有认识,把人和人之间的互动、沟通加入到人们日常工作流、任意的APP当中;而不是在这个APP中内置一个电话功能,这种思想是错误的。正确的思想是,通讯应该是一种功能,而不是一种应用。也就是说,让打电话不再只是打电话,他就是人与人之间自然的交流。比如,电话不再是一个物理的设备,现在的智能可穿戴设备将来都有可能取代打电话这件事,而且未来的通讯不止是人跟人之间,有可能是人跟物之间发生。 再比如,视频通讯不应该被视为“我能看到你的脸”,人们看到的可能是一个大的数据流——通过大数据的挖掘,你的心跳、体温、脸色等等都可以通过摄像头传输过来。这跟传统的电话的模式有根本的区别。 Q&A:对 WebRTC 技术在中国的发展有的期望 问:在从事 WebRTC 开发的厂商中,与运营商合作是一个选择,打造更强大的 SDK 和更富弹性的服务也是一种选择。您怎么评价这两种策略的未来发展?您对 WebRTC 技术在中国的发展有哪些期望? 答:我是 WebRTC 标准的制定者,对商业模式的话题并不方便也不适合回答。 声网王骅补充:如果从市场的角度来看,提供 SDK 的公司只是给开发者提供了一种便利,因此很难生存。用户需要的是提供一个稳定、可靠的点对点通讯服务。以美国市场为例,现有的20多家提供 SDK 的厂商已经有7、8家被收购了,这种收购不是以大的价值被收购的,而是活不下去才不得不被收购。 在国内市场方面,国内浏览器厂商都不大,很多厂商使用的都是同样的开源代码,我们很惊喜地发现有些代码写一遍在各家的浏览器上都可以运行。在微软慢慢往 WebRTC 这个方向靠拢之后市场方面的问题应该不大。这的确是一个比较对大家利好的事情,从运营商的角度来,他们主要是做基础建设和卖数据流,在这些数据上会衍生出很多公司和各种丰富的服务,最基本的可能是音视频服务,但远远不止这些。只要政策上面没有太多的干预,这个行业将会有很大的爆发。 Q&A:各大巨头对待 WebRTC 的态度 问:目前支持 WebRTC 的浏览器有 Chrome、Firefox、Opera 以及在此基础上的衍生产品。阻碍了 WebRTC 跨浏览器支持的因素有哪些?微软的 IE 浏览器(微软一直在推进自己的 WebRTC 版本)和苹果的 Safari 不支持 WebRTC 的主要原因是什么? 答:过去的几年里我被无数次问到这个问题。我不为微软和苹果工作,我很难知道他们是怎么想的。 然而,微软在我们最初在讨论 WebRTC 标准的时候,Skype 里的确有一些有远见的人愿意参与,但是当时正值微软收购 Skype 时期,这些人都不能说话,因此微软没能参与进来;等收购结束他们能参与进来的时候,W3C 已经决定使用另外一套方案了。Skype 的人再想走另外一条道路的时候,已经基本不可能了,所以最终微软选择的是一个非标准的 ORTC。 最初微软推出 ORTC 是想跟 WebRTC 分庭抗礼,但从去年开始两边有了一定的沟通,在 WebRTC 1.0 版之后他们能互相兼容,慢慢在标准上会互相靠拢。微软的新浏览器 Edge 已经支持了 ORTC,有迹象标明微软会在 JavaScript 库方面与 WebRTC 做兼容,从这个角度来看很有可能未来 Chrome、IE、FireFox 会站在一起。 至于苹果,没有人知道苹果到底要做什么直到他们 release。在过去的一年里,我们偶尔发现会有苹果的人来旁听了一下 WebRTC 的标准讨论。最近我们发现苹果在招聘 WebRTC 的开发岗位。所以大家还是很希望苹果能在兼容性方面能做点什么的。 要猜大公司什么时候决定支持什么样的东西是很难的,但我认为谷歌、Mozilla 和微软都站在了一起,这对苹果来说是个威胁,苹果如果不参与进来,就有可能被孤立。苹果内部可能有一些考虑,这些我就不得而知了。 声网王骅补充:最近亚马逊、思科、谷歌、英特尔、微软、Mozilla 和 Netflix 组建了开放媒体联盟,这对苹果会形成一定的压力,我们也希望看到苹果会支持 WebRTC。 来源:即时通讯网 - 即时通讯开发者社区!作者:JackJiang   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-05

简述开源实时音视频技术WebRTC的优缺点

前言 作为Google开源的技术,WebRTC并不是一个可以拿来就用并且性能很好的产品,需要工程师们对其进行较多的改善。本文主要来谈一谈WebRTC的优缺点。 另外,WebRTC的发展正如多数开源项目一样,并没有期待中的快,对于开发者而言,要想廉价的用好此项技术,仍旧存在很多难题。关于当前WebRTC的技术现状,请查看请文:《开源实时音视频技术WebRTC的现状》。 WebRTC的优点简述 1方便 对于用户来说,在WebRTC出现之前想要进行实时通信就需要安装插件和客户端,但是对于很多用户来说,插件的下载、软件的安装和更新这些操作是复杂而且容易出现问题的,现在WebRTC技术内置于浏览器中,用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。对于开发者来说,在Google将WebRTC开源之前,浏览器之间实现通信的技术是掌握在大企业手中,这项技术的开发是一个很困难的任务,现在开发者使用简单的HTML标签和JavaScript API就能够实现Web音/视频通信的功能。 2免费 虽然WebRTC技术已经较为成熟,其集成了最佳的音/视频引擎,十分先进的codec,但是Google对于这些技术不收取任何费用。 3强大的打洞能力 WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术,并支持代理。 WebRTC的缺点也很明显 1无整体技术方案参考 缺乏服务器方案的设计和部署。 2传输质量难以保证 WebRTC的传输设计基于P2P,难以保障传输质量,优化手段也有限,只能做一些端到端的优化,难以应对复杂的互联网环境。比如对跨地区、跨运营商、低带宽、高丢包等场景下的传输质量基本是靠天吃饭,而这恰恰是国内互联网应用的典型场景。 3没有对群聊进行专门优化和支持 WebRTC比较适合一对一的单聊,虽然功能上可以扩展实现群聊,但是没有针对群聊,特别是超大群聊进行任何优化。 4音频的设备适配问题 设备端适配,如回声、录音失败等问题层出不穷。这一点在安卓设备上尤为突出。由于安卓设备厂商众多,每个厂商都会在标准的安卓框架上进行定制化,导致很多可用性问题(访问麦克风失败)和质量问题(如回声、啸叫)。 5对Native开发支持不够 WebRTC顾名思义,主要面向Web应用,虽然也可以用于Native开发,但是由于涉及到的领域知识(音视频采集、处理、编解码、实时传输等)较多,整个框架设计比较复杂,API粒度也比较细,导致连工程项目的编译都不是一件容易的事。 小结 可见,WebRTC是一个优缺点兼有的技术,在拥有诱人的优点的同时,其缺点也十分的严重。在进行WebRTC的开发之前,请根据自身的情况来决定是自主开发还是使用第三方SDK。 (原文链接:http://webrtc.org.cn/webrtc-goodorbad/) 来源:即时通讯网 - 即时通讯开发者社区!   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-05

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

1、前言 群聊已经成为主流IM软件的基本功能,不管是QQ群、还是微信群,一个群友在群内发了一条消息,那么对于IM服务器来说需要保证: 在线的群友能第一时间收到消息; 离线的群友能在登陆后收到消息。 由于“消息风暴扩散系数”的存在(概念详见《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?》),群消息的复杂度要远高于一对一的单聊消息。群消息的实时性、可达性、离线消息是今天将要讨论的核心话题。 2、IM开发干货系列文章,欢迎关注网易云信博客 3、常见的群消息流程 开始讲群消息投递流程之前,先介绍两个群业务的核心数据结构: 1 2 3 4 群成员表:用来描述一个群里有多少成员 t_group_users(group_id, user_id) 群离线消息表:用来描述一个群成员的离线消息 t_offine_msgs(user_id, group_id, sender_id,time, msg_id, msg_detail) 业务场景举例: 1)一个群中有x,A,B,C,D共5个成员,成员x发了一个消息; 2)成员A与B在线,期望实时收到消息; 3)成员C与D离线,期望未来拉取到离线消息。 系统架构简介: 1)客户端:x,A,B,C,D共5个客户端用户; 2)服务端:   2.1)所有模块与服务抽象为server; 2.2)所有用户在线状态抽象存储在高可用cache里; 2.3)所有数据信息,例如群成员、群离线消息抽象存储在db里。 典型群消息投递流程,如上图步骤1-4所述: 步骤1:群消息发送者x向server发出群消息; 步骤2:server去db中查询群中有多少用户(x,A,B,C,D); 步骤3:server去cache中查询这些用户的在线状态; 步骤4:对于群中在线的用户A与B,群消息server进行实时推送; 步骤5:对于群中离线的用户C与D,群消息server进行离线存储。   典型的群离线消息拉取流程,如上图步骤1-3所述: 步骤1:离线消息拉取者C向server拉取群离线消息; 步骤2:server从db中拉取离线消息并返回群用户C; 步骤3:server从db中删除群用户C的群离线消息。 存在的问题: 上述流程是最容易想,也最容易理解的,存在的问题也最显而易见:对于同一份群消息的内容,多个离线用户存储了很多份。假设群中有200个用户离线,离线消息则冗余了200份,这极大的增加了数据库的存储压力。 4、群消息优化1:减少存储量 为了减少离线消息的冗余度,增加一个群消息表,用来存储所有群消息的内容,离线消息表只存储用户的群离线消息msg_id,就能大大的降低数据库的冗余存储量,思路如下。 1 2 3 4 群消息表:用来存储一个群中所有的消息内容 t_group_msgs(group_id, sender_id, time,msg_id, msg_detail) 群离线消息表:优化后只存储msg_id t_offine_msgs(user_id, group_id, msg_id)   这样优化后,群在线消息发送就做了一些修改: 步骤3:每次发送在线群消息之前,要先存储群消息的内容; 步骤6:每次存储离线消息时,只存储msg_id,而不用为每个用户存储msg_detail。   拉取离线消息时也做了响应的修改: 步骤1:先拉取所有的离线消息msg_id; 步骤3:再根据msg_id拉取msg_detail; 步骤5:删除离线msg_id。 存在的问题(如同单对单消息的发送一样): 1)在线消息的投递可能出现消息丢失,例如服务器重启,路由器丢包,客户端crash; 2)离线消息的拉取也可能出现消息丢失,原因同上。 需要和单对单消息的可靠投递一样,加入应用层的ACK,才能保证群消息一定到达。 5、群消息优化2:应用层ACK   应用层ACK优化后,群在线消息发送又发生了一些变化: 步骤3:在消息msg_detail存储到群消息表后,不管用户是否在线,都先将msg_id存储到离线消息表里; 步骤6:在线的用户A和B收到群消息后,需要增加一个应用层ACK,来标识消息到达; 步骤7:在线的用户A和B在应用层ACK后,将他们的离线消息msg_id删除掉。   对应到群离线消息的拉取也一样: 步骤1:先拉取msg_id; 步骤3:再拉取msg_detail; 步骤5:最后应用层ACK; 步骤6:server收到应用层ACK才能删除离线消息表里的msg_id。 存在的问题: 1)如果拉取了消息,却没来得及应用层ACK,会收到重复的消息么? 答案是肯定的,不过可以在客户端去重,对于重复的msg_id,对用户不展现,从而不影响用户体验 2)对于离线的每一条消息,虽然只存储了msg_id,但是每个用户的每一条离线消息都将在数据库中保存一条记录,有没有办法减少离线消息的记录数呢? 6、群消息优化3:离线消息表 其实,对于一个群用户,在ta登出后的离线期间内,肯定是所有的群消息都没有收到的,完全不用对所有的每一条离线消息存储一个离线msg_id,而只需要存储最近一条拉取到的离线消息的time(或者msg_id),下次登录时拉取在那之后的所有群消息即可,而完全没有必要存储每个人未拉取到的离线消息msg_id。 1 2 3 4 5 群成员表:用来描述一个群里有多少成员,以及每个成员最后一条ack的群消息的msg_id(或者time) t_group_users(group_id, user_id, last_ack_msg_id(last_ack_msg_time)) 群消息表:用来存储一个群中所有的消息内容,不变 t_group_msgs(group_id, sender_id, time,msg_id, msg_detail) 群离线消息表:不再需要了   离线消息表优化后,群在线消息的投递流程: 步骤3:在消息msg_detail存储到群消息表后,不再需要操作离线消息表(优化前需要将msg_id插入离线消息表); 步骤7:在线的用户A和B在应用层ACK后,将last_ack_msg_id更新即可(优化前需要将msg_id从离线消息表删除)。   群离线消息的拉取流程也类似: 步骤1:拉取离线消息; 步骤3:ACK离线消息; 步骤4:更新last_ack_msg_id。 存在的问题: 由于“消息风暴扩散系数”的存在,假设1个群有500个用户,“每条”群消息都会变为500个应用层ACK,将对服务器造成巨大的冲击,有没有办法减少ACK请求量呢? 7、群消息优化4:批量ACK 由于“消息风暴扩散系数”的存在,如果每条群消息都ACK,会给服务器造成巨大的冲击,为了减少ACK请求量,很容易想到的方法是批量ACK。 批量ACK的方式又有两种: 1)每收到N条群消息ACK一次,这样请求量就降低为原来的1/N了; 2)每隔时间间隔T进行一次群消息ACK,也能达到类似的效果。 新的问题:批量ACK有可能导致:还没有来得及ACK群消息,用户就退出了,这样下次登录会拉取到重复的离线消息。 解决方案:msg_id去重,不对用户展现,保证良好的用户体验。 还可能存在的问题:群离线消息过多:拉取过慢。 解决方案:分页拉取(按需拉取),分页拉取的细节在《IM消息送达保证机制实现(下篇):保证离线消息的可靠投递》一章中有详细叙述,此处不再展开。 8、本文小结 群消息还是非常有意思的,可达性、实时性、离线消息、消息风暴扩散等等等等,做个总结: 1)不管是群在线消息,还是群离线消息,应用层的ACK是可达性的保障; 2)群消息只存一份,不用为每个用户存储离线群msg_id,只需存储一个最近ack的群消息id/time; 3)为了减少消息风暴,可以批量ACK; 4)如果收到重复消息,需要msg_id去重,让用户无感知; 5)离线消息过多,可以分页拉取(按需拉取)优化。 (原文链接:http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959643&idx=1&sn=844afa6a31770fa587474ecd73c3b3b3&chksm=bd2d04878a5a8d91c5c93ad8e85254185c63eb419457efbedcba54a9b8a9053da1e8980a694a&scene=21#wechat_redirect) 来源:即时通讯网 - 即时通讯开发者社区!   了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能

2018-11-05