上一篇關於 文章中，我們講到了報文分類和標記，這篇文章讓我們再來了解一下調度機制。
上文中，我們的語音、視頻、數據這三份流量進入到了各自的隊列中，然後我們需要對其進行調度。調度怎麼理解呢？就是如何安排進來的流量有秩序有主次地出去。調度分為兩種：
① 基於隊列的調度：內部是虛擬出了7個隊列。假如語音進入了隊列5、視頻隊列4、數據隊列3. 基於隊列的調度它是怎麼工作的呢？
首先基於隊列的調度分RR（輪詢）——WRR（加權輪詢）——WFQ（加權公平）——PQ（按優先級出流量）
很明顯語音（隊列5）>視頻>數據，則RR就語音走一個包，視頻走一個包，數據走一個包，然後循環 RR。雖說非常公平，但我們要的是區別對待，高優先級先走，低優先級排後面。所以又開發了WRR，我們給語音隊列加一個權重值3、視頻2、數據不給，這樣每一個循環語音就走3個包，視頻走2個 數據還是走1個，這樣就解決高優先級先溜的問題。不過還有一個問題，現實中，我們通常是以帶寬來衡量的，假如數據的一個包1500字節，語音1個包100個字節，那麼這樣的一個循環，數據反而佔用的帶寬更高。
所以又開發了WFQ，加權又公平，基於帶寬來分配，語音分30M、視頻分20M、數據分10M，這樣就解決了上述問題。
那麼PQ是什麼，PQ就像一個莽夫，往前衝就對了。語音優先級高，那我就先把語音的流量走完，再走視頻再走數據。這樣雖然高優先級的很開心，但如果語音一直有流量，那麼視頻、數據就一個包都發不出了，會造成低優先級流量餓死的情況，顯然也是不可取的。
不過一般而言，現實中一般會採用結合的方式比如PQ+WRR，PQ+WFQ這種方式。
講完基於隊列的調度，接下來講講基於類的調度。
② Class Based Queueing（CBQ）基於類的加權公平隊列是對WFQ功能的擴展，為用戶提供了定義類的支持。CBQ首先根據IP優先級或者DSCP優先級、輸入接口、IP報文的五元組等規則來對報文進行分類，然後讓不同類別的報文進入不同的隊列。對於不匹配任何類別的報文，送入系統定義的缺省類。
那CBQ提供了哪幾個隊列呢？
EF隊列：滿足低時延業務
AF隊列：滿足需要帶寬保證的關鍵數據業務
BE隊列：滿足不需要嚴格QoS保證的盡力發送業務
我們現在通過簡單流分類or複雜流分類將語音分成一類，視頻分成一類，微信數據分成一類，發語音的時候，我們應該會對時延有著很高的要求，視頻則較高，發微信呢，卡個1-2s也還能接受，所以我們會將語音類流量，送入EF隊列，視頻類流量送入AF隊列，剩下的微信流量就默認就進入我們的BE隊列。
在EF隊列中採用PQ調度，在AF隊列中採用WFQ，在BE採用WFQ，所以我們會為EF隊列設置一個最大帶寬限制（畢竟用PQ免得BE的流量餓死了） ；為AF隊列設置一個最小帶寬限制，剩下的帶寬給BE用。在EF中還有一個特殊的隊列LLQ， LLQ比EF更優。
這樣我們就調度完了，接下來是不是該出去了？我們可以在出接口的地方做流量管理。講流量管理前我們再想想，假如流量真的很多，我再怎麼調度，所有隊列都滿了，但是入口還一直進來流量，這個時候怎麼辦？會發生擁塞對吧？堵住了，難進，出去又慢。這個時候我們就要講一講發生擁塞時候的擁塞避免。
擁塞避免
當我們擁塞時，隊列滿了會造成什麼問題呢？尾丟棄，就是後面進來的流量直接就丟包了。所以尾丟棄會造成3個問題：1、不加分區丟包；2、TCP全局同步；3、TCP流量餓死。接下來我們來進入TCP的領域。
TCP是一個可靠安全的傳輸協議，有確定機制，丟包會重傳等。假如TCP丟包了，等待重傳計時器超時，然後重傳，稱超時重傳；假如TCP丟了一部分的包，接收方能夠通過序列號等參數，確定你發來的數據不完整，這時接收方會立刻連續重複發三個ACK報文，發送方立刻意識到接收方剛剛沒收完整我發的包，立刻重發，稱快重傳。
接下來我們來看看在網絡中，我們的TCP如何啟動並且發送數據的（TCP的一個窗口）
我們來看一下這個圖，並解釋一些名詞：
擁塞窗口cwnd是發送方為一個動態變化的窗口叫擁塞窗口，擁塞窗口的大小取決於網絡的擁塞程度。
ssthresh是慢啟動門限（這裡我們設置成16）cwnd=24時為閾值（默認是56636B）;
慢開始也稱慢啟動，是指建立TCP連接時，把cwnd設置=1（536B）然後進行一個指數增長。
接下來進入重點：
現在有一個TCP連接——>開始一個慢啟動從cwnd=1開始指數增長到cwnd=16時候到達門限了，開始擁塞避免，就進入一個加法增長（發送的報文如果都收到ACK回覆，cwnd會加法性的+1+1+1）——>到達cwnd=24閾值時檢測到了擁塞——>立即把ssthresh門限降為閾值的一半也就是12，即新的ssthresh=12，為上圖的②+③。接來下有兩種處理行為：
① 擁塞後如果是超時重傳造成的丟包，則cwnd=1，此時的ssthresh則為12，為上圖的④+⑤
② 擁塞後如果是快重傳造成的丟包，則cwnd=12，進行一個擁塞避免，為上圖的①
大家捋清楚上圖後，接下來TCP全局同步是什麼意思呢？上圖是一個TCP連接，假如有100個N個TCP連接用時進行，那麼這100個TCP連接同時到達閾值，把閾值下降一半，會造成帶寬的浪費；如果50個先到閾值，下降一半，再慢啟動，另外50個就可以利用之前50個的帶寬。
那TCP流量餓死又是什麼呢？TCP流量餓死是指當TCP在cwnd很小時，如果UDP流量大量持續進來，就會造成TCP的cwnd一直很小，最後TCP流量無法傳出則稱餓死。
那我們怎麼解決這些擁塞造成的問題呢？在我們擁塞避免的階段，我們用一個叫做wred（加權早期隨機檢測）的技術，這個技術是我們為每一個隊列配置一個丟棄模板，在隊列還沒滿時，高優先級的丟10個包，低優先級丟20個包，這樣處理，有效解決了TCP全局同步+TCP流量餓死+不加區分的丟包。
閱讀更多 華為認證培訓中心 的文章
