Java後端高頻知識點學習筆記8---計算機網路

參考網址：牛 _ 客 _ 網
https://www.nowcoder.com/discuss/819312

1、OSI七層模型

OSI 模型把網路通訊的工作分為 7 層，從下到上分別是物理層、資料鏈路層、網路層、傳輸層、會話層、表示層、應用層

① 物理層
協議：IEEE802.11(無線區域網)
傳輸單位：位元
任務：在物理媒體上為資料端裝置透明地傳送位元流
實現硬體：集線器、中繼器

② 資料鏈路層 **
協議：STP、ARQ、PPP
ARQ：自動重傳請求協議； PPP：點對點協議； STP：生成樹協議
傳輸單位：幀**
任務：將網路層傳來的IP資料報組裝成幀

③ 網路層
協議：IP、ARP、OSPF； ARP:將ip地址轉化為Mac地址； OSPF:路由選擇協議
傳輸單位：資料報
任務：
1、 將傳輸層傳下來的報文段封裝成分組
2、 選擇合適的路由，使得傳輸層傳下來的分組能夠交付到目的主機
實現硬體：路由器

④ 傳輸層
協議：TCP、UDP； TCP：傳輸控制協議； UDP：使用者資料包協議
傳輸單位：報文段（TCP）、使用者資料報（UDP）
任務：
+ TCP：負責主機中兩個程序之間的通訊，為端到端的連線提供可靠的傳輸服務
+ UDP：負責向兩臺主機程序之間的通訊提供通用的資料傳輸服務

⑤ 會話層
任務：不同主機上各程序間的對話

⑥ 表示層
處理在兩個通訊系統中交換資訊的表示方式；主要負責資料格式的轉換，如加密解密、轉換翻譯、壓縮解壓縮等

⑦ 應用層
協議：HTTP、FTP、DNS、SMTP
任務：提供系統與使用者的介面
為應用程式提供互動服務；在網際網路中的應用層協議很多，如域名系統DNS，支援全球資訊網應用的HTTP協議，支援電子郵件的SMTP協議等

2、TCP三次握手和四次揮手

三次握手
為了準確⽆誤地把資料送達⽬標處，TCP協議採⽤了三次握⼿策略。

① 一次握手：客戶端––>服務端； 傳送SYN（請求）報文
② 二次握手：服務端––>客戶端； 收到SYN報文後會傳送SYN+ACK（請求+確認）報文

為什麼要三次握手？

三次握⼿的本質⽬的是建⽴可靠的通訊通道，說到通訊，簡單來說就是資料的傳送與接收，⽽三次握⼿最主要的⽬的就是雙⽅確認⾃⼰與對⽅的傳送與接收是正常的

第⼀次握⼿：Client 什麼都不能確認；Server 確認了對⽅傳送正常，⾃⼰接收正常

第⼆次握⼿：Client 確認了：⾃⼰傳送、接收正常，對⽅傳送、接收正常；Server 確認了：對⽅傳送正常，⾃⼰接收正常

第三次握⼿：Client 確認了：⾃⼰傳送、接收正常，對⽅傳送、接收正常；Server 確認了：⾃⼰傳送、接收正常，對⽅傳送、接收正常
所以三次握⼿就能確認雙發收發功能都正常，缺⼀不可

為什麼不兩次握手 / 為什麼要三次握手要有最後一次SYN+ACK？
客戶端首先向伺服器傳送一個連線請求，但是可能這個連線請求走了遠路，等了很長時間，伺服器都沒有收到，那麼客戶端可能會再次傳送請求並完成連線、資料傳輸、斷開連線；此時伺服器端才收到之前的請求；並且回覆SYN+ACK報文；在這個時候最先發送的那個連線請求到達伺服器，那麼伺服器會回覆一個SYN+ACK報文；但是客戶端表示自己已經不需要進行資料傳輸，並不搭理這個回覆，那麼伺服器可能陷入等待，如果這種情況多了，那麼會導致伺服器癱瘓，所以要三次握手

四次揮手

斷開⼀個 TCP 連線則需要“四次揮⼿”：

1、客戶端不再向伺服器端傳送資料，傳送⼀個 FIN，⽤來關閉客戶端到伺服器的資料傳送

2、伺服器收到 FIN，回覆⼀個 ACK，確認序號為收到的序號加1 。和 SYN ⼀樣，⼀個FIN 將佔⽤⼀個序號

3、伺服器也不再向伺服器端傳送資料；關閉與客戶端的連線，傳送⼀個FIN給客戶端

4、客戶端回覆 ACK報文，並將確認序號設定為收到序號加1

為什麼要四次揮手？

TCP連線是全雙工傳輸，任何⼀⽅既能傳送資料又能接收資料；當 A 沒有資料要傳送時，則發出連線釋放請求（FIN報文），告知 B 自己沒有資料要傳送了，但 B 還可能傳送資料過來，因此 B 先向 A 傳送確認，當 A 接收到 B 的FIN報文，進入半關閉狀態；當 B 也沒有資料要傳送了，B 向 A 傳送連線釋放請求，A 收到釋放請求後傳送確認；對⽅確認後就完全關閉了TCP連線

3、如果建立TCP連線後，客戶端掛了怎麼辦

TCP 協議的保活機制

TCP設有一個保活計時器，伺服器每收到一次客戶端的請求後，都會重新復位這個計時器，時長通常設定為2個小時，如果兩個小時還沒有收到客戶端的任何資料，伺服器就會發送一個探測報文段，以後沒間隔75秒傳送一次，如果一連發了10個探測報文仍然沒響應，伺服器就認為客戶端出了問題，關閉連線

保活機制的原理：在一個時間段內，如果沒有任何連線相關的活動，每隔⼀個時間間隔，傳送⼀個探測報⽂，該探測報⽂包含的資料⾮常少；如果連續⼏個探測報⽂都沒有得到響應，則認為當前的TCP 連線已經死亡，系統核心將錯誤資訊通知給上層應⽤程式

4、TCP和UDP的區別

① TCP是面向連線的傳輸層協議，即傳輸資料之前必須先建立好連線，UDP無連線

② TCP是點對點的兩點間服務，即一條TCP連線只能有兩個端點；UDP支援一對一，一對多，多對一，多對多的互動通訊

③ TCP是可靠的，UDP不可靠

④ TCP有流量控制和擁塞控制保證資料傳輸的安全性；UDP沒有流量控制和擁塞控制，網路擁塞不會影響源主機的傳送效率

⑤ 如果要保證資料的完整性，則應選用TCP協議，像檔案傳輸、重要狀態的更新；如果要保證資料傳輸的實時性，則應選用UDP協議，如視訊傳輸、實時通訊

⑥ TCP傳輸的資料是以位元組流的形式，UDP傳輸的形式是以資料報文段的形式

⑥ TCP首部開銷大，首部最少有20個位元組，UDP首部開銷小，8個位元組

5、TIME_WAIT 和 CLOSE_WAIT

TIME_WAIT狀態發生在客戶端主動關閉連線時，傳送最後一個ack後

CLOSE_WAIT狀態發生在 在Sever端收到Client的FIN訊息並向客戶端傳送ACK後

TIME_WAIT出現的意義？

1、可靠的關閉TCP連線
確保客戶端傳送ACK後能夠讓服務端正常關閉，如果服務端沒有收到客戶端傳送的ACK，服務端就會進行超時重傳，向客戶端重傳FIN報文，如果客戶端關閉了就收不到了，所以客戶端要有2MSL的TIME_WAIT等待時間

2、2MSL能夠保證本次連線的所有報文中網路中消失，避免新舊連線歷史資料錯亂

MSL概念：MSL指的是報文段的最大生存時間，如果報文段在網路中活動了MSL時間，還沒有被接收，那麼就會被丟棄；MSL指一個片段在網路中最大的存活時間，2MSL就是一個傳送和一個回覆所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連線

為什麼要等待2MSL而不是1MSL？

等待 2MSL 的真正目的是為了避免（前後兩個使用相同四元組的連線中的）前一個連線的報文干擾後一個連線，換句話說，就是為了讓此次 TCP 連線中的所有報文在網路中消失

假如現在 A 傳送 ACK 後，最壞情況下，這個 ACK 在 1MSL 時到達 B；此時 B 在收到這個 ACK 的前一剎那，一直在重傳 FIN，這個 FIN 最壞會在 1MSL 時間內消失；因此從 A 傳送 ACK 的那一剎那開始，等待 2MSL 可以保證 A 傳送的最後一個 ACK，和 B 傳送的最後一個 FIN 都在網路中消失

CLOSE_WAIT出現的意義？

答：服務端在被動關閉連線情況下，在已經接收到FIN，但是還沒有傳送自己的FIN的時刻，連線處於CLOSE_WAIT狀態；如果客戶端最後向服務端傳送ACK，服務端沒有收到，那麼服務端將重發FIN報文

TIME_WAIT和CLOSE_WAIT是什麼時候出現的？
1、Client端傳送一個FIN報文給Server端，Client狀態變為FIN_WAIT_1

2、Server端收到FIN後，傳送一個ACK報文給Client端，Server端狀態變為CLOSE_WAIT，Client收到ACK後的狀態變為FIN_WAIT_2

3、Server端也傳送了一個FIN報文給Client端，Server端狀態變為LAST_ACK

4、Client端收到報文FIN後，也傳送一個ACK報文給伺服器。Client狀態變為TIME_WAIT，等待2MSL

5、Server端收到ACK後，Server的狀態變為CLOASED

6、Client等待2MSL之後，Client的狀態也變為CLOSED

TCP報文段

一個TCP報文段分為TCP首部和TCP資料兩個部分，整個TCP段作為IP資料報的資料部分封裝在IP資料報中

TCP報文段首部的前20個位元組是固定的，後面有4N位元組是根據需要而增加的選項

TCP首部的最小長度是20位元組

TCP首部欄位：源埠、目的埠、序號、確認號、資料偏移、保留欄位、緊急位URG、確認位ACK、推送位PSH、復位位RST、同步位SYN、終止位FIN、視窗欄位、檢驗和、緊急指標欄位、選項欄位、填充欄位

7、UDP資料報

UDP資料報包含兩個部分：UDP首部和使用者資料；整個UDP資料報作為IP資料報的資料部分封裝在IP資料報中

UDP首部有8個位元組，由4個欄位組成，每個欄位的長度都是2個位元組

UDP首部欄位：源埠、目的埠、長度、校驗和

UDP首部有8個位元組，由4個欄位構成，每個欄位都是兩個位元組
1、源埠： 源埠號，需要對方回信時選用，不需要時全部置0
2、目的埠：目的埠號，在終點交付報文的時候需要用到
3、長度：UDP的資料報的長度（包括首部和資料）其最小值為8（只有首部）
4、校驗和：檢測UDP資料報在傳輸中是否有錯，有錯則丟棄。
該欄位是可選的，當源主機不想計算校驗和，則直接令該欄位全為0

當傳輸層從IP層收到UDP資料報時，就根據首部中的目的埠，把UDP資料報通過相應的埠，上交給應用程序；如果接收方UDP發現收到的報文中的目的埠號不正確（不存在對應埠號的應用程序），就丟棄該報文，並由ICMP傳送“埠不可達”差錯報文給對方

8、TCP協議如何保證可靠傳輸

TCP協議保證資料傳輸可靠性的方式主要有：校驗和、序列號、確認應答、超時重傳、連線管理、流量控制、擁塞控制

① 校驗和

傳送方在傳送資料之前計算檢驗和，並進行校驗和的填充；接收方在收到資料後，對資料以同樣的方式進行計算，求出校驗和，與傳送方的進行比對

如果接收方比對校驗和與傳送方不一致，那麼資料一定傳輸有誤；但是如果接收方比對校驗和與傳送方一致，資料不一定傳輸成功

② 序列號和確認應答

序列號：TCP傳輸時將每個位元組的資料都進行了編號，這就是序列號。

確認應答：TCP傳輸的過程中，每次接收方收到資料後，都會對傳輸方進行確認應答，也就是傳送ACK報文；這個ACK報文當中帶有對應的確認序列號，告訴傳送方，接收到了哪些資料，下一次的資料從哪裡發

序列號的作用不僅僅是應答的作用，有了序列號能夠將接收到的資料根據序列號排序，並且去掉重複序列號的資料。這也是TCP傳輸可靠性的保證之一

③ 超時重傳

傳送方在傳送完資料後等待一個時間，時間到達沒有接收到ACK報文，那麼對剛才傳送的資料進行重新發送

④ 連線管理

連線管理就是三次握手與四次揮手的過程，保證可靠的連線，是保證可靠性的前提

⑤ 流量控制

如果傳送方把資料傳送得過快，接收方可能會來不及接收，這就會造成資料的丟失；流量控制就是讓傳送方慢點，要讓接收方來得及接收

⑥ 擁塞控制

擁塞控制就是防止過多的資料注入到網路中，造成 網路擁塞的情況；若出現擁塞而不進行控制，整個網路的 吞吐量 將隨輸入負荷的增大而下降

9、滑動視窗和流量控制

TCP 利⽤ 滑動窗⼝ 實現流量控制。流量控制是為了控制傳送⽅傳送速率，保證接收⽅來得及接收；接收⽅傳送的 確認報⽂ 中的 窗⼝欄位 可以⽤來控制傳送⽅窗⼝⼤⼩，從⽽影響傳送⽅的傳送速率；若將窗⼝欄位設定為 0，則傳送⽅不能傳送資料

10、流量控制和擁塞控制

流量控制：如果傳送方把資料傳送得過快，接收方可能會來不及接收，這就會造成資料的丟失；流量控制就是讓傳送方慢點，要讓接收方來得及接收

擁塞控制：擁塞控制就是防止過多的資料注入到網路中，這樣可以使網路中的路由器或鏈路不致過載

TCP流量控制解決方法
TCP的流量控制是利用滑動視窗機制實現的，接收方在返回的資料中會包含自己的接收視窗的大小，以控制傳送方的資料傳送

TCP擁塞控制解決方法
TCP擁塞控制的四種演算法：慢開始、擁塞避免、快重傳、快恢復

慢開始演算法：當主機開始傳送資料時，並不清楚網路的負載情況，所以由小到大逐漸增大擁塞視窗，每經過一個傳輸輪次沒有出現超時就將擁塞視窗加倍。同時還需要設定一個慢開始門限，在擁塞視窗小於慢開始門限時使用慢開始演算法，大於慢開始門限時，使用擁塞避免演算法；

擁塞避免演算法：在擁塞視窗大於慢開始門限時，讓擁塞視窗按線性規律緩慢增長。即每經過一個傳輸輪次，擁塞視窗增大一個MSS最大報文段尺寸。（擁塞避免並非完全能夠避免擁塞，只是使網路比較不容易出現擁塞）

快重傳演算法：使傳送方早知道發生了個別報文段丟失，並不是出現網路擁塞；要求接收方不要等自己傳送資料時才進行捎帶確認，而是立即傳送確認；即使收到了失序的報文段也要立即發出對已收到報文段的重複確認

而傳送方一旦收到三個連續的重複確認，就將相應的報文段立即重傳，二不是等該報文的超時重傳計時器超時再重傳

假設該3號報文丟失，接收方不會發送針對該報文的確認報文給傳送方，傳送方還可以將傳送視窗內的4號資料報文段傳送出去，接收方收到後，發現這不是按序到達的報文段，因此給傳送方傳送針對2號報文段的重複確認，表明我現在希望收到的是3號報文段，但是我沒有收到3號報文段，而收到了未按序到達的報文段，傳送方還可以將傳送視窗中的5號報文段傳送出去,接收方收到後，發現這不是按序到達的報文段，因此給傳送方傳送針對2號報文段的重複確認，表明我現在希望收到的是3號報文段，但是我沒有收到3號報文段，而收到了未按序到達的報文段,，傳送方還可以將傳送視窗內的最後一個數據段即6號資料報文段傳送出去，接收方收到後，發現這不是按序到達的報文段，因此給傳送方傳送針對2號報文段的重複確認，表明我現在希望收到的是3號報文段，但是我沒有收到3號報文段，而收到了未按序到達的報文段，

快恢復演算法：傳送方知道只有個別報文段丟失而不是網路擁塞時，不啟動慢開始演算法，而是執行快恢復演算法，將慢開始門限和擁塞視窗值調整為當前視窗的一半，開始執行擁塞避免演算法

11、在瀏覽器中輸入url後執行的全過程，會用到哪些協議

開啟⼀個⽹⻚，整個過程會使⽤哪些協議？

總體來說分為以下幾個過程：

① 瀏覽器查詢域名的IP地址
② 瀏覽器向web伺服器傳送一個HTTP請求
③ 伺服器處理請求
④ 伺服器返回一個HTML響應
⑤ 瀏覽器解析渲染頁面

12、域名解析

域名解析是指把域名對映成為IP地址或把IP地址對映成為域名的過程；前者稱為正向解析，後者稱為反向解析

當客戶端需要域名解析時，通過本機的DNS客戶端構造一個DNS請求報文，以UDP資料報方式發往本地域名伺服器

① 檢查瀏覽器快取中是否快取過該域名對應的IP地址

② 如果在瀏覽器快取中沒有找到IP，將繼續查詢本機系統是否快取過IP

③ 向本地域名伺服器發起域名解析請求

④ 如果本地域名伺服器的本地快取中沒有該域名對應的ip，則將DNS客戶端的身份向根域名伺服器發出解析請求

⑤ 根域名伺服器收到請求後，經過判斷後，將對應的頂級域名伺服器的IP地址返回給本地域名伺服器

⑥ 本地域名伺服器向頂級域名伺服器發出解析請求報文

⑦ 頂級域名伺服器收到請求後，經過判斷，將對應的授權域名伺服器的IP地址返回給本地域名伺服器

⑧ 本地域名伺服器向授權域名伺服器發起解析請求報文。

⑨ 授權域名伺服器收到請求後，將查詢結果返回給本地域名伺服器。

⑩ 本地域名伺服器將查詢結果儲存到本地快取，同時返回給客戶端

13、Http狀態碼

HTTP狀態碼由三個十進位制數字組成，第一個十進位制數字定義了狀態碼的型別，後兩個數字沒有分類的作用

HTTP狀態碼共分為5種類型：

① 1xx：伺服器接收到請求，需要請求者繼續執行操作

② 2xx：伺服器成功處理了請求

③ 3xx：重定向 （需要進一步的操作以完成請求）

④ 4xx：客戶端錯誤 （請求包含語法錯誤或無法完成請求）

⑤ 5xx：伺服器錯誤 （伺服器在處理請求的過程中發生了錯誤）

常見的狀態碼：

200：表示從客戶端傳送給伺服器的請求被正常處理並返回。

301：永久重定向

302：臨時重定向

303：表示請求的資源被分配了新的URL，應使用Get的方法定向獲取請求的資源

302和303的區別：303明確表示客戶端應當採用Get方式獲取資源

404：表示伺服器上無法找到請求的資源，除此之外，也可以在伺服器拒絕請求但不想給拒絕原因時使用

500：表示伺服器在執行請求時發生了錯誤，也有可能是web應用存在的bug或某些臨時的錯誤時

503：表示伺服器暫時處於超負載或正在進行停機維護，無法處理請求

14、HTTP和HTTPS的區別

① Http資訊是明文傳輸不安全，HTTPS是具有安全性的SSL加密傳輸協議

② http和https使用的是完全不同的連線方式，用的埠也不一樣，Http埠是80，Https埠是443

③ Http不需要申請證書，Https需要到證書頒發機構申請證書

④ Https協議是由SSL+HTTP協議構建的可進行加密傳輸，身份認證的網路協議，比Http協議安全

⑤ HTTP 安全性沒有 HTTPS⾼，但是 HTTPS ⽐HTTP耗費更多伺服器資源

15、get和post區別

① Get的引數通過URL傳遞，Post的引數放在Request body中

② Get的引數直接暴露再URL上，不能用來傳輸敏感資訊，而Post較安全

③ Get請求在URL中傳送的引數是有長度限制的，而Post沒有

④ Get請求是冪等性的，Post請求不是冪等性的（冪等性：對同一個URL的多個請求應該返回相同的結果）

⑤ GET請求引數會被完整保留在瀏覽器歷史記錄裡，而POST中的引數不會被保留

16、cookie和session的區別

① cookie存放在客戶端，session存放在服務端

② cookies不安全，session是安全的

③ session依賴於cookie

④ cookie有儲存容量限制，session沒有（單個cookie儲存的資料<=4KB，一個站點最多儲存20個cookie）

⑤ cookie只能儲存ASCII型別的資料 ,session可以儲存任意型別的資料

17、轉發與重定向的區別

轉發（forward）：由服務端進行頁面跳轉；位址列不發生變化，顯示的是上一個頁面的地址，只有一次請求

重定向（Redirect）：由瀏覽器端進行頁面的跳轉；位址列顯示新的地址，有2次請求。

區別：

① 轉發是伺服器收到請求後為了完成響應跳轉到一個新的地址；重定向是瀏覽器向伺服器傳送一個請求並收到響應後再次向一個新地址發出請求；轉發是服務端的行為，重定向是客戶端行為

② 轉發請求一次，重定向至少請求兩次

③ 轉發一次請求共享資料，重定向兩次請求不共享資料

④ 轉發位址列不會發生改變，重定向位址列發生變化

⑤ 轉發只能跳轉到本站點資源，重定向可以跳轉到任意URL

18、HTTPS執行過程

HTTPS在傳輸的過程中會涉及到三個金鑰：

① 伺服器端的公鑰和私鑰，用來進行非對稱加密

② 客戶端生成的隨機金鑰，用來進行對稱加密

一個HTTPS請求實際上包含了兩次HTTP傳輸，如下圖可以細分為以下8步：

1、客戶端向伺服器發起HTTPS請求，連線到伺服器的443埠

2、伺服器端有一個金鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的；伺服器端儲存著私鑰，不能將其洩露，公鑰可以傳送給任何人

3、伺服器將自己的公鑰傳送給客戶端

4、客戶端收到伺服器端的公鑰之後，會對公鑰進行檢查，驗證其合法性，如果發現發現公鑰有問題，那麼HTTPS傳輸就無法繼續

嚴格的說，這裡應該是驗證伺服器傳送的數字證書的合法性

如果公鑰合格，那麼客戶端會生成一個隨機值，這個隨機值就是用於進行對稱加密的金鑰，我們將該金鑰稱之為client key，即客戶端金鑰；然後用伺服器的公鑰對客戶端金鑰進行非對稱加密，這樣客戶端金鑰就變成密文了，至此HTTPS中的第一次HTTP請求結束

5、客戶端會發起HTTPS中的第二個HTTP請求，將加密之後的客戶端金鑰傳送給伺服器。

6、伺服器接收到客戶端發來的密文之後，會用自己的私鑰對其進行非對稱解密，解密之後的明文就是客戶端金鑰，然後用客戶端金鑰對資料進行對稱加 密，這樣資料就變成了密文。

7、然後伺服器將加密後的密文傳送給客戶端。

8、客戶端收到伺服器傳送來的密文，用客戶端金鑰對其進行對稱解密，得到伺服器傳送的資料。這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成