近日的工作多多少少和Linux的流控有点关系，自打几年前知道有TC这么一个玩意儿并且多多少少理解了它的原理之后，我就没有再动过它，因为我不喜欢 TC命令行，实在是太繁琐了，iptables命令行也比较繁琐，但是比TC命令行直观，而TC命令行则太过于技术化。也许是我对TC框架没有对 Netfilter框架理解深刻吧，也许是的。iptables/Netfilter对应的就是tc/TC。
       Linux内核内置了一个Traffic Control框架，可以实现流量限速，流量×××，策略应用(丢弃，NAT等)。从这个框架你能想到别的什么吗？或许现在不能，但是我会先简单说一下，和 TC框架比较相似的是Netfilter框架，但是二者却又有很大的不同。
       在精通了Netfilter框架之后，再来体会TC框架会简单得多，特别是，当你觉得Netfilter具有这样那样的局限时，带着这些问题去体会TC框 架的设计，你可能会发现，TC在某些方面弥补了Netfilter的不足。在具体深入到细节前，我先来介绍一下二者的相同点以及因其初衷不同而导致设计的 大相径庭。
       先说Netfilter，无疑这个框架被设计用来在网络协议栈的内核路径上过滤数据包，就像在一条路上的关卡一样，Netfilter在协议栈处理网络数 据包的路径上的5个位置设置了这样的关卡，一个数据包在被处理的路径上经过这些关卡被检查，结果就是若干个动作：接受，丢弃，排队，导入其它路径等，框架 只需针对一个数据包得出一个结果即可，关卡内部提供什么服务在Netfilter框架中并没有任何规定。
       现在我们看TC，它旨在对数据包或者数据流提供一种服务，比如限速，×××等，而这并不是一个类似Netfilter的结果可以表达的，提供这些服务需要执 行一系列的动作，因此如何来“规划和组织这些动作的执行”是TC框架设计的关键！也就是说，TC框架关注的是如何执行而不是仅仅想要得到一个要执行的动 作。换句话说，Netfilter框架关键做什么，而TC框架关注怎么做。(关于Netfilter我已经写了大量的代码和文章，不再赘述了...)
       有关限速，流量×××方面的理论已经很多了，比较常见的比如使用令牌桶，但是本文关注的是Linux对TC框架的实现而不是令牌桶算法相关的内容，然而在一 篇短文中又不可能详细描述从流量控制理论到各种操作系统版本实现的历史，但是我们知道，使用队列是大多数实现中实际的选择，那么现在问题来了，Linux 的TC框架是如何组织队列的。在详细深入讨论队列组织之前，我最后一次比较一下Netfilter和TC。
       如果你知道UNIX的字符设备和块设备之间的区别，那么理解Netfilter框架和TC框架之间的区别就比较容易了。Netfilter的一个HOOK 点类似一个管道字符设备，而skb就是这个设备中的单向字符流，一般都是按照从一端流入，然后按照进入的顺序从另一端流出，附带一个结果，比如 ACCEPT，DROP等。而TC框架比较类似一个块设备，对内容进行随机存储和随机访问，即skb进入的顺序并不一定是skb出来的顺序，而这正是流量 ×××需要做的。也就是说，TC框架必须实现一个随机访问的数据包存储缓冲区，在这个缓冲区中进行流量控制，当然，我们已经知道，这是由队列实现的。
       当然，任何事情都不是绝对的，Netfilter的一个HOOK点也可以有存储缓冲区或者执行一系列的动作，典型的就是conntrack中的分片重组以 及NAT功能，对于PREROUTING这个HOOK点的分片重组，无疑对于分片而言，只是进入HOOK，暂时保存在里面，直到所有分片都来了切重组成功 后才一次性流出这个HOOK点，而对于NAT而言，Netfilter的处理结果无疑是“执行了一系列的动作”而不仅仅是ACCEPT。此外，我也写过一 些模块，用Netfilter来实现流量控制，反过来，TC框架也可以实现Netfilter的功能，总之，当你理解了这些框架的设计原则以及其本质后， 在使用和扩展上，你就可以庖丁解牛，游刃有余了。
       个人觉得，对于单独的一个Netfilter HOOK点，TC框架是其超集，实现上更加灵活，当然也就更加复杂。Netfilter所拥有的TC不具备的魅力在于其HOOK点位置的定义。
       好了，现在开始正式介绍TC框架的设计。
       很多网上搜到的资料在介绍TC的时候，无一例外地介绍了TC是由“队列规程，类别，过滤器”三者组成的，大多数含糊不清，我敢说这些都是出自一篇文档或者 一本书。很少有人从另外一个角度去理解TC框架的设计，而这本身就是一个比较有挑战性的事，我个人比较喜欢这种事情。在介绍TC的队列组织之前，我先来介 绍一下什么叫作递归控制，所谓的递归控制就是分层次地控制，而对于每个层次，控制方式都是一致的。熟悉CFS调度的都知道，对于组调度和task调度都采 用了完全相同的调度方式，然而显然组和task是属于不同层次的，我画了下面一张图来简单描述这种情况：

不光是控制逻辑的组织，就连Linux在实现UNIX进程模型时，也采用了这种树形的递归控制逻辑，每一个层次都是一个两层的树，下图展示了这个模型：

可以看出，递归控制是分形的，如果能用立体的图展示会更好些，对于上图而言，除了叶子节点之外的每一个节点都是一颗独立的小树，不管是大树还是小树，对于控制逻辑或者组织逻辑而言，其性质是完全一样的。
       递归的控制便于控制逻辑的任意叠加，这个我们在协议栈的设计中看到过，比如X over Y，简称XoY，比如PPPoE，IP over UDP(tun模式的Open×××)，TCP over IP(原生的TCP/IP栈)...对于TC而言，考虑下面一个需求：
1.将整个带宽按照2:3的比例分给TCP和UDP；
2.在TCP流量中，按照源IP地址段将其划分为不同的优先级；
3.在相同的优先级队列中，按照2:8的比例将带宽分给HTTP应用和其它；
4....
从以上需求可以看出，这是一个递归控制的需求，其中1和3均使用了带宽比例分配，但是显而易见，这是属于不同层次的。整个架构看起来应该是下面这个样子：

但是事情远非想象的那个单纯，虽然上面的图已经让你看出了TC框架的端倪，然而对于实现它却没有一点帮助。几个典型的问题摆在那里，你怎么甄别数据包到不同的队列，图中的非叶子节点要呈现成什么数据结构，既然不是真正的队列却又要有队列的行为，那么如何表达它们？...
       Linux在实现TC的时候，对“队列”进行了抽象，基本上它维护了两个回调函数指针，一个是enqueue入队操作，一个是dequeue出队操作。不 管是enqueue还是dequeue，都并不一定真正将数据包排入队列，而仅仅是“执行一系列的操作”。这个“执行一系列的操作”可以是：
1.对于叶子节点，真正排入一个真实的队列或者从真正的队列拉出一个数据包；
2.递归调用其它抽象队列的enqueue/dequeue。
注意上面的第2点，提到了“其它抽象队列”，那么如何来定位这个抽象队列呢？这就需要一个抉择，也就是一个选择器，根据数据包的特征来将数据包归入一个抽象队列，这个时候，TC的设计框图可以用下图来表达：

可以看到，我并没有用那个经典的“队列规程，类别，过滤器”三元组来定义TC框架，而是用一种递归控制的意义来解释。如果用经典三元组来套在这幅图上，就会是下面这个样子，注意，我删去了不必要的文字，这样图不至于太过混乱，需要文字的请参考上图：

可见，万变不离其衷或者说英雄所见略同。
       好了，现在说点题外话，还是和Netfilter有关的，当然不是它和TC的比较，而是我个人的一点想法。曾几何时，我十分推崇Cisco的ACL，应为 它们是应用于网卡接口的，而Netfilter则是拦截在处理路径上而不是处理设备上，对于Netfilter而言，处理设备只是一个毫无特殊之处的 match，不管有无关系，所有的数据包均要经过Netfilter HOOK点的抉择，起码你要判断它是否匹配-i ethX...我想在net_device上挂一个filter_list，也写过一些代码，发现效果比较好，准备采用。我是一个经常重复造轮子的人，当 我后来看了TC的实现后，发现TC框架正是我想要找的，于是我放言，能用Netfilter实现的，用TC也一样能实现。并且，TC基于队列规程(数据结 构字段正是这么写，Qdisc-queue discipline，这并非受经典三元组表达法的影响)的，抽象的入队/出队并没有规定如何实现，且队列规程和网卡绑定(更精确地说是网卡的队列-如果网卡支持多队列的话)而不是拦截在处理路径上。于是我有两种选择：
1.实现一个新的Qdisc，其内置一个简单的FIFO队列，enqueue操作进行从Netfilter移植过来的matches/target，所有ACCEPT的数据包排入FIFO；
2.在分类器上做文章，是否将数据包归于一个类别不光要看数据包的特征，还要额外执行一个action回调函数，只有该函数返回0才代表成功，而既然作为回调，你便可以在其中进行任何action(drop，nat等)，关起门来lualu。
以上1和2中，第2点已经实现了，第一点很容易实现，你只需要实现一个队列规程即可，或者说为每一个队列规程都加一个action，看上去如下图所示：

对于第2点，比较简单，其本质就是在那个菱形中做文章，放大后的菱形如下图所示：

这 样就用TC框架实现了防火墙的功能以及NAT的功能，这是我一直以来的愿望。其实我早就知道这件事，只是我不太喜欢TC的命令，因为它配置起来太技术化 了，维护起来极其困难，甚至比iptables规则维护起来都困难，而维护是超级重要的，它甚至比你想到如何书写这个规则更重要，因为如何书写是一瞬间的 事，如果你有足够的积累，那么一瞬间你就能搞定，如果你碰到了难题，敢说灵感的显现也是一瞬间的，比如酒后，但是维护却是长久的事，且维护的人不一定是你 自己，你必须要为别人考虑，因为技术社会是利他的社会。
       好了，到此为止，相信我已经把该说的都说了，都是框架性的，没有任何细节在里面，虽然不太喜欢TC命令行，但是我还是希望最后用一幅图展示一下每一条TC命令和内核数据结构的关系，依然是没有细节，命令也不全，省略了match，因为我知道那些不重要：

看 我的文章，你可能很难得到那种复制了之后直接粘贴上就能用的东西，代码省略了，命令省略了，就算是我自己，在看到自己多年前写的东西时，十分想快速运行点 什么，但是没有这样的东西。可是我觉得，思想大于实现，如果你理解了实现背后或者现实背后的本质，那么你就会得心应手，游刃有余。