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