技术环境月报──2022年第3期

banner

各位开发者小伙伴：

这里是 RTE 技术环境观察者主笔的《技术环境月报》——致力于成为对大家“有用”的 Highlight 看板——每月初通过 RTC 开发者社区(https://rtcdeveloper.agora.io/)和微信公众号（shengwang-agora）发布，恳请大伙儿多转发、多反馈。由于文中内容包含较多信源超链接、建议大家前往 RTC 开发者社区或使用我们的邮件订阅服务，喜欢用邮件的小伙伴请点击订阅「RTE技术环境月报」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从“技术环境月报”中看到哪些内容；自己推荐的信源、话题、会议等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

文中点评仅代表观察者个人，如有不同意见，欢迎大家各种留言跟帖反馈。希望此后的日子里，《技术环境月报》能与各位如期相见、偶尔启发。以下为月报正文：

00. 本月好文推荐：《虚拟化技术的前世今生》

在计算机技术的发展历史上，出现了两种著名的虚拟化方案，分别是I型虚拟化和II型虚拟化，区别在于 HyperVisor 在系统中的位置。

01. 【音视频】WebRTC 成“兵家必争”之地？

  • WebRTC 如何发展至今？WebRTC API 和协议的发展历程中有许多小故事，许多问题的答案实际上与历史有关，并且不同人的看法存在一些偏差……基于 WebRTC 的实时交互式传输是一期 Millicast 上的访谈，介绍了 WebRTC 对于当前的工业界的意义、应用方向以及对传统广播所带来的影响。
  • 市场上有不同的 WebRTC 平台，彼此之间存在一定的差异，近期杜比公司宣布收购了 Millicast 公司，布局 RTC 领域，杜比称收购是为了扩大开发者和企业的机会，把超低延迟流媒体带到 Dolby.io 中去。
  • 在1月刊中，我们曾提到 AppRTC 和 TestRTC 服务已于2021年12月13日关闭。而通过收购 TestRTC，Spearline 获得了在 WebRTC 测试、监控和支持方面的能力从而正式切入 WebRTC 赛道。
  • 高通2023年发布的下一代旗舰产品将支持 AV1，具体的实现可能是将由 Adreno 视频处理单元原生支持 AV1 编解码器。据悉，最早支持 AV1 的芯片厂商是联发科，其次是三星和博通，苹果的 A 系列目前尚未支持 AV1。[Snap 加入了开放媒体联盟](https://aomedia.org/press releases/snapinc-joins-the-alliance-for-open-media/)，目前已有超过50家企业加入 AOM；如果 AV1 在硬件方面没有得到普遍支持，那么流媒体服务就没必要重新进行编码，现阶段除 Youtube、Netflix、爱奇艺外，多数流媒体服务商仍处于观望状态。

02. 【大前端】视频聊天中“实时互动”需求凸显

  • Reddit 推出了音频直播产品 Reddit Talks；RingCentral 为视频通话加入了动态端到端加密功能；Datadog 收购了 CoScreen；谷歌旗下的 Duo 应用在视频聊天中加入“实时共享”功能，对标苹果 FaceTime 的 SharePlay 功能。上述3条资讯也证明了人们希望能在视频聊天中有更多与“实时互动”相关的需求，而不仅仅是交谈。为了满足各种“实时互动”的需求，厂商需要端到端地优化整个业务链路……包括降低应用的能耗、优化数据的传输、加强服务监控，等等。
  • 微软 Teams 是如何将视频会议的耗电量降低了一半的。具体的做法包括，在对视频采集过程中，把优化重点放在摄像头上；利用操作系统的原生资源来改善图像片段在渲染过程中的传输方式；以及利用 GPU 来支持提高 Teams 的渲染性能；此外还针对个别屏幕组件的渲染进行了优化，使视频和应用程序共享的功耗进一步降低……
  • 在网络上做 pub/sub 的最佳方式：《SSE、WebSockets 与 HTTP 的对比》，文章比较了目前可用的几种基于HTTP的双向通信方案：Server-Sent Event，WebSockets和基于扩展105/106的HTTP（类似long polling）。浏览器和CDN对几种方案的支持各不相同，目前并没有最佳方案。
  • B 站开源其 Web 服务网络性能调试工具 bvc-mahimahi，该项目灵感源自 MIT 设计的 mahimahi、依赖 B 站另一个开源的 QUIC 网络协议库 quiche，并使用了 Nginx QUIC Module。

03. 【网络】网络是构建分布式平台的基础

04. 【开发】全栈工程师的 Web 3 技能图谱

05. 【安全&其他】开源平台的攻防局势

  • 谷歌安全团队统计：Linux 内核开发者修复漏洞的速读最快。谷歌安全团队统计了2019年1月至2021年12月期间报告的漏洞发现，在2021年供应商平均花了52天来修复谷歌提交的漏洞，而3年前这个数字是80天；其中 Linux 开发者修复 Bug 的平均时间为25天，其他开源组织和企业如 Apache、Canonical、Github 和 Kubernetes 所需时间为 44 天。
供应商 Bug总数 90天内修复 在宽限期内修复 超出最后期限和宽限期 平均修复天数
Apple 84 73 (87%) 7 (8%) 4 (5%) 69
Microsoft 80 61 (76%) 15 (19%) 4 (5%) 83
Google 56 53 (95%) 2 (4%) 1 (2%) 44
Linux 25 24 (96%) 0 (0%) 1 (4%) 25
Adobe 19 15 (79%) 4 (21%) 0 (0%) 65
Mozilla 10 9 (90%) 1 (10%) 0 (0%) 46
Samsung 10 8 (80%) 2 (20%) 0 (0%) 72
Oracle 7 3 (43%) 0 (0%) 4 (57%) 109
Others* 55 48 (87%) 3 (5%) 4 (7%) 44
TOTAL 346 294 (84%) 34 (10%) 18 (5%) 61

06. 近期值得关注的会议

07. 本月热点开源项目

请 注册 或 登录 后评论
    // 作者
    R
    @RTE_Dev_Comm
    还什么也没有写～
    • 0
    // 本帖子
    分类
    开发者日报
    // 相关帖子
    Coming soon...
    • 0
    技术环境月报──2022年第3期翟方庆 发布于 声网开发者社区