webrtc开发_webrtc开发人员基本概述

webrtc开发

Audio and video communication over the internet is nothing new. Skype was one of the first tools enabling it back in 2003 and it didn’t take long for such video chats to be available directly from the browser. WebRTC is a relatively new technology enabling easy and secure video communications in the browser. So what is it exactly, how does it work, and why does it revolutionise video communications?

互联网上的音频和视频通信并不是什么新鲜事物。 Skype最早是在2003年启用它的工具之一,并且很快就可以从浏览器直接进行这种视频聊天。 WebRTC是一项相对较新的技术,可在浏览器中轻松安全地进行视频通信。 那么到底是什么,它是如何工作的,又为什么会给视频通信带来革命性的变化呢?

WebRTC is a collection of protocols, standards, and JavaScript APIs. While most solutions for video communications rely on proprietary software or at best browser plugins, WebRTC enables this kind of communications directly and solely through the browser. That means that you receive a link, click on it and, without having to download anything, you can start your online video call.

WebRTC是协议,标准和JavaScript API的集合。 尽管大多数视频通信解决方案都依赖于专有软件或最好的浏览器插件,但WebRTC可以直接且仅通过浏览器实现这种通信。 这意味着您将收到一个链接,单击该链接,无需下载任何内容,就可以开始在线视频通话。

I said that WebRTC is new but it is actually almost 10 years old. It was first released in 2011 but as always for big web standards, it took some time for it to be implemented in all major browsers. Safari only started supporting it in 2017, and even though Firefox and Chrome have been supporting it for longer, differences in their implementation made some functionalities unusable across browsers. But it is now working reliably even across browsers, at least for the main ones, and on mobile.

我说过WebRTC是新的,但实际上已经有10年的历史了。 它于2011年首次发布,但与大型网络标准一样,它要花一些时间才能在所有主要浏览器中实现。 Safari于2017年才开始支持它,即使Firefox和Chrome对其支持的时间更长,但其实现方式的差异也使得某些功能无法跨浏览器使用。 但是,即使在跨浏览器的情况下,至少在主要浏览器和移动设备上,它现在都能可靠地运行。

音频和视频引擎 (Audio & Video Engines)

A first challenge for such a project was to deal with video and audio streams. This is what a company called Global IP Solutions was working on when they were bought by Google in 2010. For a video conference to be possible between browsers, browsers first need to access the user’s hardware. Once receiving video and audio streams from the hardware, browsers need to encode them, improve them (for example cancelling noise), handle their quality and send them over a network with changing bitrate and bandwidth.

这种项目的第一个挑战是处理视频和音频流。 这是一家名为Global IP Solutions的公司在2010年被Google收购时正在进行的工作。要使浏览器之间可以进行视频会议,浏览器首先需要访问用户的硬件。 一旦从硬件接收到视频和音频流,浏览器就需要对其进行编码,改进(例如消除噪声),处理它们的质量并通过变化的比特率和带宽通过网络发送它们。

When receiving a stream, the browser needs to decode it and render it to the user with an acceptable quality, even though network conditions can be bad and packets might have gotten delayed or lost. Protocols and standards were developed in order for it to work and browsers now take care of all this work. When implementing a tool over WebRTC, a developer has a JavaScript API available, MediaStream, from which she simply can get an already improved and encoded stream.

接收流时,浏览器需要解码它,并以可接受的质量将其呈现给用户,即使网络条件可能不好并且数据包可能已延迟或丢失。 开发协议和标准是为了使其能够正常工作,现在浏览器会处理所有这些工作。 通过WebRTC实施工具时,开发人员可以使用JavaScript API MediaStream ,从中她可以简单地获取已经改进并编码的流。

在浏览器之间建立连接 (Establish a Connection between Browsers)

发信号 (Signaling)

The next challenge was to actually enable connections between browsers. Three types of information have to be exchanged between clients for a connection to be established:

下一个挑战是实际启用浏览器之间的连接。 客户端之间必须交换三种类型的信息才能建立连接:

  • Media data: which type of media do you want to share (audio only or video), with which constraints (quality for example).

    媒体数据:您要共享哪种媒体类型(仅音频或视频),具有哪些限制条件(例如质量)。
  • Session control data: to open and close the communication.

    会话控制数据:打开和关闭通讯。
  • Network data: users need to get each other’s IP addresses and ports and check if they can establish a peer-to-peer connection.

    网络数据:用户需要获取彼此的IP地址和端口,并检查是否可以建立对等连接。

This exchange is called the signaling process. These data have to be exchanged in order to open a peer-to-peer connection but how they are to be exchanged is completely up to the developer. She could use any communication means she already has established, but a common solution is to use websockets.

这种交换称为信令过程。 这些数据必须进行交换才能打开对等连接,但是如何交换它们完全取决于开发人员。 她可以使用已经建立的任何通信方式,但是一个常见的解决方案是使用websocket。

Concretely, let’s say you want to establish a WebRTC connection between Bob and Alice. Bob and Alice are both logged in into your website, and they both click a button to start a video chat. They both need to establish a connection to a websocket server first. Bob then requests audio and video streams from the MediaStream API, creates an WebRTC offer and sends it to Alice over the signaling medium, the websocket server in this example. Such an offer is a string containing information about the media data. Alice receives this offer, requests her audio and video streams, creates an answer and sends it to Bob.

具体来说,假设您要在Bob和Alice之间建立WebRTC连接。 Bob和Alice都已登录到您的网站,并且都单击了按钮以开始视频聊天。 他们俩都需要首先建立与Websocket服务器的连接。 然后,Bob从MediaStream API请求音频和视频流,创建WebRTC服务,并通过信令介质(在此示例中为Websocket服务器)将其发送给Alice。 这样的报价是包含有关媒体数据的信息的字符串。 爱丽丝收到此要约,请求她的音频和视频流,创建答案并将其发送给鲍勃。

Alice and Bob have now exchanged the media data, and notified each other that they want to start a video chat. But here comes the next challenge: we want a direct peer-to-peer connection, not a connection through a websocket server. How do we establish such a connection?

爱丽丝(Alice)和鲍勃(Bob)现在已经交换了媒体数据,并互相通知他们要开始视频聊天。 但是,下一个挑战就来了:我们需要直接的对等连接,而不是通过Websocket服务器的连接。 我们如何建立这种联系?

(ICE)

The Internet is made of computers communicating together over a network. Connecting two computers together doesn’t sound like a big issue. Thing is, you usually connect a client to a server. A server has a well known IP address and the client (the computer requesting a website) knows exactly where to send its requests. When connecting two clients though, they first have to find each other’s IP addresses and it is more complicated than it sounds.

互联网由通过网络相互通信的计算机组成。 将两台计算机连接在一起听起来并不是什么大问题。 事实是,您通常将客户端连接到服务器。 服务器具有众所周知的IP地址,客户端(请求网站的计算机)确切知道将请求发送到何处。 但是,当连接两个客户端时,它们首先必须找到彼此的IP地址,这比听起来要复杂得多。

Because of the historic lack of IP addresses (only around 4 billions addresses were available with IPv4), users are grouped under one public address, behind a router translating addresses in the packets going through it. This process is called Network Address Translation (NAT). There are different types of NATs, but some of them allocates a public IP address and a port for UDP flows (what we need). WebRTC uses the ICE (Interactive Connectivity Establishment) framework to discover and communicate the user’s public IP address to her peer.

由于历史上缺乏IP地址(IPv4仅提供约40亿个地址),因此将用户分组在一个公共地址下,位于路由器后面,它将转换通过该地址的数据包中的地址。 此过程称为网络地址转换(NAT)。 NAT有不同的类型,但是其中一些为UDP流分配了一个公共IP地址和一个端口(我们需要)。 WebRTC使用ICE(交互式连接建立)框架来发现用户的公共IP地址并将其传达给其对等方。

ICE does so using a STUN (Session Traversal Utilities for NAT) server. Such a server does nothing much, you simply send requests to it. If you are behind a NAT, a request will go through it and the NAT will set its own public address and port on it. The STUN server receives that request and returns it to you, you now have the NAT public address and port. In the best case scenario, that is enough. You communicate this address to your peer, he sends you his own address and you establish a peer-to-peer connection.

ICE使用STUN(用于NAT的会话遍历实用程序)服务器进行此操作。 这样的服务器无济于事,您只需向它发送请求。 如果您在NAT后面,则将通过该请求,并且NAT将在其上设置其自己的公共地址和端口。 STUN服务器接收到该请求并将其返回给您,您现在有了NAT公共地址和端口。 在最佳情况下,这就足够了。 您将此地址传达给您的对等方,他将您自己的地址发送给您,并且您建立了对等连接。

But not all NATs let you establish a peer-to-peer connection. Some allocate a public IP address and a port to each external source. That means that the public address and the port that were allocated for messages from the TURN server will not work for the peer you are trying to establish a connection with. In cases like this, you need another solution: the communication has to go through a TURN server. TURN stands for Traversal Using Relays around NAT. As the name says, the connection will go through a relay server and is not technically a peer-to-peer connection anymore.

但是,并非所有NAT都允许您建立对等连接。 有些分配给每个外部源一个公共IP地址和一个端口。 这意味着为来自TURN服务器的消息分配的公用地址和端口不适用于您试图与其建立连接的对等方。 在这种情况下,您需要另一种解决方案:通信必须通过TURN服务器。 TURN表示在NAT周围使用中继进行遍历。 顾名思义,该连接将通过中继服务器,从技术上讲,它不再是对等连接。

The good news is, you don’t have to take care of it yourself. The ICE agent takes care of this exploration and decision making for you, checks the possibility of a direct connection, and if it can’t be done, establishes the connection over a TURN server. The ICE agent comes up with candidates, the only thing you have to do is send these candidates over the signaling medium. Once the best candidate has been selected, the WebRTC connection is established and users can start their video call.

好消息是,您不必自己照顾它。 ICE代理会为您进行这种探索和决策,检查直接连接的可能性,如果无法完成,则通过TURN服务器建立连接。 ICE代理提出了候选对象,您唯一要做的就是通过信令介质发送这些候选对象。 选择最佳候选者后,将建立WebRTC连接,用户可以开始视频通话。

That is all there is to know to understand the basics of WebRTC. If you want to learn more about NATs, ICE, STUN and TURN you can check this article. It goes into more details and shows with JavaScript code examples how this is handled in an application using WebRTC.

了解WebRTC的基础知识就是这些。 如果您想了解有关NAT,ICE,STUN和TURN的更多信息,可以查看本文 。 它有更多细节,并通过JavaScript代码示例显示了如何在使用WebRTC的应用程序中对此进行处理。

To build your own video chat using WebRTC you can follow this series of articles:

要使用WebRTC建立自己的视频聊天,您可以阅读以下系列文章:

Each step is pretty detailed. I am working on a more concise tutorial showing how to establish a WebRTC connection (step 1, 2 and 3) in a few lines of code. article will come out soon, you can wait for it if you are looking for a fast dive-in into implementing your own video chat over WebRTC.

每个步骤都非常详细。 我正在编写一个更简洁的教程,该教程显示了如何用几行代码来建立WebRTC连接(步骤1、2和3)。 文章很快就会发布,如果您希望快速了解如何通过WebRTC实现自己的视频聊天,可以等待。

翻译自: https://levelup.gitconnected.com/webrtc-basic-overview-for-developers-435ed9703550

webrtc开发

WebRTC 简介 WebRTC,名称源自网页实时通信(Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音通话或视频聊天的技术,是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。 WebRTC提供了实时音视频的核心技术,包括音视频的采集、编解码、网络传输、显示等功能,并且还支持跨平台:windows,linux,mac,android。 虽然WebRTC的目标是实现跨平台的Web端实时音视频通讯,但因为核心层代码的Native、高品质和内聚性,开发者很容易进行除Web平台外的移殖和应用。很长一段时间内WebRTC是业界能免费得到的唯一高品质实时音视频通讯技术。 为什么需要 WebRTC 开发者教程? 虽然WebRTC技术已经较为成熟,其集成了最佳的音/视频引擎,十分先进的codec,且包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透等众多门槛并不低的技术。抛开音视频技术本身的复杂性外,要想找到合适的资料、完整的代码和库、配合合适的IDE和辅助工具能正常地实现编译和安装都非常的不容易,而这还只是个开始。没有靠谱的教程,你该怎么开始?那么地坑等在那,难道你打算一个一个趟过去? 本《WebRTC 零基础开发者教程》主要讲了什么 本文中提供下载的《WebRTC 零基础开发者教程》将以一个初学者的角度,从0开始逐步引导你掌握WebRTC开发的方方面面(当然,教程中更多的是操作性的内容,具体到技术原理和实现,显然不是本教程的讨论范畴)。 《WebRTC 零基础开发者教程》目录 1 工具 1.1 depot_tools 1.1.1 目标 1.1.2 Chromium 1.1.3 使用说明在这儿 1.1.4 下载 1.1.5 使用 1.1.6 具体使用例子 1.2 Gyp工具 1.3 Python工具 1.4 本地集成开发环境(IDE ) 1.4.1 Visual studio 1.4.2 Kdevelop 1.4.3 Eclipse 2 Webrtc 2.1 下载、编译 2.1.1 Windows下 2.1.2 ubuntu下编译 2.1.3 编译Android(只能在 linux 下) 3 webrtc开发 3.1 开发P2P视频软件需要处理的问题 3.1.1 用户列的获取、交换、信令的交换 3.1.2 P2P通信 3.1.3 多媒体处理 3.2 webrtc架构 3.2.1 WebRTC架构组件介绍 3.2.2 WebRTC核心模块API介绍 3.2.3 webRTC核心API详解 4 Libjingle详细介绍 4.1 重要组件 4.1.1 信号 4.1.2 线程和消息 4.1.3 名称转换 4.1.4 SSL支持 4.1.5 连接 4.1.6 传输,通道,连接 4.1.7 候选项 4.1.8 数据包 4.2 如何工作 4.2.1 Application模块 4.2.2 XMPP Messaging Component 模块 4.2.3 Session Logic and management commponent 模块 4.2.4 Peer to peer Component 模块 4.2.5 其他 4.3 建立libjingle应用程序 5 代码分析 5.1 音频通道建立过程 5.2 音频接收播放过程 5.3 视频接收播放过程 6 协议 6.1 XMPP协议 6.1.1 原理介绍 6.1.2 XMPP 协议网络架构 6.1.3 XMPP 协议的组成 6.1.4 Xmpp介绍 6.1.5 协议内容 6.2 Stun协议 6.2.1 P2P实现的原理 6.2.2 P2P的常用实现 6.2.3 Stun URI 6.2.4 内容 6.2.5 中文内容 6.2.6 开源服务器 6.2.7 公开的免费STUN服务器 6.3 Turn协议 6.3.1 概念 6.3.2 Turn uri 6.3.3 开源服务器工程 6.3.4 开源库 6.4 交互式连接建立(Interactive Connectivity Establishment) 6.4.1 IETF规格 6.4.2 开源工程 6.5 XEP-0166 Jingle 6.5.1 绪论 6.5.2 需求 6.6 Sctp协议 6.7 Rtp协议 7 附件 7.1 Gyp工具 7.2 Google test程序 7.3 Webrtc库介绍 7.4 webrtc代码相关基础知识 7.5 STUN和TURN技术浅析 7.6 基于ICE的VoIP穿越NAT改进方案 7.7 ubuntu安装使用stuntman 7.8 一个开源的ICE库——libnice介绍 7.9 4种利用TURN穿越对称型NAT方案的设计与实现 7.10 基于ICE方式SIP信令穿透Symmetric_NAT技术研究
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值