微信后臺如何應對像跨年，特殊時刻(比如2022年2月22日22時22分22秒)這樣的朋友圈突發流量，可做如下策略(只是比如)：

• 優先讓發一張圖片的成功。
• 九宮格只成功一部分，剩余的強有損壓縮。
• 朋友多的優先成功。(也可以反過來)
• 設置三天可見的優先成功。(也可以反過來)
• 年輕女性優先成功。(這個沒毛病)
• 歷史點贊多的優先成功。(也可以反過來)
• 頭像穿西裝打領帶的經理統統失敗。
• …

在不影響P99用戶體驗的前提下，提供有損服務，保證核心可用性，這就是柔性。
但數據傳輸的思維定勢并不認可柔性。

受TCP的影響，普遍認可的傳輸即確保傳輸，而TCP也確實能保證最低可用性，這便讓它更加被認為“絕對正確”，即便UDP-based協議也常?？吹絋CP的影子，重傳，保序，諸如此類。

TCP的普遍性使它幾乎被認為是唯一的標準，故談到傳輸優化，大多數人都會關聯TCP優化(together with QUIC優化)那一套，實際的傳輸場景(比如，傳輸的內容)卻很少被關注。

本文的話題有關音視頻傳輸優化，優化目標：

• 低卡頓率，超流暢。
• 秒互動，超低延時。
• 超高清。

優化要點不外乎：

• 音視頻傳輸優化不能基于TCP/QUIC。
• 音視頻傳輸優化需要對高清做柔性。
• 高清要強依賴編碼而非傳輸碼率。

本文不含技術細節，更不會涉及API調用，但理解這些基本思路，勝過10倍的技術細節。

稍詳細點說。

如TCP，QUIC類通用傳輸協議不適合傳輸音視頻，更無助于其傳輸優化，極致體驗需在音視頻流中自行斟酌傳輸細節。

計算機科學有一鐵律強調分層解耦解決一切，而上述結論卻將分層邏輯進行雜糅，雖與鐵律相違背，但有理由。

分層鐵律外，計算機科學還有一個約束強調一切皆trade-off。有此約束，分層協議的代價就是層次之間細節互不溝通，只通過接口交流PDU，而極致優化必依賴細節。

極致優化訴諸差異，而非共性。通用不為性能，性能也不鳥通用。

通用的另一個代價是不易定制。諸如TCP類協議均集成在系統，系統并不易改，甚至無權限修改，若需修改手機端TCP，便無能為力。優化若收斂于應用本身，則無障礙。

企圖基于TCP，QUIC等通用協議做音視頻傳輸優化終究徒勞，結合業務細節做定制才是正道。

類似量體高定西裝之于產線均碼西裝，后者換一個人都穿不合身，它只屬個人，這便是它的昂貴。

值得期待的是，若音視頻傳輸統一標準，則此基礎上通用的極致優化便成可能，新的差異方可發芽，一個螺旋上升的韻腳支撐著這押韻的故事。

昨天(2月25日)的"火山引擎視頻云科技原力峰會"上，提到火山引擎，騰訊云，阿里云三家聯合發布了《超低延時直播協議信令標準》，依次標準，火山引擎宣稱延遲控制在1s以內，但就在前幾天的2月22日，騰訊云發布了《超低延時直播白皮書》，說是聯合信通院發布的業內首份，據此提到的技術，延時可控制在500ms以內。我不曉得這個白皮書和那個標準有什么關聯，我感覺這些更多的是在pr，標準是不可能標準的，基本還是各做各自的。所以我提到的通用性問題依然存在。事實上不管是火山引擎峰會還是騰訊云的白皮書，都是含糊其辭，沒人知道這個標準或者這個技術的框架到底是什么，所承諾的github或許也只是在很久以后才能兌現的承諾，或者也將永遠不能。對圈里人士三兩句話就能點透的始終還是沒人說，大家對標準化的憧憬或者就像凡卡在等他爺爺康斯坦丁瑪卡里奇的回信一樣。是故，所有人都各自去做吧，并不難。

音視頻傳輸，必在流暢度，清晰度，通用性之間做trade-off。事情非往復，但押韻，重畫之前的一幅圖：

為什么延時不參與？流式傳輸的時間因子永遠只是流暢度，延時屬不得已而主動為之，不能算數。

若非要圖示buffer，流暢度和清晰度兩個圓之間交集的面積即為buffer的大小，而buffer大小直接表征延時：

延時受擁塞排隊及重傳共同影響，接收端部署buffer可抵抗排隊或重傳帶來的延時抖動?？傊?#xff0c;buffer的作用是，在網絡由于排隊或重傳導致數據包無法持續到達的時間段，播放器仍有持續的數據。

類似水庫，深淺寬窄各處蜿蜒不同的河道要保證出水率恒定，需建一座水庫充作buffer。傳統音視頻傳輸場景下，buffer意義類似水庫：

實屬用主動的大buffer延時抵抗被動的延時抖動，就和在坑洼顛簸的路面上蓋厚土一樣。

傳統TCP協議丟包重傳帶來的抖動非常大，若發生RTO重傳，延時抖動將達400ms。相比而言，擁塞排隊帶來的抖動在100ms以內，還好。

但調轉視角，何必引入大buffer只為堅持速率，損失掉速率保持流暢于體驗更好，若不再重傳，延時大降低，所需buffer將大減少，若在小速率下只保障關鍵幀傳輸，效果亦然，此即為柔性策略，屬無級變速。

再和坑洼顛簸的路面上蓋厚土類比，柔性相當于不動路面而改造車輛，經理座駕加裝避震，工人只能在班車里忍著。

前面一個圖，將代表流暢度和清晰度的兩個圓交集面積看作buffer大小，該視角下，buffer越大，為了既流暢又清晰的延時代價就越大，這顯然是既要也要還要模式，但在柔性視角下，則是舍魚而取熊掌模式了，解釋就有了大不同：

不再將兩個圓的交集視為合作，而視為互斥侵蝕，代表流暢度的圓“吃掉”代表清晰度的圓的面積，就是損失清晰度而額外獲得的流暢度。這就是柔性，二者不可得兼，損失一個取另一個。這個一模一樣的圖示中，再沒了buffer的位置。在現實實現中為了實施柔性，需要一個極小的buffer。

柔性又稱“松弛吧”，“放松吧”，諸如此類，典型的例子就是旅行商問題退而求其次的解，也叫松弛解?，F實中任何事我們都要避開既要也要還要，如此的話，代價巨大，同樣在阿里聽到的話，我倒喜歡第二句，“你有什么，你要什么，你能放棄什么”，總之，一切都是交換，或者說生意。

小buffer只為感知網絡變化，為無級變速提供依據，由柔性替代重傳和gap，同時小buffer平滑微弱的擁塞。2～3個RTT的buffer足以感知網絡變化，另一方面，所謂微弱平滑擁塞的背后是對互聯網公平收斂的信任。

如果可以通過歷史預測擁塞，再好不過了，不過要當心，很多大V主播直播的時間(此時必然會有擁塞)并不是固定的，這種情況就需要實時預測了。不過無法預測只是信息不夠，如果是他女朋友，預測就容易多了。

寧愿相信公平收斂原則被普遍遵守，擁塞總是不下心而為之轉瞬即逝，受益者將是大家：

• 接近0的小buffer帶來極低延時。
• 幾RTT的小buffer感知網絡變化。
• 柔性策略保證平滑流暢。

這就閉環了，但它背后的信任很脆弱，任何激進行為都能破壞平衡：

• 激進發送導致排隊，排隊導致延時增加，增大接收端buffer進行平滑，端到端延時增加。

后果就是集體墮落，所以，不要透支信任。

所有流量復用帶寬，不光音視頻流不能激進，其它UDP，TCP流量也不能。雖然運營商有一定的懲戒措施，但還是要自覺。

再詳細點說。

信息交互之根本即消除不確定性，亦是信息論的核心。

人體器官可在很寬的分辨率范圍識別信息，若信息受體如此類介質，便無需精確復制比特。音視頻傳輸正在此列，這便存在一個關鍵，在必要時柔性降級清晰度，確保流暢。

TCP，QUIC類僅適用精確復制，如文件傳輸訴諸文件系統，便要求精確復制，對于音視頻流訴諸器官，柔性傳輸便有更多彈性。

精確拷貝每一個比特的信息最終目的仍然是消除不確定性，若它不是最后的終點，若只是經由一個只能精確處理的途徑，便需保持精確性。

遺憾的是，包括TCP，QUIC在內的通用協議，無法做柔性。

通用協議不理解傳輸細節，如TCP只是死磕確保傳輸每一個字節，即便允許不可靠，也不曉得丟棄哪一個包。若音視頻協議自行做傳輸控制，就是另一局面。

例如根據網絡實時質量決定如何柔性降級，犧牲清晰度保障流暢：

• 網絡好時，按下面的序列正常傳輸：1，2，3，4，5，6，7，8
• 網絡不好時，按照下面的序列傳輸：1，1，3，5，5，7，8，8

音視頻流知道1，5，8關鍵，而2，3，4，7非關鍵，非關鍵序號可犧牲，亦可將其占位作關鍵序號的冗余，增加關鍵序號傳輸成功率，進一步避免卡頓。即便是發送輕微擁塞，該策略亦可保證關鍵序號到達。柔性既可抵抗丟包，亦可抵抗擁塞。

損失了清晰度，靈活性就多了，可以關鍵幀冗余做填充，可亂序發送，比如合并或拆分關鍵幀，可以做任意FEC，諸如此類。

這種細節信息，無法通過通用接口傳遞，若通用協議自行丟包，則不光通用協議需善后，也極易制造上層協議疊加效應，比如重傳疊加，無論如何，效果總是卡頓。故柔性只能業務自己做。

柔性不意味著一味退讓適配，probe帶寬也是必須，但這是別的話題了。

柔性后，畫質有損，但卡頓率無損。若使用TCP，弱網環境，丟包明顯，為確保傳輸，仍堅持重傳每一個包，滑動窗口自然卡死。

這就手機接入WI-FI，有時視頻非常流暢，網頁卻死活打不開的原因。視頻做了柔性，網頁是HTTP，沒這能力。HTTP的最大柔性只在TCP連接之間，網頁元素獨立使用TCP連接，若網絡不給力，則放棄不重要的，通常圖片位置會打叉。

WebRTC是個好東西，但BBR不是?；赗TP/RTCP定制的私有協議都好，但想要優化到極致，這些依然是通用的東西，忘記它們的具體形式，只將思想融入業務邏輯本身，事竟成。

說完了技術，說人。

專有協議優化容易出績效，卻難pr，針對專有協議優化的推廣相當于暴露細節，降低進場門檻，屬自廢武功。

相反，通用協議優化，比如TCP優化在業內很容易pr，卻難出績效，其復制推廣的簡易程度抹平了差異。

大概就是此意，公開渠道的技術秀以及對應的招聘更多是廣而告之，加入團隊也不一定能取真經，若不跟隨從零到一的過程，就只能維護一個成熟系統。教會徒弟便餓死師父，話不好聽，但是事實，秀場就是名利場，有人圖名圖晉升，有人賣貨拿提成，怎么可能讓人予取予求。

這實屬另一個困局。

當音視頻傳輸優化很難進行下去時，不妨換個思路，與其費勁糾結于低卡頓，低延時，高清晰度如何實現，不如看看能放棄些什么。人們絞盡腦汁設計的那些個復雜無比且脆弱并且不一定有效的算法真的必要嗎？大部分訴諸人體器官的信息并不需要精確傳輸，還不如直接有損傳輸，就像在大霧天出行一樣，要做的是走慢一點，而不是試圖去驅散迷霧，弱網就算一場霧，圖像模糊點總比卡死強。周二和周五分別了解到騰訊云和火山引擎的超低延時直播技術，但也只是了解，我相信這兩個是一回事又不是一回事，我也看不到技術細節，無論怎樣，作為一個屬于這個細分領域又不屬于這個細分領域的我而言，總要寫點自己的想法，就是本文。

浙江溫州皮鞋濕，下雨進水不會胖。

總結

以上是生活随笔為你收集整理的超低延时超低卡顿率视频传输的秘密的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。