計算機網絡基礎

原文連接

1. 計算機網絡體系結構

1.1 簡介

計算機網絡的各層 + 其協議的集合，定義該計算機網絡的所能完成的功能。

1.2 結構

計算機網絡體系結構分為3種：

• OSI體系結構

  概念結構清楚，理念完整，但復雜&不實用

• TCP/IP 體系結構

  包含一系列構成互聯網基礎的網絡協議，是Internet的核心協議 & 被廣泛的應用於局域網 和廣域網

• 五層體系結構

  融合了OSI 與 TCP/IP 的體系結構，目的是為了學習 & 講解計算機的原理

底三層為通信子網，負責數據傳輸

高三層為資源子王，相當於計算機系統，完成數據處理

傳輸層承上啟下

TCP/IP體系結構詳解

2. TCP

2.1 定義

Transmission Control Protocol，即傳輸控制協議。

1. 屬於傳輸層協議通信協議
2. 基於TCP 通信的協議有 HTTP 、SMTP、 FTP、 Telnet 和POP3

2.2 特點

• 面向連接

  使用TCP傳輸數據前，必須先建立TCP連接，傳輸完成后再釋放連接

• 面向字節流

  數據以流的方式進行傳輸

• 全雙工通信

  建立TCP連接之后，通信雙方都能發送數據

• 可靠

  通過TCP連接傳送的數據：不丟失、無差錯、不重復&按序到達

基於以上特點 ：

​ 缺點：效率慢（需要建立連接，發送確認包等）

​ 優點：數據傳輸可靠

2.3 應用場景

要求通信數據可靠，數據要准確無誤地傳遞給對方

如：傳輸文件：HTTP、HTTPS、FTP等協議；傳輸郵件：POP、SMTP等協議

• 萬維網：HTTP協議
• 文件傳輸：FTP協議
• 電子郵件：SMTP協議
• 遠程終端接入：TELNET協議

2.4 報文段格式

• TCP雖然免洗那個字節流，但是傳送的數據單元 = 報文段
• 報文段 = 首部 + 數據 2部分
• TCP的全部功能體現在它首部中各字段的作用

1. 首部前 20 個字符固定、后面有4n個字節是根據需要而增加的選項
2. 故 TCP 首部最小長度 = 20字節

源端口和目的端口

各占2個字節

分別寫入源端口 和 目的的端口號。

TCP的分用功能也是通過端口實現的。

序號（報文段序號）

各占4個字節

序號范圍為[0,2²³ -1],共2²³（即4294967296）個序號，序號增加至2²³-1后，下一個序號就又回到0。也就是說，序號使用 mod2²³運算

TCP是面向字節流的。在一個TCP連接中傳送的字節流中的每一個字節都是按照順序編號。

整個要傳送的字節流的起始序號必須在連接建立時設置。

首部中的序號字段值則指的是本報文段所發送的數據的第一個字節的序號。

確認號

占4個字節

是期望收到對方下一個報文段的第一個數據字節的序號。

若 確認號 = N，則表明：到序號N-1為止的所有數據都已正確收到。

由於序號字段有32位長，可對4GB（即4千兆字節）的數據進行編號。在一般情況下，可保證黨序號重復使用時，就需要的數據早已通過網絡到達終點

數據偏移

占4位

它指出 TCP報文段的數據起始處 距離 TCP報文段的起始處 有多遠。

這個字段實際上是指出TCP報文段的首部長度。由於首部中還有長度不確定的選項字段，因此數據偏移字段是有必要的。

但是注意，“數據偏移”的單位是32位字（即以4字節長的字為計算單位）。由於4為二進制能夠表示的最大十進制數是15，因此數據偏移的最大值是60字節，這也是TCP首部的最大長度（即選項長度不能超過40字節）

保留

占6位

保留為今后使用，但目前應置為0

緊急URG（URGent）

當URG = 1時，表示緊急指針字段有效。它告訴系統次報文段中有緊急數據，應盡快傳送（相當於高優先級的數據），而不要按照原來的排隊順序來傳送。

比如：已經發送了很長的一個程序在遠地的主機上運行，但是后來發現了一些問題，需要取消該程序的運行。因此用戶從鍵盤發出中斷命令（Control + C）。如果不使用緊急數據，那么餓着兩個字符將存儲在接收TCP的緩存末尾。只有在所有數據被處理完陳過之后，這兩個字符才被交付接收方的應用進程。這就浪費了很多時間。

當URG= 1時，發送應用進程就告訴發送方的TCP有緊急數據要傳送。於是發送方TCP就吧緊急數據插到報文段數據的最前面，而在緊急數據后面的數據仍為普通數據。這時喲與首部中的緊急指針（Urgent Pointer）字段配合使用。

確認ACK（ACKnowledgment）

僅當ACK = 1時確認號字段才有效。當ACK = 0，確認號無效。TCP規定，在連接建立之后所有傳送的報文段都必須把ACK置為1

推送PSH（PuSH）

當兩個應用進程進行交互式通信時，有時在一端的應用進程希望在鍵入一個命令后立即就能夠立即收到對方的響應。在這種情況下，TCP就可以使用推送（push）操作。

這時，發送方TCP 把PSH置為1，並立即創建一個報文段發送出去。

​ 接收方TCP收到PSH為1 的報文段，就盡快地（即“推送”向前）交付給接收應用程序，而不在等到整個緩存都填滿了之后再向上交付

復位RST（ReSeT）

當RST = 1時，表明TCP連接中出現了嚴重的差錯（如 由於主機崩潰活着其他原因），必須釋放連接，然后再重新建立運輸連接。

RST置為1還用來拒絕一個非法的報文段 或者 拒絕一個打開連接。

RST 也可稱為重建位 或 重置位。

同步SYN（SYNchronization）

在連接建立時用來同步序號。

當SYN = 1而 ACK = 0 時，表示這是一個連接請求報文段，對方若同意建立連接，則應在響應的報文段中使用SYN = 1和 ACK = 1

因此，SYN置為1，就表示這是一個連接請求或連接接收報文。

終止FIN（FINis）

用來釋放一個連接，當FIN = 1時，表明次報文段的發送方數據發送完畢，並要求釋放運輸連接。

窗口

占 2 個字節

窗口值 為[0 , 2¹⁶ -1] 之間的整數。

窗口指的是發送報文段的一方的接收窗口（而不是自己的發送窗口）。

窗口值告訴對方：從本報文段首部中的確認號算起，接收方目前允許對方發送的數據量（以字節為單位）

之所以要有這個限制，時因為接收方的數據緩存空間是有限的。

總之，窗口值作為接收方讓發送發設置其發送窗口的依據。

窗口字段明確的指出了現在允許對方發送的數據量。窗口值經常在動態變化着。

檢驗和

占 2 個字節

檢驗和 字段檢驗的范圍包括首部 和 數據這兩部分。

和 UDP用戶數據報一樣，在計算校驗和時，要在TCP報文段的前面加上12字節的偽首部。

TCP 和 UDP 的偽首部格式是相同的。只需把偽首部第四個字段中的17改為6（TCP的協議號為6），把第五個字段的UDP長度改為TCP長度即可。

接收方收到次報文段后，仍要加上這個偽首部來極端校驗和，若使用IPv6，則相應的偽首部也要改變。

緊急指針

占 2 個字節

緊急指針在URG = 1時才有意義，它指出本報文段中的緊急數據的字節數（緊急數據結束后就是普通數據）。

因此，緊急指針指出了緊急數據的末尾在報文段中的位置。

當緊急數據都處理完時，TCP就告訴應用程序恢復到正常的操作。

值得注意的是，即時窗口為0時，也可發送緊急數據。

選項

長度可變，最長可達40字節。當沒有使用“選項“時，TCP首部長度是20個字節。最后的填充字段僅僅為了使真個TCP首部長度是4字節的整數倍。

2.5 建立連接（三次握手）

成功進行TCP的三次握手后，就建立起一跳TCP連接，即可傳送應用層數據

1. 三次握手期間，任何一次未收到對面的回復，都會重發
2. 因TCP提供的是全雙工通信，故通信雙發的應用進程在任何時候都能進行數據的發送

為什么TCP建立需要三次握手

防止服務器端因接收了 早已失效的連接請求報文，從而抑制等到客戶端請求，最終導致形成死鎖，浪費資源

SYN洪泛攻擊：

• 從上可看出：服務端的TCP資源分配時刻 = 完成第二次握手時；而客戶端的TCP資源分配時刻 = 完成第三次握手時
• 這就使得服務器易於受到SYN洪泛攻擊，即同時多個客戶端發起連接請求，從而需進行多個請求的TCP連接資源分配

2.6 釋放連接過程（四次揮手）

TCP釋放連接為什么需要四次揮手

為了保證雙方都能通知對方 需釋放 & 斷開連接

即釋放連接后，都無法接受/發送消息給對方

為什么客戶端關閉連接前要等待2MSL時間？

1. 即TIME-WAIT狀態的作用是什么
2. MSL = 最長報文壽命（Maximum Segment Lifetime）

• 原因1：為了保證客戶端發送最后一個連接釋放確認報文能到達服務器，從而使服務器能正常釋放連接

  

• 原因2：防止 早已失效的連接請求報文 出現在本連接中

  客戶端發送了最后一個連接釋放請求確認報文后，再經2MSL時間，則可使本連接持續時間內產生的所有報文段從網絡中消失。

  即在下一個新的連接中 就不會出現 早已試下的連接請求報文

2.7 無差錯傳輸

2.7.1 含義

• 無差錯： 即 傳輸信道不出差錯
• 發送 & 接受效率匹配：即 無論發送方以多快的速度發送數據，接收方總來的及處理接收到的數據

2.7.2 基礎：滑動窗口協議

先理解兩個基本概念：發送窗口，接收窗口

工作原理：

對於發送端：

1. 每收到一個確認幀，發送窗口就向前滑動一個幀的距離

2. 當發送窗口內無可發送的幀時（即 窗口內的幀全部時已發送但未收到取人的幀）。發送方就會停止房東，直到收到接收方發送的確認幀使窗口移動，窗口內有可以發送的幀，之后開始繼續發送

   

對於接收端：

當收到數據幀后，將窗口向前移動一個位置，並發回確認幀，若收到的數據幀落在接收窗口之外，則一律丟棄。

滑動窗口協議的重要特性

• 只有接收窗口向前滑動、接收方發送了確認幀，發送窗口才有可能（只有發送方收到確認幀才是一定）向前滑動

• 停止-等待協議、退回N幀協議 & 選擇重傳協議 只是在發送窗口大小 和 接受窗口大小上有所差別：

  1. 停止等待協議：發送窗口大小 = 1，接收窗口大小= 1；即 單幀滑動窗口 等於 停止-等待協議
  2. 后退N幀協議：發送窗口大小 > 1，接收窗口大小 = 1；
  3. 選擇重傳協議：發送窗口大小 > 1，接收窗口大小 >1

• 當接受窗口大小為1時，可保證幀有序接收

• 數據鏈路層的滑動窗口協議中，窗口的大小在傳輸過程中時固定的（注意要與TCP的滑動窗口協議區別）

2.7.3 實現無差錯傳輸的解決方案

采用可靠的傳輸協議，使得：

1. 出現差錯的時候，讓發送方重傳插座數據：即 出錯重傳
2. 當接收方來不及接受收到的數據，可以通知發送方降低發送數據的效率：即 速度匹配

---

• 針對上述2個問題，分別采用的解決方案是：自動重傳協議 和 流量控制 & 擁塞控制協議

解決方案1：自動重傳請求協議ARQ（針對 出錯重傳）

• 即 Auto Repeat reQuest

• 類型

下面，具體介紹 上述3中協議：

類型1:停等協議ARQ（Stop-And-Wait）

• 原理：（單幀滑動窗口）停止-等待協議 + 超時重傳

即：發送窗口大小 = 1、接收窗口大小 = 1

1. 發送方每發一幀，要等到接收方的應答信號后才能發送下一幀
2. 接收方每接受一幀，都要反饋一個應答信號，表示可接收下一幀
3. 若接收方不反饋應答信號，則發送發必須一直等待

類型2：后退N幀協議

也稱：連續ARQ協議

• 原理：多幀滑動窗口 + 累計確認 + 后退N幀 + 超時重傳

即：發送窗口 > 1，接收窗口大小 = 1

• 具體描述

a. 發送方：采用多幀滑動窗口的原理，可連續發送多個數據幀，二不需要等待對方確認

b. 接收方：采用 累計確認 & 后退N幀的原理，只允許按順序接收幀。

具體原理如下

類型3: 選擇重傳ARQ（Selective Repeat）

• 原理：多幀滑動窗口 + 累計確認 + 后退N幀 + 超時重傳

  即：發動窗口大小 > 1、接收窗口大小 > 1

與 類型2 類似，只是 接收窗口的大小 有所區別

• 特點

優點：因連續發送數據幀 而 提高了信道的利用率

缺點：重傳時 又必須把原來已經傳動正確的數據幀進行重傳（僅因為這些數據幀前面有一個數據幀出了錯），將導致傳送效率低

由此可見，若信道傳輸質量很差，導致誤碼率較大時，后退N幀協議不一定優於停止等待協議

解決方案2：流量控制 & 擁塞控制（針對 速度匹配）

措施1: 流量控制

、

措施2：擁塞控制

• 定義：防止過多的數據注入到網絡中，使得網絡中的路由器 & 鏈路不至於過載

  擁塞：對網絡中的資源需求 > 該資源所能提供的部分

• 與 “流量控制的區別”：

具體解決方案：

共分為2個解決方案：慢開始&擁塞避免、快重傳&快恢復

解決方案1: 慢開始 & 擁塞避免

a. 擁塞窗口

發送方維持一個狀態變量：擁塞窗口（cwnd，congestion window）

b. 慢開始算法

• 原理

  當逐句開始發送數據時，由小到大逐漸增大 擁塞窗口數值（即 發送窗口數值），從而 由小到大逐漸增大發送報文段

• 目的

  開始傳輸時，試探網絡的擁塞情況

• 具體措施

  

• 示意圖

  

• 特別注意

  慢開始的“慢”指：一開始發送報文段時擁塞窗口（cwnd）設置得較小（為1），使得發送方在開始時只發送一個報文段（目的是試探一下網絡的擁塞情況）

  並不是指擁塞窗口（cwnd）的增長速率慢

c. 擁塞避免 算法

• 原理

  使得擁塞窗口（cwnd）按限行規律 緩慢增長：每經過一個往返時間RTT，發送方的擁塞窗口（cwnd）加1

1. 擁塞避免 並不可避免擁塞，只是將擁塞窗口按現行規律緩慢增長，使得網絡比較不容易出現擁塞
2. 想比滿開始短發的加倍，擁塞窗口增長速率緩慢很多

• 示意圖

  

解決方案描述 （慢開始 & 擁塞避免）

• 為了防止擁塞窗口（cwnd）增長過大 而引起網絡擁塞，采用慢開始 & 擁塞避免 2中算法，具體規則如下

• 實例：

解決方案2： 快重傳 & 快恢復

快重傳 & 快恢復的解決方案 是對慢開始 & 擁塞避免算法的改進

a. 快重傳算法

• 原理

  1. 接收方：每收到一個失序的報文段后 就立即發出重復確認（為的是使發送方及早知道有報文段沒有到達對方），而不要等到自己發送數據時才進行捎帶確認
  2. 發送方：只要一連接收到3個重復確認就立即重傳對方尚未收到的報文段，而不必 繼續等待設置的重傳計時器到期

• 作用：

  由於發送方 今早重傳了未被確認的報文段，因此采用快重傳后可以使整個網絡吞吐量提高約20%

• 示意圖

  

  b. 快恢復

  當發送方連續收到3個重復去人后，就：

  1. 執行 乘法減小算法：把慢開始門限（ssthresh）設置為 出現擁塞時發送窗口值的一般 = 擁塞窗口的一半
  2. 將擁塞窗口（cmnd）的值設置為慢開始門限ssthresh減半后的數值 = 擁塞窗口的一半
  3. 執行加法算法 ：執行擁塞避免算法，使擁塞窗口緩慢線性增大

  注：

  1. 由於跳過了擁塞窗口（cwnd）從1起始的慢開始過程，所以稱為：快恢復
  2. 此處網絡不會發生網絡擁塞，因若擁塞，則不會收到多個重復確認報文

解決方案描述（快重傳 & 快恢復）

• 原理

  為了優化慢開始 & 擁塞避免的解決方案，在上述方案中加入快重傳 & 快恢復 2種算法，具體規則如下

  

• 示意圖

  

2.8 與UDP協議的區別

3. UDP

3.1 定義

User Datagram Protocol，即 用戶數據報協議

1. 屬於 傳輸層通信協議
2. 基於UDP的應用層協議有 TFTP、SNMP 與 DNS

3.2 特點

無連接的、不可靠的、面向報文、無擁塞控制，具體介紹如下

3.3 優缺點

• 優點：速度快
• 缺點：消息易丟失（特別是 網絡較差時）

3.4 應用場景（對應 應用層協議）

要求通信速度高

如： 域名轉換：DNS協議 文件傳輸：FTP協議 網絡管理：SNMP協議 遠程文件服務器：NFS協議

3.5 報文段格式

• UDP的報文段共有2個字段：數據字段 & 首部字段
• 下面主要介紹首部（8字節、4個字段）

4. HTTP

4.1 簡介

4.2 工作方式

• HTTP協議采用 請求 / 響應 的工作方式
• 具體工作流程如下：

4.3 HTTP報文詳解

• HTTP在 應用層 交互數據的方式 = 報文
• HTTP的報文分為：請求報文 & 響應報文

分別用於 發送請求 & 響應請求時

4.3.1 請求報文

1. 報文結構

• HTTP的請求報文由 請求行、請求頭 & 請求體 組成，如下圖

請求行（request line）

• 作用

  聲明 請求方法、主機域名、資源路徑 & 協議版本

• 結構

  請求行的組成 = 請求方法 + 請求路徑 + 協議版本

• 組成介紹

  

• GET & POST方法的區別

請求頭

• 作用：聲明客戶端、服務端/報文的部分信息

• 使用方式：采用“header（字段名）：value（值）”的方式

• 常用請求頭：

  1. 請求和響應報文的通用Header

     

  2. 常見請求Header

  

請求體

• 作用：存放 需要發送給服務器的數據信息（可選部分，如GET請求就無請求數據）

• 使用方式：共三種

  

4.3.2 響應報文

報文結構

• HTTP的響應報文包括：狀態行、響應頭 & 響應體

響應頭 、響應體 與 請求報文的請求頭 、請求體類似

這兩種報文最大的不同在於 狀態行 和 請求行

組成1:狀態行

• 作用

  聲明 協議版本，狀態碼，狀態碼描述

• 組成

  狀態行有協議版本、狀態碼 & 狀態信息組成

其中空格不能省

• 具體介紹

  

組成2:響應頭

• 作用：聲明客戶端、服務器/報文的部分信息

• 使用方式：采用“header（字段名）：value（值）”的方式

• 常用請求頭

  1. 請求和響應報文的通用Header

  

  2. 常見響應Header

  

組成3：響應體

• 作用：存放需要返回給客戶端的數據信息
• 使用方式：和請求體是一只的，同樣分為：任意類型數據交換格式，鍵值對形勢 和分部分形勢

4.4 額外知識

• HTTP1.1 和 HTTP1.0 的區別
• HTTP 和 HTTPS的區別
• HTTP處理長連接的方式

4.4.1 HTTP1.1 和 HTTP1.0 的區別

HTTP1.1 與 HTTP1.0 多了以下優點：

• 引入了持久連接，即 在同一個TCP的連接中可傳送多個HTTP請求 & 響應
• 多個請求 & 響應 可同時進行，可重疊
• 引入更多的請求頭 & 響應頭

如 與身份認證、狀態管理 & Cache緩存等機制相關的、HTTP1.0無host字段

4.4.2 HTTP 和 HTTPS的區別

4.4.2 HTTP處理長連接的方式

5. Socket

5.1 簡介

• 套接字，是應用層 與 TCP/Ip協議族通信的中間軟件抽象層，表現為一個封裝了TCP/IP協議族的 編程接口（API）

  

1. Socket 不是一種協議，而是一個編程調用接口（API），屬於傳輸層（主要解決數據如何在網絡中傳輸）
2. 只需調用Socket去阻止數據，以符合指定的協議，即可通信

• 成對出現

  Socket = {(IP地址1:PORT端口號)，(IP地址2:PORT端口號)}
  

• 一個Socket實例 唯一 代表一個主機上的一個應用程序的通信鏈路

5.2 建立Socket 連接的過程

5.3 原理

Socket 的使用類型主要有兩種：

• 流套接字（streamsocket）：基於TCP協議，采用 流的方式 提供可靠的字節服務
• 數據報套接字（datagramsocket）：基於UDP協議，采用數據報文 提供數據打包發送的服務

具體原理圖：

5.4 Socket與Http對比

• Scoket屬於傳輸層，因為TCP/IP協議屬於傳輸層，解決的事數據如何在網絡中傳輸的問題

• Http協議屬於應用層，解決的是如何包裝數據

• Http：采用 請求-響應 方式

  1. 即建立網絡連接后，當 客戶端 向 服務器 發送請求后，服務器才能向客戶端返回數據
  2. 是客戶端有需要才進行通信

• Socket：采用 服務器主動發送數據的方式

  1. 即建立網絡連接后，服務器 可注定發送消息給客戶端，二不需要由客戶端向服務器發送請求
  2. 是服務器端有需要才進行通信

6. 其他知識

6.1 在瀏覽器中輸入URL地址-》》顯示主頁的過程

6.2 IP地址（IPv4 地址）

• 定義 連接Internet 中的每一台主機（或 路由器）的全球唯一的標識符
• 組成IP地址 = 32位 = 網絡號 + 主機號；即IP地址::=

其中：

1. 網絡號：標志主機（或路由器）所連接到的網絡。一個網絡號在整個因特網范圍內必須唯一
2. 主機號：標志該主機（或路由器）。一個主機號在它前面的網絡號所指明的網絡范圍必須是唯一的

不同類型的IP地址，其主機號 & 網絡號所占字節數不同：

故：一個IP地址在整個網絡范圍內是唯一的

• 分類。傳統IP地址是分類的地址，分為A，B，C，D，E五類
• 區別在於 網絡號 & 主機號的字節數不同

• 特別注意：在各類IP地址中，有一些IP地址用於特殊用途，不能用於做主機IP地址

6.3 ICMP協議

• 定義 Internet Control Message Protocol，即網際控制報文協議

1. 屬於IP層協議
2. 注：ICMP報文不是高層協議，而是作為IP層數據報的數據，加上數據報首部，組成IP數據報發出去

• 作用：更有效的轉發IP數據包 & 提高交付成功的機會

同時允許主機/路由器報告差錯 & 異常情況

• 分類 ICMP差錯報告報文 & ICMP 詢問報文
• 主要應用 PING（分組網間探測）、Traceroute（跟蹤1個分組從源點到終點的路徑，原理 = 從源主機向目的主機發送一連串的IP數據報）

6.4 Ping的過程

• 定義 Packet InterNet Groper ，即分組網間探測

是ICMP 報文的一個重要應用：使用了ICMP 回送請求 & 回送回答報文

是應用層 直接使用網絡層ICMP的一個例子，無經過傳輸層的TCP，UDP

• 作用 測試兩個主機的連通性
• 原理

1. 向目的主機發送多個ICMP回送請求報文
2. 根據目的的主機返回ICMP回送回答報文中的時間戳，從而計算出往返時間
3. 根據現實的結果：發送到目的主機的IP地址、發送& 收到&接收的分組數、往返時間的最小、最大&平均值

• 過程 假設有兩台主機：（目的主機）PC1：IP = 192.168.1.1 （源主機）PC2：IP = 192.168.1.2

6.5 路由器 與交換機的區別

6.6 Cookie 與 Session

• 簡介

• 區別和對比

6.7 Cookie 和Token

• 簡介

• 基於Cookie的身份驗證 & 驗證流程

• 基於Token的身份驗證 & 驗證流程