拥塞控制

cisco 2811 Qos 一、某公司QoS策略配置实例 Current configuration : 3568 bytes ! ! version 12.2 service timestamps debug datetime service timestamps log datetime service password-encryption ! hostname xxxxxx ! enable secret 5 $1$uJPt$/Uh ! clock timezone China 8 ip subnet-zero no ip source-route ip cef ! ! ip name-server x.x.x.x ip name-server x.x.x.x ! no ip bootp server ! class-map match-any premium_class description For premium match protocol fasttrack match protocol http match protocol icmp match protocol napster match protocol netshow match protocol pcanywhere match protocol realaudio match protocol

一 基础 二 拥塞控制基本概念 三 排队算法：FIFO,FQ,WFQ 四 流量整形：漏桶、令牌桶算法 五 TCP拥塞控制机制（慢启动、拥塞避免、快速重传、快速恢复） 六 拥塞避免：ECN显式拥塞控制，RED随机早检测，TCP Veges ECN显式拥塞控制 TCP Veges RED随机早检测 DECbit 来源： CSDN 作者： 杀鸡要用屠龙刀 链接： https://blog.csdn.net/qq_40167046/article/details/103845124

QOS-QOS（服务质量）概述 2018年7月7日 20:29 概述及背景： 1. 引入： 传统IP网络仅提供“尽力而为”的传输服务，网络有可用资源就转发，资源不足时就丢弃 新一代IP网络承载了 语音、视频等实时互动信息，要求网络能提供有保证的服务质量 QOS允许用户在丢包、延迟、抖动和 带宽等方面获得可预期的服务水平 2.网络性能衡量的参数： 带宽： 是链路上单位时间所能通过的最大数据流量，其单位为bps 在一条端到端的链路中，最大 可用带宽等于路径上带宽最低的链路的带宽 延迟：是标识数据包穿越网络所用时间的指标 处理延迟 交换延迟：路由器查表时 排队延迟：数据包在出接口排队的延迟 传播延迟：数据在链路上传播的时间 抖动： 是指数据包穿越网络时延迟的变化，是衡量网络延迟稳定性的指标 是由于延迟的随机性造成的，主要原因是数据包排队延迟的不确定性 丢包率： 丢包是指数据包扎传输过程中的丢失，是衡量网络可靠性的重要指标 丢包的主要原因： 网络拥塞时，当队列满了后，后续的报文将由于无法入队而被丢弃 流量超过限制时，设备对其进行丢弃 丢包以丢包率作为衡量指标 丢包率=被丢包报文数量/全部报文数量 注意： 语音需要低带宽，低延时，低抖动的网络 数据流量需要高带宽，低丢包率的网络 视频流量需要高带宽，低延时，低抖动的网络 QOS不能参加先有的带宽，只能将现有的带宽优化。 3

cisco 2811 Qos 一、某公司QoS策略配置实例 Current configuration : 3568 bytes ! ! version 12.2 service timestamps debug datetime service timestamps log datetime service password-encryption ! hostname xxxxxx ! enable secret 5 $1$uJPt$/Uh ! clock timezone China 8 ip subnet-zero no ip source-route ip cef ! ! ip name-server x.x.x.x ip name-server x.x.x.x ! no ip bootp server ! class-map match-any premium_class description For premium match protocol fasttrack match protocol http match protocol icmp match protocol napster match protocol netshow match protocol pcanywhere match protocol realaudio match protocol

0.模型 模型是最根本的！ 我非常讨厌把所有的东西杂糅在一起，我比较喜欢各个击破，所以说，我最喜欢正交基！我希望把待观测的东西分解成毫无耦合的N个方面，然后各自研究其特性。这个思路我曾经无数次提出，但是几乎没人会听，因为一旦分解，你将看不到目标，看不到结果，拆了的东西并不定能再装起来...令人欣慰的是，TCP的BBR算法思路也是这样，不幸的是，TCP领域的顶级专家并没有N维拆解，人家只是拆解了2个维度。 带宽和RTT BandWidth & RTT 我很惊奇Yuchung Cheng(郑又中)和Neal Cardwell是怎么发现这个正交基的，为什么之前30年都没有人发现这个，最为惊奇的是，他们竟然对了！他们的模型基于下图展开： 这张图几乎完全描述了网络的行为！这就是网络传输的本质模型！之所以之前的Reno到CUBIC都是错的，是因为它们没有使用这个模型，我先来解释一下这个模型，然后再看看将Reno/CUBIC套在这个模型上之后，是多么的荒唐。 值得注意的是，这个模型是Kleinrock & Gale早在1981年就提出来的，然而直到现在才被证明是有效的。之前的年月里，人们面临着实现问题(同时测量问题，后面会讲)。因此我把这个模型最终的实现者作为模型的主语，即Yuchung Cheng和Neal Cardwell们的模型，这并不是说他们是模型的发明者。就类似牛顿的定律一样

先介绍拥塞控制的基本条件： 在某段时间，若对 网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏 ，这种情况叫做拥塞。在计算机网络中的链路容量（即带宽）、交换节点中的缓存和处理机等，都是网络资源 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。 好吧，一本正经果然不适合刚开始想学习的人。举个例子：交通十字路口是有红路灯的，如果没有按照大部分中国司机的习惯就是往死里挤，然后道路只有那么宽，车子拥挤的越来越多，自然交通就瘫痪了，这里可以理解为拥塞了。所以要保持道路畅通就需要控制，所以就有了红绿灯，也就是要进行拥塞控制。 再用个图解释下理想的拥塞控制是如何的： 输入负载：单位时间内输入网络的吞吐数量 吞吐量：单位时间内从网络输出的吞吐数量。 刚开始时，吞吐量等于网络输入的负载，所以曲线呈45度上升，随着网络输入负载的增多超过某一限度时。由于网络资源受限，吞吐量不再增长而保持水平线，也就是吞吐量达到饱和。同时也说明输入的负载有一部分丢失掉了（在分组的丢失使拥塞的预兆），例如输入到网络中的某些分组被某个节点丢弃了，虽然如此在理想的拥塞控制下，网络的吞吐量维持到可达到的最大值。 四种TCP拥塞控制算法：满开始算法、拥塞避免算法、快重传、快恢复。 下面介绍四种拥塞控制算法的基本原理，为了更好的理解拥塞控制算法的使用。假设如下条件： 1、数据是单方向传送

为了防止网络的拥塞现象，TCP提出了一系列的拥塞控制机制。最初由V. Jacobson在1988年的论文中提出的TCP的拥塞控制由“慢启动(Slow start)”和“拥塞避免(Congestion avoidance)”组成，后来TCP Reno版本中又针对性的加入了“快速重传(Fast retransmit)”、“快速恢复(Fast Recovery)”算法，再后来在TCP NewReno中又对“快速恢复”算法进行了改进，近些年又出现了选择性应答( selective acknowledgement,SACK)算法，还有其他方面的大大小小的改进，成为网络研究的一个热点。 TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制，在之前我们还讨论过TCP还有一个对端通告的接收窗口(rwnd)用于流量控制。窗口值的大小就代表能够发送出去的但还没有收到ACK的最大数据报文段，显然窗口越大那么数据发送的速度也就越快，但是也有越可能使得网络出现拥塞，如果窗口值为1，那么就简化为一个停等协议，每发送一个数据，都要等到对方的确认才能发送第二个数据包，显然数据传输效率低下。TCP的拥塞控制算法就是要在这两者之间权衡，选取最好的cwnd值，从而使得网络吞吐量最大化且不产生拥塞。 由于需要考虑拥塞控制和流量控制两个方面的内容，因此TCP的真正的发送窗口=min(rwnd, cwnd)

 [1]中关于耦合式的拥塞控制算法中， α \alpha α 的计算很是吓人。尝试推导。  为什么放着原有的TCP拥塞控制不用，非要提出一个耦合式的拥塞控制呢。耦合式的拥塞控制导致发送端的吞吐量小于两条路径分别采用拥塞控制的吞吐量。[1]里面有个解释,就是不作恶。 Goal 1 (Improve Throughput) A multipath flow should perform at least as well as a single path flow would on the best of the paths available to it. Goal 2 (Do no harm) A multipath flow should not take up more capacity from any of the resources shared by its different path than if it were a single flow using only one of these paths. This guarantees it will not unduly harm other flows. Goal 3 (Balance congestion) A multipath flow should move as much traffic as

TCP协议作为一个可靠的面向流的传输协议，其可靠性和流量控制由滑动窗口协议保证，而拥塞控制则由控制窗口结合一系列的控制算法实现。 一、滑动窗口协议 关于这部分自己不晓得怎么叙述才好，因为理解的部分更多，下面就用自己的理解来介绍下TCP的精髓：滑动窗口协议。 所谓滑动窗口协议，自己理解有两点：1. “窗口”对应的是一段可以被发送者发送的字节序列，其连续的范围称之为“窗口”；2. “滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的，方式就是按顺序“滑动”。在引入一个例子来说这个协议之前，我觉得很有必要先了解以下前提： -1. TCP协议的两端分别为发送者A和接收者B，由于是全双工协议，因此A和B应该分别维护着一个独立的发送缓冲区和接收缓冲区，由于对等性（A发B收和B发A收），我们以A发送B接收的情况作为例子； -2. 发送窗口是发送缓存中的一部分，是可以被TCP协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区； -3. 发送窗口中相关的有四个概念：已发送并收到确认的数据（不再发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之中）、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据； -4. 每次成功发送数据之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送； TCP建立连接的初始

一、TCP的流量控制 1.概述 所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。 如图所示，说明了利用可变窗口大小进行流量控制。设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长，序号的初始值为seq=1,图中的箭头上面大写ACK，表示首部中的却认为为ACK，小写ack表示确认字段的值。 接收方的主机B进行了三次流量控制。第一次把窗口设置为rwind=300，第二次减小到rwind=100最后减到rwind=0，即不允许发送方再发送过数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。 假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。 2