Page 290 - Web性能权威指南

18.4 建立端到端的连接

与打开 XHR、EventSource 或新 WebSocket 会话相比，初始化一个端到端的连接所
做的事要多很多：前三者依赖于定义完善的 HTTP 握手机制协商连接参数，而且它
们都假定客户端可以访问到目标服务器（比如，服务器具有公开的可以路由到的 IP
地址，或者客户端和服务器本身都在一个内部网中）。

相对而言，WebRTC 两端则很可能分别位于自己的私有网络中，而且中间还隔着一
或多层 NAT。结果，任何一方也不能直接访问对方。为发起会话，首先必须找到两
端的候选 IP 和端口（candidate），穿越 NAT，然后检查连接，以期找到可用路径。
而即便到了这一步，也不能保证成功。

回顾 3.2 节“UDP 与网络地址转换器”和 3.2.2 节“NAT 穿透”，以了解
NAT 对 UDP 及端到端通信的巨大影响。

不过，尽管 NAT 穿越必须处理，但我们恐怕还是有点性急了。在打开到服务器的
HTTP 连接时，我们心里会假设服务器会监听握手。服务器当然可能拒绝，但不管
怎样它会一直监听新连接。不幸的是，我们对远端没办法作这种假设：远端可能不
在线或根本访问不到，亦或根本就不想与其他端建立连接。

因此，要想成功地建立端到端的连接，必须首先解决另外几个问题：

(1) 必须通知另一端我们想打开一个端到端的连接，以便它知道开始监听到来的分组；
(2) 必须找出两端之间建立连接所需的路由线路，并在两端传播这个信息；
(3) 必须交换有关媒介和数据流的必要信息，比如协议、编码，等等。

好消息是，WebRTC 为我们解决了其中一个问题：内置的 ICE 协议会执行必要的路
由和连接检查。然而，发送通知（信号）和协商会话仍然要由应用负责。

18.4.1 发信号和协商会话

在检查连接或协商会话之前，必须知道能否将信息发送到另一个端，以及另一端
是否愿意建立连接。为此，我们必须发出一个信号，而另一端必须返回应答（图
18-5）。但这样我们就会面临一个困境：如果另一端没有监听数据包，那我们向谁表
达自己的意图呢？最低限度，我们需要一个共享的发信通道。

280 ｜ 第 18 章