下面對常見的限流算法進行討論。目前，常用的限流算法主要有三種：計數(shù)器法、滑動窗口算法、漏桶算法和令牌桶算法。下面分別介紹其原理。

1. 計數(shù)器法

計數(shù)器法是通過計數(shù)對到來的請求進行選擇性處理。如系統(tǒng)限制一秒內(nèi)最多有X個請求，則在該秒時間內(nèi)對到來的請求進行計數(shù)，當計數(shù)達到X后，拒絕所有后續(xù)請求。直到下一秒開始，對計數(shù)器進行清空。該方法的主要弊端是會造成所謂的“突刺現(xiàn)象”：若請求的產(chǎn)生并不均勻（如在某一秒的前0.01秒內(nèi)就產(chǎn)生了X個請求），則會造成在后續(xù)的大部分時間內(nèi)無法處理新的請求。

2. 滑動窗口算法

將時間窗口劃分為多個子窗口，每個子窗口內(nèi)限定請求的數(shù)量，例如每秒鐘最多允許處理100個請求，每0.1秒鐘內(nèi)最多允許處理10個請求。這種算法可以更平滑地限制請求的數(shù)量。

3. 漏桶算法

漏桶算法是在計數(shù)器算法的基礎(chǔ)上，為了處理“突刺現(xiàn)象”提出的一種限流算法。該算法將所有到來的請求保存入一個隊列（漏桶）中，并以恒定的速率從該隊列中獲取請求并加以執(zhí)行。當隊列大小達到限制（桶滿）后，則拒絕后續(xù)請求。其示意圖如下。

可以看出，該算法的核心思想是利用能夠臨時存儲請求的“漏桶”，對請求的序列進行整形，從而對“突刺現(xiàn)象”進行處理。該算法的整形能力由漏桶的大小限制，當累計堆積的請求數(shù)量過多，超過漏桶大小時，整形就會失效，造成后續(xù)時間內(nèi)到來的請求無法得到處理。此外，由于漏出的速率固定，漏桶算法在突發(fā)特性的流量場景下無法充分利用資源。

4. 令牌桶算法

令牌桶算法與漏桶算法看起來十分近似。該算法以恒定的速率創(chuàng)建令牌，并放入指定大小的隊列（令牌桶）中，若令牌桶已滿，則丟棄令牌。每個請求到來時，需要從令牌桶中嘗試獲取令牌，若拿到令牌，則消耗令牌進行操作；否則將該請求阻塞，直到獲取到令牌。其原理圖如下。

令牌桶具有“先消費后生產(chǎn)”的性質(zhì)：當請求到來時，可以先使用令牌桶中初始已有的令牌進行操作，而后再生產(chǎn)令牌對令牌桶進行補充。
與漏桶算法相比，令牌桶算法對突發(fā)特性的流量具有更好的處理能力。由于其“先消費后生產(chǎn)”的性質(zhì)，只要令牌桶中存在令牌，就可以進行對突發(fā)的請求進行處理，充分利用資源。此外，令牌桶算法可以通過改變令牌生成的速率，方便地對限流效果進行調(diào)節(jié)。

小結(jié)

漏桶算法與令牌桶算法看似相似，但設(shè)計思路與性能均存在較大差別。漏桶算法將請求作為桶的生產(chǎn)方，通過限制桶桶漏出的速度實現(xiàn)限流。令牌桶算法則是將請求作為桶的消費方，通過控制桶的注入速度而實現(xiàn)限流。兩者各有特點，均被廣泛使用，沒有一定的優(yōu)劣之分。
下表總結(jié)了兩者的差異：

	限流思路	優(yōu)點	缺點
漏桶算法	限制桶的流出速度	能夠嚴格控制請求處理速率上限	在存在突發(fā)特性流量時可能無法充分利用系統(tǒng)資源
令牌桶算法	限制桶的輸入速度	可處理具有突發(fā)特性流量易于調(diào)節(jié)	無法嚴格控制瞬時請求處理速率

5. QoS

有三大主流QoS模型，Best-Effort服務(wù)模型、IntServ預(yù)留資源模型、DiffServ差分服務(wù)模型‘

5.1 Best-Effort

Best-Effort是最簡單的QoS服務(wù)模型，用戶可以在任何時候，發(fā)出任意數(shù)量的報文，而且不需要通知網(wǎng)絡(luò)。提供Best-Effort服務(wù)時，網(wǎng)絡(luò)盡最大的可能來發(fā)送報文，但對時延、丟包率等性能不提供任何保證。Best-Effort服務(wù)模型適用于對時延、丟包率等性能要求不高的業(yè)務(wù)，是現(xiàn)在Internet的缺省服務(wù)模型，它適用于絕大多數(shù)網(wǎng)絡(luò)應(yīng)用，如FTP、E-Mail等

5.2 IntServ

IntServ模型是指用戶在發(fā)送報文前，需要通過信令（Signaling）向網(wǎng)絡(luò)描述自己的流量參數(shù)，申請?zhí)囟ǖ腝oS服務(wù)。網(wǎng)絡(luò)根據(jù)流量參數(shù)，預(yù)留資源以承諾滿足該請求。在收到確認信息，確定網(wǎng)絡(luò)已經(jīng)為這個應(yīng)用程序的報文預(yù)留了資源后，用戶才開始發(fā)送報文。用戶發(fā)送的報文應(yīng)該控制在流量參數(shù)描述的范圍內(nèi)。網(wǎng)絡(luò)節(jié)點需要為每個流維護一個狀態(tài)，并基于這個狀態(tài)執(zhí)行相應(yīng)的QoS動作，來滿足對用戶的承諾。
IntServ模型使用了RSVP（Resource Reservation Protocol）協(xié)議作為信令，在一條已知路徑的網(wǎng)絡(luò)拓撲上預(yù)留帶寬、優(yōu)先級等資源，路徑沿途的各網(wǎng)元必須為每個要求服務(wù)質(zhì)量保證的數(shù)據(jù)流預(yù)留想要的資源，通過RSVP信息的預(yù)留，各網(wǎng)元可以判斷是否有足夠的資源可以使用。只有所有的網(wǎng)元都給RSVP提供了足夠的資源，“路徑”方可建立。

5.3 DiffServ

DiffServ模型的基本原理是將網(wǎng)絡(luò)中的流量分成多個類，每個類享受不同的處理，尤其是網(wǎng)絡(luò)出現(xiàn)擁塞時不同的類會享受不同級別的處理，從而得到不同的丟包率、時延以及時延抖動。同一類的業(yè)務(wù)在網(wǎng)絡(luò)中會被聚合起來統(tǒng)一發(fā)送，保證相同的時延、抖動、丟包率等QoS指標。
Diffserv模型中，業(yè)務(wù)流的分類和匯聚工作在網(wǎng)絡(luò)邊緣由邊界節(jié)點完成。邊界節(jié)點可以通過多種條件（比如報文的源地址和目的地址、ToS域中的優(yōu)先級、協(xié)議類型等）靈活地對報文進行分類，對不同的報文設(shè)置不同的標記字段，而其他節(jié)點只需要簡單地識別報文中的這些標記，即可進行資源分配和流量控制。
與Intserv模型相比，DiffServ模型不需要信令。在DiffServ模型中，應(yīng)用程序發(fā)出報文前，不需要預(yù)先向網(wǎng)絡(luò)提出資源申請，而是通過設(shè)置報文的QoS參數(shù)信息，來告知網(wǎng)絡(luò)節(jié)點它的QoS需求。網(wǎng)絡(luò)不需要為每個流維護狀態(tài)，而是根據(jù)每個報文流指定的QoS參數(shù)信息來提供差分服務(wù)，即對報文的服務(wù)等級劃分，有差別地進行流量控制和轉(zhuǎn)發(fā)，提供端到端的QoS保證。DiffServ模型充分考慮了IP網(wǎng)絡(luò)本身靈活性、可擴展性強的特點，將復(fù)雜的服務(wù)質(zhì)量保證通過報文自身攜帶的信息轉(zhuǎn)換為單跳行為，從而大大減少了信令的工作，是當前網(wǎng)絡(luò)中的主流服務(wù)模型。

5.4 基于DiffServ模型的QoS組成

基于Diffserv模型的QoS業(yè)務(wù)主要分為以下幾大類：
（1）報文分類和標記
要實現(xiàn)差分服務(wù)，需要首先將數(shù)據(jù)包分為不同的類別或者設(shè)置為不同的優(yōu)先級。報文分類即把數(shù)據(jù)包分為不同的類別，可以通過MQC配置中的流分類實現(xiàn)。報文標記即為數(shù)據(jù)包設(shè)置不同的優(yōu)先級，可以通過優(yōu)先級映射和重標記優(yōu)先級實現(xiàn)。不同的報文使用不同的QoS優(yōu)先級，例如VLAN報文使用802.1p，IP報文使用DSCP，MPLS報文使用EXP。
（2）流量監(jiān)管、流量整形和接口限速
流量監(jiān)管和流量整形可以將業(yè)務(wù)流量限制在特定的帶寬內(nèi)，當業(yè)務(wù)流量超過額定帶寬時，超過的流量將被丟棄或緩存。其中，將超過的流量丟棄的技術(shù)稱為流量監(jiān)管，將超過的流量緩存的技術(shù)稱為流量整形。接口限速分為基于接口的流量監(jiān)管和基于接口的流量整形。
（3）擁塞管理和擁塞避免
擁塞管理在網(wǎng)絡(luò)發(fā)生擁塞時，將報文放入隊列中緩存，并采取某種調(diào)度算法安排報文的轉(zhuǎn)發(fā)次序。而擁塞避免可以監(jiān)督網(wǎng)絡(luò)資源的使用情況，當發(fā)現(xiàn)擁塞有加劇的趨勢時采取主動丟棄報文的策略，通過調(diào)整流量來解除網(wǎng)絡(luò)的過載。

小結(jié)

	優(yōu)點	缺點
Best-Effort	實現(xiàn)機制簡單	對不同業(yè)務(wù)流不能進行區(qū)分對待
IntServ	可提供端到端QoS服務(wù)，并保證帶寬、延遲	需要跟蹤和記錄每個數(shù)據(jù)流的狀態(tài)，實現(xiàn)較復(fù)雜，且擴展性較差，帶寬利用率較低
DiffServ	不需跟蹤每個數(shù)據(jù)流狀態(tài)，資源占用少，擴展性較強	且能實現(xiàn)對不同業(yè)務(wù)流提供不同的服務(wù)質(zhì)量, 需要在端到端每個節(jié)點都進行手工部署，對人員能力要求較高