WebRTC实时通信技术详解

5星 · 超过95%的资源需积分: 50 179 浏览量更新于2024-07-20 收藏 24.28MB PDF 举报

"Real-Time Communication with WebRTC" 是一本由Salvatore Loreto和Simon Pietro Romano编著的专业书籍，专注于实时通信技术WebRTC。这本书深入探讨了WebRTC（Web Real-Time Communication）的原理、实现和应用，帮助读者理解和掌握在Web环境中实现高清、低延迟的实时通信的方法。 WebRTC是一种开放的网络技术，允许在浏览器和其他应用程序之间进行实时的、点对点的通信，无需插件或安装额外的软件。这一技术的出现极大地推动了互联网上音视频通信的发展，尤其是在在线协作、远程教育、游戏、社交网络等领域。书中详细讲解了WebRTC的关键组件和技术，包括： 1. **媒体捕获**：WebRTC允许用户访问设备的摄像头和麦克风，进行音频和视频的捕捉，这是实现实时通信的基础。 2. **PeerConnection**：WebRTC的核心组件之一，负责建立和管理两个浏览器之间的直接连接，实现数据流的传输。 3. **信令**：在建立连接的过程中，需要通过信令协议交换信息，如ICE（Interactive Connectivity Establishment）、STUN（Session Traversal Utilities for NAT）和TURN（Traversal Using Relays around NAT）等，这些技术帮助穿越网络地址转换（NAT）并找到最佳的通信路径。 4. **数据通道**：WebRTC不仅仅用于音视频通信，还包括了双向的数据传输能力，可以用于发送任意类型的数据，例如文本、图像或文件。 5. **安全与隐私**：WebRTC采用DTLS（Datagram Transport Layer Security）和SRTP（Secure Real-time Transport Protocol）确保通信的安全性，同时处理用户隐私问题。 6. **API接口**：书中详细介绍了JavaScript API，开发者可以利用这些接口在Web应用中集成WebRTC功能。 7. **兼容性和跨平台**：WebRTC支持多种操作系统和浏览器，包括Chrome、Firefox、Opera等，作者可能详细讨论了如何处理兼容性问题。 8. **案例分析**：可能包含实际项目中的应用示例，展示了WebRTC在不同场景下的实施策略和最佳实践。此外，该书可能还涵盖了WebRTC的发展历程、最新进展，以及未来可能的趋势。通过阅读本书，读者不仅可以学习到WebRTC的理论知识，还能获得实际操作的指导，从而在自己的项目中成功应用WebRTC技术。第一版于2014年5月发布，后续可能有更新以适应技术的发展。对于想要深入了解和应用WebRTC的开发人员、架构师和产品经理来说，这是一本不可多得的参考资料。

WebRTC Architecture

WebRTC extends the client-server semantics by introducing a peer-to-peer communi‐

cation paradigm between browsers. The most general WebRTC architectural model (see

Figure 1-1) draws its inspiration from the so-called SIP (Session Initiation Protocol)

Trapezoid (RFC3261).

Figure 1-1. The WebRTC Trapezoid

In the WebRTC Trapezoid model, both browsers are running a web application, which

is downloaded from a different web server. Signaling messages are used to set up and

terminate communications. They are transported by the HTTP or WebSocket protocol

via web servers that can modify, translate, or manage them as needed. It is worth noting

that the signaling between browser and server is not standardized in WebRTC, as it is

considered to be part of the application (see “Signaling” on page 5). As to the data path,

a PeerConnection allows media to flow directly between browsers without any inter‐

vening servers. The two web servers can communicate using a standard signaling pro‐

tocol such as SIP or Jingle (XEP-0166). Otherwise, they can use a proprietary signaling

protocol.

The most common WebRTC scenario is likely to be the one where both browsers are

running the same web application, downloaded from the same web page. In this case

the Trapezoid becomes a Triangle (see Figure 1-2).

2 | Chapter 1: Introduction

www.cxy808.com

1. DTLS is actually used for key derivation, while SRTP is used on the wire. So, the packets on the wire are not

DTLS (except for the initial handshake).

Signaling

The general idea behind the design of WebRTC has been to fully specify how to control

the media plane, while leaving the signaling plane as much as possible to the application

layer. The rationale is that different applications may prefer to use different standardized

signaling protocols (e.g., SIP or eXtensible Messaging and Presence Protocol [XMPP])

or even something custom.

Session description represents the most important information that needs to be ex‐

changed. It specifies the transport (and Interactive Connectivity Establishment [ICE])

information, as well as the media type, format, and all associated media configuration

parameters needed to establish the media path.

Since the original idea to exchange session description information in the form of Ses‐

sion Description Protocol (SDP) “blobs” presented several shortcomings, some of which

turned out to be really hard to address, the IETF is now standardizing the JavaScript

Session Establishment Protocol (JSEP). JSEP provides the interface needed by an ap‐

plication to deal with the negotiated local and remote session descriptions (with the

negotiation carried out through whatever signaling mechanism might be desired), to‐

gether with a standardized way of interacting with the ICE state machine.

The JSEP approach delegates entirely to the application the responsibility for driving

the signaling state machine: the application must call the right APIs at the right times,

and convert the session descriptions and related ICE information into the defined mes‐

sages of its chosen signaling protocol, instead of simply forwarding to the remote side

the messages emitted from the browser.

WebRTC API

The W3C WebRTC 1.0 API allows a JavaScript application to take advantage of the

novel browser’s real-time capabilities. The real-time browser function (see Figure 1-3)

implemented in the browser core provides the functionality needed to establish the

necessary audio, video, and data channels. All media and data streams are encrypted

using DTLS.

Signaling | 5

www.cxy808.com

Datagram Transport Layer Security (DTLS)

The DTLS (Datagram Transport Layer Security) protocol (RFC6347) is designed to

prevent eavesdropping, tampering, or message forgery to the datragram transport of‐

fered by the User Datagram Protocol (UDP). The DTLS protocol is based on the stream-

oriented Transport Layer Security (TLS) protocol and is intended to provide similar

security guarantees.

The DTLS handshake performed between two WebRTC clients re‐

lies on self-signed certificates. As a result, the certificates themselves

cannot be used to authenticate the peer, as there is no explicit chain

of trust to verify.

To ensure a baseline level of interoperability between different real-time browser func‐

tion implementations, the IETF is working on selecting a minimum set of mandatory

to support audio and video codecs. Opus (RFC6716) and G.711 have been selected as

the mandatory to implement audio codecs. However, at the time of this writing, IETF

has not yet reached a consensus on the mandatory to implement video codecs.

The API is being designed around three main concepts: MediaStream, PeerConnec

tion, and DataChannel.

MediaStream

A MediaStream is an abstract representation of an actual stream of data of audio

and/or video. It serves as a handle for managing actions on the media stream, such as

displaying the stream’s content, recording it, or sending it to a remote peer. A Media

Stream may be extended to represent a stream that either comes from (remote stream)

or is sent to (local stream) a remote node.

A LocalMediaStream represents a media stream from a local media-capture device (e.g.,

webcam, microphone, etc.). To create and use a local stream, the web application must

request access from the user through the getUserMedia() function. The application

specifies the type of media—audio or video—to which it requires access. The devices

selector in the browser interface serves as the mechanism for granting or denying access.

Once the application is done, it may revoke its own access by calling the stop() function

on the LocalMediaStream.

6 | Chapter 1: Introduction

www.cxy808.com

剩余162页未读，继续阅读

跬步达千里

粉丝: 239
资源: 43

WebRTC实时通信技术详解

Real-Time Communication with WebRTC 无水印pdf

webrtc权威指南完整版

WebRTC 1.0: Real-time Communication Between Browsers

Real-Time Communication with WebRTC.pdf

Real-Time Communication with WebRTC

Real-Time Communication with WebRTC 源码

Real-Time Communication with WebRTC Peer-to-Peer in the Browser 无水印pdf

Real-Time Communication with WebRTC Peer-to-Peer in the Browser epub

Real-Time Communication with WebRTC Peer-to-Peer in the Browser mobi

Getting-Started-with-Webrtc-2013-Rob-Manson.pdf

最新资源