此文章发布于6个月前,其中某些内容可能过时,或与作者现时状况、观点不同。
RFC 8825 阅读摘要

注:这是我第一次阅读IETF的文章,请谨慎参考,欢迎指出问题。

原文信息

RFC 8825
Overview: Real-Time Protocols for Browser-Based Applications
H. Alvestrand, Google, January 2021

概述

本文是对浏览器集成型即时应用 real-time applications 的协议 —— 互联网实时通信 "real-time communication on the Web",进行的一个综述。

这是一个普适性的说明,并不是定义了一种协议,而是定义了协议的规范,提供给其他 Web Real-Time Communication (WebRTC) 的实现 implementation 参考。

文章的核心内容由如下的四部分组成:

  • 介绍 Introduction
  • 意旨与术语 Principles and Terminology
  • 建构 Architecture and Functionality Groups
  • 组份 (4-11)

本摘要按顺序介绍。

介绍

本段首先引出,互联网自早起开始就已经被视作「实时通信交互应用 real-time, interactive applications」的载体(如互联网电话、视频会议),这些应用在早期阶段多半通过是私有网络、软硬件实现,对基础设施要求甚高,但是由于今天的宽带、硬件发展,常见计算设备也可以提供这些服务了。这是就是历史及现状,也是本文的前提条件。

然后,实际上这里面有很多困难,比如没有统一的通信协议,缺少统一身份系统 universal identification systems 前者指的就是这种实时通信应用的协议,后者是电话号码或者电子邮箱地址这样的。作者指出,一个通用的解决方案"The Universal Solution"绝非易事。

作者举例了新兴的浏览器应用 web application 认为只要浏览器平台有足够的接口,就可以跑几乎各种服务在上面。作者推出了该设计的核心观念,即(1)通过 JavaScript API 进行控制(2)该协议要能实现全部 WebRTC 规范中标为必须的用例 "use cases"

最后,作者提醒,它和其他项目(如W3C Web Real-Time Communications)的侧重点为“在HTML5中的可用性”不同,这里注重于提出一种规范网络上交互的协议。而在 WebRTC 的发展中必然会使得一些原来的方式不再可行,举出实例并提供了折衷方案。

意旨与术语

本段分为多个部分,首先指出了 WebRTC 协议规范的愿景是允许一个实现(即客户端)与别的实现间通过音频、视频或其他数据以最直接的方式交互。第二部分,说明了API与协议 Protocol 之间的关系,并列举了概念。第三部分说明了可交互性、创新性之间的均衡考虑。第四部分说明了本文对于标准化用语(如MUSTREQUIRED)使用情况。

建构

这是最核心的概念部分,通过ASCII图像(请见原文)和文字说明了浏览器、服务器之间的交互关系、方式和各自角色,并提出了六个构成部分。

组份

即对上一节中提出的六中概念依次进行介绍其定义,和使用的规范。

  • 数据传输 Data Transport
  • 数据封装和安全 Data Framing and Securing
  • 数据格式 Data Formats
  • 网络连接管理 Connection Management
  • 媒体呈现和控制 Presentation and Control
  • 本地系统支持功能 Local System Support Functions

其中,前三者为媒体传输 Media Transport 职能,后三者为媒体服务 Media Service 职能,且第六项为可选项(如本地回声消除功能、音量控制)。

  Comment
  • 您正在回复给 Poi