第四章 網路層
4.1 網路層概述
網路層的主要任務是 實作網路互連,進而 實作資料包在各網路在之間的傳輸,僅實作計算機網路體系結構中的物理層和資料鏈路層,是不能實作資料包在互聯網種各網路之間傳輸的,要實作該功能,就必須實作網路層,

這些異構型網路N1 ~ N7 如果只是需要各自內部通信,他們只要實作各自的物理層和資料鏈路層即可;但是如果要將這些異構型網路互連起來,形成一個更大的互聯網,就需要實作網路層設備路由器;有時為了簡單起見,可以不用畫出這些網路,圖中N1~N7,而將他們看做是一條鏈路即可
要實作網路層任務,需要解決一下主要問題:
-
網路層向運輸層提供怎樣的服務(“可靠傳輸”還是“不可靠傳輸”)
- 資料包在傳輸程序中,可能出現 誤碼,也有可能由于路由器繁忙而 被服務器丟棄,還有可能出現按序發送的資料包 不能按序到達接收方,對于 不可靠傳輸服務UDP,則對錯誤實施丟棄,若采用 可靠傳輸服務,則會對錯誤實行處理,實作正確接收接收方發送的資料,
-
網路層尋址問題
- TCP/IP協議網際層使用IP地址,N1網路的前三個數字是相同的,可以看作是它們所在網路的網路編號,而第四個數字不用,用于區分這兩個不同的路由器介面, N3網路的前2個數字是相同的,可以看作是它們所在網路的網路編號,而第3.4個數字不用,用于區分這兩個不同的路由器介面,

-
路由選擇問題

- 路由器收到資料后,是依據什么來決定將資料包從自己的哪個介面轉發出去?依據資料包的目的地址和路由器中的路由表

但在實際當中,路由器是怎樣知道這些路由記錄?
-
由用戶或網路管理員進行人工配置,這種方法只適用于規模較小且網路拓撲不改變的小型互聯網,
-
另一種是實作各種路由選擇協議,由路由器執行路由選擇協議中所規定的路由選擇演算法,而自動得出路由表中的路有記錄,這種方法更適合規模較大且網路拓撲經常改變的大型互聯網,
因特網是目前全世界用戶數量最多的互聯網,它 使用TCP/IP協議堆疊,由于TCP/IP協議堆疊的網路層使用國際協議IP,它是整個協議堆疊的核心協議,因此在TCP/IP協議堆疊中,網路層常稱為 網際層,
網路層(網際層)除了 IP協議外,還有之前介紹過的地址決議協議ARP,還有網際控制報文協議ICMP,網際組管理協議IGMP

本章主要通過學習TCP/IP協議堆疊的網際層來學習網路層的理論知識和實踐技術,
4.2 網路層提供的兩種服務
網路層提供的兩種服務,一種是面向連接的虛電路服務,另一種是無連接的資料報服務,
4.2.1 面向連接的虛電路服務
虛電路的核心思想是,可靠通信應由網路自身來保證,當兩臺計算機進行通信時,應當首先建立 網路層的連接- 虛電路VC(Virtual Circuit),以保證通信雙方需要的一切資源,通信雙方 沿著已建立的虛電路發送分組,目的主機的地址僅在連接建立階段使用,之后每個 分組的首部只需攜帶一條虛電路的編號,如果再使用可靠傳輸的網路協議,就可使所發送的分組無差錯按序到達終點,不丟失、不重復,通信結束后,需要釋放之前所建立的虛電路

*
虛電路表示這只是一條邏輯上的連接,分組都沿著這條邏輯連接按照存盤轉發方式傳送,而并不是真正建立了一條物理連接,電路交換的電話通信是先建立了一條真正的連接,分組交換的虛連接和電路交換的連接只是類似,但并不完全一樣
4.2.2 無連接的資料報服務
互聯網的先驅者提出了一種嶄新的網路設計思路;網路層向上只提供簡單靈活的、無連接的、盡最大努力交付的資料報服務;網路在發送分組時不需要先建立連接,每一個分組(即 IP 資料報)獨立發送,與其前后的分組無關(不進行編號);網路層不提供服務質量的承諾,即所傳送的分組可能出錯、丟失、重復和失序(不按序到達終點),當然也不保證分組傳送的時限,

發送方 發送給 接收方 的分組可能沿著不同路徑傳送:
盡最大努力交付
- 如果主機(即端系統)中的行程之間的通信需要是可靠的,那么就由網路的主機中的運輸層負責可靠交付(包括差錯處理、流量控制等) ,
- 采用這種設計思路的好處是:網路的造價大大降低,運行方式靈活,能夠適應多種應用,
- 互連網能夠發展到今日的規模,充分證明了當初采用這種設計思路的正確性,
4.3 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,
lPv4地址的編址方法經歷了如下三個歷史階段:

4.3.1 IPv4地址的表示方法
32位元的IPv4地址不方便閱讀、記錄以及輸入等,因此IPv4地址采用點分十進制表示方法以方便用戶使用.

4.3.2 分類編制的IPv4地址

4.3.2.1 A類地址

4.3.2.2 B類地址

4.3.2.3 C類地址

4.3.2.4 總結
- 網路號指派范圍
| 網路類別 | 最大可指派的網路數 | 第一個可指派的網路號 | 最后一個可指派的網路號 | 每個網路中最大主機數 | 備注 |
|---|---|---|---|---|---|
| A | 126 ( 2 7 ? 2 ) 126 (2^7-2 ) 126(27?2) | 1 | 126 | 16777214 ( 2 24 ? 2 ) 16777214(2^{24}-2) 16777214(224?2) | 最小網路號0,保留不指派;最大網路號127,作為本地環回地址,不指派, |
| B | 16384 ( 2 14 ) 16384(2^{14}) 16384(214) | 128.0 | 191.255 | 65534 ( 2 16 ? 2 ) 65534(2^{16}-2) 65534(216?2) | 所有網路號均可指派 |
| C | 2097152 ( 2 21 ? 1 ) 2097152(2^{21}-1) 2097152(221?1) | 192.0.0 | 223.255.255 | 246 ( 2 8 ? 2 ) 246(2^8-2) 246(28?2) | 所有網路號均可指派 |
-
特殊的IP地址
- 主機號為“全0”,這是網路地址
- 主機號為“全1”,這是廣播地址
-
一般不使用的特殊的IP地址

4.3.3 劃分子網的IPv4地址
在 ARPANET 的早期,IP 地址的設計確實不夠合理:
- IP 地址空間的利用率有時很低,
- 給每一個物理網路分配一個網路號會使路由表變得太大因而使網路性能變壞,
- 兩級的 IP 地址不夠靈活,

當有新的主機添加進來的時候,就需要重新申請一個網路號,這是不必要的,


所以就有了劃分子網的工具:子網掩碼
- 從 1985 年起在 IP 地址中又增加了一個“子網號欄位”,使兩級的 IP 地址變成為三級的 IP 地址,
- 這種做法叫做劃分子網 (subnetting) ,
- 劃分子網已成為互聯網的正式標準協議,

劃分為子網路后,資料的傳送流程:
-
凡是從其他網路發送給本單位某個主機的 IP 資料報,仍然是根據 IP 資料報的目的網路號 net-id,先找到連接在本單位網路上的路由器,
-
然后此路由器在收到 IP 資料報后,再按目的網路號 net-id 和子網號 subnet-id 找到目的子網,
-
最后就將 IP 資料報直接交付目的主機,
4.3.3.1 子網掩碼
32位元的子網掩碼可以表明分類IP地址的主機號部分被借用了幾個位元作為子網號
-
子網掩碼使用連續的位元1來對應網路號和子網號
-
子網掩碼使用連續的位元0來對應主機號
-
將劃分子網的IPv4地址與其相應的子網掩碼進行邏輯與運算就可得到IPv4地址所在子網的網路地址

舉例說明
1.
已
知
某
個
網
絡
的
地
址
為
1. 已知某個網路的地址為
1.已知某個網絡的地址為218.75.230.0,
使
用
子
網
掩
碼
使用子網掩碼
使用子網掩碼255.255.255.128
對
其
進
行
子
網
劃
分
,
請
給
出
劃
分
細
節
對其進行子網劃分,請給出劃分細節
對其進行子網劃分,請給出劃分細節
解 析 決議 解析
C
類
網
絡
地
址
C類網路地址
C類網絡地址
主
機
號
為
主機號為
主機號為.0,
網
絡
號
為
網路號為
網絡號為218.75.230
子
網
掩
碼
:
子網掩碼:
子網掩碼: 255.255.255.10000000
故 劃 分 出 的 子 網 數 量 : 2 1 = 2 故劃分出的子網數量:2^1=2 故劃分出的子網數量:21=2
子 網 絡 可 分 配 的 網 絡 地 址 : 2 7 ? 2 = 126 子網路可分配的網路地址:2^7-2=126 子網絡可分配的網絡地址:27?2=126

例2.

默認子網掩碼

總結

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地址后面加上斜線“/”,在斜線后面寫上網路前綴所占的位元數量, 如 128.14.35.7/20表示網路前綴占用的位元數量為20,主機編號占用的位元數量為:
30
?
20
=
12
30-20=12
30?20=12
CIDR實際上是將網路前綴都相同的連續的IP地址組成一個“CIDR地址塊”,
我們只要知道CIDR地址塊中的任何一個地址,就可以知道該地址塊的全部細節:
- 地址塊的最小地址
- 地址塊的最大地址
- 地址塊中的地址數量
- 地址塊聚合某類網路(A類、B類或C類)的數量
- 地址掩碼(也可繼續稱為子網掩碼)
舉例

練習
206.0.64.8/18 → \to → 206.0.0100 0000.0000 1000
最小地址:206.0.0100 0000.0000 0000即206.0.64.0
最大地址:206.0.0111 1111.1111 1111即206.0.127.255
子網掩碼:255.255.192.0
地址數量: 2 14 2^{14} 214
聚合C類網的數量: 2 14 ÷ 2 8 2^{14}\div 2^8 214÷28
4.3.4.1 路由聚合(構造超網)
路由器R1與五個網路以及路由器R2直接相連,路由器R1和R2互為相鄰路由器,它們周期性地同通告給對方自己所知道的路由資訊,若R1將直連的五個網路通告給R2,則R2的路由表會增加五條路由記錄,可以找“共同前綴”,共22個位元,記為/22,將共同前綴保持不變,剩余10個位元全部取0,然后寫成點分十進制形式,放在/22前面,這就是聚合后的地址塊(超網),將五條路由記錄聚合成一條,

練習:子網192.168.4.0/30中,能接收到目的地址為192.168.4.3的IP分組的最大主機數是?
決議:
192.168.4.0000 0000;
最小地址:192.168.4.0
最大地址:192.168.4.3
可分配的最小地址:192.168.4.1
可分配的最大地址:192.168.4.2
故為2.
小結

4.3.5 IPv4地址的應用規劃
給定一個IPv4地址快,如何將其劃分成幾個更小的地址塊,并將這些地址塊分配給互聯網中不同網路,進而可以給各網路中的主機和路由器介面分配IPv4地址,一般有兩種方法:定長的子網掩碼FLSM,另一種是變長的子網掩碼VLSM,
4.3.5.1 定長的子網掩碼FLSM(Fixed Length Subnet Mask)
使用同一個子網掩碼來劃分子網,每個子網所分配的IP地址數量相同,造成IP地址的浪費
舉例 1
C
類
網
絡
地
址
:
C類網路地址:
C類網絡地址: 網路號218.75.230主機號.0
從 主 機 號 中 借 用 三 個 比 特 位 作 為 子 網 絡 號 , 子 網 絡 的 數 量 : 從主機號中借用三個位元位作為子網路號,子網路的數量: 從主機號中借用三個比特位作為子網絡號,子網絡的數量: 2 3 = 8 2^3=8 23=8
子
網
掩
碼
:
子網掩碼:
子網掩碼: 255.255.255.1110 0000 即255.255.255.224


通過上面步驟分析,就可以從子網1~ 8中任選5個子網,分配給左圖中的N1~N5網路
采用定長的子網掩碼劃分,只能劃分出 2 n 2^{n} 2n個子網,其中n是從主機號部分借用的用來作為子網號的位元數量,每個子網所分配的IP地址數量相同
但是也因為每個子網所分配的IP地址數量相同,不夠靈活,容易造成IP地址的浪費
4.3.5.2 變長的子網掩碼VLSM(Variable Length Subnet Mask)
使用不同的子網掩碼來劃分子網,每個子網所分配的IP地址數量可以不同,盡可能減少對IP地址的浪費
無分類編址的IPv4就是變長的子網掩碼

應用需求:從地址塊218.75.230.0/24中取出5個地址塊(一個“/27”,3個“/28”,1個“/30”),按需分配給下圖的5個網路.

在該地址塊中給左圖所示的網路N1~N5分配子塊,分配原則是“每個子塊的起點位置不能隨意選取,只能選取塊大小整數倍的地址作為起點”,建議先給大的子塊分配,

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/356079.html
標籤:其他
上一篇:AzureDevOpsAndroidSigning任務不簽署APK
下一篇:Cache實作HTTP服務
