webrtc之旅--概念篇(一)

前言

刚开始接触WebRTC肯定会被WebRTC中的许多概念给吓到，不清楚STUN，TURN，ICE，信令这些在WebRTC里面起什么作用，今天这篇文章结合网络查阅的资料以及自己的理解做一些记录，希望对WebRTC初学者一些帮助，如有不正确的地方欢迎指正。
这个文档并不包括WebRTC中所有的概念，只对WebRTC建立连接时可能设计到的知识按照自己的理解进行描述。担心某些概念定义错误会误导观看者，文章中引用许多百度百科的官方描述，引用内容使用灰色区分，但并不表示这些内容不重要，相反我认为是认识这些概念最重要的部分。
下面就开始WebRTC之旅建立连接篇。
WebRTC建联流程
WebRTC是一种实时通讯技术，那首先要解决的是两个端如何建立连接的问题，需要说明的是两个端建立连接的过程相对来说也并不是那么简单(如下图)。

我们先从图中的NAT说起，再到如何解决NAT问题，再到ICE，最后再到信令服务器

NAT

WebRTC要进行端到端的通讯，最简单的方式是通讯双方知道对方的IP，通过IP直连，减少使用服务器进行数据的中转，但是实际并非如此，在实际的场景中，我们的每个客户端都是在局域网(由多台计算机或者称为客户端之间相互连成一个计算机组)内部的，对外的IP(公网IP)只有一个，内网IP是不能直接被公网访问的，那么两个客户端都处于局域网内部，如何让两个处于局域网内部的IP直接进行互相通讯呢？这个时候就需要用到NAT穿透技术了。
首先先了解下什么是NAT？
NAT（Network Address Translation），是指网络地址转换，1994年提出的。
当在专用网内部的一些主机本来已经分配到了本地IP地址（即仅在本专用网内使用的专用地址），但又想和因特网上的主机通信（并不需要加密）时，可使用NAT方法。
这种方法需要在专用网（私网IP）连接到因特网（公网IP）的路由器上安装NAT软件。装有NAT软件的路由器叫做NAT路由器，它至少有一个有效的外部全球IP地址（公网IP地址）。这样，所有使用本地地址（私网IP地址）的主机在和外界通信时，都要在NAT路由器上将其本地地址转换成全球IP地址，才能和因特网连接。
另外，这种通过使用少量的全球IP地址（公网IP地址）代表较多的私有IP地址的方式，将有助于减缓可用的IP地址空间的枯竭。在RFC 2663中有对NAT的说明
NAT功能之一：NAT 之内的 PC 联机到 Internet 上面时，他所显示的 IP 是 NAT 主机的公共 IP，所以 Client 端的 PC 当然就具有一定程度的安全了，外界在进行 portscan（端口扫描） 的时候，就侦测不到源Client 端的 PC 。– 百度百科
简单来说NAT做了公网IP与内网IP的地址转换，这个可以解决IP地址不够用及安全问题，但是这也为端到端直连带来了问题，处于局域网内部的两个客户端无法直接通过IP进行相互访问，这个时候就要用NAT穿透技术来解决这个问题，解决方案主要使用STUN和TURN协议。

STUN：

STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。该协议由RFC 5389定义。
作用：简单来说是获得局域网内部客户端的公网IP。 —百度百科
简单来说STUN 是为了让位于局域网内部的客户端找出公网IP而定义的一种协议，那大概是如何实现的呢？
STUN技术需要一个位于公网的Server(STUN Server)，这个Server实现了客户机-服务器协议(该协议见RFC5389)，一个客户端主动向服务器发送请求，之后，服务器会向客户端报告NAT路由器的公网IP地址以及NAT为允许数据传回到内网而开通的端口，这个过程让客户端能够确定使用的NAT类型，因为不同的NAT类型处理传入的UDP分组方式不同。有4种方式其中三种是可以使用的，完全圆锥型NAT，受限圆锥型NAT和端口受限圆锥型NAT，但是大型公司网络中经常采用对称性NAT，这种NAT是不可用的（对称型NAT要求发送端内网IP端口号要与对端IP端口号一一对应，因此使用STUN Server获取的端口号会失效，不能转接给其他不同IP的端进行使用），那解决这个问题需要用到另外一种协议——TURN协议

TURN 协议：

turn是网络协议，又称SPAN(Simple Protocol for Augmenting NATs）方式。
TURN协议允许NAT或者防火墙后面的对象可以通过TCP或者UDP接收到数据。这在使用了对称式的NAT（或者防火墙）的网络中尤其具有实用价值 [1] 。
TURN方式解决NAT问题的思路与STUN相似，是基于私网接入用户通过某种机制预先得到其私有地址对应在公网的地址（STUN方式得到的地址为出口NAT上的地址，TURN方式得到地址为TURNServer上的地址），然后在报文负载中所描述的地址信息直接填写该公网地址的方式，实际应用原理也是一样的。
TURN的全称为Traversal Using Relay NAT，即通过Relay方式穿越NAT，TURN应用模型通过分配TURNServer的地址和端口作为客户端对外的接受地址和端口，即私网用户发出的报文都要经过TURNServer进行Relay转发，这种方式应用模型除了具有STUN方式的优点外，还解决了STUN应用无法穿透对称NAT（SymmetricNAT）以及类似的Firewall设备的缺陷，即无论企业网/驻地网出口为哪种类型的NAT/FW，都可以实现NAT的穿透，同时TURN支持基于TCP的应用，如H323协议。此外TURNServer控制分配地址和端口，能分配RTP/RTCP地址对（RTCP端口号为RTP端口号加1）作为本端客户的接受地址，避免了STUN应用模型下出口NAT对RTP/RTCP地址端口号的任意分配，使得客户端无法收到对端发过来的RTCP报文（对端发RTCP报文时，目的端口号缺省按RTP端口号加1发送）
TURN的局限性在于所有报文都必须经过TURNServer转发，增大了包的延迟和丢包的可能性。 —— 百度百科
面对对称型NAT，STUN不能解决连接问题的时候会用到TURN协议，TURN协议主要的解决方式是通过建立中转服务器，两个通讯端均与中转服务器建立连接，服务器将数据进行转发。
由于TURN服务器需要对报文进行转发，会大量占用服务器带宽，成本较高，并且还会引入延迟，因此一般在STUN不可用的情况下才会使用。

SDP

SDP协议(Session Description Protocol)会话描述协议。使用文本对媒体信息进行描述。但是其协议本身并不传递媒体数据，只是用于参与媒体会话双方媒体协商。通过交换SDP，会话双方可以知道对方支持的音视频媒体能力如音视频编格式、网络信息等重要信息

ICE：

交互式连接创建（Interactive Connectivity Establishment），一种综合性的NAT穿透的技术。
交互式连接创建是由IETF的MMUSIC工作组开发出来的一种framework，可集成各种NAT穿透技术，如STUN、TURN（Traversal Using Relay NAT，中继NAT实现的穿透）、RSIP（Realm Specific IP，特定域IP）等。该framework可以让SIP的客户端利用各种NAT穿透方式打穿远程的防火墙。 – 百度百科
ICE是一种端到端交互的技术，并不是协议。是整合了各种NAT穿透的技术，如STUN、TURN等协议的技术。
ICE工作步骤是通过STUN/TURN服务获得可用的IP跟端口号（candidate），将这些信息扩展到SDP中，当两个客户端交换了SDP后会对candidate进行连接检测，检测是否可用，检测完成后会使用对应的candidate用于通讯

信令(Signaling)：

WebRTC在音视频传输前需要先建立媒体通道，媒体通道负责音视频数据的传输。如A与B进行交互，需要首先建立媒体通道，建立媒体通道需要相互知道对方的IP与通讯端口，除IP与端口之外还需要知道对方的音视频能力，而这些信息的交互需要一个单独的服务器进行完成，这个服务器就是信令服务器。
信令服务器不涉及音视频媒体数据相关的传输工作，只负责建立连接前必要网络信息、媒体能力信息的交换。
WebRTC并没有提供这种信息传递机制及标准，开发商或开发人员可以自行搭建服务器，网络协议可以自由选择HTTP，Websocket等方式。
信令服务器负责转发的信息主要包括两种信息，一个是媒体信息，另一个是网络信息(candidate，IP和端口等网络信息)，除此之外信令服务器还负责一部分房间管理，IM等功能。

总结

两个客户端需要通讯，首先要建立连接，建立连接第一步是要拿到对端的IP跟端口号，这些信息称为网络信息，但是由于有NAT的存在，需要使用STUN获取外网IP及端口号，但是STUN只能解决部分NAT情况，解决对称型NAT问题需要使用TURN协议，而ICE就是整合了这两种协议的技术，端到端连接问题。
有了IP与端口号后，两个客户端还需要知道对端有什么媒体能力，如能不能发送音频或者视频，有没有对应的音视频编解码等信息，这些信息称为媒体信息。
客户端只知道自己本地的网络信息跟媒体信息，那就需要另外一个服务器来完成两个端的信息交换，这个服务器就是信令服务器。客户端根据网络信息与媒体信息生成SDP，并且通过信令服务器将SDP进行交换，告诉对端自己的信息及获取对端信息，
附：
后面有时间再对本文涉及的协议进行一次深入的分析