文章目錄
Qos服務模型
- Qos(Quality of Service)在帶寬有限的情況下，Qos應用一個“有保證”的策略對網絡流量進行管理，並實現不同的流量可以獲得不同的優先服務
- 要提高通信質量就要提高帶寬、減少時延和抖動、降低丟包率
| 類型 | 單位 | 說明 |
|---|---|---|
| 網絡帶寬 | 單位時間（一般是1s）內傳輸的數據量 | 最大帶寬等於傳輸路徑上的最小帶寬 |
| 網絡時延 | 一個報文從網絡的一端傳送到另一端所需要的時間 | 一個報文從一個網絡的一端傳送到另一端所需要的時間 |
| 抖動 | 每個報文的端到端時延不一樣，會導致報文不能等間隔到達目的端 | 抖動是由於每個保溫的端到端時延不相等造成的 |
| 丟包率 | 在網絡傳輸過程中丟失報文佔傳輸報文的百分比 | 丟包可能發生在傳輸過程中的每一個環節 |
- 單個設備的時延包括：
- 傳輸時延：一個數據從發送方到接收方所需要的時間。該時延取決於傳輸距離和傳輸介質，與帶寬無關
- 串行化時延：指發送節點在傳輸鏈路上開始發送報文的第一個比特至發完該報文的最後一個比特所需要的時間。該時延取決於鏈路帶寬及報文的大小
- 處理時延：指路由器把報文從入接口放到出接口所需的時間。該時延與路由器的處理性能有關
- 隊列時延：指報文在隊列中等待的時間。該時延與隊列中報文的大小、數量、帶寬以及隊列機制有關
- 抖動的大小跟時延的大小直接相關，時延小，抖動小；時延大，抖動大
- 丟包可能發生的環節：
- 處理過程
- 排隊過程
- 傳輸過程
各類業務對服務質量的要求
| 流量類型 | 帶寬 | 時延 | 抖動 | 丟包率 |
|---|---|---|---|---|
| 語音 | 低 | 高 | 高 | 低 |
| 視頻 | 高 | 高 | 高 | 低 |
| FTP | 中，高 | 低 | 低 | 高 |
| 電子郵件、HTTP網頁瀏覽 | 低 | 低 | 低 | 中，高 |
盡力而爲服務模型
- 先進先出轉發即Best-Effort（盡力而爲）服務模型
- 一個單一（最簡單）的服務模型，應用程序可以在任意時候，發出任意數量的報文，不需要事先獲得批准，不需要通知網絡
- 盡最大的可能性來發送報文，對時延、可靠性等性能不提供保證，適用於絕大多數網絡應用
- 是現在Internet的缺省服務類型，通過先入先出（FIFO）隊列來實現
- 在盡力而爲的服務模型下，可以通過兩種方式來提高端到端的通信質量：
- 增大網絡帶寬：可以增大單位時間內傳輸的數據量
- 優點：可以改善帶寬瓶頸、串行優化延遲、丟包等問題
- 缺點：網絡建設成本高
- 升級網絡設備：可以增大數據處理能力
- 優點：可以改善處理延遲、隊列延遲、丟包等問題
- 缺點：成本較高，替換設備增大業務中斷風險
- 增大網絡帶寬：可以增大單位時間內傳輸的數據量
綜合服務模型
- 綜合服務模型（Integrated Services Model），使設備運行一些協議（RSVP）來保障關鍵業務的通信質量
- RSVP協議工作過程：在應用程序發送報文前，需要向網絡申請特定的帶寬和所需要的特定服務質量的請求，等收到確認信息後才發送報文
- 優點：可以爲某些特定業務提供貸款、延遲保障
- 缺點：
- 實現較爲複雜
- 當沒有流量發送時，仍然獨佔帶寬，使用效率較低
- 該方案要求端到端所有節點設備都支持並運行RSVP協議
綜合服務模型在現實網絡中並不多見
區分服務模型
- 區分服務模型（DiffServ），首先將網絡中的流量分成多個類，然後每個類定義相應的處理行爲，使其擁有不同的優先轉發、丟包率、時延等
- 目前應用最廣的就是區分服務模型
三種服務模型對比
| 服務模型 | 優點 | 缺點 |
|---|---|---|
| 盡力而爲服務模型 | 實現機制簡單 | 對不同的業務流不能進行區分對待 |
| 綜合服務模型 | 可提供端到端的Qos服務，並保證帶寬延遲 | 需要跟蹤和記錄每個數據流的狀態，實現較爲複雜，且拓展性較差，帶寬利用率較低 |
| 區分服務模型 | 不需要跟蹤每個數據流狀態，資源佔用少，拓展性較強；且能實現對不同業務流提供不同的服務質量 | 需要在端到端每個節點都進行手工部署，對人員能力要求較高 |
報文分類與標記
簡單流分類
- 依據不同鏈路類型傳輸的不同類別的報文，且自身含有的標識Qos優先級的字段值進行分類
各報文中的Qos分類
- WLAN幀頭中的802.1P字段（取值範圍0~7）
-
MPLS報文中的EXP字段（取值範圍0~7）
![MPLS報文]()
-
IPv4報文中的IP-Precedence字段標識其優先級（取值範圍0~7）
![IPv4報文]()
- D代表延遲（Delay），T代表吞吐量（Throughput），R代表可靠性（Reliability）
- 缺點：IP-Precedence字段最多隻能將IP報文分爲8類，而在網絡部署時，這些優先級不夠使用
DSCP值
- DSCP只有6Bits
- DSCP值的兩種表達方式：
- 數字形式：DSCP取值範圍爲0~63
- 關鍵字表達式：用關鍵字標識DSCP值
- BE相當於盡力而爲，先進先出
- AF成功轉發，優先級比較中等，AFxy中
- x代表不同的類別，由DSCP的前三位Bits組成，標識優先級的高低（4>3>2>1）
- y代表隊列被裝滿時丟包的概率，由DSCP前三位後的兩位Bits組成，y越大越容易被丟棄
- DSCP六位Bits中，最後一位固定爲0
- 由xy組成的五位二進制數對應着數字形式中的十進制數
- EF快速轉發，優先級較高
| DSCP Name | DSCP Value | IP-Precedence | 802.1P | Exp | |||||
| BE | BE(CS0) | 0 | 0 | ||||||
| CS | |||||||||
| CS1 | 8 | 1 | |||||||
| CS2 | 16 | 2 | |||||||
| CS3 | 24 | 3 | |||||||
| CS4 | 32 | 4 | |||||||
| CS5 | 40 | 5 | |||||||
| CS6 | 48 | 6 | |||||||
| CS7 | 56 | 7 | |||||||
| AF | |||||||||
| AF11 | AF12 | AF13 | 10 | 12 | 14 | 1 | |||
| AF21 | AF22 | AF23 | 18 | 20 | 22 | 2 | |||
| AF31 | AF32 | AF33 | 26 | 28 | 30 | 3 | |||
| AF41 | AF42 | AF43 | 34 | 36 | 38 | 4 | |||
| EF | EF | 46 | 5 | ||||||
DSCP Name中的CS只使用了DSCP的高三位Bits，所以只有CS1~7
複雜流分類
- 根據五元組(源、目地址，源、目端口號，協議號)等報文信息對報文進行驚喜的分類
![複雜流分類]()
報文分類配置
traffic classifier manager
if-match source-mac 3333-3333-3333
traffic classifier voice
if-match 8021p 3
traffic classifier video
if-match 8021p 2
報文標記配置
traffic behavior manager
remark 8021p 1
traffic behavior voice
remark 8021p 5
traffic behavior video
remark 8021p 3
-----------------------------------------
traffic policy a1
classifier manager behavior manager
classifier voice behavior voice
classifier video behavior video
接口調用
int g0/0/0
traffic-policy a1 inbound
int g0/0/1
traffic-policy a1 inbound
int g0/0/2
traffic-policy a1 inbound
int g0/0/3
traffic-policy a1 inbound
擁塞管理
-
擁塞管理通過隊列機制來實現：
- 將準備從一個接口發出的所有報文放入不同的緩存隊列中
- 根據各隊列間的調度機制實現不同報文的拆分轉發
-
LP（本地優先級，又稱內部優先級）優先級映射實現從數據原始攜帶的Qos優先級到內部優先級或內部優先級到Qos優先級的映射
-
對於進入設備的報文，設備將報文攜帶的優先級或者端口優先級映射爲內部優先級，然後根據內部優先級與隊列之間的映射關係確定報文進入的隊列
FIFO（First In First Out）
- FIFO先進先出隊列
- FIFO隊列不對報文進行分類，先進的報文將先出隊，後進的報文將後出隊
- FIFO隊列具有處理簡單、開銷小的優點
- FIFO隊列的缺點：不能有差別的對待優先級不同的報文
PQ(Priority Queuing)
- PQ優先級隊列
- 針對關鍵業務應用設計，關鍵業務在擁塞發生時，需要優先獲得服務減少響應延遲
- PQ調度機制：分爲高優先隊列、中優先隊列、正常優先隊列、低優先隊列，優先級依次降低
- 報文出隊時，會優先讓高優先隊列的報文發送完，然後再依次按照優先級發送報文
- 優點：對高優先級的報文提供了優先轉發
- 缺點：優先隊列可能出現“餓死”現象
如果高優先隊列中一直有報文等待發送，後面優先級較低的報文就遲遲不能得到發送，出現“餓死”現象
WRR（Weight Round Robin）
- WRR加權循環調度
- 根據每個隊列的權重來了輪流調度各隊列中的報文流
- 優點：避免了PQ調度的“餓死”現象
- 缺點：基於報文個數來調度，容易出現包長尺寸不同的報文出現不平等調度；低時延業務得不到及時調度
WFQ（Weighted Fair Queuing）
- WFQ加權公平隊列
- 根據隊列的權重（優先級）不同，劃分不同的帶寬，帶寬大的走的多，帶寬小的走的少
- 不同優先級算法：報文長度/(優先級+1)
- 優點：可保證低時延業務得到及時調度；實現按權重分配帶寬
- 缺點：無法實現根據用戶自定義靈活分類報文的需求
PQ+WFQ調度:重要的協議報文以及有低時延需求的業務報文應放入PQ調度隊列中，得到優先調度的機會，其他報文則可放入以WFQ方式調度的各隊列中
CBQ(Class-based Queueing)
- CBQ基於類的加權公平隊列
- EF隊列：滿足低時延業務
- EF隊列擁有絕對優先級，僅當EF隊列中的報文調度完畢後，纔會調度其他隊列中的報文
- AF隊列：滿足需要帶寬保證的關鍵數據業務
- 每個AF隊列分別對應一類報文，用戶可以設定每類報文佔用的帶寬。當系統調度報文出隊的時候，會按用戶爲各類報文設定的帶寬將報文進行出隊發送，可實現各個類的隊列的公平調度
- BE隊列：滿足不需要嚴格QoS保證的盡力發送業務
- 當報文不匹配用戶設定的所有類別時，報文會被送入系統定義的缺省BE類。BE隊列使用接口剩餘帶寬和WFQ調度方式進行發送
- 優點：提供了自定義類的支持；可爲不同的業務定義不同的調度策略
- 缺點：由於涉及到複雜的流分類，啓用CBQ會耗費一定的系統資源
隊列調度算法比較
qos queue-profile qos-Huawei
schedule pq 5 wfq 1 to 3 //配置Qos
int g0/0/0
qos queue-profile qos-Huawei //接口調用
dis qos queue-profile qos-Huawei //查看Qos
擁塞避免
- 隊列被裝滿後，傳統的處理方法會將後續向該隊列發送的報文全部丟棄，直至擁塞接觸（尾丟棄）
尾丟棄的缺點：
- 引發TCP全局同步：對於TCP報文，如果大量的報文被丟棄，將造成TCP超時，從而引發TCP慢啓動，使得TCP減少報文的發送
解決辦法：RED（Random Early Detection）隨機早期檢測，減緩TCP全局同步。在隊列未裝滿時，隨機丟棄一部分報文
- RED爲每個隊列的長度都設定了閾值門限，並規定：
- 當隊列的長度小於低門限時，不丟棄報文
- 當隊列的長度大於高門限時，丟棄所有收到的報文
- 當隊列的長度在低門限和高門限之間時，開始隨機丟棄到來的報文
- 引起TCP餓死現象：尾丟棄無法對流量進行區分丟棄，當TCP流量整體減小時，UDP流量不會減小，可能會導致UDP流量佔滿隊列，造成TCP餓死
- 無差別丟棄：尾丟棄無法對流量進行區分丟棄，尾丟棄可能會導致大量的非關鍵數據被轉發，大量的關鍵數據被丟棄
缺點2、3的解決方法：WRED（Weighted Random Early Detection）加權隨機早期檢測，每一種優先級都能獨立設置報文的丟包的高門限、低門限及丟包率，報文到達低門限時，開始丟包，到達高門限時丟棄所有的報文
WRED配置
drop-profile manager //創建模板-manager
wred dscp //使用wred識別dscp的值
dscp 8 low-limit 50 high-limit 70 discard-percentage 10 //dscp的值爲8時，低門限爲50，高門限爲70，丟棄最大概率爲10%
drop-profile ftp
wred dscp
dscp 16 low-limit 70 high-limit 90 discard-percentage 10
drop-profile video
wred dscp
dscp 24 low-limit 60 high-limit 80 discard-percentage 20
# Qos隊列和模板綁定
qos queue-profile qos-Huawei
queue 1 drop-profile manager
queue 2 drop-profile ftp
queue 3 drop-profile video
# 接口下應用Qos模板
interface E1
qos queue-profile qos-Huawei
流量監管與流量整形
令牌桶（CBS）
- TC代表令牌桶的令牌容量，即令牌桶中令牌的數量
- CBS承諾突發尺寸，即令牌桶的容量大小
- PBS峯值突發尺寸
- CIR承諾信息速率，每秒向令牌桶注入的令牌數量
- 單數單桶：
- 收到流量後，流量與令牌桶中的TC比較，流量大於TC，無法通過，標記紅色
- 流量小於等於TC，TC的大小減去流量的大小，標記爲綠色，通過
- 單數雙桶：
- CIR只向CBS令牌桶中注入令牌
- 當一個CBS令牌桶令牌裝滿後，會向PBS令牌桶溢出
- 收到一個流量A後，將流量A與CBS令牌桶內的TC比較，流量A小於TC，則TC減去流量A的大小，標記綠色，通過
- 當流量A大於CBS中的TC，小於PBS中的TC時，PBS中的TC減去流量A的大小，標記黃色，通過
- 當流量A大於PBS令牌桶中的TC時，直接標記紅色，無法通過
- 雙數雙桶：
- CIR會向CBS令牌桶注入令牌，PIR迴向PBS令牌桶注入令牌
- 收到一個流量B，先與令牌桶PBS比較，流量B大於PBS中的TC，則標記紅色，無法通過
- 當流量B小於PBS的TC時，在與CBS的TC比較，大於CBS的TC時，直接PBS的TC減去流量B的大小，標記黃色，通過
- 當CBS的TC也大於流量B，則PBS的TC與CBS的TC同時都減去流量B的大小，標記綠色，通過
流量監管TP（Traffic Policing）
- 對接受或發送（進出口都可以使用）的流量進行限速控制，限制進入網絡的突發流量，流量超速的部分直接丟掉
- 優點：可以實現對不同類別的報文進行限速
- 缺點：當鏈路空閒時，造成帶寬浪費；丟棄的流量可能要進行重傳
流量整形TS（Traffic Shaping）
- 限制流出某一網絡的某一連接的正常流量與突發流量，流量超出速率的會被緩存下來，只能用在出接口
- 優點：可以實現對不同報文分別進行限速；緩衝機制可以減少帶寬浪費，減少流量重傳
- 缺點：可能會增加延遲
總結
| 限速類型 | 優點 | 缺點 |
|---|---|---|
| 流量監管 | 可以實現對不同報文的限速及重標記 | 造成較高的丟包率；鏈路空閒時，帶寬得不到充分利用 |
| 流量整形 | 較少丟包報文，充分利用帶寬 | 引入額外的時延和抖動，需要較多的設備緩衝資源 |
以上內容均屬原創，如有不詳或錯誤，敬請指出。
本文鏈接：
https://blog.csdn.net/qq_45668124/article/details/107108716
版權聲明：
本博客所有文章除特別聲明外，均採用
CC BY-NC-SA 4.0
許可協議。轉載請註明出處！並附帶本文鏈接！