WebRTC基本概念

前言

WebRTC（Web Real-Time Communication),一個可讓用戶用本身流量實現音視頻實時通訊的框架（APIs),支持瀏覽器（Firefox、Chrome、Opera）以及iOS、Android 原生系統（Poor WP,默哀）。對於以爲帶寬賊貴又須要實現用戶之間音視頻通訊的公司來講，這是一個大大的福利。

What is WebRTC？

官方介紹：

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow themall to communicate via a common set of protocols.

WebRTC是一個free的開源項目，該項目提供了一組能夠在瀏覽器、手機應用平臺（再次聲明，目前只支持iOS和Android。）實現實時通訊的簡單API(s),WebRTC的目標是將實時通訊過程作得最優化。

咱們的任務（指WebRTC官方）：在手機應用平臺、瀏覽器和物聯網設備之間用同一組協議實現高質量實時通訊。

RTC基本框架

按照傳統的通訊流程，是這樣的：

以下圖所示，數據發送端和接收端都須要經過公網服務器進行轉發（由於發送端和接收端一般都作了NAT，彼此並不知對方實際位置）。

e.g.：猶如一箇中國人和一個外國人，他們彼此不懂對方的語言，不知道對方的地址，可是中間有一個郵局知道對方的地址，由於對方都在郵局作了註冊地址而且獲取了同一個編號，那麼若是他們之間須要互相通訊的話，就須要和郵局聯繫，郵局會進行翻譯併發往同一編號的對應地址。 可是這中間就會產生一個問題，這時候若是有多箇中國人和多個外國人都要進行通訊，那麼郵局的工做量就會愈來愈大，當他們的通訊超過原有郵局人手可處理規模時，郵局要麼擴招（須要錢）要麼延緩發送（會形成延遲，甚至丟失信件）。

怎麼辦？這時咱們就要考慮另一種解決方案了。咱們讓發送端直接發送數據給接收端，這樣就能夠省掉服務器的轉發功能了是否是？固然是，可是如咱們上述例子所說，中國人不懂俄語，俄羅斯人不懂中文，雞同鴨講眼碌碌。他們之間怎麼通訊呢？郵局以爲上述方式太不靠譜了，因而決定經過一種技術，當有一箇中國人或者外國人尋求轉發時，郵局經過「魔法」查找出了對方地址，而且不說話丟給了對方一隻翻譯麪包，對方接收到翻譯麪包後能夠習得對方語言，直接和對方通話。

例子中的「魔法」就是本文要介紹的 ICE框架，而翻譯麪包就是NAT穿越技術。

ICE（Interactive Connectivity Establishment)框架

在真實世界的網絡中，由於IPv4的地址個數問題，咱們基本都是採用NAT鏈接的：

當處於以上網絡時，Peer和Peer之間基本都是經過NAT和防火牆鏈接上互聯網的，因此當咱們要創建兩端之間的直接通訊時，咱們須要服務器對兩端進行Signalling，具體如何進行Signalling會在下篇文章中介紹。本文假設兩端已經Signalling完畢。

ICE框架 （ICE會嘗試找到端與端之間最優鏈接路徑）會完成如下工做：

·首先ICE會直接利用主機地址和網卡地址進行鏈接，若是恰好端擁有公網IP（無NAT），那麼此時能夠直接創建鏈接。

·若是第一步失敗，ICE會嘗試創建STUN鏈接。

·若是第二步失敗，ICE會利用TURN服務器創建鏈接。

STUN（Session Traversal Utilities for NAT）

STUN服務器提供的功能十分簡單，它讓使用者獲取本身所在的公網地址和在NAT中所映射端口號，這個服務有什麼用呢？當使用者知道本身所在公網地址以及內部NAT映射端口時，它即可以講本身的公網地址和端口號通知對方，這樣對方就能夠在茫茫大網中找到本身。

在以往統計中，WebRTC經過STUN創建鏈接的成功率爲86%。

TURN（Traversal Using Relay NAT）

TURN是一個client-server協議。TURN的NAT穿透方法與STUN相似，都是經過取得應用層中的公有地址達到NAT穿透。但實現TURN client的終端必須在通信開始前與TURN server進行交互，並要求TURN server產生」relay port」，也就是relayed-transport-address。這時TURN server會創建peer，即遠端端點（remote endpoints），開始進行中繼（relay）的動做，TURN client利用relay port將資料傳送至peer，再由peer轉傳到另外一方的TURN client。

TURN 和 STUN

STUN服務在查詢出客戶端所在IP和端口後，其所成功創建的鏈接是直接經過端與端之間的鏈接的。

TURN服務是經過TURN服務器（擁有公網地址）做爲中間人進行轉發，因此若是TURN服務速度比STUN慢，並且是須要消耗TURN服務器帶寬。