控制相鄰兩個節點間鏈路上的流量的工作在「鏈路層」完成；資料鏈路層的最基本的功能是向該層用戶提供透明和可靠的數據傳送基本服務，數據鏈路層是對物理層傳輸原始比特流的功能的加強，將物理層提供的可能出錯的物理連接改造成為邏輯上無錯誤的數據鏈路，使之對網絡層表現為一無所有的線路。
本教學操作環境：windows10系統、DELL G3電腦。
在連結層完成
資料鏈結層的最基本的功能是向該層用戶提供透明的和可靠的資料傳送基本服務。透明性是指該層上傳輸的資料的內容、格式及編碼沒有限制，也沒有必要解釋資訊結構的意義；可靠的 傳輸使用戶免去對遺失資訊、幹擾資訊及順序不正確等的擔憂。在物理層中這些情況都可能發生，在資料鏈結層中必須用糾錯碼來檢錯與糾錯。資料鏈結層是對實體層傳輸原始位元流的功能的加強，將實體層提供的可能出錯的實體連接改造成為邏輯上無錯誤的資料鏈路，使之對網路層表現為一無錯誤的線路。
擴充知識：流量控制
#錯誤控制是資料鏈結層功能中的一個部分，另一個重要部分是流量控制。流量控制涉及鏈路上字元或訊框的傳輸速率的控制，以使接收方在接收前有足夠的緩衝儲存空間來接受每一個字元或訊框。例如，在面向字元的終端機－電腦連結中，若遠端電腦為許多台終端機服務，它就有可能因無法在高峰時以預定速率傳送全部字元而暫時過載。同樣，在面向幀的自動重發請求系統中，當待確認幀數量增加時，有可能超出緩衝器儲存容量，也造成過載。
XON/XOFF方案
#增加緩衝儲存空間在某種程度上可以緩解收、發雙方在傳輸速率上的差別，但這是一種被動的和消極的方法，實現起來有許多的不便和限制。因為一方面系統不允許開設過大的緩衝空間，另一方面對於速率顯著失配且又傳送大型檔案的場合，仍會出現緩衝儲存空間不夠。 XON/XOFF方案則是一種相較之下較主動、積極的流量控制方法。 XON/XOFF方案中使用一對控製字元來實現流量控制，其中XON採用ASCII字元字集中的控製字元DC1、XOFF採用ASCII字元集中的控製字元DC3。當通訊鏈上的接收方發生過載時便向發送方發送一個XOFF字符後便暫時停止發送數據，等接收方處理完緩衝存儲器中的數據，過載恢復後，再向發送方發送一個XON字符，以通知發送方恢復資料發送。在一次資料傳輸過程中，XOFF、XON的週期可重複多次，但對使用者是透明的。許多非同步資料通訊軟體包均支援XON/XOFF協定。這種方案也可用於電腦向印表機或其它終端設備發送字符，在這種情況下，印表機或終端設備中的控制部件用以控製字符流量。
視窗機制
#為了提高頻道的有效利用率。如前節所述採用了發送方不等待確認幀返回就連續 發送若干幀的方案，這樣的發送過程就像一條連續的流水線，故又稱為管道(pipelining)技術。由於允許連續發送多個未被確認折幀，幀號就採用多位二進位數才能區分。因為凡被送出去但沿尚未被確認的幀都可能出錯或丟失而要求重發，因而這些幀都要保留下來。這就要求發送方有較大的發送緩衝區保留可能要求重發的未被確認的訊框。但是緩衝區容量總是有限的，如果接收方不能以發送方的發送速率處理收到的幀，則還是可能用完緩衝容量而暫時過載。為此，可引入類似於空閒RQ方案的調整措施，其本質是在收到一確定幀之前，對發送方可發送的幀的數目加以限制，這是由發送方調整保留在重發表中的待確認幀的數目來實現的。如果接收者來不及對收到的幀進行處理，則接收方停發確認訊息，此時送方的重發表增長，當達到重發表限度時，就不再發送新幀，直至再次收到確認信息為止。為了實現此方案，存放未確認幀的重發表中應設定未確認幀數目的最大限度，這一限度被稱為鏈路的發送視窗。顯然，如果視窗設定為1，即發送方緩衝能力公為一個幀，則傳輸控制方案就回到了空閒RQ方案，此時傳輸效率很低，故視窗限度應選為使接收方盡量能處理或接受收到的所有幀。當然選擇時也必須考慮諸如幀的最大長度、可使用的緩衝存容量以及傳輸的位元速率等因素。重發表是一個連續序號的列表，對應發送者已發送但尚未確認的那些幀。這些訊框的序號有一個最大值即發送視窗的限度。所謂發送視窗就是指示發送者已發送但尚未確認的幀序號隊列的界，其上、下界分別稱為發送視窗的上、下沿，上、下沿的間距稱為視窗尺寸。接收方類似地有接收窗口，它指示允許接收的訊框的序號。接收視窗的上、下界也是隨時間滑動的。
發送方每次發送一幀後，待確認幀的數目便增1；同樣，發送方每收到一個確認訊息後，待確認幀的數目便減1。當重發計數值，即待確認訊框的數目等於發送視窗時，便停止發送新的訊框。一般幀號只取有限位元二進制數，到一定時間後就又反覆循環，若幀號配3位二進制，則幀號在0～7間循環。當傳送過程進行時，視窗位置一直在滑動，所以也稱為滑動視窗（Slidding Window)，或簡稱為滑窗。
滑動視窗的狀態變化過程可敘述如下（假設發送視窗為2，接收視窗為1）。
初始態，發送方沒有訊框發出，發送視窗前後沿相等。接收視窗限度為1，它允許接收0號訊框。
傳送者已傳送0號幀，此時發作口開啟（即前緣加1），視窗對準0號，表示已發出但尚未收到確認回傳訊息。接收視窗狀態同前，指示允許接收0幀。
發送方在未收到0幀的確認回傳訊息前，繼續發送1號訊框。發送視窗狀態不變。
發送方已收到0幀，視窗滑動一格，表示準備接收1號幀。發送視窗狀態不變。
傳送者已收到0號幀的確認回傳訊息，發送視窗後沿加1，表示從重發表中刪除0號幀，接收視窗狀態不變。
發送方繼續發送2幀，發送視窗前緣加1，表示2號幀也納入待確認之列。接收
視窗狀態仍不變。
已收到1號幀，接收視窗滑動一格，表示準備接收2號幀。發送視窗狀態不變。
發送者收到接收方發送的1號訊框收畢的確認訊息，發送視窗後沿加1，表示從重發表中刪除最早進入的1號訊框。接收視窗狀態不變。一般說來，凡是在一定範圍內到達的幀，那怕不按順序，接收方也要接收下來。若把這個範圍看成是接收視窗的話，則接收視窗的大小應該是大於1的，而Go-back-N正是接收視窗等於1的一個特例。選擇重發也可以看作是一種滑動視窗協議，只不過其發送視窗和接收視窗都大於1。若從滑動視窗的觀點來統一看待空閒RQ、Go-back-N及選擇重發三種協議，它們的差別公在於各自視窗的大小不同而已：
空閒RQ：發送視窗=1 ，接收視窗=1
Go-back-N：發送視窗>1，接收視窗=1
#選擇重發：發送視窗>1，接收視窗>1
若訊框序號採用3位元二進位編碼，則最大序號為SMAX=2^3－1=7。對於有序接收方式，發送視窗最大尺寸選為SMAX；對於無笆接收方式，發送視窗最大尺寸至多是序號範圍的一半。管理超時控制的計時器應等於發送緩衝器數，而不是序號空間的大小。實際上，每一個緩衝器應對應一個計時器，當計時器逾時時，該對應緩衝器的內容重發。按收方必須設定的緩衝器數應該等於接收視窗尺寸，而不是序號空間的大小。
更多相關知識，請造訪常見問題欄位！
以上是控制相鄰兩個節點間鏈路上的流量的工作在什麼完成的詳細內容。更多資訊請關注PHP中文網其他相關文章！
