B站湖科大《計算機網路》超詳細重點筆記

loopyhz發表於2024-08-27
計算機網路筆記

湖科大 《計算機網路》 超詳細重點筆記 適合沒時間看課想快速掌握知識點 或者 課後梳理複習

基礎概念

路由器

是實現分組交換的關鍵構建 是最重要的分組交換機
任務是將網路互聯起來，並對接收到的分組進行轉發
不稱其為主機

報文

表示一條訊息的整個01串

三種交換方式

電路交換
報文交換

分組交換(分組的長度固定 ----->>> 緩衝區的大小便於控制)
image-20240823074335643

過程

先把報文分成小的資料段 在每一個資料段前面 加上一些由必要的控制資訊組成的首部以後 就構成了一個分組 簡稱為包 首部稱為 包頭

分組交換機收到這個包以後 先暫時儲存下來 再檢查首部 根據首部中的目的地址進行查錶轉發 找到合適的轉發介面 透過這個介面將分組轉發給下一個分組交換機。。。。。一次次轉發就到了目的主機 再去掉首部 將各資料段連線還原

衡量網路效能的一些指標

先記一下資料量的單位
image-20240823075959515

再記一下速率的單位

image-20240823090351999

這兩者直接有一一對應的約等於關係
比如: 2^10 = 10^3 2^20 = 10^6 2^30 = 10^9

標250GB實際是多少呢？

image-20240823090108457

廠家給的GB是10^9 bit 但是作業系統中的是 2^30 bit
所以image-20240823090214254

速率的計算

image-20240823090722417

頻寬

單位時間內能傳輸的資料量

image-20240823090813536

吞吐量

image-20240823090924871

時延

處理時延 知道有就行了

傳送時延
計算公式: 分組長度 / 傳送速率
image-20240823091601359
傳送速率由上面的部分共同決定

計算

image-20240823092258492

傳播時延

image-20240823091931916

時延頻寬積

image-20240823094826304

往返時間 RTT

網路利用率

image-20240823095346427

丟包率

OSI體系結構

image-20240823095904806

TCP/IP體系結構

image-20240823100004714

image-20240823100853325

五層體系結構

重新把網路介面層劃分為物理層和資料鏈路層

image-20240823100922034

每層解決的問題

image-20240823101026799

image-20240823101154539

如果在多個網路中 該如何標識各個網路和各個網路的主機呢 這就引入了網路層

image-20240823101306328

​ 當主機收到了來自伺服器的分組 那麼這些分組應該交給主機中的哪個程序來處理呢？ 運輸出現錯誤該怎麼解決呢？
image-20240823101413919

在此基礎上 制定相應的協議 並且按照協議編寫相應的應用程式 透過應用程序間的互動來完成相應的網路應用 這些就是應用層來解決的問題
image-20240823101450067

基於網路的程序間通訊的具體流程描述

​ 應用層按照http協議， 構建一個http請求報文， 把它交給運輸層處理， 運輸層給http報文新增一個tcp首部，讓他成為一個tcp報文段， 之後交給網路層， 網路層給它新增一個ip首部， 讓他成為一個ip資料包， 之後交給資料鏈路層處理， 資料鏈路層給他新增一個首部和尾部， 讓他成為幀， 之後交給物理層， 物理層把幀看成bit流， 如果是乙太網， 物理層就還會給位元流前面新增前導碼， 為了讓目的主機做好接收幀的準備， 之後物理層把這個位元流變換成相應的訊號傳送到傳輸媒體。

​ 訊號透過傳輸媒體到達路由器， 路由器的物理層將訊號再變回位元流， 去掉前導碼後交給資料鏈路層， 去掉幀的首部和尾部， 交給網路層， 是IP資料包， 網路層解析首部， 從中提取出目的網路的地址， 查詢自身的路由表， 確定轉發的埠再一步步重新給到自己的物理層傳送出去。

。。。。。。。 之後就是後半部分一樣的處理了

image-20240823102019547

實體

image-20240823102310550

協議

image-20240823102548615

注意:
邏輯通訊並不存在
是為了讓我們在研究某一層的時候不用考慮其它層 方便研究的一種手段

協議的三要素

image-20240823103019932

每層之間協議的關係

image-20240823103351181

image-20240823105011754

資料鏈路層

是什麼
image-20240823105907378

封裝成幀

把上層交付的協議資料單元封裝成幀
image-20240823111416865

image-20240823112226439

image-20240823111427446

  • 幀頭和幀尾中包含有重要的控制資訊
  • 幀頭和幀尾的作用之一就是幀定界 (比如ppp幀前後的那一個位元組) 方便接收方的資料鏈路層從物理層的Bit流中把一個個的幀提取出來(mac幀是物理層新增了前導碼,所以沒有幀定界標識)

**透明傳輸: **
image-20240823113831612

會產生的問題:
幀定界標誌是一個特殊的字元,如果在上層交付的協議資料單元中,恰好也包含了這個字元,就會出現問題。影響接收方的接收，這種情況下,資料鏈路層就會採取一些措施,保證接收方能正常接收。

問題的解決：
image-20240823114032942

位元組填充就是傳送之前先掃描一遍,遇到了幀定界符,就在前面加一個跳脫字元,和真正的幀定界符進行去區分

位元填充法就是傳送之前掃描一遍,遇到了和幀定界的這個位元組的位元完全一樣的,就在這個位元組裡面某個固定的位置填充上0

image-20240823114446187

差錯檢測

是什麼:image-20240823134142067

傳送方將檢錯碼封裝在幀尾， 接收方主機收到幀後， 透過檢錯碼和檢錯演算法， 判斷幀在傳輸過程中是否出現了誤碼 這就是差錯檢測

上面圖中幀尾那四個位元組的 FCS就是檢錯碼

奇偶校驗(很容易出錯)image-20240823140651260

迴圈冗餘校驗CRC
image-20240823140918039

具體計算:
image-20240823141030132
image-20240823141233679
image-20240823141301299

image-20240823142103747

注意 : 進行的是異或運算

image-20240823142412320

總結：

image-20240823142516609

可靠傳輸

概念: 誤碼是不能避免的,但是 只要能實現傳送方傳送什麼，接收方就接收到什麼,就稱為可靠傳輸
image-20240823142632070

提供的兩種型別：
image-20240823142655943

image-20240823142757840
另外 : 每一層都可以選擇實現可靠傳輸

舉例一些協議 的要求(要求可靠還是不可靠)
image-20240823142920744

實現可靠傳輸的具體協議(協議是資料鏈路層的協議，但是這三種協議的基本原理並不侷限於資料鏈路層,可以用到計算機網路體系的各層協議)

停止等待協議SW
image-20240823145006207但是如果接收方傳送的確認分組也丟失了怎麼辦呢？？？
那麼傳送方就會超時重傳一個重複的分組， 這個時候接收方就得判斷這是不是一個重複的分組
image-20240823145237847帶個序號就可以了
如果接收方發現重複了
就丟棄掉
再給傳送方傳送一個確認分組

既然資料分組需要編號

那麼確認分組也需要編號 這樣就可以解決重複確認的問題(資料鏈路層一般不會出現丟失的問題,所以一般不用編號)

image-20240823145353951

通道利用率
image-20240823145835388

具體計算
image-20240823150051152

回退N幀協議GBN

image-20240824081553010

好處: 採用累計確認的方法 即使確認分組丟失 也有可能是不必重傳的 比如一開始的ack1丟失了 但是ack4傳過去了， 這就說明前五個分組都是正確接收的 所以ack1也就沒必要重傳了

有差錯時: 比如傳送視窗這次傳送來的是56701 但是5就丟失了,那麼後續就會依次丟棄6701,每丟棄一個,就傳送一個ack4的確認資訊給傳送方(上一次接收到的資訊 因為上一次傳送過來的是01234 所以最後一個接收到的是4) 傳送方接收到重複的確認,就知道之前傳送的資料分組出現了差錯,不用等到超時計時器超時就立刻重傳 (這也就是回退N幀)

為什麼傳送視窗的尺寸不能超過上線？
在上面圖中的例子中,假設傳送視窗是8，正好超過上限，第一次傳送八個分組，接收方正確接收了，傳送ACK7給傳送方，但是這個確認分組丟失了，傳送分組再重發前八個分組，因為序號還是0 ~ 7 ， 所以沒有辦法分辨是新的分組還是舊的分組。

總結:

image-20240824095638581

image-20240824100001841

image-20240824100137660

當通訊線路質量不好的時候，他的通道利用率不比停等協議高

選擇重傳協議

image-20240824101852599必須對每個收到的分組逐一確認 不能再多個分組才確認一次
遇到序號不匹配的， 接收方的滑動視窗就不能向前滑動

舉個例子:
image-20240824102003354

​ 比如這個例子 2是錯誤的，所以2被丟棄了， 3進來，但是序號不匹配了，視窗就只會移動兩個位置，並且傳送兩個確認訊號，傳送方收到01兩個確認分組後，向前移動兩個位置 傳送45。傳送方沒收到2號確認分組 直接收到了3號確認分組 2號超時重傳 接收方的滑動視窗收到這個2號以後 才會繼續向前滑動

image-20240824102742175

image-20240824103117246

點對點ppp協議

image-20240824103703432

​ image-20240824103846536

幀格式
image-20240824103950691

如何解決透明傳輸問題？

image-20240824143213645

方法一: 位元組填充法
image-20240824143957132
方法二: 位元填充法
image-20240824144350340

差錯檢測

計算範圍如下
image-20240824144455563

迴圈冗餘校驗CRC
image-20240824144536807

工作狀態

ppp鏈路的開始和結束都是靜止狀態 不存在物理層連線
當檢測到調變解調器的載波訊號 並建立物理層連線之後 ppp進入鏈路的建立狀態
現在鏈路控制協議LCP 開始協商一些配置選項
協商成功 則進入鑑別狀態
協商失敗 則退回到靜止狀態
若無需鑑別 或 鑑別成功 則進入網路狀態
若鑑別失敗 則 進入終止狀態
NCP配置後 進入開啟狀態

image-20240824145608686

MAC地址 IP地址 ARP協議

image-20240824152725978

但是因為三者關係緊密 所以放在一起了

image-20240824152805024

MAC地址

使用點對點通道的資料鏈路層不需要使用地址 因為整條線路上就他們兩個
使用廣播通道的資料鏈路層必須使用地址來區分各主機

image-20240824161801522
image-20240824161816704
image-20240824161904442
image-20240824161955988

MAC地址格式
image-20240824163916536

第一位元組的b0位取0 代表是單播地址 取1代表是多播地址
第一位元組的b1位取0 代表全球管理 取1代表本地管理
image-20240824164726902

MAC地址的傳送順序
image-20240824165114340

單播MAC地址作用 ： 傳送的主機在源地址填上自己的mac地址,在目的地址填上要傳送給的那個主機的mac地址 再加上幀首部的其它欄位 資料載荷以及 幀尾部等 構成了單播幀 。 之後傳送出去，收到這個幀的主機,去目的地址檢查一下，和自己的地址是不是匹配，不匹配就直接丟棄

廣播mac地址作用 ： 目的地址欄位直接寫廣播地址就行了FF-FF-FF-FF-FF-FF 其它不變 所有主機都會接收並處理

多播mac地址作用 :
image-20240824165727280
先判斷一下這個地址是不是多播地址 直接換成二級制 完後看看最後一位是0還是1

image-20240824165838794

發現有兩個主機都包含了這個多播地址

傳送的時候在目的地址的位置填上這個多播地址 這兩臺主機就都能收到這個多播幀了

IP地址 (屬於網路層) 在這裡只介紹ip地址的作用 詳細的還是在網路層

image-20240824171145525
image-20240824171151942

從網路體系結構看ip地址和mac地址
image-20240824171311943

資料包轉發過程中IP地址和MAC地址的變化情況 本例只關注網路層和資料鏈路層
(路由器的最高層為網路層 沒有運輸層和應用層)

H1想傳送資料給H2
image-20240824172855950

image-20240824172916765

這種轉發需要透過IP地址找到MAC地址

由此引出了ARP協議

地址解析協議ARP

每臺主機都會有一個ARP快取記憶體表
image-20240824174531701

image-20240824173705427
本圖中 他之前獲取到的A的IP和MAC的關係就被存在了快取記憶體表裡面

當主機B要給主機C傳送資料包的時候
先在快取表中查詢有沒有主機C的IP MAC(他只知道C的IP 並不知道MAC 所以需要知道MAC才能傳送)
這個時候主機B傳送一個ARP請求報文 獲得主機C的MAC地址
image-20240824174116774
其它主機接收到後 將幀交付上層處理 上層的ARP程序解析ARP請求報文
如果發現詢問的IP地址不是自己的IP 就不予理會
如果發現是自己的IP地址 就進行響應

響應步驟如下
image-20240824174342366
image-20240824174358463
image-20240824174420984
image-20240824174427735

之後B就可以正常給C傳送資料包了
結束

注意:

image-20240824174552683

ARP只能逐段鏈路使用
不能跨好幾個鏈路使用

集線器與交換機的區別

集線器
image-20240825094816913

使用集線器HUB在物理層擴充套件乙太網

下面是三個使用集線器連線的相互獨立的乙太網 一二三系 ，是三個獨立的碰撞域， 也就是說 如果一系中的某臺主機傳送了資料幀，訊號會傳給一系中的全部主機。
為了使各系的乙太網能相互通訊，可以再使用一個集線器把他們互聯起來，這樣三個乙太網就互聯成了一個更大的乙太網，三個碰撞域就合併成了一個更大的碰撞域， 形成了一個更大的匯流排型乙太網，
image-20240825100722610

乙太網交換機

image-20240825100817311

假如都傳送了一個單播幀，集線器會發給匯流排上的全部主機，但是交換機會根據自身的幀交換表直接轉發給目的主機

假設都傳送了一個廣播幀 沒啥區別

假設都同時給一個主機傳送單播幀 集線器會碰撞 交換機會先快取起來再逐個發給這個主機 不會產生碰撞

詳細對比如下

image-20240825102532450
image-20240825102626771

交換機

全雙工： 傳送幀和接收幀可以同時進行

概念

image-20240825101234418

直通交換是 不必把整個幀先快取再進行處理 在接收幀的同時，就立即按照幀的目的MAC地址 決定該幀的轉發介面 但是他不檢查幀是否有差錯就直接轉發

乙太網交換機自學習和轉發幀的流程

image-20240825102906289

詳細流程(假設各主機知道網路中其它各主機的MAC地址 也就是無需進行ARP):

image-20240825105731471
假設主機A給主機B傳送幀 ， 從交換機1的介面1進入交換機1，交換機1首先進行登記工作，將MAC地址A記錄到自己的幀交換表中，將進入的介面1這個介面號也相應的記錄到自己的幀交換表中，這個登記工作就是交換機的自學習。之後進行轉發，在幀交換表中查詢B，發現找不到，於是對該幀進行盲目轉發，也稱為泛洪，也就是向除了這個介面外的所有介面轉發該幀，主機B的網路卡收到這個幀後，根據幀的目的MAC地址知道這個是傳送給自己的幀，接收。該幀從交換機2的介面2進入交換機2，交換機2也進行自學習，進行相同步驟的轉發。。。
之後主機B給主機A傳送上述幀，先自學習B，之後查詢A，發現能找到，直接轉發到介面1.

大致意思就是這樣，剩下的看下面的圖片就行了
image-20240825110553367

另外還有丟棄的情況，就是多加了一個G的這種，不會轉發到進入的介面，所以就丟棄該幀了
image-20240825110737080

image-20240825110758649

image-20240825111024355

乙太網交換機的生成樹協議STP

廣播風暴: 廣播幀會在這個環路中不停的迴圈轉發。。

現在的乙太網的問題，如果某條線路斷了，如果某個交換機只依賴這一條線路，就會直接在乙太網中斷聯了，安全性很低
image-20240825114221687

解決辦法：

image-20240825114334025

雖然有環路，但是會根據STP來阻塞自己的一些介面，避免出現網路環路
image-20240825114511082

虛擬區域網VLAN

先說路由器
路由器工作在網路層
路由器預設情況下不對廣播資料包進行轉發
所以它可以隔離廣播域

image-20240825115557044

但是成本高
所以就需要VLAN了

概念
image-20240825115705454
原本三個網段中的所有主機屬於一個廣播域，但是分割成VLAN1和VLAN2後，廣播將只在內部進行，也就是VLAN1中某主機傳送的廣播，VLAN2中的主機不會收到

實現機制
是在交換機上實現的。交換機需要有兩個功能 ， 一個是能處理帶有VLAN標記的幀，一個是交換機的各埠可以支援不同的埠型別（不同型別的埠對幀的處理方式有所不同）
image-20240825120034187

特殊幀

image-20240825121106351

交換機的埠型別

交換機的預設VLAN ID（PVID）是交換機埠在沒有特定配置時的預設VLAN標識
例如，當一個資料幀進入交換機埠時，如果該埠配置了特定的PVID，且資料幀的VLAN資訊與埠的PVID匹配，那麼該資料幀將不帶VLAN標籤直接傳送出去；如果不匹配，則資料幀將被打上埠的PVID標籤後傳送。這種機制確保了資料幀在交換機內部的正確路由和傳輸‌

image-20240825122120283
交換機的每個埠有且只有一個PVID
思科交換機在未配置VLAN時，所有埠都預設屬於VLAN1
華為交換機上稱為PVID
下面都採用PVID來描述

型別

image-20240825122320856

Access埠

下圖中的交換機初始化時，各介面預設PVID=1，埠型別預設是A，也就是Access介面
一般用於連線使用者交換機

image-20240825122551213
一個廣播幀從埠1進來，因為PVID = 1,所以給他打標籤,VID = 1，之後去檢查其它埠的PVID，一樣就去標籤轉發

下面，我們想讓主機AB劃分為VLAN2 CD劃分為VLAN3 可以如圖所示進行改變
image-20240825122841195

假如一個廣播幀從埠1進入交換機，VID=2，就只會轉發給埠2了，也就實現了VLAN的劃分

Trunk埠

一般用於交換機之間 或者 交換機與路由器之間互聯

image-20240825123342597
image-20240825123353492

想如圖把兩個交換機互聯的網路劃分為VLAN1和VLAN2
可以如圖配置
記得把交換埠 也就是埠5的埠型別改為T

轉發流程:
image-20240825123617729
從埠1進來的廣播幀，因為VID=1,和埠5的PVID相等 所以可以轉發到交換機2
image-20240825123704210

image-20240825124038178
如果VID != PVID那麼就會直接轉發 不會進行去標籤
接收的時候也是直接接收

image-20240825124318325

網路層

概述
各個網路之間由路由器互聯
image-20240825132313150

路由選擇: 路由器收到資料包後怎麼知道應該轉發到哪個路由器呢？

image-20240825132909441

所以這邊介紹的是網際層

兩種服務

面向連線的虛電路服務

是邏輯連線 並不是真的有一條線路
image-20240825145738009

無連線的資料包服務(因特網)

image-20240825145939371

image-20240825150022433

IPV4地址

概述

image-20240825151928066

表示方法

image-20240825152036852

計算方法

image-20240825152210152

到商0的時候結束,將從下到上組合位元串就行了

但是一般就是背住了湊就行了
image-20240825152639811

分類編址的IPV4地址

一共有五類 紅色數字是最高位固定的數字
image-20240825152914312

注意事項
image-20240825153703589

image-20240825161754623

image-20240825161829310

A類地址(最高位固定為0)

image-20240825155921552

B類地址(最高位固定為10)
image-20240825161020327

C類地址(最高位固定為110)
image-20240825161240104

分配網路號

image-20240825162020765

劃分子網的IPV4地址

image-20240825164502636

現在想把一個網路劃分為幾個子網 借用原來網路的主機號的一些位，來充當網路號，用來標識不同的子網

由此就有了下面的問題

image-20240825164637259

所以就引出了一個劃分子網的工具 ------>>>>> 子網掩碼
image-20240825165528727

看完例子再回去看上圖就明白了

image-20240825170250636

子網掩碼中的255.255.255 對應網路號部分
128對應的是有多少位被借用

image-20240825170348177

將128轉化為二進位制,發現只有一個1，所以只有1位是從主機號部分借用來充當子網號

image-20240825170454178

現在的主機號還剩七位 也就是隻有七位來標識主機了 所以可分配的地址數量是2^7,但是還要去掉主機號為全0的網路地址和全1的廣播地址

分析一下

這是沒有劃分子網時候 該網路地址的細節
image-20240825170841843

劃分子網後就是下面這樣了

image-20240825171025939

可以再看個例題
image-20240825171232515

預設子網掩碼
image-20240825171328915

無分類編址的IPV4地址

概念image-20240825171852211

就是採用了全新的一套 不用ABC分類了 也沒子網的概念了

image-20240825172105082

看一下例子:
image-20240825190811751

地址掩碼是 255.255.240.0

路由聚合(構造超網)
一個路由器想把自己的路由資訊告訴另一個路由器時，可以採用這種方式將很多條記錄合併為一條，以此來節約空間。
找到共同字首 下面例子中，他們的前兩個位元組都一樣，從第三個位元組開始不一樣，所以把第三個位元組轉化為二進位制形式，其它的不變。這樣就可以找到共同字首。
聚合地址塊格式為 共同字首(保持不變) + 剩下的bit全部取0 / 共同字首的長度

image-20240825192104947

看個例題:
image-20240825192348856
目的地址是4.3 也就是是一個廣播地址，所有主機都能收到 一共就兩個可以分配的IP 也就是隻有兩個主機

IPV4地址的應用規劃

給定一個IPV4的地址塊，如何將其劃分為幾個更小的地址塊，並將這些地址塊分配給網際網路中的不同網路，進而可以給各網路中的主機和路由器介面分配IPV4地址。 一般有下面的兩種方法

image-20240825194116330

定長子網掩碼劃分舉例:
先分析每個網路的IP地址需求
image-20240825194759196

由此，需要劃分為五個子網 ， 每個子網可分配的IP都不能少於自身的需求

image-20240825195334907
分析一下，借用三個位元正好可以滿足要求。在子網掩碼中，所有對應網路號的都是1，對應主機號的都是0

把後面的八個位元改寫成10進位制
image-20240825195616959

具體劃分情況如下圖
image-20240825195742298

最後隨便選五個子網分給N1到N5就可以了

總結 ： 採用定長的子網劃分 只能劃分出2^n個子網 n 是借用的用來作為子網號的位元數量

採用變長的子網掩碼劃分
和上面的劃分需求相同

可以每個子網單獨分析需要的網路字首和標識的主機的位數
image-20240825200718310

總結一下需求:
image-20240825200840164

現在就要給這5個子網來分配子塊
image-20240825201026541
image-20240825201328682

IP資料包的傳送和轉發過程

注意
image-20240826064255145

包括下面兩個部分
image-20240826064322798

直接交付和間接交付
image-20240826064433030

那麼源主機如何知道自己和目的主機是否在同一個網路中？
image-20240826064617397

假設主機C要給主機F傳送IP資料包
C先用自己的IP和自己的子網掩碼相與 得到自己的網路地址
再用F的IP地址和自己的子網掩碼相與 得到目的主機的網路地址
發現不一樣 --->>> 不在同一網路中
通訊屬於間接交付

那麼主機C如何知道應該把資料交給哪個路由器來轉發呢？

使用者指定一個預設的路由器 也就是預設閘道器

image-20240826064924022

路由器如何轉發？
image-20240826065015136

image-20240826065413029

將目的地址和地址掩碼相與 如果發現和目的網路不匹配 這條就不滿足

廣播
image-20240826065558380

如果傳送的地址是本網路中的廣播地址 就只能在本網路中傳播 路由器不會轉發

image-20240826065701465

如果傳送地址是對面的廣播地址 也不會轉發

image-20240826065908334

靜態路由配置及其可能產生的環路問題

是什麼image-20240826070150161

image-20240826070416945

當想轉發的時候 ， 查一下路由表 ， 路由表沒有的話自己配置一下，就是靜態路由配置

預設路由:
對於具有相同下一跳的不同目的網路的路由條目，可以用一條預設路由條目來替代
預設路由條目中的目的網路地址為 0.0.0.0 地址掩碼也是0.0.0.0 CIDR形式 0.0.0.0/0
image-20240826070837451

特定主機路由: 地址掩碼全1才能確定一個特定的主機
image-20240826071120833

路由環路:
解決方法1

image-20240826071254100

解決方法2(解決聚合了不存在網路的問題) 新增黑洞路由

image-20240826071603245

路由選擇協議

image-20240826071900534

因特網採用的路由選擇協議的主要特點:
image-20240826072251718

自治系統內部和自治系統外部可以採用不同類別的協議

image-20240826072347276
EGP和IGP只是路由選擇協議的分類名稱 不是具體的路由選擇協議

常見的路由選擇協議
image-20240826072617039

路由器的基本結構
image-20240826072731549

流程: 訊號從某個埠進入 物理層將訊號轉換成位元流 資料鏈路層從位元流中識別出幀 去掉幀頭和幀尾後送交網路層處理
如果送交網路層的是普通的資料分組 就去查錶轉發 查不到就丟棄
轉發後再一步步封裝 傳送出去
如果送交網路層的是交換路由資訊的路由報文 就把這個分組送交路由選擇處理機
處理機根據分組的內容更新自己的路由表

image-20240826073252790
還有緩衝區

**路由表和轉發表 ** 後續課程不嚴格區分
image-20240826073158842

路由資訊協議RIP

基本概念

image-20240826073639594

image-20240826073837520

**基本工作流程: ** 看 下面圖右邊 的 1 2 3 就是流程
image-20240826074105091

路由條目更新規則 兩個路由器之間透過封裝有路由資訊的RIP更新報文來交換

D收到C的路由表後 先進行改造
image-20240826074332693
舉例都增加1 下一跳全部改成C

下面透過改造好的路由表對自己的路由表進行更新 有不同的更新理由
image-20240826074547557

要注意16就是不可達了

image-20240826074726651
image-20240826074732852

問題
R1到N1的線路故障了 但是還沒來得及把新的路由資訊傳送給R2 就接收到了R2原來的資訊 導致R1被誤導了
image-20240826074945483
image-20240826075014660

開放最短路徑優先OSPF

一些基本概念
image-20240826082125419

image-20240826082155704

image-20240826082257205

image-20240826082840628
image-20240826082925368

image-20240826083017637

分組型別
image-20240826083329166

工作過程

R1收到R2發來的資料庫描述分組後,如果發現自己的資料庫中缺少了資訊,就會傳送LSR分組 ，R2會回應LSU分組image-20240826084012563

當鏈路狀態發生改變或者到了指定的時間 就會傳送鏈路狀態更新分組 收到該分組的路由器會洪泛轉發該分組
image-20240826084141168

在多點接入網路中建立鄰居關係後，如何減少問候分組傳送的數量?
image-20240826084636482

劃分割槽域 --->>> 把利用洪泛法交換鏈路狀態資訊的範圍 侷限於每一個區域 而不是 整個自治系統

image-20240826084938091

邊界閘道器協議BGP

不能以 代價來作為標準尋找最佳路由
image-20240826090408312

具體情況比較複雜 儘量選擇一條能到的比較好的就可以了
image-20240826090918651

基本工作原理
image-20240826091047010
image-20240826091157620
image-20240826091233109

BGP報文型別
image-20240826091329642

封裝關係

image-20240826091925487

IPV4資料包的首部格式

為了簡單起見，將IPV4資料包簡稱為IP資料包

某些IP資料包的首部 除了包含20位元組外 還包含一些可選的欄位 來 增加IP資料包的功能
每一行32Bit 也就是4個位元組

image-20240826092812549

image-20240826092820357
image-20240826092927250
image-20240826092950673

IP資料包的首部長度一定是四位元組的整數倍
由於首部中可選欄位的長度從1位元組到40位元組不等
所以當長度不是四位元組的整數倍的時候
就要用到填充欄位了
image-20240826093122899

image-20240826093148581

image-20240826093218436

總長度欄位和首部長度欄位的關係
image-20240826093431223

首部長度是以4位元組為單位的
總長度直接以位元組為單位
二者相減就得到了資料載荷的長度

標識 標誌 片偏移欄位
這三個欄位共同用於IP資料包分片

為什麼要分片？

image-20240826093649709

image-20240826093802844

舉例說明IP資料包如何進行分片

image-20240826094006062

將3800位元組的資料載荷部分分片為三個單獨的IP資料包 給每個資料包都新增上首部

分片1資料載荷部分的第一個位元組就是原資料包資料載荷部分的第一個位元組
所以片偏移為 0 / 8 (因為片偏移欄位以8為單位)

填表如下
image-20240826094424272

若還需再次分片
image-20240826094447676
image-20240826094509153

生存時間

image-20240826094609653

image-20240826094727577

可以防止IP資料包在網路中永久兜圈

協議欄位
image-20240826094857972

image-20240826094943833

image-20240826095009428

注意: 片偏移量必須為整數 如果計算出來不是整數 就得換一種分片方式了

網際控制報文協議ICMP

image-20240826100035867

分類
image-20240826100214902

終點不可達
image-20240826103044393

源點抑制(讓源點發的慢點)
image-20240826103249661

時間超過
image-20240826103611819
image-20240826103634929

引數問題
image-20240826103705184

改變路由
image-20240826103823879

在什麼情況下不傳送差錯報告報文
image-20240826104231888

ICMP詢問報文
image-20240826104428546

應用

image-20240826104557721

Ping命令就是第一個應用 用來測試主機或路由器間的連通性

image-20240826104657467

tracert命令的原理:
image-20240826104905476H1給H2傳送TTL=1的回送請求報文
到達R1的時候超時
R1丟棄該資料包 並給源主機傳送ICMP差錯報告

之後H1給H2傳送TTL=2的回送請求報文
。。。。。。
以此類推
image-20240826105237615

虛擬專用網VPN與網路地址轉換NAT

虛擬專用網VPN

image-20240826105957945
image-20240826110003708

這三個是無需分配的專用地址
image-20240826110031598

專用地址 只能用於一個機構的內部通訊

內部使用專用網路的兩個透過因特網相互通訊的部門
具體通訊流程如下
image-20240826110329346

雖然要要經過多個網路和路由器
但是從邏輯上看
好像是點對點的一樣
所以也稱為IP隧道技術

內聯網VPN和外聯網VPN

image-20240826110723416

網路地址轉換NAT

用來緩解IPV4地址即將被耗盡的問題
image-20240826110913881

NAT路由器

假如使用私有地址的主機要給因特網上使用全球IP地址的另一臺主機傳送IP資料包
該主機先將ip資料包傳送給NAT路由器
首部中源地址欄位的值為該主機的私有地址
目的地址為另一臺主機的全球地址
NAT路由器從自己的全球IP地址池中
給這個私有地址分配一個臨時的全球IP地址
image-20240826111418678

交換期間使用的全都是全球IP地址
當這臺主機給源主機發回資料包後
NAT路由器會檢查NAT轉換表image-20240826111539364

之後把目的地址再修改為私有地址 並進行轉發

產生的問題

image-20240826111634540

解決

image-20240826111737632

其實就是多加了個埠號

注意: 外網主機不能主動發起通訊
image-20240826111825009

運輸層

概述

之前的幾層實現了主機到主機的通訊
但是通訊的實體是位於通訊兩端主機中的程序
image-20240826131926442
應用程序 到 應用程序

通訊過程如下
image-20240826132040233

image-20240826132134908

埠號

運輸層使用埠號來區分不同的應用程序

埠號的基本概念
image-20240826133101248

傳送方的複用和接收方的分用

在運輸層使用UDP協議封裝 稱為UDP複用
在運輸層使用TCP協議封裝 稱為TCP複用

在網路層使用IP協議封裝成IP資料包 稱為IP複用
IP資料包首部中協議欄位的值 用來表明IP資料包的資料載荷部分封裝的是何種資料單元
取值為6 TCP
取值為17 UDP

接受方的網路層接收到IP資料包後進行IP分用
如果協議欄位17 把資料載荷上交運輸層的UDP
運輸層進行分用
也就是根據埠號
將他們交付給上層相應的使用者程序

如下圖所示流程
image-20240826134010672

TCP/IP體系的 應用層常用協議 所使用的 運輸層熟知埠號

image-20240826134212897

DNS伺服器端程序所使用的熟知埠號是53

舉例:
透過域名訪問WEB伺服器時候, 先向DNS伺服器傳送一個DNS查詢請求
在運輸層採用UDP協議 封裝成UDP使用者資料包
之後將UDP使用者資料包 封裝在IP資料包中
透過乙太網傳送給DNS伺服器
DNS伺服器接收到這個報文後
從中解封出UDP使用者資料包
UDP首部中的目的埠號為53
所以把資料載荷部分交給DNS伺服器

源埠是 使用者PC中的DNS服務(DNS客戶端)程序埠號

image-20240826134757794

image-20240826135040370

TCP和UDP的對比

image-20240826140654996

UDP支援 一對一 一對多 一對全部的通訊
TCP僅支援 一對一通訊

image-20240826145829843

這兩個協議對應用報文的處理

UDP對應用程序交下來的報文既不合並也不拆分 而是 保留這些報文的邊界 UDP是面向應用報文的

TCP把應用程序交下來的資料塊 僅僅看作一連串的 無結構的位元組流
TCP把他們放到傳送快取中，根據傳送策略， 從傳送快取中提取一定數量的位元組，構建TCP報文段併傳送
接收方的TCP一方面從所接收到的TCP報文段中 取出資料載荷部分儲存在接收快取中 一方面將接收快取中的一些位元組交付給應用程序 而且假如傳送方發了10個資料塊 接收方可能只用了4個資料塊就把這些位元組交付給應用程序了 所以應用程序要自己能還原出來這些資訊 TCP是全雙工通訊
TCP是面向位元組流的 image-20240826150543594

可靠不可靠的對比

雖然網際層使用的是IP資料包 向上層提供不可靠的傳輸服務 但只要運輸層使用TCP協議 就可向上層提供面向連線的可靠的傳輸服務
image-20240826151028930

首部對比

image-20240826151116919

TCP的流量控制

讓傳送方別發的太快，要讓接收方來得及接收
image-20240826152012676

舉例:
A給B傳送資料 B對A進行流量控制
假設A的TCP報文段一次可以傳送100位元組資料
建立連線時
B告知A 視窗的大小是400
A也將傳送視窗設定為400
大寫ACK是TCP報文段首部中的標誌位
小寫ack是TCP報文段首部中的確認號欄位 取值201說明序號201之前的資料全部正確接收了
rwnd是視窗欄位

具體流程如下:
image-20240826152917530

就是透過調整自己的接收視窗來對主機A進行流量控制

出現的問題
如果主機B又想讓主機A傳送資料了
重新調整接收視窗大小為300
但是調整報文在途中丟失了
就會產生死鎖

image-20240826153123736

解決 啟用計時器 + 傳送零視窗探測報文
image-20240826153255072

TCP規定 即使接收視窗為0 也必須接收零視窗探測報文

TCP的擁塞控制

基本概念

image-20240826155105469

四種擁塞控制演算法

image-20240826155257742

擁塞視窗 / 慢開始門限

image-20240826155501513

慢開始演算法

一個傳輸輪次 就是一個 往返時間
往返時間並不是恆定的數值
使用傳輸輪次作為橫座標是為了強調
已經把擁塞視窗所允許傳送的報文段都連續傳送出去 並收到了對已傳送的最後一個報文段的確認
開始時擁塞視窗的值為1 慢開始門限的初始值為16

在執行慢開始演算法的時候
傳送方每收到一個對新報文段的確認時
就把擁塞視窗 大小翻倍
然後開始下一輪的傳輸
當擁塞視窗的值增長到慢開始門限值的時候
就改為執行擁塞避免演算法
擁塞視窗是幾 就能傳送幾個資料包文段

改為執行擁塞避免演算法後
收到了一批確認報文後
只能給 擁塞視窗的大小 +1

如果有部分報文段在傳輸過程中丟失了一部分
image-20240826161359387
這樣就會使傳送方超時重傳
傳送方以此判斷網路很可能出現了擁塞
需要進行下圖工作:

image-20240826161535493

整體傳輸過程如下圖:
image-20240826161650140

注意:
image-20240826161708238

但是這兩種演算法有些問題

image-20240826161902094

另外兩種演算法：

image-20240826161930855

快重傳演算法

image-20240826162353404

過程如下:

image-20240826162559861

確認M6 代表前6個報文段都被正確接收了

快恢復演算法
image-20240826162952637

包含全部四種演算法的整個控制擁塞的流程如下圖:

發生了超時重傳的話 就進行前兩種演算法的擁塞控制辦法
當傳送方收到三個重複確認的時候
就進行快重傳和快恢復

image-20240826163123740

來個例題:
image-20240826163732882

TCP超時重傳時間選擇

縱座標是時間

超時重傳時間RTO 應略大於 往返時間RTT

因為TCP下層是很複雜的網路環境
資料包的轉發路由也有可能不同
所以每次的往返時間也有很大差別
所以這個超時重傳時間RTO還是很難選擇

image-20240826165322001

如上圖 可能RTT1 > RTT0 那我們一開始設定的略大於往返時間的RTO就不在合適了

所以選擇的規則如下
image-20240826165642535

RFC6298給出的計算RTO的公式如下:

當測量到第一個RTT1的時候 RTTD1的值取為該樣本的一半
image-20240826170355686

往返時間RTT的測量
image-20240826170453931

image-20240826170543516

會出現上圖的情況

針對出現超時重傳時無法準確測量RTT的情況
解決方法如下:

image-20240826192035732

計算舉例:
沒出現超時重傳就按公式算就可以了
出現了超時重傳就不看公式了 直接變成之前的兩倍

image-20240826192256312

TCP可靠傳輸的實現

TCP基於以位元組為單位的滑動視窗來實現可靠傳輸

ack=31 說明接收方希望收到的下一個資料的序號是31 且 30號及以前的資料都被正確的接收了

image-20240826193750584

本例中傳送視窗的尺寸大小是20
image-20240826194223439

傳送視窗的情況 包括前沿 後沿的情況

image-20240826194307084

現在31~41已經傳送 但是還沒收到確認 42~50是可以傳送但是沒傳送的狀態
如何描述傳送視窗的狀態呢？
image-20240826194418030

接收方只能對按序收到的資料中的最高序號給出確認
如果收到了 32 33 但是沒收到31 那麼會把32 33 放在快取中 同時傳送一個確認資訊 仍然是ack=31
傳送方收到三個重複確認後就會進行快重傳

補充說明image-20240826195000120

來個例題:
image-20240826195831763

TCP連線的建立

概述
image-20240826200838030

連線的建立要解決下面三個問題
image-20240826201641179

三報文握手建立連線的過程

一臺主機中的某個程序主動發起TCP連線建立，稱為TCP客戶，另一臺主機中被動等待TCP連線建立的應用程序稱為TCP伺服器。 將TCP連線建立的過程比喻為握手

一開始，TCP伺服器程序首先建立傳輸控制塊， 用來儲存TCP連線中的一些重要資訊。之後，TCP伺服器程序進入監聽狀態，等待TCP客戶程序的連線請求，稱為被動開啟連線。
TCP客戶程序也是首先建立傳輸控制塊，在打算建立連線的時候，向TCP伺服器程序傳送TCP連線請求報文段，並進入同步已傳送狀態。 稱為主動開啟連線。 SYN=1 說明是連線請求報文段 SYN=1的報文段不能攜帶資料
服務端傳送連線請求確認報文段 ， 並進入同步已接收狀態。報文段也不能攜帶資料
客戶請求收到後 ， 再傳送一個普通的TCP確認報文段，並進入連線已建立狀態 可以攜帶資料 但是不攜帶資料就可以不消耗序號
伺服器程序收到這個確認後 也進入連線已建立狀態image-20240826202913767

為什麼最後還要再傳送一個普通的確認報文段呢？

下面舉例說明:
TCP客戶程序傳送了一個TCP連線請求報文段，但是該報文在某些網路結點長時間滯留了，這會導致該報文段的超時重傳，如果重傳的報文段被TCP服務正確接收，TCP伺服器給TCP客戶程序傳送一個TCP連線請求的確認報文段，並進入連線已建立狀態(現在已經改成了兩報文握手，所以直接進入了連線已建立狀態，而不是像三報文握手那樣進入同步已接收狀態)，現在TCP連線的雙方都進入了連線已建立狀態。
但是，一段時間過後，剛才滯留的請求報文又到達了TCP伺服器程序，就會被誤認為是又發起了一個新的TCP連線請求。這樣會浪費主機很多資源。image-20240826204745254

TCP連線的釋放

透過四報文揮手來釋放連線

下面來舉例說明:
FIN是該報文段首部的終止位

TCP連線釋放報文段(同時對之前收到的報文段進行確認,序號seq欄位的值設定為u,等於客戶程序之前已經傳送過的最後一個位元組的序號 + 1,FIN=1的報文段即使不攜帶資料，也要消耗掉一個序號.ack等於之前客戶程序之前已收到的，資料的最後一個位元組的序號 + 1)
伺服器收到後，傳送一個普通的TCP確認報文段並進入關閉等待狀態。通知高層應用程序客戶端程序要斷開連線了。 TCP客戶程序到服務程序這個連線就釋放了 ， 現在的TCP連線屬於半關閉狀態(如果伺服器程序仍有資料要傳送，客戶程序依然要接收)
客戶端程序收到普通確認報文段後，進入終止等待2狀態，等待TCP服務端程序發出的TCP連線釋放報文段
服務端傳送連線釋放報文段 進入最後確認狀態
客戶端收到後傳送確認報文段 進入時間等待狀態
服務端收到後 進入關閉狀態
客戶端經過2MSL後進入關閉狀態(確保TCP伺服器程序收到最後一個TCP確認報文段並進入關閉狀態)

image-20240826211252087

保活計時器
image-20240826211820957

TCP報文段的首部格式

image-20240826213752347

首部格式如圖
image-20240826213954797

image-20240826214024736

image-20240826214409001

image-20240826214452861

image-20240826214501483

image-20240826214516468

image-20240826214712707
該欄位以4位元組為單位
0101的話 十進位制是5 以4位元組為單位 所以首部的長度就是 20位元組
1111的話 十進位制是15 以4位元組為單位 所以首部長度就是 60位元組
image-20240826215111086

image-20240826215149598

傳送視窗大小應該選擇 擁塞視窗和接收視窗中的較小者
image-20240826215323036

image-20240826215354900

image-20240826215450242

image-20240826215501514

image-20240826215529702

擴充套件首部
image-20240826215618381

image-20240826215632691

應用層

常見的應用
image-20240827074606185

客戶/伺服器(C/S)方式 和 對等(P2P)方式

CS方式

image-20240827074804394
image-20240827074920321
image-20240827075001996

對等方式
image-20240827075217498
image-20240827075243123

動態主機配置協議DHCP(TCP/IP體系應用層的協議)

DHCP報文在運輸層被封裝成UDP使用者資料包

需要給主機手動配置 IP地址 子網掩碼 預設閘道器 DNS伺服器等 才能使使用者主機正確訪問Web伺服器
但是手工配置的工作量較大
所以可以在網路中設定一臺DHCP伺服器，網路開機後自動啟動DHCP程式，向DHCP伺服器請求自己的網路配置資訊，這樣就可以自動獲取網路配置資訊了，不需要手動設定了

DHCP的工作過程

現在網路中有兩臺DHCP伺服器和一臺主機
DHCP伺服器使用CS方式，在DHCP伺服器上執行DHCP伺服器程序 ，簡稱為DHCP伺服器(使用的UDP埠是67)
使用者主機上執行DHCP客戶端進行，簡稱為客戶(使用的UDP埠是68)

先傳送一個DHCP發現報文
封裝有 事務ID DHCP客戶端的MAC地址 等
源IP地址是 0.0.0.0
目的IP地址是: 255.255.255.255
伺服器根據MAC地址查詢自己的資料庫 查詢有無這個MAC地址對應的配置資訊(也要用ARP確保IP地址沒被佔用)
有的話就用這個配置資訊構建併傳送DHCP提供報文
沒有的話就用預設配置資訊來構建併傳送DHCP提供報文(目的地址也是廣播地址)
DHCP客戶根據事務ID來判斷是不是自己請求的發現報文(和自己封裝的事務ID相等就是自己請求的報文)
兩臺伺服器各會傳送一個，客戶選擇先到的那個就可以了(現在就挑選好了DHCP伺服器)
下面傳送請求報文,也就是要徵得DHCP伺服器的同意
請求報文包含以下內容
image-20240827092845923

伺服器同意，給客戶傳送確認報文
客戶收到這個確認報文後，就可以開始使用所租用的IP地址了
不過在使用前還會先看看是不是被網路中的其它主機佔用了
image-20240827093041547

當租期已經過去一半時，客戶會給伺服器傳送更新請求報文
同意 則發回確認報文
不同意 則發回否認報文 客戶收到後必須立即停止使用的IP地址並重新傳送DHCP發現報文 重新開始申請IP地址
無響應 則當租期過去87.5%時，必須重新傳送更新請求報文
。。。

另外伺服器可以隨時提前終止DHCP伺服器所提供的租用期
傳送釋放報文段即可

完整流程圖如下:

image-20240827093552720

DHCP中繼代理

image-20240827094003015

路由器不會轉發DHCP發現報文 因為是廣播

解決方法:
給該伺服器配置DHCP伺服器的IP地址
並使之稱為DHCP中繼代理
image-20240827094132475

域名系統DNS

工作流程:
在瀏覽器輸入域名後，使用者主機會現在自己的DNS快取記憶體中查詢該域名對應的IP地址，沒有找到的話，就會向網路中的某臺DNS伺服器查詢(DNS伺服器中有域名和IP地址對映關係的資料庫)，DNS伺服器收到DNS查詢報文後，在其資料庫中進行查詢，之後將查詢結果傳送給使用者主機。 使用者主機的瀏覽器透過IP地址對這個伺服器進行訪問。

層次樹狀結構的域名結構

image-20240827095740989

image-20240827100013837

形成了下面這種樹形結構
image-20240827100245691

DNS是分散式系統
image-20240827100652191

域名解析的過程

遞迴查詢
image-20240827103617149

迭代查詢
image-20240827103743822

image-20240827103923048

在查詢時就可以利用上快取記憶體了
image-20240827103958719

image-20240827104014101

不光在本地域名伺服器中需要快取記憶體
在使用者主機中也很需要
image-20240827104224435

檔案傳送協議FTP

image-20240827133121917

FTP客戶計算機可以將各種檔案上傳到FTP伺服器
也可以從FTP伺服器下載檔案
image-20240827133235874

image-20240827133339314

建立FTP伺服器後 會有一個IP地址
客戶在瀏覽器中可以透過這個地址訪問FTP伺服器

image-20240827133458207

工作原理
一開始建立的連線 是來傳送命令的 是命令通道
後面建立的才是資料通道

主動模式
image-20240827133711735

被動模式
image-20240827133750654

埠號不一樣 伺服器是被動等待客戶連線的

image-20240827133902392

電子郵件

image-20240827140245272

郵件伺服器中有很多郵箱
有用來轉發待傳送郵件的快取

使用者代理 其實就是電子郵件的客戶端軟體 比如Gmail 之類的
image-20240827140725454

郵件傳送和接收過程
image-20240827140837594

SMTP的基本工作原理

發現有待轉發的郵件 就建立TCP連線
基於命令和應答

具體流程如下圖

220是應答程式碼 可能跟有描述資訊
image-20240827142710652

image-20240827142904392

注意:
image-20240827142931191

電子郵件的資訊格式

image-20240827144234084

傳送

如果有非ASCII碼資料 要轉化為MIME進行傳送
image-20240827144853703

為了實現這種轉換
image-20240827144929925

下面介紹有關郵件讀取的相關內容

常用的郵件讀取協議
image-20240827151042028

基於全球資訊網的電子郵件

用的都是HTTP協議
image-20240827151246798

很方便

全球資訊網

是執行在因特網上的一個分散式應用
image-20240827151557559

瀏覽器
image-20240827151737046

image-20240827151826983

全球資訊網的文件
image-20240827151950733

這些文件都部署在伺服器端
需要從伺服器傳送給瀏覽器進行解析和渲染

TCP/IP體系中應用層非常重要的協議
HTTP超文字傳輸協議
image-20240827153156432

舉例:
image-20240827153257364

HTTP/1.0

在第三次握手，也就是最後一個報文的資料載荷部分攜帶了HTTP請求
image-20240827153847547

HTTP/1.1

image-20240827153942922

HTTP的報文格式

image-20240827154353636

HTTP請求報文的格式
image-20240827154524305

url 統一資源定位符 /index.htm：伺服器上資源的路徑（例如一個網頁）

這個HTTP報文沒有主體實體

image-20240827154709055

支援以下方法
image-20240827154946731

HTTP響應報文的格式

短語是對狀態碼的簡單描述

image-20240827155035110

常見的狀態碼image-20240827155049532

image-20240827155153929

Cookieimage-20240827155316017

後續每次客戶端請求伺服器的時候，都會把cookie放在首部行中
具體流程如下:
image-20240827155455413

全球資訊網快取與代理伺服器
image-20240827155703351

代理伺服器沒有請求的資料才會向因特網上的原始伺服器傳送請求
image-20240827155733405

image-20240827155829234

如果Web快取的命中率高，就可以大大減少該鏈路上的通訊量 降低網路時延

image-20240827161025212

相關文章