一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第24天，点击查看活动详情。
这一节来看 RTCDataChannel 相关的 API，和之前介绍的 API 不同，这个是 WebRTC 专用的 API，对于有相关来发经验的工程师很熟悉，但是对于没接触过音视频开发的用户来说 WebRTC 所有的 API 都不常用，这一节来看下这部分都是什么。
在正式进入正文之前先提前说一下，本文是给不了解 RTCDataChannel 的人来科普一下这部分是做什么的，以及为什么要用，具体 WebRTC 的相关实现不会展开，我之前也写过 WebRTC PeerConnection 和 getUserMedia 相关的文章，里面有详细的介绍。
RTCDataChannel 可以用来双向传输数据。在 WebRTC 中，媒体数据可以通过 PeerConnection 传输，但是如果我们在此之外还想传递其他信息，这时就必须有一个额外的通道，这个通道需要支持双向传输。可能我们会第一时间想到 WebSocket，我们都知道 WebSocket 可以双向传输数据，但是这里面有一个问题，WebSocket 是基于 TCP 的，存在队头阻塞问题。
队头阻塞问题与 TCP 的机制有关，为了保次可靠传输，TCP 对于失败的内容会有重传机制，重传就会影响后面的内容传递。而在实时流媒体场景下，数据具有很强的时效性，比如我们进行视频直播，一共有 10 帧视频，现在第 3 帧失败了，这是对于 TCP 传输，它会重试等第 3 帧成功后再传输第 4 帧，从视频效果来看，我们会卡一下然后还会有延迟。但是实际上，这时第 3 帧内容已经过期了，我们真的需要吗？
和 TCP 不同的是 UDP 传输，UDP 不会等待是否成功，他直接发出去，上面的场景下，第 3 帧丢失第 4 帧还会正确传递，用户少收到一帧对于视频整体效果几乎没影响，后面正常播放，不影响时效性，因此流媒体场景通常都需要 UDP 传输。
RTCDataChannel 就是 UDP 传输的重要实现，我们可以通过 PeerConnection 上面的 createDataChannel 来创建通道，之后直接 send 数据，使用 on 接收数据即可。虽然 PeerConnection 已经可以传输音视频，但是如果有更高定制化的流媒体数据要求，这时 DataChannel 很有用。
