快手多媒體傳輸演算法優化實踐

目前多媒體內容佔據了主要的互聯網流量，快手作為一個數億級用戶的短視頻與直播平台，業務多樣，用戶分布廣，網路情況複雜，給多媒體內容分髮帶來巨大挑戰。本篇文章介紹快手自研的私有傳輸協議 KTP (Kuaishou Transmission Protocol)，涉及快手在多媒體內容傳輸上遇到的挑戰與思考、技術選型、以及 KTP 在短視頻上傳、直播、連麥等典型業務中的優化策略。

以下內容根據快手科技演算法科學家周超博士在 2018 北京 ArchSummit 全球架構師峰會上的演講內容整理，有刪減。

1

一、 為什麼要走自研之路——KTP 背後的思考

1. 快手在多媒體傳輸上的業務需求

快手是一個 UGC 平台，從內容生產到消費形成一個完整的閉環。內容要在整個閉環系統中流動起來，必須經過網路的傳輸與分發。網路架起了生產和消費之間的一座橋樑，這座橋樑修得好不好，牢不牢靠，對用戶的體驗至關重要。

快手的業務複雜多樣，對網路傳輸需求的差異性也非常大。例如，對於短視頻上傳，最關心的是作品發布的成功率和發布速度。成功率直接影響著用戶發布作品的積極性及留存率，而發布速度與發布耗時直接關聯，進而影響發布的取消率。對於直播，作為內容的源頭，推流質量是需要優先考慮的。推流的卡頓、清晰度、延遲直接影響著億萬觀眾的體驗。此外，直播的玩法多樣，對推流質量的需求也各不相同。簡單歸納一下，快手的直播大致可以分為以下三類：i) 互動直播； ii) 遊戲直播； iii) 實時連麥。不同的直播玩法，對直播的延遲、流暢性、傳輸可靠性、視頻的清晰度等要求也各不一樣。

因此，為了滿足快手多樣化的業務需求，一個可行的傳輸協議必須包含兩大模塊：一個是網路傳輸直接相關的網路控制模塊，包含網路擁塞控制、可靠性控制等；一個是對業務需求感知的信源信道聯合優化模塊，包含動態流控、延遲控制、數據優先順序控制等。

2. 現有協議與快手多媒體傳輸訴求的差距

已有的傳輸協議可以分為兩大類，一類基於 TCP，一類基於 UDP。

基於 TCP 類的傳輸協議，一般滿足面向連接且完全可靠的業務需求，例如用於文件傳輸的 HTTP-POST，用於直播推流的 RTMP/TCP 等。這類協議的優點是穩定性強，但雖然 TCP 底層的擁塞控制演算法經過多年的實踐驗證，但依然存在一些問題：i) 帶寬利用率不夠高。研究表明，對於 Live 或 VoD 類應用，為了保證視頻的流暢性，一般要求帶寬是視頻碼率的兩倍；ii) 延遲大。TCP 是面向連接的可靠傳輸協議，通過重傳來對抗網路的丟包與抖動，延遲較大，無法用於實時音視頻通信的場景 ; iii) 抗弱網能力差。這主要包含兩方面，一是在一些高延遲的場景下，重傳效率低下；另一方面則是底層擁塞控制演算法的效率問題。從早期的 TCP Reno 到目前操作系統里的 Cubic 和 Compound，雖然性能上有很大的改進，但在一些弱網下，性能依然非常差。例如丟包率到 20%，這類演算法基本失效 ; iv) 此外，TCP 集成在系統內核里，給進一步的優化也帶來很大的阻礙。結合快手的業務需求，HTTP/POST 可以滿足短視頻上傳的業務需求，但實際我們遇到的問題是作品發布成功率不夠高（TCP 抗弱網能力不夠強），發布耗時長（帶寬利用率不夠高）。嘗試過一些手段，例如分片傳輸、並行傳輸等，但由於無法修改底層擁塞控制演算法，效果提升非常有限。對於直播場景，RTMP/TCP 是業界使用最多的協議，也是快手早期的方案。但在實際部署中，我們遇到兩個問題：一是 TCP 的擁塞控制演算法不夠高效且集成在內核中，一些優化手段無法落地；二是業務感知不靈活，缺乏高效的信源信道聯合優化模塊，無法滿足我們多種直播玩法的不同需求。

基於 UDP 類的傳輸協議，一般滿足面向無連接、低延遲、且不要求完全可靠的業務需求，例如實時音視頻通信。最有代表性的是 Google 推出的 WebRTC，以及在 RFC 中與之並列的思科的 NADA 和愛立信的 SCREAM，這類 RTC 協議 / 演算法主要是為低延遲的實時音視頻業務設計的，目前使用也非常廣泛。但是，一方面與快手已有業務框架不匹配，不適合快手的短視頻和直播業務；另一方面這類協議的碼率控制演算法都比較簡單，沒有充分考慮網路的多樣性；此外，這類協議的核心是提出一套 RTC 架構和演算法雛形，沒有充分考慮多媒體（音視頻）自身的一些特殊特性。例如幀間依賴關係、音視頻同步等。在媒體傳輸的清晰度、時延、流暢性方面，沒有找一個很好的平衡點。最後，這些協議也沒有考慮多流競爭的場景，例如直播連麥，此時存在直播流與 RTC 媒體流競爭的情況。

最後，值得一提的是 Google 的 QUIC 協議。該協議是基於 UDP 設計，卻達到了 TCP 的效果，具有低延遲與高效擁塞控制等特性。其低延遲主要是在於減少了 TCP 三次握手及 TLS 握手時間，而不是低延遲的媒體傳輸。在傳輸層面，依然保持著 TCP 的特性，即可靠傳輸，適合文件傳輸與直播場景，並不適合 RTC 類應用。高效的擁塞控制則來自於底層的擁塞控制演算法 BBR，該演算法與 Cubic 和 Compound 等演算法相比，具有更高的抗丟包能力和帶寬利用率。除了無法直接用於快手的 RTC 類應用外，另一個問題在於 QUIC 的提出是為了替換 TCP，而並非專門為媒體傳輸設計，所以除了用底層的 BBR 進行網路擁塞控制外，缺乏對業務感知的流控策略。而在直播場景下，流控策略的性能直接決定了業務的體驗。

3. KTP 的設計目標

目前基本沒有任何協議 / 演算法能直接滿足快手多樣化的業務需求，自研是唯一的選擇，也就有了 KTP 的誕生。從快手自身的需求出發，KTP 必須基於 UDP，因為只有基於 UDP，才能極大的提高靈活性與擴展性，無論從性能優化還是業務需求角度，都能提供無限的想像空間。KTP 的設計原則為：突破地域、網路、業務的限制，以流暢度、清晰度、可靠性、和延遲作為評價指標，感知業務需求，動態調整各個評價指標的優先順序及權重。總體來說，KTP 具有以下特性：

基於 UDP，高效的傳輸演算法實現極致的用戶體驗。為了提升用戶體驗，必須在弱網下的性能有足夠的可控性，也即必須做弱網的優化，弱網優化只能基於 UDP。在 UDP 之上，我們能很快的復現並測試已知的一些高效傳輸演算法，也能快速落地並測試自研演算法

架構統一，業務感知的信源信道聯合優化。統一的架構，一致的介面，滿足快手多樣化的業務需求，降低開發和維護成本的同時，提高擴展性，滿足快速發展的新業務。通過業務感知的信源信道聯合優化，將底層網路優化與信源優化高效聯合起來，因此，信源信道聯合優化也是 KTP 的核心之一。

可控性強，背靠強大的 AB 系統與大數據分析系統。KTP 中的所有模塊和功能都做到了可插拔，能非常容易的新增 / 替換 / 打開 / 關閉某個功能及演算法模塊，同時背靠強大的 AB 系統和大數據分析系統，任何小的改動，都能在用戶那裡得到最真實的反饋，為後續的優化和改善提供極大的便利。

最後，考慮到兼容性問題，目前 KTP 主要用於快手業務的上行優化，因為 CDN 暫時不支持 KTP 協議。因此，無論是短視頻上傳、直播推流，還是 RTC 類應用，KTP 都只是將用戶的上行與我們的自建機房連接起來，CDN 則負責從機房 / 源站回源數據，進而分發給最終的消費者，如下圖所示。

2

二、 KTP 的架構與現狀

這是 KTP 的架構示意圖，列舉了一些大的模塊，下面分別簡單介紹：

1、網路估計模塊。部署在 KTP 服務端，在該模塊，KTP 通過接收數據包的特性估計網路的當前狀態，包括延遲估計、帶寬估計、丟包估計等。這些網路狀態的估計主要是基於 KTP 包頭攜帶的自定義欄位實現的。通過不斷的摸索與業務需求，同時考慮 KTP 包頭的開銷，KTP 包頭攜帶了一些 TCP 拿不到的信息，從而對網路帶寬、延遲、丟包的估計更加準確與靈活。

2、網路控制模塊。部署在 KTP 發送端的底層，負責直接與網路 IO 交互。在該模塊，KTP 在 UDP 之上實現了擁塞控制、緩存控制、Pacing 機制、ARQ、動態可靠性控制等。這裡要簡單地強調下，通過自定義包頭，KTP 可以動態的設定每個包的重傳次數、優先順序，從而滿足不同場景的需求。不像 TCP 完全可靠、UDP 不可靠這種非黑即白的特性。

3、業務感知的信源信道聯合優化模塊。這個模塊把網路和業務緊密結合到一起，這也是決定用戶體驗至關重要的一個模塊。在該模塊，流控策略結合服務端網路估計模塊對網路狀態的估計，網路控制模塊對發送狀態的反饋，以及業務的特性，最終決定信源端，也即業務層一些參數與狀態，例如編碼器相關的碼率、幀率、解析度；可靠性相關的 FEC 動態碼率；延遲相關的緩存控制；基於媒體數據優先順序特性的丟包策略、非對稱差錯保護等。

目前，KTP 在快手已經全量上線，服務於快手的短視頻、直播與連麥業務，總體來說，KTP 具有以下基本特性：

1、業務層面。滿足短視頻上傳、直播、連麥等多種業務需求。提升了短視頻上傳的成功率和速度。對於直播，同時支持互動直播和低延遲的連麥需求，且二者能做到無感知的切換。

2、弱網優化層面。基於 KTP 的強擴展性與業務感知特性，對不同的應用場景採用不同的優化手段。對於短視頻上傳，可以達到在 90% 丟包率的條件下，依然發布成功。對於直播，KTP 能做到 20% 丟包無感知，觀眾感受不到任何的卡頓。而對於傳統的基於 TCP 的協議，20% 丟包是一個門檻，到了 20% 丟包，TCP 類協議幾乎不可用。此外，在聯合優化層面，KTP 集成了豐富的優化策略並做到聯合優化，例如重傳、FEC、非對稱保護、信源信道聯合優化等。

3、其他特性。KTP 中所有的策略與演算法都是獨立的子模塊，可以任意的插拔，從而極大的提高了 KTP 的擴展性和優化效率。此外，KTP 協議還可以做到多種網路無縫切換，用戶在 4G/Wi-Fi 進行切換時，可以做到業務無感知。

3

三、 短視頻上傳優化

上圖是短視頻上傳的架構圖。傳統短視頻上傳直接將編輯模塊產出的文件通過 HTTP-POST 上傳到後端伺服器。為了更好地優化上傳成功率和速度，我們通過一個獨立的上傳模塊接管了客戶端的上傳業務。上傳模塊通過 KTP 協議與部署在 IDC 的 Gateway 通信，進行文件上傳，再由 Gateway 將文件中轉到後端業務模塊。

短視頻上傳的優化中，KTP 的網路估計模塊不用設計得過於複雜。對於丟包、延時、帶寬的估計，根據實時數據做一些統計即可。因為短視頻上傳對數據包間的實效性要求很低，用戶並不關心這個文件每個包什麼時候上傳成功，只關心這個文件的最後一個包什麼時候被成功的上傳上來。因此，可以用較長時間段的數據進行平滑濾波，濾掉網路的噪音與干擾

為了保證上傳的時效性，快速完成短視頻上傳，KTP 採用比較激進的網路控制模式。這裡用一個圖來簡單解釋一下，如上圖右下角的子圖，表述了網路延遲與發送速率的關係。最左邊，當發送速度特別小的時候，延時幾乎不會變，近似等於網路的固定延時；隨著發送速率增大，當發送速率達到網路的帶寬瓶頸後，數據就會慢慢堆積，延時越來越大。當積累到一定程度，整個網路的 buffer 被塞滿，這時候延時將不再增大。因此，在文件上傳中，KTP 偏向於發送速度達到右邊這個拐點附近，這樣做能增大發送速率，搶佔網路帶寬，但是也會帶來丟包的風險。因此，在短視頻上傳的場景下，KTP 的丟包判定非常保守。此外，為了保證數據的有效性，降低數據的冗餘率，網路編碼也是一個非常有效的手段。

在短視頻上傳業務中，信源是一個從編輯模塊輸出的視頻文件，因此，我們需要結合網路估計模塊對網路狀態的估計，動態調整視頻文件的轉碼碼率（視頻文件大小），目標在保證用戶視頻質量的前提下，最小化發布耗時。

4

四、直播推流優化

直播推流的功能複雜，場景豐富，但總體架構比較簡單：推流模塊負責採集、前處理、編碼，然後把媒體數據傳給 KTP 進行封裝並發送。KTP 的接收端部署在自建的源站系統里，源站負責接收數據，並做一些處理，例如錄製、轉碼等。最後，CDN 來源站回源，並分發到最終的消費者。主播端（推流模塊）與源站之間的通信，則完全依靠 KTP。

直播推流過程中，我們最關心的是推流質量。決定推流質量的因素是多樣化的，包括推流的可靠性、傳輸實時行、網路利用的高效性、媒體流的流暢性等，並且這些因素之間是相互影響的。從優化的角度，我們主要考慮以下問題：

1、網路估計。接收端，也即 KTP 協議棧的網路估計模塊，需要結合 KTP 協議攜帶的信息，估計網路的帶寬、丟包、延遲等狀態信息。考慮到直播一般能容忍秒級的延遲，因此，在估計網路狀態的時候，主要採用指數濾波等方式，過濾網路的噪音與抖動。

2、網路控制。KTP 網路控制模塊的核心在於發送速率與可靠性的控制。發送速率主要由擁塞控制策略決定，需要綜合考慮網路估計模塊反饋的網路狀態以及媒體流的特性。在直播場景下，擁塞控制的決策與傳統的文件傳輸有所不同：

數據源（直播流）是實時產生的，如果視頻碼率低於可用帶寬時，容易出現發送隊列為空的情況。當發送隊列沒有數據時，網路會處於空閑的狀態，此時傳統的基於發送速率 - 丟包 - 延遲模式的擁塞控制規則將失效。在 KTP 中，當出現發送隊列為空時，該信號會被告知給擁塞控制模塊，從而避免因為網路空閑導致演算法失效。

發送隊列有數據堆積。此時擁塞控制機制雖然有效，但是數據的堆積會增大延遲以及丟包的風險。傳統的做法是以擁塞控制演算法的反饋速率，無感知的進行發送。KTP 會依據緩存數據的多少、變化趨勢等，在擁塞控制演算法反饋的發送速率的基礎上，動態的調整發送速率，目標在控制延遲與丟包的前提下，儘可能以平穩的速率進行數據傳輸。

可靠性。結合數據包的優先順序（例如音頻與視頻的特性、視頻中不同幀類型的特性等），動態調整每個數據包的可靠性與重傳次數。同時，KTP 在不同場景下，採用了多種丟包判定策略，從而在丟包的激進程度上做到可靠可調節。

3、信源信道聯合優化。該模塊直接感知不同直播場景的業務需求，關係著推流質量。在該模塊，最重要的功能是保證上層編碼器與底層網路能協調工作， 主要手段則是依據編碼器的特性、直播場景的特性、網路的特性等，動態決定編碼器的編碼碼率、幀率、解析度，以及給網路控制層發送數據的速率等。同時，要控制緩衝區的大小從而控制延遲，在極端網路下，需要採用基於優先順序的丟幀策略等。為了提升綜合性能，KTP 的基本出發點是期望應用層的緩衝區不空，但也不要太滿。因為緩衝區空，則很可能帶寬沒有充分利用起來，導致帶寬利用率不夠高，視頻清晰度下降。當緩衝區過滿，則會大大增大延遲與推流卡頓的概率。因此，如何在二者之間尋找平衡點，是流控的關鍵，採用的手段則以控制論為基礎進行建模，設計不同的控制器（PI、PD、PID 等）進行動態調控。

5

五、直播連麥

直播連麥是直播的升級版玩法，即主播與一個或多個粉絲通過音視頻實時互動，同時其他粉絲正常觀看直播。主播和粉絲端的架構比較類似，發送端包括採集、編碼、KTP 發送數據，接收端 KTP 接收數據、解碼、渲染。在連麥方面，主播與粉絲之間的實時音視頻流，通過自建的 MCU 進行轉發，主播與 MCU、MCU 與粉絲之間的通信都基於 KTP。此外，在直播方面，MCU 還需將連麥的合併流以直播的方式發送給源站系統，進而由 CDN 回源並進行正常直播。

這是實時音視頻的流控結構圖，列舉了主要的控制模塊。發送端，編碼器採集編碼後，將數據發送到 MediaBuffer 進行緩存，KTP 從 MediaBuffer 中獲取數據並封裝成 KTP 包，然後以一定的速率進行發送。接收端一方面需要接收媒體數據並進行解碼渲染，另一方面，還需要統計發送與接收數據的特性，進而估計網路的帶寬、丟包和延遲。值得注意的是，在服務端存在一個聚類模塊，這是因為 KTP 的網路估計模塊以單向網路為單位進行網路估計，從而提升擴展性。通過聚類模塊收集各個單跳網路的網路狀態，同時結合路由路徑，進而估計整個端到端鏈路的狀態，並將最終的結果反饋給發送端的 RateControl 模塊。在發送端，RateControl 模塊結合 MediaBuffer 與網路反饋結果的狀態，動態決定編碼器的碼率、幀率、FEC 比例、Pacing 碼率、MediaBuffer 緩存控制等。

直播連麥面臨的挑戰相比單純的互動直播和短視頻上傳都要大很多：

1、網路估計模塊的挑戰。首先是延遲的估計，連麥對延遲的要求很高，在估計網路延遲的時候，需要選擇合理的延遲指標，例如常見的有 RTT （SRTT）、One-Way-Delay、Queueing-Delay，KTP 則綜合考慮後兩者。此外，過濾網路的噪音和抖動，對延遲的估計也至關重要，延遲估計的誤差對連麥質量的影響非常大，常見的方式是濾波，例如卡爾曼濾波，指數濾波等。對於丟包的估計，則需要區分導致丟包的原因：隨機丟包還是擁塞丟包。二者的處理方式完全不一樣，隨機丟包主要通過增加 FEC 或重傳來對抗，而擁塞丟包則主要通過流控降低發送速率，緩解網路擁塞來避免。KTP 基於延遲的抖動規律，同時結合丟包率的特性，來動態判定當前丟包的原因，進而採取合適的策略。對於網路帶寬估計，KTP 主要以延遲估計為基礎，結合實時發送速率與接收速率的特性為輸入，對網路進行分類建模，動態預判網路帶寬的變化趨勢。

2、弱網的優化。採用 UEP 區分對待不同重要性的數據包，聯合 ARQ/FEC 對抗網路的丟包。此外，另一個挑戰是編碼器的特性對流控的影響特別大，信源信道聯合優化顯得更加重要。例如，在實際系統中，編碼器的輸出並不能按照流控的反饋準確的控制碼率（通過一定的手段可以做到嚴格的 CBR，但是會大大損失編碼質量），這是因為實時視頻的碼率與具體的場景、幀類型都相關。而連麥這種 RTC 應用，對實時碼率的抖動非常敏感。碼率的抖動會影響傳輸延遲的抖動，進而影響網路狀態的估計與流控的決策。因此，編碼器的優化與傳輸策略的優化，只有深入結合，才能保障實時音視頻通信的效果。

3、競爭的考慮。對於主播，上行存在直播流與連麥流的競爭，二者的特性以及底層的擁塞控制策略都不一樣。因此，對網路的利用程度、競爭程度也完全不一樣。一般情況下，直播流的擁塞控制策略會比連麥的激進，搶佔能力更強，因此，二者的配合也非常重要。在 KTP 里，二者在統一的架構中，能彼此知道對方的狀態，以直播和連麥的總體效果為目標，在各自擁塞策略和流控機制的基礎上，做全局的優化，從而決定最終的發送速率。

6

六、後記

KTP 已經全面落地於快手的多項相關業務，KTP 基於 UDP，具有極強的靈活性。KTP 各模塊獨立解耦性可插拔，同時背靠快手的 AB 系統與大數據系統，為後續的持續優化提供了極大的空間與便利。從業務角度看，多人實時互動也是目前的重點業務，對 KTP 的挑戰也將大大增加。此外，除了利用 KTP 進行上行優化外，我們也在做下行的優化，包括直播多碼率、短視頻多碼率、CDN 智能調度等。

快手秉承積極開放的心態，希望利用快手的技術優勢與數據優勢，推動相關技術的快速發展，也歡迎志同道合的技術達人一起探討 / 加入我們 KTP 的持續優化中來。

7

作者介紹

周超博士，快手科技演算法科學家。畢業於北京大學，主要研究方向包括計算機網路、多媒體通信、流媒體傳輸優化等。發表論文三十餘篇，申請專利三十餘項。現任快手科技演算法科學家，負責快手視頻傳輸演算法組的管理與業務優化，主導了快手私有傳輸協議 KTP 的設計、實現、優化到全面落地。

8

活動推薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！