理解流量監管和整形的關鍵算法—令牌桶

無論是流量監管還是流量整形都提到一個超額流量的問題，而前面已經描述了監管和整形對超額流量的處理方式不同，監管丟棄或者重標記，流量整形是緩存，通過加大延遲的方式發送平滑的數據流量，那么網絡設備怎么去確定這個超額流量，難道鏈路的帶寬為512K，而此時用戶以每秒768KB/s發送數據，使用768-512就256KB,難道超額的流量就是256KB嗎？不是的，這樣做是一種錯誤的理解，要確定用戶的超額流量必須使用如下兩種算法中的一種來確定，一種叫漏桶算法（leaky bucket algorithm）另一種叫令牌桶算法（token bucket algorithm），而思科在流量監管和整形時使用的是令牌桶算法，為什么思科會選擇令牌桶算法，下面開始來理解：

漏桶算法（leaky bucket algorithm）

?? 漏桶算法（leaky bucket algorithm）是一種不支持任何數據突發量的算法，為了更好的理解漏桶算法，如圖所示，它好比一個底部呈現一個漏孔，然后裝滿水的桶，而桶的底部有一個恒定大小的漏孔，由于漏孔的大小是是恒定的，所以無論桶上方的水龍頭以多大的注水量向桶中注水，水通過漏孫向外泄漏的速率永遠是一樣的，算法不會因為桶中的水快被溢出而瞬間將桶中的水泄漏完之后，再繼續盛水。在這個比喻中桶中的水就好比是數據，水龍頭好比是用戶發送數據的速率，而桶底部的漏孔比如是流量整形或者監管的速率。

注意：在上面的描述中只是為了更好的理解漏桶算法，因為該算未能不并是需要描述的重點，大家只需要記住這樣這個原則：因為漏桶算法只能以恒定速率輸送數據，不支持任持續突發和最大突發，所以在流量管理中不使用漏桶算法，而是后面將要描述的令牌桶算法。

?

令牌桶算法（token bucket algorithm）或叫令牌漏桶算法

如圖所示：其實令牌桶的底部也有一個“漏洞”這一點是乎和漏桶非常相似，所以令牌桶還有另一個名命叫“令牌漏桶（本章節至此以后統稱它為令牌桶）”但是它與一般所指的常規漏洞有實質上的區別，令牌桶里面裝載的是令牌，然后讓令牌去關聯到數據發送，常規漏桶里面裝載的是數據，令牌桶允許用戶的正常的持續突發量（Bc），就是一次就將桶里的令牌全部用盡的方式來支持續突發，而常規的漏桶則不允許用戶任何突發行。而令牌桶的算法分為“單桶”和“雙桶”算法，那現在首先來理解單桶算法。

令牌桶中的令牌如何去關聯到數據發送

在令牌桶算法中，只有拿到令牌的數據才能被發送，反之則不能，假設一個令牌可以發送1bit（比特）的數據，那么要發6個bit的數據就需要拿到六個令牌，當拿到令牌的數據被發送后，該令牌就從桶中移除。換句話說桶中有多少令牌就能發送多少數據。如上圖所示，一共有6個數據需要被發送，桶中有四個令牌，那么就能發送4個數據。在圖示環境中剩下的2個數據因為沒有多余的令牌可用它們將不被發送。

?

令牌桶算法如何判斷超額流量以及如何向令牌桶中加入令牌

簡單的講，如果令牌桶中沒有可用的令牌，那么在這個時刻到來的所有數據流量都是超額流量。如下圖所示，至于超額的流量怎么處理，它可能被監管丟棄，也可能被整形所緩存，但這不是這里討論的重點，在實驗部分會重點討論丟棄和緩存的效果。至此為止，大家應該清晰的知道使用令牌去關聯數據并發送的過程了，令牌除了會從桶中移除以后，算法還會每隔一個的周期不斷的向桶中加入令牌，關鍵加入令牌的速率是多少？是什么時候（間隔時間周期）加入令牌？然后加多少令牌到桶中？這些問題被三個關鍵因素所決定，它們是：CIR（承諾信息速率）、Tc（時間周期）、Bc（持續突發量）。

CIR（承諾信息速率）：這個速率就是向令牌桶中加入令牌的速度，單位是bits persecond每秒多少個比特，一般情況下，會將這個速率配置成與認購的合同速率相匹配。比如：雖然您的接入速率可能有128K，但是認購速率為64K，那么就應該把CIR配置為64K。

Tc（時間間隔）：承諾的持續突發（Bc）間隔時間，也是讓令牌桶充滿令牌的時間隔，它的單位是毫秒（ms），這個Tc間隔是不能手工配置的，通常思科會假設這個Tc為125ms。它能被CIR和Bc通過公式計算而得到。

Bc（持續突發量）：它實際上定義了令牌桶的容量，或者這樣講更容易理解，它就是在一個Tc時間時隔內允許用戶一次耗盡桶中所有令牌的數量，以比特（bit）為單位。

?

流量監管和整形必須理解的重要公式：Bc = Tc * CIR

假設現在需要將一個（接入速度是128K）的鏈路，流量整形為承諾信息速率64K，那么該連接的持續突發量Bc是多少？很簡單此時只需要使用思科默認的Tc(125ms)即0.125s乘以64000bit/s即得到8000bits的持續突發量Bc。同樣的道理，如果已經知道了CIR和Bc就可以通過公式來計算出Tc。但是請始終注意一個問題：Tc是不可以手工配置的。能手工配置的只有CIR和Bc，而且思科建議只配置CIR，其它的參數，比如Bc，都讓系統去自動計算完成。所以在上述的三個參數中最重要的還是CIR。

?

注意：有些時候讀者在參看一些外文書籍或者參資料時，這個CIR也叫整形后的目標速率（Target Rate）或者叫整形速率（Shaped Rate），但其核心意思都一樣：往令牌桶中加入令牌的速率。所以公式Bc = Tc * CIR等同于Bc = Tc * Target rate也等同于Bc = Tc * Shaped Rate。但是這有一個前提：就是你整形后的目標速率或者叫整形速率必須與承諾信息速率相同。但是在一些特殊案例中，當用戶想獲得高于CIR的數據發送速率時，可以將上述后兩個公式中的Target rate 和Shaped Rate適當設置得更高些。

?

理解令牌桶算法支持用戶的持續突發行為，為什么叫Bc為“持續”突發？

事實上，在單令牌桶的算法中，用戶的持續突發量被Bc所決定的，Bc也代表令牌桶的容量，所謂突發行為是指：允許用戶一次用完令牌桶中的所有令牌，那么如何體現“持續”突發的特點呢？持續突發是指間隔一個Tc時間，令牌桶中的令牌會被再次充滿，然后用戶可以再次用盡令牌桶中的所有令牌，也就是說這個突發行為是可以持續進行的，會在間隔Tc的時間周期上反復充滿桶中的令牌同時又不斷釋放桶中的令牌，而不是在整個流量的較長時間發送過程中的瞬間行為。

?

流量整形到底是如何將接入速率（AR）轉化為認購速率？

比如說接入速率（也就是物理時鐘頻率工作在128K），而認購速率也就是CIR只有64K，流量整形是如何將這個接入速率128K整形成與CIR相匹配的64K的？在回答這個問題前首先得弄明白一個不可爭義的事實：如果接入速率工作在128K通常這個速率被時鐘頻率所決定，請注意在任何時候該接口都只會以128K的速率發送數據，就接口本身而言它是決不可能自己將發送速率降致64K的，但是它可以采取一種機制，把1秒鐘（1s）拿來平均化成N個以毫秒（ms）組成的時間間隔，然后一些間隔時間不讓其發送數據，能發送的時間間隔，接口還是以128K的速率來發送，如圖所示：就是將128K的接入速率整形為64K的認購速率（也就是CIR），假設配置令牌桶的深度（Bc）8000比特，因為Tc=Bc/CIR,所以就會產生8000除以64000等于0.125s(125ms)的時間間隔，那么8個125ms就是1秒，所以現在以125ms為基礎，劃分8個時間間隔。然后接口仍然將以128K來發送數據，因為這是不可改變的事實，當前令牌桶的深度(Bc)是8000比特，如果以128K來發送數據，那么8000除以128000等于62.5ms就完成數據發送了（正好是125ms的一半），但是此時由于令牌桶中的令牌耗盡，令牌耗盡就代表數據無法拿到令牌，無法拿到令牌就無法發送數據。所以在125ms的時間間隔中的另一半時間（后62.5ms），數據發送將被抑制，不能發送，直到125ms間隔周期到來，令牌桶又被充滿，然后再次耗盡它，然后重復的執行這個過程。所以從一秒鐘這個角度來看，雖然接口以128K發送，但是有500ms發送都被抑制，實際上就每秒就等于64K的發送率。最后就能得到如圖所示的整形情況：

通過上面的描述應該能理解單桶流量整形的工作機制了，現在需要進一步提出一個問題：如果用戶有長時間沒有發送數據，或者發送的數據低于令牌桶的容量（也就是不耗盡Bc中的令牌），那么新產生入桶的令牌會發生什么情況？

?

理解雙令牌桶算法：

??? ?如果只有一個令牌桶(Bc)，那么當用戶發送的數據低于令牌桶的容量（也就是不耗盡Bc中的令牌），新產生入桶的令牌會充滿令牌桶，當桶已經被充滿時，多余的令牌將被丟棄，這意味著用戶的整個突發量只能維持在Bc之內。不能存在有高過持續突發的超額突發（或者我更喜歡稱呼超額突發為瞬間突發）。為了突破這個限制，現在在令牌桶算法中引入雙桶機制，如圖所示，第一個令牌桶通常被稱為桶1也叫Bc或者叫持續突發桶；第二個令牌桶通常叫桶2也叫Be或者叫瞬間突發桶。雙桶算法遵守如下重要原則：

1 算法不會直接向桶2產生并加入令牌

2 只有當桶1被填充滿載時，從桶1溢出的令牌將被放入到桶2

3 不能保證桶2在每個時間間隔被充滿令牌，這被桶1溢出多少令牌到桶2有關。

4 但是如果桶2也被滿載，那么多余的令牌將被丟棄

?

根據上述的原則當引入桶2（Be）后，如果用戶發送數據時，他將獲得比單桶算法更大的突發量，因為流量耗盡了桶1（Bc）的令牌后，算法讓會讓流量去使用桶2（Be）中的令牌，所以此時用戶的數據突發量將等于Bc+Be。但是在流量整形過程中Bc和Be到底可以配置成多少bits，建議這樣的原則：將用戶獲得ISP的認購合同書上的CIR速率配置到流量整形中，讓系統自行去計算最合理的Bc和Be，并不建議用戶通過人工的方式去配置Bc和Be，整形系統的Bc可以通過Tc*CIR獲得，而Be和Bc在數學上是不存在必然的關系的。思科一般會將Be的大小自動配置為和Bc相同。舉一個例子來說明，如圖所示為將接入速率128K整形為64K，Bc=8000bits, Be=8000bits,所以圖中的流量突發會多一個Be的瞬間突發流量（如箭頭所指示的那一部分），為什么Be只有那么一瞬間的突發量，而不能持續，因為算法從來都不會向Be直接加入令牌，Be只能收集被Bc溢出的令牌，如果用戶一直以持續的高于64K的速率來發送數據，那么Bc就根本不會有令牌溢出，它將被反復的充滿又耗光，然后又充滿，然后又耗光，那么就不會有多是余的令牌溢出到桶2(Be)中，所以被允許的Be叫瞬間突發，一般只出現在數據初始發送的第一個時間時隔內，因為只有此時的Bc和Be的令牌都是滿桶，還有就是出現在用戶以低于CIR的速率在發送數據，只有這個時候桶2（Be）才有機會被充滿。

注意區別持續突發和瞬間突發的差異：

持續突發是指Bc，所謂持續是指它可以每隔一個Tc間隔，就能將Bc的令牌全部用完，這意味著這個行為是可以反復持續的進行的，它與CIR和Tc存在必然的數學關系，通常是Bc=CIR*Tc，而瞬間突發或者叫超額突發是指Be，它不能被持續進行，能執行瞬間突發的一個唯一條件就是Bc的令牌已經滿了，有令牌溢出到Be，當完成一次突發后，耗完Be的令牌后，如果一直沒有令牌從Bc溢出到Be那么就不能在進行瞬間突發行為，所以它只是瞬間。

?

流量整形的配置及單雙桶的確認

以GTS（通用流量整形）為例，默認情況下建議只配置CIR，系統自動計算Bc和Be，系統會使用雙桶算法（同時使用Bc和Be），具體如下所示：

?

關于流量整形的配置說明：

R1(config)#inte s1/0

R1(config-if)#traffic-shape rate 64000?? * 配置流量整形到每秒64Kbps

R1(config-if)#exit

?

??? 上述配置就僅是配置了整形的CIR，讓系統去確定Bc和Be，當完成配置后，可以通過show traffic-shape來查看流量整形的各項配置參數，如圖所示，當前的配置是將接入速率整形到64K，桶1(Bc)=8000bits=1000bytes；該參數是系統根據64000/bps(CIR)*0.125s(Tc)=8000bits所得到的。Tc思科默認是125ms。同時系統啟動了雙桶算法，將桶2（Be）配置成為與桶1（Bc）相同的大小8000bits。所以現在第一個時間時隔的突發量就是Bc+Be=16000bits，換成以字節為單位就是16000除以8等于2000byte。

手工配置Bc并申明使用單桶機制：

R1(config)#intes1/0

R1(config-if)#traffic-shaperate 64000 8000 0

* 整到CIR64K，手工配置桶1（Bc）為8000bits，手工配置桶2（Be）為0，由于Be被配置為0，這就申明目前流量整形只使用單桶算法，具體如圖所示。

總結

以上是生活随笔為你收集整理的理解流量监管和整形的关键算法—令牌桶的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。