這一篇我們來講一下WebRTC協議，之前我總結過一篇各種網路協議的總結，沒看過的朋友建議先看下這篇web知識梳理，有助於加深這篇關於WebRTC的理解。
基本概念
WebRTC是由Google主導的，由一組標準、協議和JavaScript API組成，用於實現瀏覽器之間（端到端之間）的音訊、視訊及資料共享。WebRTC不需要安裝任何外掛，通過簡單的JavaScript API就可以使得實時通訊變成一種標準功能。
現在各大瀏覽器以及終端已經逐漸加大對WebRTC技術的支援。下圖是webrtc官網給出的現在已經提供支援了的瀏覽器和平臺。
Android上實現一個WebRTC專案
在深入講解協議之前，我們先來看例項。我們先來看下在Android中實現一個WebRTC的程式碼示例。
引入依賴包
首先，引入WebRTC依賴包，這裡我是使用Nodejs下的socket.io庫實現WebRTC信令伺服器的，所以也要引入socket.io依賴包。
...
dependencies {
...
implementation 'io.socket:socket.io-client:1.0.0'
implementation 'org.webrtc:google-webrtc:1.0.+'
implementation 'pub.devrel:easypermissions:1.0.0'
}
複製程式碼初始化核心類PeerConnectionFactory
PeerConnectionFactory.initialize(PeerConnectionFactory
.InitializationOptions
.builder(this)
.createInitializationOptions());
複製程式碼採集本地視訊流
從Android裝置的攝像頭獲取視訊流，進入Activity的時候開啟攝像頭。
@Override
protected void onResume() {
super.onResume();
videoCapturer.startCapture(VIDEO_RESOLUTION_WIDTH, VIDEO_RESOLUTION_HEIGHT,
VIDEO_FPS);
}
複製程式碼private VideoCapturer createVideoCapturer() {
if (Camera2Enumerator.isSupported(this)) {
return createCameraCapturer(new Camera2Enumerator(this));
} else {
return createCameraCapturer(new Camera1Enumerator(true));
}
}
private VideoCapturer createCameraCapturer(CameraEnumerator enumerator) {
final String[] deviceNames = enumerator.getDeviceNames();
// First, try to find front facing camera
Log.d(TAG, "Looking for front facing cameras.");
for (String deviceName : deviceNames) {
if (enumerator.isFrontFacing(deviceName)) {
Logging.d(TAG, "Creating front facing camera capturer.");
VideoCapturer videoCapturer = enumerator.createCapturer(deviceName, null);
if (videoCapturer != null) {
return videoCapturer;
}
}
}
// Front facing camera not found, try something else
Log.d(TAG, "Looking for other cameras.");
for (String deviceName : deviceNames) {
if (!enumerator.isFrontFacing(deviceName)) {
Logging.d(TAG, "Creating other camera capturer.");
VideoCapturer videoCapturer = enumerator.createCapturer(deviceName, null);
if (videoCapturer != null) {
return videoCapturer;
}
}
}
return null;
}
surfaceTextureHelper = SurfaceTextureHelper.create("CaptureThread",
rootEglBase.getEglBaseContext());
videoCapturer.initialize(surfaceTextureHelper, getApplicationContext(),
videoSource.getCapturerObserver());
videoTrack.setEnabled(true);
複製程式碼渲染視訊
我們需要一個WebRTC封裝過後的SurfaceViewRenderer來渲染視訊來表示本地視訊流。
<org.webrtc.SurfaceViewRenderer
android:id="@+id/view_local"
android:layout_width="150dp"
android:layout_height="150dp" />
複製程式碼然後對這個控制元件進行渲染：
localView.init(mRootEglBase.getEglBaseContext(), null);
localView.setScalingType(RendererCommon.ScalingType.SCALE_ASPECT_FILL);
localView.setMirror(true);
localView.setEnableHardwareScaler(false);
//渲染視訊流
videoTrack.addSink(localView);
複製程式碼建立PeerConnection物件
要想從遠端獲取資料，我們就必須建立 PeerConnection 物件。該物件的用處就是與遠端建立聯接，並最終為雙方通訊提供網路通道。
PeerConnection peerConnection = factory.createPeerConnection(
iceServers, //ICE伺服器列表，幹什麼用下面會詳細解釋
constraints, //MediaConstraints
this); //Context
peerConnection.addTrack(videoTrack, mediaStreamLabels);
peerConnection.addTrack(audioTrack, mediaStreamLabels);
複製程式碼使用DataChannel進行資料傳遞
/**
*DataChannel.Init 可配引數說明：
*ordered：是否保證順序傳輸；
*maxRetransmitTimeMs：重傳允許的最長時間；
*maxRetransmits：重傳允許的最大次數；
**/
DataChannel.Init init = new DataChannel.Init();
dataChannel = peerConnection.createDataChannel("dataChannel", init);
複製程式碼傳送訊息：
byte[] msg = message.getBytes();
DataChannel.Buffer buffer = new DataChannel.Buffer(
ByteBuffer.wrap(msg),
false);
dataChannel.send(buffer);
複製程式碼onMessage()回撥收訊息：
ByteBuffer data = buffer.data;
byte[] bytes = new byte[data.capacity()];
data.get(bytes);
String msg = new String(bytes);
複製程式碼WebRTC協議詳解
下面這張圖清楚的描述了WebRTC的協議分層，該圖引自《web效能權威指南》，如有侵權，立馬刪掉。
傳輸層協議
WebRTC實時通訊傳輸音視訊的場景，講究的是實時，當下，處理音訊和視訊流的應用一定要補償間歇性的丟包，所以實時性的需求是大於可靠性的需求的。
如果使用TCP當傳輸層協議的話，如果中間出現丟包的情況，那麼後續的所有的包都會被緩衝起來，因為TCP講究可靠、有序，如果不清楚的朋友可以去看我上一篇關於TCP的內容講解，web知識梳理。而UDP則正好相反，它只負責有什麼訊息我就傳過去，不負責安全，不負責有沒有到達，不負責交付順序，這裡從底層來看是滿足WebRTC的需求的，所以WebRTC是採用UDP來當它的傳輸層協議的。
當然這裡UDP只是作為傳輸層的基礎，想要真正的達到WebRTC的要求，我們就要來分析在傳輸層之上，WebRTC做了哪些操作，用了哪些協議，來達到WebRTC的要求了。
RTCPeerConnection通道
RTCPeerConnection代表一個由本地計算機到遠端的WebRTC連線。 該介面提供了建立，保持，監控，關閉連線的方法的實現，簡而言之就是代表了端到端之間的一條通道。api呼叫上面程式碼裡已經看到了，接下來我們就一點點的來剖析這條通道都用了哪些協議。
P2P內網穿透
上面我們也提到了UDP其實只是在IP層的基礎上做了一些簡單封裝而已。而WebRTC如果要實現端到端的通訊效果的話，必定要面臨端到端之間很多層防火牆，NAT裝置阻隔這些一系列的問題。之前我試過寫了原生的webrtc 發現只要不在同一段區域網下面，經常會出現掉線連不上的情況。相同的道理這裡就需要做 NAT 穿透處理了。
NAT穿透是啥，在講NAT穿透之前我們需要先提幾個概念：
- 公有IP地址是在Internet上全域性唯一的IP地址，僅有一個裝置可能擁有公有IP地址。
- 私有IP地址是非全域性的唯一的IP地址，可能同時存在於很多不同的裝置上。私有IP地址永遠不會直接連線到internet。那私有IP地址的裝置如何訪問網路呢？
就是這個NAT（NetWork Address Translation），它允許單個裝置（比如路由器）充當Internet（公有IP）和專有網路（私有IP）之間的代理。所以我們就可以通過這個NAT來處理很多層防火牆後那個裝置是私有IP的問題。
路通了，那麼就有另一個問題了，兩個WebRTC客戶端之間，大概率會存在A不知道B的可以直接傳送到的IP地址和埠，B也不知道A的，那麼又該如何通訊呢？
這就要說到ICE了，也就是互動式連線建立。ICE允許WebRTC克服顯示網路複雜性的框架，找到連線同伴的最佳途徑並連線起來。
在大多數的情況下，ICE將會使用STUN伺服器，其實使用的是在STUN伺服器上執行的STUN協議，它允許客戶端發現他們的公共IP地址以及他們所支援的NAT型別，所以理所當然STUN伺服器必須架設在公網上。在大多數情況下，STUN伺服器僅在連線設定期間使用，並且一旦建立該會話，媒體將直接在客戶端之間流動。
具體過程讓我們來看圖會更清楚，WebRTC兩個端各自有一個STUN伺服器，通過STUN伺服器來設定連線，一旦建立連線會話，媒體資料就可以直接在兩個端之間流動。
剛才也說了大多數的情況，如果發生STUN伺服器無法建立連線的情況的話，ICE將會使用TURN中繼伺服器，TURN是STUN的擴充套件，它允許媒體遍歷NAT，而不會執行STUN流量所需的“一致打孔”，TURN伺服器實際上在WebRTC對等體之間中繼媒體，所以我這裡理解的話使用TURN就很難被稱為端對端之間通訊了。 同樣，我們畫個圖來形容TURN中繼伺服器的資料流動方式：
媒體協議
WebRTC 以完全託管的形式提供媒體獲取和交付服務:從攝像頭到網路，再從網路到螢幕。 從上面的Android demo中我們可以看到，我們除了一開始制定媒體流的約束以外，編碼優化、處理丟包、網路抖動、錯誤恢復、流量、控制等等操作我們都沒做，都是WebRTC自己來控制的。這裡WebRTC 是怎麼優化和調整媒體流的品質的呢? 其實WebRTC 只是重用了 VoIP 電話使用的傳輸 協議、通訊閘道器和各種商業或開源的通訊服務:
-
安全實時傳輸協議(SRTP，Secure Real-time Transport Protocol) 通過 IP 網路交付音訊和視訊等實時資料的標準安全格式。
-
安全實時控制傳輸協議(SRTCP，Secure Real-time Control Transport Protocol) 通過 SRTP 流交付傳送和接收方統計及控制資訊的安全控制協議。
資料協議
我們都知道UDP是不安全的，但是WebRTC要求所有傳輸的資料（音訊、視訊和自定義應用資料）都必須加密，所以這裡就要引入一個DTLS協議的概念。
DTLS說白了，其實就是因為TLS無法保證UDP上傳輸的資料的安全，所以在現存的TLS協議架構上提出了擴充套件，用來支援UDP。其實就是TLS的一個支援資料包傳輸的版本。
既然知道了DTLS可以說是TLS的擴充套件版以後，我們再來看看dtls解決了哪些問題。首先先來看TLS的問題，剛才我們也提到了TLS不能直接用於資料包環境，主要的原因是包可能會出現丟失或者重排序的情況，而TLS無法處理這種不可靠性，而無法處理這種不可靠性就帶來了兩個問題：
- TLS無法對某個記錄單獨解密，什麼意思呢？如果A和B之間傳遞訊息，訊息以1到10依次為序列號，如果訊息5沒收到，那麼6以後的訊息都會報錯，這裡無法通過TLS的完整性校驗，而且如果順序不對，也無法通過TLS的完整性校驗。
- TLS握手層假定握手訊息是可靠投遞的，如果訊息丟失則會中斷。
那麼DTLS是如何在儘可能與TLS相同的情況下解決以上兩個問題的呢？
首先在DTLS中，每個握手訊息都會在握手的時候分配一個序列號和分段偏移欄位，當收訊息的那一方收到一個握手訊息的時候，會根據這個序列號來判斷是否是期望的下一個訊息，如果不是則放入佇列中，這樣就滿足了有序交付的條件，如果順序不對就報錯，跟TLS一樣。而分段偏移欄位是為了補償UDP報文的1500位元組大小限制問題。
至於丟包問題，DTLS採用了兩端都使用一個簡單的重傳計時器的方法，還是上面序列號為1到10的例子，如果A發給B一個序列號為5的訊息，然後希望從B那裡獲取到序列號為6的訊息，但是沒收到，超時了，A就知道他發的5或者B給的6這個訊息丟失了，然後就會重新傳送一個重傳包，也就是5這個訊息。
為保證過程完整，A和B兩端都要生成自已簽名的證照，而WebRTC會自動為每一端生成自已簽名的證照，然後按照常規的 TLS 握手協議走。
DataChannel
除了傳輸音訊和視訊資料，WebRTC 還支援通過 DataChannel API 在端到端之間傳 輸任意應用資料。DataChannel 依賴於 SCTP(Stream Control Transmission Protocol，流控制傳輸協議)，而 SCTP 在兩端之間建立的 DTLS 通道之上執行的。
DataChannel api呼叫和WebSocket類似，上面的Android專案中我們已經講過了，接下來我們來詳細講下DataChannel所依賴的SCTP協議。
SCTP
SCTP同時具備了TCP和UDP中最好的功能：面向訊息的 API、可配置的可靠性及交付語義，而且內建流量和擁塞控制機制。
因為本身UDP相對TCP來說比較簡單，之前也提到UDP只是對IP層的一個簡單封裝而已，所以這裡我們就通過比較TCP和SCTP的區別來簡單的講講SCTP到底是什麼東西和為什麼具備TCP和UDP兩者最好的功能。
-
TCP是單流有序傳輸，SCTP是多流可配置傳輸 上一篇web知識梳理中我們也講過，TCP在一條連線中可以複用TCP連線，是單流的，而且是有順序的，如果一條訊息出了問題的話，後面的所有訊息都會出現阻塞的情況，強調順序。而SCTP可以區分多條不同的流，不同的流之間傳輸資料互不干擾，在有序和無序的問題上，SCTP是可配置的，又可以像TCP那樣交付次序可序化，也可以像UDP那樣亂序交付。
-
TCP是單路徑傳輸，SCTP是多路徑傳輸 SCTP兩端之間的連線可以繫結多條IP，只要有一條連線是通的，那麼就是通的，熟悉TCP的朋友應該都知道，TCP之間只能用一個IP來連線。
-
TCP連線建立是三次握手，SCTP則需要四次握手 上一篇web知識梳理中我們也已經講過TCP的三次握手了，SCTP的四次握手比TCP多了一個步驟：server端在收到連線請求時，不會像TCP三次握手那樣子收到請求訊息以後立馬分配記憶體，將其快取起來，而是返回一個COOKIE訊息。 client端需要回送這個COOKIE，server端對這個COOKIE進行校驗以後，從cookie中重新獲取有效資訊（比如對端地址列表），兩端之間才會連線成功。
-
TCP以位元組為單位傳輸，SCTP以資料塊為單位傳輸 塊是SCTP 分組中的最小通訊單位，核心概念與HTTP 2.0分幀層中的那些概念基本一樣，沒看過的朋友可以參考web知識梳理
ok，到這裡基本把WebRTC通訊協議的應用，以及要用到的協議啊概念啊什麼的都過了一遍，要實現低延遲的，端到端的通訊傳輸不是一件容易的事情。相信隨著WebRTC不斷的完善，支援的端也會越來越多，效能也會越來越完善。