TC

Traffic Control
TC 框架可以理解为一个控发不控收的框架，在 ingress 的位置只能做简单的控制，且不能有其他子项。如想对 ingress 进行控制请参考 IMQ 以及 ifb。

流控方式

SHAPING：限流，平滑激增流量使得网络更加稳定。只适用于出口的流量。
SCHEDULING：调度，管理类数据包传输，按优先级分配带宽。只适用于出口流量。
POLICING ：策略，用于入口流量。
DROPPING ：丢弃，超过带宽的流量，可以用于入口和出口流量。

处理这几种方式的方法有三种 qdiscs、classes、filters。

QDISCS

Queueing Discipline，内核如果需要通过某个网络接口发送数据包，它都需要按照为这个接口配置的 qdisc (排队规则)把数据包加入队列。内核会尽可能多地从qdisc里面取出数据包，把它们交给网络适配器驱动模块。

CLASSES

某些QDisc(排队规则)可以包含一些类别，不同的类别中可以包含更深入的QDisc(排队规则)，通过这些细分的QDisc还可以为进入的队列的数据包排队。通过设置各种类别数据包的离队次序，QDisc可以为设置网络数据流量的优先级。

FILTERS

Filters 用来为 classful qdiscs 去判定如何进行分类排序。当数据包进入一个包含子类的类别中的时候就需要分类，filters 就是其中一种分类的方式。再一个有一个具体的结果被分类器挑选出来之前，所有的 filters 将被尝试的去调用。如果最终也没有返回结果，那么可能需要除了 filters 之外其他的分类方式。Filters 是 qdiscs 内部的方法，不能作为一个主体自己单独使用。

Qdiscs 的类别

Classeless Qdiscs

choke ：CHOKe (CHOose and Keep for responsive flow, CHOose and Kill for responsive flows)
[p|b]fifo : 最简单的先入先出队列，限制入口流量。
fq ：Fair Queueing 公平调度算法。
red ： red是Random Early Detection(随机早期探测)的简写。如果使用这种QDISC，当带宽的占用接近于规定的带宽时，系统会随机地丢弃一些数据包。它非常适合高带宽应用。
sfq ： sfq是Stochastic Fairness Queueing的简写。它按照会话(session–对应于每个TCP连接或者UDP流)为流量进行排序，然后循环发送每个会话的数据包。
tbf ： tbf是Token Bucket Filter的简写，适合于把流速降低到某个值。
pfifo_fast ：在编译内核时，如果打开了高级路由器(Advanced Router)编译选项，pfifo_fast就是系统的标准QDISC。它的队列包括三个波段(band)。在每个波段里面，使用先进先出规则。而三个波段(band)的优先级也不相同，band 0的优先级最高，band 2的最低。如果band0里面有数据包，系统就不会处理band 1里面的数据包，band 1和band 2之间也是一样。数据包是按照服务类型(Type of Service,TOS)被分配多三个波段(band)里面的。

还有一大堆可以使用的方式可以使用，可以参看一下 man page。

Classes Qdiscs

CBQ ： CBQ是Class Based Queueing(基于类别排队)的缩写。它实现了一个丰富的连接共享类别结构，既有限制(shaping)带宽的能力，也具有带宽优先级管理的能力。带宽限制是通过计算连接的空闲时间完成的。空闲时间的计算标准是数据包离队事件的频率和下层连接(数据链路层)的带宽。
HTB ： HTB是Hierarchy Token Bucket的缩写。通过在实践基础上的改进，它实现了一个丰富的连接共享类别体系。使用HTB可以很容易地保证每个类别的带宽，它也允许特定的类可以突破带宽上限，占用别的类的带宽。HTB可以通过TBF(Token Bucket Filter)实现带宽限制，也能够划分类别的优先级
PRIO ： PRIO QDisc不能限制带宽，因为属于不同类别的数据包是顺序离队的。使用PRIO QDisc可以很容易对流量进行优先级管理，只有属于高优先级类别的数据包全部发送完毕，才会发送属于低优先级类别的数据包。为了方便管理，需要使用iptables或者ipchains处理数据包的服务类型(Type Of Service,ToS)。

还有一大堆可以使用的方式可以使用，可以参看一下 man page，里面有各个方式的详细说明以及算法原理。

TC 结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5IhLj5k1-1624007281392)(E:\KEDA工作\图片\TC-struct.png)]

整个 TC 是一个树型的结构，每一个 qdisc 可以有很多不同的 class 但是注意每一个 class 只能有一个 qdisc。这样就是以针对已经被分类的数据流量进行进一步的分类。

TC内核结构

          Userspace programs^|+---------------+-----------------------------------------+|               Y                                         ||    -------> IP Stack                                    ||   |              |                                      ||   |              Y                                      ||   |              Y                                      ||   ^              |                                      ||   |  / ----------> Forwarding ->                        ||   ^ /                           |                       ||   |/                            Y                       ||   |                             |                       ||   ^                             Y          /-qdisc1-\   ||   |                            Egress     /--qdisc2--\  |--->->Ingress                       Classifier ---qdisc3---- | ->|   Qdisc                                   \__qdisc4__/  ||                                            \-qdiscN_/   ||                                                         |+----------------------------------------------------------+

实例

tc qdisc add dev eth0 root handle 1:0 cbq2 bandwidth Kbit avpkt 1 cell 8

使用 CBQ 方法管理队列

bandwidth: 实际带宽

avpkt : 包平均大小

cell ：计算传输时间的细粒度(granularity)

tc class add dev eth0 parent 1:0 classid 1:1 cbq2 bandwidth Kbit rate Kibit weight Kbit allot 1514 cell 8 maxburst 20 minburst 10 avpkt 1 bounded"

rate : 实际带宽

weight ： “weight”参数控制WRR过程。每个类都轮流取得发包的机会。如果其中一个类要求的带宽显著地高于其他的类，就应该让它每次比其他的类发送更多的数据（以字节为单位，可以理解为偏袒数量，例如weight 200Kbit就相当于每次处理优先级的数据比普通数据多处理200Kbit）。CBQ会把一个类下面所有的weight值加起来后归一化，所以数值可以任意定，只要保持比例合适就可以。人们常把“速率/10”作为参数的值来使用，实际工作得很好。归一化值后的值乘以“allot”参数后，决定了每次传输多少数据。

allot ：最大报文长度（带 MAC 头部）

参考资料

关于tc作用在入口(ingress)和出口(egress)效果的调研

Linux Advanced Routing & Traffic Control HOWTO

Linux TC的ifb原理以及ingress流控-转

Linux TC 带宽管理队列规则

tc命令详解及限速功能

TC源码分析一，tc命令相关推荐

【Redis源码分析】Redis命令处理生命周期
运营研发团队李乐前言本文主要讲解服务器处理客户端命令请求的整个流程,包括服务器启动监听,接收命令请求并解析,执行命令请求,返回命令回复等,这也是本文的主题"命令处理的生命周期" ...
【Flink源码分析】Flink 命令启动全流程
一.启动脚本分析 1. WordCount启动命令 bin/flink run examples/streaming/SocketWindowWordCount.jar --hostname loca ...
【Android 性能优化】应用启动优化 ( 阶段总结 | Trace 文件分析及解决方案 | 源码分析梳理 | 设置主题的方案总结 ) ★
文章目录一. 常用的耗时方法优化方案 ( 重要 ) 二. 源码分析梳理 1. 应用启动时间计算相关源码分析 2. Launcher 应用中启动 Android 应用流程三. 启动白屏解决方案 An ...
Django源码分析10：makemigrations命令概述
django源码分析本文环境python3.5.2,django1.10.x系列 django源码分析-makemigrations命令概述 Django项目中的数据库管理命令就是通过makemig ...
Django源码分析8：单元测试test命令浅析
django源码分析本文环境python3.5.2,django1.10.x系列 django源码分析-test命令分析 Django项目中提供了,test命令行命令来执行django的单元测试,该 ...
Django源码分析7：migrate命令的浅析
django源码分析本文环境python3.5.2,django1.10.x系列 django源码分析-migrate命令分析 Django项目中提供了,通过migrations操作数据库的结构的命 ...
celery源码分析:multi命令分析
celery源码分析本文环境python3.5.2,celery4.0.2,django1.10.x系列 celery简介 celery是一款异步任务框架,基于AMQP协议的任务调度框架.使用的场景 ...
docker stats命令源码分析结果
2019独角兽企业重金招聘Python工程师标准>>> 本文是基于docker 1.10.3版本的源码,对docker stats命令进行源码分析,看看docker stats命令输 ...
Docker源码分析(二)：Docker Client创建与命令执行
http://www.infoq.com/cn/articles/docker-source-code-analysis-part2 1. 前言如今,Docker作为业界领先的轻量级虚拟化容器管理引 ...

TC源码分析一，tc命令

TC