2010年5月:Google以6820万美元收购VoIP软件开发商Global IP Solutions的GIPS引擎,并改为名为“WebRTC”(见《了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化》)。旨在建立一个互联网浏览器间的实时通信的平台,让 WebRTC技术成为 H5标准之一。
此外,WebRTC 也旨在实现浏览器之间丰富的沟通。浏览器已经发展了很长时间,它“拥有”大量的优质资源,它可以访问摄像头和麦克风,这些特性都值得被开发利用。用户不需要写自己的应用,而是基于 WebRTC 的标准 API 便可以轻松使用。不仅是浏览器,在移动设备和 IoT 设备通信时也同样。
3.2在 WebRTC 中究竟发生了哪些事呢?
举个例子:A 想要与 B 进行通信,但 A 与 B 之间“互不相识”。所以 A 首先需要找到所有 Public(不是 B)能连接到它的途径,检查 A 是否有一个公共 IP 能被 Public 识别或使用,如果没有检查 A 的路由器是否允许公开端口转发规则、是否在路由上有公共代表等等。B 也做了以上同样的事。
此外:A 和 B 还会收集自身所支持的加密方式、安全参数、视频编解码器等等大量的信息,注意这些信息还没有被送到对端,在这个阶段只是广泛地收集。所有这些信息,构成了“SDP”。
接下来:A 和 B 会通过其他方式(可以是 WhatsApp、QR、Tweet、WebSockets、HTTP Fetch…)发出会话信息,这种方式具体是什么 WebRTC 并不关心,只要能从 A 到 B(B 到 A)就可以。
这种工作方式表面上是有些“愚蠢的”,部分人可能会认为“既然我已经有了 A 和 B 之间通信的线路,那还要 WebRTC 做什么呢?”但认真思考一下就可以发现,WebRTC 只要首次通信双方交换了 SDP,后面就会实现真正的 P2P 通信,不再需要 WhatsApp、QR 等等中间途径,不会有比这更快的通信路径。因此最终 A 通过最优路径连接到了 B,这就是 WebRTC 的工作流程。
更详细的阐释这个例子如下:
如上图所示:假设 A 找到了 A1、A2、A3 三种方式可以访问它,同时还找到了安全参数、媒体选项等信息。同时,B 也做了一样的工作。接下来,他们通过一些方式(例如 WhatsApp)交换了以上信息。然后 A 找到 B2 是可用的最佳路径,而 B 也发现 A1 是可用的最佳路径,那么二者将通过这条路径直接连接彼此。
如果你有一个公开的 Public IP 地址,连接过程将不会有什么问题。因为你会像 Web 服务器一样一直监听端口,把端口和 IP 都提供给对方后,你和它就可以直接进行连接了。但在大多数情况下,用户都是隐藏在公共网络之后的,无法直接连接。
如下图所示的示例中:路由器有一个 Public IP 5.5.5.5,也有一个 Private IP 10.0.0.1(也被称为 gateway),你的机器只有一个 Private IP 10.0.0.2,但你想要访问 IP 为 4.4.4.4:80 的机器,要如何实现呢?
首先:你的机器会构建一个数据包,声明想向 4.4.4.4:80 发出 GET 请求,10.0.0.2 是源 IP 地址。接下来:你的机器会通过子网掩码判断是否可以直接与 4.4.4.4:80 进行连接,运算结果会显示 4.4.4.4:80 并不在你所在的子网中,因此无法直接进行通信。所以下一步就需要将请求发送给路由器,借助 gateway 进行通信。路由器会替换源 IP 地址和端口为 Public IP 和一个随机端口,但在此之前会创建 NAT 表,来记录三者之间的对应关系。这样对端就能收到你的GET请求,并进行后续处理了(如下图所示)。