摘要：最后，消息成功抵達(dá)并顯示在頁面上。在中，所有的數(shù)據(jù)都使用數(shù)據(jù)報(bào)傳輸層安全性。如果應(yīng)用知識簡單的一對一文件傳輸，使用不可靠的數(shù)據(jù)通道將需要設(shè)計(jì)一定的響應(yīng)重傳協(xié)議。目前建議的最大塊大小為。

本文翻譯自WebRTC data channels

在兩個(gè)瀏覽器中，為聊天、游戲、或是文件傳輸?shù)刃枨蟀l(fā)送信息是十分復(fù)雜的。通常情況下，我們需要建立一臺服務(wù)器來轉(zhuǎn)發(fā)數(shù)據(jù)，當(dāng)然規(guī)模比較大的情況下，會(huì)擴(kuò)展成多個(gè)數(shù)據(jù)中心。這種情況下很容易出現(xiàn)很高的延遲，同時(shí)難以保證數(shù)據(jù)的私密性。

這些問題可以通過WebRTC提供的RTCDataChannel API來解決，他能直接在點(diǎn)對點(diǎn)之間傳輸數(shù)據(jù)。這篇文章將介紹如何創(chuàng)建并使用數(shù)據(jù)通道，并提供了一些網(wǎng)絡(luò)上常見的用例

  
為了充分理解這篇文章，你可能需要去了解一些RTCPeerConnection API的相關(guān)知識，以及STUN，TURN、信道如何工作。強(qiáng)烈推薦Getting Started With WebRTC這篇文章

我們已經(jīng)有WebSocket、AJAX和服務(wù)器發(fā)送事件了，為什么我們需要另外一個(gè)通信信道？WebSocket是全雙工的，但這些技術(shù)的設(shè)計(jì)都是讓瀏覽器與服務(wù)器之間進(jìn)行通信。

RTCDataChannel則是一個(gè)完全不同的途徑：
* 它通過RTCPeerConnection API，可以建立點(diǎn)對點(diǎn)互聯(lián)。由于不需要中介服務(wù)器，中間的“跳數(shù)”減少，延遲更低。
* RTCDataChannel使用Stream Control Transmission Protocol(SCTP)協(xié)議，允許我們配置傳遞語義：我們可以配置包傳輸?shù)捻樞虿⑻峁┲貍鲿r(shí)的一些配置。

基于SCTP的支持的RTCDataChannel已經(jīng)能夠在桌面的Chrome、Opera和Firefox中使用，移動(dòng)端則有Android支持。

盡管WebRTC允許點(diǎn)對點(diǎn)的通信，但它依然需要服務(wù)器：
* 信令傳輸：建立點(diǎn)對點(diǎn)的連接需要傳輸一些媒體和網(wǎng)絡(luò)相關(guān)的元數(shù)據(jù)信息，需要通過服務(wù)器
* NAT和防火墻穿透：我們需要通過ICE框架來建立點(diǎn)與點(diǎn)之間的網(wǎng)絡(luò)路徑。可以使用STUN服務(wù)器（確定雙方的可公開訪問你的IP地址和端口）以及TURN服務(wù)器（如果直接連接失敗，就必須數(shù)據(jù)中繼了）

WebRTC in the real world: STUN, TURN, and signaling 文章詳細(xì)介紹了WebRTC如何與這兩種服務(wù)器進(jìn)行交互

RTCDataChannel API支持靈活的數(shù)據(jù)類型。它的API是模仿WebSocket設(shè)計(jì)的，并且支持JavaScript中的二進(jìn)制類型如Blob、ArrayBuffer和ArrayBufferView，另外還支持字符串。這些類型對于文件傳輸和多玩家的游戲來說意義重大。

以上來自Ilya Grigorik的High Performance Browser Networking

RTCDataChannel在不可靠模式（類似于UDP）或可靠模式（類似于TCP）下都能夠正常工作。但這兩種模式有一些不同：
* 可靠模式：保證消息傳輸一定成功，并保證按序到達(dá)。這自然需要一定量的開銷，速度也更慢
* 不可靠模式：不保證消息傳輸一定成功，也不保證按序到達(dá)。這消除了那些開銷，速度也更快

在不會(huì)丟包的情況下，這兩種模式的效率差不多。然而，可靠模式下，丟包將造成后續(xù)的所有包阻塞，丟失的數(shù)據(jù)包也將重傳直至其成功到達(dá)。當(dāng)然，我們能在同一個(gè)應(yīng)用中使用多個(gè)數(shù)據(jù)通道，每一個(gè)有他們自己的可靠性

下面將說明如何去配置可靠模式或不可靠模式的RTCDataChannel

網(wǎng)上已經(jīng)有很多RTCDataChannel的例子了：
* simpl.info/dc
* googlechrome.github.io/webrtc/dc1.html(SCTP或者RTP)
* pubnub.github.io/webrtc(兩個(gè)PubNub用戶)

ps：PubBub是一個(gè)實(shí)時(shí)信息通訊應(yīng)用開發(fā)公司

在這個(gè)例子中，瀏覽器創(chuàng)建了一個(gè)對等連接連接到自己。然后在這個(gè)對等連接n上創(chuàng)建了一個(gè)數(shù)據(jù)通道，發(fā)送了一些消息。最后，消息成功抵達(dá)并顯示在頁面上。

var peerConnection = new RTCPeerConnection();

//使用信令傳輸信道創(chuàng)建對等連接
var dataChannel =
  peerConnection.createDataChannel("myLabel", dataChannelOptions);

dataChannel.onerror = function (error) {
  console.log("Data Channel Error:", error);
};

dataChannel.onmessage = function (event) {
  console.log("Got Data Channel Message:", event.data);
};

dataChannel.onopen = function () {
  dataChannel.send("Hello World!");
};

dataChannel.onclose = function () {
  console.log("The Data Channel is Closed");
};

dataChannel對象建立在一個(gè)已經(jīng)創(chuàng)建完畢的對等連接之上。它可以創(chuàng)建在信令傳輸前后。另外，可以賦予一個(gè)label來作區(qū)分，并提供一系列的配置選項(xiàng)：

var dataChannelOptions = {
  ordered: false, //不保證到達(dá)順序
  maxRetransmitTime: 3000, //最大重傳時(shí)間
};

我們可以加入一個(gè)maxRetransimits選項(xiàng)（最大重傳次數(shù)），但maxRetransimitTime或maxRetransimits只能設(shè)定一個(gè)，不能兩個(gè)懂事設(shè)定。如果想使用UDP的方式，設(shè)定maxRetransmits為0，ordered為false。如果想要獲取更多信息，請查看RFC 4960（SCTP）和RFC 3758（SCTP部分可靠性）
* ordered: 數(shù)據(jù)通道是否保證按序傳輸數(shù)據(jù)
* maxRetrasmitTime：在信息失敗前的最大重傳時(shí)間（強(qiáng)迫進(jìn)入不可靠模式）
* maxRetransmits：在信息失敗前的最大重傳次數(shù)（強(qiáng)迫進(jìn)入不可靠模式）
* protocol：允許使用一個(gè)自協(xié)議，但如果協(xié)議不支持，將會(huì)失敗
* negotiated：如果設(shè)為true，將一處對方的數(shù)據(jù)通道的自動(dòng)設(shè)置，也就是說，將使用相同的id以自己配置的方式與對方建立數(shù)據(jù)通道
* id：為數(shù)據(jù)通道提供一個(gè)自己定義的ID

在WebRTC所有的組件中，都會(huì)強(qiáng)制進(jìn)行加密。在RTCDataChannel中，所有的數(shù)據(jù)都使用數(shù)據(jù)報(bào)傳輸層安全性（DTLS）。DTLS是SSL的衍生，也就是說，你的數(shù)據(jù)將和使用基于SSL的連接一樣安全。DTLS已經(jīng)被標(biāo)準(zhǔn)化，并內(nèi)置于所有支持WebRTC的瀏覽器中。如果需要更多關(guān)于DTLS信息，請?jiān)L問Wireshark的維基

處理大批量的數(shù)據(jù)，一直是JavaScript的一個(gè)難點(diǎn)。正如Sharefest所提出的觀點(diǎn)，我們需要用一種新的方式來考慮數(shù)據(jù)。如果你需要傳輸一個(gè)比你當(dāng)前可用內(nèi)存更大的文件，就必須考慮新的保存信息的方式了。這也就是像FileSystem API等技術(shù)存在的意義。我們將在下面進(jìn)行介紹

現(xiàn)在我們可以通過RTCDataChannel來創(chuàng)建文件共享應(yīng)用。將應(yīng)用建立在RTCDataChannel智商也意味著傳輸?shù)奈募?shù)據(jù)都將加密，而且不會(huì)經(jīng)過應(yīng)用的服務(wù)器端。通過這個(gè)功能，我們能夠?qū)崿F(xiàn)多用戶之間的互聯(lián)，進(jìn)行文件共享。

需要成功傳輸一個(gè)文件，我們需要如下幾步：
1. 通過JavaScript的File API讀取文件數(shù)據(jù)
2. 使用RTCPeerConnection在用戶間創(chuàng)建一個(gè)對等連接
3. 使用RTCDataChannel在用戶間創(chuàng)建一個(gè)數(shù)據(jù)通道

在使用RTCDataChannel時(shí)，還有一些其他問題需要考慮：
* 文件大小：如果文件很小，能夠直接通過一個(gè)Blob進(jìn)行存儲和讀取，那么我們可以直接使用File API將其讀進(jìn)內(nèi)存，并通過可靠的數(shù)據(jù)通道發(fā)送（但是需要注意的是，瀏覽器有最大傳輸大小的限制）。隨著文件變大的話，就不那么簡單了。我們需要一個(gè)分塊機(jī)制：文件將分成多個(gè)碎片，稱為文件塊。我們不再直接發(fā)送整個(gè)文件，而是一次發(fā)送一個(gè)文件塊。當(dāng)然文件塊上會(huì)有一些元數(shù)據(jù)如塊的ID，方便對方能夠識別。接收到文件塊之后，首先將這些文件塊保存在離線存儲中（例如，使用FileSystem API），只有當(dāng)所有塊都接收完畢，才將其拼合起來成為完整的文件，保存到用戶的硬盤。
* 速度：文件傳輸更適合使用可靠模式（像TCP）還是非可靠模式（像UDP）還有待商榷。如果應(yīng)用知識簡單的一對一文件傳輸，使用不可靠的數(shù)據(jù)通道將需要設(shè)計(jì)一定的響應(yīng)/重傳協(xié)議。你必須自己來實(shí)現(xiàn)它，就算你非常優(yōu)秀，它仍然不會(huì)比使用可靠的數(shù)據(jù)傳輸快多少。可靠而無序的數(shù)據(jù)通道將會(huì)更加合適，但是如果是多方文件傳輸，結(jié)果可能會(huì)有所不同。
* 塊大小：這些是你的應(yīng)用中的最小的“原子”數(shù)據(jù)。目前有傳輸大小限制（盡管以后可能不會(huì)有限制），所以必須要進(jìn)行分塊。目前建議的最大塊大小為16KB。

如果文件已經(jīng)被完全傳輸，就可以使用一個(gè)a標(biāo)簽提供下載了：

function saveFile(blob) {
  var link = document.createElement("a");
  link.href = window.URL.createObjectURL(blob);
  link.download = "File Name";
  link.click();
};

目前已經(jīng)有兩個(gè)文件共享的應(yīng)用使用了這種方式：pubnub.github.io/rtc-pubnub-fileshare和github.com/Peer5/ShareFest，這兩個(gè)應(yīng)用都是開源的，并提供了基于RTCDataChannel的文件共享

RTCDataChannel為文件共享、多人游戲以及內(nèi)容交付應(yīng)用提供了全新的實(shí)現(xiàn)思路：
* 上面已經(jīng)提到了點(diǎn)對點(diǎn)的文件傳輸了
* 多人游戲，與諸如WebGL等其他技術(shù)相結(jié)合，比如Mozilla的Banana Bread
* 內(nèi)容交付：由PeerCDN重新改造的一個(gè)用于提供點(diǎn)對點(diǎn)通信提供資源的框架

現(xiàn)在我們可使用高新能、低延遲的RTCDataChannel來創(chuàng)建更優(yōu)秀的應(yīng)用了。一些框架，諸如PeerJS和PubNub WebRTC SDK，使得RTCDataChannel更加易于使用，其API也被各個(gè)平臺所支持

RTCDataChannel所帶來的優(yōu)勢能夠改變你在瀏覽器中傳輸數(shù)據(jù)的觀念。

Getting started with WebRTC

WebRTC in the real world: STUN, TURN and signaling

WebRTC resources

W3C Working Draft

IETF WebRTC Data Channel Protocol Draft

How to send a File Using WebRTC Data API

7 Creative Uses of WebRTC’s Data Channel

Banana Bread 3D first person shooter game compiled to JS+WebGL, using WebRTC data channels in multiplayer mode