子曰：“不患無位，患 所以立俺亮；不患莫己驮捍，求 為可知也〗旁”
前言
WebRTC（Web Real-Time Communication),一個(gè)可以讓用戶用自己流量實(shí)現(xiàn)音視頻實(shí)時(shí)通信的框架（APIs),支持瀏覽器（Firefox东且、Chrome、Opera）以及iOS本讥、Android 原生系統(tǒng)（Poor WP,默哀）苇倡。對(duì)于覺得帶寬賊貴又需要實(shí)現(xiàn)用戶之間音視頻通信的公司來說，這是一個(gè)大大的福利囤踩。本系列文章會(huì)從WebRTC基本概念慢慢說起旨椒。
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是一個(gè)free的開源項(xiàng)目堵漱，該項(xiàng)目提供了一組可以在瀏覽器综慎、手機(jī)應(yīng)用平臺(tái)（再次聲明，目前只支持iOS和Android勤庐。）實(shí)現(xiàn)實(shí)時(shí)通信的簡單API(s),WebRTC的目標(biāo)是將實(shí)時(shí)通信過程做得最優(yōu)化示惊。
我們的任務(wù)（指WebRTC官方）：在手機(jī)應(yīng)用平臺(tái)、瀏覽器和物聯(lián)網(wǎng)設(shè)備之間用同一組協(xié)議實(shí)現(xiàn)高質(zhì)量實(shí)時(shí)通信愉镰。
RTC基本框架
按照傳統(tǒng)的通信流程米罚，是這樣的：
如下圖所示，數(shù)據(jù)發(fā)送端和接收端都需要通過公網(wǎng)服務(wù)器進(jìn)行轉(zhuǎn)發(fā)（因?yàn)榘l(fā)送端和接收端通常都做了NAT丈探，彼此并不知對(duì)方實(shí)際位置）录择。
e.g.：猶如一個(gè)中國人和一個(gè)外國人，他們彼此不懂對(duì)方的語言碗降，不知道對(duì)方的地址隘竭，但是中間有一個(gè)郵局知道對(duì)方的地址，因?yàn)閷?duì)方都在郵局做了注冊地址并且獲取了同一個(gè)編號(hào)讼渊，那么如果他們之間需要互相通信的話动看，就需要和郵局聯(lián)系，郵局會(huì)進(jìn)行翻譯并發(fā)往同一編號(hào)的對(duì)應(yīng)地址爪幻。 但是這中間就會(huì)產(chǎn)生一個(gè)問題菱皆，這時(shí)候如果有多個(gè)中國人和多個(gè)外國人都要進(jìn)行通信须误，那么郵局的工作量就會(huì)越來越大，當(dāng)他們的通信超過原有郵局人手可處理規(guī)模時(shí)仇轻，郵局要么擴(kuò)招（需要錢）要么延緩發(fā)送（會(huì)造成延遲京痢，甚至丟失信件）。
怎么辦拯田？這時(shí)我們就要考慮另外一種解決方案了历造。我們讓發(fā)送端直接發(fā)送數(shù)據(jù)給接收端甩十，這樣就可以省掉服務(wù)器的轉(zhuǎn)發(fā)功能了是不是船庇？當(dāng)然是，但是如我們上述例子所說侣监，中國人不懂俄語鸭轮，俄羅斯人不懂中文，雞同鴨講眼碌碌橄霉。他們之間怎么通信呢窃爷？郵局覺得上述方式太不靠譜了，于是決定通過一種技術(shù)姓蜂，當(dāng)有一個(gè)中國人或者外國人尋求轉(zhuǎn)發(fā)時(shí)按厘，郵局通過“魔法”查找出了對(duì)方地址，并且不說話丟給了對(duì)方一只翻譯面包钱慢，對(duì)方接收到翻譯面包后可以習(xí)得對(duì)方語言逮京，直接和對(duì)方通話。
例子中的“魔法”就是本文要介紹的 ICE框架束莫，而翻譯面包就是NAT穿越技術(shù)懒棉。
時(shí)間關(guān)系，以下內(nèi)容不再舉例說明览绿，需要網(wǎng)絡(luò)基礎(chǔ)的同學(xué)才能繼續(xù)觀看策严。
-
ICE（Interactive Connectivity Establishment)框架
在真實(shí)世界的網(wǎng)絡(luò)中，因?yàn)镮Pv4的地址個(gè)數(shù)問題饿敲，我們基本都是采用NAT連接的：
當(dāng)處于以上網(wǎng)絡(luò)時(shí)妻导，Peer和Peer之間基本都是通過NAT和防火墻連接上互聯(lián)網(wǎng)的，所以當(dāng)我們要建立兩端之間的直接通信時(shí)怀各，我們需要服務(wù)器對(duì)兩端進(jìn)行Signalling栗竖，具體如何進(jìn)行Signalling會(huì)在下篇文章中介紹。本文假設(shè)兩端已經(jīng)Signalling完畢[1]渠啤。
ICE框架 （ICE會(huì)嘗試找到端與端之間最優(yōu)連接路徑）會(huì)完成以下工作：
- 首先ICE會(huì)直接利用主機(jī)地址和網(wǎng)卡地址進(jìn)行連接狐肢，如果剛好端擁有公網(wǎng)IP（無NAT），那么此時(shí)可以直接建立連接沥曹。
- 如果第一步失敗份名，ICE會(huì)嘗試建立STUN[2]連接碟联。
- 如果第二步失敗，ICE會(huì)利用TURN[3]服務(wù)器建立連接僵腺。
在本章中鲤孵，我們只需要知道，ICE是一個(gè)提供了連接建立的服務(wù)框架辰如。
-
STUN（Session Traversal Utilities for NAT）
STUN服務(wù)器提供的功能十分簡單普监，它讓使用者獲取自己所在的公網(wǎng)地址和在NAT中所映射端口號(hào)，這個(gè)服務(wù)有什么用呢琉兜？當(dāng)使用者知道自己所在公網(wǎng)地址以及內(nèi)部NAT映射端口時(shí)凯正，它便可以講自己的公網(wǎng)地址和端口號(hào)通知對(duì)方，這樣對(duì)方就可以在茫茫大網(wǎng)中找到自己豌蟋。
在以往統(tǒng)計(jì)中廊散，WebRTC通過STUN建立連接的成功率為86%。
-
TURN（Traversal Using Relay NAT）
TURN[2]是一個(gè)client-server協(xié)議梧疲。TURN的NAT穿透方法與STUN類似允睹，都是通過取得應(yīng)用層中的公有地址達(dá)到NAT穿透。但實(shí)現(xiàn)TURN client的終端必須在通訊開始前與TURN server進(jìn)行交互幌氮，并要求TURN server產(chǎn)生"relay port"缭受，也就是relayed-transport-address。這時(shí)TURN server會(huì)建立peer该互，即遠(yuǎn)端端點(diǎn)（remote endpoints）米者，開始進(jìn)行中繼（relay）的動(dòng)作，TURN client利用relay port將資料傳送至peer慢洋，再由peer轉(zhuǎn)傳到另一方的TURN client塘雳。
TURN 和 STUN
STUN服務(wù)在查詢出客戶端所在IP和端口后，其所成功建立的連接是直接通過端與端之間的連接的普筹。
TURN服務(wù)是通過TURN服務(wù)器（擁有公網(wǎng)地址）作為中間人進(jìn)行轉(zhuǎn)發(fā)败明，所以如果TURN服務(wù)速度比STUN慢，而且是需要消耗TURN服務(wù)器帶寬太防。
