共计 1194 个字符，预计需要花费 3 分钟才能阅读完成。
WebRTC 给咱们带来了浏览器中的视频、音频聊天体验。但集体认为，它最实用的个性莫过于 DataChannel——在浏览器之间建设一个点对点的数据通道。在 DataChannel 之前，浏览器到浏览器的数据传递通常是这样一个流程：浏览器 1 发送数据给服务器，服务器解决，服务器再转发给浏览器 2。这三个过程都会带来相应的耗费，占用服务器带宽不说，还减缓了音讯从发送到接管的工夫。其实最现实的形式就是浏览器 1 间接与浏览 2 进行通信，服务器不须要参加其中。WebRTC DataChannel 就提供了这样一种形式。
老刘和老姚
当然服务器齐全不参加其中，显然是不可能的，用户须要通过服务器上存储的信息，能力确定须要和谁建设连贯。这里通过一个故事来讲述建设连贯的过程：
不如钓鱼去
一些背景：
- 老刘和老姚都住在同一个小区但不同的片区，小区很破旧，没有电话
- 片区互相隔离且片区门口有个保安，保安只意识本人片区的人，遇到不意识的人就须要查问凭证能力通过，而凭证须要找物业能力确定
- 门卫老大爷意识小区里的所有人然而不晓得都住哪，有什么音讯都能够在出入小区的时候代为传播
当初，老刘据说老姚钓鱼技术高超，想和老姚探讨钓鱼技巧。只有老刘和老姚相互之间晓得对方的门牌号以及凭证，就能够串门了:
- 门卫老大爷意识老刘和老姚
- 老刘找物业确定了本人片区的出入凭证，将凭证、本人的门牌号以及用意通知门卫老大爷，让其转交给老姚
- 老姚买菜归来遇到门卫老大爷，门卫老大爷将老刘的音讯传播给老姚。于是老姚晓得怎么去老刘家了
- 老姚很开心，他也找物业获取了本人小区的凭证，并将凭证、本人的门牌号等信息交给门卫老大爷，心愿他传播给老刘
- 老刘吃早餐回来遇到门卫老大爷，老大爷把老姚的小区凭证、门牌号等信息通知老刘，这样老刘就晓得了怎么去老姚家了
老刘和老姚相互之间晓得了对方的门牌号和小区出入凭证，他们相互之间有什么须要交换的间接串门就行了，音讯不再须要门卫老大爷来代为传播了
换个角度
咱们把角色做一个映射：
- 老刘：浏览器 1
- 老姚：浏览器 2
- 片区：不同网段
- 保安：防火墙
- 片区凭证：ICE candidate
- 物业：ICE server
- 门牌号：session description
- 门卫老大爷：server
于是乎故事就变成了这样：
- 浏览器 1 和浏览器 2 在 server 上注册，并保有连贯
- 浏览器 1 从 ice server 获取 ice candidate 并发送给 server，并生成蕴含 session description 的 offer，发送给 server
- server 发送浏览器 1 的 offer 和 ice candidate 给浏览器 2
- 浏览器 2 发送蕴含 session description 的 answer 和 ice candidate 给 server
- server 发送浏览器 2 的 answer 和 ice candidate 给浏览器 1
这样，就建设了一个点对点的信道，流程如下所示：
原文地址：
应用 WebRTC 搭建前端视频聊天室——点对点通信篇
正文完