當你想要找到你 WebRTC 產(chǎn)品中的問(wèn)題時(shí)，webrtc-internals 是一個(gè)非常棒的工具，因為你需要用它測試 WebRTC 以及 debug，或者你需要對你的配置進(jìn)行微調。
如何獲得 webrtc-internals 的數據轉儲（ stats dump ）
如果你對這個(gè)工具不熟悉的話(huà)，那么打開(kāi)你 Chrome 瀏覽器里的 WebRTC 段，在這段里打開(kāi)另一個(gè)表單并且將其指向這個(gè)內部（ internal ）URL：chrome://webrtc-internals/
webrtc-internals 允許將軌道作為大型的 JSON 下載下來(lái)，這樣你就可以一層一層地來(lái)看它了，但是當你這么做的時(shí)候，你會(huì )看到類(lèi)似這樣的東西：
查看webrtc-internals數據
人們通常問(wèn)到的第一件事是—這些數字到底代表什么？我們自己的一位測試人員將這些值放入時(shí)序圖表里并且將其輸出出來(lái)。這就給了我們要比直接從 webrtc-internals 中取出的300×140的圖片要大的多的圖表。
這些圖表是使用 HighCharts 庫得到的，并且有很多十分方便的特性，比如隱藏線(xiàn)條，放大所需區域，或者停靠在特定點(diǎn)處并顯示精確值。這比用 JSON 轉儲（像上面一樣）要方便的多。
回到基礎的 webrtc-internals 頁(yè)中。在此頁(yè)頂端，我們可以考到一系列的表單，一個(gè)是給getUserMedia調用的，剩下的兩個(gè)分別給每個(gè) RTCPeerConnection。
在 GetUserMedia 請求表單中，我們可以看到每次的 getUserMedia 調用，以及相關(guān)約束。不幸的是，我們不能看到結果或者 MediaStreams 中有的 ids。
RTCPeerConnection 數據
對于每個(gè)peerconnection，我們可以看到這四點(diǎn)：
- RTCPeerConnection 是如何配置的，也就是 STUN 和 TURN 服務(wù)器是如何被使用的，以及如何配置
- PeerConnection API 的軌跡被調用顯示在左邊。這些 API 軌跡展現了所有的RTCPeerConnection 調用和他們的參數（例如createOffer），以及回調和類(lèi)似于 onicecandidate 的事件觸發(fā)器
- 從 getStats（） API 采集的數據在右側被顯示出來(lái)
- 由 getStats（） API 產(chǎn)生的圖表在底部顯示
RTCPeerConnection API 軌跡是非常強大的工具，可以幫助你完成很多的事情，比如分析造成 ICE 失敗的原因，或者幫你找到適合部署 TURN 服務(wù)器的地方。我們會(huì )在以后的博文中來(lái)談這些。
webrtc-internals 所給出的統計數據是 Chrome 的內部格式。這意味著(zhù)其與目前的規范略有不同步，一些名稱(chēng)和結構體會(huì )有改變。在較高層，我們在 webrtc-internals 頁(yè)上看到的與我們調用這個(gè)函數所得到的結果相近：
下面是 RTCStatsReport 對象的隊列，其中有很多秘鑰和數值，可以這樣讀取：
要記住的是在這些統計數據和規范之間有一些區別。這里面有一個(gè)經(jīng)驗法則，任意一個(gè)名稱(chēng)以 “Id” 結尾的秘鑰都包含一個(gè)指向不同的報告，其 id 屬性與秘鑰的值對應。所以全部這些報告都是彼此相連的。還要注意，這些值都是字符型的，盡管它們看起來(lái)像布爾值那樣的數字。
RTCStatsReport 中最重要的屬性是報告的種類(lèi)，下面是其中的幾種：
- googTrack
- googLibjingleSession
- googCertificate
- googComponent
- googCandidatePare
- localCandidate
- remoteCandidate
- ssrc
- VideoBWE
讓我們來(lái)深入探討一下這些報告型
googTrack 與 googLibjingleSession 報告- googTrack 和 googLibjingleSession 沒(méi)包含什么信息，所以我們跳過(guò)它不做分析。
- googCertificate 報告
- googCertificate 報告包括了一些有關(guān)近端和對等端所使用的 DTLS 證書(shū)的信息，以及指紋和哈希算法。這些都在 RTCCertificateStats 字典中有詳細說(shuō)明。
googComponent 報告的作用就像是認證數據與連接之間的膠水。它包含了一個(gè)紙箱當前活躍的候選項對的指針，以及有關(guān)用語(yǔ) DTLS 和 SRTP 加密的加密套接字。
googCandidatePair 報告
googCandidatePair 對一對 ICE 候選做了描述，也就是低層次的連接。從這個(gè)報告中，你可以得到這些信息：
- 發(fā)送和接收的數據包以及字節數總數（ bytesSent，bytesReceived，packetsSent；因為不明原因丟失的 packetsReceived ）。這是一個(gè)包含 RTP 報頭的 UDP 或者 TCP字節。
- 如何判斷這是否是一個(gè)活躍的連接，googActiveConnection 的值是真則為活躍，否則為假。大多數時(shí)間你都會(huì )只對活躍的候選對感興趣。對等的規范可以在這里找到。
- 被發(fā)送和接收的 STUN 請求和應答數量是計算在 ICE 進(jìn)程中輸入和輸出的 STUN 請求數量。
- googRtt 是最新的 STUN 請求的往返時(shí)間。這與 ssrc 報告上的 googRtt 是不一樣的，我們稍后會(huì )說(shuō)。
- localCandidateId 和 remoteCandidateId 指向 localCandidate 型和 remoteCandidate型。localCandidate 和 remoteCandidate 描述了本地和遠端的ICE候選項。你可以在googLocalAddress 型上面找到絕大多數信息。
- googTr 以及 googLocalCandidateType 的值。
- googTransportType 規定了傳輸的類(lèi)型。注意這些數據的值通常是 “udp” 的，即便是在 TCP 上的 TURN 被用于連接 TURN 服務(wù)器的情況下。只有當 ICE-TCP 被使用時(shí)，此值才會(huì )是 “tcp” 的。
從下面這張圖上可以比較直觀(guān)地看到一些數據，如發(fā)送和接收的字節數等等：
- localCandidate 和 remoteCandidate 與規范中所描述的是一模一樣的，告訴我們 ip 地址，端口號，以及候選項的類(lèi)型。對于 TURN 候選來(lái)說(shuō)，其會(huì )告訴我們候選被分配在哪個(gè)端口上了。
Ssrc 報告
ssrc 報告是這里面最重要的報告之一。每一個(gè)音頻或者視頻軌道發(fā)送或接收都有一個(gè) ssrc 報告。在舊版本的規范中，這些叫做 MediaStreamTrackStats 和 RTPStreamStats 。其內容決定于這是音頻還是視頻軌道，以及這是發(fā)送還是接收。讓我們先來(lái)描述下一些其中基本的元素：
- mediaType 表示我們在觀(guān)察的是音頻數據還是視頻數據
- ssrc 屬性指定了媒體是發(fā)送ssrc還是接收
- googTrackId 會(huì )識別這些數據描述的軌跡。這個(gè) id 可以在 SDP 中，以及本地或遠端媒體流軌道中被找到。事實(shí)上，這違背了以 “ Id ” 為后綴的命名法則，通常以 “ Id ” 結束的都是一個(gè)指向其他報告的指針。Google 把 goog stats 給搞錯了。
- googRtt 表示的是往返時(shí)間。與之前說(shuō)過(guò)的往返時(shí)間不同，這個(gè)往返時(shí)間是從 RTCP 測量的時(shí)間。
- transportId，是指向被用于傳送 RTP 流的部分。通常用于音頻和視頻流的 transportId 是一樣的。
- googCodecName 規定了編譯碼器的名稱(chēng)。典型的音頻編解碼器是 opus，對于視頻來(lái)說(shuō)，使用的是 VP8，VP9 或者使用 H264。你還可以看到在 codecImplementationName 統計數據中使用的實(shí)施方案的有關(guān)信息。
- bytesSent，bytesReceived，packetsSent 以及 packetsReceived 的值可以讓你計算出總的字節數。這些數字是累加的，所以你需要在你最后一次詢(xún)問(wèn) getStats 之后要將其按時(shí)間分開(kāi)。規定中的示例代碼寫(xiě)的還不錯，單是要注意 Chrome 有事會(huì )將這些計數器重置，所以你有可能得到一個(gè)負數的速率。
- packetsLost 讓你知道有多少包在傳輸過(guò)程中丟失了。對于發(fā)送端來(lái)說(shuō)，丟包來(lái)自 RTCP，對于接收端來(lái)說(shuō)，丟包是在本地測量的。當你在檢查一個(gè)質(zhì)量不好的通話(huà)時(shí)，這個(gè)參數可能是你想要查看的最直接的數據。
音頻特性
對于音軌來(lái)說(shuō)，我們有 audioInputLevel 和 audioOutputLevel（在規范中叫做 audioLevel ）可以告訴我們音頻信號是來(lái)與麥克風(fēng)，還是通過(guò)揚聲器播出的。這個(gè)特性可以用來(lái)探測 Chrome 里不受歡迎的音頻 bug。我們還可以通過(guò) googJitterReceived 和 googJitterBufferReceived 得知有多少抖動(dòng)被接收，以及 jitter buffer 的狀態(tài)。
視頻特性
對于視頻軌道來(lái)說(shuō)，我們有兩大信息需要關(guān)注。第一個(gè)是被送入 googNacksSent，googPLIsSent 和 googFirsSent 中，NACK，PLI 和 FIR 數據包的數量差別。這可以讓我們知道丟包會(huì )如何影響視頻質(zhì)量。
更重要的是，我們得知了框架大小和速率是作為輸入（ googFrameWidthInput，googFrameHeightInput，googFrameRateInput ）并且實(shí)時(shí)上是發(fā)送到網(wǎng)絡(luò )之上（ googFrameWidthSent，googFrameHeightSent，googFrameRateSent ）。
相似的數據可以在接收端被收集到存在 googFrameWidthReceived，googFrameHeightReceived 中。對于框架速率來(lái)說(shuō)我們甚至可以將其從 googFrameRateReceived，googFrameRateDecoded 和 GOOGFrameRateOutput 中分開(kāi)來(lái)。
在編碼端我們可以看到這些值之間的差別，還能知道為什么圖片會(huì )被縮小。通常這些事情發(fā)生不是因為沒(méi)有足夠大的 CPU，就是沒(méi)有足夠大的帶寬來(lái)傳送完整的圖片。另外，想要降低框架速率（ 其可以從對比 googFrameRateInput 和 googFrameRateSent 之間的差距得到），我們需要得到額外的信息：分辨率是否因為 CPU 的問(wèn)題而得到適應，以及是否是因為帶寬不夠使得 googBandwidthLimitedResolution 的值是真。無(wú)論是上述哪個(gè)情況發(fā)生了改變，googAdaptionChanges 計數器都會(huì )增加。
我們可以從這張圖表上看到這些變化：
這里的丟包是人為產(chǎn)生的。作為反應，Chrome 在 t=184 時(shí)第一次嘗試降低分辨率，這是綠線(xiàn)代表的 googFrameWidthSent 開(kāi)始偏離黑線(xiàn)代表的 googFrameWidthInput。接下來(lái)在 t=186 時(shí)，框架開(kāi)始下降，輸入框架速率（淺藍色線(xiàn)條所示）大約是 30fps，與發(fā)出的框架速率（藍色線(xiàn)條所示）產(chǎn)生區別，后者幾乎是 0.
另外，Chrome 在 ssrc 報告中公開(kāi)了大量關(guān)于音頻和視頻堆棧的表現的數據。我們會(huì )在未來(lái)的博文中進(jìn)行討論。
VideoBWE 報告
最后，但并不是不重要，我們來(lái)分析一下 VideoBWE 報告。就像它名字所表達的，它包括有關(guān)帶寬估計的信息。但是還有一些其他的有用信息包含在這個(gè)報告里：
- googAvailableReceiveBandwidth — 對于接收視頻數據可用的帶寬。
- googAvailableSendBandwidth — 對于發(fā)送視頻數據可用的帶寬。
- googTargetEncBitrate — 視頻編碼器的目標比特率。這項指標會(huì )嘗試填滿(mǎn)可用的帶寬。
- googActualEncBitrate — 視頻編碼器輸出的比特率。通常這與目標比特率是匹配的。
- googTansmitBitrate — 這個(gè)比特率是實(shí)際傳輸的比特率。如果此數值與實(shí)際編碼比特率有較大的差別，那么可能是因為前向錯誤糾正造成的。
- googRetransmitBitrate — 如果RTX被使用的話(huà)，這項允許測量重傳的比特率。此數據通常代表丟包率。
- googBucketDelay — 是Google為了處理大框架速率的策略表示。通常是很小的數值。
正如你看到的，這個(gè)報告會(huì )給你視頻質(zhì)量最重要的信息—可用帶寬。查看發(fā)送和接收的可用帶寬通常都是在深入分析 ssrc 報告之前做的最重要的事。因為有時(shí)你可能會(huì )發(fā)現這樣的情況，這解釋了用戶(hù)所抱怨的 “質(zhì)量差”：
在這種情況下，“ 在所有時(shí)間里，帶寬估計都在下降 ” 是對質(zhì)量問(wèn)題的一個(gè)比較好的解釋。
原文鏈接：http://testrtc.com/webrtc-internals-parameters/
原文鏈接：http://testrtc.com/webrtc-internals-parameters/
