拥塞避免和拥塞管理(4)

目录

拥塞避免全局概念

限速当中的两个技术流量监管和流量整形并不能完全保证不会出现拥塞，一旦出现了拥塞，那就得依靠拥塞技术来解决

image-20230329161229575

image-20230329161238850

如上图所示，当流量超出了接口可以容纳的极限时，接口就会出现拥塞，其原因一般是带宽不匹配或接口汇聚造成的。

面对拥塞有两个技术可以采用：

  1. 拥塞避免
  2. 拥塞管理

拥塞避免就是通过这种技术尽量让流量不拥塞，在拥塞发生之前，而拥塞管理技术是是在拥塞之后，如何让通过管理流量使得情况变得没有那糟糕。

拥塞避免

拥塞避免是通过监视内存或缓存队列里面的内容，在马上将要把内存打满或是在拥塞加剧的时候，提前主动丢弃报文，让队列空闲下来，这与公司裁员很像，在公司没有倒闭之前先裁员，总比公司倒闭了之后宣布破产让大家都失业要好。

要丢弃哪些地内容也是比较有讲究的，大概有三种方法：

  1. 尾部丢弃，达到阈值之后，从后向前进行丢弃，尾部丢弃这一个很好理解，看运气，谁排在最后面，没办法赶上了，丢弃。
  2. RED（随机丢弃），就像灭霸一样，随机让一些要消失，还是比较公平的
  3. WRED（基于权重的丢弃），这就不公平了，选择一些高素质人才，把没用的人丢弃，我们这个社会大致就是这个运行方式。

尾部丢弃的问题比较严重，因为一旦把TCP的ACK包丢弃了，那发送端的PC会认为自己向目标设备发送的数据没有收到，发送端PC会认为是自己发的太快了，中间的链路状态也不佳，途中的链路拥塞导致丢包，那根据TCP协议栈的规定，接下来将TCP的滑动窗口的size减小，整体的流量也开始减少，那当整体流量减少网络不再拥塞时，双方又都能收到确认的报文，认为网络不再拥塞了，进入到慢启动过程，然后慢启动又过渡到高速转发，然后再拥塞，再慢启动，周而复始，这样过程叫TCP的全局同步，其实就是双方都会受到影响。

其实像尾部丢弃这种问题，其实比较严重的，因为它不分青红皂白，丢弃哪个报文全看运气，也不做区分 ，所以又有了另一种丢弃方法叫随机丢弃（RED，random early detection），其实就是不按着尾部一直薅羊毛，当队伍快要拥塞时，大家都有责任，谁也没跑，咱随机的丢弃，这样比较公平一些，就像灭霸解决资源枯竭的思路是一样的，随机干掉一些人。这种方式也会导致TCP的全局同步，只不过没有那么严重。

我们再看，其实随机丢弃也不是很科学，最好是把一些关键业务的特权优先级提高，非关键性业务也有优先级，只不过优先级并不高，所以当拥塞的时候会尽量少丢弃优先级高的，但是不是一点都不丢弃。这种是比较优秀的解决方案，特别像人民代表大会，会有三个农民代表，表示国家没有忘记农民，但是，除了这三个之外全都是非农民代表，这种方式叫WRED（weithted random early detection）加权随机先期检测。

拥塞管理

image-20230329161248047

不能百分百保证不拥塞，拥塞管理了就是拥塞了之后进行拥塞管理，让情况变得没那么糟糕。

拥塞管理技术其实实现的原理比较简单，使用队列技术，就是将数据报文进行成不同的队伍，有的队伍优先进行转发，比如说高铁站内的VIP通道，VIP的队列总是优先通过。默认有8个下行队列，队列也称为CQ（class queue），也称为端口队列（port-queue），如下所示，就这是8个队列：

  1. BE
  2. AF1
  3. AF3
  4. AF4
  5. EF
  6. CS6
  7. CS7

值得一提的是你看这几个队列的名字其实与DSCP非常相似，但并不是一回事儿，这一点需要注意。另外一点，注意查看上图当中队列的位置，是在CAR和Remark处理完成之后。

注意，这8个队列本身并没有任何算法，并没有任何优先转发、确认转发之类的含义，至于它到底有什么含义取决于将它放置于哪个组，组本身带有算法，有优先转发之类的属性，你把它放到哪个组，它就自动拥有了哪个组的属性。

既然有8个队列那哪个队列比较优先呢？其实这具是根据组来看的， 不同的组有不同的算法，大概分为这三个组，优先级从上到下分别是：

  1. PQ：使用SP调度算法，严格优先级
  2. WFQ：使用WFQ调度算法，加权公平队列
  3. LPQ：使用SP调度算法,严格优先级

当遇到拥塞的时候，先转发PQ队列当中的，接着是WFQ，最后是LPQ。

我们再来看一下几种算法：

  1. 先进先出：FIFO
  2. SP：严格优先级
  3. 加权公平队列WFQ

先进先出是绝对公平，当是没办法保证关键性业务，严格优先级就是对业务进行不同的优先级划分，拥塞的时候优先转发优先级高的，但这样有一个问题，问题就是如果一直有关键性业务，那非关键性业务的数据就一直得不到转发，这也是非常不合理的，所以又有了WFQ这种加权公平队列，就是给关键业务高权，给普通业务低权，在拥塞的时候肯定还是对关键性的业务转发多一些，但是还是会照顾到非关键性业务，不会导致非关键性的业务一点也得不到转发。

小实验

image-20230329161257522

# 匹配流量
# 从这个地方就可以看出来这已经是简单匹配了，直接就开始匹配DSCP里面的值了
[AR2]traffic classifier EF
[AR2-classifier-EF]if-match dscp ef
[AR2]traffic classifier AF1.
[AR2-classifier-AF1]if-match dscp af11

# 新建队列,确定最小带宽
[AR2]traffic behavior EF
[AR2-behavior-EF]queue ef bandwidth 1000
[AR2]traffic behavior AF
[AR2-behavior-AF]queue af bandwidth 2000
# 剩下的流量走WFQ
[AR2]traffic behavior WFQ
[AR2-behavior-WFQ]que	
[AR2-behavior-WFQ]queue ?
  af   Specify AF (Assured Forwarding) service  # 注意这里面的AF指的是队列
  ef   Specify EF (Expedited Forwarding) service
  llq  Specify LLQ (Low-latency) service
  wfq  Specify flow-based WFQ for BE (Best-Effort) traffic
[AR2-behavior-WFQ]queue wfq

# 策略
[AR2]traffic policy CBQ
[AR2-trafficpolicy-CBQ]classifier EF behavior EF
[AR2-trafficpolicy-CBQ]classifier AF1 behavior AF
[AR2-trafficpolicy-CBQ]classifier default-class behavior WFQ

# 应用出接口
[AR2]int s1/0/0
[AR2-Serial1/0/0]traffic-policy CBQ outbound

[AR2]dis traffic policy ?
  statistics    Statistic
  user-defined  Defined by user 
[AR2]dis traffic policy de	
[AR2]dis traffic policy user	
[AR2]dis traffic policy user-defined 
  User Defined Traffic Policy Information:
  Policy: CBQ
   Classifier: EF
    Operator: OR
     Behavior: EF
      Expedited Forwarding:
        Bandwidth 1000 (Kbps) CBS 25000 (Bytes)
        Queue Length: 64 (Packets) 131072 (Bytes)

   Classifier: AF1
    Operator: OR
     Behavior: AF
      Assured Forwarding:
        Bandwidth 2000 (Kbps)
        Drop Method: Tail
        Queue Length: 64 (Packets) 131072 (Bytes)

   Classifier: default-class
    Operator: AND
     Behavior: WFQ
      Flow based Weighted Fair Queueing:
        Max number of hashed queues: 1
         Drop Method: Tail 
         Queue Length: 64 (Packets) 131072 (Bytes)

在“拥塞管理配置实验“当中，整体过程是：通过MQC配置时就是先通过DSCP匹配住想要流量；然后通过behavior建立行为，行为里面通过queue给它分配一个队列，我看老师经常用的队列是af和ef；再然后就在通过策略将前面两步捆绑上；最后在接口应用。这个过程当中也没有将某个队列放到某个组，比如说将ef队列放到PQ组这个过程呀，我理解的是得把队列放到某个组，比如说PQ组它才会按照这个组关联到的算法才能生效呀，是我理解的不对吗？

其实情况是这样的：MQC的流分类提供了三种队列，确保转发队列AF、加速转发EF、尽力转发BE”，难道在MQC当中af不再是普通队列了？是已经成功加入了组里面并且已经拥有属性的的队列了？是这样的，到这里面，队列就成了拥有组并且拥有组所携带的属性的队列了，也被称为“真实队列”了。

HQOS

在企业网里面只有一个用户，根据业务分8个队列足够，但是在小区这种多租户的环境下8个队列肯定不够的，怎么办？HQOS能够实现多级队列层次化的调度，不仅区分了用户，也区分了业务，实现了QOS的精细化管理。如果SD-WAN也是多租户环境，可能也需要采用这种多租户的技术。

所谓的多层次化其实很简单，做两套方案，一套方案专门用于租户，用以区分同一个租户下不同的业务，比如说语音、视频；然后我们再通过MQOC做一套方案，这套方案作用于连接多租户的物理接口，最终再把第一套方案和第二套方案嵌套在一起。第一套方案的作用点是每个用户，第二个方案的作用点是整个物理接口，两个方案一嵌套就成了HQOS；

  • 物理接口QOS
    • 用户QOS
      • 语音
      • 视频
    • 用户QOS
      • 语音
      • 视频

那物理接口在向外发送数据时候，将一个用户QOS看做是一个单位，采取轮询的方法。

posted @ 2019-11-15 19:32  张贺贺呀  阅读(713)  评论(0)  编辑  收藏  举报