日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁(yè) > 云知道 > >

服務(wù)質(zhì)量分析模型有什么 服務(wù)質(zhì)量的五個(gè)標(biāo)準(zhǔn)( 七 )

云知道



總結(jié)一下，對(duì)于服務(wù)質(zhì)量保障，首先提高網(wǎng)絡(luò)質(zhì)量，NACK和FEC解決丟包問題，JitterBuffer解決視頻的亂序與抖動(dòng)，NetEQ解決音頻的亂序與抖動(dòng)；帶寬評(píng)估通過Goog-REMB和Goog-TCC，還有丟包的帶寬評(píng)估；為了保障實(shí)時(shí)性，需要選擇更優(yōu)質(zhì)的線路，比如客戶端與服務(wù)端通信的時(shí)候選擇更好的路線節(jié)點(diǎn)，保證云端網(wǎng)絡(luò)帶寬等等；從業(yè)務(wù)上，減少數(shù)據(jù)量可以用AV1、SVC、Simulcast、動(dòng)態(tài)碼率，減少業(yè)務(wù)；在防擁塞上，通過Pacer進(jìn)行流控，只要能控制在500ms之內(nèi)，適當(dāng)增加時(shí)延也是可以接收的 。
以上就是本次分享的全部?jī)?nèi)容，謝謝！
Q&A (部分)
1. 路徑的選擇是WebRTC內(nèi)部自動(dòng)選擇的嗎？
是自動(dòng)選擇的 。WebRTC會(huì)自動(dòng)判斷通信的雙方是否在同一個(gè)局域網(wǎng)內(nèi)，如果是就直接在局域網(wǎng)內(nèi)建立連接；如果不是，會(huì)通過STUN協(xié)議獲取各自的外網(wǎng)地址，然后進(jìn)行NAT穿越；如果還不成功的話，才會(huì)選擇TURN服務(wù)進(jìn)行數(shù)據(jù)中轉(zhuǎn) 。
2. WebRTC網(wǎng)絡(luò)傳輸質(zhì)量衡量指標(biāo)有什么？
衡量任何一個(gè)實(shí)時(shí)傳輸系統(tǒng)時(shí)，首要看它的時(shí)延是否達(dá)到500ms以內(nèi) 。其實(shí)500ms對(duì)于實(shí)時(shí)通信而言，也是比較苛刻的標(biāo)準(zhǔn)了，因?yàn)榫W(wǎng)絡(luò)的變化是非常大的，所以要實(shí)現(xiàn)這個(gè)指標(biāo)其實(shí)難度也是蠻大的 。其次是丟包率，這是非常關(guān)鍵的指標(biāo)，剛才說到2%的丟包率代表網(wǎng)絡(luò)比較好；小于10%，對(duì)于WebRTC來說，代表目前的帶寬是準(zhǔn)確的；超過10%則代表發(fā)生了擁塞 。有些廠商說它的產(chǎn)品可以抗xx%的丟包，這樣的前提是不認(rèn)為丟包是一個(gè)指標(biāo)，但在真網(wǎng)絡(luò)中，當(dāng)路由的緩沖被撐爆后，必然會(huì)出現(xiàn)大量丟包，如果不把丟包當(dāng)作指標(biāo)的話，就缺少了一種判斷網(wǎng)絡(luò)擁塞發(fā)生的條件，這顯然是不合理的 。
3. 視頻JitterBuffer怎么具體控制平滑的？
其實(shí)JitterBuffer平滑處理的難度并不像我們想像的那樣復(fù)雜，之所以大家認(rèn)為它復(fù)雜，可能是因?yàn)橐恍╊~外的因素，如還要處理音視頻同步等問題 。對(duì)于平滑處理，我們完全可以自己通過一個(gè)Buffer來實(shí)現(xiàn) 。Buffer可以是動(dòng)態(tài)大小或固定大小 。為了簡(jiǎn)化，我們假設(shè)它是固定大小，比如定義一個(gè)可以存放 100 個(gè)元素的數(shù)組，在數(shù)組的一頭每隔 10 毫秒取一個(gè)包，這就是一個(gè)最簡(jiǎn)單的平滑處理 。當(dāng)然更好的方式是可以根據(jù)網(wǎng)絡(luò)的變化讓這個(gè)平滑數(shù)組的大小也動(dòng)態(tài)變化，這樣就更高級(jí)一些 。當(dāng)然，如果Buffer是動(dòng)態(tài)變化的，那在計(jì)算平滑數(shù)組的動(dòng)態(tài)大小時(shí)，會(huì)稍難一些 。
4. WebRTC要和SIP客戶端通訊有什么好的方案？
一般與SIP通信最好借助流媒體服務(wù)器比如Janus，它既支持SIP協(xié)議也能支持WebRTC客戶端 。這樣SIP終端就可以將數(shù)據(jù)傳輸流媒體服務(wù)器，然后再轉(zhuǎn)發(fā)給WebRTC終端了，同理WebRTC終端也可以通過流媒體服務(wù)器與SIP終端通信了 。
5. FEC和NACK默認(rèn)是不是都要開啟？
是的 。對(duì)于WebRTC來說，F(xiàn)EC和NACK都是開啟的，也可以控制它們的開關(guān) 。
6. 能說下為什么TCC比REMB準(zhǔn)確嗎？
TCC和REMB主要有兩個(gè)區(qū)別 。第一是計(jì)算的端不同，REMB是在接收端計(jì)算的，接收端計(jì)算后再將結(jié)果返回給發(fā)送端進(jìn)行控制，而在回傳結(jié)果時(shí)，可能網(wǎng)絡(luò)又發(fā)生了新的變化，這就造成了REMB的及時(shí)性不夠；TCC是將所有數(shù)據(jù)都交給發(fā)送端做計(jì)算和控制，因此及時(shí)性和準(zhǔn)確度會(huì)更高 。第二是濾波器不同，REMB是卡爾曼濾波器（Kalman），TCC是最小二乘法濾波器（Trend line） 。最小二乘法濾波器在網(wǎng)絡(luò)延時(shí)評(píng)估這方面比卡爾曼濾波器效果更好一些 。
7. 在內(nèi)網(wǎng)環(huán)境下p2p想讓延時(shí)盡可能小，可以做哪些工作？實(shí)驗(yàn)室環(huán)境最小延時(shí)可以達(dá)到100ms以下嗎？
如果在同一個(gè)局域網(wǎng)內(nèi)，實(shí)際只有幾十毫秒的延遲 。有同學(xué)可能會(huì)疑惑，有的產(chǎn)品在同一局域網(wǎng)內(nèi)延遲非常小，為什么用WebRTC反而延遲增大了？這就是因?yàn)閃ebRTC為保障網(wǎng)絡(luò)質(zhì)量，在內(nèi)部通過多種機(jī)制，各種緩沖，來做到的 。所以它必然會(huì)產(chǎn)生一定的延遲，也就是拿延遲換質(zhì)量 。而在局域網(wǎng)內(nèi)，網(wǎng)絡(luò)基本沒有延時(shí)，不丟包、不抖動(dòng)、不亂序 。這時(shí)什么策略都不采用，網(wǎng)絡(luò)的傳輸才是最快的，因此在內(nèi)網(wǎng)通信時(shí)，WebRTC的實(shí)時(shí)性一定不如什么策略都不加的產(chǎn)品好 。

推薦閱讀