資料鏈路層的流量控制
資料鏈路層的協議一個很重要的功能就是進行流量控制，那麼鏈路層是怎麼進行流量控制的呢？
首先什麼是流量控制？為什麼要進行流量控制？
我們看下面鏈路的一跳。傳送發給接受方傳送資料，如果傳送方每1秒傳送100包，接收方只能1秒處理50包，會出現什麼現象呢？接收方會在快取中大量快取接受的包，直到快取區滿了。滿了之後會怎麼樣？接著就會出現最不能容忍的情況，緩衝區溢位，也就是丟包的現象。所以接收方一定要在緩衝區快滿的時候通知傳送方讓他降低傳送速度，這就是鏈路層的流量控制。流量控制用於確保實體傳送的資料不會覆蓋接受實體已接收的資料。
那麼流量控制有那些方法呢？主要有兩種：停-等流量控制和滑動窗流量控制。下面具體解釋一下：
1. 停等流量控制：傳送實體傳送一個幀，接受實體接收處理完之後必須發回一個對於這個幀的確認表示自己同意接收下一個幀；傳送方收到這個確認之後，才能傳送下一個幀。所謂停等，接收方能夠簡單的通過停止傳送確認的方式來阻止資料流的傳送。
停等方式的有點很明顯：它的控制非常簡單，傳送方除了資料就是接收確認，接受方每次就傳送一個確認就行。但是他也有很明顯地缺點：它的效率不高。考慮下面這個情景：如果傳送一個包長424b,兩端相距1000km, 光纖的傳輸資料速率為155Mbps，那麼傳播時間（實體傳送資料的時間）Tframe是424/155000000 = 2.7*10^-6. 但是在介質中的傳輸時間Tprop卻達到了100000/30000000 = 0.33*10^-2. 對於停等協議，效率只有α= Tframe/(Tframe+2*Tprop)=0.04% 。也就是線路很長時間都是空閒的，效率很差。
2. 滑動視窗流量控制 所以我們很自然的想到，既然任何時刻都只有一個傳送效率很低，那麼我們一次傳送n個，然後等待一個確認，不就會讓效率高了嗎？這個就是滑動視窗協議的思想。滑動視窗協議：利用視窗控制連續傳送的資料量。注意：必須為每一個幀分配一個序號，接收端需要按照序號接收，進行校驗是否出錯。
如上圖所示，傳送視窗為5，所以一次最多就能傳送五個幀；接受視窗只有1個，所以一次只能接收1幀。這裡可以看出來，傳送視窗和接受視窗不一樣大也是可以的。傳送方一次傳送5個幀，接收方收到之後予以確認，發方收到確認之後視窗前移，接著傳送下面的幀（5,6,7,0...）。收方傳送確認之後視窗也要前移，等待下一個幀的接收。
這裡應該注意：第一，序號是迴圈使用的，這很好理解，因為一共就那麼多儲存空間，肯定從7之後要回到0否則一直增大下去就會沒有儲存空間的。第二，滑動視窗只是一個序號，滑到這個視窗就傳送或接收對應的幀，而不是代表窗口裡面是這個幀。事實上應該是有專門的緩衝區來存這些幀，滑動窗滑到那裡，就對應滑動窗的序號去緩衝區取那個有幀號的幀就行了。
我們看上面這個圖。最開始在滑動視窗中的是0~4一共5幀，接受方滑動視窗只有1幀，序號為0. 傳送方一次傳送了兩個幀0,1，那麼滑動窗滑了2位，幀號變成了2~6，接收方收到了0,1，那麼他的滑動窗也就變成了2，表示下一步我期待接收的是幀序號為2的幀，再給傳送方傳送ACK2,表示我正確接受了前兩幀（0和1），等待開始接收2幀了。更具體來說：
傳送方連續傳送了5幀之後，每次再發送，視窗的 下限 前移（視窗變小），每次接收到之前的確認，視窗的 上限 前移（視窗變大變回原來的大小）。而對於接收方，每次接收到幀之後，視窗的 下限 前移（視窗減小），收到幀確認無誤傳送了確認之後， 視窗的 上限 前移（視窗變大，變回原來大小）。這樣保證接收方和傳送方的視窗大小都保持相對不變，不會隨著傳送過了一段時間變大或者變小。
對於傳送方，他只能傳送傳送視窗內序號對應的幀。對於接收方來說，傳送確認的前提條件是他接收到的幀落在自己的接受窗口裡面，並且校驗正確，這樣才能發回確認，發回確認之後再把自己的視窗上限前移。
對於滑動視窗協議，它的效率明顯變高了，因為它可以一直髮送。如果視窗大小N要大於傳輸延遲和傳送時間之和T（這個時間可以理解為一個幀從傳送，到通道中的時間，再到確認返回的時間三者之和），那麼就可以一直髮送了，所以效率可以達到100%。如果N<T，那麼最多把N個幀一起傳送，沒法再多傳送了，因為迴圈序號的問題，不能同時存在兩個同樣序號的幀，所以最多一次傳送N個幀，通道會有空閒，效率為N/T。
不論是停等協議還是滑動視窗協議，都是通過接收方把自己的反饋（ACK）傳送給接受方, 傳送方通過這個反饋判斷接收方的狀態再進行傳送。停等協議是滑動視窗協議的特殊版（WT=1）而已。這就是鏈路層用於流量控制的方法。
這一篇可以和我的下一篇《資料鏈路層的差錯控制ARQ》一起看，因為兩個的思想是相通的，都是停等和滑動窗。一起看有助於快速理解。