計算機網絡之數據鏈路層概述和三個重要相關問題


數據鏈路層概述

 

一.定義

 

1:鏈路是指從一個節點到另一個節點的純物理線路,而中間沒有其他任何節點。

 

2:數據鏈路:在鏈路的基礎上添加了實現通信協議的硬件和軟件就是數據鏈路。

 

3.數據鏈路層以幀為單位處理和傳輸數據。

二.數據鏈路層的三個重要問題

 

1.封裝成幀:

  數據鏈路層給從網絡層下來的網絡層協議數據單元添加一個幀頭,添加一個幀尾,這個操作就叫做封裝成幀。添加幀頭幀尾的目的是為了在鏈路上以幀為單元傳送數據。

2.差錯檢測:

  數據鏈路層通過物理層把封裝好的幀發送給傳輸媒體,但是在傳輸媒體中可能出現誤碼,也就是0變1,1變0,所以為了讓接收方知道是否誤碼,需要在數據幀的尾部添加一個檢錯碼,這個檢錯碼是發送方根據差錯檢測算法和待發送數據算出來的。接受方通過檢錯碼和相應算法得知是否出現誤碼的過程就叫做差錯檢測。

3.可靠傳輸:

  如果接收方發現數據出現誤碼,就會將數據幀丟棄。因為是可靠傳輸,所以需要其他措施來確保接收方會重新收到被丟棄的這個幀的正確副本。換句話說,因為誤碼是不能完全避免的,所以如果實現了發送方發送什么,接收方就收到什么,那么我們就稱之為可靠傳輸!

三.數據鏈路層的互連設備

1.網橋和交換機的工作原理

2.集線器(物理層設備)和交換機的區別

 

上面因為是概述,所以寫的比較簡略,下面我們開始逐一深入總結。

 

一.封裝成幀

1.幀的定界符

數據鏈路層通過物理層將構成幀的各比特轉化成電信號,然后再發送到傳輸媒體,但是接收方的數據鏈路層如何從一串比特流中提取出一個一個幀呢?它是怎么清楚一個幀的開頭和結尾的呢?其實幀頭幀尾的作用之一就是幀定界,在幀頭幀尾中各含一字節的標志字段。

值得說明的是,並不是所有的數據鏈路層協議都有幀定界標志,例如在以太網v2的mac幀中就沒有幀定界標志。

 

物理層在這種幀前面添加上前導碼,通過前導碼來實現幀開始定界符的作用,而且規定了幀間間隔時間為96比特時間,所以幀結束定界符的作用也能實現了。

2.防止數據被當作定界符的措施

首先我們先來說一下透明傳輸的概念,透明傳輸是指網絡層不受數據鏈路層的任何限制,可以像數據鏈路層傳輸任意數據,就好像數據鏈路層根本不存在一樣。

透明傳輸是網絡分層的前提,是必須要實現的特性。

可是如果我們按照上面的幀定界符來划分幀的首尾,那么一旦有數據和定界符相等,是不是就會被誤認為定界符而產生錯誤?可能有人會想到,只要命令網絡層堅決不發送和定界符相同的數據不就好了。但這樣會打破透明傳輸,使鏈路層對網絡層產生影響,那么這樣的鏈路層就是毫無意義的,因此這種方案不可行。通常數據鏈路層會通過字節填充和零比特填充的方法來消除這種影響。

對於面向字節的物理鏈路應該使用字節填充的方法來實現透明傳輸,即如果數據中出現幀定界符或者轉義字符那么就在它前面添加一個轉義字符,這樣接收方看見轉義字符就知道后面那個字符是數據,不會產生誤會。

對於面向比特流的物理鏈路應該使用零比特填充的方法來實現透明傳輸,即如果連續出現五個1那么就在其后面添加一個0,這樣接收方在連續收到五個一后把后面的零去掉即可,同樣可以不產生誤會。

二.差錯檢測

1.奇偶校驗:

首先雙方先約定采用奇校驗或偶校驗,如采用奇數校驗那么就在比特串后面添加一個1,使1的個數為奇數,如果接收方收到數據后發現1的個數為偶數則說明數據無誤,偶校驗以此類推。

這種校驗方式很明顯的會導致准確率不高,因為只要偶數個比特位錯誤,就檢查不出來,所以奇偶校驗很少用。

2.crc循環冗余校驗。

(1)雙方先約定好一個生成多項式G(X).

(2)發送方基於待發送的數據和生成多項式生成校驗碼(冗余碼),並將其添加到后面一起傳輸。

(3)接收方收到數據后通過生成多項式來計算是否產生誤碼。

文字可能描繪不清楚,我用兩幅圖來描述接收雙方的行為:

 

循環冗余校驗碼有很好的檢錯能力,漏檢率很低,因此在數據鏈路層被廣泛使用。

三.可靠傳輸

可靠傳輸有三種實現機制,要一一總結,所以篇幅會有點長,做好准備,沖沖沖!

1.停止等待協議(stop-and-wiat)

  如上圖所示,發送方向接收方發送數據,如果接收方成功收到並且驗證無誤后,會發送ACK給發送方確認收到,這是發送方才可以接着往下發送,如果有誤碼,那么就會發送NAK,發送方收到后就會重傳數據,知道發送方收到ACK才會接着向下進行。

這么看上去是不是好像很簡單?然而真的只有這樣嗎,如果DATA沒有產生誤碼而是直接丟失掉那該怎么處理呢?就像下圖所示:

 

 

  別怕,我們還有超時重傳機制:發送方發送完一個分組后會啟動一個超時計時器,如果到了所限制的時間,發送方仍然沒有收到來自接收方的的ACK或者NAK那么就會自動重傳。一般計時器設置時間為從發送方到接收方的平均往返時間。

  那么加上超時重傳機制就完美了嗎?不,還差點東西,DATA數據都可以丟失了,那么ACK和NAK確認當然也可以丟失了,如下圖所示:

  所以如果ACK或NAK丟失,那么一定會出發超時重傳機制,這就會導致分組重復發送,這不是我們希望看到的。因此,我們通過給每個分組帶上一個序號來避免重復發送。對於停止等待協議由於每次發送后都會等待一段時間,所以只要保證每次發送的分組與上一次的不同即可,因此,只需一個比特位來用作序號,即序號只有0和1就夠了。當收到連續的序號時,接收方將會丟棄該分組,並向發送方返回ACK確認,從而使發送方接着往下發送。

  既然DATA都要加序號確認了,那么ACK和NAK需不需要呢,我們看下圖:

  如果ACK在發送時遲到了,那么發送方就會重傳DATA0,這時會有兩個ACK返回,第一個ACK告訴發送方可以發送DATA1了,這是正確的,但是第二個ACK其實是多余的,但發送方會把它當成對DATA1的確認,從而產生BUG,所以ACK和NAK也要加上一個比特的序號來解決確認遲到和重復確認的問題!

因為數據鏈路層的點對點信號往返時間很固定,確認序號不會遲到,所以如果只是在數據鏈路層實現停止等待協議就不需要給ACK加序號防止重復了。

  我們再來看一下停止等待協議的信道利用率,U=TD/(TD+RTT+TA),其中TD為發送數據的時間,RTT為往返時間,TA為發送確認的時間,由於TA過小,所以一般忽略。可以看出,RTT一定是遠遠大於TD的所以信道利用率十分低,如果在發生重傳什么的,就雪上加霜了,所以為了緩解這個問題,又出現了后退N幀協議(GBN),和選擇重傳協議(SR).

2.后退N幀協議

  停止等待協議信道利用率低最最主要的原因是他等待的時間太長了,如果采用流水線式發送,也就是可以有多個分組連續發送,如下圖:

 

   那么信道利用率自然就提升了。而我們要說的后退N幀協議,正是在流水線發送的基礎上演變的,它規定了一個發送窗口,和k位序號來防止重復,發送窗口的大小是(1~2^k-1),如果超過了這個大小那么接收方將會無法辨析舊分組的數據。而接收方的窗口大小只能為1.

  發送方可以在未收到接收方確認的基礎上把發送窗口內的數據全部發送出去,接收方每收到一個當前窗口內的並且無誤碼的數據就將窗口往后挪一個位置,同時為了減少開銷,接收方不一定每收到一個分組就發一個確認,可以發送一個累計確認,就代表在這個分組序號前的所有分組都已接到,這樣做不僅減少了發送確認的開銷,還減少了分組重傳的概率。另外,如果收到了未按序到達的分組后,除了要將其丟棄,還要把最近按序收到的分組進行確認。

  發送方收到確認后會把窗口向后移動,並且如果收到多個重復確認時可以直接開始重傳而不需要等待超時計時器,發送窗口某個分組發生超時重傳后在其后面並且也在這個窗口的分組也必須要進行重傳,這就是后退N幀協議(GO-BACK-N)

3.選擇重傳協議

  由於后退N幀協議的接收方窗口只能為1,所以只能按序接受數據分組,一個分組的誤碼或者丟失,會導致后面多個分組不能被接受而被丟棄,這顯然是對計算機資源的浪費,所以能不能把接收窗口變大一大呢?

  通過加大接收窗口就可以先收下那些按需到達而且無誤碼的分組,等到缺失的分組補齊后在向上提交,這樣就可以只重傳丟失或者誤碼的分組,又進一步的提高了資源利用率,這就是選擇重傳協議的概念。需要注意的是,采用了選擇重傳后為了能只重傳出錯的分組,就不能使用累計確認了,必須要對收到的分組逐一確認。

  選擇重傳協議兩種窗口的大小范圍:1<發送窗口<=2^(k-1),1<接收窗口<=發送窗口,如果發送窗口大於指定范圍那么可能造成重復接收相同分組。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM