计算机网络体系结构整理-第四单元网络服务质量控制
第四单元 网络服务质量控制
一、流量管理
Qos定义：服务质量（是用来解决网络延迟和阻塞的技术）关于一个或多个对象的集体行为的一组质量要求。为不同的应用程序、用户或数据流提供不同的优先级，或者保证数据流有一定性能水平。
Qos的基本测度：带烤、延迟、丢包率、可用性、稳定性
服务级别约定SLA：1、服务质量（服务质量的集中体现，它决定着使用者的满意程度）2、服务级别约定是两个或两个以上的实体在谈判活动之后达成的正式协议，其范围包括评估每一部分的服务特点、责任及优先事项3、SLA设计Qos的部分称为Qos协议，包括两个实体之间商定的用于监视流量和规定Qos参数的部分
阻塞的概念：1、定义：网络或其一部分由于超载而引起的性能严重下降的现象称为阻塞 2、阻塞的原因是资源相对不足。过多的突发报文、系统处理能力不够、重传处理不当、路由不合理（路由策略不能使网络流量比较均匀）
阻塞控制的目的：避免全局同步，超过崖点的吞吐量急剧下降，网络负载小于knee时，网络能够及时处理到达的流量
拥塞的处理：1、拥塞控制（对已经发生的网络过载做出反应避免拥塞） 2、拥塞避免（过载前检测和预防）
拥塞控制与资源分配：网络的重要角色是将其传输资源分配给用户或应用
1、让网络来分配资源：分配资源很困难，可能浪费资源
2、让源发送它们想要的数据：在拥塞发生时从拥塞中恢复过来，易于实现可能丢失数据包
资源分配的基本方式：1、依据处理对象（主机/路由器） 2、依据分配的时间（传输开始前预留资源、传输过程中动态调整）3、依据使用策略（使用窗口机制、根据接收者处理能力确定传输路径的资源）
资源分配的评价标准：1、有效性 2、公平性
二、队列管理
队列管理机制：1、FIFO方法（有限队列长度，先来先服务，溢出丢弃，没有处理多种数据流的能力，健壮性依赖于用户的行为）2、优先队列（按优先级排队，处理代价高于FIFO，有处理不同数据流的能力，健壮性依然依赖于用户的行为）3、随机公平队列SFQ（散列函数映射，映射函数经常更换，有数据的队列称为活跃队列，各队列对贷款的分配由一个策略控制，不能限制长流对资源的多用，有处理不同的数据流的能力，有一定的鲁棒性）4、类别队列CBQ（将服务映射到队列，可以避免某种服务完全拒绝的情况，类似于优先队列）5、加权公平队列WFQ（以加权的方式给每个队列分配资源，可以用于区分不同的用户流，给一些队列更高的优先级，不适合在主干网中使用，流的权重变化后需要一个信令协议在网络中告知，计算开销大）
接纳控制：接纳控制是一个网络Qos过程，它决定了如何为具体不同需求的流分配带宽和延迟，通常以流为整体单位进行整体调节
DEC-bit 基于反馈的拥塞控制机制（基本思想：在拥塞时路由器在包上设置一个位、在确认中接受端发送的中继位，发送端使用反馈来调整发送速率）关键问题：路由器反馈策略（路由器何时，如何发送反馈）来源：信号过滤，发送方如何相应
流量的监管与整形：1、流量监管：流量的准入约束 2、流量整形：利用队列换成平滑突发流量 3、Token Bucket算法
为何选择主动队列管理？
•锁定延时问题-drop-tail允许一些流独占队列空间，锁定其他流（由于同步）
•完整的队列问题-drop tail可能在拥塞期间保持完整或接近完整的队列
Lock-out问题的解决：1、随机丢弃 2、丢弃前面的 3、丢弃不合适的
Full Queues问题的解决：1、在队列变满之前丢弃数据包（早期丢弃）2、直觉：通知发送者早期拥塞
随机早期检测：是在缓冲超过一定的阈值之后对每个流按不同的概率丢弃一个报文，由于这种丢弃不是同时发生的，从而在放慢速率的同时使引起的波动最小。避免大数据流长时间抢占小数据流的队列空间。平均队列长度（就是刚刚的阈值）
随机早期检测的基本性质：1、处理代价比FIFO略高2、送的越多被丢弃的就越多，所以平均来看对每个流是公平的3、对于TCP这样的适应流RED比FIFO鲁棒4、多样性与FIFO同
WRED：使用两组阈值，并根据平均队列长度将路由器的拥塞状态分为5个阶段，报文按是否超过指定带宽分为In 和Out两种状态（优先级）
无拥塞阶段Qavg<minout 路由器无拥塞
拥塞敏感阶段minout<avg<maxout 开始丢弃Out报文
拥塞容忍阶段maxout<avg<minin 所有的Out报文都被丢弃
拥塞警报阶段minin<avg<maxin 开始丢弃In报文
拥塞控制阶段maxin<avg 丢弃所有报文
WRED的特点：基本性质与RED相似，但比RED控制做的更细致，拥塞敏感阶段和拥塞容忍阶段是WRED的理想工作状态，资源利用率高且SLA可以满足，而无阻阶段的资源利用率可能较低In Out可以进一步分成Green、Yellow和Red以区分保证带宽、竞争带宽和超出部分带宽
CHOKE：
将新数据包与队列中的随机数据包进行比较
如果来自同一流程，全丢弃。如果不是，使用RED来决定新数据包的命运
这种方法可以寻找占用资源较多的流，它们被同时取中两个或以上报文的概率要大于较小的流。这种方法针对恶意流，因此每到达一个，就丢掉两个 (或更多)，使其数量在队列中逐渐减少。
三、TCP的拥塞控制
主机中的阻塞控制：
线性控制模型：Xi（t + 1）= ai + bi Xi（t）
•配方允许反馈信号：
- 加法增加/减少（通过改变ai）
- 乘法增加/减少（通过改变bi）
•四种组合中哪一种最佳？
基于滑动窗口的拥塞控制：接收方的通告窗口（rwnd）发送方的拥塞窗口（cwnd）
TCP中的拥塞控制：网络报文守恒原则（在均衡时，仅在移除一个数据包时将数据包注入网络中）、非均衡调节（加法增加乘法减少）、异常预测（三次握手）
TCP的Delayed ACK延迟确认机制：接收端收到了第2个数据报文后发送ACK报文，超过了Delayed ACK的超时阀值，改为对每个收到的报文发送ACK
Nagle算法：面向虚拟终端类应用，TCP连接上最多只能有一个未被确认的小分组，在该分组的确认到达之前不能发送其他的小分组。
TCP协议中的阻塞控制机制：基本术语（段：任意的TCP报文，SMSS：发送方最大段长，RMSS：接收方最大段长，全长段：数据长度为SMSS的报文，rwnd：接收窗口，实际的接收端缓冲长度，cwnd：阻塞窗口 发送数据的顺序号 ≤ 最大的应答顺序号 ＋ min {cwnd, rwnd}）
慢启动与阻塞避免：主机在发送了一个报文后就要停下来等待应答。每收到一个应答，cwnd的值就增加一段的长度，直至cwnd的值等于ssthresh的值。慢启动期间cwnd的增长将随RTT呈指数级增长。当 cwnd的值大于等于ssthresh的值时，使用阻塞避免，其目的是试探网络是否还有更多的容量可供使用。加法递增的方式来递增cwnd
快速重发和快速恢复：快速重发算法要求发送方在收到3个相同的重复应答之后立即启动重发，而不必等待重发计时器超时，快恢复是置为ssthresh。
高速信道的问题：提高发送速率：RTT尽量小，cwnd尽量大
Binary Increase Congestion control：为Linux默认的拥塞控制算法
CUBIC：使用一个3次函数来确定拥塞窗口的大小，且与RTT无关
基于拥塞的拥塞控制：
bbr算法实际上非常简单，在实现上它由5部分组成：
1.即时速率的计算：在bbr运行过程中，系统会跟踪当前为止最大的即时带宽
2.RTT的跟踪：在bbr运行过程中，系统会跟踪当前为止最小RTT
3.bbr pipe状态机的维持：根据网的拥塞行为有针对性地定义了4中状态（STARTUP，DRAIN，PROBE_BW，PROBE_RTT）bbr通过对上述计算的即时带宽bw以及rtt的持续观察，在这4个状态之间自由切换
4.结果输出-pacing rate和cwnd：bbr的输出并不仅仅是一个cwnd，更重要的是pacing rate
在传统意义上，cwnd是TCP拥塞控制算法的唯一输出，但是它仅仅规定了当前的TCP最多可以发送多少数据，它并没有规定怎么把这么多数据发出去。pacing rate规定cwnd指示的一窗数据的数据包之间，以多大的时间间隔发送出去。
5.其它外部机制的利用-fq，rack等：很多机制并不是它本身实现的，而是利用了外部的已有机制
1.即时带宽的计算
bbr作为一个纯粹的拥塞控制算法，完全忽略了系统层面的TCP状态，计算带宽时它仅仅需要两个值就够了：1).应答了多少数据，记为delivered；2).应答1)中的delivered这么多数据所用的时间，记为interval_us。将上述二者相除，就能得到带宽：bw = delivered/interval_us
2.状态机：不断地基于当前带宽以及当前的增益系数计算pacing rate以及cwnd，以此2个结果作为拥塞控制算法的输出，在TCP连接的持续过程中，每收到一个ACK，都会计算即时的带宽，然后将结果反馈给bbr的pipe状态机，不断地调节增益系数，这就是bbr的全部
BDP表示了单位时间通过能力与通过所需要的时间之积，这就是在途的数据数量，即inflight
BltBw是瓶颈带宽
RTprop是报文在不排队的条件下从发送端到达接收端的时间（单向时延）
App-limited：inflight小于可用带宽，因此在RTT的约束下受应用发送数据能力的限制；
Bandwidth-limited：可用带宽开始受RTT限制，然后受瓶颈带宽限制，最终受瓶颈缓存大小的限制；报文在瓶颈节点排队的条件是inflight >BDP
RTT (blue), Inflight (green) 和Delivery rate (RED) 的关系：
RTprop：光信号从A端到B端的最小时延，BtlBw：在A到B的链路中，它的带宽取决于最慢的那段链路的带宽，称为瓶颈带宽。前者随路由改变而变化，但带宽无变化；后者随某跳流量的带宽改变而改变，但路由无变化。报文没有排队时可以测量RTprop，否则只能测量瓶颈带宽；pacing_gain来调节RTT、Inflight和交付速率等参数
pacing_gain：控制相对于BtlBw的报文发送速率。pacing_gain > 1时增加inflight，减少报文的inter-arrival time；
BBR使用pacing_gain序列来实现一个顺序探测状态机，以寻找更高的带宽。BBR需要进行周期性的测试，加快报文发送以检测瓶颈带宽是否增加；放慢报文发送以检测RTprop是否下降。
BBR的Startup状态
BBR对于Startup、Drain、ProbBW等不同的状态使用单一算法进行发送控制。
BBR在Startup状态对BtlBw进行快速发现，设定gain = 2/ln2，如果交付速率增加则每周期发送速率加倍；BBR检测BtlBw值的平稳性，以判断是否通路满；一旦通路满，cwnd_gain将队长限制为 (cwnd_gain - 1) x BDP如果连续三轮发送的反馈显示瓶颈带宽的增加小于25%，则BBR认定瓶颈带宽已经稳定，则离开Startup状态，进入Drain状态。
BBR的Drain状态
BBR将pacing_gain置为Startup状态时值的倒数，通过减少inflight（已经从A发出但未被B收到的数据）来消除队列
当inflight与估计的BDP匹配时，BBR认为队列已经消除但通路仍然是满的，这时BBR离开Drain状态，进入ProbeBW
BBR的稳定状态
BBR的稳定状态分为ProbeBW (98%)和ProbeRTT (2%)BBR的流处于ProbeBW状态时，使用gain cycling方法进行带宽测试，以试图提高瓶颈带宽
如果BBR处于其它状态且RTProp超过10秒没有降低，则进入ProbeRTT状态。此时，将CWND降为4个报文长，并维持这个infight超过一个RTT (至少200nm)，然后BBR视对队列的估计情况进入Startup或ProbeBW状态。
流的公平性控制
ProbeBW阶段使用gain循环来使大流快速向小流让出带宽，导致各个流可在几个循环周期内获得带宽公平。
流的稳定性控制
为增加算法的鲁棒性，减少网络突发流量或路由改变事件的干扰，BBR将cwnd_gain x BDP设为当前CWND的上限，限制过多报文的发送。如果遇到重发超时，则发送方认为所有的inflight 报文丢失。这时BBR将CWND降为1，与CUBIC处理方法一致。
BBR vs. CUBIC：BBR的Startup与CUBIC的slow start相比，前者不受丢包或时延增加的影响。BBR是平滑地连续发送报文，而CUBIC是断续式发送，受Ack报文的限制。BBR比CUBIC更加保守，发现产生排队就限速，而不是等丢包了再限速。
Google的B4中BBR：Google用来互联其数据中心的基于SDN的广域网
TCP的阻塞控制分为两类：基于时延(BBR为代表)和基于丢包(CUBIC为代表) 。
BBR已经在固网和移动环境中表明比CUBIC有更好的传输效率
四、全局控制模型
IntServ集成服务：面向传输路径，引入了虚拟连接的概念。带宽资源必须经过显示的分配和管理才能满足应用的服务质量需要：所以有资源预留和准入控制。
资源预留保证在一条路上，准入控制：资源还有允许进入token相当于资源量，token用光了就不允许进入了。
通信一般从功能的角度可以分为两大类：有时延要求（视频通信）、无时延要求
基于流：端到端的质量服务保证RSVP（带宽时延抖动有量化规定）、基于相关状态：可控负载型服务（负载不会超过token）
工作机制：1、网络为每个数据流进行带宽资源预留，网络节点可以因为资源不足而拒绝服务，但如果承担服务，则要保存其状态信息并预留资源。2、主机在想网络发送数据流前，使用RSVP信令向网络提交数据流规范。数据流传输路径中的节点根据自己的当前资源状态决定是否接纳这个请求，如果接纳则应该建立相应的状态信息。3、主机和路由器节点一直保持已经建立的数据流状态信息，以保证该流的每个报文都得到保证的Qos服务，知道该数据流结束时才清楚相应的状态信息4、IntServ使用接纳控制器决定是否接受一个资源预留的请求，使用分类器来区别不同的数据流的报文，使用报文调度器来管理各个数据队列的报文发送。
RSVP连接管理协议：所有网络连接中建立的连接基本上都是RSVP：通常按服务级别调度，类似于一个月钱看一个月电视，用户服务请求这个级别和微观不同。
RSVP分为控制平面 RSVP交付过程资源够不够是不是可以建立，信令平面：根据资源状态，当前还可以调动的资源数量，数据平面：各走各的路，每个不同的RSVp路径对应不同的传输通路
IntServ有可扩展性问题，很艰难维持这么多的队列，比如查500k的指针表，太大的数据。
因为RSVP要求设备都支持所以向下兼容性也不好
区分服务（DiffServ）：主流类型是DiffServ每个点都只管自己，基本概念：通过服务类别体现网络服务质量的差别，将用户流按服务类别聚类，以降低管理开销
区分服务是一种面向大规模网络的Class of Service机制，用户数据可以在进入网络之前提v胡自己的传输质量要求。用户类别不同优先级，资源调度时不同待遇。
区分服务的体系结构：报文在网络的边界点确定服务类别，内部节点按类别进行调度转发，流状态信息的保存与流监控机制的实现只在边界节点进行，内部节点的状态是无关的。
内部节点的转发处理基于可配置的标准化的报文逐条行为，称为PHB。
不影响路由：区分服务节点提供的服务手段仅限于队列调度和缓冲管理，不涉及路由选择机制。与路由无关只决定谁先走。
区分服务体系结构也是分层的：分为DS domain（管理者）和DS region（不同子网）
换个管理者之后，金牌银牌可能不一样，所以需要打通，是加钱换金牌，还是降级成银牌
标准化PHB：1、缺省型BE：提供best effort服务2、加速型EF：保证最低带宽3、确保型AF：基本带宽 4类选择型CS：类别选择器，不同的数据进入不同的队列。
现实之间大家都是抢带宽最后塞死：如何让网络传输最大化，解决方法：使用市场机制，多用就多花钱，资源调度很多体验都是动态的，令牌拍卖，动态调节。
Emule的信用系统：你为别人穿的多，别人为你传的多（信用机制）
