摘要
介於英語考試在即，當前工作需要，特意找了這本書，原書《Learning_WebRTC_Develop_interactive》，之前好久都沒有中文版，執意決定自行翻譯。後來在豆瓣閱讀找到了翻譯版，有需要者可以移步購買Learning WebRTC中文版。
說實話，WebRTC沒有網絡基礎是不太容易消化理解，這本書的好處是重實踐，在實踐成果中慢慢理解深奧的計算機網絡。2017年著作，其中一些api相繼廢棄，本人在原書pdf中做了修改批註，有需要的聯繫[email protected]。
第三章是一個核心篇章，所以決定從此開始翻譯，前面兩章是基礎，比較簡單，後續會補上翻譯文，大概計劃與本年底翻譯完整本。
能力不高，技術有限，文章僅供參考，勿噴！！！
創建一個基礎應用
理解udp實時傳輸
webrtc應用首選udp傳輸的原因是，它提供了高性能傳輸，不用像tcp那樣控制數據的準確性。目前，大多數web應用都建立在tcp協議之上，原因在於它爲用戶提供保證，其中一些特性如下：
- 發送的所有數據都會接收到確認
- 數據一旦發送失敗，將停止繼續發送並重新發送失敗的數據
- 確保數據唯一性
今天，大多數的web應用選擇tcp，也正式基於這些特性。假如，你發送一個html頁面，讓所有數據以正確的順序排列並確保它到達另一方是有意義的。但是，這一技術不否和所有的用戶場景。例如，在多人遊戲中傳輸數據。視頻遊戲中的大多數數據在幾秒鐘甚至更短時間內變得陳舊，這就意味着用戶只關心過去幾秒內發生的事情，僅此而已。如果需要保證每一條數據都能到達另一方，那麼當數據丟失時，這可能會導致很大的瓶頸。
因爲tcp約束的原因，使得webrtc的開發人員首選udp作爲他們的傳輸方式。webrtc的音頻和視頻並不需要的可靠的連接，而是，需要高性能傳輸。我們可以接收丟包，從而，也意味着，對於這類的應用程序來說，udp是一個更好的選擇。
UDP通過做出大量的不保證來實現這種情況，它被構建成一個不太可靠的傳輸層，對您發送的數據進行較少的假設。upd不可靠傳輸的原因如下：
- 不確定數據發送給對方的順序
- 傳輸過程中可能丟包，不能確保每個數據包都能準確無誤的發送給對方
- 不跟蹤數據包的狀態，即時客戶端丟失數據，也不會停止發送數據
現在，webrtc可以以儘快的方式發送音頻和視頻，這也透漏出webrtc是一個多麼複雜的主題。並不是每個網絡都允許udp流量通過，具有企業防火牆的大型網絡可以直接阻止UDP流量，以防止惡意連接。這些連接必須沿着與今天大多數網頁下載不同的路徑傳播。必須圍繞UDP構建許多變通方法和流程，以使其適用於廣泛的受衆。在WebRTC技術方面，這只是冰山一角。在接下來的幾節中，我們將介紹在瀏覽器中啓用WebRTC的其他支持技術。
webrtc接口
接下來的幾節將介紹目前在瀏覽器中實現的WebRTC API。這些函數和對象允許開發人員與WebRTC層進行通信，並與其他用戶建立對等連接。它由幾個主要技術組成：
- The RTCPeerConnection object
- Signaling and negotiation
- Session Description Protocol (SDP)
- Interactive Connectivity Establishment (ICE)
The RTCPeerConnection object
RTCPeerConnection是webrtc api的主入口點。提供初始化連接、對等連接、賦值媒體信息。它處理與另一個用戶的UDP連接的創建。現在我們開始熟悉這個api，因爲在本書的其餘部分將會多次出現。
RTCPeerConnection的主要作用是在瀏覽器中維護對等連接的會話和狀態。它還處理對等連接的設置和創建。它封裝了所有這些內容，並公開了一組在連接過程中的關鍵點被觸發的事件。通過這些事件，您可以訪問對等連接期間發生的配置和內部信息：
RTCPeerConnection對象是瀏覽器中的一個簡單對象，可以使用新的構造函數進行實例化，如下所示：
var myConnection = new RTCPeerConnection(configuration);
myConnection.onaddstream = function (stream) {
// Use stream here
};連接接受配置對象，我們將在本章後面介紹。在示例中，我們還爲onaddstream事件添加了一個處理程序。
當遠程用戶將視頻或音頻流添加到其對等連接時，會觸發此操作。我們還將在本章後面介紹這一點。
信令和協商
通常，連接到另一個瀏覽器需要知道瀏覽器在網絡上的位置。通常情況下是採用ip地址和端口號的方式尋找目的主機。你的計算機或移動設備的IP地址允許其他啓用Internet的設備直接在彼此之間發送數據; 這就是RTCPeerConnection的基礎。一旦這些設備知道如何在互聯網上找到彼此，他們還需要知道如何相互交談。這意味着交換有關每個設備支持的協議以及音視頻編解碼器等有關數據。
這也意味着，爲了連接到另一個用戶，你需要更多的瞭解他們。一種可能的解決方案是在你的計算機上存儲可以連接到的用戶的列表。要啓用與其他用戶的通信，您只需交換聯繫信息，讓WebRTC處理其餘的信息。然而，這有一個弊端，你必須和你需要連接的用戶手動共享信息。你必須維護一個您想要連接的任何用戶的大列表，並通過其他通信渠道交換信息。使用WebRTC，我們可以使這一過程自動化。
幸運的是，我們今天使用的大多數Web通信應用程序中解決了這個問題。要與Facebook或LinkedIn等熱門服務上的任何人聯繫，您只需要知道他們的名字並搜索他們。然後，你可以將他們添加到已知聯繫人列表中，並隨時訪問其信息。
這一過程就是WebRTC中的信令和協商。
信令過程包括幾個步驟：
- 生成對等連接的潛在候選列表。
- 用戶或算法將選擇用戶進行連接。
- 信令層將通知該用戶有人想要與他/她聯繫，並且他/她可以接受或拒絕。
- 通知第一個用戶接收要約連接。
- 如果接受，第一個用戶將與另一個用戶啓動
RTCPeerConnection。 - 用戶都將通過信令信道交換有關其計算機的硬件和軟件信息。
- 兩個用戶還將通過信令信道交換關於他們的計算機的位置信息。
- 用戶之間的連接成功或失敗。
然而，這只是WebRTC信令可能發生的一個例子。實際上，WebRTC規範沒有包含關於兩個用戶如何交換信息的任何標準。這是由於不斷增加的連接用戶標準列表。今天存在許多標準，甚至在信號和談判過程中創造了更多標準。WebRTC標準作者決定，試圖就一個標準達成一致意見將阻止它向前發展。
這本書中，我們將建立自己的信令和協商履行條約。編寫一個可以在兩個瀏覽器之間傳輸信息的簡單服務器。雖然它很簡單並且容易出現安全漏洞，但它應該讓你很好地理解這個過程在WebRTC中是如何工作的。同時，你也可以探究其他公司提供的信令方案。有數百種信令和談判解決方案，每天都有更多的信息和協商解決方案。有些集成了當前的電話或基於聊天的實現，例如XMPP或SIP，有些還提出了一種全新的信令方式。
會話描述協議
要與其他用戶建立聯繫，您需要先了解一下這些用戶。關於另一個客戶端的一些最重要的事情是他們支持的音頻和視頻編解碼器，他們的網絡帶寬，以及他們的計算機可以處理多少數據，而且還需要在客戶之間輕鬆傳輸。由於我們沒有指定如何傳輸這些數據，因此它也應該能夠通過多種類型的傳輸協議進行傳輸。這意味着我們需要一個基於字符串的名片，其中包含我們可以發送給其他用戶的所有用戶信息。SDP正好爲我們提供了這樣的功能。