-
RTCPeerConnection
-
MediaStream
-
MediaTrack
-
IceCandidata
-
Transceiver
-
...
Today
通过自建Turn server、Signaling server再加上一点简单的web开发，可以让我和我的朋友们在天涯各地聚在一起玩耍、欢呼甚至可以云实景剧本杀。
这是它带给我和朋友们的快乐
这些都源于它带来的低延迟；
刚发布不久的HTTP3 QUIC或未来的Web Transport 跟它主要依赖的传输协议都有异曲同工之处 - UDP；
UDP与TPC的差异和带来的传输影响在此不做过多赘述，可以参考很多文献。
与传统直播模式的差异，也决定了它的特性（优缺点）
RTC场景：例如我在打竞技类游戏，在一个关键节点，我的朋友移动网络短暂的进入了电梯，那么此时我的画面是不能传达到他的屏幕上，这会让我们很懊恼... 当然也有一些解决办法；
传统直播场景：我依然在打竞技类游戏，也是在同一个游戏关键节点，我的朋友移动网络也短暂的进入了电梯，那么我的画面他大概率会一览无余；
为什么？为什么会有如此差异？
切片buffer与stream
前者传统大众方案不论任何的协议都是基于视频切片，切片组合的视频相较于实时流意味着稳定画质、媒体的缓存， 回到那个场景我的朋友进入电梯前他已经缓存好了30秒前的切片buffer，当他在无网络的情况下，媒体当然可以从本地组合解码播放，直至他重新连接网络，已有的切片会保证他额外的播放一会儿 ，这意味着延迟，但带来了相对稳定；
后者从设计上就摒弃了需要大量延迟生成的视频切片buffer，而是对帧数据进行编码打包后实时发送，所以可以粗略理解为我的朋友进入电梯前接收到的是无延迟或者毫秒级延迟的RTP包，那么他进入电梯，当电梯门关上的那一刻，可以说他的视频就会停留在最后一帧，哪怕当时我可能正在秀的天翻地覆，他也只能盯着最后一帧，细细品味，这表示着局限，但带来了实时可互动的画面；
其中：媒体加密 规模性网络问题 网络拥堵 抗丢包 NAT穿透都是RTC开发中需要处理的。
Future
目前实时通信用例已随处可见，电竞、运动生产、办公...
这些场景未来都需要更大的数据、更频繁的交互、更敏捷的处理
都会促进WebRTC流量增长
目前浏览器中webRTC目前也存在一定的优化上限，未来
- 采集 mediaDevice extension
- 媒体处理、编解码 webCodec
- 传输 WebTransport
解构下的webRTC会更优。
最后，本文旨在分享、阐述webRTC基础性概念，希望让更多人了解到我们日常使用到的技术，并更好的理解它们并尝试使用，欢迎大家多多指教或讨论。
