网络传输中的重要参数-时延与丢包率
目前从事于音视频流媒体领域的我，主要工作在传输层与应用层的交界处，研究如何针对流媒体场景实现高效而可靠的传输协议。工作两年比较深刻的体会之一就是网络传输是个看似简单清晰实则到处是坑的领域，本系列将首先对网络传输中重要的几个参数进行梳理，讨论各个参数的实际意义，以及各自常见的获取方式。
理想的传输链路
在上层将需要传输的数据划分为一个个小于MTU的数据包Packet后，在理想的传输链路中，发送端即按照上层Packet交付的顺序，通过socket将数据按序交付给接收端。整个数据交付流程没有延迟，没有丢失，完全按序。
谁又不想拥有这样完美的传输体验呢？但现实往往比理想残酷一些，在实际场景中，还有很多因素会影响传输体验。其实这些因素是显而易见且易于理解的，只是这里进行一下简单的归纳与总结。
时延与RTT
无论在哪里，主机之间的数据传输都是通过下层各种各样的物理数据链路实现的，基站、交换机与网桥等设备将一个个独立的数据链路们相连，打通互联网的每一个角落。既然信号在网络中进行物理传输，那自然需要时间，即端到端时延。为了明确端到端时延的概念，这里首先需要明确几个参数，首先是传播时延与传输时延。
传播时延：是指电磁信号或光信号在传输介质中传播一定的距离所花费的时间，即从发送端发送数据开始，到接收端收到数据（或者从接收端发送确认帧，到发送端收到确认帧），总共经历的时间。
传输时延：是指结点在发送数据时使数据块从结点进入到传输媒体所需的时间，即一个站点从开始发送数据帧到数据帧发送完毕（或者是接收站点接收一个数据帧的全部时间）所需要的全部时间。
通俗点解释，传播时延是信号在物理介质内传播的时延，比如对于一个电磁波信号，在10km的距离传输1bit所需要的时间为10km/c，c即为光速，对应该时间也就是传播时延。传输时延则为设备将一个Packet所有的bit推入网络所需要的时间（收端则为接收需要的时间），这个时长不受限于传输介质，而更受限于具体的设备性能。除了传播时延与传输时延之外，端到端的传输还需要经历端上设备以及传输路径中各个节点的处理时延和排队时延。
处理时延：即设备检查分组（这里只分组交换中的分组，简单理解也可以当做Packet）的首部，差错验证等需要的时间。
排队时延：为数据在端上缓冲中等待被处理的时间。
处理时延相对容易理解，至于排队时延，举个简单的例子，假设发端的发送速率\(v_{send}\)大于接收端的处理速率\(v_{recv}\)，那么收端便会由于处理不过来到达的而外数据而将这些数据临时缓存起来处理，Packet在缓存中等待的时间即为排队时延，如果缓存为0，排队时延也自然为0，如果缓存很大，排队时延也会跟随着增长，如果缓存已满，则会发生丢包。
综上，传播时延、传输时延、处理时延以及排队时延共同组成了端到端时延，即数据（分组或Packet）从发送端到接收端总花费的时间。
除了端到端时延之外，另外一个重要（也许更重要）的与时间相关的指标为RTT（Round-trip delay time，RTT），即往返时间/来回通信延迟，参考维基百科的定义：“在双方通信中，发讯方的信号（Signal）传播（Propagation）到收讯方的时间，加上收讯方回传消息到发讯方的时间”，可以简单理解为发端到收端的端到端时延+收端到发端的端到端时延，由于现在基本所有的传输场景都支持双向通信，且为了支持可靠传输，发端需要收端的反馈以确认数据是否成功到达，发送+反馈这样一来一回的机制让RTT参数在可靠传输协议的设计中占据重要的地位。在丢包恢复（ARQ）与流控（CC）等领域，RTT也起着重要作用，坑先挖好，日后再谈。
计算方法
常见的RTT获取方法依赖于ACK确认机制，即收端接受到数据包后，会像发端回复一个ACK告知该数据包已经被成功接受，ACK的内容一般是数据包的序号Seq，具体跟随使用的传输协议而定。在发端收到ACK后，便能够根据数据包发送的时间与ACK接收的时间对RTT进行采样与估计，假设数据包的Seq为k即有RTT采样值为
这里\(t_{recvAck}^k\)为该包收到ACK的时间，\(t_{send}^k\)为该包发送的时间，\(ACKdelay^k\)为收端的处理时延，即接收到包到发送ACK的时间。在获取采样值之后，我们便可以利用各种各样的滤波方法对RTT值进行预测估计了，比较常用的是指数加权移动平均法EWMA（TCP使用的方案），计算复杂度低，易于实现，效果也不错，这里不再展开，贴个链接：https://www.cnblogs.com/keye/p/14958351.html。
丢包率
上学的时候我们的教材是经典的《计算机网络-自顶向下方法》，我记着原文写的“如果将网络传输领域最重要的10个问题拿出来，可靠传输是第一位的有力候选者”（肯定有出入，懒得回去验证了），为什么可靠传输这么重要，因为他能够保证传输层之上各个应用的正常工作，为用户正常的互联网产品体验提供保障。为什么可靠传输这么困难，因为它面向的是底层未知的传输链路，面对随时可能发生的各种情况导致的丢包。
丢包的种类有很多，根据数据链路的不同发生的形式也不同，在共享介质的网络里可能会发生多个终端间的冲突（感兴趣的可以了解下CSMA相关的协议），在非共享介质下也可能由于链路中节点的处理错误或是上面提到的缓存已满而导致的丢包。anyway，对于发端而言，相对可以简单的把丢包分为两类：随机丢包和拥塞丢包，拥塞丢包即为在链路拥塞，收端缓存满时候，新到达的数据包由于无处缓存而被丢失导致的丢包，随机丢包即除了拥塞丢包之外的其他（手动狗头）。
计算方法
发端能够准确的识别丢包类型与丢包强度对于发端高效利用带宽有着重要的意义，这里先不对如何利用进行展开，主要关注丢包强度，一般我们使用丢包率lossRate来描述这一特性，丢包率的定义为“传输中所丢失数据包数量占所发送数据组的比率”，理解起来比较简单直白，即一段时间内，记发端发送的包数个数为n，其中收到ACK的个数为m，\(\frac{n-m}{m}\)即为简单的丢包率估计，需要注意的是对于那些刚刚发送的包，一般不纳入统计，因为这些包可能未发生丢包，只是还没有收到ACK。上一节提到，包往返的时间是RTT，或许取now-RTT直接的一段时间进行丢包率的采样是更好的选择。采样伴随着误差，在得到丢包率的采样后，不同的策略也同样可以通过滤波手段进一步估计网络中实际的丢包表现，进一步决定策略的调整与适配。
小结
本文简单梳理了网络传输中RTT与丢包率两个参数的定义（物理意义）与常见的获取收端，在人均百兆带宽的今天，丢包率和RTT就能够很大程度上对网络画像进行有效的描述，后续的ARQ与CC等可靠传输策略也离不开对于这两个参数的理解与应用。
本文来自博客园，转载请注明原文链接：https://www.cnblogs.com/mapleumr/p/17464980.html
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文连接，否则保留追究法律责任的权利。