QOS，服務質量。顧名思義，就是爲了給現有的網絡提供一個更好的性能，讓各種網絡應用更加順暢的運作。當然了，如果你想讓網絡運作的更好，那你就得了解你自己的網絡啊。看看這個網絡中都運行着什麼網絡應用，且這些網絡應用比較關心的網絡因素有那些，比如網絡延遲、抖動、丟包率等等因素。我們就是通過控制這些對網絡應用有着關鍵作用的因素來調節網絡的正常、高速運行的。可以這樣說：QOS特性就是用來修理網絡數據傳輸過程中的一些小瑕疵的特性。只要你把這個數據路徑修理的足夠光滑，在某種程度來說沒有任何的阻礙了，那麼數據跑起來就會相當的流暢，什麼丟包啊，延遲啊，延遲抖動啊就都統統解決啦。速度和質量得到了雙保障。當然了，我們得對症下藥，知道問題出在了那裏。並且，這樣還不夠，我們還要知道問題“可能”出在那裏！這樣的話，我們就會把這種數據傳輸過程中的一些不良的隱患全部消除掉了。
我們使用了QOS後，可以說是我們想讓網絡怎麼地，網絡就怎麼地，完全處於你的控制中。不但實現了網絡數據的流暢傳輸，並且對網絡資源的使用也做到了精確的控制，不會浪費資源，也不會讓資源出現極其緊張的局面，即使有可能出現緊張的局面，那麼我們也有辦法來預防這種情況的發生。廢話了不少，這些都是使用QOS的好處。其實，仔細看看，也不是廢話，其中也談到了很多QOS的核心內容：
1. 因爲我們可以對各種網絡應用做到了精確的控制使用資源，那麼肯定就是對他們進行區別對待了，這也就是QOS中分類的概念啊。
2. 上面說到的，修理數據傳輸路徑上的小瑕疵，以求讓數據傳輸的更流暢，這也就是後面我們將要降到的流量調節啊。
3. 在最後面我們還提到了，出現資源緊張的局面，我們可以採取措施來搞定，這裏也就說到了後面將要詳細介紹的擁塞管理和擁塞避免。
OK，開始正題。
QOS的好處不說了，那麼我們有必要認識下QOS的倆大門派：集成QOS（IntServ QOS）和區分QOS（DiffServ QOS）。
來簡單的介紹下他們倆個：集成的呢，就是用硬件方式來實現的。都是固化在設備裏面的一些程序，也就說他們的靈活性不怎麼地，這種類型的QOS只可以用在那種面向的技術升級很慢的環境中，如果升級很快的話，那麼你更換設備就得跟上，那還了得啊！虧大了~~這種QOS的實現，是建立在網絡對網絡應用的處理行爲是可預測的基礎上的。它的主要實現依賴於一個重要的協議：RSVP(Resource Reservation Protocol) 資源預留協議。當一個支持RSVP的應用在發送數據之前，他們利用這個協議向RSVP網絡請求特定類型的服務，並且應用將他的流量配置文件（traffice profile）發送給網絡，告訴這個網絡，需要按照這樣的要求，給我分配資源，滿足了這樣的環境後，俺才發送數據咧。當網絡得到確認後，纔可以進行發送數據。有了這樣的應用環境了，我們還得有一些控制措施啊，這就得通過在PDP(Policy Decision Point，策略決策點)使用COPS(common open policy service，通用開放策略服務)來集中完成許可控制。可以看出：這個集成QOS的實現靠的是RSVP+traffice profile + COPS來完成的。就這麼點活~~~
那再看看DiffServ QOS 。這個傢伙，相對前面的就比較靈活了，可以說是爲現在的網絡量身打做的。這個這種類型的QOS中，數據流是要進行分類的，然後，我們可以進一步的對各種不同類的流進行的控制。這個控制的實現就是通過策略表來實現的。這樣簡單一說，我們就該知道了，實現他們是要有個類表，然後還得有個控制表----策略表。這年頭，幹啥不都講究策略啊，呵呵、、、QOS也不例外。我們現在一般使用的都是後者。所以下面詳細講解。我們通過了解他的一些特性來理解他的工作原理和工作過程
區分服務QOS有一下特性：
1． 分類
2． 標記
3． 流量調節
4． 擁塞管理
5． 擁塞避免
我們一個一個的來分析各個特性的特性和實現。
分類：顧名思義，顯然就是對網絡中的的數據流進行不同的分類，區別對待。那麼分類的依據是什麼呢？分類的方法有哪些呢？我們研究數據包的時候，有時候關心的是2層的，還有的時候是主要關心3層的。那麼對於不同的層次的數據來說，分類的依據是一樣的嗎？分類的依據是系統默認的呢，還是可以進行人爲設置的?帶着問題看下面的分析！
QOS主要進行分類的依據就是DSCP（different services code point ：區別服務編碼點）。其實，這裏說的這個8位的DSCP值更準確說應該是內部DSCP值。後面就會知道了。
對於2層的數據幀來說，我們使用COS來區分不同的數據流，並且這個3位的字段只出現的ISL或者802.1Q的封裝幀中。存在VLAN標記中的，只佔3位。
對於3層的數據包來說，我們使用的是IP數據包頭中的TOS字段來表示的。TOS在IP數據報頭中有一個字節的長度，但是並不是所有的位都來擔任進行區分不同IP數據流的服務的。而只是高6位。其中高3位表示的是IP優先級。所以我們一般看的就是IP優先級，平時的映射關係說的也是IP優先級和內部DSCP的映射。中間的3位都是0。
現在看來，我們使用的是COS或者TOS的高6位。但是上面說是使用DSCP，所以就會有這倆者和DSCP(內部)之間的映射關係。不過，我們平時說的時候也是直接說DSCP，而不說COS和TOS 了。
典型的以太網數據包
|
2層數據報頭 |
3層數據報頭 |
數據 |
第二層ISL幀
|
ISL包頭（26字節，3位用於COS） |
被封裝的幀 |
FCS（4字節） |
第二層802.1Q幀
|
前 導 碼 |
起始幀分隔符 |
DA |
SA |
標記(3位用於COS(用戶優先級)) |
其他第二層報頭 |
數據 |
FCS |
第三層Ipv4數據包
|
版本/長度 |
TOS(1字節) |
長度 |
ID |
標記 |
TTL |
協議 |
校驗和 |
IP-SA |
IP-DA |
數據 |
其中TOS的高3位表示IP優先級，高6位表示的DSCP值。
不管如何，COS和TOS都是要和內部DSCP進行映射的，無論是人工映射，還是默認的映射關係。3位COS和3的IP優先級是一樣的。只是COS作用在2層，而IP優先級是對於3層。當然了，他們映射到一個內部的DSCP得到的數值也是一樣的的。
OK了，就是這樣，QOS通過這些就可以將非常的多的數據流，簡單的規劃分類爲幾個大的數據流，不關你原來是什麼模樣的，只要你進這個類，就得按照這個類的規矩辦事，該減速的減速，該拋錨的拋錨。讓你咋滴就咋滴。
既然說到了歸類了，那就談下，如何建立這個類吧。
分類肯定得有很多種方法吧：
1． 按接口的信任模式；
2． 按接口的手工分類；
3． 按數據包（基於ACL）；
![]()
![]()
4． NBAR(network based application recognition)基於網絡應用的識別；
接口的信任模式：
當我們沒有使用QOS的時候，對數據包的處理是處於盡力而爲best-effort等級的，也就說從端口裏進來的數據都是一個樣的，根本就沒類的概念。這個時候呢，如果數據包格式中有DSCP了，不管原來的是多少，只要經過端口進入到交換機的時候，都將DSCP設備爲0。也就說呢，不信任以前的那些DSCP值，即使你本來的數據中包含着一個DSCP，那也白搭。現在，我們要講的這種分類方式，就是要相信這種數據中的DSCP值，按照這些數據中本來就有的DSCP來進行分類，因爲不同的接口接收的數據是不同的，有的是2層的，有的是3層的。所以呢，當我們在接口上設置這種信任數據中的DSCP的命令的時候，得考慮清楚了。相關命令：接口配置模式下，mls qos trust cos | ip-preference | dscp
配置了這些命令中的相關的命令後，說明設備就相信這個接口接收到的數據包中的COS值，IP 優先級，DSCP值。進入到設備內部後，就會按照默認的映射方式，映射到內部DSCP值。然後設備就會根據這個內部DSCP對數據流進行有條不紊的操作。
讓我們再來看看，上面我們提到的這個命令中的參數。前面我們說了IP優先級和COS是一樣的，爲什麼在這裏都出來了呢？那肯定是有不同的地方啊。OK了，COS使用在2層，IP優先級用在3層。那麼IP優先級和DSCP呢？他們好像也是一回事啊~~爲什麼也會同事出現了呢？那麼有什麼區別呢？這裏之所以把他們倆個放在一起寫出來了，是因爲有的設備只支持IP優先級，而不認識DSCP，那麼以DSCP來標示類的網絡設備與之交流的時候，就會進行IP優先級和DSCP之間的映射，這個是非常簡單的，只要把DSCP的後3位全部寫成0就OK 了。就可以實現DSCP和IP優先級之間的完美映射了。
下面我們接着說，當設備信任了端口接收的數據中的DSCP、COS、IP優先級，那麼進來後就可以按照默認的映射來進行處理（處理行爲在策略表中規定着呢）。那麼我們是否可以讓他們按照我們個人的意願來進行映射呢，而不是默認的映射方式。答案是肯定的，我們完全可以根據網絡應用需要將從某個端口進來的數據的DSCP映射到一個我們想要的內部DSCP值上去，就是利用命令：全局模式下，mls qos map cos-dscp * * * * * * * *
其中的*號表示的是和COS對應的8位數字。搞清楚了是誰到誰的映射：是COS到DSCP的映射，當然咯，後面的8位數表示的也是內部DSCP值。
以此類推，肯定也可以進行IP優先級到DSCP的映射咯：mls qos map ip-prec-dscp [dscp-value]
下面，咱就講講如何根據數據包來進行分類，也就是那種基於ACL的。其實很簡單，就是將我們建立好的ACL和要建立的CLASS關聯起來。就這麼簡單，符合ACL的所有數據，我們就看做是一類。分類不是關鍵，關鍵是對他們進行更加精確和詳細的控制------策略表。
具體實例：
1．全局配置模式下：class-map match-all [name ]
Match [……]括號裏面就是具體的一些條件。（完善類表的過程）
這些條件根據不同的設備支持的QOS的特性的多少而有所差異。
2．全局配置模式：policy-map [name ]
Class [name]
? （完善策略表的過程）
就會顯示這個設備支持的所有策略動作。
其中比較關鍵的還是第2中的第二個命令，它的作用就是把這個類表和策略表關聯起來。
3．將建立好的策略表應用到特性接口的出口或者進口的方向上。但是，並不是所有的交換機都支持出口策略的。命令：interface type slot/port
Service-policy {input | output } [name]
4．最後一個，也是最重要的一個：將該端口設置成信任端口。因爲我們實施這些策略的動作的時候，人家是依據DSCP來的。如果是不信任這個接口來的DSCP的話，那麼就無法進行這些策略動作了。
接下來要講的就是最後一種了：NBAR----基於網絡的應用識別。簡單的說，這種分類方法，就是比上一種方法中的類表和策略表的定義方面，又多了一些參數，也就說功能更加完善了。基本步驟上面都是完全一樣的。
到這裏，我們就已經可以對數據進行詳細分類了，各種方法都有。但是應用得具體情況，具體分析。
標記
這裏需要各位朋友清楚的是：這個“標記”不是一個名詞，而是一個動詞。就是一個修改的動作。例如，我們對某個參數進行標記，那意思就說是我們我們對這個參數原來的數值進行了修改。
這個特性，可以讓我們實現修改從某個特定的端口進來的數據包DSCP值，這樣的話，就達到了我們對某些數據流進行特定服務的目的。我們可以認爲在網絡界確實有默認的一些應用和相應的DSCP的映射關係。但是，除了這些，我們還可以根據網絡的具體環境人爲的將一些我們特別關注的數據流打上一個我們自己想要打上的DSCP。並且，我們後面建立的CLASS—TABLE和POLICY—TABLE 中都要對這個DSCP值的數據包進行相應的操作設置。然後，這個值進去設備後，QOS就會根據這個DSCP而得到的內部DSCP對這些數據流進行一定的操作。這個就是QOS的標記特性。實現這個特性的命令是：在相應的接口下，使用
Mls qos dscp [dscp-value] 數值範圍是0-----63；
Mls qos cos [cos-value] 數值範圍是0------7
顯然，這些得到的DSCP值或者COS值都不是QOS特性實施的依據-----內部DSCP，而是這些值經過映射後的DSCP值，叫做內部DSCP值。
如果，我們希望在通過ACL對通信流進行分類的策略映射表中配置標記。那麼我們需要使用下列類別映射表操作命令：
Set ip dscp [ip-dscp-value]
Set ip precedence [ip –precedence-value]
Set cos [cos-value]
從文章的敘述佈局上，我們就可以看的出：上面的那種在接口模式下強制改變進來的數據的DSCP值的方法和後面的這種軟性的通過策略方法來實現改變數據的DSCP值是有點區別的。因爲他們需要面向的對象的確定方式不同。前者，就可以精確到某個具體的端口的；而後者，面向的是那些分佈在網絡中各處的，但是具有同樣的特定的數據（這個特點就是ACL來定的）
流量調節
在流量調節這方面，我們可以通過倆種方式來達到這種效果：一個是利用策略，一個是利用整型。
這倆種方式顯然是並列的關係，中間也是存在着很多差距的。現在用最火的一個還是通過策略來進行流量的調節。並且，對於CISCO不同的設備，實現流量調節的方式也是不盡相同的。在CISCO路由器和交換機都支持策略和整型。只是支持和實現的方式不同。對於CISCO路由器來說，支持倆種整型方法：GTS(generic traffic shaping通用流量整型)和FRTS(frame relay traffic shaping幀中繼流量整型)。對於運行IOS軟件的路由器，它使用CAR(committed access rate 承諾接入速率)工具來支持流量策略。而對於CISCO交換機支持流量策略和整型的方法和配置和路由器稍有不同。
其實，整型和策略機制都控制“通信流通過交換機傳輸的速度”，他們都使用分類來區分通信流，但是，他們之間還是有一些區別的。
整型測量通信流的速率（採用這種機制的時候，是需要由一個指定速率的），並推遲超額通信流的傳輸，確保通信流的速率不超過指定的值。
所以呢，通過這種流整型量調節機制，可是實現那種突發的通信流量。這樣呢，就可以減少交換機丟棄的數據了。其實說白了，這種調節機制的核心思想就是：通過測量數據流的速率，來確定哪些不合格的數據，並且推遲這些超越規定的通信流的傳輸時間。這樣一來，也就是可以保證所有的這些數據都是可以傳輸出去的，但是付出的代價就是：延遲有可能會大大的增加。
所以呢，這種實現機制對與那種對延遲非常敏感的網絡應用就非常的不好。
而策略對超過指定速率的通信流採取特性的措施，不再是推遲或者是緩衝通信流了。也就是說對於這種機制中，無論如何都不會以增加延遲作爲代價的，而是對這些違規的數據流進行一些具體的處理措施。通常情況下，對於這種數據都是進行丟棄處理了，但是，我們現在可以使用其他的處理措施，比如信任或者標記。也就是說，我們又把這些數據流和靈活的策略結合在一起了，以後對這些不法分子處理起來就靈活的多了、、、、
因爲策略可以支持很多的參數啊，比如速率啊，突發量啊，合規措施，超額措施，違規措施，
其中的參數，最難搞定的就是突發量了，所以我們這裏給出了一個計算突發量的公式：
突發量=2 X RTT X 速率。其中，RTT是TCP繪畫的往返時間。這個參數的獲得我們可以通過簡單的命令ping 來獲得。而速率是端到端的吞吐量。
在CISCO交換機上，有3種類型的策略：
單一策略器：應用在單個接口上的策略器。
聚合策略器（aggregate policer ）：將策略參數應用到一組接口。是把這一組接口看做一個整體來運作的。例如，我們把一個限制流量速率不超過75M/S的聚合策略器運用到一組接口上，那麼他所表達的意思就成爲了：這組接口的總流量將不能超過75M/S。而單一策略器只可以運用到單個接口上。
微流策略(microflow policing ):它是針對單“個”（可以理解成是單種流）數據流的。交換機將策略參數應用於策略映射表中的每種類別。
通過上面的3種類別的策略器的描述，我們是不是覺得最後這個更好點啊~~~我覺得是，因爲這個用起來更加靈活，並且也更加到位。其實呢，這3種策略器的實現都是要和類別映射表結合起來的。因爲爲了就是實現這個控制那些我們可以指定的那些數據流啊（就是我們打了標記的，分了類的）。實現策略器和有一定特點的數據流的結合。我們需要做的工作就有2個：第一是定義、完善這些策略器的內容，第二是將這些除了器和類別流結合起來。
定義：全局配置模式下police [ ] 後面有很多的參數，到時候打個問號就好了，什麼參數，及其解釋就都出來了。一般也就是限制個速率啊，以及對違反這些規定的措施，比如說drop。
關聯：在策略映射表中，使用上以前定義的策略器就可以了。這個策略器，從整體上看，策略映射表就將其看作是一個處理動作。當然了，這個策略映射表中得包含着那個需要的分類表啊。否則，就不會完成映射了啊~~
這些都是非常簡單的，他們運用起來的方式都是一樣的，主要是明白他們之間的區別。
擁塞管理
擁塞管理是QOS一個非常重要的特性。後面的擁塞避免同樣是。他們都是作用在出站口上的。我們使用QOS，就是爲了讓數據流按着我們的意思去走。或者快，或者慢，超出了我們設置的界限，該如何處理，是丟棄還是採取其他的一些比較溫柔的處理措施。對於一個設備來說，數據有進有出，這個設備上出去的數據流，在另一個設備的角度上看，這就是進來的數據流，所以呢，我們要保證出去的這些數據流都是按着我們個人的意願來走這個路的，至於到了對端的設備如何來處理這些進的數據，那是他們的事情。而我們現在要做的就是儘量的讓我們這個設備上出去的數據更加如人意，爭取做到數據流最大程度上傳輸順暢，並且不給那個對端接受的設備帶來太大的負擔。
我們都知道，一個端口是包含多個隊列的，包括輸入隊列和輸出隊列，並且每種隊列都不是一個的。我們這個擁塞管理就是運用在這些輸出對列上的。當數據進來的時候，是會被劃分到不同的輸出隊列的。根據什麼來分呢？爲什麼要區分開來呢？既然區分了，那又有什麼不一樣的處理措施呢？這些問題，是我們知道了這個特性是運用在端口上的，還是具體到端口的各個輸出隊列上的時候我們必須想到的。帶着這些疑問，我們來詳解。
在默認的情況下呢，也就是沒有使用QOS特性的時候，交換機的各個端口中的各個隊列對待所有的數據都是一視同仁的，在一個接口中使用的派對方法是：FIFO，先進先出。就是說誰來的早就先解決誰。是有先來後到的這麼一說的。看起來，挺合理啊。但是，當今社會那裏有這麼“公平”的事情啊，不都是“老大”說了算的嗎？呵呵、、這裏的老大就是指的那種老大的身份，誰的地位高，誰就說了算，就先解決誰的問題。
那既然出現了這種不公平的問題，肯定得是有身份依據的。不同身份的數據分配到不同的輸出隊列。這樣一來，我們可以肯定的是：這個特性使得有依據來區分各個隊列，並且還可以把不同身份的數據安排到特定的隊列中，這不就是特定DSCP值的數據分配到特定的隊列嗎？嘿嘿、、、、這是我們的猜測。我們必須得這樣，得先有自己的想法，然後戴着你個人的這些想法去看書，或者是和作者的想法一致，或者是撞擊出智慧的火花，對我們來說都是另外的一種收穫，我們記憶知識還會更牢固。
來區分隊列：
不同型號的交換機的端口支持的隊列是不一樣的，有支持3個的，4個的，甚至2個的。並且他們在沒使用QOS的時候，身份還是一樣的。即使他們這些隊列中有幾個個別的隊列的骨子裏有中特別的氣質，哎、、、、但是外界條件不允許啊~~沒辦法，也只能是藍領一個啊。但是當我們啓用了這個QOS特性後，啓用了端口隊列的優先級後，那些有着內在氣質的隊列，就可以鶴立雞羣了。與衆不同！默認情況下，內在的氣質是與生俱來的，只要我們啓用了這個端口隊列的優先級特性，某些隊列就成了優先級隊列，在這個隊列裏排隊的數據都是優先處理的，只有當這個隊列中的數據處理完了，其他的隊列的數據纔開始進行處理。所以呢，以後我們就可以把一些情況比較緊急的數據放進這個隊列裏，當然了，這個問題就牽涉到了後面的特性身份的是數據和隊列的映射問題了。OK，這是默認的情況下，但是呢，氣質呢是可以後天培養的，所以我們也可以對平常的那些隊列進行特性的培養啊，使我們心儀的隊列成爲優先級隊列，而不是使用默認的優先級隊列了。也就說，這個優先級隊列的指定的操作性還是很大的嘛，嘿嘿、、、、具體的實現命令是這樣的：
使用默認的優先級隊列：
端口模式下：priority—queue out （cisco 3500系列，默認的是隊列4）
不同型號的設備的配置命令是不同的。
使用後天形成的優先級隊列：
wrr—queue priority—queue
wrr—queue cos—map [queue id ] [threshold 閥值] [cos value ….]
其中這個閥值是什麼意思，我到現在還真的不是很瞭解，因爲對應着一個隊列可以有好幾個閥值。非常不解。後面的COS說的是出站COS。而不是內部DSCP。
通過使用這個命令，我們就可以將一定COS值的數據映射到特定的隊列中，並且這個隊列也就是我們說的那個後天形成的優先級隊列。
通過這幾條簡單命令的闡述，我們把上面說的倆個問題都解決了：隊列的區分和隊列與特定數據流的映射。
我們都知道，QOS對數據包進行特定處理的依據是內部DSCP。我們外面進來的數據DSCP在端口的時候有可能被重改寫（相關的命令前面已經提到過）或者是通過策略表中的動作來實現DSCP的更改。所以呢，我們稱這個狀態下的DSCP值（對於2層的數據來說就是COS，對於3層的來說就是IP優先級）爲外部DSCP，即使被更改了。這個數值到了交換機的內部後，還得進行一次映射，即：COS/IP優先級到內部DSCP（QOS特性處理數據的依據）的映射。這個映射表呢我們也是可以盡心改變的，在前面似乎已經提到了相關的配置命令。當然了，這樣說，那麼肯定就會存在一個默認的映射關係表啊！最後的時候，如果時間允許我會盡量的給大家畫出來。我們一直在強調這個問題：這個內部DSCP只是在內部的時候使用的。
上面，我們對命令的參數進行了一定程度上的解釋，這裏主要的就是那個後面的COS值，這個值說的是出站COS，而不是內部DSCP值。出站是根據這個出站COS來對數據進行傳輸處理的。看來，這裏還有一個內部DSCP到出站COS的映射過程。肯定的啦，存在一個默認的映射關係表的，並且呢，我們也是可以人爲的改變這種映射關係的。
相關的配置命令：
Mls qos map dscp—cos [dscp value ] to [ cos value]
我們現在是，可以區分數據了，可以區分不同的隊列了，也可以區分把這些數據有區別的映射到不同的隊列上了，那接下來的問題就是最關係的問題了：對各個隊列的處理又是怎樣的呢？
我們可以對各個出站隊列設置的特定的監測參數，以及一個特定的閥值。比如爲各個隊列指定一定的帶寬，後面具體的參數的取值範圍是1----255。再比如隊列長度，參數的具體取值範圍是1%---100%。這些監測參數說明：我給你相應方面的資源就這些（是對各個隊列而言的）
端口配置模式下：
Wrr-queue bandwidth [weight for queue1] [weight for queue 2] …..[weight for queue n]
Wrr-queue queue-limit [low priority queue weight ] [medium priority queue weight] [high priority queue weight ]
在這裏，第二個命令中，大家都看到了出現了低級隊列，中級隊列和高級隊列的說法。其實，
![]()
在端口的隊列中確實有這麼一種說法的：隊列1屬於低級隊列，隊列2數據高級隊列，再往上就是屬於嚴格優先級隊列了。所謂的嚴格優先級隊列就是我們說的那個優先級隊列。不管是人爲指定的，還是那個默認的。我們都叫它嚴格優先級隊列。
但是如果這些分配個各個隊列的資源都快用光了或者都用光了咋辦啊？當然是產生擁塞了啊，這些是我們最大的忌諱啊~~~咋辦呢？這就是擁塞避免的事情了。
擁塞避免
簡單來講，快擁塞的時候的一般的處理措施當然就是丟棄後來的那些數據咯，但是如果後面來的那些數據還是非常的重要的，那怎麼辦呢？我們首要的原則就是爲了保證這些重要的應用順利實現嘛，所以，我們丟棄後來的這些數據包的時候就得有一定的選擇了啊，
具體的配置命令如下：
Wrr-queue random-detect min-threshold [queue id ] [thr m%]
Wrr-queue random-detect max-threshold [queue id ] [thr n%]
這倆個命令也就說：當相應的id的隊列中的數據填滿程度達到了該隊列的m%時，開始進行丟棄這個隊列的數據。當達到n%的時候就開始採取尾丟棄的方法，也就說說達到這個程度，這個接口的在接受到的任何一個數據包都進行丟棄。
總結一下：
其實，說白了，QOS就是保證數據經過的每一個環節都可以得到人爲的精確控制。通過什麼來實現啊，還是得說那個內部DSCP。但是這個東西是用在設備內部的。
那咱就看看，整個數據傳輸的過程中，有過幾次外部的DSCP(COS或者IP優先級)和內部DSCP的映射。
1． 進設備端口的時候，得需要給數據加上一個，爲什麼啊，爲的就是讓這些數據能有一個COS或者IP優先級好和內部的DSCP映射啊，然後通過這個東西對數據進行分類啊啥的，就是爲了得到一個可以對這些數據進行區別對待的依據。
2． 出設備的時候，我們還需要把內部的DSCP映射到COS，它叫做出站COS,爲的就是實現擁塞的管理。因爲擁塞這傢伙就靠這個活着呢。
搞清楚了這麼個流程，中間的那些具體的處理措施啊，就簡單多了。
大家有沒有覺得擁塞管理和擁塞避免與流量調節有點彆扭啊？我開始看起來的時候，就總覺得他們在說一回事，有點犯迷糊，呵呵、、、其實，你瞭解了數據在端端之間的經過的每一個坑吭砍砍的就知道了，他們說的不是一回事，真都不是一回事，呵呵、、、、、考慮考慮！！
凌晨2點，整理完畢，有點多，大家慢慢的看，仔細的看。希望對大家有所幫助。
中間如果出現什麼問題，還請大家多多指正~~謝謝！我會繼續努力，爭取寫出更好的文章。
大家有什麼想法可以和我交流，讓我們共同進步。
不好意思，差點忘記了，我還得給大家寫上上述文章中設計到的映射表。
默認的映射關係表：
COS到內部DSCP的映射關係表
|
COS值 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
內部DSCP值 |
0 |
8 |
16 |
24 |
32 |
40 |
48 |
56 |
IP優先級到內部DSCP的映射關係表
|
IP優先級 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
內部DSCP值 |
0 |
8 |
16 |
24 |
32 |
40 |
48 |
56 |
內部DSCP到COS的映射關係表
|
內部DSCP值 |
0~7 |
8~15 |
16~23 |
24~31 |
32~39 |
40~47 |
48~55 |
56~63 |
|
COS值 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
推薦專欄
掃一掃,領取大禮包
Ctrl+Enter 發佈
發佈
取消