計算機網絡(湖科大教書匠)
本文檔為教學視頻【計算機網絡微課堂(有字幕無背景音樂版)_嗶哩嗶哩_bilibili】的摘錄
目錄
- 計算機網絡(湖科大教書匠)
- 一、緒論
- 1.2 因特網概述
- 1.2.1 網絡、互連網(互聯網)和因特網
- 1.2.2 因特網發展的三個階段
- 1.2.3 因特網的標準化工作
- 1.2.4 因特網的組成
- 1.3 三種交換方式
- 1.3.1 電路交換(Circuit Switching)
- 1.3.2 分組交換(Packet Switching)
- 1.3.X 報文交換(Message Switching)
- 1.3.3 三種交換方式對比
- 1.4 計算機網絡的定義與分類
- 1.4.1 計算機網絡的定義
- 1.4.2 計算機網絡的分類
- 1.5 計算機網絡的性能指標
- 1.5.1 速率
- 1.5.2 帶寬
- 1.5.3 吞吐量
- 1.5.4 時延
- 1.5.5 時延帶寬積
- 1.5.6 往返時間
- 1.5.7 利用率
- 1.5.8 丟包率
- 1.6 計算機網絡體系結構
- 1.6.1 常見的計算機網絡體系結構
- 1.6.2 計算機網絡體系結構分層的必要性
- 1.6.3 計算機網絡體系結構分層思想舉例
- 1.6.4 計算機網絡體系結構專用術語
- 1.7 習題
- 1.7.1 體系結構相關習題
- 1.7.2 時延相關習題
- 傳輸中間帶有路由轉發的時延計算
- 二、物理層
- 2.1 物理層的基本概念
- 2.2 物理層下面的傳輸媒體
- 2.3 傳輸方式
- 2.4 編碼與調制
- 2.5 信道的極限容量
- 三、數據鏈路層
- 3.1 數據鏈路層概述
- 3.2 封裝成幀
- 3.3 差錯檢測
- 3.4 可靠傳輸
- 3.4.1 可靠傳輸的基本概念
- 3.4.2 停止等待協議SW(Stop-and-Wait)
- 3.4.3 回退N幀協議GBN(Go-Back-N)
- 3.4.4 選擇重傳協議SR(Selective Request)
- 3.5 點對點協議PPP
- 3.6 媒體接入控制MAC
- 3.6.1 媒體接入控制的基本概念
- 3.6.1 媒體接入控制 —— 靜態劃分信道
- 3.6.3 隨機接入 —— CSMA/CD協議
- 3.6.4 隨機接入 —— CSMA/CA協議
- 3.7 MAC地址、IP地址以及ARP協議
- 3.7.1 MAC地址
- 3.7.2 IP地址
- 3.7.3 ARP協議
- 3.8 集線器與交換機的區別
- 3.9 以太網交換機自學習和轉發幀的流程
- 3.10 以太網交換機的生成樹協議STP
- 3.10.Extra 【番外篇】生成樹算法STA
- 3.11 虛擬局域網VLAN
- 3.11.1 虛擬局域網VLAN概述
- 3.11.2 虛擬局域網VLAN的實現機制
- 四、網絡層
- 4.1 網絡層概述
- 4.2 網絡層提供的兩種服務
- 4.3 IPv4地址
- 4.3.1 IPv4地址概述
- 4.3.2 分類編址的IPv4地址
- 4.3.3 劃分子網的IPv4地址
- 4.3.4 無分類編址的IPv4地址
- 4.3.5 IPv4地址的應用規劃
- 4.4 IP數據報的發送和轉發過程
- 4.5 靜態路由配置及其可能產生的路由環路問題
- 4.6 路由選擇協議
- 4.6.1 路由選擇協議概述
- 4.6.2 路由信息協議RIP的基本工作原理
- 4.6.3開放最短路徑優先OSPF的基本工作原理
- 4.6.Extra Dijkstra最短路徑算法
- 4.6.4 邊界網關協議BGP的基本工作原理
- 4.7 IPv4數據報的首部格式
- 4.8 網際控制報文協議ICMP
- 4.9 虛擬專用網VPN與網絡地址轉換NAT
- 五、運輸層
- 5.1 運輸層概述
- 5.2 運輸層端口號、復用與分用的概念
- 5.3 UDP和TCP的對比
- 5.3.A UDP校驗
- 5.4 TCP的流量控制
- 5.5 TCP的擁塞控制
- 5.6 TCP超時重傳時間的選擇
- 5.7 TCP可靠傳輸的實現
- 5.8 TCP的運輸連接管理
- 5.8.1 TCP的連接建立
- 5.8.2 TCP的連接釋放
- 5.9 TCP報文段的首部格式
- 六、應用層
- 6.1 應用層概述
- 6.2 客戶/服務器方式(C/S方式)和對等方式(P2P方式)
- 6.3 動態主機配置協議DHCP
- 6.4 域名系統DNS(Domain Name System)
- 6.5 文件傳送協議FTP
- 6.6 電子郵件
- 6.7 萬維網WWW
- 6.7 萬維網WWW
一、緒論
1.2 因特網概述
1.2.1 網絡、互連網(互聯網)和因特網
- **網絡(Network)由若干結點(Node)和連接這些結點的鏈路(Link)**組成
- 多個網絡還可通過路由器(Router)互連起來,便構成了一個覆蓋范圍更大的網絡,即互聯網(互連網)。因此,互聯網是**“網絡的網絡(Network of Networks)”**
- **因特網(Internet)**是世界最大的互連網絡(用戶數以億計,互連的網絡數以百萬計)
internet 與 Internet 的區別:
- internet(互聯網或互連網):是通用名稱,泛指由多個計算機網絡互連而成的網絡。在這些網絡之間的通信協議可以是任意的
- Internet(因特網):是專用名詞,指全球最大的、開放的、由眾多網絡相互連接而成的特定計算機網絡,采用TCP/IP協議簇作為通信的規則,其前身是美國的ARPANET
1.2.2 因特網發展的三個階段
因特網服務提供者ISP(Internet Service Provider)
基于ISP的三層結構的因特網
1.2.3 因特網的標準化工作
1.2.4 因特網的組成
- 邊緣部分:由所有連接在因特網上的主機組成。這部分是用戶直接使用的,用來進行通信(傳送數據、音頻、視頻)和資源共享
- 核心部分:由大量網絡和連接這些網絡的路由器組成。這部分是為邊緣部分提供服務的(提供連通性和交換)
1.3 三種交換方式
1.3.1 電路交換(Circuit Switching)
電話之間兩兩相接不借助交換機的情況下,nnn部電話則需要連接$C_{n}^{2} $條電路
- 電話交換機接通電話線的方式稱為電路交換
- 從通信資源的分配角度來看,交換(Switching)就是按照某種方式動態地分配傳輸線路的資源
- 電路交換的三個步驟:
- 建立連接(分配通信資源)
- 通話(一直占用通信資源)
- 釋放連接(歸還通信資源)
思考:若使用電路交換來傳送計算機數據,效果如何?
由于計算機數據的傳送具有一定的突發性,用戶之間建立連接后一般只有少部分時間用于數據傳送,但期間卻一直占用著該條連接,因此利用率較低。計算機網絡通常采用分組交換
1.3.2 分組交換(Packet Switching)
- 發送方:構造分組、發送分組
- 路由器(分組交換機):緩存分組、轉發分組
- 接收方:接收分組、還原報文
1.3.X 報文交換(Message Switching)
1.3.3 三種交換方式對比
電路交換:
優點:
- 通信時延小
- 有序傳輸
- 沒有沖突
- 適用范圍廣
- 實時性強
- 控制簡單
缺點:
- 建立連接時間長
- 線路獨占、使用效率低
- 靈活性差
- 難以規格化
報文交換:
優點:
- 無需建立連接
- 動態分配線路
- 提高線路可靠性
- 提高線路利用率
- 提供多目標服務
缺點:
- 引起了轉發時延
- 需要較大存儲緩存空間
- 需要傳輸額外的信息量
分組交換:
優點:
- 無需建立連接
- 線路利用率高
- 簡化了存儲管理
- 加速傳輸
- 減少出錯概率和重發數據量
缺點:
- 引起了轉發時延
- 需要傳輸額外的信息量
- 對于數據報服務,存在失序、丟失或重復分組的問題;對于虛電路服務,存在呼叫建立、數據傳輸和虛電路釋放三個過程
1.4 計算機網絡的定義與分類
1.4.1 計算機網絡的定義
-
計算機網絡的精確定義并未統一
-
計算機網絡的最簡單的定義是:一些互相連接的、自治的計算機的集合
- 互連:是指計算機之間可以通過有線或無線的方式進行數據通信
- 自治:是指獨立的計算機,它有自己的硬件和軟件,可以單獨運行使用
- 集合:是指至少需要兩臺計算機
-
計算機網絡的較好的定義是:計算機網絡主要是由一些通用的、可編程的硬件互連而成的,而這些硬件并非專門用來實現某一特定目的(例如,傳送數據或視頻信號)。這些可編程的硬件能夠用來傳送多種不同類型的數據,并能支持廣泛的和日益增長的應用
- 計算機網絡所連接的硬件,并不限于一般的計算機,而是包括了智能手機等智能硬件
- 計算機網絡并非專門用來傳送數據,而是能夠支持很多種的應用(包括今后可能出現的各種應用)
1.4.2 計算機網絡的分類
- 按交換技術分類
- 電路交換網絡
- 報文交換網絡
- 分組交換網絡
- 按使用者分類
- 公用網
- 專用網
- 按傳輸介質分類
- 有線網絡
- 無線網絡
- 按覆蓋范圍分類
- 廣域網WAN
- 城域網MAN
- 局域網LAN
- 個域網PAN
- 按拓撲結構分類
- 總線型網絡
- 星型網絡
- 環形網絡
- 網狀型網絡
- 總線型網絡
1.5 計算機網絡的性能指標
1.5.1 速率
-
比特(bitbitbit):計算機中數據量的單位,也是信息論中信息量的單位。一個比特即為二進制數字中的一個1或0
- 常用數據量單位:字節(ByteByteByte)
- 單位換算:1Byte=8bit1Byte = 8bit1Byte=8bit,1KB=210B1KB = 2^{10}B1KB=210B,1MB=220B1MB = 2^{20}B1MB=220B,1GB=230B1GB = 2^{30}B1GB=230B,1TB=240B1TB = 2^{40}B1TB=240B
-
速率:連接在計算機網絡上的主機在數字信道上傳送比特的速率,也稱為比特率或數據率
- 常用數據率單位:比特每秒(bit/s、b/s、bps)
- 單位換算:1kb/s=103b/s1kb/s = 10^{3}b/s1kb/s=103b/s,1Mb/s=106b/s1Mb/s = 10^{6}b/s1Mb/s=106b/s,1Gb/s=109b/s1Gb/s = 10^{9}b/s1Gb/s=109b/s,1Tb/s=1012b/s1Tb/s = 10^{12}b/s1Tb/s=1012b/s
數據量中的單位有時為了簡化計算,被視為和速率單位一致以10次冪為基準,需要依據具體題目說明而定
1.5.2 帶寬
- 帶寬在模擬信號系統中的意義
- 信號所包含的各種不同頻率成分所占據的頻率范圍
- 單位:Hz、kHz、MHz、GHz
- 帶寬在計算機網絡中的意義
- 用來表示網絡的通信線路所能傳送數據的能力,因此網絡帶寬表示在單位時間內從網絡中的某一點到另一點所能通過的“最高數據率”
- 單位:(與上述速率單位一致)
其實,帶寬的這兩種表述之間有著密切的聯系。一條通信線路的“頻帶寬度”越寬,其所傳輸數據的“最高數據率”也越高
1.5.3 吞吐量
- 吞吐量表示在單位時間內通過某個網絡(或信道、接口)的數據量
- 吞吐量被經常用于對現實世界中的網絡的一種測量,以便知道實際上有多少數據量能夠通過網絡
- 吞吐量受網絡的帶寬或額定速率的限制
1.5.4 時延

-
發送時延
- 計算:
- 實際的發送速率由三部分決定,并且符合木桶效應
- 計算:
-
傳播時延
- 計算:
- 電磁波在不同空間的傳播速率
- 自由空間:約為 3?108m/s3\cdot10^{8} m/s3?108m/s
- 銅線:約為 2.3?108m/s2.3\cdot10^{8}m/s2.3?108m/s
- 光纖:約為 2.0?108m/s2.0\cdot10^{8}m/s2.0?108m/s
- 計算:
-
處理時延(一般不方便計算)
1.5.5 時延帶寬積
- 計算:傳播時延×帶寬傳播時延\times帶寬傳播時延×帶寬
- 若發送端連續發送數據,則在所發送的第一個比特即將到達終點時,發送端就已經發送了時延帶寬積個比特
- 鏈路的時延帶寬積又稱為以比特為單位的鏈路長度
1.5.6 往返時間
- 多數情況下,因特網上的信息不僅僅是單方向傳輸,而是雙向交互
- 因此,**往返時間RTT(Round-Trip Time)**是一個重要指標
- 時間為:發送端發送分組開始到接收到接收端傳回的確認信息為止
由于衛星鏈路的距離較長,因此往返時間中該段路程占主導時間
1.5.7 利用率
-
信道利用率:某信道有百分之幾的時間是被利用的(有數據通過)
-
網絡利用率:全網絡的信道利用率的加權平均值
-
信道利用率并非越高越好,通信存在排隊,利用率高也意味著排隊產生的時延久
-
網絡當前時延DDD,網絡空閑時延D0D_{0}D0?和利用率UUU三者關系:
- 當網絡的利用率達到50%時,時延便要加倍
- 當網絡的利用率超過50%時,時延急劇增大
- 當網絡的利用率接近100%時,時延趨于無窮大
- 因此,一些擁有較大主干網的ISP通常會控制它們的信道利用率不超過50%。若超過了,就準備擴容,增大線路的帶寬
-
也不能使信道利用率太低,否則將浪費寶貴的通信資源,應該使用一些機制,可以根據情況動態調整輸入到網絡中的通信量,使網絡利用率保持在一個合理的范圍內
1.5.8 丟包率
- 丟包率即分組丟失率,指在一定的時間范圍內,傳輸過程中丟失的分組數量與總分組數量的比率
- 丟包率具體可分為接口丟包率、結點丟包率、鏈路丟包率、路徑丟包率、網絡丟包率等
- 丟包率使網絡運維人員非常關心的一個網絡性能指標,但對于普通用戶來說通常意識不到網絡丟包
- 分組丟失主要的兩種情況:
- 分組在傳輸過程中出現誤碼,被結點丟棄
- 在通信量較大時可能造成網絡擁塞,分組到達一臺隊列已滿的分組交換機時被丟棄
- 丟包率反映了網絡的擁塞情況:
- 無擁塞時路徑丟包率為 0
- 輕度擁塞時路徑丟包率為 1% - 4%
- 嚴重擁塞時路徑丟包率為 5% - 15%
1.6 計算機網絡體系結構
1.6.1 常見的計算機網絡體系結構
1.6.2 計算機網絡體系結構分層的必要性
-
計算機網絡是個非常復雜的系統。早在最初的ARPANET設計時就提出了分層的設計理念
-
“分層”可將龐大而復雜的問題,轉化為若干較小的局部問題,而這些較小的局部問題就比較易于研究和處理
-
物理層
- 實際上傳輸媒體不屬于物理層
- 解決使用何種信號來傳輸比特的問題
-
數據鏈路層
- 解決分組在一個網絡(或一段鏈路)上傳輸的問題
-
網絡層
- 解決分組在多個網絡上傳輸(路由)的問題
-
運輸層
- 解決進程之間基于網絡的通信問題
-
應用層
- 解決通過應用進程的交互來實現特定網絡應用的問題
1.6.3 計算機網絡體系結構分層思想舉例
各層對數據進行加碼
物理層會將幀看作比特流并加上前導碼
各層加碼的具體內容與作用
-
HTTP請求報文內容
-
TCP報文段首部格式
- 作用:區分應用進程、實現可靠傳輸
-
IP數據報首部格式
- 作用:使IP數據報可以在互聯網上傳輸(即被路由器轉發)
-
幀首部格式
- 作用:使幀能在一個網絡(或一段鏈路)上傳輸,能夠被響應的主機接收
-
幀尾部格式
- 作用:讓目的主機檢查所接收到的幀是否有誤碼
-
比特流前導碼格式
- 作用:為了讓目的主機做好接收幀的準備
1.6.4 計算機網絡體系結構專用術語
-
實體:任何可發送或接收消息的硬件或軟件進程
- 對等實體:收發雙方相同層次中的實體
- 對等實體:收發雙方相同層次中的實體
-
協議:控制兩個對等實體進行邏輯通信的規則的集合
- 協議三要素
- 語法:定義所交換信息的格式
- 語義:定義收發雙方所要完成的操作
- 同步:定義收發雙方的時序關系
- 協議三要素
-
服務
- 在協議的控制下,兩個對等實體間的邏輯通信使得本層能夠向上一層提供服務
- 要實現本層協議,還需要使用下面一層所提供的服務
- 協議是”水平的“,服務是”垂直的“
- 實體看得見相鄰下層所提供的服務,但并不知道實現該服務的具體協議。也就是說,下面的協議對上面的實體是”透明的“
- 服務訪問點:在同一系統中相鄰兩層的實體交換信息的邏輯接口,用于區分不同的服務類型
- 數據鏈路層的服務訪問點:幀的類型字段
- 網絡層的服務訪問點:IP數據報首部中的協議字段
- 運輸層的服務訪問點:端口號
- 服務原語:上層使用下層所提供的服務必須通過與下層交換一些命令,這些命令稱為服務原語
- 協議數據單元PDU:對等層次之間傳送的數據包稱為該層的協議數據單元
- 服務數據單元SDU:同一系統內,層與層之間交換的數據包稱為服務數據單元
- 多個SDU可以合成為一個PDU,一個SDU也可劃分為幾個PDU
1.7 習題
1.7.1 體系結構相關習題
1.7.2 時延相關習題
連續發送多個比特(分組)的總時延為:多個比特(分組)的發送時延 + 該鏈路所需的傳播時延(傳播一個比特所需的時間)
鏈路上的傳播時延是固定的,由電磁波的傳播速率以及鏈路的長度決定。
數據發送是連續的,總時延可理解為數據流末端發送至接收端的時間加上從發送數據流首端到發送數據流末端的時間,顯然前者即為鏈路上的傳播時延,而后者即整個數據流的發送時延
傳輸中間帶有路由轉發的時延計算
假設分組等長、各鏈路長度相同、帶寬也相同,忽略路由器的處理時延
若n個分組,m段鏈路,總時延為:n個分組的發送時延 + 單個分組的發送時延 × (m-1) + 一段鏈路的傳播時延 × m
第一個分組比第二個分組早一個發送時延發送,因此將比第二個分組早一個發送時延抵達路由,此時路由緊接著發送第一個分組消耗一個發送時延后,此時第二個分組恰好抵達路由,由于第一個分組已被發送便可接著發送第二個分組,因此前后兩個分組之間并不存在路由處排隊的現象
于是我們計算總時延時只需專注觀察最后一個分組,即結果為最后一個分組從發送到抵達接收端的時間加上開始時前面多個分組所消耗的發送時延,前者便為(單個分組的發送時延 + 一段鏈路的傳播時延)× m,后者即為 n-1個分組的發送時延
電路交換的時延:電路建立時間 + 發送時延 + 傳播時延
分組長度:分組數據部分長度 + 分組首部長度
分組數量:報文長度 / 分組數據部分長度
發送時延:分組長度 / 帶寬
報文交換中的轉發路由,只有接收完全部報文數據后才可轉發發送
二、物理層
2.1 物理層的基本概念
- 物理層考慮的是怎樣才能在連接各種計算機的傳輸媒體上傳輸數據比特流
- 物理層數據鏈路層屏蔽了各種傳輸媒體的差異,使數據鏈路層只需要考慮如何完成本層的協議和服務,而不必考慮網絡具體的傳輸媒體是什么

- 傳輸媒體
- 引導型:雙絞線、同軸電纜、光纖
- 非引導性:微波通信(2 ~ 40GHz)
- 物理層協議的主要任務
- 機械特性:指明接口所用接線器的形狀和尺寸、引腳數目和排列、固定和鎖定裝置
- 電氣特性:指明在接口電纜的各條線上出現的電壓的范圍
- 功能特性:指明某條線上出現的某一電平的電壓表示何種意義
- 過程特性:指明對于不同功能的各種可能事件的出現順序
2.2 物理層下面的傳輸媒體
-
導引型傳輸媒體:
-
同軸電纜
- 基帶同軸電纜(50Ω)
數字傳輸,過去用于局域網 - 寬帶同軸電纜(75Ω)
模擬傳輸,目前主要用于有線電視
同軸電纜價格較貴且布線不夠靈活和方便,隨著集線器的出現,在局域網領域基本上都是采用雙絞線作為傳輸媒體
- 基帶同軸電纜(50Ω)
集線器:
集線器的英文稱為“Hub”。“Hub”是“中心”的意思,集線器的主要功能是對接收到的信號進行再生整形放大,以擴大網絡的傳輸距離,同時把所有節點集中在以它為中心的節點上。它工作于OSI(開放系統互聯參考模型)參考模型第一層,即“物理層”。集線器與網卡、網線等傳輸介質一樣,屬于局域網中的基礎設備,采用CSMA/CD(即帶沖突檢測的載波監聽多路訪問技術)介質訪問控制機制。集線器每個接口簡單的收發比特,收到1就轉發1,收到0就轉發0,不進行碰撞檢測。集線器(hub)屬于純硬件網絡底層設備,基本上不具有類似于交換機的"智能記憶"能力和"學習"能力。它也不具備交換機所具有的MAC地址表,所以它發送數據時都是沒有針對性的,而是采用廣播方式發送。也就是說當它要向某節點發送數據時,不是直接把數據發送到目的節點,而是把數據包發送到與集線器相連的所有節點,如圖所示,簡單明了。HUB是一個多端口的轉發器,當以HUB為中心設備時,網絡中某條線路產生了故障,并不影響其它線路的工作。所以HUB在局域網中得到了廣泛的應用。大多數的時候它用在星型與樹型網絡拓撲結構中,以RJ45接口與各主機相連(也有BNC接口),HUB按照不同的說法有很多種類。—— 百度百科-
雙絞線
-
光纖
- 纖芯直徑
- 多模光纖:50微米、62.5微米
- 單模光纖:9微米
- 包層直徑:125微米
- 工作波長
- 0.85微米(衰減較大)
- 1.30微米(衰減較小)
- 1.55微米(衰減較小)
- 光纖的優點
- 通信容量大(25000 - 30000GHz的帶寬)
- 傳輸損耗小,遠距離傳輸時更加經濟
- 抗雷電和電磁干擾性能好(這在大電流脈沖干擾的環境下尤為重要)
- 無串音干擾,保密性好,不易被竊聽
- 體積小,重量輕
- 光纖的缺點
- 割接需要專用設備
- 光電接口價格較貴
- 光纖內部結構
- 多模光纖
- 由于色散(模式、材料、波導色散),光在多模光纖中傳輸一定距離后必然產生信號失真(脈沖展寬)
- 因此,多模光纖只適合近距離傳輸(建筑物內)
- 發送光源:發光二極管
- 接收檢測:光電二極管
- 單模光纖
- 沒有模式色散,在1.31微米波長附近材料色散和波導色散大小相等符號相反,兩者正好抵消
- 適合長距離傳輸且衰減程度小,但其制造成本高,對光源要求高
- 發送光源:激光發射器
- 接收檢測:激光檢波器
- 纖芯直徑
-
電力線
-
-
非導引型傳輸媒體
- 電信領域使用的電磁波的頻譜
-
無線電波
-
LF和MF頻段
主要利用地面波進行傳輸 -
HF和VHF頻段
主要靠電離層的反射
-
-
微波
由于微波會穿透電離層而進入宇宙空間,因此不能經過電離層的反射傳播到地面上很遠的地方。兩種主要的微波通信方式:- 地面微波接力通信
- 衛星通信
- 地面微波接力通信
-
紅外線
- 點對點無線傳輸
- 直線傳輸,中間不能有障礙物,傳輸距離短
- 傳輸速率低(4Mb/s - 16Mb/s)
-
可見光
- LIFI
2.3 傳輸方式
-
串行和并行傳輸
- 遠距離傳輸(如計算機網絡)通常采用串行傳輸
- 計算機內部通常采用并行傳輸
-
同步和異步傳輸
-
單向(單工)/雙向交替(半雙工)/雙向同時(全雙工)通信
2.4 編碼與調制
-
常用編碼
- 不歸零編碼
- 需要額外一根傳輸線來傳輸時鐘信號,使發送方和接收方同步(由于存在同步問題,計算機網絡傳輸不采用該類編碼)
- 歸零編碼
- 每個碼元傳輸結束后信號都要“歸零”,所以接收方只需要在信號歸零后進行采樣即可,不需要單獨的時鐘信號
- 實際上,歸零編碼相當于把時鐘信號用“歸零”方式編碼在了數據之內,這稱為“自同步”信號
- 但是,歸零編碼中大部分的數據帶寬都用來傳輸“歸零”而浪費掉了(編碼效率低)
- 曼徹斯特編碼
- 碼元中間時刻的跳變既表示時鐘,又表示數據
- 差分曼徹斯特編碼
- 跳變僅表示時鐘
- 碼元開始處電平是否發生變化表示數據
- 比曼徹斯特編碼變化少,更適合較高的傳輸速率
- 不歸零編碼
-
常用調制
-
基本調制方法
- 使用基本調制方法,1個碼元只能包含1個比特信息
-
混合調制(舉例——正交振幅調制QAM)
- QAM - 16
- 12 種相位
- 每種相位有1或2種振幅可選
- 可以調制出16種碼元(波形),每種碼元可以對應表示4個比特
- 碼元與4個比特的對應關系采用格雷碼(任意兩個相鄰碼元只有一個比特不同)
- QAM - 16
-
2.5 信道的極限容量
-
失真
- 失真因素
- 碼元傳輸速率
- 信號傳輸速率
- 噪聲干擾
- 傳輸媒體質量
- 失真因素
-
奈奎斯特準則
只要采用更好的調制方法,讓碼元可以攜帶更多的比特,豈不是可以無限制地提高信息的傳輸速率?
答案是否定的。因為信道的極限信息傳輸速率還要受限于實際的信號在信道中傳輸時的信噪比
-
香農公式
- 在信道帶寬一定的情況下,根據奈氏準則和香農公式,要想提高信息的傳輸速率就必須采用多元制(更好的調制方法)和努力提高信道中的信噪比
- 自從香農公式發表后,各種新的信號處理和調制方法就不斷出現,其目的都是為了盡可能接近香農公式給出的傳輸速率極限
三、數據鏈路層
3.1 數據鏈路層概述
- 鏈路(Link)就是從一個結點到相鄰結點的一段物理線路,而中間沒有任何其他的交換結點
- 數據鏈路(Data Link)是指把實現通信協議的硬件和軟件加到鏈路上,就構成了數據鏈路
- 數據鏈路層以幀為單位傳輸和處理數據
- 數據鏈路層的三個重要問題:
- 封裝成幀
- 差錯檢測
- 發送方發送前基于待發送的數據和檢錯算法計算出檢錯碼,并將其封裝在幀尾
- 可靠傳輸
- 接收端收到有誤碼的幀后不會接收而是將其丟棄
- 盡管誤碼是不能完全避免的,但若能實現發送方發送什么,接收方就能收到什么,便稱為可靠傳輸
- 封裝成幀
- 使用廣播信道的數據鏈路層
- 目的地址
- 通過在幀頭中編址,便可指定發送的目的地址
- 碰撞問題
- 當多臺主機同時向總線上發送數據便會產生碰撞
- 以太網采用CSMA/CD協議解決碰撞問題
- 目的地址
- 交換式局域網、無線局域網
3.2 封裝成幀
-
封裝成幀是指數據鏈路層給上層交付的協議數據單元添加幀頭和幀尾使之成為幀
-
幀頭和幀尾中包含有重要的控制信息
-
幀頭和幀尾的作用之一就是幀定界
-
PPP幀中幀頭尾均有1字節的標志位用于界定幀
-
以太網版本2的MAC幀在交付給物理層時會在幀前附加8字節前導碼
- 前7個字節為前同步碼,作用使接收方的時鐘同步
- 最后1字節為幀開始界定符,表明后面緊跟著的便是MAC幀
- 此外,以太網V2還規定了幀間間隔時間為96比特發送時間(因此不需要幀結束界定符)
-
-
-
透明傳輸
- 指數據鏈路層對上層交付的傳輸數據沒有任何限制,就好像數據鏈路層不存在一樣
-
當上層數據中包含幀標志符時,會造成接收方的誤判
-
可以在數據中與標識符相同的字段前加上轉義字符,接收方遇到轉義字符便知道其后跟著的數據而非真正的標識符,并且接收方需將該轉義字符剔除掉
-
但如果數據中還含有和轉義字符相同的字段,這時便又會引起接收方的誤判(將本為數據的轉義字符剔除),此時將數據中的轉義字符前再加上一個轉義字符,這樣一來接收方每次遇到轉義字符時便知道其后緊跟的是數據并剔除該一個轉義字符即可
-
面向字節的物理鏈路使用字節填充(或稱字符填充)的方法實現透明傳輸
-
面向比特的物理鏈路使用比特填充的方法實現透明傳輸
- 零比特填充法
- 幀標志位為01111110(連續6個1)
- 對于數據部分出現的同標志位的字段,在每連續5個1后添加1個0(無論其是否構成和幀標志相同,都一律按該規則添0),保證了數據部分不再與標志位相同,接收方接收時將每連續的5個1后的一個0進行剔除
- 零比特填充法
-
傳輸效率
- 為了提高幀的傳輸效率,應當使幀的數據部分的長度盡可能大些
- 考慮到差錯控制等多種因素,每種數據鏈路層協議都規定了幀的數據部分的長度上限,即最大傳送單元MTU(Maximum Transfer Unit)
3.3 差錯檢測
- 實際的通信鏈路都不是理想的,比特在傳輸的過程中可能會產生差錯:1可能變為0,而0也可能變為1,這稱為比特差錯
- 在一段時間內,傳輸錯誤的比特占所傳輸比特總數的比率稱為誤碼率BER(Bit Error Rate)
- 使用差錯檢測碼來檢測數據在傳輸過程中是否產生了比特差錯,是數據鏈路層所要解決的重要問題之一
-
FCS(Frame Check Sequence):幀校驗序列
-
奇偶校驗
- 在待發送的數據后面添加1位奇偶校驗位,使整個數據(包括所添加的校驗位在內)中**“1”的個數**為奇數(奇校驗)或偶數(偶校驗)
- 如果有奇數個位發生誤碼,則奇偶性發生變化,可以檢查出誤碼
- 如果有偶數個位發生誤碼,則奇偶性不發生變化,不能檢查出誤碼(漏檢)
-
循環冗余校驗CRC(Cyclic Redundancy Check)
- 收發雙方約定好一個生成多項式G(x)G(x)G(x)
- 發送方基于待發送的數據和生成多項式計算出差錯檢測碼(冗余碼),將其添加到待傳輸數據的后面一起傳輸
- 接收方通過生成多項式來計算收到的數據是否產生了誤碼
- 檢錯碼只能檢測出幀在傳輸過程中出現了差錯,但并不能定位錯誤,因此無法糾正錯誤
- 想要糾正傳輸中的差錯,可以使用冗余信息更多的糾錯碼進行前向糾錯。但糾錯碼的開銷比較大,在計算機網絡中較少使用
- 循環冗余校驗CRC有很好的檢錯能力(漏檢率非常低),雖然計算比較復雜,但是非常易于用硬件實現,因此被廣泛應用于數據鏈路層
- 在計算機網絡中通常采用檢錯重傳方式來糾正傳輸中的差錯,或者僅僅是丟棄檢測到差錯的幀,這取決于數據鏈路層向其上層提供的是可靠傳輸服務還是不可靠傳輸服務
3.4 可靠傳輸
3.4.1 可靠傳輸的基本概念
- 數據鏈路層向上層提供的服務類型
- 不可靠傳輸服務:僅僅丟棄有誤碼的幀,其他什么也不做
- 可靠傳輸服務:想辦法實現發送端發送什么,接收端就收到什么
- 一般情況下,有線鏈路的誤碼率較低,為了減小開銷,并不要求數據鏈路層向上提供可靠傳輸服務。即使出現了誤碼,可靠傳輸的問題由其上層處理
- 無線鏈路易受干擾,誤碼率比較高,因此要求數據鏈路層必須向上層提供可靠傳輸服務
- 比特差錯只是傳輸差錯中的一種
- 從整個計算機網絡體系結構來看,傳輸差錯還包括分組丟失、分組失序以及分組重復(這些傳輸差錯一般出現在數據鏈路層的上層)
- 可靠傳輸服務并不僅局限于數據鏈路層,其他各層均可選擇實現可靠傳輸
- 可靠傳輸的實現比較復雜,開銷也比較大,是否使用可靠傳輸取決于應用需求
3.4.2 停止等待協議SW(Stop-and-Wait)
- 發送方向接收方發送數據
- 接收方通過差錯檢測若無誤碼則接收并向發送方發送確認分組(ACK)
- 發送方接收到確認分組后便可刪除上條數據的緩存并發送下一組數據
- 若出現了誤碼,接收方丟棄該數據并向發送方發送否認分組(NAK)
- 發送方收到否認分組后重新傳送上一條數據

現在實用的可靠傳輸協議都不使用這種否認報文了,雖然“否認報文”能夠讓發送方盡早知道出現了差錯,但這樣處理會使協議復雜化
-
當發送的數據中途丟失時,此時接收方未接收到數據便無法響應發送確認或否認分組,而發送方也一直等待接收方的反饋分組,此時陷入一種類似“死鎖”的狀態
為解決該問題,可以在發送方發送完一個數據分組時,啟動一個超時計時器。若到了計時器所設置的重傳時間而發送方仍收不到接收方的任何ACK或NAK,則重傳原來的數據分組,這就叫超時重傳
一般可將重傳時間設置為略大于“從發送方到接收方的平均往返時間”
-
若接收方發送的確認分組中途丟失,這時超過重傳時間后發送方又將上條數據重發,此時接收方便接收到了兩條同樣的數據,應當丟棄第二次重發的數據
為避免分組重復這種傳輸錯誤,必須給每個分組帶上序號。接收方通過編號便可判斷是否是重復的數據,對于重復的數據丟棄即可
對于停止-等待協議,由于每發送一個數據就停止等待,只要保證每發送一個新的數據分組,其發送序號與上次發送的數據分組的序號不同就可以了,因此用一個比特來編號就夠了
-
若接收方發送的確認分組遲到,并且在遲到期間發送方重發了上條數據A,確認分組到達后又緊接著發送了下一條數據B,接收方收到重復的數據將其丟棄并發送確認分組,這時發送方接收到確認分組后會誤以為是數據B的確認信號則會立即發送下條數據
這里應當忽略重復的確認分組,而是等到真正的數據B確認分組傳達后再發送下條數據,因此同樣的還需給確認分組編號,遇到重復的確認分組將其忽略
對于數據鏈路層的點對點信道,往返時間比較固定,不會出現確認遲到的情況,因此若只是在數據鏈路層實現停止-等待協議,可以不用給確認分組編號
-
停止-等待協議的信道利用率:
- 當往返時延RTT遠大于數據幀發送時延時(例如使用衛星鏈路),信道利用率非常低
- 若出現重傳,則對于傳送有效的數據信息來說,信道利用率更低
- 為克服停止-等待協議信道利用率很低的缺點,便產生另外兩種協議(后退N幀協議GBN 和 選擇重傳協議SR)
3.4.3 回退N幀協議GBN(Go-Back-N)
- 采用3個比特給分組遍序號,即序號0 - 7
- 發送窗口的尺寸WTW_TWT?的取值:1<WT≤23?11<W_T\le2^3-11<WT?≤23?1,本例取WTW_TWT?=5
- 接收窗口的尺寸WRW_RWR?的取值:WRW_RWR?=1
- 發送方先連續發送5個數據幀
- 接收方逐個接收到數據幀,并返回每個數據幀的確認分組
- 發送方每接收到一個確認分組便移動一位發送窗口,再執行步驟1
-
累積確認
接收方不一定要對收到的數據分組逐個發送確認,而是可以在收到幾個數據分組后(由具體實現決定),對按序到達的最后一個數據分組發送確認。ACKnACK_nACKn?表示序號為nnn及以前的所有數據分組都已正確接收
這里接收方產生了兩個確認分組ACK1ACK_1ACK1?和ACK4ACK_4ACK4?,若途中ACK1ACK_1ACK1?丟失發送方收到ACK4ACK_4ACK4?后也可知道序號4及以前的數據分組均已正確接收
- 優點:
- 即使確認分組丟失,發送方也可能不必重傳
- 減少接收方開銷、減少對網絡資源占用
- 缺點:
- 不能向發送方及時反映接收方已經確認接收的數據分組信息
此時5號數據出現誤碼被丟棄,而其余的數據分組與接收窗口的序號不匹配,也會被丟棄。接著接收方會對之前按序接收的最后一個分組進行確認,每丟棄一個數據分組就發送一個確認分組(ACK4ACK_4ACK4?)
發送方收到重復的確認,便知道之前所發送的數據分組出現了差錯,于是可以不等超時計時器超時就立刻重傳(至于收到幾個重復確認就立刻重傳,由具體實現決定)
本例中,盡管序號為6、7、0、1的數據分組正確到達接收方,但由于5號數據分組誤碼不被接受,它們也受到牽連而不被接受,發送方還需重傳這些數據分組,這便是所謂的Go-Back-N
可見,當通信線路質量不好時,回退N幀協議的信道利用率并不比停止-等待協議高
- 若WTW_TWT?超過取值范圍
這里一次性發送8個數據分組,第一遍的確認分組丟失,于是發送方超時重傳這8個分組,此時重復分組的序號和接收窗口的序號是匹配的接收方無法分辨新舊數據
- 優點:
-
總結
3.4.4 選擇重傳協議SR(Selective Request)
- 回退N幀協議的接收窗口尺寸**WRW_RWR?只能等于1**,因此接收方只能按序接收正確到達的數據分組
- 一個數據分組的誤碼就會導致其后續多個數據分組不能被接收方按序接收而丟棄(盡管它們無亂序和誤碼)。這必然會造成發送方對這些數據分組的超時重傳,顯然這時對通信資源的極大浪費
- 為了進一步提高性能,可設法只重傳出現誤碼的數據分組。因此,接收窗口的尺寸**WRW_RWR?不應再等于1(而應大于1),以便接收方先收下失序到達但無誤碼并且序號落在接收窗口內的那些數據分組**,等到所缺分組收齊后再一并送交上層。這就是選擇重傳協議
選擇重傳協議為了使發送方僅重傳出現差錯的分組,接收方不能再采用累積確認,而需要對每個正確接收到的數據分組進行逐一確認
- 采用3個比特給分組編序號,即序號0 - 7
- 發送窗口的尺寸WTW_TWT?的取值:1<WT≤23?11<W_T\le2^{3-1}1<WT?≤23?1,本例取WTW_TWT?=4
- 接收窗口的尺寸WRW_RWR?的取值:WR=WT=4W_R=W_T=4WR?=WT?=4
- 發送方依次發送0 - 3序號四個數據分組
- 其中2號數據分組出現誤碼,接收方將其丟棄,接收窗口只有按序接收時才可滑動,因此0、1序號數據使窗口向右滑動2位,由于2號數據分組的缺失,窗口需在此停駐
- 接收方將正確接收到的數據分組向發送方反饋確認分組,同樣的發送窗口也是只有按序接收的確認分組才可滑動,同樣的向右滑動2位
- 發送方接著發送4、5號數據分組,接收方正確接收后返回響應的確認分組
- 此時2號分組的重傳計時器超時重傳,接收方正確接收,由于接收窗口中的數據分組均已按序接收,于是窗口可向右滑動4位(同樣的發送方的發送窗口中的確認分組也均按序接收到后也會向右滑動4位)
- 窗口尺寸問題
- 發送窗口尺寸WTW_TWT?必須滿足:1<WT≤2n?11<W_T\le2^{n-1}1<WT?≤2n?1(n是構成分組序號的比特數量)
- WT=1W_T=1WT?=1:與停止-等待協議相同
- WT>2n?1W_T\gt2^{n-1}WT?>2n?1:造成接收方無法分辨新、舊數據分組的問題
- 接收窗口尺寸WRW_RWR?必須滿足:1<WR≤WT1<W_R\le W_T1<WR?≤WT?
- WR=1W_R=1WR?=1:與回退N幀協議相同
- WR>WTW_R\gt W_TWR?>WT?:無意義
- 發送窗口尺寸WTW_TWT?必須滿足:1<WT≤2n?11<W_T\le2^{n-1}1<WT?≤2n?1(n是構成分組序號的比特數量)
3.5 點對點協議PPP
-
點對點協議PPP(Point-to-Point Protocol)是目前使用最廣泛的點對點數據鏈路層協議
-
PPP協議為在點對點鏈路傳輸各種協議數據報提供了一個標準方法,主要由以下三部分構成
- 對各種協議數據報的封裝方法(封裝成幀)
- 鏈路控制協議LCP,用于建立、配置以及測試數據鏈路的連接
- 一套網絡控制協議NCPs,其中的每一個協議支持不同的網絡層協議
-
幀格式
- 標志(Flag)字段:PPP幀的界定符,取值為0x7E
- 地址(Address)字段: 取值為0xFF,預留(目前沒有什么作用)
- 控制(Control)字段:取值為0x03,預留(目前沒有什么作用)
- 協議(Protocol)字段:指明幀的數據部分送交哪個協議處理
- 0x0021:IP數據報
- 0xC021:LCP分組
- 0x8021:NCP分組
- 幀檢驗序列(Fram Check Sequence)字段:CRC計算出的校驗位
-
透明傳輸
-
面向字節的異步鏈路采用插入轉義字符的字節填充法
- 出現的每個
7E
(PPP幀的定界符)字節轉變成2字節序列(7D5E
) - 出現的每個
7D
(轉義字符)字節轉變成2字節序列(7D5D
) - 出現的每個ASCII碼控制字符(數值小于0x20的字符),則在該字符前插入一個
7D
字節,同時將該字符的編碼加上0x20 - 接收方進行反變換即可恢復出原來的幀的數據部分
- 出現的每個
-
面向比特的同步鏈路采用插入比特0的比特填充法
- 發送方:對幀的數據部分進行掃描(一般由硬件實現)只要發現5個連續的比特1,則立即填充1個比特0
- 接收方:對幀的數據部分進行掃描(一般由硬件實現)只要發現5個連續的比特1,就把其后的1個比特0刪除
-
-
差錯檢測
- 接收方每收到一個PPP幀,就進行CRC檢驗。若CRC檢驗正確,就收下該幀;反之就丟棄該幀。使用PPP的數據鏈路層向上提供的是不可靠傳輸服務
-
工作狀態
3.6 媒體接入控制MAC
3.6.1 媒體接入控制的基本概念
- 共享信道要考慮的一個問題就是如何協調多個發送和接收站點對一個共享傳輸媒體的占用,即媒體接入控制MAC(Medium Access Control)
隨著奇數的發展,交換技術的成熟和成本的降低,具有更高性能的使用點對點鏈路和鏈路層交換機的交換式局域網在有線領域已經完全取代了共享式局域網,但由于無線信道的廣播天性,無線局域網仍然使用的是共享媒體技術
3.6.1 媒體接入控制 —— 靜態劃分信道
-
信道復用
- 復用(Multiplexing)是通信技術中的一個重要概念。復用就是通過一條物理線路同時傳輸多路用戶的信號
- 當網絡中的傳輸媒體的傳輸容量大于多條單一信道傳輸的總通信量時,可以利用復用技術在一條物理線路上建立多條通信信道來充分利用傳輸媒體的帶寬
-
頻分復用FDM
頻分復用的所有用戶同時占用不同的頻帶資源并行通信 -
時分復用TDM
時分復用的所有用戶在不同的時間占用同樣的頻帶寬度 -
波分復用(WDM)
-
碼分復用(CDM)
-
碼分復用CDM是另一種共享信道的方法。實際上,由于該技術主要用于多址接入,人們更常用的名詞是碼分多址CDMA(Code Division Multiple Access)
-
同理,頻分復用FDM和時分復用TDM同樣可用于多址接入,相應的名詞時頻分多址FDMA(Frequency Division Multiple Access)和時分多址TDMA(Time Division Multiple Access)
-
復用和多址概念可簡單理解如下:
- 復用是將單一媒體的頻帶資源劃分成很多子信道,這些子信道之間相互獨立,互不干擾。從媒體的整體頻帶資源上看,每個子信道只占用該媒體頻帶資源的一部分
- 多址(更確切地應該稱為多點接入)處理的是動態分配信道給用戶。這在用戶僅僅暫時性地占用信道的應用中是必須的,而所有的移動通信系統基本上都屬于這種情況。相反,在信道永久性地分配給用戶的應用中,多址是不需要的(對于無線廣播或電視廣播站就是這樣)
- 某種程度上,FDMA、TDMA、CDMA可以分別看成是FDM、TDM、CDM的應用
-
與FDM和TDM不同,CDM的每個用戶可以在同樣的時間使用同樣的頻帶進行通信
-
由于各用戶使用經過特殊挑選的不同碼型,因此各用戶之間不會造成干擾
-
CDM最初是用于軍事通信的,因為這種系統所發送的信號有很強的抗干擾能力,其頻譜類似于白噪聲,不易被敵人發現
-
隨著技術的進步,CDMA設備的價格和體積都大幅度下降,因而現在已廣泛用于民用的移動通信中
-
在CDMA中,每一個比特時間再劃分為m個短的間隔,稱為碼片(Chip)。通常m的值是64或128。為了簡單期間,后續的舉例中,假設m為8
-
使用CDMA的每個站被指派一個唯一的m bit碼片序列(Chip Sequence)
- 一個站若要發送比特1,則發送它自己的m bit碼片序列
- 一個站若要發送比特0,則發送它自己的m bit碼片序列的二進制反碼
-
碼片序列的挑選原則如下:
-
分配給每個站的碼片序列必須各不相同,實際常采用偽隨機碼序列
-
分配給每個站的碼片序列必須相互正交(規格化內積為0)
令向量S表示站S的碼片序列,令向量T表示其他任何站的碼片序列。兩個不同站的碼片序列正交,就是向量S和T的規格化內積為0
- 每個站碼片序列跟本站的規格化內積為1
- 跟其他站的反碼規格化內積也為0
- 跟本站的反碼規格化內積為-1
- 每個站碼片序列跟本站的規格化內積為1
(妙啊!)
-
-
3.6.3 隨機接入 —— CSMA/CD協議
載波監聽多址接入/碰撞檢測 CSMA/CD (Carrier Sense Multiple Access/Collision Detection)
-
多址接入MA
多個站連接在一條總線上,競爭使用總線 -
載波監聽CS
每個站在發送幀之前先要檢測一下總線上是否有其他站點在發送幀(先聽后說)- 若檢測到總線空閑96比特時間,則發送該幀
- 若檢測到總線忙,則繼續檢測并等待總線轉為空閑96比特時間,然后發送該幀
96比特時間是指發送96bit所耗費的時間,也稱為幀間最小間隔。其作用是使接收方可以檢測出一個幀的結束,同時也使得所有其他站點都能有機會平等競爭信道并發送幀
-
碰撞檢測CD
每個正在發送幀的站邊發送邊檢測碰撞(邊聽邊說)- 一旦發現總線上出現碰撞,則立即停止發送,退避一段隨機時間后再次發送(“一旦沖突,立即停說,等待時機,重新再說”)
以太網還采取了一種叫做強化碰撞的措施。這就是當發送幀的站點一旦檢測到碰撞,除了立即停止發送幀外,還要再繼續發送32bit或48bit的人為干擾信號(Jamming Signal),以便有足夠多的碰撞信號使所有站點都能檢測出碰撞
-
爭用期
-
主機最多經過2τ2\tau2τ(即δ→0\delta\to 0δ→0)的時長就可以檢測到本次發送是否遭受了碰撞
-
因此,以太網端到端往返傳播時延2τ2\tau2τ稱為爭用期或碰撞窗口
-
經過爭用期這段時間還沒有檢測到碰撞,才能肯定這次發送不會發生碰撞
-
每個主機在自己發送幀之后的一小段時間內,存在著遭遇碰撞的可能性。這小段時間是不確定的,它取決于另一個發送幀的主機到本主機的距離,但不會超過總線的端到端往返傳播時延,即一個爭用期時間
-
顯然,在以太網中發送幀的主機越多,端到端往返傳播時延越大,發送碰撞的概率就越大。因此,共享式以太網不能連接太多的主機,使用的總線也不能太長
10Mb/s以太網把爭用期定為512比特發送時間,即51.2微秒,因此其總線長度不能超過5120m,但考慮到其他一些因素,如信號衰減等,以太網規定總線長度不能超過2500m
-
-
最小幀長
- 以太網規定最小幀長為64字節,即512比特(512比特時間即為爭用期)
- 如果要發送的數據非常少,那么必須加入一些填充字節,是幀長不小于64字節
- 以太網的最小幀長確保了主機可在幀發送完成之前就檢測到該幀的發送過程中是否遭遇了碰撞
- 如果在爭用期(共發送64字節)沒有檢測到碰撞,那么后續發送的數據就一定不會發送碰撞
- 如果在爭用期內檢測到碰撞,就立即中止發送,這時已經發送出去的數據一定小于64字節,因此凡長度小于64字節的幀都是由于碰撞而異常中止的無效幀
- 以太網規定最小幀長為64字節,即512比特(512比特時間即為爭用期)
-
最大幀長
-
截斷二進制指數退避算法
- 退避時間 = 基本退避時間 × 隨機數r
- 基本退避時間為爭用期2τ2\tau2τ
- 隨機數r從離散的整數集合{0,1,...,2k?1}\{0,1,...,2^k-1\}{0,1,...,2k?1}中隨機選出一個數,其中k=min(重傳次數,10)k=min(重傳次數, 10)k=min(重傳次數,10)
- 若連續多次發生碰撞,就表明可能有較多的主機參與競爭信道。但使用上述退避算法可使重傳需要推遲的平均時間隨重傳次數而增大(這也稱為動態退避),因而減小發生碰撞的概率,有利于整個系統的穩定
- 當重傳達16次仍不能成功時,表明同時打算發送幀的主機太多,以至于連續發生碰撞,則丟棄該幀,并向高層報告
- 退避時間 = 基本退避時間 × 隨機數r
-
信道利用率
- 因此為提高信道利用率,應使以太網幀的長度T0T_0T0?盡量長些,端到端的距離τ\tauτ受到限制
-
幀發送流程圖
-
幀接收流程圖
CSMA/CD協議曾經用于各種總線結構以太網和雙絞線以太網的早期版本中
現在的以太網基于交換機和全雙工連接,不會有碰撞,因此沒有必要使用CSMA/CD協議
3.6.4 隨機接入 —— CSMA/CA協議
載波監聽多址接入/碰撞避免 CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance)
-
在無線局域網中,不能使用碰撞檢測CD,原因如下
- 由于無線信道的傳輸條件特殊,其信號強度的動態范圍非常大,無線網卡上接收到的信號強度往往會遠遠小于發送信號的強度(可能相差百萬倍)。如果要在無線網卡上實現碰撞檢測CD,對硬件的要求非常高
- 即使能夠在硬件上實現無線局域網的碰撞檢測功能,但由于無線電波傳播的特殊性(存在隱蔽站問題),進行碰撞檢測的意義也不大
隱蔽站問題
-
802.11無線局域網使用CSMA/CA協議,在CSMA的基礎上增加了一個碰撞避免CA功能,而不再實現碰撞檢測功能
-
由于不可能避免所有的碰撞,并且無線信道誤碼率較高,802.11標準還使用了**數據鏈路層確認機制(停止-等待協議)**來保證數據被正確接收
-
802.11的MAC層標準定義了兩種不同的媒體接入控制方式:
- 分布式協調功能DCF(Distributed Coordination Function)。在DCF方式下,沒有中心控制站點,每個站點使用CSMA/CA協議通過爭用信道來獲取發送權,這是802.11定義的默認方式
- 點協調功能PCF(Point Coordination Function)。PCF方式使用集中控制的接入算法(一般在接入點AP實現集中控制),是802.11定義的可選方式,在實際中較少使用
-
802.11標準規定,所有的站點必須在持續檢測到信道空閑一段指定時間后才能發送幀,這段時間稱為幀間間隔IFS(InterFrame Space)
-
幀間間隔的長短取決于該站點要發送的幀的類型:
- 高優先級幀需要等待的時間較短,因此可優先獲得發送權
- 低優先級幀需要等待的時間較長。若某個站的低優先級幀還沒來得及發送,而其他站的高優先級幀已發送到信道上,則信道變為忙態,因而低優先級幀就只能再推遲發送了。這樣就減少了發生碰撞的機會
-
常用的兩種幀間間隔如下:
- 短幀間間隔SIFS(28μs),是最短的幀間間隔,用來分隔開屬于一次對話的各幀。一個站點應當能夠在這段時間內從發送方式切換到接收方式。使用SIFS的幀類型有ACK幀、CTS幀、由過長的MAC幀分片后的數據幀、以及所有回答AP探詢的幀和在PCF方式中接入點AP發送出的任何幀
- DCF幀間間隔DIFS(128μs),它比短幀間間隔SIFS要長得多,在DCF方式中用來發送數據幀和管理幀
-
CSMA/CA協議的工作原理
源站為什么在檢測到信道空閑后還要再等待一段時間DIFS?
考慮到可能有其他的站有高優先級的幀要發送。若有,就要讓高優先級幀先發送目的站為什么正確接收數據幀后還要等待一段時間SIFS才能發送ACK幀?
SIFS是最短的幀間間隔,用來分隔開屬于一次對話的各幀。在這段時間內,一個站點應當能夠從發送方式切換到接收方式信道由忙轉為空閑且經過DIFS時間后,還要退避一段隨機時間才能使用信道?
防止多個站點同時發送數據而產生碰撞- 當站點檢測到信道是空閑的,并且所發送的數據幀不是成功發送完上一個數據幀之后立即連續發送的數據幀,則不使用退避算法
- 以下情況必須使用退避算法:
- 在發送數據幀之前檢測到信道處于忙狀態時
- 在每一次重傳一個數據幀時
- 在每一次成功發送后要連續發送下一個幀時(這時為了避免一個站點長時間占用信道)
-
CSMA/CA協議的退避算法
- 在執行退避算法時,站點為退避計時器設置一個隨機的退避時間:
- 當退避計時器的時間減小到零時,就開始發送數據
- 當退避計時器的時間還未減小到零時而信道又轉變為忙狀態,這時就凍結退避計時器的數值,重新等待信道變為空閑,再經過時間DIFS后,繼續啟動退避計時器
- 在進行第iii次退避時,退避時間在時隙編號{0,1,...,22+i?1}\{0,1,...,2^{2+i}-1\}{0,1,...,22+i?1}中隨機選擇一個,然后乘以基本退避時間(也就是一個時隙的長度)就可以得到隨機的退避時間。這樣做是為了使不同站點選擇相同退避時間的概率減少。當時隙編號達到255時(對應于第6次退避)就不再增加了
- 在執行退避算法時,站點為退避計時器設置一個隨機的退避時間:
-
CSMA/CA協議信道預約和虛擬載波監聽
- 為了盡可能減少碰撞的概率和降低碰撞的影響,802.11標準允許要發送數據的站點對信道進行預約
- 源站在發送數據幀之前先發送一個短的控制幀,稱為請求發送RTS(Request To Send),它包括源地址、目的地址以及這次通信(包括相應的確認幀)所需的持續時間
- 若目的站正確收到源站發來的RTS幀,且媒體空閑,就發送一個響應控制幀,稱為允許發送CTS(Clear To Send),它也包括這次通信所需的持續時間(從RTS幀中將此持續時間復制到CTS幀中)
- 源站收到CTS幀后,再等待一段時間SIFS后,就可發送其數據幀
- 若目的站正確收到了源站發來的數據幀,在等待時間SIFS后,就向源站發送確認幀ACK
- 除源站和目的站以外的其他各站,在收到CTS幀(或數據幀)后就推遲接入到無線局域網中。這樣就保證了源站和目的站之間的通信不會受到其他站的干擾
- 如果RTS幀發生碰撞,源站就收不到CTS幀,需執行退避算法重傳RTS幀
- 由于RTS幀和CTS幀很短,發送碰撞的概率、碰撞產生的開銷及本身的開銷都很小。而對于一般的數據幀,其發送時延往往大于傳播時延(因為是局域網),碰撞的概率很大,且一旦發生碰撞而導致數據幀重發,則浪費的時間就很多,因此用很小的代價對信道進行預約往往是值得的。802.11標準規定了3種情況供用戶選擇:
- 使用RTS幀和CTS幀
- 不使用RTS幀和CTS幀
- 只有當數據幀的長度超過某一數值時才使用RTS幀和CTS幀
- 除RTS幀和CTS幀會攜帶通信需要持續的時間,數據幀也能攜帶通信需要持續的時間,這稱為802.11的虛擬載波監聽機制
- 由于利用虛擬載波監聽機制,站點只要監聽到RTS幀、CTS幀或數據幀中的任何一個,就能知道信道被占用的持續時間,而不需要真正監聽到信道上的信號,因此虛擬載波監聽機制能減少隱蔽帶來的碰撞問題
3.7 MAC地址、IP地址以及ARP協議
3.7.1 MAC地址
- 當多個主機連接在同一個廣播信道上,要想實現兩個主機之間的通信,則每個主機都必須有一個唯一的標識,即一個數據鏈路層地址
-
在每個主機發送的幀中必須攜帶標識發送主機和接收主機的地址。由于這類地址是用于媒體接入控制MAC(Media Access Control),因此這類地址被稱為MAC地址
- MAC地址一般被固化在網卡(網絡適配器)的電可擦可編程只讀存儲器EEPROM中,因此MAC地址也被稱為硬件地址
- MAC地址有時也被稱為物理地址。請注意:這并不意味著MAC地址屬于網絡體系結構中的物理層!
- MAC地址一般被固化在網卡(網絡適配器)的電可擦可編程只讀存儲器EEPROM中,因此MAC地址也被稱為硬件地址
-
一般情況下,用戶主機會包含兩個網絡適配器:有線局域網適配器(有線網卡)和無線局域網適配器(無線網卡)。每個網絡適配器都有一個全球唯一的MAC地址。而交換機和路由器往往擁有更多的網絡接口,所以會擁有更多的MAC地址。綜上所述,嚴格來說,MAC地址是對網絡上各接口的唯一標識,而不是對網絡上各設備的唯一標識
-
IEEE 802局域網的MAC地址格式
-
單播MAC地址舉例
-
廣播MAC地址舉例
-
多播MAC地址舉例
由于多播地址的第一字節的b0為1,故可通過判斷十六進制的低位數是否可被2整除快速判斷是否為多播地址
給主機配置多播組列表進行私用應用時,不得使用公有的標準多播地址,具體可以在以下網址查詢
http://standards.ieee.org/develop/regauth/grpmac/public.html
3.7.2 IP地址
注意:IP地址屬于網絡層的內容
-
IP地址是因特網上的主機和路由器所使用的地址,用于標識兩部分信息
- 網絡編號:標識因特網上數以百萬計的網絡
- 主機編號:標識同一網絡上不同主機(或路由器各接口)
-
顯然,之前介紹的MAC地址不具備區分不同網絡的功能
- 如果只是一個單獨的網絡,不接入因特網,可以只是用MAC地址(這不是一般用戶的應用方式)
- 如果主機所在的網絡需要接入因特網,則IP地址和MAC地址都需要使用
-
從網絡體系結構看IP地址與MAC地址
-
數據包轉發過程中IP地址與MAC地址的變化情況
- 數據包轉發過程中源IP地址和目的IP地址保持不變
- 數據包轉發過程中源MAC地址和目的MAC地址逐個鏈路(或逐個網絡)改變
目前發送站知道應該將數據包轉給具體哪個路由或主機,發送站知道其目的站的IP地址,但不知道其對應的MAC地址是什么(將在后續的ARP協議中解釋)
3.7.3 ARP協議
-
主機B打算給C發送數據包。目前B知道C的IP地址,但不知道MAC地址,因此B的數據鏈路層封裝MAC幀時,無法填寫目的MAC地址
-
實際上,每臺主機都會有一個ARP高速緩存表。表中記錄有IP地址和MAC地址的對應關系,于是主機B在表中試圖查找主機C的IP地址
-
由于未找到,則主機B需要發送ARP請求報文(廣播)獲取主機C的MAC地址
-
主機C收到廣播后,首先將B的IP地址與MAC地址記錄到自己的ARP高速緩存表中,再給B發送ARP響應(單播),以告知自己的MAC地址
-
主機B收到主機C發送的ARP響應后,將對應信息添加在自己的ARP高速緩存中
其中每條記錄的類型分為動態(dynamic)和靜態(static)兩種:
- 動態:自動獲取,生命周期默認為2min
- 靜態:手工設置,不同的操作系統下的生命周期不同,例如系統重啟后不存在或系統重啟后依然有效
- ARP協議只能在一段鏈路或一個網絡上使用,而不能跨網絡使用,ARP協議的使用是逐段鏈路進行的
3.8 集線器與交換機的區別
-
早期的總線型以太網
-
使用雙絞線和集線器HUB的星型以太網
- 使用集線器的以太網在邏輯上仍是一個總線網,各站共享總線資源,使用的還是CSMA/CD協議
- 集線器只工作在物理層,它的每個接口僅簡單地轉發比特,不進行碰撞檢測(由各站的網卡檢測)
- 集線器一般都有少量的容錯能力和網絡管理功能。例如,若網絡中某個網卡出了故障,不停地發送幀。此時,集線器可以檢測到這個問題,在內部斷開與出故障網卡的連線,使整個以太網仍然能正常工作
-
使用集線器HUB在物理層擴展以太網
-
以太網交換機
- 以太網交換機通常都有多個接口。每個接口都可以直接與一臺主機或另一個以太網交換機相連。一般都工作在全雙工方式
- 以太網交換機具有并行性,能同時連通多對接口,使多對主機能同時通信,無碰撞(不使用CSMA/CD協議)
- 以太網交換機一般都具有多種速率的接口,例如:10Mb/s、100Mb/s、1Gb/s、10Gb/s接口的多種組合
- 以太網交換機工作在數據鏈路層(也包括物理層),它收到幀后,在幀交換表中查找幀的目的MAC地址所對應的接口號,然后通過該接口轉發幀
- 以太網交換機是一種即插即用設備,其內部的幀交換表是通過自學習算法自動地逐漸建立起來的
- 幀的兩種轉發方式:
- 存儲轉發
- 直通交換:采用基于硬件的交叉矩陣(交換時延非常小,但不檢查幀是否有差錯)
以下對比交換機中忽略ARP過程并且假設交換機的幀交換表已學習好了
-
單播對比
-
廣播對比
-
多臺主機同時給另一臺主機發送單播幀對比
產生碰撞
緩存并逐個發送,未產生碰撞
-
擴展對比
-
小結
3.9 以太網交換機自學習和轉發幀的流程
- 主機A給主機B發送數據
- 交換機1記錄A的MAC地址及對應的接口號
- 交換機1在幀交換表中未找到主機B的MAC地址信息,于是盲目轉發
- 交換機2收到數據后進行與交換機1相同的步驟
- 主機B給主機A發送數據
- 交換機1記錄B的MAC地址及對應的接口號
- 交換機1在幀交換表中找到了A的MAC地址對應的接口號,于是只需通過該接口轉發給主機A
- 主機E給主機A發送數據
- 交換機2記錄E的MAC地址及對應的接口號
- 交換機2在幀交換表中找到了A的MAC地址對應的接口號,于是只需通過該接口轉發給交換機1
- 交換機1記錄E的MAC地址及對應的接口號
- 交換機1在幀交換表中找到了A的MAC地址對應的接口號,于是只需通過該接口轉發給主機A
- 主機G給主機A發送數據(丟棄幀的情況)
- 主機A不借助交換機可直接收到主機G的數據
- 但數據依舊會傳到交換機1中,交換機1記錄G的MAC地址和接口號
- 交換機1找到了A的接口號,但發現與G的接口號是一致的,于是丟棄不再轉發該幀
幀交換表中,每條記錄都有自己的有效時間,到期自動刪除。這是因為MAC地址和交換機接口的對應關系并不是永久性的
- 交換機的接口改接了另一臺主機
- 主機更換了網卡
- 以太網交換機自學習和轉發幀的流程:
- 收到幀后進行登記。登記的內容為幀的源MAC地址及進入交換機的接口號
- 根據幀的目的MAC地址和交換機的幀交換表對幀進行轉發,有以下三種情況:
- 明確轉發:交換機知道應當從哪個(或哪些)接口轉發該幀(單播,多播,廣播)
- 盲目轉發:交換機不知道應當從哪個端口轉發幀,只能將其通過除進入交換機的接口外的其他所有接口轉發(也稱為泛洪)
- 明確丟棄:交換機知道不應該轉發該幀,將其丟棄
3.10 以太網交換機的生成樹協議STP

- 添加冗余鏈路可以提高以太網的可靠性
- 但是,冗余鏈路也會帶來負面效應——形成網絡環路
其帶來以下問題:- 廣播風暴
大量消耗網絡資源,使得網絡無法正常轉發其他數據幀 - 主機收到重復的廣播幀
大量消耗主機資源 - 交換機的幀交換表震蕩(漂移)
- 廣播風暴
- 以太網交換機使用生成樹協議STP(Spanning Tree Protocol),可以在增加冗余鏈路來提高網絡可靠性的同時又避免網絡環路帶來的各種問題
- 不論交換機之間采用怎樣的物理連接,交換機都能夠自動計算并構建一個邏輯上沒有環路的網絡,其邏輯拓撲結構必須是樹型的(無邏輯環路)
- 最終生成的樹型邏輯拓撲要確保連通整個網絡
- 當首次連接交換機或網絡物理拓撲發生變化時(有可能是人為改變或故障),交換機都將進行生成樹的重新計算
3.10.Extra 【番外篇】生成樹算法STA
https://www.bilibili.com/video/BV1St411d7uD
- 選舉根交換機
- 根交換機的選舉條件:網橋ID(BID)最小者當選
- 網橋ID由以下兩部分構成
- 優先級
- 范圍:0 - 61440
- 步長:4096
- 默認值:32768
- 交換機的基本MAC地址
- 優先級
- 網橋ID的比較方法:
- 優先級取值越小,則網橋ID就越小
- 若優先級相同,則比較MAC地址,從MAC地址的左側開始依次比較,數值小的,則網橋ID就越小
- 選舉根端口
- 在每個非根交換機上選出一個根端口RP(Root Port),并且只能是一個
- 根端口用于接收根交換機發來的BPDU,也用來轉發普通流量
- 根端口RP的選舉條件:
- BPDU接收端口到根交換機的路徑成本最小
- 若成本相同,則選擇對端(指預選根端口的另一端的端口)的網橋ID最小
- 若對端均指向同一交換機,則選擇對端的端口ID(PID)最小(比較規則與網橋ID類似)
- 優先級
- 范圍:0 - 240
- 步長:16
- 默認值:128
- 端口號
- 優先級
- BPDU接收端口到根交換機的路徑成本最小
- 選舉指定端口并阻塞備用端口
- 在每個網段上選出一個指定端口DP(Designated Port),并且只能是一個
- 指定端口用于轉發根交換機發來的BPDU,也用來轉發普通流量
- 指定端口的選舉條件:
- 根交換機的所有端口都是指定端口
- 根端口的對端端口一定是指定端口
- BPDU轉發端口到根交換機的路徑成本最小
- 若成本相同,則選擇本端的網橋ID最小
- 剩余端口成為備用端口AP(Alternate Port),將它們阻塞
3.11 虛擬局域網VLAN
3.11.1 虛擬局域網VLAN概述
-
以太網交換機工作在數據鏈路層(也包括物理層)
-
使用一個或多個以太網交換機互連起來的交換式以太網,其所有站點都屬于同一個廣播域
-
隨著交換式以太網規模的擴大,廣播域相應擴大,其帶來的弊端有:
- 廣播風暴
會浪費網絡資源和各主機的CPU資源 - 難以管理和維護
- 潛在的安全問題
- 廣播風暴
-
網絡中會頻繁出現廣播信息
- TCP/IP協議棧中的很多協議都會使用廣播:
- 地址解析協議ARP(已知IP地址,找出其相應的MAC地址)
- 路由信息協議RIP(一種小型的內部路由協議)
- 動態主機配置協議DHCP(用于自動配置IP地址)
- NetBEUI:Widnows下使用的廣播型協議
- IPX/SPX:Novel網絡的協議棧
- Apple Talk:Apple公司的網絡協議棧
- TCP/IP協議棧中的很多協議都會使用廣播:
-
分割廣播域的方法
- 使用路由器可以隔離廣播域
由于路由器默認情況下不對廣播數據包進行轉發,因此路由器很自然地就可以隔離廣播域。然而路由器的成本較高,局域網內部全部使用路由器來隔離廣播域是不現實的
- 使用路由器可以隔離廣播域
-
虛擬局域網VLAN(Virtual Local Area Network)是一種將局域網內的設備劃分成與物理位置無關的邏輯組的技術,這些邏輯組具有某些共同的需求
只有同一個VLAN才收得到廣播消息
3.11.2 虛擬局域網VLAN的實現機制
-
IEEE 802.1Q幀(也稱Dot One Q幀)對以太網的MAC幀格式進行了擴展,插入了4字節的VLAN標記
-
VLAN標記的最后12比特稱為VLAN標識符VID,它唯一地標志了以太網幀屬于哪一個VLAN
- VID的取值范圍是0 ~ 4095(000 ~ 212?12^{12}-1212?1)
- 0和4095都不用來表示VLAN,因此用于表示VLAN的VID的有效取值范圍是1 ~ 4094
-
802.1Q幀是由交換機來處理的,而不是用戶主機來處理的
- 當交換機收到普通的以太網幀時,會將其插入4字節的VLAN標記轉變為802.1Q幀,簡稱“打標簽”
- 當交換機轉發802.1Q幀時,可能會刪除其4字節VLAN標記轉變為普通以太網幀,簡稱“去標簽”
-
交換機的端口類型有以下三種:
- Access
- Trunk
- Hybrid
-
交換機各端口的缺省VLAN ID
- 在思科交換機上稱為Native VLAN,即本征VLAN
- 在華為交換機上稱為Port VLAN ID,即端口VLAN ID,簡記為PVID
-
Access端口
- Access端口一般用于連接用戶計算機
- Access端口只能屬于一個VLAN
- Access端口的PVID值與端口所屬VLAN的ID相同(默認為1)
- Access端口接收處理方法:
一般只接受“未打標簽”的普通以太網MAC幀。根據接收幀的端口的PVID給幀“打標簽”,即插入4字節VLAN標記字段,字段中的VID取值與端口的PVID取值相等 - Access端口發送處理方法:
若幀中的VID與端口的PVID相等,則“去標簽”并轉發該幀;否則不轉發
-
Trunk端口
- Trunk端口一般用于交換機之間或交換機與路由器之間的互連
- Trunk端口可以屬于多個VLAN
- 用戶可以設置Trunk端口的PVID值。默認情況下,Trunk端口的PVID值為1
- Trunk端口發送處理方法:
- 對VID等于PVID的幀,“去標簽”再轉發
- 對VID不等于PVID的幀,直接轉發
- Trunk端口接收處理方法:
- 接收“未打標簽”的幀,根據接收幀的端口的PVID給幀“打標簽”,即插入4字節VLAN標記字段,字段中的VID取值與端口的PVID取值相等
- 接收“已打標簽的幀”
為何trunk端口不都直接不去標簽,直接轉發和接收呢?
-
Hybrid端口
- Hybrid端口既可用于交換機之間或交換機與路由器之間的互連(同Trunk端口),也可用于交換機與用戶計算機之間的互連(同Access端口)
- Hybrid端口可以屬于多個VLAN(同Trunk端口)
- 用戶可以設置Hybrid端口的PVID值。默認情況下,Hybrid端口的PVID值為1(同Trunk端口)
- Hybrid端口發送處理方法(與Trunk端口不同)
查看幀的VID是否在端口的“去標簽”列表中:- 若存在,則“去標簽”后再轉發
- 若不存在,則直接轉發
- Hybrid端口接收處理方法(同Trunk端口)
- 接收“未打標簽”的幀,根據接收幀的端口的PVID給幀“打標簽”,即插入4字節VLAN標記字段,字段中的VID取值與端口的PVID取值相等
- 接收“已打標簽的幀”
四、網絡層
4.1 網絡層概述
- 網絡層的主要任務是實現網絡互連,進而實現數據包在各網絡之間的傳輸
- 要實現網絡層任務,需要解決以下主要問題:
- 網絡層向運輸層提供怎樣的服務(“可靠傳輸”還是“不可靠傳輸”)
- 網絡層尋址問題
- 路由選擇問題
- 因特網(Internet)是目前全世界用戶數量最多的互聯網,它使用TCP/IP協議棧
- 由于TCP/IP協議棧的網絡層使用網際協議IP,它是整個協議棧的核心協議,因此在TCP/IP協議棧中網絡層常稱為網際層
- 綜上所述,我們通過學習TCP/IP協議棧的網際層來學習網絡層的理論知識和實踐技術

4.2 網絡層提供的兩種服務
-
面向連接的虛電路服務
-
可靠通信由網絡來保證
-
必須建立網絡層的連接——虛電路VC(Virtual Circuit)
-
通信雙方沿著已建立的虛電路發送分組
-
目的主機的地址僅在連接建立階段使用,之后每個分組的首部只需攜帶一條虛電路的編號(構成虛電路的每一段鏈路都有一個虛電路編號)
-
這種通信方式如果再使用可靠傳輸的網絡協議,就可使所發送的分組最終正確到達接收方(無差錯按序到達、不丟失、不重復)
-
通信結束后,需要釋放之前所建立的虛電路
-
很多廣域分組交換網都使用面向連接的虛電路服務。例如,曾經的X.25和逐漸過時的幀中繼FR、異步傳輸模式ATM等
-
-
無連接的數據報服務
- 可靠通信應當由用戶主機來保證
- 不需要建立網絡層連接
- 每個分組可走不同的路徑
- 每個分組的首部必須攜帶目的主機的完整地址
- 這種通信方式所傳送的分組可能誤碼、丟失、重復和失序
- 由于網絡本身不提供端到端的可靠傳輸服務,這就使網絡中的路由器可以做得比較簡單,而且價格低廉(與電信網的交換機相比較)
- 因特網采用了這種設計思想,也就是將復雜的網絡處理功能置于因特網的邊緣(用戶主機和其內部的運輸層),而將相對簡單的盡最大努力的分組交付功能置于因特網核心
-
小結
由于TCP/IP體系結構的因特網的網際層提供的是最簡單靈活、無連接的、盡最大努力交付的數據報服務,因此本章主要圍繞網際層如何傳送IP數據報這個主題進行討論
4.3 IPv4地址
4.3.1 IPv4地址概述
-
在TCP/IP體系中,IP地址是一個最基本的概念,我們必須把它弄清楚
-
IPv4地址就是給因特網(Internet)上的每一臺主機(或路由器)的每一個接口分配一個在全世界范圍內是唯一的32比特的標識符
-
IP地址由因特網名字和數字分配機構ICANN(Internet Corporation for Assigned Names and Numbers)進行分配
- 我國用戶可向亞太網絡信息中心APNIC(Asia Pacific Network Information Center)申請IP地址,需要繳費
- 2011年2月3日,互聯網號碼分配管理局IANA(由ICANN行使職能)宣布,IPv4地址已經分配完畢
- 我國在2014至2015年也逐步停止了向新用戶和應用分配IPv4地址。同時全面開展商用部署IPv6
-
IPv4地址的編址方法經歷了如下三個歷史階段:
-
32比特的IPv4地址不方便閱讀、記錄以及輸入等,因此IPv4地址采用點分十進制表示方法以方便用戶使用
4.3.2 分類編址的IPv4地址

- 只有A類、B類和C類地址可分配給網絡中的主機或路由器的各接口
- **主機號為“全0”**的地址是網絡地址,不能分配給主機或路由器的各接口
- **主機號為“全1”**的地址是廣播地址,不能分配給主機或路由器的各接口
(這里的1.0.0.0地址貌似是不能指派的,因為主機號全0了)
- 可指派的網絡數量為28?1?2=1262^{8-1}-2=12628?1?2=126(減2的原因是除去最小網絡號0和最大網絡號127)
- 每個網絡中可分配的IP地址數量為224?2=167772142^{24}-2=16777214224?2=16777214(減2的原因是除去主機號為全0的網絡地址和全1的廣播地址)
注意:有些教材中指出128.0是保留網絡號,B類第一個可指派的網絡號為128.1
但根據2002年9月發表的RFC 3330文檔,128.0網絡號已經可以分配了。有興趣的同學可以自行查詢以128.0開頭的IP地址,看看它們屬于那些國家
- 可指派的網絡數量為216?2=163842^{16-2}=16384216?2=16384
- 每個網絡中可分配的IP地址數量為216?2=655342^{16}-2=65534216?2=65534(減2的原因是除去主機號為全0的網絡地址和全1的廣播地址)
- 可指派的網絡數量為224?3=20971522^{24-3}=2097152224?3=2097152
- 每個網絡中可分配的IP地址數量為28?2=2542^{8}-2=25428?2=254(減2的原因是除去主機號為全0的網絡地址和全1的廣播地址)
注意:有些教材中指出192.0.0是保留網絡號,C類第一個可指派的網絡號為192.0.1
但根據2002年9月發表的RFC 3330文檔,192.0.0網絡號已經可以分配了。只不過目前還沒有分配出去
4.3.3 劃分子網的IPv4地址

-
為新增網絡申請新的網絡號會帶來以下弊端:
- 需要等待時間和花費更多的費用
- 會增加其他路由器中路由表記錄的數量
- 浪費原有網絡中剩余的大量IP地址
-
從主機號部分借用一部分作為子網號
如果未在圖中標記子網號部分,那么我們和計算機又如何知道分類地址中主機號有多少比特被用作子網號了呢?
-
32比特的子網掩碼可以表明分類IP地址的主機號部分被借用了幾個比特作為子網號
- 子網掩碼使用連續的比特1來對應網絡號和子網號
- 子網掩碼使用連續的比特0來對應主機號
- 將劃分子網的IPv4地址與其相應的子網掩碼進行邏輯與運算就可得到IPv4地址所在子網的網絡地址
例題:
-
默認子網掩碼是指在未劃分子網的情況下使用的子網掩碼
4.3.4 無分類編址的IPv4地址
-
劃分子網在一定程度上緩解了因特網在發展中遇到的困難,但是數量巨大的C類網因為其地址空間太小并沒有得到充分使用,而因特網的IP地址仍在加速消耗,整個IPv4地址空間面臨全部耗盡的威脅
-
為此,因特網工程任務組IETF又提出了采用無分類編址的方法來解決IP地址緊張的問題,同時還專門成立IPv6工作組負責研究新版本IP以徹底解決IP地址耗盡問題
-
1993年,IETF發布了無分類域間路由選擇CIDR(Classless Inter-Domain Routing)的RFC文檔:RFC 1517~1519和1520
- CIDR消除了傳統的A類、B類和C類地址,以及劃分子網的概念
- CIDR可以更加有效地分配IPv4的地址空間,并且可以在新的IPv6使用之前允許因特網的規模繼續增長
-
CIDR使用“斜線記法”,或稱CIDR記法。即在IPv4地址后面加上斜線“/”,在斜線后面寫上網絡前綴所占的比特數量
-
CIDR實際上是將網絡前綴都相同的連續的IP地址組成一個“CIDR地址塊”
-
我們只要知道CIDR地址塊中的任何一個地址,就可以知道該地址塊的全部細節:
- 地址塊的最小地址
- 地址塊的最大地址
- 地址塊中的地址數量
- 地址塊聚合某類網絡(A類、B類或C類)的數量
- 地址掩碼(也可繼續稱為子網掩碼)
-
路由聚合(構造超網)
-
網絡前綴越長,地址塊越小,路由越具體
-
若路由器查表轉發分組時發現有多條路由可選,則選擇網絡前綴最長的那條,這稱為最長前綴匹配,因為這樣的路由更具體
4.3.5 IPv4地址的應用規劃
-
定長的子網掩碼FLSM(Fixed Length Subnet Mask)
- 使用同一個子網掩碼來劃分子網
- 每個子網所分配的IP地址數量相同,造成IP地址的浪費
應用需求:將C類網絡218.75.230.0劃分成5個子網,每個子網上可分配的IP地址數量不得少于各自的需求
注意:每個子網還需要一個額外的路由器接口地址
圖中的網絡5只需要4個IP地址,但是不得不分配32個IP地址,從而造成了嚴重的浪費
-
變長的子網掩碼VLSM(Variable Length Subnet Mask)
- 使用不同的子網掩碼來劃分子網
- 每個子網所分配的IP地址數量可以不同,盡可能減少對IP地址的浪費
應用需求:從地址塊218.75.230.0/24中取出5個地址塊(1個“/27”、3個“/28”、1個“/30”),按序分配給其中的5個網絡分配原則:每個子塊的起點位置不能隨意選取,只能選取塊大小整數倍的地址作為起點(保證同一個地址塊中的IP的網絡號及子網號的組合前綴是一致的),建議先給大的子塊分配
4.4 IP數據報的發送和轉發過程
為了將重點放在TCP/IP協議棧的網際層發送和轉發IP數據報的過程上,在之后的舉例中,我們忽略使用ARP協議來獲取目的主機或路由器接口的MAC地址的過程以及以太網交換機自學習和轉發幀的過程。
- IP數據報的發送和轉發過程包含以下兩部分:
- 主機發送IP數據報
- 路由器轉發IP數據報
舉例:
- 同一個網絡中的主機之間可以直接通信,屬于直接交付
- 不同網絡之間主鍵需要通過路由器中轉,屬于間接交付
源主機如何知道目的主機是否與自己在同一個網絡中?
將源主機IP與源主機子網掩碼相與得到本機網絡地址,再將目的主機IP與源主機子網掩碼相與得到目的網絡地址,再比對網絡地址即可,相同則說明在同一網絡中
-
主機C需要通過路由器轉發來向主機F通信
主機C如何知道該由哪個路由器轉發呢?
實際上,用戶為了讓本網絡的主機能和其他網絡中的主機進行通信,就必須給其指定本網絡中的一個路由器,由該路由器幫忙進行轉發。所指定的路由器也被稱為默認網關
對于本例,可將路由器接口0的IP地址,指定給該接口所直連網絡中的各個主機作為默認網關,右邊的網絡也是同理 -
主機A進行間接交付給主機D,其數據報通過默認網關發送給路由器
路由器收到IP數據報后如何轉發?
- 檢測IP數據報首部是否出錯:
- 若出錯,則直接丟棄該IP數據報并通告源主機
- 若沒有出錯,則進行轉發
- 根據IP數據報的目的地址在路由表中查找匹配的條目:
- 若找到匹配的條目,則轉發給條目中指示的下一跳
- 若找不到,則丟棄該IP數據報并通告源主機
- 檢測IP數據報首部是否出錯:
-
IP數據報首部未出錯,路由器將首部中的目的地址與路由表中地址掩碼相與,再比對是否匹配,若匹配則向其下一跳發送
-
廣播通信
4.5 靜態路由配置及其可能產生的路由環路問題
-
靜態路由配置是指用戶或網絡管理員使用路由器的相關命令給路由器人工配置路由表
- 這種人工配置方式簡單、開銷小。但不能及時適應網絡狀態(流量、拓撲等)的變化
- 一般只在小規模網絡中采用
-
使用靜態路由配置可能出現以下導致產生路由環路的錯誤
- 配置錯誤
- 聚合了不存在的網絡
- 網絡故障
-
【舉例】靜態路由配置
-
【舉例】默認路由
本例中,配置了默認路由后,甚至可刪除它的上一條路由 -
【舉例】特定主機路由
特定主機路由在路由表中的掩碼為全1即255.255.255.255 -
【舉例】靜態路由配置錯誤導致路由環路
為了防止IP數據報在路由環路中永久兜圈,在IP數據報首部設有生存時間TTL字段
IP數據報進入路由器后,TTL字段的值減1。若TTL的值不等于0,則被路由器轉發,否則被丟棄 -
【舉例】聚合了不存在的網絡而導致路由環路
對于該情況,可以在路由表中為聚合路由中不存在的網絡添加黑洞路由(其作為下一跳相當于丟棄了該數據報)
-
【舉例】網絡故障而導致路由環路
發送故障時,路由器會自動刪除路由表中與故障地址相關的條目,從而引起環路
同樣地,采用黑洞路由的方法為故障的目的網絡添加黑洞路由條目
該黑洞路由條目在該網絡故障時自動生效,而故障恢復后由于路由器自動得出了正確的路由條目,此時黑洞路由處于失效狀態 -
路由條目的類型
- 直連網絡
- 靜態路由(人工配置)
- 動態路由(路由選擇協議)
-
特殊的靜態路由條目
- 默認路由(目的網絡為0.0.0.0,地址掩碼為0.0.0.0)
- 特定主機路由(目的網絡為特定主機的IP地址,地址掩碼為255.255.255.255)
- 黑洞路由(下一跳為null0)
4.6 路由選擇協議
4.6.1 路由選擇協議概述
靜態路由選擇 | 動態路由選擇 |
---|---|
由人工配置的網絡路由、默認路由、特定主機路由、黑洞路由等都屬于靜態路由 | 路由器通過路由選擇協議自動獲取路由信息 |
這種人工配置方式簡單、開銷小。但不能及時適應網絡狀態(流量、拓撲等)的變化 | 比較復雜、開銷比較大。能較好地適應網絡狀態的變化 |
一般只在小規模網絡中采用 | 適用于大規模網絡 |
- 因特網所采用的路由選擇協議的主要特點
- 自適應:動態路由選擇,能較好地適應網絡狀態的變化
- 分布式:路由器之間交換路由信息
- 分層次:將整個因特網劃分為許多較小的自治系統AS(Autonomous System)

-
域間路由選擇采用外部網關協議EGP(現也稱外部路由協議ERP),域內路由選擇采用內部網關協議IGP(現也稱內部路由協議IRP)
-
路由選擇協議
- 內部網關協議IGP
- 路由信息協議RIP
基于距離向量,在因特網上最早使用 - 內部網關路由協議IGRP
基于距離向量,思科早期私有的協議,現在已被EGIRP取代 - 增強型內部網關路由協議EIGRP
思科私有協議,用來取代IGRP的混合型路由協議(結合距離向量和鏈路狀態) - 開放式最短路徑優先OSPF
基于鏈路狀態,在各種網絡中廣泛使用 - 中間系統到中間系統IS-IS
基于鏈路狀態,集成化IS-IS時ISP骨干網上最常用的IGP協議
- 路由信息協議RIP
- 外部網關協議EGP
- 邊界網關協議BGP
- 內部網關協議IGP
-
路由器的基本結構
- 信號從某個輸入端口進入路由器,物理層將信號轉換為比特流,并交付數據鏈路層處理
- 數據鏈路層從比特流中識別出幀,去掉幀頭和幀尾后,交付網絡層處理
- 若交付網絡層的分組是普通待轉發的數據分組,則根據分組首部中的目的地址進行查表轉發
- 若找不到匹配的轉發條目,則丟棄該分組
- 否則按照匹配條目中所指示的端口進行轉發
- 網絡層更新數據分組首部中某些字段的值(例如,將數據分組的生存時間減1),然后交付數據鏈路層進行封裝
- 數據鏈路層將數據分組封裝成幀交付網絡層處理
- 物理層將幀看作比特流,將其變換成相應的電信號進行發送
- 步驟3中,若交付網絡層的分組是路由器之間交換路由信息的路由報文,則把該分組送交路由選擇處理機,路由選擇處理機根據分組的內容來更新自己的路由表
- 路由表一般僅包含從目的網絡到下一跳的映射
- 路由表需要對網絡拓撲變化的計算最優化
- 轉發表是從路由表得出的
- 轉發表的結構應當使查找過程最優化
在之前的靜態路由配置的相關課程中,并未嚴格區分路由器中的路由表和轉發表,有助于簡化問題的分析
- 路由選擇處理機除了處理收到的路由報文外,還會周期性的給其他路由器發送自己所知道的路由信息
- 路由器的各端口還應具有輸入緩沖區和輸出緩沖區,輸入緩沖區用來暫存新進入路由器但還來不及處理的分組,輸出緩沖區用來暫存已經處理完畢但還來不及發送的分組(路由器的端口一般都同時具有輸入和輸出的功能,圖中分給出輸入和輸出目的在于更好地演示路由器的基本工作過程(過程在視頻里,這里是沒有滴))
4.6.2 路由信息協議RIP的基本工作原理
-
路由信息協議RIP(Routing Information Protocol)是內部網關協議IGP中最先得到廣泛使用的協議之一,其相關標準文檔為RFC 1058
-
RIP要求自治系統AS內的每一個路由器都要維護從它自己到AS內其他每一個網絡的距離記錄。這是一組距離,稱為“距離向量D-V(Distance-Vector)"
-
RIP使用跳數(Hop Count)作為度量(Metric)來衡量到達目的網絡的距離
- 路由器到直連網絡的距離定義為1
- 路由器到非直連網絡的距離定義為所經過的路由器數加1
- 允許一條路徑最多只能包含15個路由器。“距離”等于16時相當于不可達。因此,RIP只適用于小型互聯網
需要說明的是,有些路由器廠商并未嚴格按照RIP標準文檔的規定來實現RIP。例如思科路由器中的RIP,將路由器到直連網絡的距離定義為0,但這并不影響RIP的正常運行
-
RIP認為好的路由就是“距離短”的路由,也就是所通過路由器數量最少的路由
這里RIP認為R1到R5的好路由是:R1→R4→R5,盡管這條路由上各段鏈路的帶寬都非常小 -
當到達同一目的網絡有多條“距離相等”的路由時,可以進行等價負載均衡(即將通信量均衡地分布到多條等價的路由上)
-
RIP包含以下三個要點:
- 和誰交換信息?
僅和相鄰路由器交換信息
- 交換什么信息?
自己的路由表 - 何時交換信息?
周期性交換(例如每30秒)
- 和誰交換信息?
-
【舉例】RIP的基本工作過程
- 路由器剛開始工作時,只知道自己到直連網絡的距離為1
- 每個路由器僅和相鄰路由器周期性地交換并更新路由信息
- 若干次交換和更新后,每個路由器都知道到達本AS內各網絡的最短距離和下一跳地址,稱為收斂
-
【舉例】RIP的路由條目的更新規則
其中C路由表中下一跳的問號表示路由器D不必關心該信息路由器D收到C的路由表并將其如下改造
- 下一跳均設為C,因為是D轉發數據經過C再抵達這些網絡
- 距離在C路由表的基礎上加1,因為比C額外經過了C路由器
- 對于原路由表條目【N2 2 C】
由于新的改造后的C路由表中【N2 5 C】,說明C到N2的拓撲發生變化,應將其更新為【N2 5 C】
“到達目的網絡,相同下一跳,最新消息,更新” - 由于原路由表沒有N3相關的條目
于是將【N3 9 C】添加到路由表中
“發現了新的網絡,添加” - 對于原路由表條目【N6 8 F】
由于【N6 5 C】同屬于到達N6網絡,并且距離更短,因此將其更新為【N6 5 C】
“到達目的網絡,不同下一跳,新路由優勢,應當更新” - 對于原路由表條目【N8 4 E】
由于與【N8 4 C】距離相同且屬于不同下一跳,因此可將其添加到原表中進行等價負載均衡
“到達目的網絡,不同下一跳,等價負載均衡” - 對于原路由表條目【N9 4 F】
由于表中【N9 6 C】距離比其長,因此不做更新
“到達目的網絡,不同下一跳,新路由劣勢,不更新”
-
RIP存在“壞消息傳播得慢”的問題
R1直連的網絡N1發生故障,R1監測到后將其條目中距離改為16表示不可達,等待RIP更新周期到時后,發送路由信息給R2。假設R2的更新周期先到時,于是【N1 2 R1】信息先到達R1,于是R1被謠言誤導將條目改為【N1 3 R2】并在更新周期到時后發送給R2,于是R2也被謠言誤導條目改為【N1 4 R1】,接著來回往復傳遞謠言,最終距離抵達16才明白不可到達N1網絡- “壞消息傳播得慢”又稱為路由環路或距離無窮計數問題,這是距離向量算法的一個固有問題。可以采取多種措施減少出現該問題的概率或減小該問題帶來的危害
- 限制最大路徑距離為15(16表示不可達)
- 當路由表發生變化時就立即發送更新報文(即“觸發更新”),而不僅是周期性發送
- 讓路由器記錄收到某特定路由信息的接口,而不讓同一路由信息再通過此接口向反方向傳送(即“水平分割”)
- “壞消息傳播得慢”又稱為路由環路或距離無窮計數問題,這是距離向量算法的一個固有問題。可以采取多種措施減少出現該問題的概率或減小該問題帶來的危害
4.6.3開放最短路徑優先OSPF的基本工作原理
-
開放最短路徑優先OSPF(Open Shortest Path First),是為克服RIP的缺點在1989年開發出來的
- “開放”表明OSPF協議不是受某一家廠商控制,而是公開發表的
- “最短路徑優先”是因為使用了Dijkstra提出的最短路徑算法SPF
-
OSPF是基于鏈路狀態的,而不像RIP那樣是基于距離向量的
-
OSPF采用SPF算法計算路由,從算法上保證了不會產生路由環路
-
OSPF不限制網絡規模,更新效率高,收斂速度快
-
鏈路狀態是指本路由器都和哪些路由器相鄰,以及相應鏈路的“代價”(cost)
- “代價”用來表示費用、距離、時延、帶寬,等等。這些都由網絡管理人員來決定
【舉例】思科路由器中OSPF計算代價的方法:100Mbps/鏈路帶寬,計算結果小于1的值仍記為1;大于1且有小數的,舍去小數
- “代價”用來表示費用、距離、時延、帶寬,等等。這些都由網絡管理人員來決定
-
OSPF相鄰路由器之間通過交互問候(Hello)分組,建立和維護鄰居關系
- Hello分組封裝在IP數據報中,發往組播地址224.0.0.5
- 發送周期為10秒
- 40秒未收到來自鄰居路由器的Hello分組,則認為該鄰居路由器不可達
- Hello分組封裝在IP數據報中,發往組播地址224.0.0.5
-
使用OSPF的每個路由器都會產生鏈路狀態通告LSA(Link State Advertisement)。LSA中包含以下內容:
- 直連網絡的鏈路狀態信息
- 鄰居路由器的鏈路狀態信息
-
LSA被封裝在鏈路狀態更新分組LSU中,采用洪泛法發送
-
使用OSPF的每個路由器都有一個鏈路狀態數據庫LSDB,用于存儲LSA
-
通過各路由器洪泛發送封裝有自己LSA的LSU分組,各路由器的LSDB最終將達到一致
-
使用OSPF的各路由器基于LSDB進行最短路徑優先SPF計算,構建出各自到達其他各路由器的最短路徑,即構建各自的路由表
-
OSPF有以下五種分組類型類型
- 類型1,問候(Hello)分組
用來發現和維護鄰居路由器的可達性 - 類型2,數據庫描述(Database Description)分組
向鄰居路由器給出自己的鏈路狀態數據庫中的所有鏈路狀態項目的摘要信息 - 類型3,鏈路狀態請求(Link State Request)分組
向鄰居路由器請求發送某些鏈路狀態項目的詳細信息 - 類型4,鏈路狀態更新(Link State Update)分組
路由器使用這種分組將其鏈路狀態進行洪泛發送,即用洪泛法對全網更新鏈路狀態 - 類型5,鏈路狀態確認(Link State Acknowledgment)分組
這是對鏈路狀態更新分組的確認分組
- 類型1,問候(Hello)分組
-
OSPF的基本工作過程
- 相鄰路由器之間周期性發送問候分組,以便建立和維護鄰居關系
- 給鄰居路由器發送數據庫描述分組,即將自己的鏈路狀態數據庫中的所有鏈路狀態項目的摘要信息,發送給鄰居路由器
- R1收到R2發送的數據庫描述分組后,發現自己缺少其中的某些鏈路狀態項目,于是給R2發送鏈路狀態請求分組
- R2收到后,將R1所缺少的鏈路狀態項目的詳細信息封裝在鏈路狀態更新分組中發送給R1
- R1收到后,將這些所缺少的鏈路狀態項目的詳細信息添加到自己的鏈路狀態數據庫中,并給R2發送鏈路狀態確認分組
- 最終,R1和R2的鏈路狀態數據庫將達到一致,即鏈路狀態數據庫同步
- 每30分組或鏈路狀態發送變化時,路由器都會發送鏈路狀態更新分組,收到該分組的其他路由器將洪泛轉發該分組,并給該路由器發回鏈路狀態確認分組,這又稱為新情況下的鏈路狀態數據庫同步
-
OSPF在多點接入網絡中路由器鄰居關系的建立
若不采用其他機制,將會產生大量的多播分組
- 選舉指定路由器DR(designated router)和備用的指定路由器BDR(backup designated router)
- 所有的非DR/BDR只與DR/BDR建立鄰居關系
- 非DR/BDR之間通過DR/BDR交換信息
- 若DR出現問題,則由BDR頂替DR
-
為了使OSPF能夠用于規模很大的網絡,OSPF把一個自治系統再劃分為若干個更小的范圍,叫做區域(Area)
4.6.Extra Dijkstra最短路徑算法
算法執行大致步驟:
- 首先選擇一個點作為根結點
- 將根結點相鄰的結點記錄在表中,表中記錄每個點到根結點的最短距離以及其前驅結點,初始時表中的距離可視作無窮大
- 此時以根結點作為出發點的過程已完畢,做上標記,于是再以表中距離較小且為做完畢標記的結點為出發點
- 計算途經該出發點到它的鄰接點的距離(根到出發點距離 + 出發點到鄰接點距離),若計算出的距離小于表中原有距離則更新表(同時更新距離和前驅結點,前驅即為該出發點)
- 于是循環步驟3、4操作直到所有的點都做上標記說明路徑已全部計算完畢
4.6.4 邊界網關協議BGP的基本工作原理
-
外部網關協議EGP(例如邊界網關協議BGP)
- 在不同自治系統內,度量路由的“代價”(距離,帶寬,費用等)可能不同。因此,對于自治系統之間的路由選擇,使用“代價”作為度量來尋找最佳路由是不行的
- 自治系統之間的路由選擇必須考慮相關策略(政治,經濟,安全等)
- BGP只能是力求尋找一條能夠到達目的網絡且比較好的路由(不能兜圈子),而并非要尋找一條最佳路由
- 在配置BGP時,每個自治系統的管理員要選擇至少一個路由器作為該自治系統的“BGP發言人”
- 不同自治系統的BGP發言人要交換路由信息,首先必須建立TCP連接,端口號為179
- 在此TCP連接上交換BGP報文以建立BGP會話
- 利用BGP會話交換路由信息(例如,增加新的路由,或撤銷過時的路由,以及報告出錯的情況等)
- 使用TCP連接交換路由信息的兩個BGP發言人,彼此稱為對方的鄰站(neighbor)或對等站(peer)
- BGP發言人除了運行BGP外,還必須運行自己所在自治系統所使用的內部網關協議IGP,例如OSPF或RIP
-
BGP發言人交換網絡可達性的信息(要到達某個網絡所要經過的一系列自治系統)
-
當BGP發言人互相交換了網絡可達性的信息后,各BGP發言人就根據所采用的策略從收到的路由信息中找出到達各自治系統的較好的路由。也就是構造出樹形結構、不存在回路的自治系統連通圖
-
BGP適用于多級結構的因特網
-
BGP-4有以下四種報文
- OPEN(打開)報文:用來與相鄰的另一個BGP發言人建立關系,使通信初始化
- UPDATE(更新)報文:用來通告某一路由的信息,以及列出要撤銷的多條路由
- KEEPALIVE(保活)報文:用來周期性地證實鄰站的連通性
- NOTIFICATION(通知)報文:用來發送檢測到的差錯
- 在不同自治系統內,度量路由的“代價”(距離,帶寬,費用等)可能不同。因此,對于自治系統之間的路由選擇,使用“代價”作為度量來尋找最佳路由是不行的
4.7 IPv4數據報的首部格式
-
版本
占4比特,表示IP協議的版本
通信雙方使用的IP協議的版本必須一致。目前廣泛使用的IP協議版本號為4(即IPv4) -
首部長度
占4比特,表示IP數據報首部的長度。該字段的取值以4字節為單位
最小十進制取值為5,表示IP數據報首部只有20字節固定部分
最大十進制取值為15,表示IP數據報首部包含20字節固定部分和最大40字節可變部分 -
可選字段
長度從1個字節到40個字節不等。用來支持排錯、測量及安全等措施
可選字段增加了IP數據報的功能,但這同時也使得IP數據報的首部長度成為可變的。這就增加了每一個路由器處理IP數據報的開銷。實際上可選字段很少被使用 -
填充字段
確保首部長度為4字節的整數倍。使用全0進行填充 -
區分服務
占8比特,用來獲得更好的服務
該字段在舊標準中叫作服務類型,但實際上一直沒有被使用過
1998年,因特網工程任務組IETF把這個字段改名為區分服務
利用該字段的不同數值可提供不同等級的服務質量
只有在使用區分服務時,該字段才起作用。一般情況下都不使用該字段 -
總長度
占16比特,表示IP數據報的總長度(首部+數據載荷)
最大取值為十進制65535,以字節為單位
-
標識、標志、片偏移三個字段共同用于IP數據報分片
由于數據鏈路層的幀的數據載荷長度受限于最大傳輸單元MTU(例如,以太網規定MTU值為1500字節),因此當IP數據報長度超過MTU時,無法封裝,需要進行分片- 標識
占16比特,屬于同一個數據報的各分片數據報應該具有相同的標識
IP軟件維護一個計數器,每產生一個數據報,計數器值加1,并將此值賦給標識字段 - 標志
占3比特,各比特含義如下:- DF位:1表示不允許分片;0表示允許分片
- MF位:1表示“后面還有分片”;0表示“這是最后一個分片”
- 保留位:必須為0
- 片偏移
占13比特,指出分片數據報的數據載荷部分偏移其在原數據報的位置有多少個單位
片偏移以8個字節為單位
【舉例】對IPv4數據報進行分片
假定分片2的IP數據報經過某個網絡時還需要再進行分片
- 標識
-
生存時間TTL
占8比特,最初以秒為單位,最大生存周期為255秒;路由器轉發IP數據報時,將IP數據報首部中的該字段的值減去IP數據報在本路由器上所耗費的時間,若不為0就轉發,否則就丟棄
現在以“跳數”為單位,路由器轉發IP數據報時,將IP數據報首部中的該字段的值減1,若不為0就轉發,否則就丟棄
【舉例】生存時間TTL字段的作用——防止IP數據報在網絡中永久兜圈
-
協議
占8比特,指明IPv4數據報的數據部分是何種協議數據單元
常用的一些協議和相應的協議字段值如下協議名稱 協議字段值 ICMP 1 IGMP 2 TCP 6 UDP 17 IPv6 41 OSPF 89 -
首部檢驗和
占16比特,用來檢測首部在傳輸過程中是否出現差錯。比CRC檢驗碼簡單,稱為因特網檢驗和
IP數據報每經過一個路由器,路由器都要重新計算首部檢驗和,因為某些字段(生存時間、標志、片偏移等)的取值可能發生變化
由于IP層本身并不提供可靠傳輸的服務,并且計算首部校驗和是一項耗時的操作,因此在IPv6中,路由器不再計算首部校驗和,從而更快轉發IP數據報 -
源IP地址和目的IP地址
各占32比特,用來填寫發送該IP數據報的源主機的IP地址和接收該IP數據報的目的主機的IP地址
4.8 網際控制報文協議ICMP
-
為了更有效地轉發IP數據報和提高交付成功的機會,在網際層使用了網際控制報文協議ICMP(Internet Control Message Protocol)
-
主機或路由器使用ICMP來發送差錯報告報文和詢問報文
-
ICMP報文被封裝在IP數據報中發送
-
ICMP差錯報告報文共有以下五種:
-
終點不可達
當路由器或主機不能交付數據報時,就向源點發送終點不可達報文。具體可再根據ICMP的代碼字段細分為目的網絡不可達目的主機不可達、目的協議不可達、目的端口不可達、目的網絡未知、目的主機未知等13種錯誤
-
源點抑制
當路由器或主機由于擁塞而丟棄數據報時,就向源點發送源點抑制報文,使源點知道應當把數據報的發送速率放慢
-
時間超過
當路由器收到一個目的IP地址不是自己的IP數據報,會將其生存時間TTL字段的值減1。若結果不為0,則將該IP數據報轉發出去;若結果為0,除丟棄該IP數據報外,還要向源點發送時間超過報文
另外,當終點在預先規定的時間內不能收到一個數據報的全部數據報片時,就把已收到的數據報片都丟棄,也會向源點發送時間超過報文
-
參數問題
當路由器或目的主機收到IP數據報后,根據其首部中的檢驗和字段發現首部在傳輸過程中出現了誤碼,就丟棄該數據報,并向源點發送參數問題報文
-
改變路由(重定向)
路由器把改變路由報文發送給主機,讓主機知道下次應將數據報發送給另外的路由器(可通過更好的路由)
-
-
以下情況不應發送ICMP差錯報告報文
- 對ICMP差錯報告報文不再發送ICMP差錯報告報文
- 對第一個分片的數據報片的所有后續數據報片都不發送ICMP差錯報告報文
- 對具有多播地址的數據報都不發送ICMP差錯報告報文
- 對具有特殊地址(如127.0.0.0或0.0.0.0)的數據報不發送ICMP差錯報告報文
-
常用的ICMP詢問報文有以下兩種:
- 回送請求和回答
ICMP回送請求報文是由主機或路由器向一個特定的目的主機發出的詢問。
收到此報文的主機必須給源主機或路由器發送ICMP回送回答報文。
這種詢問報文用來測試目的站是否可達及了解其有關狀態。 - 時間戳請求和回答
ICMP時間戳請求報文是請某個主機或路由器回答當前的日期和時間。
在ICMP時間戳回答報文中有一個32位的字段,其中寫入的整數代表從1900年1月1日起到當前時刻一共有多少秒。
這種詢問報文用來進行時鐘同步和測量時間
- 回送請求和回答
-
ICMP應用舉例
-
分組網間探測PING(Packet InterNet Groper)
- 用來測試主機或路由器間的連通性
- 應用層直接使用網際層的ICMP(沒有通過運輸層的TCP或UDP)
- 使用ICMP回送請求和回答報文
-
跟蹤路由traceroute
- 用來測試IP數據報從源主機到達目的主機要經過哪些路由器
- Windows版本
- tracert命令
- 應用層直接使用網際層ICMP
- 使用了ICMP回送請求和回答報文以及差錯報告報文
- Unix版本
- traceroute命令
- 在運輸層使用UDP協議
- 僅使用ICMP差錯報告報文
 不斷從1開始增加數據報的生存時間TTL,借助ICMP差錯報告中的時間超過來獲取沿途的路由器信息,直至收到目的主機返回的回答報文
-
4.9 虛擬專用網VPN與網絡地址轉換NAT
-
虛擬專用網VPN(Virtual Private Network)
利用公用的因特網作為本機構各專用網之間的通信載體,這樣的專用網又稱為虛擬專用網。由于IPv4地址的緊缺,一個機構能夠申請到的IPv4地址數量往往遠小于本機構所擁有的主機數量。因此,虛擬專用網中的各主機所分配的地址應該是本機構可自由分配的專用地址,而不是需要申請的、在因特網上使用的公有地址
如下圖所示,同一機構內不同部門的內部網絡所構成的虛擬專用網VPN又稱為內聯網VPN
有時一個機構的VPN需要有某些外部機構(通常就是合作伙伴)參加進來。這樣的VPN就稱為外聯網VPN
在外地工作的員工需要訪問公司內部的專用網絡時,只要在任何地點接入到因特網,運行駐留在員工PC中的VPN軟件,在員工的PC和公司的主機之間建立VPN隧道,即可訪問專用網絡中的資源。這種VPN稱為遠程接入VPN -
網絡地址轉換NAT(Network Address Translation)
雖然因特網采用了無分類編址方式來減緩IPv4地址空間耗盡的速度,但由于因特網用戶數目的激增,特別是大量小型辦公室網絡和家庭網絡接入因特網的需求不斷增加,IPv4地址空間即將面臨耗盡的危險仍然沒有被解除
1994年提出了一種網絡地址轉換NAT的方法再次緩解了IPv4地址空間即將耗盡的問題
NAT能使大量使用內部專用地址的專用網絡用戶共享少量外部全球地址來訪問因特網上的主機和資源
該轉換方法存在一個問題:如果NAT路由器具有N個全球IP地址,那么至多只能有N個內網主機能夠同時和因特網上的主機通信。
由于絕大多數的網絡應用都是使用運輸層協議TCP或UDP來傳送數據,因此可以利用運輸層的端口號和IP地址一起進行轉換
這樣,用一個全球IP地址就可以使多個擁有本地地址的主機同時和因特網上的主機進行通信。這種將端口號和IP地址一起進行轉換的技術叫作網絡地址與端口號轉換NAPT(Network Address and Port Translation)外網主機是否可以首先發起通信?
不可以,若由外網主機首先發起,當NAPT路由器收到來自外網的IP數據報后,在NAPT轉換表中找不到相應的記錄,也就無法把數據報轉發給內網的主機。因此,使用私有地址的主機不能直接充當因特網服務器
對于一些P2P網絡應用,需要外網主機主動與內網主機進行通信,在通過NAT時會遇到問題,需要網絡應用自己使用一些特殊的NAT穿越技術來解決問題
另外,由于NAT對外網屏蔽了內網主機的網絡地址,能為內網的主機提供一定的安全保護
五、運輸層
5.1 運輸層概述
- 之前課程所介紹的計算機網絡體系結構中的物理層、數據鏈路層以及網絡層它們共同解決了將主機通過異構網絡互聯起來所面臨的問題,實現了主機到主機的通信
- 但實際上在計算機網絡中進行通信的真正實體是位于通信兩端主機中的進程
- 如何為運行在不同主機上的應用進程提供直接的通信服務是運輸層的任務,運輸層協議又稱為端到端協議
- 運輸層向高層用戶屏蔽了下面網絡核心的細節(如網絡拓撲、所采用的路由選擇協議等),它使應用進程看見的就好像是在兩個運輸層實體之間有一條端到端的邏輯通信信道
- 根據應用需求的不同,因特網的運輸層為應用層提供了兩種不同的運輸協議,即面向連接的TCP和無連接的UDP,這兩種協議就是本章要討論的主要內容
5.2 運輸層端口號、復用與分用的概念
-
運行在計算機上的進程使用進程標識符PID來標志
-
因特網上的計算機并不是使用統一的操作系統,不同的操作系統(Windows、Linux、Mac OS)又使用不同格式的進程標識符
-
為了使運行不同操作系統的計算機的應用進程之間能夠進行網絡通信,就必須使用統一的方法對TCP/IP體系的應用進程進行標識
-
TCP/IP體系的運輸層使用端口號來區分應用層的不同應用進程
- 端口號使用16比特表示,取值范圍0 ~ 65535
- 熟知端口號:0~1023,IANA把這些端口號指派給了TCP/IP體系中最重要的一些應用協議,例如:FTP使用21/20,HTTP使用80,DNS使用53
- 登記端口號:1024~49151,為沒有熟知端口號的應用程序使用。使用這類端口號必須在IANA按照規定的手續登記,以防止重復。例如:Microsoft RDP微軟遠程桌面使用的端口是3389
- 短暫端口號:49152~65535,留給客戶進程選擇暫時使用。當服務器進程收到客戶進程的報文時,就知道了客戶進程所使用的動態端口號。通信結束后,這個端口號可供其他客戶進程以后使用
- 端口號只具有本地意義,即端口號只是為了標識本計算機應用層中的各進程,在因特網中,不同計算機中的相同端口號是沒有聯系的
- 端口號使用16比特表示,取值范圍0 ~ 65535
-
發送方的復用和接收方的分用
(聽麻了……) -
TCP/IP體系的應用層常用協議所使用的運輸層熟知端口號
-
【舉例】運輸層端口號
計算機網絡微課堂(有字幕無背景音樂版)_嗶哩嗶哩_bilibili - p58
自己看,從6:00開始全是
5.3 UDP和TCP的對比
- 用戶數據報協議UDP(User Datagram Protocol)
傳輸控制協議TCP(Transmission Control Protocol)

- 無連接的UDP:可隨時發送數據
面向連接的TCP:在數據通信之前,必須通過**“三報文握手”建立TCP連接**,建立成功后才能進行數據傳輸,數據傳輸結束后必須通過**“四報文揮手”釋放連接**(這里所謂的連接是指邏輯連接關系,而非物理連接)

- UDP支持單播、多播以及廣播;TCP僅支持單播

- UDP是面向應用報文的:UDP對應用進程交下來的報文既不合并也不拆分,而是保留這些報文的邊界
TCP是面向字節流的:這正是TCP實現可靠傳輸、流量控制、以及擁塞控制的基礎

- UDP向上層提供無連接不可靠傳輸服務:對于誤碼報文僅丟棄,中途丟失的報文不做任何處理。適用于IP電話、視頻會議等實時應用
TCP向上層提供面向連接的可靠傳輸服務:基于TCP連接的可靠信道,不會出現傳輸差錯(誤碼、丟失、亂序、重復)。適用于要求可靠傳輸的應用,例如文件傳輸
- UDP用戶數據報首部僅8字節
TCP報文段首部最小20字節,最大60字節
5.3.A UDP校驗
- 偽首部
在計算檢驗和時,要在UDP用戶數據報之前增加12個字節的偽首部。偽首部只是臨時添加的,其既不向下傳送也不向上遞交,而僅僅為了計算檢驗和。其如圖依次由以下5部分組成:- 源IP地址(4字節)
- 目的IP地址(4字節)
- 全0(1字節)
- IP首部中的協議字段值(1字節)
- UDP用戶數據報的長度(2字節)
與首部的長度字段是一致的,為何這樣冗余設計?
這是書上UDP校驗和計算和校驗的例子
書上這里的**“按二進制反碼運算求和”**,即在一般加法求和運算的基礎上將最高位的進位又加到了最低為上
但經網絡資料查閱,二進制反碼求和貌似與書上的運算有出入。其大概可解釋為以下兩種運算方式:
- 將各參與計算的二進制數求和,且最高位產生的進位需再加到最低位,最后將求和結果取反
- 將各參與計算的二進制數先取反,再求和,同樣地“循環進位”,求和結果即為最終結果
當然也可能是我理解錯了,大概是在書上的基礎上加了取反的一步。以下驗證按照書上的運算解釋
校驗實現步驟:
- 發送前將UDP的偽首部、首部、數據部分看作整體后,以16位(2字節)字分割,若數據部分長度為奇數字節,則在末尾填充1字節的全0(與偽首部一樣也是臨時添加),計算之前首部的校驗和也為全0
- 將分割后的全部16位字按二進制反碼運算求和,并將求和結果取反寫入首部的檢驗和
- 當接收到該UDP報文,可以按上述方法進行二進制反碼求和,若結果全為1(FFFFH),說明無差錯,否則有差錯
證明:
-
將檢驗和除外的其他數據二進制反碼和記為SSS,發送前計算出的檢驗和結果為XXX,步驟2的計算可表示為:
X=S+0 ̄=S ̄X=\overline{S+0} =\overline{S} X=S+0?=S
其中000表示檢驗和初始值為全0 -
證明步驟3的檢驗依據,即證明:S+X=FFFFHS+X=\mathrm{FFFFH}S+X=FFFFH
S+X=S+S ̄=FFFFHS+X=S+\overline{S}=\mathrm{FFFFH} S+X=S+S=FFFFH
還就內個證畢,怎么說
這種簡單的差錯檢驗方法的檢錯能力并不強,但它的好處是簡單,處理起來較快
5.4 TCP的流量控制
- 一般來說,我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快,接收方就可能來不及接收,這就會造成數據的丟失
- 所謂流量控制(flow control)就是讓發送方的發送速率不要太快,要讓接收方來得及接收
- 利用滑動窗口機制可以很方便地在TCP連接上實現對發送方的流量控制
- TCP接收方利用自己的接收窗口的大小來限制發送方發送窗口的大小
- TCP發送方收到接收方的零窗口通知后,應啟動持續計時器。持續計時器超時后,向接收方發送零窗口探測報文
- 【舉例】
5.5 TCP的擁塞控制
- 在某段時間,若對網絡中某一資源的需求超過了該資源所能提供的可用部分,網絡性能就要變壞。這種情況就叫做擁塞(congestion)
- 在計算機網絡中的鏈路容量(即帶寬)、交換結點中的緩存和處理機等,都是網絡的資源
- 若出現擁塞而不進行控制,整個網絡的吞吐量將隨輸入負荷的增大而下降
- 擁塞控制的四種算法:
- 慢開始(slow-start)
- 擁塞避免(congestion avoidance)
- 快重傳(fast retransmit)
- 快恢復(fast recovery)
下面介紹這四種擁塞控制算法的基本原理,假定如下條件:
- 數據是單方向傳送,而另一個方向只傳送確認
- 接收方總是有足夠大的緩存空間,因而發送方發送窗口的大小由網絡的擁塞程度來決定
- 以最大報文段MSS的個數為討論問題的單位,而不是以字節為單位
- 發送方維護一個叫做擁塞窗口cwnd的狀態變量,其值取決于網絡的擁塞程度,并且動態變化
- 擁塞窗口cwnd的維護原則:只要網絡沒有出現擁塞,擁塞窗口就再增大一些;但只要網絡出現擁塞,擁塞窗口就減少一些
- 判斷出現網絡擁塞的依據:沒有按時收到應當到達的確認報文(即發生超時重傳)
- 發送方將擁塞窗口作為發送窗口swnd,即swnd = cwnd
- 維護一個慢開始門限ssthresh狀態變量:
- 當cwnd < ssthresh時,使用慢開始算法
- 當cwnd > ssthresh時,停止使用慢開始算法而改用擁塞避免算法
- 當cwnd = ssthresh時,既可使用慢開始算法,也可使用擁塞避免算法
-
“慢開始”是指一開始向網絡注入的報文段少,并不是指擁塞窗口cwnd增長速度慢
-
“擁塞避免”并非指完全能夠避免擁塞,而是指在擁塞避免階段將擁塞窗口控制為按線性規律長,使網絡比較不容易出現擁塞
-
慢開始和擁塞避免算法是1988年提出的TCP擁塞控制算法(TCP Tahoe版本)
-
1990年又增加了兩個新的擁塞控制算法(改進TCP的性能),這就是快重傳和快恢復(TCP Reno版本)
- 有時,個別報文段會在網絡中丟失,但實際上網絡并未發生擁塞
- 這將導致發送方超時重傳,并誤認為網絡發生了擁塞
- 發送方把擁塞窗口cwnd又設置為最小值1,并錯誤地啟動慢開始算法,因而降低了傳輸效率
- 有時,個別報文段會在網絡中丟失,但實際上網絡并未發生擁塞
-
采用快重傳算法可以讓發送方盡早知道發生了個別報文段的丟失
-
所謂快重傳,就是使發送方盡快進行重傳,而不是等超時重傳計時器超時再重傳
- 要求接收方不要等待自己發送數據時才進行捎帶確認,而是要立即發送確認
- 即使收到了失序的報文段也要立即發出對已收到的報文段的重復確認
- 發送方一旦收到3個連續的重復確認,就將相應的報文段立即重傳,而不是等該報文段的超時重傳計時器超時再重傳
- 對于個別丟失的報文段,發送方不會出現超時重傳,也就不會誤認為出現了擁塞(進而降低擁塞窗口cwnd為1)。使用快重傳可以使整個網絡的吞吐量提高約20%
-
發送方一旦收到3個重復確認,就知道現在只是丟失了個別的報文段。于是不啟動慢開始算法,而執行快恢復算法
- 發送方將慢開始門限ssthresh值和擁塞窗口cwnd值調整為當前窗口的一半,開始執行擁塞避免算法
- 也有的快恢復實現是把快恢復開始時的擁塞窗口cwnd值再增大一些,即等于新的ssthresh+3
- 既然發送方收到3個重復的確認,就表明有3個數據報文段已經離開了網絡
- 這3個報文段不再消耗網絡資源而是停留在接收方的接收緩存中
- 可見現在網絡中不是堆積了報文段而是減少了3個報文段。因此可以適當把擁塞窗口擴大些
5.6 TCP超時重傳時間的選擇

-
不能直接使用某次測量得到的RTT樣本來計算超時重傳時間RTO
-
利用每次測量得到的RTTRTTRTT樣本,計算加權平均往返時間RTTSRTT_SRTTS?(又稱為平滑的往返時間)
RTTS1=RTT1RTTSn=(1?α)×RTTSn?1+α×RTTn\begin{array}{l} RTT_{S_1}=RTT_1 \\ RTT_{S_n}=(1-\alpha )\times RTT_{S_{n-1}}+\alpha \times RTT_n \end{array} RTTS1??=RTT1?RTTSn??=(1?α)×RTTSn?1??+α×RTTn??在上式中,0≤α<10\le \alpha < 10≤α<1:
- 若α\alphaα很接近于0,則新RTTRTTRTT樣本對RTTSRTT_SRTTS?的影響不大
- 若α\alphaα很接近于1,則新RTTRTTRTT樣本對RTTSRTT_SRTTS?的影響較大
已成為建議標準的RFC6298推薦的α\alphaα的值為0.125
-
用這種方法得出的加權平均往返時間RTTSRTT_SRTTS?就比測量出的RTTRTTRTT值更加平滑
-
顯然,超時重傳時間RTORTORTO應略大于加權平均往返時間RTTRTTRTT
-
RFC6298建議使用下式計算超時重傳時間RTORTORTO:
RTO=RTTS+4×RTTDRTO=RTT_S+4\times RTT_D RTO=RTTS?+4×RTTD?
其中RTTDRTT_DRTTD?為RTTRTTRTT偏差的加權平均,具體計算如下:
RTTD1=RTT1÷2RTTDn=(1?β)×RTTDn?1+β×∣RTTSn?RTTn∣(0≤β<1)\begin{array}{l} RTT_{D_1}=RTT_1\div 2 \\ RTT_{D_n}=(1-\beta )\times RTT_{D_{n-1}}+\beta \times |RTT_{S_n}-RTT_n|(0\le \beta <1) \end{array} RTTD1??=RTT1?÷2RTTDn??=(1?β)×RTTDn?1??+β×∣RTTSn???RTTn?∣(0≤β<1)?RFC6298推薦β\betaβ值為0.25
-
往返時間RTT的測量比較復雜
- 源主機若誤將確認當作是對原報文段的確認,所計算出的RTTSRTT_SRTTS?和RTORTORTO就會偏大,降低了傳輸效率
- 源主機若誤將確認當作是對重傳報文段的確認,所計算出的RTTSRTT_SRTTS?和RTORTORTO就會偏小,導致報文段沒必要的重傳,增大網絡負荷
-
針對出現超時重傳時無法測準往返時間RTT的問題,Karn提出了一個算法:在計算加權平均往返時間RTTs時,只要報文段重傳了,就不采用其往返時間RTT樣本。也就是出現重傳時,不重新計算RTTs,進而超時重傳時間RTO也不會重新計算
- 這又引起了新的問題。設想出現這樣的情況:報文段的時延突然增大了很多,并且之后很長一段時間都會保持這種時延。因此在原來得出的重傳時間內,不會收到確認報文段。于是就重傳報文段。但根據Karn算法,不考慮重傳的報文段的往返時間樣本。這樣,超時重傳時間就無法更新。這會導致報文段反復被重傳
-
因此,要對Karn算法進行修正。方法是:報文段每重傳一次,就把超時重傳時間RTO增大一些。典型的做法是將新RTO的值取為舊RTO值的2倍

5.7 TCP可靠傳輸的實現
- TCP基于以字節為單位的滑動窗口來實現可靠傳輸
這里建議看視頻,我開擺了
計算機網絡微課堂(有字幕無背景音樂版)_嗶哩嗶哩_bilibili - p63
- 雖然發送方的發送窗口是根據接收方的接收窗口設置的,但在同一時刻,發送方的發送窗口并不總是和接方的接收窗口一樣大
- 網絡傳送窗口值需要經歷一定的時間滯后,并且這個時間還是不確定的
- 發送方還可能根據網絡當時的擁塞情況適當減小自己的發送窗口尺寸
- 對于不按序到達的數據應如何處理,TCP并無明確規定
- 如果接收方把不按序到達的數據一律丟棄,那么接收窗口的管理將會比較簡單,但這樣做對網絡資源的利用不利,因為發送方會重復傳送較多的數據
- TCP通常對不按序到達的數據是先臨時存放在接收窗口中,等到字節流中所缺少的字節收到后,再按序交付上層的應用進程
- TCP要求接收方必須有累積確認和捎帶確認機制,這樣可以減小傳輸開銷。接收方可以在合適的時候發送確認,也可以在自己有數據要發送時把確認信息順便捎帶上
- 接收方不應過分推遲發送確認,否則會導致發送方不必要的超時重傳,這反而浪費了網絡的資源
TCP標準規定,確認推遲的時間不應超過0.5秒。若收到一連串具有最大長度的報文段,則必須每隔一個報文段就發送一個確認[RFC 1122] - 捎帶確認實際上并不經常發生,因為大多數應用程序很少同時在兩個方向上發送數據
- 接收方不應過分推遲發送確認,否則會導致發送方不必要的超時重傳,這反而浪費了網絡的資源
- TCP的通信是全雙工通信。通信中的每一方都在發送和接收報文段。因此,每一方都有自己的發送窗口和接收窗口。在談到這些窗口時,一定要弄清楚是哪一方的窗口
5.8 TCP的運輸連接管理
-
TCP是面向連接的協議,它基于運輸連接來傳送TCP報文段
-
TCP運輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程
-
TCP運輸連接有以下三個階段:
- 建立TCP連接
- 數據傳送
- 釋放TCP連接
-
TCP的運輸連接管理就是使運輸連接的建立和釋放都能正常地進行
5.8.1 TCP的連接建立
-
TCP的連接建立要解決以下三個問題:
- 使TCP雙方能夠確知對方的存在
- 使TCP雙方能夠協商一些參數(如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量等)
- 使TCP雙方能夠對運輸實體資源(如緩存大小、連接表中的項目等)進行分配
-
TCP使用“三報文握手”建立連接
注意:TCP的標準規定,SYN=1的報文段不能攜帶數據,但要消耗掉一個序號;普通的確認報文段如果不攜帶數據,則不消耗序號第三次“握手”發送針對TCP連接請求的確認的確認是否多余,是否可改為僅通過“兩次握手”實現建立連接?
不多余。這是為了防止已失效的連接請求報文段突然又傳送到了TCP服務器,因而導致錯誤
5.8.2 TCP的連接釋放
-
TCP通過”四報文揮手“來釋放連接
最后的TCP客戶端時間等待是否有必要?
有必要。
-
保活計時器
- TCP服務器進程每收到一次TCP客戶進程的數據,就重新設置并啟動保活計時器(2小時定時)
- 若保活計時器定時周期內未收到TCP客戶進程發來的數據,則當保活計時器到時后,TCP服務器進程就向TCP客戶進程發送一個探測報文段,以后則每隔75秒鐘發送一次。若一連發送10個探測報文段后仍無TCP客戶進程的響應,TCP服務器進程就認為TCP客戶進程所在主機出了故障,接著就關閉這個連接
5.9 TCP報文段的首部格式

- 為了實現可靠傳輸,TCP采用了面向字節流的方式
- 但TCP在發送數據時,是從發送緩存取出一部分或全部字節并給其添加一個首部使之成為TCP報文段后進行發送
- 一個TCP報文段由首部和數據載荷兩部分構成
- TCP的全部功能都體現在它首部中各字段的作用
- 源端口:占16比特,寫入源端口號,用來標識發送該TCP報文段的應用進程
- 目的端口:占16比特,寫入目的端口號,用來標識接收該TCP報文段的應用進程

- 序號:占32比特,取值范圍[0,232?1][0,2^{32}-1][0,232?1],序號增加到最后一個后,下一個序號就又回到0
指出本TCP報文段數據載荷的第一個字節的序號

-
確認號:占32比特,取值范圍[0,232?1][0,2^{32}-1][0,232?1],確認號增加到最后一個后,下一個確認號就又回到0
指出期望收到對方下一個TCP報文段的數據載荷的第一個字節的序號,同時也是對之前收到的所有數據的確認若確認號=n,則表明到序號n-1為止的所有數據都已正確接收,期望接收序號為n的數據
-
確認標志位ACK:取值為1時確認號字段才有效;取值為0時確認號字段無效
TCP規定,在連接建立后所有傳送的TCP報文段都必須把ACK置1

-
數據偏移:占4比特,并以4字節為單位。
用來指出TCP報文段的數據載荷部分的起始處距離TCP報文段的起始處有多遠這個字段實際上是指出了TCP報文段的首部長度。
首部固定長度為20字節,因此數據偏移字段的最小值為(0101)2(0101)_2(0101)2?
首部最大長度為60字節,因此數據偏移字段的最大值為(1111)2(1111)_2(1111)2?

-
保留:占6比特,保留為今后使用,但目前應置為0
-
窗口:占16比特,以字節為單位。指出發送本報文段的一方的接收窗口
窗口值作為接收方讓發送方設置其發送窗口的依據。
這是以接收方的接收能力來控制發送方的發送能力,稱為流量控制。發送窗口的大小還取決于擁塞窗口的大小,也就是應該從接收窗口和擁塞窗口中取小者
-
校驗和:占16比特,檢查范圍包括TCP報文段的首部和數據載荷兩部分
在計算校驗和時,要在TCP報文段的前面加上12字節的偽首部 -
同步標志位SYN:在TCP連接建立時用來同步序號

- 終止標志位FIN:用來釋放TCP連接

-
復位標志位RST:用來復位TCP連接
當RST=1時,表明TCP連接出現了異常,必須釋放連接,然后再重新建立連接。
RST置1還用來拒絕一個非法的報文段或拒絕打開一個TCP連接。 -
推送標志位PSH:接收方的TCP收到該標志位為1的報文段會盡快上交應用進程,而不必等到接收緩存都填滿后再向上交付
-
緊急標志位URG:取值為1時緊急指針字段有效;取值為0時緊急指針字段無效
-
緊急指針:占16比特,以字節為單位,用來指明緊急數據的長度
當發送方有緊急數據時,可將緊急數據插隊到發送緩存的最前面,并立刻封裝到一個TCP報文段中進行發送。緊急指針會指出本報文段數據載荷部分包含了多長的緊急數據,緊急數據之后是普通數據。
-
選項
- 最大報文段長度MSS選項:TCP報文段數據載荷部分的最大長度
- 窗口擴大選項:為了擴大窗口(提高吞吐率)
- 時間戳選項:
- 用來計算往返時間RTT
- 用于處理序號超范圍的情況,又稱為防止序號繞回PAWS
- 選擇確認選項
-
填充:由于選項的長度可變,因此使用填充來確保報文段首部能被4整除(因為數據偏移字段,也就是首部長度字段,是以4字節為單位的)
六、應用層
6.1 應用層概述
- 應用層是計算機網絡體系結構的最頂層,是設計和建立計算機網絡的最終目的,也是計算機網絡中發展最快的部分
- 早期基于文本的應用(電子郵件、遠程登錄、文件傳輸、新聞組)
- 20世紀90年代將因特網帶入干家萬戶的萬維網WWW
- 當今流行的即時通信、P2P文件共享及各種音視頻應用
- 計算設備的小型化和“無處不在”,寬帶住宅接入和無線接入的日益普及和迅速發展,為未來更多的新型應用提供了廣闊的舞臺
- 在本章中,我們以一些經典的網絡應用為例來學習有關網絡應用的原理、協議和實現方面的知識
- 萬維網WWW
- 域名系統DNS
- 動態主機配置協議DHCP
- 電子郵件
- 文件傳送協議FTP
- P2P文件共享
- 多媒體網絡應用
6.2 客戶/服務器方式(C/S方式)和對等方式(P2P方式)
-
網絡應用程序運行在處于網絡邊緣的不同的端系統上,通過彼此間的通信來共同完成某項任務
-
開發一種新的網絡應用首先要考慮的問題就是網絡應用程序在各種端系統上的組織方式和它們之間的關系。目前流行的主要有以下兩種:
- 客戶/服務器(Client/Server,C/S)方式
- 對等(Peer-to-Peer,P2P)方式
-
客戶/服務器(Client/Server,C/S)方式
- 客戶和服務器是指通信中所涉及的兩個應用進程
- 客戶/服務器方式所描述的是進程之間服務和被服務的關系
- 客戶是服務請求方,服務器是服務提供方
- 服務器總是處于運行狀態,并等待客戶的服務請求。服務器具有固定端口號(例如HTTP服務器的默認端口號為80),而運行服務器的主機也具有固定的IP地址
-
C/S方式是因特網上傳統的、同時也是最成熟的方式,很多我們熟悉的網絡應用采用的都是C/S方式。包括萬維網WWW、電子郵件、文件傳輸FTP等
-
基于C/S方式的應用服務通常是服務集中型的,即應用服務集中在網絡中比客戶計算機少得多的服務器計算機上
- 由于一臺服務器計算機要為多個客戶機提供服務,在C/S應用中,常會出現服務器計算機跟不上眾多客戶機請求的情況
- 為此,在C/S應用中,常用計算機群集(或服務器場)構建一個強大的虛擬服務器
-
對等(Peer-to-Peer,P2P)方式
- 在P2P方式中,沒有固定的服務請求者和服務提供者,分布在網絡邊緣各端系統中的應用進程是對等的,被稱為對等方。對等方相互之間直接通信,每個對等方既是服務的請求者,又是服務的提供者
-
目前,在因特網上流行的P2P應用主要包括P2P文件共享、即時通信、P2P流媒體、分布式存儲等
-
基于P2P的應用是服務分散型的,因為服務不是集中在少數幾個服務器計算機中,而是分散在大量對等計算機中,這些計算機并不為服務提供商所有,而是為個人控制的桌面計算機和筆記本電腦,它們通常位于住宅、校園和辦公室中
-
P2P方式的最突出特性之一就是它的可擴展性。因為系統每增加一個對等方,不僅增加的是服務的請求者,同時也增加了服務的提供者,系統性能不會因規模的增大而降低
-
P2P方式具有成本上的優勢,因為它通常不需要龐大的服務器設施和服務器帶寬。為了降低成本,服務提供商對于將P2P方式用于應用的興趣越來越大
6.3 動態主機配置協議DHCP
-
動態主機配置協議DHCP(Dynamic Host Configuration Protocol)提供了一種機制,稱為即插即用連網。這種機制允許一臺計算機加入新網絡時可自動獲取IP地址等網絡配置信息而不用手工參與
-
DHCP主要使用以下報文來實現其功能:
- DHCP DISCOVER:DHCP發現報文
- DHCP OFFER:DHCP提供報文
- DHCP REQUEST:DHCP請求報文
- DHCP ACK:DHCP確認報文
- DHCP NACK:DHCP否認報文
- DHCP RELEASE:DHCP釋放報文
-
DHCP報文在運輸層使用UDP協議封裝
- DHCP客戶使用的UDP端口號為68
- DHCP服務器使用的UDP端口號為67
-
DHCP客戶在未獲取到IP地址時使用地址0.0.0.0
-
在每一個網絡上都設置一個DHCP服務器會使DHCP服務器的數量太多。因此現在是使每一個網絡至少有一個DHCP中繼代理(通常是一臺路由器),它配置了DHCP服務器的IP地址信息,作為各網絡中計算機與DHCP服務器的橋梁
-
DHCP的工作過程
- DHCP中繼代理
6.4 域名系統DNS(Domain Name System)
- 因特網采用層次樹狀結構的域名結構
- 域名的結構由若干個分量組成,各分量之間用“點”隔開,分別代表不同級別的域名
- 每一級的域名都由英文字母和數字組成,不超過63個字符,不區分大小寫字母
- 級別最低的域名寫在最左邊,而級別最高的頂級域名寫在最右邊
- 完整的域名不超過255個字符
- 域名系統既不規定一個域名需要包含多少個下級域名,也不規定每一級的域名代表什么意思
- 各級域名由其上一級的域名管理機構管理,而最高的頂級域名則由因特網名稱與數字地址分配機構ICANN進行管理
【舉例】湖南科技大學網絡信息中心的域名
- 頂級域名TLD(Top Level Domain)分為以下三類:
- 國家頂級域名nTLD:采用ISO3166的規定。如cn表示中國,us表示美國,uk表示英國、等等
- 通用頂級域名gTLD:最常見的通用頂級域名有七個,即:com(公司企業)、net(網絡服務機構)、org(非營利性組織)、int(國際組織)、edu(美國教育結構)、gov(美國政府部門)、mil(美國軍事部門)
- 反向域arpa:用于反向域名解析,即IP地址反向解析為域名
- 在國家頂級域名下注冊的二級域名均由該國家自行確定。例如,頂級域名為jp的日本,將其教育和企業機構的二級域名定為ac和co,而不用edu和com
- 我國則將二級域名劃分為以下兩類:
- 類別域名:共七個,ac(科研機構)、com(工、商、金融等企業)、edu(教育機構)、gov(政府部門)、net(提供網絡服務的機構)、mil(軍事機構)和org(非營利性組織)
- 行政區域名:共34個,適用于我國的各省、自治區、直轄市。例如:bj為北京市、sh為上海市、js為江蘇省,等等
【舉例】因特網的域名空間
懂不懂湖科大的含金量啊(后仰
這種按等級管理的命名方法便于維護名字的唯一性,并且也容易設計出一種高效的域名查詢機制。需要注意的是,域名只是個邏輯概念,并不代表計算機所在的物理地點
-
域名和IP地址的映射關系必須保存在域名服務器中,供所有其他應用查詢。顯然不能將所有信息都儲存在一臺域名服務器中。DNS使用分布在各地的域名服務器來實現域名到IP地址的轉換
-
域名服務器可以劃分為以下四種不同的類型:
- 根域名服務器
根域名服務器是最高層次的域名服務器。每個根域名服務器都知道所有的頂級域名服務器的域名及其IP地址。因特網上共有13個不同IP地址的根域名服務器。盡管我們將這13個根域名服務器中的每一個都視為單個的服務器,但“每臺服務器”實際上是由許多分布在世界各地的計算機構成的服務器群集。當本地域名服務器向根域名服務器發出查詢請求時,路由器就把查詢請求報文轉發到離這個DNS客戶最近的一個根域名服務器。這就加快了DNS的查詢過程,同時也更合理地利用了因特網的資源。根域名服務器通常并不直接對域名進行解析,而是返回該域名所屬頂級域名的頂級域名服務器的IP地址 - 頂級域名服務器
這些域名服務器負責管理在該頂級域名服務器注冊的所有二級域名。當收到DNS查詢請求時就給出相應的回答(可能是最后的結果,也可能是下一級權限域名服務器的IP地址) - 權限域名服務器
這些域名服務器負責管理某個區的域名。每一個主機的域名都必須在某個權限域名服務器處注冊登記。因此權限域名服務器知道其管轄的域名與IP地址的映射關系。另外,權限域名服務器還知道其下級域名服務器的地址 - 本地域名服務器
本地域名服務器不屬于上述的域名服務器的等級結構。當一個主機發出DNS請求報文時,這個報文就首先被送往該主機的本地域名服務器。本地域名服務器起著代理的作用,會將該報文轉發到上述的域名服務器的等級結構中。每一個因特網服務提供者ISP,一個大學,甚至一個大學里的學院,都可以擁有一個本地域名服務器,它有時也稱為默認域名服務器。本地域名服務器離用戶較近,一般不超過幾個路由器的距離,也有可能就在同一個局域網中。本地域名服務器的IP地址需要直接配置在需要域名解析的主機中
- 根域名服務器
-
域名解析的過程
-
遞歸查詢
-
迭代查詢
由于遞歸查詢對于被查詢的域名服務器負擔太大,通常采用以下模式:從請求主機到本地域名服務器的查詢是遞歸查詢,而其余的查詢是迭代查詢。
-
-
為了提高DNS的查詢效率,并減輕根域名服務器的負荷和減少因特網上的DNS查詢報文數量,在域名服務器中廣泛地使用了高速緩存。高速緩存用來存放最近查詢過的域名以及從何處獲得域名映射信息的記錄。
-
由于域名到IP地址的映射關系并不是永久不變,為保持高速緩存中的內容正確,域名服務器應為每項內容設置計時器并刪除超過合理時間的項(例如,每個項目只存放兩天)
-
不但在本地域名服務器中需要高速緩存,在用戶主機中也很需要。許多用戶主機在啟動時從本地域名服務器下載域名和IP地址的全部數據庫,維護存放自己最近使用的域名的高速緩存,并且只在從緩存中找不到域名時才向域名服務器查詢。同理,主機也需要保持高速緩存中內容的正確性
-
DNS報文使用運輸層的UDP協議進行封裝,運輸層端口號為53
6.5 文件傳送協議FTP
-
將某臺計算機中的文件通過網絡傳送到可能相距很遠的另一臺計算機中,是一項基本的網絡應用,即文件傳送
-
文件傳送協議FTP(File Transfer Protocol)是因特網上使用得最廣泛的文件傳送協議
- FTP提供交互式的訪問,允許客戶指明文件的類型與格式(如指明是否使用ASCII碼),并允許文件具有存取權限(如訪問文件的用戶必須經過授權,并輸入有效的口令)
- FTP屏蔽了各計算機系統的細節,因而適合于在異構網絡中任意計算機之間傳送文件
-
在因特網發展的早期階段,用FTP傳送文件約占整個因特網的通信量的三分之一,而由電子郵件和域名系統所產生的通信量還要小于FTP所產生的通信量。只是到了1995年,萬維網WWW的通信量才首次超過了FTP
-
FTP的基本工作模式
6.6 電子郵件
-
電子郵件(E-mail)是因特網上最早流行的一種應用,并且仍然是當今因特網上最重要、最實用的應用之一
-
傳統的電話通信屬于實時通信,存在以下兩個缺點:
- 電話通信的主叫和被叫雙方必須同時在場
- 一些不是十分緊迫的電話也常常不必要地打斷人們的工作或休息
-
而電子郵件與郵政系統的寄信相似
- 發件人將郵件發送到自己使用的郵件服務器
- 發件人的郵件服務器將收到的郵件按其目的地址轉發到收件人郵件服務器中的收件人郵箱
- 收件人在方便的時候訪問收件人郵件服務器中自己的郵箱,獲取收到的電子郵件
-
電子郵件使用方便、傳遞迅速而且費用低廉。它不僅可以傳送文字信息,而且還可附上聲音和圖像
-
由于電子郵件的廣泛使用,現在許多國家已經正式取消了電報業務。在我國,電信局的電報業務也因電子郵件的普及而瀕臨消失
-
電子郵件系統采用客戶/服務器方式
-
電子郵件系統的三個主要組成構件:用戶代理,郵件服務器,以及電子郵件所需的協議
- 用戶代理是用戶與電子郵件系統的接口,又稱為電子郵件客戶端軟件
- 郵件服務器是電子郵件系統的基礎設施。因特網上所有的ISP都有郵件服務器,其功能是發送和接收郵件,同時還要負責維護用戶的郵箱
- 協議包括郵件發送協議(例如SMTP)和郵件讀取協議(例如POP3,IMAP)
- 簡單郵件傳送協議SMTP(Simple Mail Transfer Protocol)的基本工作原理
- 電子郵件的信息格式并不是由SMTP定義的,而是在RFC 822中單獨定義的。這個RFC文檔已在2008年更新為RFC 5322。一個電子郵件有信封和內容兩部分。而內容又由首部和主體兩部分構成。
- SMTP協議只能傳送ASCII碼文本數據,不能傳送可執行文件或其他的二進制對象
- SMTP不能滿足傳送多媒體郵件(例如帶有圖片、音頻或視頻數據)的需要。并且許多其他非英語國家的文字(例如中文、俄文、甚至帶有重音符號的法文或德文)也無法用SMTP傳送
- 為解決SMTP傳送非ASCII碼文本的問題,提出了多用途因特網郵件擴展MIME(Multipurpose Internet Mail Extensions)
- 增加了5個新的郵件首部字段,這些字段提供了有關郵件主體的信息
- 定義了許多郵件內容的格式,對多媒體電子郵件的表示方法進行了標準化
- 定義了傳送編碼,可對任何內容格式進行轉換,而不會被郵件系統改變
- 實際上,MIME不僅僅用于SMTP,也用于后來的同樣面向ASCII字符的HTTP

-
常用的郵件讀取協議有以下兩個:
- 郵局協議POP(Post Office Protocol),POP3是其第三個版本,是因特網正式標準。
非常簡單、功能有限的郵件讀取協議。用戶只能以下載并刪除方式或下載并保留方式從郵件服務器下載郵件到用戶方計算機。不允許用戶在郵件服務器上管理自己的郵件。(例如創建文件夾,對郵件進行分類管理等) - 因特網郵件訪問協議IMAP(Internet Message Access Protocol),IMAP4是其第四個版本,目前還只是因特網建議標準。
功能比POP3強大的郵件讀取協議。用戶在自己的計算機上就可以操控郵件服務器中的郵箱,就像在本地操控一樣,因此IMAP是一個聯機協議 - POP3和IMAP4都采用基于TCP連接的客戶/服務器方式。POP3使用熟知端口110,IMAP4使用熟知端口143
- 郵局協議POP(Post Office Protocol),POP3是其第三個版本,是因特網正式標準。
-
基于萬維網的電子郵件
- 通過瀏覽器登錄(提供用戶名和口令)郵件服務器萬維網網站就可以撰寫、收發、閱讀和管理電子郵件。這種工作模式與IMAP很類似,不同的是用戶計算機無需安裝專門的用戶代理程序,只需要使用通用的萬維網瀏覽器
- 郵件服務器網站通常都提供非常強大和方便的郵件管理功能,用戶可以在郵件服務器網站上管理和處理自己的郵件,而不需要將郵件下載到本地進行管理
6.7 萬維網WWW
- 萬維網WWW(World Wide Web)并非某種特殊的計算機網絡。它是一個大規模的、聯機式的信息儲藏所,是運行在因特網上的一個分布式應用
- 萬維網利用網頁之間的超鏈接將不同網站的網頁鏈接成一張邏輯上的信息網
- 萬維網是歐洲粒子物理實驗室的Tim Berners-Lee最初于1989年3月提出的
-
1993年2月,第一個圖形界面的瀏覽器Mosaic
-
1995年著名的Netscape Navigator瀏覽器上市
-
目前比較流行的瀏覽器如下:
IE基本上快被淘汰了,取而代之的是微軟的edge瀏覽器
-
瀏覽器最重要的部分是渲染引擎,也就是瀏覽器內核。負責對網頁內容進行解析和顯示
- 不同的瀏覽器內核對網頁內容的解析也有不同,因此同一網頁在不同內核的瀏覽器里的顯示效果可能不同
- 網頁編寫者需要在不同內核的瀏覽器中測試網頁顯示效果
-
為了方便地訪問在世界范圍的文檔,萬維網使用統一資源定位符URL來指明因特網上任何種類“資源”的位置
-
URL的一般形式由以下四個部分組成:
-
萬維網的文檔
- 超文本標記語言HTML(HyperText Markup Language)
使用多種“標簽”來描述網頁的結構和內容 - 層疊樣式表CSS(Cascading Style Sheets)
從審美的角度來描述網頁的樣式 - JavaScript腳本語言(和Java沒有任何關系,
難蚌)
控制網頁的行為
- 超文本標記語言HTML(HyperText Markup Language)
-
超文本傳輸協議HTTP(HyperText Transfer Protocol)
HTTP定義了瀏覽器(即萬維網客戶進程)怎樣向萬維網服務器請求萬維網文檔,以及萬維網服務器怎樣把萬維網文檔傳送給瀏覽器
-
HTTP/1.0采用非持續連接方式。在該方式下,每次瀏覽器要請求一個文件都要與服務器建立TCP連接,當收到響應后就立即關閉連接
- 每請求一個文檔就要有兩倍的RTT的開銷。若一個網頁上有很多引用對象(例如圖片等),那么請求每一個對象都需要花費2RTT的時間
- 為了減小時延,瀏覽器通常會建立多個并行的TCP連接同時請求多個對象。但是,這會大量占用萬維網服務器的資源,特別是萬維網服務器往往要同時服務于大量客戶的請求,這會使其負擔很重
-
HTTP/1.1采用持續連接方式。在該方式下,萬維網服務器在發送響應后仍然保持這條連接,使同一個客戶(瀏覽器)和該服務器可以繼續在這條連接上傳送后續的HTTP請求報文和響應報文。這并不局限于傳送同一個頁面上引用的對象,而是只要這些文檔都在同一個服務器上就行。
- 為了進一步提高效率,HTTP/1.1的持續連接還可以使用流水線方式工作,即瀏覽器在收到HTTP的響應報文之前就能夠連續發送多個請求報文。這樣的一個接一個的請求報文到達服務器后,服務器就發回一個接一個的響應報文。這樣就節省了很多個RTT時間,使TCP連接中的空閑時間減少提高了下載文檔的效率
-
HTTP的報文格式
HTTP是面向文本的,其報文中的每一個字段都是一些ASCII碼串,并且每個字段的長度都是不確定的。
- 使用Cookie在服務器上記錄用戶信息
- 早期的萬維網應用非常簡單,僅僅是用戶查看存放在不同服務器上的各種靜態的文檔。因此HTTP被設計為一種無狀態的協議。這樣可以簡化服務器的設計
- 現在,用戶可以通過萬維網實現各種復雜的應用,如網上購物、電子商務等。這些應用往往需要萬維網服務器能夠識別用戶
- Cookie提供了一種機制使得萬維網服務器能夠“記住”用戶,而無需用戶主動提供用戶標識信息。也就是說,Cookie是一種對無狀態的HTTP進行狀態化的技術
- 萬維網緩存與代理服務器
- 在萬維網中還可以使用緩存機制以提高萬維網的效率
- 萬維網緩存又稱為Web緩存(Web Cache),可位于客戶機,也可位于中間系統上,位于中間系統上的Web緩存又稱為代理服務器(Proxy Server)
- Web緩存把最近的一些請求和響應暫存在本地磁盤中。當新請求到達時,若發現這個請求與暫時存放的請求相同,就返回暫存的響應,而不需要按URL的地址再次去因特網訪問該資源
完結撒花!
就像在本地操控一樣,因此IMAP是一個聯機協議
-
POP3和IMAP4都采用基于TCP連接的客戶/服務器方式。POP3使用熟知端口110,IMAP4使用熟知端口143
-
基于萬維網的電子郵件
- 通過瀏覽器登錄(提供用戶名和口令)郵件服務器萬維網網站就可以撰寫、收發、閱讀和管理電子郵件。這種工作模式與IMAP很類似,不同的是用戶計算機無需安裝專門的用戶代理程序,只需要使用通用的萬維網瀏覽器
- 郵件服務器網站通常都提供非常強大和方便的郵件管理功能,用戶可以在郵件服務器網站上管理和處理自己的郵件,而不需要將郵件下載到本地進行管理
[外鏈圖片轉存中…(img-HvZbecfO-1639975589147)]
6.7 萬維網WWW
- 萬維網WWW(World Wide Web)并非某種特殊的計算機網絡。它是一個大規模的、聯機式的信息儲藏所,是運行在因特網上的一個分布式應用
- 萬維網利用網頁之間的超鏈接將不同網站的網頁鏈接成一張邏輯上的信息網
- 萬維網是歐洲粒子物理實驗室的Tim Berners-Lee最初于1989年3月提出的
[外鏈圖片轉存中…(img-IsGAzJpC-1639975589147)]
-
1993年2月,第一個圖形界面的瀏覽器Mosaic
[外鏈圖片轉存中…(img-usDPcPO4-1639975589147)] -
1995年著名的Netscape Navigator瀏覽器上市
[外鏈圖片轉存中…(img-09Ikn61s-1639975589148)] -
目前比較流行的瀏覽器如下:
[外鏈圖片轉存中…(img-MHtTvigU-1639975589148)]IE基本上快被淘汰了,取而代之的是微軟的edge瀏覽器
-
瀏覽器最重要的部分是渲染引擎,也就是瀏覽器內核。負責對網頁內容進行解析和顯示
- 不同的瀏覽器內核對網頁內容的解析也有不同,因此同一網頁在不同內核的瀏覽器里的顯示效果可能不同
- 網頁編寫者需要在不同內核的瀏覽器中測試網頁顯示效果
-
為了方便地訪問在世界范圍的文檔,萬維網使用統一資源定位符URL來指明因特網上任何種類“資源”的位置
-
URL的一般形式由以下四個部分組成:
[外鏈圖片轉存中…(img-VakGeJxH-1639975589149)]
[外鏈圖片轉存中…(img-Rjep9CGY-1639975589149)]
[外鏈圖片轉存中…(img-K1je8MHA-1639975589150)] -
萬維網的文檔
- 超文本標記語言HTML(HyperText Markup Language)
使用多種“標簽”來描述網頁的結構和內容 - 層疊樣式表CSS(Cascading Style Sheets)
從審美的角度來描述網頁的樣式 - JavaScript腳本語言(和Java沒有任何關系,
難蚌)
控制網頁的行為
- 超文本標記語言HTML(HyperText Markup Language)
-
超文本傳輸協議HTTP(HyperText Transfer Protocol)
HTTP定義了瀏覽器(即萬維網客戶進程)怎樣向萬維網服務器請求萬維網文檔,以及萬維網服務器怎樣把萬維網文檔傳送給瀏覽器
[外鏈圖片轉存中…(img-Nyc75REm-1639975589150)]
-
HTTP/1.0采用非持續連接方式。在該方式下,每次瀏覽器要請求一個文件都要與服務器建立TCP連接,當收到響應后就立即關閉連接
[外鏈圖片轉存中…(img-uWHSqYaC-1639975589150)]
- 每請求一個文檔就要有兩倍的RTT的開銷。若一個網頁上有很多引用對象(例如圖片等),那么請求每一個對象都需要花費2RTT的時間
- 為了減小時延,瀏覽器通常會建立多個并行的TCP連接同時請求多個對象。但是,這會大量占用萬維網服務器的資源,特別是萬維網服務器往往要同時服務于大量客戶的請求,這會使其負擔很重
-
HTTP/1.1采用持續連接方式。在該方式下,萬維網服務器在發送響應后仍然保持這條連接,使同一個客戶(瀏覽器)和該服務器可以繼續在這條連接上傳送后續的HTTP請求報文和響應報文。這并不局限于傳送同一個頁面上引用的對象,而是只要這些文檔都在同一個服務器上就行。
- 為了進一步提高效率,HTTP/1.1的持續連接還可以使用流水線方式工作,即瀏覽器在收到HTTP的響應報文之前就能夠連續發送多個請求報文。這樣的一個接一個的請求報文到達服務器后,服務器就發回一個接一個的響應報文。這樣就節省了很多個RTT時間,使TCP連接中的空閑時間減少提高了下載文檔的效率
-
HTTP的報文格式
HTTP是面向文本的,其報文中的每一個字段都是一些ASCII碼串,并且每個字段的長度都是不確定的。
[外鏈圖片轉存中…(img-FIexWwaS-1639975589151)]
[外鏈圖片轉存中…(img-Nmm5jsrq-1639975589151)]
[外鏈圖片轉存中…(img-LFjeTEvu-1639975589151)]
- 使用Cookie在服務器上記錄用戶信息
- 早期的萬維網應用非常簡單,僅僅是用戶查看存放在不同服務器上的各種靜態的文檔。因此HTTP被設計為一種無狀態的協議。這樣可以簡化服務器的設計
- 現在,用戶可以通過萬維網實現各種復雜的應用,如網上購物、電子商務等。這些應用往往需要萬維網服務器能夠識別用戶
- Cookie提供了一種機制使得萬維網服務器能夠“記住”用戶,而無需用戶主動提供用戶標識信息。也就是說,Cookie是一種對無狀態的HTTP進行狀態化的技術
[外鏈圖片轉存中…(img-1flOtPZl-1639975589152)]
- 萬維網緩存與代理服務器
- 在萬維網中還可以使用緩存機制以提高萬維網的效率
- 萬維網緩存又稱為Web緩存(Web Cache),可位于客戶機,也可位于中間系統上,位于中間系統上的Web緩存又稱為代理服務器(Proxy Server)
- Web緩存把最近的一些請求和響應暫存在本地磁盤中。當新請求到達時,若發現這個請求與暫時存放的請求相同,就返回暫存的響應,而不需要按URL的地址再次去因特網訪問該資源
[外鏈圖片轉存中…(img-PXI7voQz-1639975589152)]
完結撒花!
最后感謝湖科大教書匠以及本教學視頻制作團隊