- 博客(137)
- 收藏
- 关注
RSS订阅原创 构建一个完整的 WebRTC 通信系统 (架构篇)
完整 WebRTC 系统架构:| 负载均衡器 || | || 信令服务器 | | API 服务器 | | Web 服务器 || (WebSocket) | | (REST) | | (静态资源) || || | 数据库 || | (用户/房间) || 消息队列 || SFU 集群 | | TURN/STUN || 客户端 |组件技术职责信令服务器信令交换API 服务器Node.js/Go业务逻辑SFUmediasoup媒体转发TURNcoturnNAT 穿透。
2025-12-29 22:08:10
950
原创 WebRTC 安全机制 (DTLS、SRTP、ICE、权限管理)
WebRTC 安全层次:| 应用层安全 | 身份认证、授权| 信令层安全 | HTTPS/WSS| 媒体层安全 | SRTP/SRTCP| 传输层安全 | DTLS| 网络层安全 | ICE 验证特点:- 强制加密 (无明文传输)- 端到端加密 (媒体)- 身份验证- 完整性保护- TLS 的 UDP 版本- 提供加密和认证- WebRTC 强制使用DTLS 版本:- DTLS 1.0 (基于 TLS 1.1)
2025-12-29 22:07:26
562
原创 WebRTC 质量优化: 码率、延迟、卡顿、丢包
WebRTC 质量核心指标:1. 视频质量- 分辨率- 帧率- 清晰度 (PSNR/SSIM)2. 音频质量- 采样率- 音量- 清晰度 (MOS)3. 实时性- 端到端延迟- 抖动4. 流畅性- 卡顿率- 丢帧率5. 可靠性- 连接成功率- 掉线率质量优化检查清单:[ ] 码率配置合理[ ] 分辨率/帧率匹配场景[ ] Jitter Buffer 大小适当[ ] NACK/FEC 策略正确[ ] 自适应降级策略[ ] 网络监控告警[ ] 定期质量测试。
2025-12-28 07:00:00
379
原创 WebRTC 调试: 抓包、RTCStats、webrtc-internals
WebRTC 调试难点:1. 实时性- 问题转瞬即逝- 难以复现2. 复杂性- 多协议栈 (ICE/DTLS/SRTP/RTP/RTCP)- 多组件交互3. 网络依赖- NAT 穿透问题- 网络波动影响4. 端到端- 发送端/接收端/服务器- 需要多点协同调试工具优点缺点适用场景无需代码,实时仅限浏览器快速诊断可编程,灵活需要开发监控系统Wireshark协议级分析学习曲线高深度调试。
2025-12-28 06:15:00
291
原创 WebRTC 数据通道 (RTCDataChannel)
RTCDataChannel 特点:- P2P 数据传输通道- 支持任意数据 (文本/二进制)- 可靠/不可靠传输可选- 有序/无序传输可选- 低延迟特性说明协议可靠性可配置 (可靠/不可靠)有序性可配置 (有序/无序)数据类型文本/二进制流量控制。
2025-12-27 07:00:00
339
原创 在移动端使用 WebRTC (Android/iOS)
移动端 WebRTC 挑战:1. 硬件差异- 不同设备性能差异大- 摄像头/麦克风规格不同2. 网络环境- WiFi/4G/5G 切换- 网络不稳定3. 电量消耗- 编解码耗电- 网络传输耗电4. 后台限制- iOS 后台限制严格- Android 后台服务限制5. 权限管理- 摄像头/麦克风权限- 后台运行权限平台SDK特点Android原生性能好iOS原生性能好Flutter跨平台跨平台恭喜你完成了 WebRTC 技术专栏的全部学习!Part 1。
2025-12-27 06:45:00
595
原创 搭建一个 SFU (以 mediasoup 为例)
mediasoup 特点:- 高性能 SFU 媒体服务器- Node.js API + C++ 核心- 支持 WebRTC 和 ORTC- 支持 Simulcast 和 SVC- 开源免费 (ISC License)组件功能Worker媒体处理进程Router房间路由TransportWebRTC 传输Producer发布流Consumer订阅流。
2025-12-26 07:00:00
868
原创 WebRTC SFU 架构详解: 为什么需要 SFU?
WebRTC 多人通信三种架构:1. Mesh (网状)- 每个参与者直接连接其他所有人- 纯 P2P,无服务器- 所有流汇聚到服务器- 服务器混流后分发- 所有流汇聚到服务器- 服务器选择性转发架构适用场景关键特点Mesh小型通话无服务器,延迟低MCU传统会议混流,客户端简单SFU现代会议转发,灵活高效。
2025-12-26 06:45:00
424
原创 构建自己的 WebRTC 信令服务器 (Node.js 实战)
信令服务器职责:1. 用户管理- 用户连接/断开- 用户身份标识2. 房间管理- 创建/加入/离开房间- 房间成员列表3. 消息转发- 自定义消息4. 状态同步- 用户状态- 房间状态组件功能WebSocket实时双向通信房间创建/加入/离开信令消息路由客户端PeerConnection 管理。
2025-12-25 07:00:00
754
原创 WebRTC 中的 Simulcast 与 SVC (多路与分层编码)
多人视频会议场景:发送端 (1080p 摄像头)│v+--------+| SFU |+--------+│├──> 接收端 A (大屏幕, 高带宽) -> 需要 1080p│├──> 接收端 B (笔记本, 中带宽) -> 需要 720p│└──> 接收端 C (手机, 低带宽) -> 需要 360p问题:- 单一码流无法满足所有接收端- 需要多种质量的视频流技术适用场景关键配置Simulcast多人会议,兼容性优先SVC大规模会议,带宽优先混合复杂场景。
2025-12-25 05:30:00
449
原创 音频处理: AEC、AGC、NS、VAD
实时通话中的音频问题:1. 回声 (Echo)- 扬声器播放的声音被麦克风采集- 对方听到自己的声音2. 噪声 (Noise)- 环境噪声: 风扇、空调、交通- 设备噪声: 电流声、底噪3. 音量不一致- 不同设备音量差异大- 说话距离变化4. 静音检测- 不说话时浪费带宽- 需要检测语音活动模块功能关键参数AEC消除回声滤波器长度、收敛速度AGC自动增益目标电平、攻击/释放时间NS噪声抑制抑制强度、噪声估计VAD语音检测能量阈值、挂起时间。
2025-12-24 13:17:22
362
原创 WebRTC 视频编码基础 (VP8/VP9/H.264/AV1)
原始视频数据量:- 分辨率: 1920 x 1080- 颜色深度: 24 bits (RGB)- 帧率: 30 fps数据量 = 1920 x 1080 x 24 x 30 = 1.49 Gbps经过编码后:压缩比: 300-1000 倍场景推荐编码器原因1:1 视频通话VP8/H.264低延迟,兼容性好多人会议VP9SVC 支持,带宽效率屏幕共享VP9/AV1屏幕内容优化移动端H.264硬件加速高质量录制AV1最佳压缩效率。
2025-12-24 13:16:55
900
原创 媒体流与轨道模型 (Track / Stream / Transceiver)
WebRTC 媒体模型层次 || || 应用层 || | MediaStream | 包含多个 Track || | || v || 传输层 || | (发送轨道) | | (接收轨道) | || | | || v v || | RTCRtpTransceiver| 双向媒体通道 || | || v || | RTCPeerConnection| 管理所有 Transceiver || |概念说明单个媒体轨道发送媒体接收媒体双向通道Simulcast多流发送。
2025-12-22 11:16:27
1117
原创 带宽估计 BWE (WebRTC 的智能网络优化核心)
网络带宽动态变化:时间 -->带宽 | ____| / \____| / \ ____| / \__/ \|/ \____问题:- 发送码率 > 可用带宽 -> 拥塞、丢包、延迟增加- 发送码率 < 可用带宽 -> 浪费带宽、质量下降目标:- 实时估计可用带宽- 动态调整发送码率- 最大化质量,最小化延迟组件作用Trendline检测延迟趋势AIMD码率增减控制丢包响应Pacer平滑发送Prober带宽探测。
2025-12-22 11:15:54
931
原创 两条通往AGI的道路：当我们为错误的未来做准备时
2023年，ChatGPT向世界展示了大语言模型的潜力。2024年，我们看到了AI代理的爆发。2025年，MCP等协议开始标准化代理间通信。基础设施已经就位。
2025-12-22 10:28:10
940
原创 抖动缓冲区 (Jitter Buffer) 与网络抗性
网络抖动 (Jitter) 是指数据包到达时间间隔的变化。理想情况 (无抖动):发送: |--20ms--|--20ms--|--20ms--|--20ms--|接收: |--20ms--|--20ms--|--20ms--|--20ms--|实际情况 (有抖动):发送: |--20ms--|--20ms--|--20ms--|--20ms--|接收: |--15ms--|--30ms--|--10ms--|--25ms--|^ ^ ^抖动 抖动 抖动。
2025-12-21 07:45:00
991
原创 SRTP: 安全加密传输层 (DTLS-SRTP)
WebRTC 安全层次 || || 应用数据 (音视频/DataChannel) || | || v || | (媒体数据加密) | | (数据通道) | || | | || | || v || | (密钥交换/认证) | || | || v || |要点说明DTLSUDP 上的 TLS,用于密钥交换证书验证通过 SDP fingerprint密钥导出从 DTLS master secret 导出SRTP 加密认证10 字节 Auth Tag。
2025-12-20 08:30:00
597
原创 完整的 WebRTC 信令流程图 (从建立到关闭)
DTLS (Datagram Transport Layer Security) 是 TLS 在 UDP 上的实现,用于在 WebRTC 中建立安全通道。1. Offer/Answer 交换- 交换媒体能力 (编解码器、方向)- 交换 ICE 凭据和 DTLS 指纹- 收集本地候选 (host, srflx, relay)- 交换候选地址3. ICE 连通性检测- STUN Binding 请求/响应- 选择最优候选对4. DTLS 握手- 建立安全通道。
2025-12-19 07:30:00
688
原创 RTP 协议与 Media Stream 结构解析
本文深入解析RTP(实时传输协议)的结构与工作原理。RTP是WebRTC媒体传输的核心协议，其设计注重实时性、时间同步和源标识。文章详细剖析了RTP包格式，包括12字节的固定头部(含版本号、填充位、扩展位等)、CSRC列表、扩展头部和负载数据。重点讲解了序号、时间戳、SSRC/CSRC等关键字段的作用，以及RTP包与媒体帧的映射关系。通过对比音频和视频RTP包的典型大小，展现了不同媒体类型的传输特点。RTP协议为实时音视频传输提供了基础时序和同步机制。
2025-12-19 07:00:00
696
原创 STUN: 外网地址发现 (含协议解析)
STUN (Session Traversal Utilities for NAT) 是一种网络协议,用于发现 NAT 设备并获取经过 NAT 映射后的公网地址。STUN 定义在 RFC 5389 中。要点说明作用发现 NAT 映射的公网地址协议UDP 为主,也支持 TCP端口默认 3478 (TLS: 5349)消息类型关键属性安全性。
2025-12-18 07:15:00
1559
原创 TURN: 中继服务器详解
TURN (Traversal Using Relays around NAT) 是 STUN 的扩展协议,定义在 RFC 5766 中。当 P2P 直连失败时,TURN 服务器作为中继,转发双方的媒体数据。要点说明作用P2P 失败时的中继方案协议STUN 的扩展,RFC 5766端口认证长期凭据或临时凭据开销高带宽消耗优先级ICE 中最低优先级。
2025-12-18 07:15:00
980
原创 ICE 框架 (Interactive Connectivity Establishment)
ICE (Interactive Connectivity Establishment) 是一个用于在 NAT 环境下建立点对点连接的框架,定义在 RFC 8445 中。ICE 整合了 STUN 和 TURN 协议,提供了一套完整的 NAT 穿透解决方案。要点说明候选类型候选优先级连通性检测使用 STUN Binding 请求状态机ICE Lite简化实现,适用于服务器ICE 重启网络变化时重新建立连接。
2025-12-17 11:15:00
665
原创 深度理解 SDP (Session Description Protocol)
SDP (Session Description Protocol) 是一种用于描述多媒体会话的文本协议,定义在 RFC 4566 中。媒体类型(音频、视频、数据)编解码器及其参数传输协议和端口加密参数网络连接信息WebRTC 使用 Offer/Answer 模型进行媒体协商,定义在 RFC 3264 中。│ Offer/Answer 模型 ││ ││ 发起方 (Offerer) 接收方 (Answerer) ││ ││ 1. 创建 Offer ││ │ ││ ▼ │。
2025-12-17 08:45:00
998
原创 RTCP: 统计、同步与网络自适应
RTCP (RTP Control Protocol) 是 RTP 的伴随协议,定义在 RFC 3550 中。传输统计信息(丢包率、延迟、抖动)同步多个媒体流标识参与者控制 RTP 会话要点说明SR发送者统计和时间戳映射RR接收质量报告丢包率抖动指数加权移动平均RTT同步使用 NTP-RTP 映射。
2025-12-16 10:33:58
688
原创 信令是什么?为什么 WebRTC 需要信令?
信令(Signaling)是指在建立实时通信会话之前,通信双方交换控制信息的过程。会话的发起和终止媒体能力的协商(编解码器、分辨率等)网络连接信息的交换(IP地址、端口等)会话状态的同步在 WebRTC 中,信令是建立点对点连接的前置步骤。没有信令,两个浏览器无法知道对方的存在,更无法建立连接。灵活性考虑视频会议可能需要房间管理、用户列表等功能一对一通话可能只需要简单的呼叫/应答机制直播场景可能需要与现有的直播系统集成兼容性考虑复用现有的信令基础设施(如 SIP、XMPP)
2025-12-16 10:29:19
834
原创 WebRTC 的 API 全景图（API 体系篇）
API用途获取摄像头/麦克风屏幕共享枚举设备恭喜你完成了 WebRTC 基础入门系列的学习！篇章主题核心收获第 1 篇概览篇理解 WebRTC 的定位、能力和应用场景第 2 篇架构篇掌握 WebRTC 的整体架构和组件关系第 3 篇实操篇动手实现一个完整的音视频通话 Demo第 4 篇理论篇深入理解 NAT 穿透、RTP 协议、音频处理第 5 篇API 篇全面掌握 WebRTC API 体系。
2025-12-16 08:45:00
960
原创 WebRTC 的三个关键技术（理论强化篇）
网络传输中，数据包的到达时间不均匀，这种现象称为抖动（Jitter）。发送时间: |──10ms──|──10ms──|──10ms──|──10ms──|到达时间: |──8ms──|──15ms──|──5ms──|──12ms──|抖动 = 到达间隔的变化WebRTC 使用算法进行带宽估计和拥塞控制。│ GCC 算法架构 ││ ││ │ 发送端 BWE │ ││ │ │ ││ │ │ 延迟梯度 │ │ 丢包率 │ │ 带宽估计 │ │ │。
2025-12-16 07:45:00
1019
原创 写一个最简单的 WebRTC Demo（实操篇）
我们将构建一个 1 对 1 的实时音视频通话应用，包含以下功能：2. 获取摄像头与麦克风2.1 基础 API：getUserMedia 是获取媒体设备的核心 API。2.2 处理权限和错误2.3 高级约束配置2.4 显示本地视频3. 建立 RTCPeerConnection3.1 创建 PeerConnection3.2 添加本地媒体轨道3.3 处理远端媒体流3.4 Offer/Answer 交换3.5 ICE 候选交换4. 实现完整的 P2P 音视频通话
2025-12-15 21:11:20
798
原创 WebRTC 架构概览（整体框架篇）
1.2 架构层次说明第一层：Web 应用层开发者编写的 JavaScript 代码，通过 WebRTC API 实现实时通信功能。第二层：WebRTC JavaScript API浏览器暴露给 JavaScript 的标准 API，由 W3C 定义：这是 libwebrtc 提供的 C++ 接口层，主要包含：包含三个主要模块：Session Management：会话管理Voice Engine：音频引擎Video Engine：视频引擎负责网络传输的协议栈：1.3 浏览器实现差异不同浏览器的
2025-12-15 21:06:22
1792
原创 WebRTC 是什么？能做什么？（概览篇）
方面要点定义浏览器原生的实时音视频通信技术标准化W3C（API）+ IETF（协议）核心组件核心优势无插件、低延迟、端到端加密、P2P主要局限大规模场景、NAT 穿透、移动端兼容。
2025-12-12 23:39:20
973
原创 “红色警报“后的反击：OpenAI 发布 GPT-5.2，AI 霸主之争白热化
GPT-5.2 的发布，标志着 OpenAI 与 Google 的AI霸主之争进入白热化阶段OpenAI：凭借快速迭代和迪士尼等重磅合作，试图守住领先地位Google：Gemini 3 强势崛起，用户增长迅猛，生态整合优势明显Anthropic：Claude 系列在编程领域仍保持一定优势更强的模型、更低的成本、更丰富的功能正在加速到来。** 发布信息**发布日期：2025年12月11日(大家可以在周四的更新后使用测试)可用范围：ChatGPT 付费用户、API 开发者。
2025-12-12 10:53:07
863
原创 WebRTC 信号槽机制：当 C++ 遇上观察者模式，代码解耦的优雅之道
信号槽是一种事件驱动Signal（信号）：事件的发送方。当某件事发生时，信号被"发射"出去。Slot（槽）：事件的接收方。槽是一个函数，当它连接的信号被发射时，槽函数会被调用。connect：将槽"连接"到信号上，建立订阅关系。emit：发射信号，触发所有已连接的槽。信号槽就是观察者模式的一种优雅实现。public:// 定义一个信号，携带 1 个参数（IceConnectionState）// signal1 表示 1 个参数，signal2 表示 2 个参数，以此类推。
2025-12-11 21:04:08
912
原创 WebRTC 中的临界锁实现：从 CritScope 到 RAII 机制的深度解析
RAII 是 C++ 之父 Bjarne Stroustrup 提出的一种编程惯用法，全称是Resource Acquisition Is Initialization（资源获取即初始化）。资源的获取（如分配内存、打开文件、获取锁）发生在对象构造时；资源的释放（如释放内存、关闭文件、释放锁）发生在对象析构时。由于 C++ 保证对象离开作用域时析构函数一定会被调用，因此资源的释放是自动且确定的。自动化资源管理：减少人为错误，避免忘记释放锁。异常安全：即使发生异常，锁也能正确释放。代码简洁。
2025-12-11 20:57:48
1056
原创 深入理解 WebRTC 临界锁实现与 C++ RAII 机制
直译为"资源获取即初始化"，是 C++ 中管理资源的核心惯用法。资源的获取发生在对象的构造函数中资源的释放发生在对象的析构函数中利用 C++ 的作用域规则，确保资源被正确释放特性RAII (C++)defer (Go)代码简洁度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐作用域精确控制⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐不易遗漏⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐异常安全⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐递归锁（Recursive Lock），也称为。
2025-12-10 16:15:34
331
原创 深入理解 WebRTC 视频质量降级机制
在实时音视频通话中，视频质量降级（Quality Limitation）是指系统主动降低视频的帧率或分辨率，以适应当前的硬件性能或网络带宽条件。这是一种典型的自适应策略（Adaptive Degradation），目的是在资源受限时优先保证通话的流畅性，而非追求极致的画质。在质量与流畅性之间取得平衡。宁可画面模糊，也要保证流畅宁可降低分辨率，也要避免卡顿宁可主动丢帧，也要防止延迟累积。
2025-12-10 16:08:12
483
原创 WebRTC 视频编码核心技术解析：从 GOP 结构到时间戳管理
NACK (重传)：通常用于恢复 P 帧丢失。如果 P 帧恢复不回来，解码器会报错。PLI (关键帧请求)：当 NACK 失败，或者接收端判定无法解码（如缺少参考帧）时，会触发 PLI，强制重置 GOP。Pacer (发送端平滑)：由于 I 帧巨大，必须通过 Pacer 将其拆分并在几百毫秒内平滑发送，防止瞬间流量突增导致网络拥塞。希望这篇文章能让你在面对 WebRTC 的或告警时，不仅知道“发生了什么”，更能明白“为什么发生”。
2025-12-09 22:45:00
1053
原创 WebRTC 视频轨道（Video Outbound）从采集到编码再到发送的完整流程解析
管线架构：WebRTC 视频出站管线分为采集、处理、编码、发送四个阶段，渲染和编码并行处理。：核心的帧分发组件，采用发布-订阅模式，将帧数据广播给所有 VideoSink 订阅者。编码器抽象：通过接口实现编码器的可插拔设计，支持 VP8、VP9、H264、AV1 等多种格式。RTP 封装：视频帧被切片为多个 RTP 包，每个包包含序列号、时间戳等关键元数据，最后一个分片设置 Marker 位。Pacing 机制：通过平滑发送流量，避免突发数据造成网络拥塞。安全传输。
2025-12-09 17:40:41
1071
原创 从零开始：用 Android Studio 开发一个 AI 智能日记 App
写这篇文章的目的，是想把我从完全不懂 Android 开发，到做出一个能用的 App 的过程记录下来，希望对同样想入门移动端开发的朋友有所帮助。后来我在 YouTube 上看到一个视频，博主用 iPhone 的快捷指令做了一个工作流：白天随时用语音记录零碎的想法（比如"今天中午吃的拉面不错"、“下午开会被老板骂了”），晚上让 AI 把这些碎片整理成一篇完整的日记。安装好之后，点 New Project，选择 Empty Activity（注意是 Compose 版本的，不是传统 View 版本）。
2025-12-08 19:15:49
1801
原创 作为一个学生，如何用免费 AI 工具手搓了一款 Android AI 日记 App
一开始我觉得分层好麻烦，写个简单的增删改查要写 Entity、Dao、Repository、UseCase、ViewModel 这么多文件。但后来我真香了。当我需要把原本的“仅支持 OpenAI”改成“支持 DeepSeek 和 Ollama”时，我发现我只需要修改Data层的一个实现类，UI 层完全不用动！这就是解耦的快乐。看着手机里这个自己亲手（虽然大部分是 AI 手）打造的 App，我感慨万千。
2025-12-08 14:32:16
933
原创 深入 WebRTC 核心：揭秘 ICE 候选路径的“选美”机制
ICE 的连接排序不仅仅是一个技术细节，它是 WebRTC 保证**“体验下限（能连通）”和追求“体验上限（低延迟）”**的核心策略。决定了大方向（走内网、公网还是中继）。Check List决定了尝试的顺序。Nomination决定了最终的赢家。下次当你再看 WebRTC 的日志时，不妨关注一下那个长长的priority数字，它背后藏着 WebRTC 为了帮你省流量、降延迟而付出的所有努力。
2025-12-07 20:30:07
965
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人