一、信令通道初始化：
这一步的核心是为后续交换地址和能力信息建立一条稳定的通道。
Spring Boot 项目初始化时，基于Netty框架启动 IO 服务，Netty 负责底层的网络连接管理、IO 多路复用和高并发处理。
在 Netty 之上，服务端搭建WebSocket服务，对外暴露 WebSocket 连接地址（如ws://your-server.com/signaling）。
WebSocket 的作用是维持长连接，保证客户端和服务端之间可以随时双向推送信令，无需频繁发起 HTTP 请求。
客户端接入
客户端 A 和客户端 B（如浏览器、App）分别发起 WebSocket 连接请求，与服务端建立长连接。
连接成功后，服务端会记录每个客户端的连接标识（如用户 ID），确保后续信令能精准转发。
二、NAT 穿透与公网地址获取
因为大部分设备都在路由器（NAT）之后，无法直接被外网访问，所以需要借助 STUN 服务器获取自己的公网可见地址。
客户端发起 STUN 请求
客户端 A 和 B 分别向STUN服务器（如谷歌的stun.l.google.com:19302）发送绑定请求（Binding Request）。
这个请求会携带客户端的内网 IP 和端口。
STUN 服务器响应
STUN 服务器收到请求后，会识别请求包经过 NAT 时被转换后的公网 IP + 端口（也叫 "反射地址"）。
服务器将这个公网地址封装在绑定响应中，返回给客户端。
客户端获取公网地址
客户端 A 和 B 各自从 STUN 响应中拿到自己的公网 IP 和端口，这个地址就是其他设备能从外网访问到自己的入口。
三、信令交换：交换 "通话能力" 与 "网络地址"
这是 WebRTC 的核心环节，客户端需要通过信令通道交换两种关键信息：SDP 会话描述和ICE 候选地址。
生成 SDP 会话描述
客户端 A 先创建本地 PeerConnection 对象，生成包含自己媒体能力的本地 SDP（如支持的音视频编码格式、传输协议等）。
这个 SDP 相当于 "通话邀请"，告诉对方 "我能支持这些媒体格式，我们可以这样通话"。
发送 SDP 与 ICE 候选
客户端 A 将本地 SDP 和从 STUN 获取的ICE 候选地址（即公网 IP + 端口）打包成 "A 信令"，通过 WebSocket 发送给服务端。
服务端根据连接标识，将 A 信令转发给客户端 B。
客户端 B 响应信令
客户端 B 收到 A 信令后，解析出 A 的 SDP 和 ICE 候选，生成自己的本地 SDP和 ICE 候选地址，打包成 "B 信令"。
B 信令同样通过 WebSocket 发送给服务端，再由服务端转发给客户端 A。
结果
此时客户端 A 和 B 都拥有了对方的 SDP（知道了彼此的媒体能力）和 ICE 候选（知道了彼此的公网地址）。
四、P2P 连接建立与数据传输：直接通信
有了对方的网络地址和媒体能力，客户端就可以跳过服务端，直接建立安全的 P2P 连接。
ICE 连通性检查
客户端 A 和 B 会通过 ICE 框架，尝试用对方的 ICE 候选地址发起连接，测试哪些地址可以成功通信（这一步可能会尝试多个候选地址，直到找到可用的）。
DTLS 握手加密
一旦找到可用的网络路径，双方会进行DTLS 握手，建立加密的传输通道，确保后续数据传输的安全性。
媒体流传输
连接建立完成后，音视频、文件等媒体数据会通过SRTP 协议（安全实时传输协议）在 P2P 通道中直接传输，不再经过服务端中转。
这就是图中粉色箭头 "直接用 WebRTC 通讯" 的阶段，大幅降低了服务端的带宽压力和延迟。