WebRTC的通信方式隐藏在协议的缝隙里，它不强制使用某种方式，但会悄悄影响你的网络设计。
WebRTC是浏览器中实现实时通信的“超能力”，但它不是万能的。它的设计哲学非常有趣——它不规定与服务器的通信方式。这就意味着，你可以在WebRTC中使用任何你想要的协议，比如WebSocket。这种灵活性背后，其实藏着一些你必须了解的真相。
想象一下，你正在开发一个实时视频会议应用。浏览器端的WebRTC如何把你的音视频流传送到另一端？答案是：通过信令服务器。但信令服务器到底用什么协议来传输这些信息？这正是今天要聊的话题。
WebRTC的核心是P2P通信，但它的初始连接阶段却离不开服务器。这个阶段被称为信令交换（Signaling Exchange），它主要负责两件事：建立连接和交换媒体信息。而这一步，通常都是通过SDP协议完成的。
SDP是一种会话描述协议，它负责描述客户端的媒体能力。比如，你是否支持H.264编码？你是否能够接收音频？这些信息都会通过SDP传输。但SDP本身不是一个实时传输协议，它必须依赖某种底层传输协议来完成数据的交换。
这就引出了一个问题：WebRTC到底用什么协议来传输SDP信息？ 答案是：WebSocket。但为什么不是HTTP？因为HTTP是请求-响应的，而WebRTC需要双向通信。WebSocket正是为这种场景而生。
接下来，我们来看看一个典型的SDP交换流程。假设客户端A和客户端B要进行视频通话，它们首先需要通过WebSocket连接到同一个信令服务器。然后，客户端A会向服务器发送一个Offer（即SDP描述），服务器将这个Offer转发给客户端B。客户端B收到后，会生成一个Answer并返回给服务器，服务器再把这个Answer传回给客户端A。最后，双方通过ICE候选建立直接的P2P连接，不再经过服务器。
这个过程虽然看似简单，但其中的每一个细节都可能影响性能和安全性。比如，SDP的格式、ICE候选的生成、NAT穿透的机制，甚至服务器如何选择最佳的传输方式，都是你必须掌握的知识。
如果你正在尝试用WebRTC实现自己的应用，那么理解WebSocket在信令交换中的角色就变得至关重要。为什么选择WebSocket而不是其他协议？因为它低延迟、全双工，非常适合实时通信的场景。
但WebRTC的灵活性也带来了复杂性。比如，你是否知道，某些浏览器对WebSocket的兼容性并不一致？或者，你是否想过将WebSocket替换为其他协议，比如MQTT或CoAP？这可能是一个值得探索的方向。
此外，WebRTC的安全性也是一个不容忽视的问题。SDP交换虽然是关键的一步，但如果服务器配置不当，可能会导致信息泄露或中间人攻击。你有没有想过，如何在这一阶段保护你的数据？
最后，我想问你一个问题：如果你要用WebRTC做点什么，你会选择WebSocket还是其他协议？为什么？
关键字：WebRTC, WebSocket, SDP, 实时通信, 信令交换, ICE候选, NAT穿透, 协议选择, 网络编程, 安全性