网络实时通信：实时通信增强网络能力

ZDNET网络频道 06月27日 综合消息：Web平台为人们浏览海量内容提供了一种独特的方式，为开发人员提供了一个开发一次、任何地方部署的模式，可支持服务提供商在全球范围内部署服务。以HTML5为代表的Web浏览器的技术升级浪潮，以及正在进行的将实时通信功能融入Web平台的工作，为通信与数据的结合以及改善用户体验创造了新的机遇(见图1)。

HTML5和Web浏览器的发展

信息通信技术ICT在技术、社会文化、当地及全球层面的变革可以在一夜之间发生。伴随先进技术迅速成为主流，人们快速采纳新的解决方案。HTML5，即第5版网页通用技术标准，的发展就是各种因素推动下的改变创造新事物的典型实例，其本身也是推动创新的催化剂。这些因素包括越来越普及的固定和移动宽带、消费者与企业对多媒体和通信业务的需求，以及对一平台的需要，其在可控成本下通过各种设备让用户可达。当前以HTML5为主导的浏览器的发展演进正推动浏览器的能力日益接近原生(Native)应用环境。支持实现WebRTC，即基于Web的实时通讯正在出现。为确保本地浏览器能够支持实时通信的API协议方面，目前万维网联盟(W3C)正与互联网工程任务组(IETF)联合开展标准化的协同工作，这只是第一步。爱立信的原型浏览器和开发者版本的Google Chrome都可以早期实施支持实时通信的API(应用程序接口)。目前为止，结果很令人鼓舞。但是，在所有主流浏览器和所有类型设备上实现互操作的道路还很长，没有人完全有把握取得成功。

标准化工作的目标是创建实现Web应用在任何设备上都可以运行的API，以便在浏览器之间点对点接收和发送实时媒体和数据流。在浏览器上运行的API大多都需要在浏览器内核使用现有的协议和编码解码器。API的设计使网络开发人员能够自由使用各种功能，以发现和连接通讯会话的参与者。Web平台需要支持跨越不同设备和操作系统，并融合通信与数据，是解决方案能满足目前及未来各种需求的一项关键技术。开放浏览器标准化的最大优势之一就是它利用万维网联盟W3C和互联网工程任务组IETF等机构以及其他高能力的浏览器技术组织(如苹果公司成立的WebKit开放源项目和网络超文本应用技术工作小组即WHATWG)的工作。这些群体积极共享知识，根据开发者和用户需求，逐步开发解决方案，一步步演进Web平台。

Web成为应用的平台

Web设计之初并没有考虑到应用开发。随着时间的推移，网络已发展成为充分支持应用的平台。开发者快速创建创新解决方案的需要推动了Web功能的提升。JavaScript语言、DOM协定和其他一些(常常是专有的)功能为基于Web的应用开发现代化铺平了道路。新APIs的加入可改善现有应用，并使其在功能上与本地应用处于同等水平。

用来开发Web应用的功能数量不断增加，它们常被称为开放Web平台。一项特定功能的成功最终是由它是否被纳入主流浏览器所决定。尽管HTML5仅是开放Web的一个组成部分，但它也常被视为“实现进展”的同义词。

HTML作为网络标记语言，是结构化的应用和数据，使应用能够与CSS集成在一起，并用JavaScript语言进行控制。

通过HTTP基础架构提供的HTML、CSS和JavaScript等技术是开放Web平台的基石。它们与脚本APIs一起构成了吸引应用开发者的基础，包括用户界面的描述和命名方式，以及动态脚本语言所具有的多功能性。

Web应用大量增加的部分原因是进入门槛低- 代码碎片在开发人员中被复制、粘贴和共享，所需工具只有浏览器和文本编辑器。内容更全面的用途也常常被收入JavaScript库，从而产生了拥有自己开发人员群体、书籍的整个框架(在某些情况下甚至还有会议)。除了它们对开发人员的吸引力外，几乎所有设备都支持浏览器这样一种现实可能最终起到决定作用，倾向于利用Web而非其他技术进行应用开发。如果任何设备上所用浏览器都充分符合标准，那么所有遵守标准的应用都可以在这些设备上运行，无论其采用任何操作系统和硬件架构。在一些情况下，为多种设备开发应用的成本是合理的，而在其他情况下，最好是针对具体的设备平台。但是，在多数情况下，从成本或产品上市时间角度来看，瞄准所有可能平台并不可行。应用的成功由可达范围决定，以合理成本支持可达范围的解决方案将最终在平台竞争中成为胜者。

浏览器和标准化

目前有四种Web浏览器引擎能够运行高级Web应用。其中两种为开放源，分别是Firefox使用的Mozilla Gecko引擎和苹果Safari、谷歌Chrome使用的WebKit。另外两种引擎是Opera的Presto和微软的Trident(已在Internet Explorer上使用)，它们都是封闭源。Web标准化目前正与浏览器引擎技术齐头并进，同步发展。

任何人都可以提出新功能，但只有那些能够实施特定功能，并展现出具有在更大环境中工作所需技能和知识的开发人员才有直接优势决定哪些新功能会被接受并最终在主浏览器实施。

具体来讲，在大多数情况下，开放源项目和Web标准化的实施工作采用精英管理，与设计团队相比，更注重个人成绩。万维网联盟在Web标准化中扮演着重要作用。但是，规范受到各浏览器厂商商业决策的影响- 在现实中，Web浏览器厂商决定着采用哪些功能。

WHATWG常被视为Web浏览器厂商联盟，但它实际上是由代表主流浏览器厂商从事相关行业的个人组成的松散联合体(微软例外)。

走向Web实时通信

2006年，首个便于Web应用点对点连接的API 被增加到WHATWG网络应用1.0。该API是专门为发送数据而开发的。2009年晚些时候，WHATWG规范中增添了设备元素和 MediaStream API。这一新元素实现授权用户能访问某些隐私和安全敏感的设备(如网络摄像头和耳机)，而且增加这一API是为了处理来自这些设备的媒体流。该API将来自媒体采集设备的内容本地存储，并将它们录入二进制大数据格式供以后上传。

2010年上半年，点对点通信API初步方案加入WHATWG规范。这些方案采用了ICE建立连接和RTP over UDP协议，将本地媒体流传送到远端对等方进行实时呈现。除了API外，方案包括了点对点数据通信和文件传送的方式。2010年晚些时候，谷歌举办了一场研讨会，邀请了包括爱立信在内的Web和电信行业多家知名企业参加。

研讨会期间，各企业一致同意继续在相关标准化论坛上公开合作，而不是专门为此形成一个联盟。

2011年3月，WHATWG方案经过全面修订。设备元素被丢弃，转而采用纯JavaScript API。这一版本的API内容详细全面，达到了实施水平。信令经过更新到与SDP offer/answer兼容，包括点对点之间实际SDPs的带外传输，由应用开发人员决定如何通过服务器将信令消息传输给远端对等方。如何传输与媒体平面无直接关系的所有高层信号也完全由应用开发人员决定。

2011年8月，万维网联盟工作小组决定对WHATWG规范进行深入调查，之后在Web实时通信(WebRTC)工作小组的现有工作基础上对调查结果进行了一系列修订，但原始规范的基本结构和原则保持不变。

API有两个基本概念：MediaStream和PeerConnection。MediaStream是实际媒体流的抽象表现。它是管理流内容展示、录音或发送给远端对等方等媒体流行为的抓手。LocalMediaStream代表来自本地摄像机、耳机或其他媒体采集设备的媒体流。为获取本地流，Web应用必须要求用户访问(通过“getUserMedia”功能)。该应用确定它要求访问的媒体类型：音频或是视频。浏览器接口的设备选择器作为同意或拒绝访问的机制。PeerConnection代表与远端对等方的联系，通常是指另一个在远端运行相同Web应用的实例。一旦对等连接建立后，MediaStream对象可以发送给远端对等方。对等连接机制使用ICE穿越NAT和防火墙。使用ICE提供安全手段，它可以防止非信任的网页和应用向主机随意发送数据。媒体平面的信令在点对点之间带外发送。API将发送将被大多数应用视为不透明二进制对象的信令消息，但它们必须由Web应用安全有效地传输到其他对等方。每个信令消息到达后将立即被输入到负责接收的对等连接，同时RTP携带着媒体数据。对等连接概念包含一个功能，即Web应用可以向远端对等方发送通用数据。

只开发媒体控制平面API的主要动机是许多可能受益于这一技术的现有服务已经有了用户相互寻找的成熟管理机制。在一些情况下，双向、低延时通道可用于在端点之间传送信令消息。以社交网络服务为例，用户是服务的基本组成部分。用户相互寻找途径和互动交流是主要服务。根据人们对朋友、同事和校友的分类，自然地形成不同的用户群。视频聊天等服务是服务的延伸。这种情况下就需要找到妥善向现有平台增添更多服务的解决方案。该API就是这样一种解决方案，它仅负责在端点之间建立起媒体流，而不关心这些端点如何、何时和为什么决定进行通信。

社交平台上当用户群在轻松会议环境中进行通信时，点对点模式可能需要补充网络基础设施才能连接多于2个或3个以上的参与者。一般用户可用的上行带宽可能不足以与多人同时并行通信，但是这一模式可以得到演进，以便使端点成为会议混音器。

应用开发人员和Web服务提供商决定如何发现和连接Web应用的对等实例(Peer)。API要求浏览器内核具有建立所需音频和视频通道的功能。正在进行的标准化工作尚未就那些编码(Codec)做出定论。目前假定所有媒体和数据流始终是加密。