linux中的TC（TrafficControl）詳細說明

1. qdisc(排隊規則)、class(類別)和filter(過濾器)

Linux操作系統中的流量控制器TC（TrafficControl）用於Linux內核的流量控制，它利用隊列規定建立處理數據包的隊列，並定義隊列中的數據包被髮送的方式，從而實現對流量的控制。

• qdisc通過隊列將數據包緩存起來，用來控制網絡收發的速度
• class用來表示分類策略
• filter用來將數據包劃分到具體的分類中
  

1.1 隊列

TC模塊實現流量控制功能使用的隊列規定分爲兩類：

• 一類是無類隊列規定
  無類隊列對進入網絡設備(網卡)的數據流不加區分統一對待的隊列
  這類隊列規定形成的隊列可以對整個網絡設備(網卡)的流量進行整形，但不能細分各種情況。
  這類隊列規定使用的流量整形手段主要是排序、限速和丟包。
  常用的無類隊列規定主要有pfifo_fast(先進現出)、TBF(令牌桶過濾器)、SFQ(隨機公平隊列)、ID(前向隨機丟包)等等。

• 另一類是分類隊列規定
  分類隊列對進入網絡設備的數據包根據不同的需求以分類的方式區分對待的隊列規定。
  數據包進入一個分類的隊列後，它就需要被送到某一個類中，也就是說需要對數據包做分類處理。
  對數據包進行分類的工具是過濾器，過濾器會返回一個決定，隊列規定就根據這個決定把數據包送入相應的類進行排隊。每個子類都可以再次使用它們的過濾器進行進一步的分類。直到不需要進一步分類時，數據包才進入該類包含的隊列排隊。
  除了能夠包含其它隊列規定之外，絕大多數分類的隊列規定還能夠對流量進行整形。這對於需要同時進行調度(如使用SFQ)和流量控制的場合非常有用。

1.2 控制策略

流量控制包括以下4種方式

1. SHAPING(限制)
   當流量被限制，它的傳輸速率就被控制在某個值以下。限制值可以大大小於有效帶寬，這樣可以平滑突發數據流量，使網絡更爲穩定。shaping（限制）只適用於向外的流量。
2. SCHEDULING(調度)
   通過調度數據包的傳輸，可以在帶寬範圍內，按照優先級分配帶寬。SCHEDULING(調度)也只適於向外的流量。
3. POLICING(策略)
   SHAPING用於處理向外的流量，而POLICIING(策略)用於處理接收到的數據。
4. DROPPING(丟棄)
   如果流量超過某個設定的帶寬，就丟棄數據包，不管是向內還是向外。

2. TC命令操作

2.1 tc命令

tc可以使用以下命令對QDisc、類和過濾器進行操作：

tc qdisc [ add | change | replace | link ] dev DEV [ parent qdisc-id | root ] [ handle qdisc-id ] qdisc [ qdisc specific parameters ]
tc class [ add | change | replace ] dev DEV parent qdisc-id [ classid class-id ] qdisc [ qdisc specific parameters ]
tc filter [ add | change | replace ] dev DEV [ parent qdisc-id | root ] protocol protocol prio priority filtertype [ filtertype specific parameters ] flowid flow-id
tc [-s | -d ] qdisc show [ dev DEV ]
tc [-s | -d ] class show dev DEV tc filter show dev DEV

2.2 基本步驟

1. 針對網絡物理設備（如以太網卡eth0）綁定一個隊列QDisc；
2. 在該隊列上建立分類class；
3. 爲每一分類建立一個基於路由的過濾器filter；
4. 最後與過濾器相配合，建立特定的路由表。

3. 流控算法

3.1 漏桶(Leaky Bucket)算法

水(請求)先進入到漏桶裏，漏桶以一定的速度出水(接口有響應速率),
當水流入速度過大會直接溢出(訪問頻率超過接口響應速率), 然後就拒絕請求,

漏桶算法有兩個變量：
一個是桶的大小,支持流量突發增多時可以存多少的水(burst),
另一個是水桶漏洞的大小(rate)。

3.2 令牌桶算法(Token Bucket)

隨着時間流逝,系統會按恆定1/QPS時間間隔(如果QPS=100,則間隔是10ms)
往桶裏加入Token(想象和漏洞漏水相反,有個水龍頭在不斷的加水)
如果桶已經滿了就不再加了. 新請求來臨時
會各自拿走一個Token,如果沒有Token可拿了就阻塞或者拒絕服務.

4. 雲環境下的動態流控

傳統的流控採用的是靜態預分配。
而在雲計算環境下，服務節點也會由於服務的動態上下線而處於頻繁變化的狀態，這種場景下靜態分配顯然沒辦法滿足需求。
雲服務的資源也是動態分配的，靜態分配閾值的方法沒辦法遷移到雲上

4.1 方案一：動態流控

以服務註冊中心以流控週期T爲單位，動態推送每個節點分配的流控閾值QPS，當服務節點發生變更時，會觸發服務註冊中心重新計算每個節點的配額，然後進行推送，這樣無論是新增還是減少服務節點，都可以在下一個流控週期內被識別和處理，實現動態變更

4.2 方案二：配額動態申請和返還

每個節點根據自己分配到的值和自身處理速率做出預測，若指標有剩餘就返還給註冊中心，若不夠，就主動像註冊中心申請，申請不到配額時就做出節流限制

參考

流量控制工具TC詳細說明
統一流控服務開源-1：場景&業界做法&算法篇
分佈式框架中的流量控制