偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

RTC 弱網(wǎng)對抗之冗余策略

原創(chuàng) 精選
開發(fā)
網(wǎng)絡傳輸鏈路上存在著許多不穩(wěn)定的情況,造成所發(fā)出去的數(shù)據(jù)包出現(xiàn)丟包、延時或者抖動。不穩(wěn)定的原因有很多,兩個通訊雙方在物理空間上存在距離,傳輸過程經(jīng)過很多設備的處理,中途存在線路硬件故障、軟件驅動限制、或者鏈路數(shù)據(jù)擁塞等情況,都會導致發(fā)送出去的數(shù)據(jù)包在接收端沒有辦法收到或者延遲收到。

?1. 背景

當下社會,實時音視頻通話已經(jīng)成為人們生活、工作中重要的組成部分,如商務會談、親朋聊天等。而在通話過程中,總會存在著這樣那樣的意外情況:可能你坐在飛馳的高鐵上——信號時好時壞;又或者在會議途中離開辦公室——網(wǎng)絡從 wifi 切換到 4G……實現(xiàn)高質(zhì)量的實時音視頻通話需要搭建一座無視距離連接人們的“橋梁”,而這座“橋梁”需要優(yōu)秀的“基建技術”來保障網(wǎng)絡傳輸?shù)姆€(wěn)定性和可靠性。

網(wǎng)絡傳輸鏈路上存在著許多不穩(wěn)定的情況,造成所發(fā)出去的數(shù)據(jù)包出現(xiàn)丟包、延時或者抖動。不穩(wěn)定的原因有很多,兩個通訊雙方在物理空間上存在距離,傳輸過程經(jīng)過很多設備的處理,中途存在線路硬件故障、軟件驅動限制、或者鏈路數(shù)據(jù)擁塞等情況,都會導致發(fā)送出去的數(shù)據(jù)包在接收端沒有辦法收到或者延遲收到。

我們可以通過一些簡單基礎的工具檢測網(wǎng)絡是否處于波動情況,比如 ping 命令或者 Iperf 工具可以幫助統(tǒng)計丟包、延時以及單向抖動。我們用 ping 命令向一個遠端的主機發(fā)送 ICMP 消息,遠端主機會對你進行應答,這個過程中如果你發(fā)送出去的 ICMP 消息丟了,或者遠端服務器應答的消息丟了,在命令行界面上,對應的 icmp_seq 就會顯示超時未收到,這種情況就直觀地體現(xiàn)了丟包。

ping vs iPerf   

圖片

帶寬分配和冗余策略是弱網(wǎng)對抗核心模塊,隨著算法的演進迭代,我們能夠保證線上大部分場景的優(yōu)質(zhì)音視頻體驗。對于一些小概率或特殊場景,如突發(fā)網(wǎng)損、擁塞恢復、PPT 翻頁等,我們還引入了多種冗余策略,來兼顧流暢、恢復效率和低延時的需求。

2. 常用包恢復技術

通常,一個數(shù)據(jù)包在網(wǎng)絡傳輸鏈路中丟失了,主要有兩種方式將包進行恢復:一種是發(fā)送端利用接收端通知或者超時的機制,重新將這個包發(fā)送過來;另一種則是基于其他收到的冗余包,在接收端將該包恢復出來。

第一種是我們熟知的自動重傳請求 ARQ 技術。與 TCP 協(xié)議中的 ACK 應答機制不同,實時音視頻場景使用的是 NACK 否定應答機制,通過接收端檢查包序號的連續(xù)性,主動將丟失的包信息通知給發(fā)送端進行重新發(fā)送。這種方式的優(yōu)點是在低延時場景下的恢復效率高,帶寬利用率好,但在高延時場景下的效果比較差,存在重傳風暴等情況。

圖片

第二種是 Forward Error Correction (FEC) 即前向糾錯編碼,一種通過冗余發(fā)送對抗網(wǎng)絡丟包的技術。它主要的技術原理就是分組編碼,組內(nèi)進行冗余恢復。假設每個分組由 k 個媒體包和 r 個冗余包組成,一個分組中 k+r 個數(shù)據(jù)包中任意 k 個包可以用來重建 k 個原始媒體包。這種方式的優(yōu)勢是根據(jù)先驗知識進行冗余決策,不受延時影響。

圖片

3. 冗余策略

在上述基本的包恢復技術下,為了使各種場景的整體抗弱網(wǎng)能力最大化,需要針對帶寬分配、抗丟包技術的組合配置等進行一系列的優(yōu)化,從而達到抗丟包能力、端到端延時、卡頓率、冗余率的平衡,達到“消耗最小的代價,實現(xiàn)最優(yōu)的體驗”。

下面具體介紹我們在這方面做的幾項優(yōu)化。

3.1 自適應調(diào)整策略

冗余策略大致可以分為兩類,一類是前向冗余,一類是被動冗余。按照前文的描述,我們知道前向冗余的優(yōu)點是不需要交互,在高延時環(huán)境下更加適用,缺點是帶寬占用過多。被動冗余的優(yōu)點是按需發(fā)送,占用帶寬較少,缺點是高延時場景效果會急劇下滑。

圖片

我們的冗余策略則是在尋找一個平衡點,通過被動冗余和前向冗余策略比例的調(diào)整,在保證丟包恢復率(比如 99.5%)的前提下,盡量的減小冗余占比,盡量的減小抗丟包恢復時間。所以,我們可以將當前問題抽象成如下一個數(shù)學場景:

  • 假設 m 個媒體包,在重傳 k 次后,收到 i 個包的概率記為: P(m, i, k)
  • 假設 n 個冗余包,接收端收到 j 個包的概率記為: P(n, j, 0)
  • 根據(jù)當前的 FEC 算法,這個 m + n 的分組在重傳 k 的情況下,接收端只需要接收到任意 m 個包,就能夠恢復全部的媒體包, 這個概率為:圖片
  • Nack FEC 算法就是基于恢復概率大于 99% 的情況來計算當前最少需要配置的 FEC 冗余度 n

基于上面的模型,在 m (平均幀分組大小), k (允許時間范圍內(nèi)的重傳次數(shù)), i,j 是可以自變量。我們只要將 n 從 0 開始代入,上面求和的結果大于 99%,就可以將這個 n 作為 FEC 的冗余率。

圖片

通過上面的算法,我們定義一個抗丟包恢復時間 resend_delay,就可以獲得被動重傳次數(shù) k。通過參數(shù) k,可以推導出為了達到恢復率 99%,還需要的 FEC 比例。上述就是理論上的最優(yōu)冗余率計算邏輯。通過該算法邏輯,我們可以獲得一個自適應的冗余調(diào)整策略,從而獲得最優(yōu)的冗余比例、最合適的延時損耗、以及最佳的丟包恢復率。

3.2 可靠重傳策略

在接收端媒體緩存中,對于 seq 最新和最老范圍內(nèi)沒有接收到的數(shù)據(jù),接收端會發(fā)送 Nack 請求,然后發(fā)送端接收 Nack 請求,將相應的包傳送過來。

正常工作狀態(tài)中,Pacer 優(yōu)先發(fā)送 RTX 重傳數(shù)據(jù),然后再發(fā)送媒體數(shù)據(jù),這樣接收端這邊較老的丟失數(shù)據(jù)包,總能夠優(yōu)先得到恢復。

但是在一些場景下,比如大丟包(70% 或以上的丟包率),或者突然限寬(4M ---> 300K)時,會出現(xiàn)大量的數(shù)據(jù)包被丟棄掉。這個數(shù)據(jù)包既包括原始包,也包括 Nack 重傳包,這樣會導致如下圖的一些問題。

圖片

如圖,如果丟包恢復效果比較差,比如上面 n + 3 的幀已經(jīng)開始發(fā)送了,但是 n 幀還沒有被接收端全部接收到,這時,接收端生成的需要重傳的包列表 nack_list 就會很長。對于發(fā)送端來說,由于媒體數(shù)據(jù)還在繼續(xù)發(fā)送,理論上接收端請求的 nack 會越來愈多,這樣就會形成 nack 風暴。

Nack 風暴不但會導致大量的重傳流量擠占媒體帶寬,導致帶寬分配模塊分配給媒體的碼率降低,也會導致 Pacer 擁堵,從而帶來更大的端到端延時。同時,由于不是選擇性的重傳某個幀的媒體包,導致接收端需要解碼的幀能夠被完整丟包恢復的概率比較低。

為了避免上述情況,我們引入了可靠重傳模塊:在檢測到上述情況后,及時暫停媒體發(fā)送,同時全力保障已經(jīng)發(fā)送的幀數(shù)據(jù)能夠完全恢復。

圖片

我們通過 TccAck 和 Nack 請求的信息來確定某一個包處于什么狀態(tài),然后統(tǒng)計當前已經(jīng)發(fā)送的數(shù)據(jù)中沒有被完整 ACK 的幀數(shù)量。如果這個數(shù)量過大,則會暫停媒體發(fā)送(同時暫停編碼器)。暫停媒體發(fā)送后,按照幀從老到新的順序,把 pacer 預算分配給最高優(yōu)先級的幀,主動發(fā)送這些幀里面沒有被 ACK 的數(shù)據(jù)。

通過上面的方式,我們有效解決了目標場景長時間卡死或者卡頓過多的問題。

圖片

3.3 擁塞恢復場景下快速抑制 FEC 碼率

我們 FEC 使用 loss 計算 FEC 冗余率,為了防止抖動帶來的劇烈變化,這個 loss 值被平滑過。但是對于一些場景,比如帶寬突然掉落到較低的場景下,當擁塞狀態(tài)解除后,網(wǎng)絡丟包就會消失。這個時候,我們需要快速的抑制 FEC 碼率,讓出帶寬給到媒體,這樣可以盡快地提升畫面質(zhì)量。

圖片

使用上面的狀態(tài)機,在接收到擁塞解除信號(擁塞狀態(tài)解除,并且瞬時 tcc loss 變?yōu)?)后,在平滑 loss 沒有變?yōu)?0 的情況下,使用瞬時 loss,可以快速取消掉 FEC 冗余。

3.4 空余帶寬利用優(yōu)化

在共享場景下,冗余策略會遇到進一步的挑戰(zhàn)。比如在 PPT 不翻頁的時候,空余帶寬需要讓給視頻。但是在翻頁的時候共享流又會迅速占據(jù)帶寬。這樣就會導致視頻碼率在翻頁時出現(xiàn)較大的波動。如果整體可用帶寬較低,就能夠看到視頻質(zhì)量的明顯變化——卡頓率、延時上升。

圖片

如圖,在 PPT 翻頁場景,video 會使用 screen 空余未被使用的帶寬。靜止畫面下,video 使用了大部分原本共享的預算。一旦 PPT 翻頁,共享的碼率瞬時提高,而 video 沒有及時把編碼碼率降下來,就會造成 pacer 模塊的擁堵,導致丟幀從而攝像頭流卡頓。

針對該場景,我們對帶寬分配策略進行了優(yōu)化:

  • 緩升快降

帶寬分配過程中對每個媒體流使用的上一層傳過來的空余碼率進行緩升快降操作,防止高優(yōu)先級碼流過快讓出空余帶寬,導致低優(yōu)先級碼流的分配碼率大幅波動。

  • 關鍵幀檢測

當某個媒體流開始收到關鍵幀的時候,降低該流讓出空余帶寬的量,使得整體輸出碼率的波動性降低。

  • 波峰檢測

使用 300ms 統(tǒng)計窗口判斷波峰,出現(xiàn)較大的波峰數(shù)據(jù)時,降低該流讓出帶寬的量,減小整體輸出碼率的波動性。

4. 優(yōu)化效果

在上述的冗余策略優(yōu)化下,飛書會議整體冗余率大幅度降低(部分上漲是由于原有算法冗余不足,出現(xiàn)大量卡頓,算法優(yōu)化后,整體冗余率調(diào)整為最佳值)。同時,在保證了音視頻整體效果的前提下,整體端到端延時也進一步下降,提升了飛書會議的整體音視頻體驗。

  • 算法優(yōu)化大幅度降低了低延時場景的冗余率,高延時場景的冗余率也趨于理論上的合理值。
  • 解決了原有算法在高丟包場景下的問題,對于高延時,高丟包率的弱網(wǎng)場景下的體驗大幅提升。
  • 解決了場景,網(wǎng)絡狀態(tài)變化過程中的收斂速度,提升了變化過程中的音視頻體驗。?

圖片

圖片

在與同類產(chǎn)品的比較中,我們優(yōu)化算法的冗余度明顯低于同類產(chǎn)品,在流暢度對齊的情況下,消耗更小的帶寬。特別是在高丟包,高延時場景下,我們的冗余率只相當于同類產(chǎn)品的 40%。

圖片

圖片

5. 未來展望

通過這些經(jīng)優(yōu)化的冗余策略,當前飛書會議在弱網(wǎng)場景下的卡頓率、端到端延時、冗余率等指標得到了大幅度的優(yōu)化。在此基礎上,我們未來會在極端弱網(wǎng)支持,帶內(nèi)冗余聯(lián)動策略,智能場景識別等方面,進一步加大投入,增加飛書會議在各種弱網(wǎng)場景下的客戶端體驗。

5.1 極端場景下的抗弱網(wǎng)能力支持

增加針對極高丟包、極高延時、丟包+延時,低帶寬+高丟包等場景的支持,配合冗余策略以及帶寬分配策略,達到極端弱網(wǎng)場景下面的最佳音視頻體驗。

圖片

5.2 帶內(nèi)冗余聯(lián)動下的抗弱網(wǎng)策略

冗余策略,除了前面提到的非音視頻編碼內(nèi)的帶外冗余(Nack,F(xiàn)EC 等),也包含音視頻編碼內(nèi)的帶內(nèi)冗余。相比于帶外冗余,帶內(nèi)冗余往往結合編碼自身的特點,使用更少的冗余碼率代價,達到更高的抗弱網(wǎng)效果。

我們的冗余策略也會進一步結合、更大化利用帶內(nèi)冗余算法,進一步提高抗弱網(wǎng)能力,降低整體延時和帶寬占用。

圖片

5.3 場景識別下的抗弱網(wǎng)策略優(yōu)化

后續(xù),我們還將對當前的網(wǎng)絡環(huán)境進行識別,獲取到當前的網(wǎng)絡場景,從而可以進一步對冗余策略以及編碼策略進行預判式的策略下發(fā)。

圖片

比如,我們識別到當前場景為高鐵場景,就可以在冗余策略生成的時候偏向于抗連續(xù)丟包的策略,也可以預先增加默認前向冗余來增加突發(fā)弱網(wǎng)的抗性。根據(jù)識別場景的特性,可以在實際發(fā)生弱網(wǎng)之前以及發(fā)生弱網(wǎng)之后,做出策略上的區(qū)別。

責任編輯:未麗燕 來源: 字節(jié)跳動技術團隊
相關推薦

2022-11-24 09:35:52

2018-01-05 16:14:25

VM存儲策略

2024-11-05 09:56:30

2020-12-28 09:42:25

弱密碼密碼加密

2016-07-28 10:34:12

云計算

2023-02-17 08:03:11

2017-11-14 14:24:46

移動端DNS無線網(wǎng)絡

2019-09-16 09:46:55

對抗反分析檢測逃逸惡意軟件

2019-09-16 09:46:55

2014-05-19 09:25:33

2015-06-05 15:29:16

網(wǎng)絡優(yōu)化

2019-09-11 15:49:02

入侵檢測反分析逃逸技術

2023-09-08 15:20:30

2010-09-14 14:52:37

2020-06-22 14:18:02

運維架構技術

2011-07-20 16:07:55

組策略

2012-01-11 16:52:05

Strix礦井
點贊
收藏

51CTO技術棧公眾號