近日的工作多多少少和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，因為我知道那些不重要：