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鲁莽的重传也会导致不必要的数据重复发送，进而浪费宝贵的有限带宽资源。总而言之就是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应用端口与各种互联网应用以及各种网络优化解决方案，达到对全平台的支持与兼容。

精品文章推荐

技术干货：