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