LiveVideoStack » 范醒哲：敬畏自然渴望技术 —— 新冠肺炎后对网络数据传输能力的思考

范醒哲：敬畏自然渴望技术 —— 新冠肺炎后对网络数据传输能力的思考

视频会议 TCP CDN

LiveVideoStack 2020年3月7日

老树开新花

从学生时代起，我就一直在做计算机网络协议方面的研发工作，到现在做了将近20年了，反而越做越感兴趣。

2005年的时候，我开始参加工作，在University of Miami 电子与计算机工程系教授计算机网络相关的课程，同时从事TCP方面的科研。

之后由于机缘巧合，加入了硅谷的一家创业公司Aspera，从事基于UDP的应用层协议研发。公司被成功收购后，我开始思索下一个需要被解决的大问题在哪里。

我注意到，尽管TCP是互联网使用最广泛的标准数据传输协议，但这么多年来，其性能问题却一直是互联网、物联网的痛点，于是我开始了第二次创业之旅：解决TCP协议的低率问题。

我们现在的公司Cascade Range Networks在不改变TCP协议标准的前提下，重写TCP的3万行内核代码，重新实现了TCP、解决了TCP为大家所诟病的低效，让老树也开出了新花。

我们的产品是一部“越野车队”

最近由于新冠肺炎的影响，大家都在家里远程上课、远程办公、远程会议，很多平常线下的活动全部都移到了线上，有一些行业也被“逼”开直播自救，网络带宽因而压力猛增。如何提升视频流并发量从而更高效地利用网络带宽，成为疫情期间我们遇到的技术难点之一。

比方说原来一条1Gbps的教育线路可以支持300路高清视频流供学生课后复习观看，但是由于疫情，学校的IT部门突然被要求在同样的带宽下支持450路等同的高清视频流。学校发现如果继续使用原有数据传输技术就会出现线路拥塞，这时我们需要做的，就是在不升级线路带宽的情况下仍能迅速支持更多的学生观看教学视频。

攻克这个技术难点的关键，是要对每一路数据流进行精准的速度控制，去除TCP的暴力发送数据、暴力抢占带宽等造成的不必要的数据丢包和数据重传，及时重传丢包的同时不抢占别的数据流的带宽，做到精准的“恒速”发送。

这个工作，就好比是以前的TCP是一群不守规矩的司机，开车频繁换道、加速和刹车，不仅自己没能节省时间还对其他车辆造成了干扰，从而导致道路未满负荷就已经拥堵。

我们所做的就像是为每辆车升级，使其具备自动驾驶功能，这样车与车之间保持匀速小间距，车辆也不再频繁换道，尽可能让道路做到满负荷、高吞吐量并服务尽可能多的数据流。从而支持更多的学生在线上无卡顿地观看教学视频，也降低端到端的延时与滞后。

在上一次接受LiveVideoStack采访的时候，我做过这样一个比喻：如果把带宽想象成“路”，那我们的产品就是无论路况好坏都可以在上面高速行驶的“越野车队”，为客户准确、快速、可靠地“运送”数据。

流量暴增的情况下，数据传输解决方案首先要保证优先传输关乎国计民生的视频数据流，然后再传输相对次要的供大家消遣娱乐的视频数据流，这就对数据传输速度有一个非常高的要求，即在带宽拥堵等不理想的情形下能快速可靠、及时优先地传送重要应用的数据，比方说重要的疫情监控视频等。

以前绝大多数数据传输技术的缺陷在于，在理想的情形下（比方说近距离、低丢包，好比道路路况较好时）能够持续稳定地保证数据传输速度，而在不理想情形下（比方说远距离，高丢包，好比道路路况不好时）就不能够稳定地保证传输速度，进而无法保证及时性，这就造成了很多现有数据传输解决方案依赖于专线（好比铺设专用通道），或者依赖于提前传输预存（好比各地建立很多仓储提前把视频预存在城市附近的数据中心）。

具体来说，在没有像这次新冠肺炎造成的互联网数据流量暴增时，视讯服务提供方往往依赖于像CDN、SDWAN等预传输、预分发或专有线路优化技术，或者FEC等数据冗余技术，面对突然数据流量的急剧暴增，这些技术方案或因实施耗时而无法快速应对需求、或因预传输分发等无法满足实时性要求、或因“冗余”传输量在需求陡增时“浪费严重”。

所以在突发事件发生时，不仅要靠CDN，SDWAN这样的“道路”基础设施类方案，还需要有“越野车队”，能及时的传送数据。在这次突发情形下，我们看到视频类应用的一个核心要求就是在全天候“路况”下，如何保障其所需的传输速度和低时延。这里面有很多算法和系统方面的挑战。

在算法方面，及时的重传技术不仅需要准确的探测丢包还需要准确的预测丢包，这些算法需要一系列的数据结构和软件架构来支持；

在系统方面，在应用层UDP之上实现这些算法相对难度较低，因而近些年来我们看到很多应用层的API的出现，但是在操作系统内核中直接重组重构重写TCP，因内核内部没有稳定的网络传输层API，难度很大。

选择基于UDP的应用层API还是TCP，这个可以说各有利弊，就目前的技术生态来看，完整的解决方案本身两者是都需要的。

速度与激情的挑战

这次我们聊的高清会议，在我看来主要有两个挑战，第一是高清带来的传输速度的挑战，第二是会议带来的实时性挑战。

在网络上，大家谈起速度往往同时涵盖了单位时间道路吞吐量和用户感知时延两个概念。如果形象的想象每个数据包在网络里的移动，那数据包移动的平均速度可以用时间来量化，即从数据发送端到数据接收端花了多长时间，在技术上我们称之为时延。

当一个数据包丢失了，这个数据包就需要被重传，所以真正的用户感知时延往往是线路时延的数倍，这个简单的说就是实时性的挑战。

单独一个包到达对用户是没有意义的，视频流需要很多很多数据包才能播放起来，所以需要单位时间的吞吐量大，这个简单的称为传输速度的挑战。

攻克速度和实时性的难点需要同时几方面的努力，在速度方面需要精准的带宽检测和带宽预测，做到尽可能大的利用可用带宽。在实时性方面需要精准的丢包检测和丢包预测，及时重传减小用户感知时延等待。

疫情造成的互联网拥堵还增加了另外一个挑战，就是在有限带宽底下最大限度的提升视频流的并发量，虽然一直有这方面的优化，但在面对突发性的互联网流量陡增时，我们就不会仅仅满足于次优。继续提升的难点在于需要结合码率做传输速度方面的非常精准的速度控制，这方面的工作需要一定的数学建模和像现代控制理论这样的应用数学工具指导速度控制。

速度控制的本质是可用带宽的跟踪。可用带宽随着用户的数量、信号的强弱、运营商的某些策略等随着时间变化。5G带宽大但是基站覆盖范围小，容易受建筑物等影响，也会造成可用带宽的巨变。

再聊聊沉浸式会议体验，这也是未来的趋势之一。沉浸式会议体验对数据传输技术要求的关键点还是高带宽和低延时，这种带宽和延时的要求是端到端（用户端到服务端）的用户感知带宽和用户感知时延。

5G可以解决网络接入部分的高带宽和低时延要求，所以很多媒体在报道时认为5G的到来意味着新兴媒体体验的到来，这个还是需要澄清一下，沉浸式会议体验所要求的高带宽是用户应用感知的带宽，它跟5G带宽相关但不完全是5G的物理带宽。

首先用户感知带宽是端到端的，这种带宽瓶颈随着5G接入带宽的提升，更有可能出现在服务器端，比方说由访问用户增多引起的挤兑拥塞，如像这次新冠肺炎疫情造成服务器访问流量激增而造成用户访问变慢；其次用户感知的带宽还要考虑丢包、重传或者FEC冗余数据等造成的折扣。

5G接入带宽的提升，会马上暴露以上所述数据传输的瓶颈，而任何用户感知带宽过低（相比5G物理带宽）都会马上带来急需解决的技术问题：比如数据发送端重传丢包造成的数据接收端等待；简单FEC带来的冗余数据过多而不能自适应网络丢包状况；服务器高并发访问造成带宽利用率下降等等问题。这些都是沉浸式会议体验给数据传输技术带来的高带宽方面的要求。

除了高带宽的要求，沉浸式会议体验也有非常苛刻的用户感知时延要求，比方某些VR应用的时延滞后达到一定阈值时，参与者会有明显的晕眩感，这就需要不仅是5G网络接入段降低时延，骨干网络部分、服务器网络接入部分都要有很低的时延。

考虑到共享网络时延的不可预测性，沉浸式会议体验所要求的低用户感知时延将会更多依赖优化路由甚至租用专线来满足，但数据传输本身，比如发送端不能及时重传先前丢失数据从而造成的接收端应用等待，进而造成用户感知延时过大也是非常需要注意的问题。

5G与SRT，新与旧

谈到5G可否带来上层技术诸如多媒体压缩技术和传输技术的标准化，这是个很有意思的话题。

接入带宽的极大提升的确给了上层技术更多的想象空间，好比存储空间的极大提升也促进了文件系统、文件格式的发展，不过这将是一个非常漫长的过程。

网络和存储的不同在于，网络是一个多层多样的系统，5G仅是网络接入技术。就好比我们家庭宽带以前依赖铜缆，现在越来越多依赖光纤，接入带宽的提升仅是把瓶颈从一个地方移到了另外一个地方。新的瓶颈将更有可能出现在流媒体服务器端，甚至是5G基站的互联网接入端。

我们知道网络除了路段多样和瓶颈多样外，它的数据通讯实现也是分层的，各层之间的设计是相对独立的，所以上层传输层或者应用层并不知晓端到端（用户端到服务器端）发生在何处，上层对底层的瓶颈是一视同仁的。

一个好的协议或者标准，在设计之初不会仅为一个G而设计，或者仅针对某个特定路段的瓶颈而设计，它是相对稳定的。一个简单的例子就是TCP协议，它从最初的1G到现在的5G，都是互联网的标准，支撑着我们最常见的像HTTPS这样的应用层协议。

我想，这个话题更深一层的思索，是以前的协议或者标准是否能够在5G时代继续生存和发展。具体而言，数据传输协议在5G时代（平均无线用户感知100Mbps的量级，相比4G时代平均用户感知10Mbps的量级、3G时代的平均1Mbps的量级）是否能继续生存下去，还是将被新的协议标准所替代。

我个人认为当前的多媒体传输协议标准大部分不会受到5G带来的冲击，只会继续调优适应带宽的增长，因为如前所述绝大部分这些技术并不是为某一个G、或者某一特定路段瓶颈而设计的，是为互联网设计的。

5G带来的速度提升对上层应用来说也并不是第一次遇到，比方说在我们的家庭宽带接入中，也是从小带宽提升到100Mbps的量级，而且现在100Mbps早已不少见，这些协议一直在发展并胜任了家庭光纤接入，我想它们也能胜任5G时代的到来。

当然5G的另一挑战是带宽大但基站覆盖范围小，对终端用户体验的影响是带宽瞬时变化巨大，您可能在路上移动转个弯，手机的速度就或许就从100Mbps掉到1Mbps以下。

这当然是一个很有意思的问题，我个人觉得很多现有的多媒体传输技术面对带宽的剧烈波动是会受影响，所以每个协议需要做些相应的工作，但这些应该不会影响协议标准，仅是协议内部的调优。当然优化也会造成优胜劣汰，让我们拭目以待。

SRT随着互联网音视频应用的增多也会逐步增多各种应用场景。

一个协议被看好与否不仅仅是技术原因，比方说是否容易集成、是否容易调优、是否可以自学习适应各种不同的网络环境和不同的应用要求等，还有很多商业因素，比方说是否有联盟支持、联盟中企业在互联网和其相关行业中的分量、是否容易找到相应的集成和开发人员等等。

总体来说SRT相较其他视频流传输格式（RTMP、HLS、DASH等）有一定技术和非技术方面的优势，但是SRT的劣势也是相当明显的，就是在高并发时带宽的浪费。这也是整个基于UDP的视频传输协议目前的通病，目前来看还是比较适合点对点视频传输，比方说网红直播时主播推流到平台，还有企业高清视频会议，在点到面上的场景现在应用起来需要一些冗余带宽，比如阿里一年一度的晚会等特殊场合。

长远来说实现SRT与专业实时会议通讯系统的兼容，还有一定的路要走，需要厂家的集成与支持。据我们观察，厂家在对SRT的支持上也是有一定的私心的，比如说将SRT的经验用于厂家自己私有协议的开发、还有一些厂家在优化SRT后未完全公开优化代码等等。

我个人觉得，厂家从自身商业利益考虑，将来会在自己的设备中支持多个标准协议，保证设备的通用性。比方说同时支持基于UDP和TCP的传输方案，在这点上，这些不同方案对厂家来说是一个生态，在其产品里一个合作的生态更有利于其硬件系统在互联网、物联网的普适性。

当时只道是平常

疫情影响了很多行业，也让很多人“闲”在家里，可以说是“人闲了，网络忙了”。而我们这些网络工程师恰恰相反，在疫情期间反而比平常更忙。

疫情之下，平常看来理所当然的事，其实都来之不易，我的内心是“对自然深深的敬畏，对真情深深的感动，和对技术强烈的渴望”。

在面对突发事件时，大家通过在家办公、在家上课，继续为社会做贡献的同时也减轻了给地球生态带来的压力。这些都离不开一个更加强大的互联网和物联网，也让我们对现在做的工作多了一份使命感。

CRN是一家专注于数据传输技术的公司，一直致力于革新陈旧的数据传输协议，解决互联网和物联网上各种数据传输瓶颈。

当前我们看到的最大的数据传输瓶颈就是互联网最广泛使用的传输协议TCP的瓶颈，这个协议40年来未能与时俱进，有很多技术方面的难点，深嵌在操作系统的内核中，内核本身有非常多的变种和版本，市场产品等碎片化非常严重；也有理论方面的难点，比方说需要很多智能控制与预测算法。

由于互联网的存在，地球越来越小，我们今天可以跨区域、跨洋进行超高清的视频会议、视频点播，这在以前只有通过卫星才能做到的事，现在也能通过CDN、SDWAN等底层技术与上层应用结合来实现。

我们的目标是继续降低互联网数据移动的成本，尽可能利用已有的共享互联网络带宽，减少不必要的专线开销，减少不必要的缓存服务器开销。

疫情结束了，我们会抓紧时间提升互联网的数据传输效率。好好工作，只争朝夕，不负韶华。