文 / 範醒哲
整理 / 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魯莽的重傳也會導緻不必要的資料重複發送，進而浪費寶貴的有限帶寬資源。總而言之就是TCP流之間帶寬共享無任何保護，帶寬搶占近乎随機，使得帶寬資源配置設定不合理，這種端到端的寬帶資源利用與共享命題是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的開發設計具有一定後發優勢。基于UDP的方案也主要在應用層開發， 而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協定并未妥善解決音視訊行業所面臨的時延與卡頓問題，尤其是在處理低延遲時間互動、跨國傳輸與卡頓頻率、每次卡頓等待時間等問題時均顯得力不從心。現在的TCP無法滿足安防、互動直播等諸多行業的需求。我們看到業界呼喚新一代與TCP相容的高速資料傳輸技術能夠從容應對音視訊大資料和智能終端的挑戰，借助全新設計的内部架構與機制和在智能檢測、控制、信号處理方面的全新理論基礎，從根本上解決核心傳輸問題并與現有個解決方案協同工作。
面對音視訊行業的需求，我們經過不屑努力研發了新一代TCP傳輸協定，即CRN-TCP，主要用于解決高清視訊播放時的卡頓問題，上圖展示的是實驗室中的實測資料，其中第一列是不同的網絡時延，第二列是不同的網絡丢包，最後一行是CRN-TCP相對于傳統Cubic-TCP所帶來的性能提升倍數。CRN-TCP 在帶寬允許的高丢包與高時延長距離網絡上實作了4K高清視訊的無卡頓播放。
我們希望與音視訊行業相關人士一起努力，實作在不做任何應用與網絡架構的變更下降低音視訊流的時延與卡頓，提升音視訊使用者在弱網下的體驗；同時實作最大的帶寬使用率與最高的帶寬使用效率，進而節省昂貴的帶寬開銷并實作與音視訊資料流的公平帶寬共享；新一代協定全面相容現有TCP協定并支援标準TCP應用端口與各種網際網路應用以及各種網絡優化解決方案，達到對全平台的支援與相容。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/86581743「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。