Linux TC(Traffic Control)框架原理解析

近日的工作多多少少和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框架之间的差别就比較easy了。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模式的OpenVPN)，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的设计框图能够用下图来表达：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZG9nMjUw/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZG9nMjUw/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

可见，万变不离其衷或者说英雄所见略同。
       好了，如今说点题外话，还是和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点已经实现了，第一点非常easy实现，你仅仅须要实现一个队列规程就可以，或者说为每个队列规程都加一个action，看上去例如以下图所看到的：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZG9nMjUw/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZG9nMjUw/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

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

看我的文章。你可能非常难得到那种复制了之后直接粘贴上就能用的东西。代码省略了，命令省略了，就算是我自己，在看到自己多年前写的东西时，十分想高速运行点什么，可是没有这样的东西。

可是我认为，思想大于实现。假设你理解了实现背后或者现实背后的本质，那么你就会得心应手，游刃有余。