主頁 > 軟體設計 > 計算機網路「三」 資料鏈路層 (爆肝 5w 字,多圖詳解,保姆級教程,附帶練習題)

計算機網路「三」 資料鏈路層 (爆肝 5w 字,多圖詳解,保姆級教程,附帶練習題)

2021-10-01 07:51:35 軟體設計

本文為計算機網路系列第三章筆記,陸續會更新余下內容,文章參考:計算機網路微課堂

系列文章:

計算機網路「一」計算機網路概述 ? 確定不進來看看??

計算機網路「二」物理層 ? 多圖詳解 ?

需要說明:文章中圖片多來自于網路和網課,本文只用作后期學習時參考
在這里插入圖片描述

一、資料鏈路層概述


資料鏈路層在網路體系結構中的地位

主機 H1 給主機 H2 發送資料,中間要經過 3 個路由器和電話網、局域網以及廣域網等多種網路,從五層協議原理體系結構角度來看:
在這里插入圖片描述

為了專注資料鏈路層內容,這里我們只考慮資料鏈路層,而不考慮其他層
在這里插入圖片描述

主機 H1 到 H2 的通信可以看作在 4 個不同鏈路上組成

  • 鏈路(LINK)就是從一個結點到相鄰結點的一段物理線路,而中間沒有任何其他的交換結點

要在鏈路上傳輸資料,僅有鏈路還不夠,還需要一些通信協議來控制資料的傳輸

  • 資料鏈路(Data Link)是指把實作通信協議的硬體和軟體加到鏈路上,就構成了資料鏈路

在資料鏈路層上傳輸的資料包又稱為

  • 資料鏈路層以 為單位傳輸和處理資料

資料鏈路層的三個重要問題

這里先簡單了解一下三個問題,后續內容詳細介紹

  • 封裝成幀
    在這里插入圖片描述

  • 差錯檢測
    在這里插入圖片描述

  • 可靠傳輸
    在這里插入圖片描述

說明:這三個問題針對于點對點信道的資料鏈路層,使用廣播信道的資料鏈路層除了這三個問題外,還有一些其他問題
在這里插入圖片描述

二、封裝成幀


  • 封裝成幀 是指資料鏈路層給上層交付的協議資料單元添加 幀頭 幀尾 的程序
    在這里插入圖片描述

    1. 幀頭和幀尾中包含有重要的控制資訊
      在這里插入圖片描述
    2. 幀頭和幀尾的作用之一就是幀定界
      在這里插入圖片描述
      圖中標志的作用就是幀定界

發送方的資料鏈路層將上層交付下來的協議資料單元封裝成幀后,還要通過物理層將構成幀的各位元轉換成電信號發送到傳輸媒體,
在這里插入圖片描述

那么,接收方的資料鏈路層如果從物理層交付的位元流中提取一個個的幀呢?

幀定界

如下圖,紅色欄位為幀定界標志
在這里插入圖片描述

  • 說明:并不是每一種資料鏈路層協議的幀都包含幀定界標志,例如,以太網 V2 的 MAC 幀:
    在這里插入圖片描述
    1. 前導碼中的前7個位元組為前同步碼,作用是使接收方的時鐘同步,之后1位元組為幀開始定界符,表明后面緊跟的為MAC幀
      在這里插入圖片描述
    2. 此外,以太網定義了幀間間隔為 96 位元的發送時間,因此,MAC 幀不需要幀結束定界符
      在這里插入圖片描述

透明傳輸

透明傳輸是指資料鏈路層對上層交付的傳輸資料沒有任何限制,就好像資料鏈路層不存在一樣,

要實作透明傳輸就要思考一個問題,如果上層交付的協議資料單元中含有幀定界標志應該怎么辦?

兩種方法:

  • 面向位元組的物理鏈路使用位元組填充(或稱字符填充)的方法實作透明傳輸
    在這里插入圖片描述
    在發送資料前,對幀的資料部分進行掃描,每出現一個幀定界符或轉義字符,就在其前面插入一個轉義字符,這里的轉義字符是一個特殊的控制字符,長度為 1 個位元組,十進制值為 27,

  • 面向位元的物理鏈路使用 位元填充 的方法實作透明傳輸
    在這里插入圖片描述
    在發送前對資料部分進行掃描每 5 個連續的位元 1 后面就插入 1 個位元 0,這樣就確保了幀定界在整個幀中的唯一性,也就可以實作透明傳輸,接收方資料鏈路層將每5個連續位元 1 后位元 0 剔除即可,
    在這里插入圖片描述

  • 為了提高幀的傳輸效率,應當使 幀的資料部分的長度盡可能大些

最大傳送單元MTU

考慮到差錯控制等多種因素,每一種資料鏈路層協議都規定了幀的資料部分的長度上限,即 最大傳送單元MTU (Maximum TransferUnit)

在這里插入圖片描述

三、差錯檢測


  • 實際的通信鏈路都不是理想的,位元在傳輸程序中可能會產生差錯:1 可能會變成 0,而 0 也可能變成 1,這稱為 位元差錯

  • 在一段時間內,傳輸錯誤的位元占所傳輸位元總數的比率稱為 誤碼率BER (Bit Error Rate)

  • 使用 差錯檢測碼 來檢測資料在傳輸程序中是否產生了位元差錯,是資料鏈路層所要解決的重要問題之一
    在這里插入圖片描述
    如上述兩種幀格式中,FCS欄位的作用就是檢查幀傳輸程序中是否產生誤碼

下面介紹兩種檢錯方法:奇偶校驗、回圈冗余校驗

1. 奇偶校驗


具體步驟

  • 在待發送的資料后面添加 1 位奇偶校驗位,使整個資料(包括所添加的校驗位在內)中 “1” 的個數為奇數(奇校驗)或 偶數(偶校驗)
  • 如果有 奇數個位 發生誤碼,則奇偶性發生變化,可以檢查出誤碼
  • 如果有 偶數個位 發生誤碼,則奇偶性不發生變化,不能檢查出誤碼(漏檢

在這里插入圖片描述
這種檢錯方法漏檢率比較高,計算機網路的資料鏈路層一般不會采用這種檢測方法

2. 回圈冗余校驗


回圈冗余校驗CRC (Cyclic Redundancy Check) 具體步驟

  1. 收發雙方約定好一個 生成多項式 G(x)

  2. 發送方基于待發送的資料和生成多項式計算出差錯檢測碼(冗余碼),將其添加到待傳輸資料的后面一起傳輸
    在這里插入圖片描述

  3. 接收方通過生成多項式來計算收到的資料是否產生了誤碼

    在這里插入圖片描述

  • 生成多項式舉例
    在這里插入圖片描述
  • 常用的生成多項式
    在這里插入圖片描述
    需要注意,CRC演算法要求生成多項式必須包含最低次項

示例分析

在這里插入圖片描述
在這里插入圖片描述
注意:

  1. 檢錯碼只能檢測幀在傳輸程序中是否出現差錯,無法定位錯誤、糾正錯誤
  2. 回圈冗余校驗CRC有漏檢率低,易于硬體實作,廣泛應用于資料鏈路層

四、 可靠傳輸


1. 可靠傳輸基本概念

使用差錯檢驗技術,接收方的資料鏈路層就可檢測出幀在傳輸程序中是否產生了誤碼(位元錯誤),那么接下來如何處理呢?
在這里插入圖片描述

  • 這取決于資料鏈路層向其上層提供的服務型別:
    1. 不可靠傳輸服務:僅僅丟棄有誤碼的幀,其他什么都不做
    2. 可靠傳輸服務:想辦法實作發送端發送什么,接收端接收什么

對有線鏈路而言

  • 一般情況下,有線鏈路的誤碼率比較低,為了減少開銷,并不要求資料鏈路層向其上層提供可靠傳輸服務,即使出現了誤碼,可靠傳輸的問題由其上層處理

對于無線鏈路

  • 無線鏈路易受干擾,誤碼率比較高,因此要求資料鏈路層必須向上層提供可靠傳輸服務

傳輸差錯

  • 位元差錯只是傳輸差錯的一種

  • 從整個計算機網路體系結構來看,傳輸差錯還包括 分組丟失分組失序 以及 分組重復

  • 分組丟失、分組失序、分組重復這些傳輸差錯,一般不會出現在資料鏈路層,而會出現在其上層

  • 可靠傳輸服務并不僅局限在資料鏈路層,其他各層均可選擇實作可靠傳輸

    例如:TCP/IP四層體系結構中:
    在這里插入圖片描述

可靠傳輸的實作比較復雜,開銷也比較大,是否使用可靠傳輸取決于應用需求

2. 可靠傳輸的三種實作機制


下面將講述可靠傳輸的三種實作機制:

  • 停止 - 等待協議SW
  • 回退N幀協議GBN
  • 選擇重傳協議SR

需要注意的是,這三種可靠傳輸實作機制的基本原理 可以應用到計算機網路體系結構的各層協議

「一」停止 - 等待協議SW


在這里插入圖片描述

ACK 和 NAK

  • ACK:接收方收到資料分組后進行差錯檢測,若沒有誤碼,則接收該分組,并給發送方 發送確認分組,簡稱為ACK
  • NAK:若差錯檢測發現誤碼,則丟棄該分組,并給發送方 發送否認分組,簡稱為 NAK

停止等待的程序

  • 發送方每發送完一個資料分組后,就 停止 發送下一個資料分組,等待 來自接收方的 確認分組或否認分組,若收到確認分組,則可以繼續發送下一個資料分組;若收到否認分組,則重發之前發送的那個資料分組,

下面講述一下 傳輸程序出現的三個問題(不僅針對資料鏈路層)

問題 1上述只是發送程序中資料分組產生誤碼的情況,如果資料分組在傳輸程序中丟失了呢 ?

兩點說明:

  1. 接收方接收不到資料分組,就不會發送 ACK 或 NAK ,如果不采取其他措施,發送方就會一直處于等待狀態,
  2. 這里說明一下,對于資料鏈路層點對點信道而言,不太容易出現此情況,但對多網路多路由器的互連網環境而言,經常出現此情況

為解決該問題,可采用 超時重傳 實作資料分組的重新傳輸
在這里插入圖片描述

  • 超時重傳:在發送方發送完一個資料分組后,啟動一個 超時計時器,到了超時計時器所設定的重傳時間而發送方仍接收不到ACK或NAK,則重傳原分組
  • 一般可將重傳時間選為略大于 “ 從發送方到接收方的平均往返時間 ”

問題 2 : 發送方發送的確認分組丟失,如何確定超時重傳后的資料分組 是否為重復的資料分組 呢?

避免重復分組 這種傳輸錯誤,必須給每個分組 帶上序號
在這里插入圖片描述

  • 只需要保證與上個分組的序號不同即可,因此只需 1 個位元編號即可,即 0 或 1

問題 3如果確認分組遲到,導致了超時重傳,接收方再次發送確認分組,如何區分同一確認分組的重復發送呢 ?

說明:

  • 對于資料鏈路層的點對點信號,往返時間比較固定,不會出現確認遲到的情況,因此,如果只在資料鏈路層實作 停止-等待協議,可以不用給確認分組編號

解決方式就是 對確認分組也進行編號,就可以使發送方避免這種誤判
在這里插入圖片描述

停止 - 等待協議的 信道利用率

在這里插入圖片描述

  • TD:發送方發送資料分組的發送時延
  • RTT:收發雙方之間的往返時間
  • TA:接收方發送確認分組所耗費的發送時延
  • 圖中忽略了接收方對資料分組的處理時延,以及發送方對確認分組的處理時延

在這里插入圖片描述

  • 當往返時延RTT遠大于發送時延TD時(例如使用衛星鏈路),信道利用率非常低
  • 為了克服停止-等待協議信道利用率很低的缺點,就產生了另外兩種協議,即 后退N幀協議GBN 和 選擇重傳協議SR

相關練習題

在這里插入圖片描述

「二」回退N幀協議GBN


如果發送發在收到接收方的確認分組之前,可以連續發送多個資料分組,則可大大提高信道利用率,這是一種流水線式的傳輸,如下圖所示
在這里插入圖片描述
為此,我們引入 回退 N 幀協議 GBN

  • 流水線傳輸 的基礎上利用 發送視窗 來限制發送方可連續發送資料分組的數量
  • 在協議的作業程序中發送視窗和接收視窗不斷向前滑動,因此這類協議又稱為 滑動視窗協議

示例分析

在這里插入圖片描述
在這里插入圖片描述

在這里插入圖片描述
在這里插入圖片描述

  • 程序分析:
  1. 發送方將序號落在發送視窗內的 0~4 號資料分組依次連續發送出去,通過互連網的傳輸正確到達接收方
    在這里插入圖片描述

  2. 接收方按序接收它們,每接收一個,接收視窗就向前滑動一個位置,并給發送方發送確認分組
    在這里插入圖片描述

  3. 0~4 號確認分組通過互連網的傳輸正確到達發送方,發送方每接收一個,發送視窗就向前滑動一個位置,這樣就有新序號落入發送視窗,發送方可以將已收到確認的資料分組從快取中洗掉,發送方將已接收的資料分組交付上層處理
    在這里插入圖片描述

累計確認

累計確認: 接收方 不一定要對收到的資料分組逐個發送確認,而是可以在收到幾個資料分組后(由具體實作決定),對按需到達的 最后一個資料分組發送確認

ACKn: 表示序號為 n 及以前的所有資料分組都已正確接收

在這里插入圖片描述
當接收完 0 號和 1 號資料分組后,給發送方發送一個累積確認 ACK1,接受完 2~4 號分組后,發送累積確認ACK4,假設ACK1在傳輸程序中丟失,而ACK4正確到達發送方,發送方接收后就知道序號4及之前的分組都已正確接收,

  • 即使確認分組丟失,發送方也可能不必重傳
  • 減少了接收方的開銷和對網路資源的占用

上述是無差錯情況,下面說一下遇到差錯時的傳輸程序:

在這里插入圖片描述

  1. 如圖 5 號資料分組出現誤碼被丟棄,后續到達的 4 個資料分組的序號與接收視窗不匹配,同樣也不能接收,將它們丟棄,并回傳之前最后一個確認分組 ACK4,每丟棄一個分組就發送一個 ACK4,也就是會連續發送 4 個 ACK4,
  2. 發送方收到重復的確認,就知道之前發送的分組出現差錯,于是就可以不等超時計時器超時就立刻重傳,至于收到幾個重復確認分組后開始重傳,由具體實作決定,

在本例中,盡管序號為 6,7,0,1 的資料分組正確到達接收方,但由于 5 號資料分組誤碼不被接受,它們也 “受到牽連” 而不被接受,發送方還要重傳這些資料分組,這就是所謂的 Go-back-N (回退 N 幀)

相關真題

在這里插入圖片描述
在這里插入圖片描述

「三」選擇重傳協議


通過前文可知,一個資料分組的誤碼就會導致后續多個資料分組不能被接收方按序接收而丟棄(盡管它們無亂序和誤碼),這必然會造成發送方對這些資料分組的超時重傳,對通信資源產生極大浪費,因此引入選擇重傳協議,

選擇重傳協議

設法 只重傳出現誤碼的資料分組,因此,接收視窗的尺寸WR不再等于 1 (而是 大于 1),以便 接收方先收下視窗內無誤碼的資料分組 ,等所缺部分收齊后一并遞交上層,這就是 選擇重傳協議

  • 接收方不能再采取累積確認,而是 逐一確認

在這里插入圖片描述在這里插入圖片描述

示例分析

傳輸條件如下圖
在這里插入圖片描述

但在傳輸程序中 2 號資料分組丟失
在這里插入圖片描述

  • 程序分析
  1. 接收方將接收 0 號和 1 號資料分組,并發送確認分組,之后接收視窗向前滑動兩個位置,接收方再接收 3 號資料分組,并發送 3 號確認分組,但是接收視窗不能向前滑動,因為這是一個未按序到達的資料分組,
    在這里插入圖片描述
  2. 發送方接收 0 號 和 1 號確認分組,發送視窗向前滑動兩個位置,再將落入的 4 號 和 5 號資料分組發送出去,發送方接收 3 號資料分組,但是視窗不能向前滑動,因為這個是一個未按序到達的確認分組,
    在這里插入圖片描述
  3. 等待 2 號資料分組超時重傳后,接收方接收到按序到達的資料分組,并發送確認分組,接收視窗才可以向前滑動,
    在這里插入圖片描述
  4. 發送方收到按序到達的 2 號確認分組,發送視窗向前滑動 4 個位置,
    在這里插入圖片描述

相關真題

在這里插入圖片描述

五、點對點協議PPP


1. 基本概念

  • 點對點協議 PPP(Point-to-Point Protocal)是目前使用最廣泛的點對點資料鏈路層協議
    在這里插入圖片描述
    另外,PPP協議也廣泛用于廣域網路由器之間的專用線路
  • PPP協議為在點對點鏈路傳輸各種協議資料報提供了一個標準方法,主要由以下三部分構成:
    1. 對各種協議報的封裝方法(封裝成幀)
    2. 鏈路控制協議LCP (用于建立、配置以及測驗資料鏈路的連接)
    3. 一套網路控制協議NCPs(其中的每一個協議支持不同的網路層協議)
      在這里插入圖片描述

2. 幀格式


在這里插入圖片描述

3. 透明傳輸


  • 實作透明傳輸的方法
    在這里插入圖片描述
  1. 面向位元組的異步鏈路
    在這里插入圖片描述
  2. 面向位元的同步鏈路
    在這里插入圖片描述

4. 差錯檢測


在這里插入圖片描述

PPP幀尾部包含有 1 個兩位元組的幀檢驗序列 FCS 欄位,使用回圈冗余校驗 CRC 來計算該欄位的取值,

  • 采用的生成多項式如下
    在這里插入圖片描述

接收方每收到一個PPP幀,就進行 CRC 檢驗,若 CRC 檢驗正確,就收下這個幀;反之,就丟棄這個幀,使用PPP的資料鏈路層 向上提供可靠傳輸服務

5. 作業狀態


以撥號接入為例,簡單介紹PPP協議的作業狀態

在這里插入圖片描述

六、媒體介入控制


1. 基本概念

  • 共享信道要著重考慮的一個問題就是如何協調多個發送和接收站點對一個共享傳輸媒體的占用,即 媒體接入控制 MAC (Medium Access Control)
    在這里插入圖片描述
  • 媒體接入控制主要分類
    在這里插入圖片描述

靜態劃分信道

  • 靜態劃分信道也就是預先固定分配好信道,這類方法非常不靈活,對于突發性資料傳輸信道利用率會很低
  • 通常在無線網路的物理層中使用,而不是在資料鏈路層中使用

動態接入控制

  • 集中控制 的多點輪詢協議中,有一個主站以回圈方式 輪詢 每個站點有無資料發送,只有被輪詢到的站點才能發送資料,集中控制的最大缺點,就是存在單點故障問題 (已淘汰
  • 分散控制 的令牌傳遞協議中,各站點是平等的,并連接成一個環型網路,令牌(一種特殊的控制幀)沿環逐站傳遞,接收到令牌的站點才有權發送資料,并在發送完資料后,將令牌傳給下一個站點(已淘汰
  • 采用 令牌協議 的典型網路有:IEEE 802.5 令牌環網,IEEE 802.4 令牌總線網,光線分布式資料介面FDDI(已淘汰
  • 隨機接入 的特點是 所有站點通過競爭,隨機的在信道上發送資料,如果有兩個或以上站點在同一時刻發送資料,那么信號在共享媒體上就要 產生碰撞,使得站點的發送都失敗,因此,這類協議要解決的關鍵問題是如何 避免沖突,以及發生沖突后如何 盡快恢復通信
  • 著名的共享式以太網采用的就是 隨機接入

隨著技術的發展,交換技術的成熟和成本的降低,具有更高性能的使用點對點鏈路和鏈路層交換機的交換式局域網在有線領域已完全取代了共享式局域網,但由于無線信道的廣播天性,無線局域網仍然使用的是共享技術

2. 靜態劃分信道

信道復用

  • 復用(Multiplexing)就是通過一條物理線路同時傳輸多路用戶的信號

  • 當網路中的傳輸媒體的傳輸容量大于多條單一信道傳輸的總通信量時,可利用復用技術在一條物理線路上建立多條通信信道來充分利用傳輸媒體的帶寬
    在這里插入圖片描述
    在這里插入圖片描述

  • 常見的信道復用技術有

    1. 頻分復用 FDM
    2. 時分復用 TDM
    3. 波分復用 WDM
    4. 碼分復用 CDM

「一」 頻分復用 FDM

在這里插入圖片描述

  • 頻分復用的所有用戶同時占用不同的頻帶資源并行通信

「二」 時分復用 TDM

在這里插入圖片描述

  • 時分復用的所有用戶在不同的時間占用同樣的頻帶寬度
  • 每對用戶只在所分配的時隙里使用線路傳輸資料

「三」波分復用 WDM

在這里插入圖片描述

  • 波分復用其實就是光的頻分復用
  • 光復用器和光分用器之間可以放入 4 個摻鉺光纖放大器,使得光復用器和光分用器之間的無線電轉換的距離可達 600km

「四」 碼分復用 CDM

  • 實際上,由于該技術主要用于多址接入,人們更常用的名詞是 碼分多址 CDMA
  • 同理,頻分復用 FDM 和時分復用 TDM 同樣可用于多址接入,相應的名詞是頻分多址 FDMA 和時分多址 TDMA
  • 這里,我們不嚴格區分復用和多址的概念,可簡單理解如下:
    1. 復用 是將單一媒體的頻帶資源分成很多子信道,這些子信道之間獨立,互不干擾
    2. 多址 (更確切的應該稱為多點接入)處理的是動態分配信道給用戶,這在用戶僅僅暫時性地占用信道的應用中是必須的,而所有的移動通信系統基本上都屬于這種情況,相反,在信道永久性地分配給用戶的應用中,多址是不需要的(無線廣播或電視廣播)
  • 與 FDM 和 TMD 不同,CMD 的每一個用戶可以在 同樣的時間使用同樣的頻帶進行通信
  • 由于 各用戶使用經過特殊挑選的不同碼型,因此用戶之間 不會造成干擾

碼片

  • 在 CMDA 中,每一個位元時間再劃分為 m 個短的間隔,稱為 碼片(Chip),通常 m 的值是 64 或 128

  • 使用 CMDA 的每一個站被指派一個唯一的 m bit 碼片序列(Chip Sequence)

    1. 一個站如果要發送位元 1,則發送它自己的 m bit 碼片序列
    2. 一個站如果要發送位元 0,則發送它自己的 m bit 碼片序列反碼
      在這里插入圖片描述
  • 碼片序列的挑選原則如下:

    1. 分配給每個站的 碼片序列必須各不相同,實際常采用偽隨機碼序列
    2. 分配給每個站的 碼片序列必須相互正交(規格化內積為 0)

    令向量 S 表示站 S 的碼片序列,令向量 T 表示其他任何站的碼片序列
    兩個不同站 S 和 T 的碼片序列正交,就是向量 S 和 T 的規格化內積為 0

    在這里插入圖片描述
    在這里插入圖片描述

  • 應用在這里插入圖片描述

相關練習題

在這里插入圖片描述
在這里插入圖片描述在這里插入圖片描述

3. 隨機接入 —— CSMA/CD協議


在這里插入圖片描述
早期的共享式以太網采用 載波監聽多址接入/碰撞檢測 ,即 CSMA/CD協議 來解決碰撞沖突問題

多址接入MA

  • 多個站連接在一條總線上,競爭使用總線

載波監聽CS

  • 每一個站在發送幀之前先要檢測一下總線上是否有其他站點在發送幀(先聽后說):
    1. 若檢測到總線空閑 96 位元時間,則發送這個幀
    2. 若檢測到總線忙,則繼續檢測并等待總線轉為空閑 96 位元時間,然后發送這個幀
  • 96 位元時間 是指發送 96 位元所耗費的時間,也稱為 幀間最小間隔,其作用是使接收方可以檢測出一個幀的結束,同時也使得其他站點有機會平等競爭信道并發送幀

碰撞檢測CD

  • 每一個正在發送幀的站邊發送邊檢測碰撞(邊聽邊說):

    一旦發現總線上出現碰撞,則立即停止發送,退避一段隨機時間后再次發送

舉例分析 載波監聽多址接入/碰撞檢測 程序

  1. 假設在主機 B 發送幀的程序中,主機 C 也要發送幀,主機 C 進行載波監聽,發現總線空閑 96 位元后立即發送幀,這必然導致碰撞
    在這里插入圖片描述
  2. 碰撞信號沿總線傳播,主機 C 比主機 B 更早檢測到碰撞并停止發送,退避一段隨機時間后,重新發送之前所發送的幀
    在這里插入圖片描述
  3. 當主線 B 檢測到碰撞后,同樣也停止發送退避一段隨機時間,重新發送之前所發送的幀
    在這里插入圖片描述

以太網還采用了一種 強化碰撞 的措施,這就是當發送幀的站點一旦檢測到碰撞,除了立即停止發送幀外,還要繼續 發送 32 位元或 48 位元的人為干擾信號(Jamming Signal),以便有足夠多的碰撞信號使所有站點都能檢測出碰撞,

CSMA/CD協議 —— 爭用期(碰撞視窗)

在這里插入圖片描述
在這里插入圖片描述

  • 經過爭用期這段時間還沒有檢測到碰撞,才能肯定這次發送不會發生碰撞
  • 每一個主機在自己發送幀之后的一小段時間內,存在著偶遇碰撞的可能性,這一小段時間取決于另一個發送幀的主機到本主機的距離,但不會超過總線端到端的往返傳播時延,也就是一個爭用期時間
  • 顯然,在以太網中發送幀的主機越多,端到端往返傳播時延越大,發生碰撞的概率就越大,因此,共享式以太網不能連接太多的主機,使用的總線也不能太長

CSMA/CD協議 —— 最小幀長

在這里插入圖片描述

  • 以太網規定最小幀長為 64 位元組,即 512 位元(512 位元時間即為爭用期)
    1. 如果要發送的資料非常少,那么必須加入一些填充位元組,使幀長不少于 64 位元組
  • 以太網的 最小幀長確保了主機可在幀發送完成之前就檢測到該幀的發送程序中是否遭遇了碰撞
    1. 如果在爭用期(共發送 64 位元組)沒有檢測到碰撞,那么后續發送的資料就一定不會發生碰撞
    2. 如果在爭用期內檢測到碰撞,就立即中止發送,這時已經發送出去的資料一定小于 64 位元組,因此,凡長度小于 64 位元組的幀都是由于碰撞而例外中止的無效幀

CSMA/CD協議 —— 最大幀長

在這里插入圖片描述

  • 示例
    在這里插入圖片描述
    在這里插入圖片描述

CSMA/CD協議 —— 截斷二進制指數退避演算法

在這里插入圖片描述
在這里插入圖片描述

  • 若連續多次發生碰撞,就表明可能有較多的主機參與競爭信道,但使用上述退避演算法可 使重傳需要推遲的平均時間隨重傳次數而增大(這也稱為 動態退避),因而 減小發生碰撞的概率,有利于整個系統的穩定
  • 重傳 16 次仍不能成功 時,表明同時打算發送幀的主機太多,以至于發生碰撞,則 丟棄該幀,并向高層報告

CSMA/CD協議 —— 信道利用率

在這里插入圖片描述
在這里插入圖片描述
在這里插入圖片描述

CSMA/CD協議 —— 幀發送流程

在這里插入圖片描述

CSMA/CD協議 —— 幀接收流程

在這里插入圖片描述

相關練習題

在這里插入圖片描述
在這里插入圖片描述
在這里插入圖片描述
在這里插入圖片描述

注意:CSMA/CD協議曾經用于各種總線結構以太網和雙絞線以太網的早期版本中, 現在的以太網基于交換機和全雙工連接,不會有碰撞,因此沒有必要使用CSMA/CD協議,

4. 隨機接入 —— CSMA/CA協議


本節介紹無線局域網使用的媒體接入協議 CSMA/CA,也就是 載波監聽多址接入/碰撞避免

思考:既然 CSMA/CD協議已經成功地應用于使用廣播信道的有線局域網,那么同樣使用廣播信道的無線局域網能不能也使用 CSMA/CD協議呢?

  • 在無線局域網中,仍然可以使用載波監聽多址接入CSMA,即在發送幀之前先對傳輸媒體進行載波監聽,若發現有其他站在發送幀,就推遲發送以免發生碰撞
  • 在無線局域網中,不能使用碰撞檢測CD,原因如下:
    1. 由于無線信道的傳輸條件特殊,其信號強度的動態非常大,無線網卡上接收到的信號強度往往會遠遠小于發送信號的強度(可能相差百萬倍),如果要在無線網卡上實作碰撞,對硬體要求非常高
    2. 即使能夠在硬體上實作無線局域網的碰撞檢測功能,但由于無線電波傳播的特殊性(存在隱蔽站問題),進行碰撞檢測的意義也不大
      在這里插入圖片描述
      這種未能檢測到信道上其他站點信號的問題叫做隱蔽站問題

IEEE 802.11是現今無線局域網通用的標準,雖然經常將 Wi-Fi 與 802.11 混為一談,但兩者并不等同

  • 802.11無線局域網使用CSMA/CA協議,在CSMA的基礎上增加了一個碰撞避免CA功能,而不再實作碰撞檢測功能
  • 由于不能避免所有的碰撞,并且無線信道誤碼率較高,802.11標準還使用了資料鏈路層確認機制(停止-等待協議)來保證資料被正確接收
  • 802.11的MAC層標準定義了兩種不同的媒體接入控制方式:
    1. 分布式協調功能DCF:在DCF方式下,沒有中心控制站點,每個站點使用CSMA/CA協議通過爭用信道來獲取發送權,這是802.11定義的默認方式
    2. 點協調功能PCF:CF方式使用集中控制的接入演算法,是802.11定義的可選方式,實際中較少使用

幀間間隔IFS

  • 802.11標準規定,所有的站點必須在持續檢測到信道空閑一段指定時間后才能發送幀,這段時間稱為幀間間隔IFS
  • 幀間間隔的長短取決于該站點要發送的幀的型別:
    1. 高優先級幀需要等待的時間較短,因此可優先獲得發送權
    2. 低優先級幀需要等待的時間較長,若信道被高優先級幀占用,低優先級幀則推遲發送,減少碰撞
  • 常用的兩種幀間間隔如下:
    1. 短幀間間隔SIFS(28μs),是最短的幀間間隔,用來分隔開屬于一次對話的各幀
    2. DCF幀間間隔DIFS(128μs),在DCF方式中用來發送資料幀和管理幀

CSMA/CA 協議作業原理

在這里插入圖片描述

三個問題

  • 源站為什么在檢測到信道空閑后還要再等待一段時間 DIFS ?
    1. 考慮到可能有高優先級的幀要發送,若有,應先讓高優先級幀發送
  • 目的站為什么正確接收資料幀后還要等待一段時間 SIFS 才能發送 ACK 幀呢?
    1. SIFS是最短的幀間間隔,用來分隔開屬于一次對話的各幀
    2. 在這段時間內,一個站點應當能從發送方式切換到接收方式
  • 信道由忙轉為空閑且經過DIFS時間后,為什么還要退避一段隨機時間才能使用信道?
    1. 防止多個站點同時發送資料而產生碰撞

何時采用退避演算法?

  • 當站點檢測到信道是空閑的,并且所發送的資料幀緊接上次發送時,不使用退避演算法
  • 但以下情況必須使用退避演算法:
    1. 在發送資料幀之前檢測到信道處于忙狀態
    2. 在每一次重傳一個資料幀時
    3. 在每一次成功發送后要連續發送下一個幀時(避免一個站點長時間占用信道)

CSMA/CA 協議的退避演算法

  • 在執行退避演算法時,站點為退避計時器設定一個隨機的退避時間:
    1. 當退避計時器的時間減少到零時,就開始發送資料
    2. 當退避計時器的時間還未減少到零時而信道又轉為忙狀態,這時就凍結退避計時器的數值,重新等待信道變為空閑,再經過時間DIFS后,繼續啟動退避計時器
    3. 在進行第 i 次退避時,退避時間在時隙編號 { 0,1,…,2 ^(2+i) - 1 } 中隨機選擇一個,然后乘以基本退避時間(也就是一個時隙的長度)就可以得到隨機的退避時間,這樣做是為了使不同站點選擇相同退避時間的概率減少,當時隙編號達到 255 時(對應于第6次退避)就不再增加了,

在這里插入圖片描述

CSMA/CA 協議的信道預約和虛擬載波監聽

  • 為了盡可能減少碰撞的概率和降低碰撞的影響,802.11 標準允許要發送資料的站點對信道進行預約
    1. 源站在發送資料幀之前先發送一個短的控制幀,稱為 請求發送RTS(Request To Send),它包括源地址、目的地址以及這次通信(包括相應的確認幀)所需的持續時間
    2. 若目的站正確收到源站發來的RTS幀,且媒體空閑,就發送一個回應控制幀,稱為 允許發送CTS(Clear To Send),它也包括這次通信所需的持續時間(從RTS幀中將此持續時間復制到CTS幀中)
    3. 源站收到CTS幀后,再等待一段時間SIFS后,就可發送其資料幀
    4. 若目的站正確收到了源站發來的資料幀,在等待時間SIFS后,就向源站發送確認幀ACK

在這里插入圖片描述

  • 除源站和目的站以外的其他各站,在收到CTS幀(或資料幀)后就推遲接入到無線局域網中,這樣就保證了源站和目的站之間的通信不會收到其他站的干擾

  • 如果RTS幀發生碰撞,源站就收不到CTS幀,需執行退避演算法重傳RTS幀

  • 由于RTS幀和CTS幀很短,發送碰撞的概率、碰撞產生的開銷及本身的開銷都很小,而對于一般的資料幀,其發送時延往往大于傳播時延,碰撞的概率很大,且一旦發生碰撞而導致資料幀重發,則浪費很多時間,因此用很小的代價對信道進行預約往往是很值得的,802.11 標準規定了 3 種情況供用戶選擇:

    1. 使用RTS幀和CTS幀
    2. 不使用RTS幀和CTS幀
    3. 只有當資料幀的長度超過某一數值時才使用RTS幀和CTS幀
  • 除RTS幀和CTS幀會攜帶通信需要持續的時間,資料幀也能攜帶通信需要持續的時間,這稱為802.11的 虛擬載波監聽 機制

  • 由于利用虛擬載波監聽機制,站點只要監聽到RTS幀、CTS幀或資料幀中的任何一個,就能知道信道被占用的持續時間,而不需要真正監聽到信道上的信號,因此虛擬載波監聽機制能減少隱蔽站帶來的碰撞問題

    1. 如下圖所示隱蔽站
    2. 主機 C 接收到主機 B 發送來的CTS,就知道了信道將被占用時間,在這段時間內不能發送幀
      在這里插入圖片描述

相關練習

  • 習題一
    在這里插入圖片描述
  • 習題二
    在這里插入圖片描述
  • 習題三
    在這里插入圖片描述

七、MAC地址、IP地址以及 ARP 協議


  • MAC 地址是以太網的 MAC 子層所使用的地址 (資料鏈路層內容)
  • IP 地址是 TCP/IP 體系結構網際層所使用的地址(網際層內容)
  • ARP 協議屬于 TCP/IP 體系結構的網際層,其作用是已知設備所分配到的 IP 地址,使用 ARP 協議可以通過該 IP 地址獲取到設備的 MAC 地址(網際層內容)

盡管 IP 地址和 ARP 協議屬于 TCP/IP 體系結構的網際層(而不屬于資料鏈路層),但是它們和 MAC 地址存在一定關系,因此放在一起討論,

1. MAC 地址

  • 使用點對點信道的資料鏈路層不需要使用地址
    在這里插入圖片描述

  • 使用廣播信道的資料鏈路層必須使用地址來區分各主機
    在這里插入圖片描述

  • 當多個主機連接在同一個廣播信道上,要想實作兩個主機之間的通信,則每個主機都必須有一個唯一的標識,即一個資料鏈路層地址

  • 在每個主機發送的幀中必須攜帶發送主機和接收主機的地址,由于這類地址是用于媒體接入控制 MAC(Media Access Control),因此這類地址被稱為 MAC地址

    1. MAC 地址一般被固化在網卡(網路配接器)的電可擦可編程只讀存盤器 EEPROM 中,因此 MAC 地址也被稱為 硬體地址
      在這里插入圖片描述

    2. MAC 地址有時也被稱為 物理地址但這不意味著 MAC 地址屬于網路體系中的物理層
      在這里插入圖片描述

  • 每個網路配接器都有一個全球唯一的 MAC 地址,而交換機和路由器往往擁有更多的網路介面,所以會擁有更多的 MAC 地址,嚴格來說,MAC 地址是對網路上各介面的唯一標識,而不是對網路上各設備的唯一標識

IEEE 802 局域網的 MAC 地址格式

它由 48 個位元構成,每 8 個位元為一位元組,從左右依次為第一到第六位元組,這種地址識別符號稱為 擴展的唯一識別符號 EUI,對于 48 位元的 MAC 地址,可稱為 EUI - 48
在這里插入圖片描述

IEEE 802 局域網的 MAC 地址表示方法

  1. 每 4 個位元寫成 1 個十六進制的字符,共 12 個字符,每兩個字符分為一組,
  2. 如下圖
    在這里插入圖片描述

IEEE 802 局域網的 MAC 地址型別

在這里插入圖片描述
在這里插入圖片描述

  • 對于使用 EUI-48 空間的應用程式,IEEE 的目標壽命為 100 年(直到 2080 年),但是鼓勵采用 EUI-64 作為代替

IEEE 802 局域網的 MAC 地址發送順序

  • 位元組發送順序: 第一位元組 -----→ 第七位元組
  • 位元組內的位元發送順序:b0 -----→ b7

單播 MAC 地址作用 舉例說明

下圖為一個擁有三臺主機的總線型以太網,各主機網卡上固化了全球單播 MAC 地址,假設,主機 B 要給主機 C 發送單播幀

  • 程序分析
    在這里插入圖片描述
  1. 主機 B 首先要構建該單播幀,在幀首部中目的地址欄位填入主機 C 的 MAC 地址,源地址欄位填入自己的 MAC 地址,再加上幀首部中的其他欄位、資料載荷以及幀尾部,就構成了該單播幀
    在這里插入圖片描述
  2. 主機 B 將該單播幀發送出去,主機 A 和 C 都會收到該單播幀,主機 A 的網卡發現該單播幀的 MAC 地址和自己不匹配,于是丟棄該幀;主機 C 發現其匹配,接收該幀,并將其交給上層處理
    在這里插入圖片描述

廣播 MAC 地址作用 舉例說明

如下圖所示,主機 B 要發送廣播幀
在這里插入圖片描述

  • 程序分析
  1. 主機 B 首先要構建該廣播幀,在幀首部的目的地址欄位填入廣播地址,源地址欄位填入自己的 MAC 地址,再加上幀首部中的其他欄位、資料載荷以及幀尾部,就構成了該廣播幀
    在這里插入圖片描述
  2. 主機 B 將該廣播幀發送出去,主機 A 和 C 收到后,發現該廣播幀首部中目的地址欄位的內容是廣播地址,就知道該幀是廣播幀,于是接收該幀,并交給上層處理
    在這里插入圖片描述

多播 MAC 地址作用 舉例說明

如下圖,主機 A 要發送多播幀給給多播地址,將該多播地址的左起第一個位元組寫成 8 個位元,可以看到最低位元位是 1,這就表明該地址是多播地址,
在這里插入圖片描述
假設主機 B、C、D 支持 MAC 多播,各用戶給自己的主機配置的多播組串列如下:
在這里插入圖片描述

  • 程序分析
  1. 主機 A 首先要構建該多播幀,在幀首部中的目的欄位填入該多播地址,源地址字體填入自己的 MAC 地址,再加上幀首部中的其他欄位、資料載荷以及幀尾部,就構成了該多播幀
    在這里插入圖片描述
  2. 主機 A 將該多播幀發送出去,主機 B、C、D 收到該多播幀后,將該多播幀的目的 MAC 地址與自己的多播組串列中地址匹配,主機 B、C匹配成功后,接收該幀,并交予上層處理;而主機 D 則丟棄該多播幀
    在這里插入圖片描述
  • 這里介紹一個判斷 MAC 地址是否為多播地址的方法
    在這里插入圖片描述
  • 需要注意:給主機配置多播組串列進行私有應用時,不得使用公有的標準多播地址

2. IP 地址

  • IP 地址是因特網上的主機和路由器所使用的地址,用于標識兩部分資訊:
    1. 網路編號:標識因特網上數以百萬計的網路
    2. 主機編號:標識同一網路上不同主機(或路由器各介面)
      在這里插入圖片描述
  • 很顯然,之前介紹的 MAC 地址不具備區分不同網路的功能,而 IP 地址具備此種功能
    1. 如果只是一個單獨的網路,不接入因特網,可以只使用 MAC 地址(這不是一般用戶的應用方式)
    2. 如果主機所在的網路要接入因特網,則 IP 地址和 MAC 地址都需要使用

網路體系結構看 IP 地址與 MAC 地址

在這里插入圖片描述

資料包轉發程序中 IP 地址與 MAC 地址的變化情況

假設主機 H1 要向主機 H2 發送資料包
在這里插入圖片描述
發送程序如下(只考慮網路層和鏈路層,IP地址、MAC地址用字符標識)
在這里插入圖片描述

  • 資料包轉發程序中 源 IP 地址和目的 IP 地址保持不變
  • 資料包轉發程序中 源 MAC 地址和目的 MAC 地址逐個鏈路(或逐個網路)改變

在這里插入圖片描述

3. ARP 協議

問題: 如果通過 IP 地址找到相應的 MAC 地址呢 ?

  • 這就是地址決議協議 ARP 所要實作的功能

ARP 協議的作業原理

假設主機B要給主機C發送資料包,主機B知道主機C的 IP 地址,但不知道主機C的 MAC 地址,因此主機B的資料鏈路層封裝 MAC 幀時,無法填寫目的 MAC 地址,進而無法構建要發送的 MAC 幀,
在這里插入圖片描述

  • 實際上,每臺主機都會有一個 ARP 高速快取表,ARP高速快取表中記錄有IP地址和MAC地址的對應關系
    在這里插入圖片描述
  • 程序分析
  1. 當主機B要給主機C發送資料包時,會首先在自己的ARP高速快取表中查找主機C的IP地址所對應的 MA 地址,但是未找到,因此,主機B需要發送ARP請求報文來獲取主機C的MAC地址
    在這里插入圖片描述
    ARP 請求報文被封裝在 MAC 幀中發送,目的地址為廣播地址

  2. 主機B發送封裝有ARP請求報文的廣播幀,總線上的其他主機都能收到該廣播幀,主機A對此不予理會,主機C進行回應
    在這里插入圖片描述

  3. 主機C將B的IP地址與MAC地址記錄到自己的ARP高速快取表中,然后給B發送ARP回應報文,以告知自己的MAC地址
    在這里插入圖片描述
    ARP回應報文被封裝在MAC幀中發送,目的地址為主機B的MAC地址

  4. 主機C給主機B發送封裝ARP回應報文的單播幀,總線上的其他主機都能收到該單播幀,主機A丟棄該幀;主機B收到發現匹配后交予上層處理,上層決議后,將其記錄到ARP快取表中
    在這里插入圖片描述

  5. 于是,主機B就可以向主機C發送資料包了
    在這里插入圖片描述

  • ARP 高速快取表中的每一條記錄都有其型別,分為 動態 和 靜態 兩種:
    在這里插入圖片描述
  • ARP 協議只能在一段鏈路或一個網路上使用,而不能跨網路使用
    在這里插入圖片描述

八、集線器與交換機的區別


早期的總線型以太網

在這里插入圖片描述
這種使用無源電纜和大量機械接頭的總線型以太網,并不可靠

使用雙絞線和集線器HUB的星型以太網

在這里插入圖片描述
實踐證明,使用雙絞線和集線器比使用具有大量機械接頭的無源電纜可靠得多,而且價格便宜、使用方便,因此,粗纜和細纜的以太網早已成為歷史,

  • 使用集線器的以太網在邏輯上仍是一個總線網,各站共享總線型資源,使用的還是CSMA/CD協議
  • 集線器只作業在物理層,它的每個介面僅簡單地轉發位元,不進行碰撞檢測(由各站的網卡檢測)
  • 集線器一般都具有少量的容錯能力和網路管理功能,例如,若網路中某個網卡出了故障,不停地發送幀,此時,集線器可以檢測到這個問題,在內部斷開與出故障網卡的連線,使整個以太網仍然能正常作業

使用集線器HUB在物理層擴展以太網

假設某學院下設三個系部,每個系部有一個使用集線器作為互聯設備的以太網,這三個以太網相互獨立,各自共享自己的總線資源
在這里插入圖片描述
為了使各系的以太網相互通信,可再使用一個集線器將它們互連起來,形成一個更大的總線型以太網
在這里插入圖片描述

以太網交換機 SWITCH

在集線器之后,發展出了更先進的網路互連設備,也就是以太網交換機

  • 以太網交換機與集線器的區別
    在這里插入圖片描述

  • 以太網交換機通常都有多個介面,每個介面都可以直接與一臺主機或另一個以太網交換機相連,一般都作業在全雙工方式,發送和接收幀可以同時進行
    注意:使用集線器的以太網在邏輯上是共享總線的,需要使用CSMA/CD協議來協調各主機爭用總線,只能作業在半雙工模式,收發幀不能同時進行

  • 以太網交換機具有并行性,能同時連通多對介面,使多對主機能同時通信,無碰撞(不使用CSMA/CD協議)
    在這里插入圖片描述

  • 以太網交換機一般都具有多種速率的介面,如:10Mb/s、100Mb/s、1Gb/s、10Gb/s介面的多種組合

  • 以太網交換機作業在資料鏈路層(也包括物理層),它收到幀后,在幀交換表中查找幀的目的MAC地址所對應的介面號,然后通過該介面轉發幀
    在這里插入圖片描述

  • 以太網交換機是一種即插即用的設備,其內部的幀交換表是通過自學習演算法自動地逐漸建立起來的

  • 幀的兩種轉發方式:

    1. 存盤轉發
    2. 直通交換:采用基于硬體的交叉矩陣(交換時延非常小,但不檢查幀是否有差錯)

對比集線器和交換機

  • 主機發送單播幀時
    在這里插入圖片描述 在這里插入圖片描述
  • 主機發送廣播幀時
    在這里插入圖片描述 在這里插入圖片描述
  • 多臺主機同時向另一臺主機發送單播幀
    在這里插入圖片描述 在這里插入圖片描述
  • 擴展以太網下發送單播幀
    在這里插入圖片描述
  • 擴展以太網下發送廣播幀
    在這里插入圖片描述
  • 擴展以太網下多主機發送單播幀
    在這里插入圖片描述

總結集線器與交換機區別

在這里插入圖片描述

九、以太網交換機自學習和轉發幀的流程


  • 以太網交換機作業在資料鏈路層(也包括物理層)
  • 以太網交換機收到幀后,在幀交換表中查找幀的目的MAC地址所對應的介面號,然后通過該介面轉發幀
  • 以太網交換機是一種即插即用設備,剛上電啟動時其內部的幀交換表是空的,隨著網路中各主機間的通信,以太網交換機通過自學習演算法自動逐漸建立起幀交換表

舉例分析

如圖所示,相互連接的兩臺以太網交換機各自連接了三臺主機,構成了一個交換式以太網,
注意:本案例重點說明自學習和轉發幀流程,假設前提是各主機知道網路中其他各主機的MAC地址(無需進行ARP)

假設主機A給主機B發送幀,下面分析一下流程:

  1. 該幀從交換機1的介面1進入交換機1,交換機1首先進行登記作業,將該幀的源MAC地址A記錄到自己的幀交換表中,將該幀進入自己的介面的介面號1相應地也記錄到幀交換表中,上述登記作業就稱為交換機的自學習
  2. 之后,交換機1對該幀進行轉發,該幀的目的MAC地址是B,在幀交換表中查找MAC地址B,發現找不到,于是對該幀進行盲目轉發,也稱為泛洪,也就是向除該幀進入交換機介面外的其他所有介面轉發該幀
  3. 主機B的網卡收到該幀后,根據幀的目的MAC地址B就知道這是發送給自己的幀,于是接收該幀;而主機B和主機C收到該幀后將其丟棄
  4. 該幀從交換機2的介面2進入交換機2,交換機2首先進行登記的作業,之后對該幀進行轉發,但是在幀交換表中找不到MAC地址B,于是盲目轉發,主機D、E和F都不能接收該幀因而將其丟棄

在這里插入圖片描述

  1. 接下來,主機B給主機A發送幀,該幀從交換機1的介面3進入交換機1,交換機1首先繼續登記,將該幀源MAC地址B記錄到自己的交換表中,將該幀進入自己的介面號3也記錄下來

  2. 之后交換機1對該幀進行轉發,在幀轉換表中可以找到目的MAC地址A,于是從介面1轉發該幀(明確的轉發,交換機2不會收到該幀
    在這里插入圖片描述

下面我們給交換機1的介面1再連接一臺主機G,主機A、G和交換機的介面1共享同一根總線,下面分析主機G向主機A發送幀的程序:
在這里插入圖片描述

  1. 該幀通過總線傳輸,主機A和交換機1的介面1都可以收到,主機A的網卡收到該幀后接收該幀;交換機1收到該幀后,首先進行登記作業,之后對該幀進行轉發
  2. 在幀交換表中查找目的MAC地址A,發現所對應的介面號是1,而該幀正是從此介面進入的,因此交換機1不會再從此介面將幀轉發出去,于是丟棄該幀

需要注意:幀交換表中的每條記錄都有自己的有效時間,到期自動洗掉!這是因為MAC地址與交換機介面的對應關系并不是永久性的,如,交換機介面改接其他主機;主機更換網卡

相關習題

  • 練習一
    在這里插入圖片描述
  • 練習二
    在這里插入圖片描述
  • 練習三
    在這里插入圖片描述

十、以太網交換機的生成樹協議STP


思考一個問題:如何去提高以太網的可靠性呢?

如下圖,如果交換機A與B直接鏈路故障,則導致交換機B上連接的所有主機無法與交換機A、C上所連主機通信
在這里插入圖片描述

  • 可以通過添加冗余鏈路來提高以太網的可靠性
    在這里插入圖片描述
    但是,冗余鏈路也會帶來負面效應 —— 形成網路環路

  • 網路環路會帶來以下問題

    1. 廣播風暴
      在這里插入圖片描述
      大量消耗網路資源,使得網路無法正常轉發其他資料幀

    2. 主機收到重復的廣播幀

      大量消耗主機資源

    3. 交換機的幀交換表震蕩(漂移)
      在這里插入圖片描述

生成樹協議STP

以太網交換機使用生成樹協議STP,可以在增加冗余鏈路提高網路可靠性的同時又避免網路環路帶來的問題

  • 無論交換機之間采用怎樣的物理連接,交換機都能夠自動計算并構建一個邏輯上沒有環路的網路,其邏輯拓撲結構必須是樹型的(無邏輯環路)
    在這里插入圖片描述
  • 最終生成的樹型邏輯拓撲要確保連通整個網路
  • 當首次連接交換機或網路物理拓撲發生變化時(有可能是人為改變或故障),交換機都將進行生成樹的重新計算
    在這里插入圖片描述

十一、虛擬局域網VLAN


1. 虛擬局域網VLAN概述

  • 以太網交換機作業在資料鏈路層(也包括物理層)

  • 使用一個或多個以太網交換機互連起來的交換式以太網,其所有站點都屬于同一個廣播域

  • 隨著交換式以太網規模的擴大,廣播域相應擴大

  • 巨大的廣播域會帶來很多弊端

    1. 廣播風暴
      在這里插入圖片描述
      某主機為獲取目的主機MAC地址,發送ARP廣播請求,該請求會傳遍整個網路,網路中的其他所有主機都會收到該廣播(這就是廣播風暴)
    2. 難以管理和維護
    3. 潛在的安全問題
  • 網路中會頻繁出現廣播資訊
    在這里插入圖片描述

分隔廣播域的方法

  • 使用路由器可以隔離廣播域
    在這里插入圖片描述
    路由器默認情況下不對廣播資料包進行轉發,因此路由器可以很自然地隔離廣播域,但是,路由器成本較高,局域網內部全部使用路由器來隔離廣播域是不現實的,

  • 虛擬局域網VLAN技術應運而生

虛擬局域網VLAN技術

虛擬局域網VLAN是一種將局域網內的設備劃分成與物理位置無關的邏輯組技術,這些邏輯組具有某些共同的需求,

如下圖,根據應用需求將某局域網劃分成兩個VLAN:VLAN1 和 VLAN2,此后,VLAN1中的廣播資料包不會傳給VLAN2,VLAN2中的廣播資料包也不會傳給VLAN2,
在這里插入圖片描述
那么,如何才能實作VLAN呢 ?我們下面介紹實作機制,

2. 虛擬局域網VLAN的實作機制


虛擬局域網VLAN技術是在交換機上實作的,需要交換機能實作以下兩大功能:

  1. 能夠處理帶有VLAN標記的幀,即 IEEE 802.1Q幀
  2. 交換機的各埠可以支持不同的埠型別,不同型別的埠對幀的處理方式不同

IEEE 802.1Q 幀

  • IEEE 802.1Q幀(也稱Dot One Q幀)對以太網的MAC幀格式進行了擴展,插入了4位元組的VLAN標記

在這里插入圖片描述

  • VLAN標記的最后12位元稱為 VLAN識別符號VID,它唯一地標識了以太網幀屬于哪一個VLAN
    在這里插入圖片描述
  • 802.1Q 幀是由交換機來處理的,而不是用戶主機來處理的
    1. 當交換機收到普通的以太網幀時,會向其插入4位元組的VLAN標記轉變為 802.1Q 幀,簡稱 “ 打標簽
    2. 當交換機轉發 802.1Q 幀時,可能會洗掉其4位元組VLAN標記轉變為普通以太網幀,簡稱 “ 去標簽

交換機的埠型別

  • 交換機的埠型別有以下三種
    1. Access
    2. Trunk
    3. Hybrid
  • 交換機各埠的預設VLAN ID
    1. 在思科交換上稱為 Native VLAN, 即本征 VLAN

      例如,思科交換機在用戶未配置VLAN時,所有埠都默認屬于 VLAN1,即所有埠的本征VLAN都是VLAN1

    2. 在華為交換機上稱為 Port VLAN ID,即埠 VLAN ID,簡記為 PVID

      需要注意,交換機的每個埠有且僅有一個PVID

Access 埠

  • Access埠一般用于連接用戶計算機
  • Access埠只能屬于一個VLAN
  • Access埠的PVID值與埠所屬VLAN的ID相同(默認為 1)

如圖所示,交換機首次上電時,默認配置各埠屬于 VLAN1,也就是各埠的PVID值等于1;默認配置各埠的型別為 Access
在這里插入圖片描述

  • Access 埠接收處理方法:

    一般只接受 “ 未打標簽 ” 的普通以太網MAC幀,根據接收幀的埠的PVID給幀 “ 打標簽 ”,即插入 4 位元組VLAN標記欄位,欄位中的VID取值與埠的PVID取值相等
    在這里插入圖片描述
    由于埠1的PVID值等于 1,因此所插入4位元組VLAN標記欄位中的VID值也為 1

  • Access 埠發送處理方法:

    若幀中的VID與埠的PVID相等,則 “ 去標簽 ” 并轉發該幀;否則不轉發
    在這里插入圖片描述

    廣播幀中的VID取值與埠2,3,4 的PVID取值都等于 1,因此,交換機會從這三個埠對幀進行 “去標簽” 轉發

舉例分析 —— Access 埠功能

應用需求:將主機 A 和 B 劃歸到 VLAN2,主機 C 和 D 劃歸到 VLAN3,VLAN2 中廣播幀不會傳送到 VLAN3

為實作此應用,可以在交換機上創建 VLAN2 和 VLAN3,將交換機的埠 1 和 2 劃歸到 VLAN2,埠 3 和 4劃歸到 VLAN3,

下圖為主機 A 發送廣播幀的情況:
在這里插入圖片描述
同樣,主機 C 發送廣播幀時:
在這里插入圖片描述

Trunk 埠

  • Trunk 埠一般用于交換機之間或交換機與路由器之間的互連
  • Trunk 埠可以屬于多個 VLAN,也就是說 Trunk 埠可以接收和發送多個 VLAN 的幀
  • 用戶可以設定 Trunk 埠的 PVID 值,默認情況下,Trunk 埠的 PVID 值為 1
  • Trunk 埠發送處理方法:
    1. 對于 VID 等于 PVID 的幀, “ 去標簽 ” 再轉發
    2. 對于 VID 不等于 PVID 的幀,直接轉發
  • Trunk埠接收處理方法:
    1. 接收 “ 未打標簽 ” 的幀,根據接收幀的埠的 PVID 給幀 “ 打標簽
    2. 接收 “ 已打標簽的幀 ”

更準確的說法:

Trunk 埠收報文: 收到一個報文,判斷是否有 VLAN 資訊,如果沒有則打上埠的 PVID,并進行交換轉發;如果有判斷該 Trunk 埠是否允許該 VLAN 的資料進入:如果允許則報文攜帶原有 VLAN 標記進行轉發,否則丟棄該報文,

Trunk埠發報文: 比較埠的 PVID 和將要發送報文的 VLAN 資訊,如果兩者相等則剝離 VLAN 資訊再發送,否則報文將攜帶原有的 VLAN 標記進行轉發,

舉例說明 ——Trunk 埠功能

應用需求: 將主機 A、B、E、F 劃歸到 VLAN1,主機 C、D、G、H 劃歸到 VLAN2,

在這里插入圖片描述

  1. 由于交換機首次上電時默認配置各埠屬于 VLAN1,其相應的 PVID 值等于 1,埠型別為 Access,因此,需要對交換機進行相應的配置才能滿足需求
  2. 分別在兩個交換機上創建 VLAN2,并將它們的埠 3 和 4 都劃歸到 VLAN2,其相應的 PVID 值等于 2,而兩個交換機的埠 1 和 2 默認配置即可,也就是其相應的 PVID 值等于 1
  3. 需要注意,兩個交換機互連的埠 5,需要將它們的型別更改為 Trunk 型別,而它們的 PVID 值保持默認的 1 即可

下面是主機 A 發送廣播幀的情況:
在這里插入圖片描述

下面是主機 C 發送廣播幀的情況:
在這里插入圖片描述

看一個習題

在這里插入圖片描述
結論:互連的 Trunk 埠的PVID值不等,可能會造成轉發錯誤

Hybrid 埠(華為交換機私有)

  • Hybird 埠既可用于交換機之間或交換機與路由器之間的互連(同 Trunk 埠),也可用于交換機與用戶計算機之間的互連(同 Access 埠)

  • Hybird 埠可以屬于多個 VLAN(同 Trunk 埠)

  • 用戶可以設定 Hybird 埠的 PVID 值,默認情況下,Hybird 埠的 PVID 值為 1(同 Trunk 埠)

  • Hybird 埠發送處理方法(與 Trunk 埠不同

    查看幀的 VID 是否在埠的 “ 去標簽 ” 串列中:

    1. 若存在,則 “ 去標簽 ” 后再轉發
    2. 若不存在,則直接轉發
  • Hybird 埠接收處理方法(同 Trunk 埠)

    1. 接收 “ 未打標簽 ” 的幀,根據接收幀的埠的 PVID 給幀 “ 打標簽 ” ,即插入 4 位元組VLAN標記欄位,欄位中的 VID 取值與埠的 PVID 取值相等
    2. 接收 “ 已打標簽 ” 的幀

應用實體 —— Hybrid 埠

在這里插入圖片描述

  • 主機 B 向主機 C 發送資料幀時
    在這里插入圖片描述
  • 主機 A 向主機 B 發送資料幀時
    在這里插入圖片描述
    主機 B 無法識別帶 VLAN 標記的 802.1Q 幀(主機 B 可以識別普通以太網 MAC 幀,不能識別 802.1Q 幀),而將其丟棄

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/304492.html

標籤:其他

上一篇:nginx那點事兒——nginx模塊

下一篇:TCP/IP協議

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more