TCP的困境与解决方案
TCP協議是互聯網應用最廣泛的數據傳輸協議之一，在過去的40年中改變了世界，但也成為了新的技術瓶頸。Cascade Range Networks, Inc CTO/聯合創始人 范醒哲在LiveVideoStack線上交流分享中詳細解析了TCP面臨的困境與可行的解決方案。本文由LiveVideoStack整理而成。
文 / 范醒哲
整理 / LiveVideoStack
直播回放?
https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=9336cda7b1fe4125ab730c818fe1219a
大家好，我是來自Cascade Range Networks的范醒哲，本次我為大家準備的分享主題為“TCP的困境與解決方案”。作為互聯網使用最廣泛的傳輸協議，TCP帶來巨大改變的同時，也面臨一些亟待解決的問題，接下來我將圍繞音視頻行業與大家討論以下相關內容：
1.?為什么關注TCP？
為什么我們需要持續關注傳輸問題？最根本的原因是數據量增長的速度遠遠超出帶寬增長的速度。即使5G時代即將到來，傳輸問題依舊是技術實踐當中的關鍵性命題。看似5G時代下強大的帶寬會讓傳輸問題迎刃而解，但在實踐中不難發現數據的增長速度遠遠更快。隨著5G時代到來的是超高清視頻、3D、VR、AR等數據量極大需要帶寬更多的音視頻應用，這就使得帶寬成為一項技術瓶頸始終制約音視頻行業的未來發展，我們需要一個能夠妥善處理帶寬問題的解決方案。
我們在音視頻社區討論數據傳輸，主要是因為數據傳輸雖然是一個網絡概念，卻與音視頻技術中的各種技術存在一定相關性；而音視頻數據現已經成為互聯網中數據傳輸的主要對象，其占比預計會從2016年的51%增長到2021年的67%。
而Live Video方面則會出現4倍的增長，2021年達到13%，這使得我們不能不關心其未來發展。
即使在現在的音視頻行業中有很多解決方案都是基于UDP協議，但作為一個承載互聯網中大部分應用的傳輸協議，TCP在可預見的未來依舊是最主要的協議 。
?
例如對于全球最大的流媒體平臺Netflix而言，從Netflix數據中心到CDNs的Outsourcing，從數據中心到Amazon cloud的Cloudsourcing以及用戶從Amazon Cloud獲取視頻數據等數據流的后端都在使用著各種基于TCP的方案。雖然有些后端已經陸續使用基于私有UDP協議方案的大規模數據傳輸，但前端的大部分數據傳輸尤其是用戶從Amazon Cloud獲取視頻數據還是基于TCP方案來實現視頻分發。
作為未來智慧城市中不可或缺的一部分，安防系統中的智能攝像頭到NVR再到云的大部分數據流都是基于TCP實現。一些擁有私有云的企業可能使用基于UDP的解決方案，但如果接入數據至公有云則仍需要TCP進行承載。
除了上述案例，家庭娛樂與未來的遠程醫療都需要大量的音視頻數據作為支撐，其傳輸也主要由TCP承載。
2.?TCP面臨的挑戰與問題
TCP作為互聯網應用最廣的數據傳輸協議，所面臨的挑戰值得我們一探究竟。首先，由于今天絕大多數的網絡社交、視頻、云計算、大數據與智能終端等使用TCP作為底層傳輸協議的應用都是基于HTTPS實現的，每項應用對性能的要求側重點不同——交互視頻、游戲等側重低時延，高清視頻、在線4K播放等側重數據傳輸速度，這些不同應用的不同側重需求使TCP的設計充滿挑戰；其次，由于在TCP的研發初期帶寬資源較為匱乏，而隨著通信技術的發展帶寬資源與質量明顯提升，互聯網帶寬已有幾個數量級的提升，此時的TCP必須對幾十年前的內部架構與工作機制進行一定技術改進才能保證在高帶寬中高速的傳輸數據——如優化TCP的主體架構等，以避免TCP面臨一些具有海量數據應用時在速度等性能參數方面力不從心；最后，隨著全球數字化及超高清網絡音視頻應用的層出不窮，遠距離與大數據也給TCP帶來了很多前所未有的挑戰。
具體而言，TCP面臨的主要問題是帶寬資源的浪費。在互聯網初期帶寬資源不多，就好比路不寬不好，后來路在逐漸拓寬升級等，但是TCP這輛車卻一直沒有升級很多，就像一輛老舊汽車在高速路上無法快速飛奔。另一方面，有如下班高峰期的道路擁堵，網絡擁塞也是TCP亟待解決的問題，這方面的研究可以堪比自動駕駛技術極大提升高速公路的車流量，使每一位司機都變成一位守規的開車人。
2.1 TCP的效率問題——時延
時延程度對一些特殊場景下的音視頻而言至關重要，如在線課堂應用場景中一旦講師的音畫出現明顯時延就會導致講師與聽眾之間無法正常交互；而像游戲直播等出現明顯時延則會極大影響游戲直播效果與觀眾觀看體驗。
2.2 TCP效率問題——速度
TCP的速度問題同樣至關重要，如在未來4K在線播放等對數據傳輸速度要求極高的應用場景，一旦速度過低無法達到流暢播放的要求，觀看就會經歷大量卡頓等待或者變碼率造成的清晰度下降，體驗便會大打折扣；而如果速度過高則會造成網絡的擁塞與丟包、重傳，進而造成帶寬利用低下等問題。
互聯網技術的發展，帶寬自始至終都是非常昂貴的資源。此環境下的TCP正逐漸成為一個制約音視頻發展的新瓶頸，其限制首先在于當帶寬足夠時TCP無法實現100%的帶寬使用率，這時會出現物理帶寬足夠播放1080P等高清視頻時卻出現嚴重卡頓，即帶寬未得到100%利用的現象。我們需要在考慮帶寬投入的同時重視帶寬的利用效率，避免TCP成為效率的制約因素。
TCP瓶頸的其他方面包括：
1）當應用不再需要時，TCP不必要的間歇搶占帶寬與暴力發送會對正常的視頻流傳輸帶來極大干擾從而造成視頻卡頓、非必要丟包等狀況。
2）TCP魯莽的重傳也會導致不必要的數據重復發送，進而浪費寶貴的有限帶寬資源?？偠灾褪荰CP流之間帶寬共享無任何保護，帶寬搶占近乎隨機，使得帶寬資源分配不合理，這種端到端的寬帶資源利用與共享命題是40年來學術界公認的互聯網最難解決的問題之一。
3.?TCP速度性能研發改進
3.1 實戰派
實戰派主要是通過對TCP代碼的修補，小幅提升TCP的性能。
TCP從初期便使用一種被稱為“滑動窗口”的方式進行發包，也就是類似于批量流水線的方式，如上圖右側展示的那樣，工人對應TCP的一段代碼，通過調整此滑動窗口的大小來確定發什么包及發包的速度。
早在1990年TCP便采用被稱為AI/MD的滑動窗口發包模式，AI即逐步線性探測帶寬，MD即在擁塞時指數遞減滑動窗口，如每探測到擁塞或者丟包時將滑動窗口減小到原來的一半， 從而減慢發送速度。
但實際上TCP的AI部分反應速度十分緩慢，在面對高帶寬環境時明顯力不從心。因此在改進的TCP Cubic上引入了一些非線性探測方法，可以簡單的理解為將傳統的線性搜索改進為二分搜索從而提升搜索速度。
除此之外，BBR也是是近年新起的一個擁塞算法，其原理是通過短暫的暴力發送來探測帶寬并根據估算的帶寬決定發送速率。
當然，近些年還有一些商業算法面世，例如由Riverbed公司開發的Highspeed TCP，其是在原來AI/MD的基礎上，把MD的窗口減半改為減小1/8。
而微軟則嘗試通過加快網絡帶寬探測的速度，細節如上圖所示。
從最初的滑動窗口改變策略，到后續的各種改進，業界已經將滑動窗口策略改進作為優化TCP性能表現的常見思路。
落實到內核代碼層面的改動，改進一個滑動窗口協議算法的工程量一般小于幾百行代碼。
實戰派的基于反復試錯的實踐對音視頻行業而言的確始終是姍姍來遲，以至于近些年來音視頻行業對各種網絡狀況下的速度訴求遠遠超出了TCP自身在弱網情形下的速度提升，所以慢慢有群體 提出使用UDP取代TCP的各種解決方案。相對于較為功能全面的TCP，UDP更像是一張白紙，基于UDP的開發設計具有一定后發優勢?；赨DP的方案也主要在應用層開發， 而TCP的開發幾乎都在操作系統內核中，難度極大。
3.2 學術派
學術界在過去三十多年中也在不斷探索針對TCP的速度性能改進與研發。雖然學術派的想法距離我們日常運維實踐來說較為遙遠，但一些開創性方案同樣具備一定指導意義。
學術界的重要思路是通過建模與仿真實現對TCP的性能優化，上圖展示的是一個網絡拓撲，其中包括4個source與3個link。link1的速率對應流x1、x3的速率之和，link2的速率對應流x1、x2、x3的速率之和，link3的速率對應流x1、x2、x4的速率之和，總體來看就是每個link的速率等于各單流速率之和。而我們通過測量往返時延來量化擁塞程度，x1的往返時延等于流y1、y2、y3上的往返時延之和；x2的往返時延等于流y2、y3上的往返時延之和。從建模的角度我們可以看到這是一個非常規整的對偶問題：使用線性代數表述，鏈接上的速率等于矩陣x鏈接速度乘以矩陣R，而擁塞正好是將此矩陣順/逆時針旋轉90度后再乘以每個鏈接上的時延即可得到對應鏈路的往返時延。
1998年，英國一位院士在研究網絡建模時發現TCP協議與AMQ協議實際上是最大效用網絡全局優化命題。上圖右側公式中的c代表帶寬，我們需要在保證速率不超過帶寬的情況下盡可能提高網絡效用性能，所謂的各種網絡效用即對應了各種TCP協議。
Kelly教授不僅將此問題建模，還得出此問題的兩個分布式解，這兩個分布式解正好分別對應了TCP協議與AMQ協議。這種將網絡看作為一個分布式自動控制系統的想法是開創性的，使得我們可以將具有近百年歷史的控制理論與博弈理論應用于網絡的研究中。
以Reno為例，上圖展示的兩段代碼中，第一段用于進行線性探測帶寬，第二段用于探測到網絡擁塞時將窗口數量減半。
兩段代碼對應兩段數學公式， 對應線性探測帶寬， 對應探測到網絡擁塞時將窗口數量減半。
于是我們就可以推導出TCP協議的效用公式，這種建模可將不同的TCP協議對應至不同的數學方程當中， 不同的TCP對應不同的效用也就順理成章地解決了大家關心的帶寬共享和使用問題。除此之外，實際傳輸速度的快慢也即等同于趨于平衡點的速度快慢，也就是將原命題轉化為一個自動控制問題，這樣我們就可以將很多自動控制理論用于此網絡命題的研究之中。
雖然在過去三四十年學術界通過不斷的建模與仿真從未停止過對TCP的理論研究，但這種建模與仿真對音視頻行業來說具有一定的局限性。首先，盡管學術界有上千篇關于TCP研究的文章，但這些研究很多都僅停留在高校院所或學術期刊上，并未真正被音視頻行業所知曉與實踐，許多理論仍停留在數學公式階段，無法在短時間內被轉為工業應用；加上院校也沒有機會接觸音視頻行業實實在在亟需解決的問題，缺乏對音視頻行業的深入理解與思考，一些實際的問題容易被研究者忽視；以上種種原因導致學術界有關TCP的研究無法在實際的音視頻行業得到較為成功的應用。
3.3 研究思路
?
無論是嘗試通過底層代碼進行優化的實戰派還是借助仿真與建模進行優化的學術派，在評估各種TCP的好壞時，都可以將TCP作為一個黑盒子來研究。我們作為終端用戶也可以用同樣的辦法來評估，普通用戶進可以忽略TCP內部的代碼與建模方式，將測試重點放在量測各種網絡情況下的TCP性能，這種性能分析的實現門檻較低，只需一臺電腦即可完成。如圖所示，我們可以通過兩臺Linux虛擬機上的tc命令行創建兩個網損：配置分別從B到A和A到B的兩個100ms、丟包1%的單向網損，此情況下就得到了一個200ms 1%丟包的雙向網損；接下來我們就可以用一些業界的常用量測工具如iperf來量測TCP的性能，這便是評價TCP性能的最快方式。
通過類似的量測與建模研究，學術界和工業界得到一些TCP最大理論速度的經驗公式，如上圖展示的一個公式，由此公式我們可以發現，TCP的理論最大速度與傳輸距離成反比，與丟包率的開平方成反比。這也就是為什么當在訪問距離較遠的網站時TCP會經常出現一些性能問題，例如一個可以在局域網內流暢觀看的高清4K視頻流被跨國傳輸到海外時便會出現無法正常播放等一系列問題。同樣，TCP對丟包的極其敏感也與公式中的開平方有關系，假設線路信號錯誤丟包為百萬分之一，開平方后即為1/1000在公式右半邊的分母中，而實際擁塞丟包為百分之一，開平方后的數值為1/10，其與1/1000存在一百倍的差距，這便導致了TCP對丟包的敏感性。擁塞丟包就好比道路堵車在現實中是無法避免的。
?
面對TCP的上述種種缺陷我們應該如何改進與解決？
4. 解決方案
4.1 基于內容的解決方案
我們可以將此方案概括為基于緩存或CDN進行數據壓縮，重復數據刪除或對應用協議進行特定優化。
1）基于緩存或CDN實現
?
我們可以將第一個方案概括為基于緩存或CDN進行數據壓縮，重復數據刪除或對應用協議進行特定優化。此方案被絕大多數音視頻企業所采用，也是CDN的主要收入來源之一。在這里CDN主要為企業提供兩部服務：帶寬與覆蓋。后者主要依靠CDN的多城市布點以降低往返時延來解決。雖然此方案間接解決了一些TCP的短板，但卻是非常昂貴的。
2）刪除壓縮、重復數據或優化特定應用程序
?
基于壓縮、重復數據的刪除與應用程序特定優化的解決方案在以前受到追捧，如Riverbed公司便使用軟件加速核心來壓縮數據與刪除重復數據。但在音視頻行業中，已經上傳的數據幾乎不能夠進行二次壓縮，尤其對于HTTPS數據流而言更是難以實現；而應用程序特定優化是指提升單次交流的效率，主要用于解決在線視頻交互的時延問題，這種提升對大數據音視頻應用的是非常有限的。
?
即便如此，基于內容的解決方案本身并未真正解決TCP的諸多問題，而是彌補了TCP的相關短板，通過覆蓋、內容壓縮等降低TCP的發包數量。
4.2 基于虛擬路由或線路優化減小TCP時延
?
此方案主要針對路由或線路的優化，多用于一些手游加速。其關鍵在于基于緩存或CDN進行擴展，通過購買或租用線路來優化小數據傳輸路徑，從而解決單個數據包端到端的時延問題，但由于其云路位于由ISP控制的物理路由之上，優化受到限制，且所需花費的成本十分龐大，維系一個SD-WAN僅運維所需成本就高達上千萬，且性能提升十分受限，同樣也是非常昂貴的解決方案。
4.3 基于UDP的解決方案
?
TCP的諸多久未改善的缺陷使得業界更加傾向于使用基于UDP的解決方案，隨著音視頻行業的高速發展。TCP的發展停滯不前，越來越多的企業不斷探索新的改進方向，基于UDP便是其中的一種。其優勢在于UDP是一個應用層封裝，開發者在UDP上開發一個協議的難度遠小于內核層級的開發，具有一定后發優勢。當然，UDP的缺陷在于由于其端口開放的設計易導致一系列安全隱患，不易受IT部門青睞；加上UDP本身沒有可靠的性與擁塞控制，因此基于UDP的應用層傳輸協議必須在應用層得到重建，這就會造成額外的軟件開發與CPU&RAM的資源浪費；最后，UDP作為一個雙端方案，需要數據發送端與接收端的雙端部署，這對于那些不能控制收發兩端的企業來說無疑是不能接受的；同時，面向廣大消費者的雙端方案也面臨許多問題，如某在線教育公司為保證在線課堂視頻交互的成功率會要求學生使用PC的Chrome瀏覽器或手機端的Chromium內核瀏覽器觀看視頻，這體現了UDP無法在短時間內大規模進入消費市場的現狀，可以說在覆蓋和穿透上并UDP和TCP相比還有很大的距離 。
4.4 改進的TCP擁塞控制
?
上圖展示的就是前文提及的改進TCP擁塞控制算法的一些優劣與實例。
?
經過這么多年的發展我們可以看到，UDP協議的成功從側面反映了TCP協議的失敗。TCP協議并未妥善解決音視頻行業所面臨的時延與卡頓問題，尤其是在處理低時延交互、跨國傳輸與卡頓頻率、每次卡頓等待時間等問題時均顯得力不從心?，F在的TCP無法滿足安防、交互直播等諸多行業的需求。我們看到業界呼喚新一代與TCP兼容的高速數據傳輸技術能夠從容應對音視頻大數據和智能終端的挑戰，借助全新設計的內部架構與機制和在智能檢測、控制、信號處理方面的全新理論基礎，從根本上解決核心傳輸問題并與現有個解決方案協同工作。
面對音視頻行業的需求，我們經過不屑努力研發了新一代TCP傳輸協議，即CRN-TCP，主要用于解決高清視頻播放時的卡頓問題，上圖展示的是實驗室中的實測數據，其中第一列是不同的網絡時延，第二列是不同的網絡丟包，最后一行是CRN-TCP相對于傳統Cubic-TCP所帶來的性能提升倍數。CRN-TCP 在帶寬允許的高丟包與高時延長距離網絡上實現了4K高清視頻的無卡頓播放。
?
我們希望與音視頻行業相關人士一起努力，實現在不做任何應用與網絡架構的變更下降低音視頻流的時延與卡頓，提升音視頻用戶在弱網下的體驗；同時實現最大的帶寬利用率與最高的帶寬使用效率，從而節省昂貴的帶寬開銷并實現與音視頻數據流的公平帶寬共享；新一代協議全面兼容現有TCP協議并支持標準TCP應用端口與各種互聯網應用以及各種網絡優化解決方案，達到對全平臺的支持與兼容。
精品文章推薦
技術干貨：
RUDP傳輸那些事兒
RTMP之后，SRT與QUIC
跨國實時網絡調度系統設計
WebRTC的擁塞控制和帶寬策略
基于HLS格式的低延時互動直播技術
CCtalk高可用多媒體服務技術選型與實現
UDP成為低延時流媒體關鍵 選SRT還是QUIC？
下一代低延時直播CDN：HLS、RTMP 與UDP +WebRTC
總結
以上是生活随笔為你收集整理的TCP的困境与解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LiveVideoStack线上交流分享
- 下一篇： 音视频技术开发周刊 83期