当前位置: 首页 > news >正文

webrtc初了解

1. webrtc的简介

一、WebRTC 是什么?
Web Real-Time Communication(网页实时通信),是浏览器原生支持的实时音视频通信技术,无需安装插件或客户端,可直接在浏览器之间实现点对点(P2P)通信。
核心目标:让浏览器具备实时数据传输能力(音视频、文本、文件等),常用于视频会议、直播连麦、在线教育等场景。

二、WebRTC 的角色定位

  1. 核心在客户端(浏览器)
    WebRTC 是 浏览器内置的 API 和协议栈(如 getUserMedia、RTCPeerConnection 等),用于在 客户端之间直接建立实时连接(如音视频流、数据传输)。
    举例:当你用浏览器打开腾讯会议时,WebRTC 负责在你的浏览器和对方浏览器之间直接传输音视频数据,无需依赖中间服务器转发(除非无法直连时才通过服务器中转)。

  2. 需要服务端辅助
    虽然 WebRTC 支持客户端直连,但仍需服务端完成以下关键任务:

    • 信令交互(Signaling):客户端需通过服务端交换连接元数据(如 IP 地址、端口、编解码参数等),这是建立 P2P 连接的前提(类似打电话前先通过短信约定时间)。
    • NAT 穿透失败时的中继:若客户端因防火墙限制无法直连,需通过服务端中转数据(此时服务端作为 “中继服务器”)。
    • 房间管理、用户鉴权:多人会议场景中,服务端负责管理用户列表、房间创建 / 销毁等逻

** 三、WebRTC架构**
在这里插入图片描述
Web API 层:由 W3C 组织编辑制定,是面向 Web 开发者的 JavaScript API,如RTCPeerConnection用于在浏览器间建立直接通讯,DataChannel实现节点间双向数据传输 。通过这些 API,开发者能轻松开发网络视频聊天等 Web 应用。

传输层:

  • RTP Stack 协议栈:即 Real - Time Protocol(实时协议) ,用于音视频数据的实时传输。
  • STUN/ICE:STUN(Session Traversal Utilities for NAT ,NAT 会话穿越应用程序)和 ICE(Interactive - – Connectivity Establishment ,交互式连通建立)用于建立不同类型网络间的呼叫连接,实现 NAT 穿透。
  • SRTP:安全实时传输协议(Secure Real - Time Transport Protocol),对传输的音视频数据进行加密 。
    Multiplexing:复用技术,提高传输效率 。

音频引擎(VoiceEngine) :

  • 编解码器:iSAC(Internet Speech Audio Codec)是针对 VoIP 和音频流的宽带及超宽带音频编解码器,为默认编解码器;iLBC(Internet Low Bitrate Codec)是 VoIP 音频流的窄带语音编解码器 。
  • NetEQ for Voice:具备自适应抖动控制和语音包丢失隐藏算法,可适应网络环境变化,保障音质 。
    回声消除(Echo Canceler):消除麦克风采集到的回声 。
  • 噪声抑制(Noise Reduction):降低特定背景噪声 。

视频引擎(VideoEngine) :

  • VP8 编解码器:是默认视频图像编解码器,针对低延迟设计,适合实时通信 。
  • 视频抖动缓冲器(Video jitter buffer):降低视频抖动和数据包丢失带来的不良影响 。
  • 图像增强(Image enhancements):对采集图像进行明暗度检测、颜色增强、降噪等处理,提升视频质量 。

四、webRTC的应用场景

  • 操作系统兼容:WebRTC 具备跨操作系统的兼容性,在移动平台方面,支持主流的 Android 和 iOS 系统 。在 PC 端,对 Windows、macOS、Linux 等常见操作系统也能很好适配。就像在 Android 手机和平板上可借助相关应用基于 WebRTC 实现实时音视频通话;在 Windows 电脑上用浏览器访问视频会议网站,也能基于 WebRTC 技术进行实时交流。
  • 浏览器适配:WebRTC 是浏览器原生支持的技术,主流浏览器如 Chrome、Firefox 等在移动和 PC 端均支持 WebRTC 。这意味着开发者基于 WebRTC 开发的实时通信应用,用户无需额外安装插件,直接在浏览器中就能使用,使用便捷性高。

2 基本概念

2.1 网络基本知识

一、本地链路地址(无网络连接时的IP)

  • 存在场景
    当设备未连接路由器或DHCP服务器(如断开网线、未连Wi-Fi)时,系统会自动生成本地链路地址(如IPv4的169.254.x.x或IPv6的fe80::开头地址)。
    关键点它不是“没有IP”,而是系统自动分配的临时地址,用于同一链路内(如直连的两台设备)的通信。
  • 作用
    • 无需路由器即可实现设备间临时互传文件、共享资源。
    • 提示网络故障:若联网后仍显示此地址,说明设备无法从路由器获取正常IP(如DHCP服务异常)。

二、局域网IP(路由器分配的私有IP)

  • 定义
    设备连接到路由器后,由路由器(通过DHCP协议)分配的私有IP地址,属于局域网(LAN)范围
  • 常见地址段(IPv4):
    • 192.168.x.x(最常见,如192.168.1.100
    • 10.x.x.x(如10.0.0.5
    • 172.16.x.x~172.31.x.x(如172.16.1.20
  • 特点
    • 仅在局域网内有效,无法直接被互联网访问。
    • 同一路由器下的设备通过局域网IP互相通信(如手机连接家用Wi-Fi后,与电脑共享文件)。
  • 与本地链路地址的区别
    • 局域网IP由路由器分配,属于正常联网状态;本地链路地址由系统自动生成,属于无路由联网状态。
    • 局域网IP支持跨子网通信(通过路由器转发),而本地链路地址仅限同一链路内通信。

三、公网IP(通过NAT映射的互联网IP)

  • 定义
    公网IP是直接连接互联网的唯一标识,具有全球唯一性。但大多数家庭/企业网络中,路由器会通过 NAT(网络地址转换)技术,将局域网内的多个私有IP共享一个公网IP访问互联网。
  • 实现逻辑
    • 当局域网内设备(如手机)访问互联网时,路由器会将设备的私有IP(如192.168.1.100)和端口(如8080),映射为路由器的公网IP和一个随机端口(如202.100.1.1:50001)。
    • 互联网服务器返回数据时,通过公网IP和端口找到路由器,路由器再根据映射关系将数据转发给对应的局域网设备。
  • 公网IP的类型
    • 动态公网IP:由运营商动态分配(多数家庭宽带属于此类),每次重启路由器可能变更。
    • 静态公网IP:需向运营商申请,地址固定(常用于企业服务器或需要远程访问的场景)。
  • 关键点
    • 公网IP不是“端口”,而是IP地址本身;端口是NAT映射时用于区分不同设备的“通道编号”。
    • 只有拥有公网IP的设备(如路由器)才能被互联网直接访问,局域网内设备需通过NAT“借道”路由器上网。

四、关系

“当设备未连接路由器时,系统会自动生成本地链路地址(如169.254.x.x)用于临时通信;连接路由器后,设备获取局域网IP(如192.168.1.x),属于私有地址,仅在局域网内有效;路由器通过 NAT技术,将局域网IP和端口映射到公网IP(运营商分配的互联网地址),实现多设备共享一个公网IP访问互联网。”

五、核心区别总结表

类型分配方式地址范围/示例能否被互联网访问典型场景
本地链路地址系统自动生成(无路由)IPv4: 169.254.x.x否(仅限本地链路)两台直连电脑互传文件
局域网IP(私有)路由器DHCP分配IPv4: 192.168.x.x否(需通过NAT转发)家用Wi-Fi下手机与电脑共享文件
公网IP(公有)运营商分配(静态/动态)202.100.1.1是(全球唯一)路由器连接互联网、服务器对外服务

NAT 模式的本质:共享你电脑的网络,但藏起虚拟机你电脑的真实网络:

  • 比如你电脑连了家里的 Wi-Fi,有一个真实的 IP(比如 192.168.1.100),能上网。
  • 虚拟机的 “虚拟小网络”:
    当你用 NAT 模式启动虚拟机时,软件会在你电脑里偷偷创建一个 虚拟路由器 和 虚拟宽带:
    • 虚拟路由器:负责把虚拟机的网络请求 “转发” 到你电脑的真实网络(就像你家真实路由器把手机请求转发到宽带一样)。
    • 虚拟宽带:让虚拟机 “假装” 自己连了一个独立的网络,但其实用的是你电脑的网络流量。

关键:虚拟机的 IP 是 “虚拟路由器” 分配的:
就像你家路由器会给手机分配 192.168.1.101 这样的 IP 一样,虚拟机软件里的 “虚拟路由器” 会给虚拟机分配一个 虚拟局域网 IP(比如 192.168.137.100),这个 IP 只在你电脑的虚拟网络里有效。

2.2 webrtc的痛点以及解决

一、媒体协商:SDP 协议确定编解码规则
目标:解决“如何让双方解对方的码”的问题,本质是协商一致的音视频格式与参数

  1. SDP(Session Description Protocol,会话描述协议)
    • 作用
      • 描述终端支持的编解码器(如 VP8/H.264 视频、Opus/iSAC 音频)。
      • 协商媒体传输格式(如 RTP 载荷类型、时间戳频率)。
      • 提供网络连接元数据(如 IP 地址、端口,但实际中常由 ICE 处理)。
    • 核心字段
      • m=video 9 UDP/TLS/RTP/SAVPF 100 101:声明视频流使用的端口和编解码列表(如 payload 100 对应 VP8)。
      • a=rtpmap:100 VP8/90000:将 payload 100 映射到 VP8 编解码器,采样率 90000Hz。
      • a=fingerprint:sha-256 ...:用于 DTLS 加密的证书指纹验证。
    • 协商流程

在这里插入图片描述

  • 关键逻辑
    • 双方通过信令服务器交换 SDP,最终达成交集编解码方案(如均支持 VP8 则选 VP8,否则降级)。
    • SDP 不直接传输媒体数据,仅用于“对暗号”,确保双方使用相同规则编解码。

二、网络协商:ICE 框架整合 STUN/TURN 实现连接建立
目标:解决“双方公网 IP 是否能通信”的问题,本质是穿越 NAT 建立有效连接路径

1. ICE(Interactive Connectivity Establishment,交互式连接建立)

  • 定位
    • 不是协议,而是整合 STUN/TURN 的框架,用于收集、测试、选择最优网络路径。
    • 核心流程:收集候选地址 → 排序优先级 → 尝试连接
  • 候选地址类型
    • 主机候选(Host):终端本地 IP(如虚拟机内网 IP 192.168.137.100)。
    • 服务器反射候选(SRFLX):通过 STUN 服务器获取的公网 IP+端口(如 202.100.1.1:50001)。
    • 中继候选(RELAY):通过 TURN 服务器中转的地址(如 39.100.200.5:8080)。

2. STUN:获取公网地址与 NAT 类型

  • 核心功能
    • 终端向 STUN 服务器发送请求,服务器返回终端的公网 IP+端口NAT 类型(如完全圆锥型、对称型)。
    • 用途
      • 判断是否可直接 P2P 连接(如对称型 NAT 需 TURN 中继)。
      • 生成“服务器反射候选地址”用于 ICE 连接测试。
  • 典型交互流程
    客户端 → STUN服务器:"我在哪?"  
    STUN服务器 → 客户端:"你的公网地址是 X.X.X.X:端口,NAT类型是对称型"  
    
  • 局限性
    • 仅适用于UDP 穿透,且无法穿越对称型 NAT(约占 30% 网络环境)。
      在这里插入图片描述

3. TURN:中继转发突破复杂网络限制

  • 核心功能
    • 当 STUN 无法建立直连时,作为中继服务器转发媒体数据,充当“数据中转站”。
    • 适用场景
      • 双方均位于对称型 NAT 后(无法直连)。
      • 防火墙禁止 UDP 传输(TURN 可封装数据为 TCP)。
  • 代价与优化
    • 带宽成本:数据经服务器中转,消耗服务器带宽(适合多人会议场景,单人通话尽量走 P2P)。
    • 延迟增加:中继路径增加约 1 个 RTT 延迟,需结合 CDN 部署多区域 TURN 节点降低延迟。
    • 在这里插入图片描述

2.3 信令服务器

一、信令服务器的核心作用
信令服务器不直接传输音视频或数据,而是负责协调通信双方的连接过程,主要功能包括:

  • 交换元数据
    传递双方的媒体信息(如编码格式、分辨率)、网络信息(如公网 IP、端口)。
    例如:通过 SDP 协议描述媒体参数,通过STUN/TURN 获得的网络地址需通过信令服务器中转
  • 控制通信流程
    • 管理连接的建立、断开、重连等状态(如发起呼叫、接受 / 拒绝请求)。
    • 类似 “电话交换机”,只负责建立通话链路,不参与通话内容传输。

二、数据传输的两种场景

  1. 直接 P2P 传输(无需信令服务器)
    条件:双方处于同一局域网(网段相同)或公网可直接互通(无 NAT 或 NAT 类型支持 P2P)。
    过程:
    双方直接获取对方的 IP 和端口(如通过本地广播、预共享信息)。
    无需信令服务器中转,直接建立连接传输数据(如文件、消息)。
    局限:
    受限于网络环境(NAT 穿透失败时无法通信)。
    无法处理复杂场景(如多人通信、动态地址变更)。

2. 复杂网络环境下的传输(必须依赖信令服务器)
场景:

  • 双方位于不同网段(如虚拟机与主机、跨公网的两台设备)。
  • 存在 NAT 防火墙(需通过 STUN/TURN 穿透或中继)。
  • 多人通信(需协调多方的媒体流路由)。

过程:

  • 信令交互:
    设备 A 通过信令服务器向设备 B 发送连接请求(含自身媒体和网络信息)。
    设备 B 响应请求并返回自身信息(如经 STUN 解析的公网地址,或 TURN 中继地址)。
  • 媒体协商:
    双方通过信令服务器交换 SDP,协商一致的编解码格式。
  • 网络协商:
    若直接连接失败(如 NAT 类型不兼容),信令服务器协助分配 STUN/TURN 服务器地址,建立中继连接。
  • 关键依赖:
    信令服务器是建立连接的桥梁,没有它,双方无法得知彼此的 “通信地址” 和 “能力参数”。
    数据最终通过 P2P 或中继传输,但信令交互是前提。

信令服务器不只是交互 媒体信息sdp和网络信息candidate,比如:
(1)房间管理
(2)人员进出房间

3 peer to peer的原理

在这里插入图片描述

  1. 初始化阶段
  • 创建PeerConnection对象:Peer - A和Peer - B都各自创建一个RTCPeerConnection对象,这是WebRTC进行点对点通信的核心对象,用于管理连接、媒体流传输等操作 。
  • 添加媒体流:双方分别调用AddStream将本地采集的音视频媒体流添加到PeerConnection对象中,准备后续传输。比如,摄像头采集的视频流和麦克风采集的音频流。
  1. 媒体协商阶段
  • 创建Offer并设置本地描述:Peer - A通过CreateOffer & SetLocalDescription生成一个Offer SDP(会话描述协议)。SDP中包含了Peer - A支持的音视频编解码器(如VP8视频编解码器、Opus音频编解码器 )、媒体传输格式等信息 。然后将这个Offer SDP设置为本地描述,即告知自身后续通信使用这些媒体参数。
  • 信令服务器中继Offer SDP:Peer - A通过Send Offer SDPOffer SDP发送给信令服务器,信令服务器再通过Relay Offer SDP将其转发给Peer - B。
  • Peer - B处理Offer并生成Answer:Peer - B收到Offer SDP后,调用setRemoteDescription设置远程描述,即知晓Peer - A的媒体参数。然后Peer - B通过CreateAnswer & SetLocalDescription生成Answer SDP,其中包含了Peer - B根据自身能力和Peer - A的Offer SDP协商后的媒体参数 。
  • 信令服务器中继Answer SDP:Peer - B通过Send Answer SDPAnswer SDP发送给信令服务器,信令服务器再通过Relay Answer SDP转发给Peer - A,Peer - A收到后调用setRemoteDescription设置远程描述。
  • 媒体协商总结:通过SDP在信令服务器的中继下交换,双方确定了一致的音视频编解码等媒体参数,解决了双方如何编解码媒体流的问题,确保双方能正确处理对方传来的音视频数据。
  1. 网络协商阶段
  • ICE候选地址收集
    • Peer - A和Peer - B在本地通过ICE Request触发ICE(交互式连接建立)流程,收集各自的ICE候选地址。这些候选地址包括主机候选地址(本地局域网IP地址 )、服务器反射候选地址(通过STUN服务器获取的公网IP地址 )和中继候选地址(通过TURN服务器获取的地址 )。
    • 当收集到ICE候选地址时,会触发oniceCandidate事件。
  • 信令服务器中继ICE候选地址
    • Peer - A和Peer - B分别通过Send ICE Candidate将各自的ICE候选地址发送给信令服务器,信令服务器通过Relay ICE Candidate相互转发。
    • 双方收到对方的ICE候选地址后,通过AddIceCandidate将其添加到PeerConnection对象中。
  • 连接建立尝试:双方根据收集到的ICE候选地址,按照优先级(通常主机候选 > 服务器反射候选 > 中继候选 )尝试建立连接。如果双方处于可以直接穿透NAT的网络环境,可能通过主机候选地址或服务器反射候选地址直接建立P2P连接 。但如果像在中国网络环境下,至少一半网络无法直接穿透打洞,就需要借助TURN服务器,通过中继候选地址进行数据中继转发来建立连接。
  1. 媒体流传输阶段
    当连接成功建立后,双方就可以通过已建立的链路进行媒体流传输。Peer - A和Peer - B分别通过onAddStream事件接收对方传来的媒体流,并进行播放展示,从而实现一对一的实时通话 。

  2. 信令服务器的作用
    信令服务器在整个过程中扮演着至关重要的角色。它负责中继双方的SDP信息和ICE候选地址等信令消息,协调双方的媒体协商和网络协商过程。没有信令服务器,双方无法得知对方的媒体参数和网络地址信息,也就无法建立起通信连接 。

  3. STUN和TURN服务器的作用

  • STUN服务器:帮助Peer - A和Peer - B获取自身的公网IP地址和端口,以及检测所在的NAT类型 。在网络协商中,用于生成服务器反射候选地址,尝试实现P2P连接。
  • TURN服务器:当STUN无法成功穿透NAT建立P2P连接时,TURN服务器作为中继,对双方的数据进行转发。在复杂网络环境下,保障通话能够顺利进行 。

相关文章:

  • uniapp+ts模拟popup弹出框(下拉框)
  • 解决 xmlsec.InternalError: (-1, ‘lxml xmlsec libxml2 library version mismatch‘)
  • Spring Boot 整合 Spring Data JPA、strategy 的策略区别、什么是 Spring Data JPA
  • window11系统 使用GO语言建立TDengine 连接
  • TDengine 运维——巡检工具(安装工具)
  • Oracle 临时表空间详解
  • Dynamics 365 Business Central AI Sales Order Agent Copilot
  • Deepseek应用技巧-Dify本地化搭建合同审批助手
  • 【面板数据】上市公司供应链网络地位数据(2001-2024年)
  • solidworks报错-只有合并特征才能被阵列。如果恰当,请选择实体的阵列
  • 解释k8s种ConfigMap和Secret的作用,如何在Pod中挂载环境变
  • 时间序列噪声模型分析软件推荐与使用经验
  • [9-1] USART串口协议 江协科技学习笔记(13个知识点)
  • 基于生产-消费模式,使用Channel进行文件传输(Tcp方式)
  • Rocky Linux上安装Go
  • 66常用控件_QTableWidget的使用
  • Win11安装Dify
  • APM32微控制器键盘PCB设计实战教程
  • Scratch节日 | 拯救屈原 | 端午节
  • WPF的布局核心:网格布局(Grid)
  • 保定市做网站的公司/广东省人大常委会
  • 最好的手机资源网站/太原关键词优化公司
  • 网站建设实例教程/怎么在百度上做网站
  • 陕西省建设造价协会网站/快速排名优化
  • 做网站搜索如何显示官网/百度搜索服务
  • 桂林森禾医药有限公司/seo网络营销的技术