目录

• 目录
• 参考资料
• 什么是WebRTC？
• 能做什么？
• 架构图
• 个人理解(类比)
  
  • 核心知识点
  • 核心知识点类比
    
    • ICE框架
    • STUN(协议)
    • NAT(网络地址转换)
    • TURN
    • SDP(会话描述协议)
    • WebRTC的核心API
• 现在开始做饭
• 准备阶段
  
  • 环境准备
  • 服务器搭建
  • Coturn TURN server(开源服务) 部署
  • Signal Server信令服务
  • 信令服务与客户端源代码
  • 测试
• 总结
• 常见问题

参考资料

• WebRTC详细文档
• WebRTC samples(官方)
• 如何搭建一个简单的webrtc服务器(其他博主文档)
• WebRTC官方Demo
• webRTC开源库
• coturn Server部署和Docker
• WebRTC服务器测试地址

什么是WebRTC？

• WebRTC（Web实时通信）技术
• 浏览器之间交换任意数据，而无需中介
• 不需要用户安装插件或任何其他第三方软件

能做什么？

与Media Capture和Streams API一起

• 支持音频和视频会议
• 文件交换
• 屏幕共享
• 身份管理
• 以及与传统电话系统的接口，包括支持发送DTMF（按键拨号）信号

架构图

个人理解(类比)

官方文档晦涩难懂，所以按照自己的思路，整理总结。

核心知识点

先整理官方核心知识点，这里不理解，没关系，我们继续按自己的思路总结

• ICE（框架）允许您的Web浏览器与对等端连接
• STUN（协议）用于发现您的公共地址并确定路由器中阻止与对等体直接连接的任何限制
• NAT 用于为您的设备提供公共IP地址
• TURN 是指通过打开与TURN服务器的连接并通过该服务器中继所有信息来绕过对称NAT限制
• SDP 从技术上讲会话描述协议(SDP并不是一个真正的协议，而是一种数据格式)

核心知识点类比

我们使用餐厅（或者其他）来类比WebRTC核心概念， 想象一下，你现在正在餐厅里面。
顾客(用户)
可以直接与
厨房(服务器)
进行交流，而不需要通过
服务员(中介)
。在这个餐厅里，顾客可以
点菜(发送音视频请求)
、
享用美食(接受音视频流)
，
还可以与其他顾客(其他用户)直接交流(数据传输)
,而这一切都
不要
额外的
工具或设备(插件)

备注:如果你明白，上面描述，那我们就继续。

ICE框架

想象一下ICE就像餐厅
整体布局和设计
，它确保
顾客(用户)
能够顺利找到座位并与
厨房(对等端)
建立联系。ICE负责协调顾客和厨房之间的所有连接方式，确保他们能顺利交流。

STUN(协议)

STUN就像餐厅门口
接待员
，负责帮助顾客找到餐厅的公共入口。接待员会
告诉顾客他们的公共地址(公共IP地址)
,并帮助他们了解是否有任何
障碍(比如路由器的限制、防火墙等)阻止他们直接进入餐厅(与对等端直接连接)
。

NAT(网络地址转换)

NAT就像餐厅外墙，它为餐厅提供一个
公共门牌号(公共IP地址)
。虽然餐厅内部有很多
桌子(设备)
,但外面的人只知道这个公共门牌号，而不知道内部具体位置。

TURN

TURN就像餐厅的
外卖服务
。如果顾客无法直接进入餐厅(由于对称NAT限制)，他们可以选择通过
外卖服务(TURN服务器)来获取食物
。所有的订单和交流通过外卖服务进行，这样即使顾客无法直接到达餐厅，他们仍然可以享用美食。

SDP(会话描述协议)

SDP就像餐厅的
菜单
，它描述了可供选择的菜品和饮料(音视频流的格式和参数)，虽然菜单本身不是一个真正协议，但它提供顾客和厨房之间所需的信息，以便他们能达成共识，确保顾客点的菜品能够被厨房正确准备。

WebRTC的核心API

• getUserMedia（点菜）：

这个API就像顾客在餐厅里点菜。顾客告诉厨房他们想要什么（音频或视频），厨房就会准备好这些食材（获取用户的音频和视频流）。

• RTCPeerConnection（厨房的工作台）：

这个API就像厨房的工作台，负责处理顾客的订单（建立连接）。它确保顾客和厨房之间的交流顺畅，处理音视频流的传输，就像厨房准备和发送食物一样。

• RTCDataChannel（顾客之间的交流）：
  这个API就像顾客之间的对话。顾客可以直接与其他顾客交流（传输数据），比如分享他们的用餐体验或交换食谱，而不需要通过服务员。
  总结
  在这个餐厅的类比中，WebRTC就像一个高效的餐厅，顾客可以直接与厨房和其他顾客交流，享受美食和分享信息，而不需要中介的干预。核心API则是实现这一切的工具，帮助顾客点菜、厨房准备食物和顾客之间的交流。这样，WebRTC使得实时通信变得简单而高效。

现在开始做饭

如果你看到这里，恭喜你，我们达成共识，现在开始做饭。

准备阶段

环境准备

安装Docker、Nginx、Nodejs等，请查询其他文档

• 一台服务器
• Debian 12 x86_64 操作系统
• Docker
• Nginx
• Nodejs

服务器搭建

首先我们需要两个服务，STUN/TURN、Signal Server, What's Signal Server? 别紧张我待会，会解释现在我们先专注与STUN/TURN,再次之前我们需要了解  Coturn TURN server(开源框架,感谢开发人员)

• STUN/TURN
• Signal Server 信令服务

Coturn TURN server(开源服务) 部署

对的你没有看错，就一行命令,这就是我为什么推荐使用Docker的原因，详细的Dockerfile请看 参考资料

docker run -d --network=host coturn/coturn

测试

打开我们的测试网站
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
添加服务器，等等我们的密码哪里来的？

用户名和密码

用户名和密码在Dockerfile文件里面,我使用的是默认配置，没设置任何配置文件，所以密码是默认密码，自己可以修改
https://github.com/coturn/coturn/blob/master/docker/coturn/debian/Dockerfile

Signal Server信令服务

想象一下，在这个餐厅中，顾客(用户)需要与厨房(对等端)进行交流，但他们并不能直接看到厨房内部情况，信令服务器就像餐厅的接待员或前台，负责协调顾客之间的交流和信息传递。

• 传递消息，比如顾客A想与顾客B进行视频通话，顾客A请求会先发送到信令服务器，然后由信令服务器转发给顾客B

信令服务与客户端源代码

注意事项： WebRTC需要使用 SSL/TLS 证书，也就是https 协议。

• 源代码

测试

总结

• 搭建Signal Server信令服务
• 搭建STUN/TURN 服务
• Docker 部署Coturn TURN server(节省大量部署时间)

常见问题

• 稍后补充

源代码

• 信令服务和客户端