計算機網路複習筆記

本文結合計算機網路自頂向下，中科大鄭烇老師網課，b 站 up 主湖科大教書匠(講的太好了)以及優秀的部落格(CS-Notes)和公眾號進行總結，從問題出發，同時不破壞計算機網路得整體結結構，對問題分類總結，方便記憶

文章目錄

• 1.計算機網路分層模型
• • 1.1計算機分層模型⭐️
  • • 五層協議
• 2 傳輸層(TCP)
• • 2.1 TCP 和 UDP 的區別⭐️
  • 2.2 TCP 頭部格式⭐️
  • 2.3 三次握手四次揮手⭐️
  • • 2.3.1 三次握手細節⭐️
    • 2.3.2 為什麼不能兩次握手呢⭐️
    • 2.3.3 TCP 四次揮手⭐️
    • 2.3.4 TCP 為什麼要四次揮手⭐️
    • 2.3.5 簡述 TIME_WAIT和 CLOSE_WAIT⭐️
  • 2.4 TCP 協議如何保證傳輸的可靠性
  • • 2.4.1超時重傳(ARQ)
    • 2.4.2確認應答號和***
    • 2.4.3三次握手四次揮手
    • 2.4.4 流量控制
    • 2.4.5 擁塞控制
    • • 2.4.5.1慢開始和擁塞避免演算法
      • 2.4.5.2 快重傳和快恢復
      • 2.4.5.3 改進的整體演算法
• 3 傳輸層(HTTP)
• • 3.1 HTTP 報文結構和狀態碼
  • 3.2 GET 和 POST方法
  • 3.3HTTP是不儲存狀態的協議,如何儲存使用者狀態?
  • 3.4Cookie的作用是什麼?和Session有什麼區別？
  • 3.5 輸入一個網址發生的事情

1.計算機網路分層模型

1.1計算機分層模型⭐️

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-bhaffciJ-1620353895627)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截圖2021-04-29 11.12.07.png)]

• 五層協議

  • 應用層 ：為特定應用程式提供資料傳輸服務，例如 HTTP、DNS 等協議。應用程式之間的互動資料單位為報文。
  • 傳輸層 ：為兩臺主機程序提供通用資料傳輸服務。運輸層包括兩種協議：傳輸控制協議 TCP，提供面向連線、可靠的資料傳輸服務，資料單位為報文段；使用者資料報協議 UDP，提供無連線、盡最大努力的資料傳輸服務，資料單位為使用者資料報。TCP 主要提供完整性服務，UDP 主要提供及時性服務。
  • 網路層 ：網路層的任務就是選擇合適的網間路由和交換結點， 確保資料及時傳送。在傳送資料時，網路層把運輸層產生的報文段或使用者資料報封裝成分組和包進行傳送。(路由)
  • 資料鏈路層 提供鏈路層協議為同一鏈路
    的主機提供資料傳輸服務。（交換機）
  • 物理層 ：考慮如何在傳輸介質上傳輸資料流，使資料鏈路層感覺不到不同的傳輸介質和傳輸手段的差異對它造成的影響

  報文，報文段，分組，包，資料報、幀、資料流

2 傳輸層(TCP)

2.1 TCP 和 UDP 的區別⭐️

2.2 TCP 頭部格式⭐️

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-DzapVBnf-1620353895628)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截圖2021-04-29 18.55.44.png)]

• 源埠和目的埠號：表明該報文段來自的應用程序，以及要去向哪個程序

• 序號：TCP 報文段的資料載荷的第一個位元組的序號

• 確認號：期望收到的下一個 TCP報文段的資料載荷的第一個位元組的序號，也是對之前收到的資料的確認。(如果確認號 = n，則表明序號為 n - 1的所有的資料已經正確接收，期望接收序號為 n 的資料)

• ACK：ACK 確認號欄位為1時，確認欄位有效，0則無效。TCP建立連線後所有的欄位都必須把 ACK 設定為1.

• 資料偏移：用來指出 TCP 報文段的資料載荷離TCP 報文段的開頭有多遠

• SYN(Synchronize Sequence Numbers)：TCP建立時來同步序號

• FIN(FInish):用來釋放連線

2.3 三次握手四次揮手⭐️

seq：seq = ack(對方的的期望下一次的序號) ack = seq + 1(對方的***加一)

2.3.1 三次握手細節⭐️

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-ugVPQFdf-1620353895629)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截圖2021-05-01 16.55.49.png)]

答題思路：對該圖進行描述

2.3.2 為什麼不能兩次握手呢⭐️

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-sr8blMIE-1620353895629)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截圖2021-05-01 17.05.20.png)]

答題思路：是因為為了防止已經失效的 TCP 客戶端連線請求又傳送到了伺服器端，造成資源浪費，然後進行上圖的木描述。

2.3.3 TCP 四次揮手⭐️

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-qAUYXp3T-1620353895630)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截圖2021-05-03 10.32.47.png)]

答題思路：按照圖片描述，注意 各種數值

2.3.4 TCP 為什麼要四次揮手⭐️

​ 因為 TCP 伺服器端可能還有一 些報文段需要傳送，所以對於客戶端的請求關閉連線只能先回復，你的 FIN我收到了，但是我還有一些資料要傳送你等我傳送完之後，我再給你傳送關閉請求。

2.3.5 簡述 TIME_WAIT和 CLOSE_WAIT⭐️

​ 描述：客戶端收到伺服器端的 FIN 請求的時候進入這個狀態，此時客戶端並不是直接關閉進入 CLOSE 狀態，而是再保持一個2MSL 再進入 CLOSED 狀態。

​ 原因：

​ 1. 確認伺服器端能夠收到客戶端的確認報文，萬一沒有收到，就會重新發送，而此時客戶端已經關閉，那麼伺服器端就會造成資源浪費，無法關閉

​ 2.使本次連線內的所有報文段都消失，下一次的連線內不會出現這一次的報文段。

2.4 TCP 協議如何保證傳輸的可靠性

2.4.1超時重傳(ARQ)

傳送發沒有收到 ACK 那麼會進行重新發送

2.4.2確認應答號和***

2.4.3三次握手四次揮手

2.4.4 流量控制

​ TCP 利用滑動視窗實現流量控制。流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。 接收方傳送的確認報文中的視窗欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將視窗欄位設定為 0，則傳送方不能傳送資料

2.4.5 擁塞控制

• 當我們對網路的吞吐量超過了目前網路所能提供的吞吐量那麼網路效能可能就會變壞

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-8SSiaAlB-1620353895631)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截圖2021-05-03 14.54.10.png)]

2.4.5.1慢開始和擁塞避免演算法

• 慢開始

  1. 目的：用來確定網路的負載能力

  2. 思路：從小到大增加擁塞視窗的數值

  3. 兩個變數：

     ​ 擁塞視窗（cwnd）初始擁塞視窗值

     ​ 慢開始門限（ssthresh）：防止擁塞視窗增長過大引 起網路擁塞。

• 擁塞避免

  1. 思路：讓擁塞視窗 cwnd 緩慢地增大，避免出現擁塞。

  2. 每經過一個傳輸輪次，擁塞視窗 cwnd = cwnd + 1

     [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-kCjqrR8u-1620353895631)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截圖2021-05-03 15.17.10.png)]

2.4.5.2 快重傳和快恢復

• 快重傳：傳送方一旦收到接收方的三個連續的重複確認，就立即重傳，而不是等到重傳計時器超時再重傳，這樣避免了有個別報文段丟失，之前的演算法卻誤以為發生了網路擁塞，降低了效率。

• 快恢復：傳送方一旦收到接收方的三個連續的重複確認，就啟動快恢復演算法而不是慢開始演算法。

2.4.5.3 改進的整體演算法

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-47sxJ2g4-1620353895631)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截圖2021-05-03 15.39.09.png)]

3 傳輸層(HTTP)

3.1 HTTP 報文結構和狀態碼

請求報文結構：

• 第一行是包含了請求方法、URL、協議版本；
• 接下來的多行都是請求首部 Header，每個首部都有一個首部名稱，以及對應的值。
• 一個空行用來分隔首部和內容主體 Body
• 最後是請求的內容主體

GET http://www.example.com/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cache-Control: max-age=0
Host: www.example.com
If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT
If-None-Match: "3147526947+gzip"
Proxy-Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 xxx

param1=1&param2=2

響應報文結構：

• 第一行包含協議版本、狀態碼以及描述，最常見的是 200 OK 表示請求成功了
• 接下來多行也是首部內容
• 一個空行分隔首部和內容主體
• 最後是響應的內容主體

HTTP/1.1 200 OK
Age: 529651
Cache-Control: max-age=604800
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 648
Content-Type: text/html; charset=UTF-8
Date: Mon, 02 Nov 2020 17:53:39 GMT
Etag: "3147526947+ident+gzip"
Expires: Mon, 09 Nov 2020 17:53:39 GMT
Keep-Alive: timeout=4
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Proxy-Connection: keep-alive
Server: ECS (sjc/16DF)
Vary: Accept-Encoding
X-Cache: HIT

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
	// 省略... 
</body>
</html>

狀態碼：

• 200 OK

• 301 Moved Permanently ：永久性重定向

• 302 Found ：臨時性重定向

• 400 Bad Request ：請求報文中存在語法錯誤。

• 401 Unauthorized ：該狀態碼錶示傳送的請求需要有認證資訊（BASIC 認證、DIGEST 認證）。如果之前已進行過一次請求，則表示使用者認證失敗。

• 403 Forbidden ：請求被拒絕。

• 404 Not Found：輸入了錯誤的 URL

• 500 Internal Server Error ：伺服器正在執行請求時發生錯誤。

• 503 Service Unavailable ：伺服器暫時處於超負載或正在進行停機維護，現在無法處理請求。

3.2 GET 和 POST方法

3.3HTTP是不儲存狀態的協議,如何儲存使用者狀態?

​ HTTP 是一種不儲存狀態，即無狀態（stateless）協議。也就是說 HTTP 協議自身不對請求和響應之間的通訊狀態進行儲存。那麼我們儲存使用者狀態呢？Session 機制的存在就是為了解決這個問題，Session 的主要作用就是通過服務端記錄使用者的狀態。典型的場景是購物車，當你要新增商品到購物車的時候，系統不知道是哪個使用者操作的，因為 HTTP 協議是無狀態的。服務端給特定的使用者建立特定的 Session 之後就可以標識這個使用者並且跟蹤這個使用者了

3.4Cookie的作用是什麼?和Session有什麼區別？

cookie：是伺服器傳送到使用者瀏覽器並且儲存在本地的一塊小資料，它會在瀏覽器之後向同一伺服器再次傳送請求時攜帶上，用來告知伺服器端兩個請求是否來自於同一個瀏覽器(服務員給的小卡片)

1. 瀏覽器第一次訪問伺服器，伺服器為它建立一個身份，格式為 key - value，內容放入 set-cookie 欄位裡面
2. 瀏覽器看到這個欄位就會儲存下來，然後下次的時候就會放在 cookie 欄位裡面傳送到伺服器端
3. 伺服器端收到這個請求報文後，相當於身份的識別，就會為它提供個性化的服務

session：儲存在伺服器端，更加安全。過程是借用了 cookie 的傳輸機制

1. 客戶進行登入，瀏覽器進行驗證賬戶和密碼，通過之後，資訊儲存再 redis 裡面，然後裡面有一個 session id
2. 伺服器返回的相響應報文內包含了這個 session id，客戶端收到響應報文後將 cookie 存入瀏覽器
3. 下一次訪問時候攜帶上 sessionid，就可以繼續進行操作

3.5 輸入一個網址發生的事情