計算機網絡基礎+HTTP知識點總結

1.什麼是DHCP？執行流程？

DHCP就是動態主機配置協議。作用就是爲新加入網絡中的主機分配一個合法的ip地址。

當一臺主機新加入網絡中時，它只持有自身的MAC地址，還沒有ip地址，此時它會發出一個DHCP Discover，具體的做法就是發送一個廣播包，源IP地址是0.0.0.0，目的IP地址是255.255.255.255，並且使用UDP進行傳輸。

DHCP server接受到這個請求後，就會爲當前主機分配一個ip地址，並且同樣通過UDP進行回傳，這個過程叫做DHCP offer

主機收到DHCP offer後，還需要發起一次確認。因爲有可能不止一個DHCP爲它分配ip，所以它完全有可能收到多個offer，那麼主機一般來說會選擇第一個到達的DHCP offer來使用。然後會給這些DHCP server分別發送一個DHCP request，用來表明自己將要接受的ip。提供此ip的DHCP server就會發送DHCP ACK消息包來確認。那麼主機就成功分配到一個ip地址，加入到網絡之中了。

2.說一下TCP的三次握手？爲什麼是三次？二次不行嘛？

大寫：xx控制塊 seq：初始序號 ack：確認序號

因爲TCP是面向連接的可靠傳輸，所以在傳輸之前必須經過三次握手建立連接，具體的流程就是：

建立連接就需要有客戶端和服務端嘛，一開始的時候客戶端處於CLOSED狀態，而服務端處於LISTEN狀態等待客戶端的連接

1）客戶端發送一個連接請求，其中包含同步控制位SYN=1，挑選一個隨機的傳輸數據信號seq=x。然後客戶端從CLOSED態轉爲SYN_SENT態，等待服務端的迴應

2）服務端收到連接請求後，如果同意連接，就會給客戶端發回一個確認請求，其中就包括同步控制位SYN=1和確認控制位ACK=1，請求信號ack=x+1,隨機挑選一個傳輸數據信號=y。且服務端從LISTEN狀態轉化爲SYN_RCVD狀態。

3）客戶端收到服務端的確認請求，然後發送二次確認，請求中包含ACK確認控制位，以及請求信號ack=y+1。然後客戶端轉爲ESTABLISHED狀態

4）服務端接受到客戶端發來的二次請求。於是也轉爲ESTABLISHED狀態，連接正式建立了

之所以是三次握手，是因爲防止某個已經過期的連接請求突然又到達服務端，造成資源浪費的現象。

比如說客戶端向服務端發送一個連接請求，但這個連接請求因爲種種原因比如說網絡堵塞，沒有按時到達服務端，此時客戶端等待一個超時重傳時間後便會重新開始發送連接請求，然後連接成功進行數據傳輸，然後再斷開連接。此時最開始的連接請求終於到達了服務端，若沒有客戶端的二次確認也就是第三次握手的話，此時服務端就會直接打開連接，這個資源就被白白浪費了。

3.說一下TCP的四次揮手？最後爲什麼要等待一個超時時間？

TCP四次揮手是TCP斷開連接的過程。

首先在斷開連接之前，客戶端和服務端都是處於ESTABLISHED狀態。

1）客戶端發送一個斷開連接的請求，請求包含一個結束控制位FIN=1，隨機選取一個值作爲數據發送信號seq=x，然後客戶端從ESTABLISHED狀態轉化爲FIN_WAIT的第一狀態。客戶端發出這個請求的語義就是：自己已經沒有其他數據要傳輸了，即將準備關閉連接，但是服務端還可以進行傳輸，客戶端也可以進行接受

2）服務端接受到請求後，發送一個確認信號，其中包含了一個ACK確認控制位=1，隨機選取一個數據發送信號seq=y，ack請求信號=x+1。然後從ESTABLISHED態轉化爲CLOSE_WAIT狀態。

3）客戶端接受到這個確認信號後，從FIN_WAIT的第一狀態轉化爲第二狀態。然後此時服務端可以完成剩下的數據發送，客戶端進行接受

4）當服務端傳送完所有數據後，此時就真的可以準備關閉連接了。服務端發送一個斷開連接請求，其中包含FIN控制位=1，確認控制位ACK=1，再隨機選取一個數作爲數據傳輸信號seq=v，請求字段ack=x+1，並且自身進入LAST_ACK狀態，等待客戶端的確認信號

5）客戶端收到信號後，最後發送一個確認信號，包含ACK確認控制位=1，，然後等待一個超時時間後，進入CLOSED狀態。

6）服務端收到客戶端的確認信號，然後就進入CLOSED狀態，連接斷開。

最後客戶端等待一個超時時間主要有兩個原因：

• 爲了防止確認信號丟失，導致服務端無法關閉：如果客戶端發送完確認信號就直接進入CLOSED狀態的話，如果這個確認信號丟失了，那麼服務端就無法接收到，所以服務端就無法被關閉。等待一個超時時間就是爲了避免這樣的情況發生
• 使本次連接產生的一些請求儘可能在網絡中耗盡，防止干擾下一次連接的請求傳遞。

4.TCP協議如何保證傳輸的可靠性？

因爲網絡層並沒有提供可靠傳輸，所以數據正確性要在傳輸層中得到保證。

• 數據包檢驗：TCP接受端在接受數據包時需要對數據包的正確性進行檢驗，若發現有錯誤發生，則把該數據包丟棄然後什麼都不做，發送端等待一個超時重傳時間後就會重新發送該數據包。
• 丟失重複數據：每個數據包都會有一個編號，如果接受端發現收到的編號有重複的話。
• 超時重傳機制：因爲TCP接受端在成功接受到數據塊之後必須向發送端發出一個確認信號，來通知傳輸的成功。所以說發送端如果在一個時間內沒有接受到接受端的確認信號，就會認爲此次發送失敗，進行重傳
• 流量控制和擁塞控制：流量控制主要是協調發送端和接受端的發送窗口大小，讓接受端傳回receive windows信號來限制發送端的窗口大小。而擁塞控制是用來協調發送端接受端的發送窗口要根據網絡情況進行調整。分爲慢開始-擁塞避免，和快重傳-快開始

5.說一下TCP的流量控制？

TCP的流量控制主要是爲了協調發送端和接受端的傳輸速度，避免出現發送太快而來不及接收，導致大量數據塊丟失的情況發生。

TCP主要是通過滑動窗口來解決這個問題的。

對於發送端來說，滑動窗口的實現由三個指針構成，其中兩個指針就劃定了窗口的範圍，而中間一個指針指示的是已發送字節與未發送字節的一個界限。那隨着字節發送，這個指針會不斷向右邊移動，直到它和窗口邊緣重合時，就無法繼續發送了，此時如果接受端發回一個確認信號，整個窗口纔可以向右移動

對於接受端來說，同樣有一個接受窗口，並且和傳統的停止等待方法不一樣的是，接受端並不需要對每一個成功接受的字節都發回一個確認信號，只需要發送成功接受的所有字節中的最後一個字節就可以了。比如發回的確認信號中確認序號ack=201，說明201之前的所有字節都已經成功接受了，下一次從201開始發送就可以。另外信號中還會有一個receive window序號，它就是真正用來控制發送端窗口大小的，比如說這個字段爲300，那麼發送端接受到之後就會把自己窗口大小調整爲300.

6.說一下TCP的擁塞控制？

TCP的擁塞控制主要是從網絡擁塞情況的角度去協調發送端和接受端的窗口值。TCP擁塞控制主要有兩種，一種是叫慢開始-擁塞避免算法 一種是叫快重傳-快開始算法

慢開始-擁塞避免算法：這個算法會設置一個慢開始門限，默認值爲16，初始窗口大小設爲1；當窗口大小小於慢開始門限時，窗口大小是指數級增長的。而在超過慢開始門限後，增長速度變慢，開始使用擁塞避免算法了，也就是每次只增長1，但是一直增長下去，也總有發生網絡阻塞的時候，當發生網絡阻塞時；窗口值又被重新設爲1，然後慢開始門限被更新爲發生阻塞時窗口值的一半，然後繼續進行增長；之所以說慢開始，是因爲發生阻塞之後，窗口被初始化爲了1.

快重傳-快開始：快重傳說的是，當發送端連續三次收到了同樣的確認信號，說明有數據丟失了，此時無需等待超時等待的時間，就直接進行數據重傳了，這就是快重傳。而這個方法同樣也需要維護一個慢開始門限，也是按照同樣的增長方法；當發送端連續三次收到了同樣的確認信號，就直接執行快重傳，然後將慢開始門限設置爲當前窗口值的一半，然後讓窗口值更新爲和慢開始門限一樣，然後繼續執行阻塞避免。快開始就體現在發生重傳之後，窗口值不需要回到1，而是從慢開始門限開始繼續增長

7.什麼是DDos攻擊？如何預防？

DDos攻擊就是客戶端不斷地向服務端發送連接請求，並且服務端會爲每一個請求創建一個連接，並且發送確認數據包，並等待客戶端的二次確認。製造大量的客戶端連接請求就可以加大服務端的負載，實現DDos攻擊

預防：

1.限制服務端打開半連接的數目

8.如果三次握手中的第三次握手失敗了，會怎麼樣？

如果第三次握手失敗了，客戶端仍然會處於ESTABLISHED，也就是連接建立的狀態，而服務端會處於SYNC_RCVD狀態。如果服務端等待一次超時重傳時間後仍然沒有接受到客戶端的確認，會重新發送帶有同步控制塊SYN和確認控制塊ACK的數據包，也就是重新進行第二次握手。當然會有重傳上限次數，在Linux中可以進行參數的修改，默認的是5次。如果五次重傳依然不成功，那麼服務端就會關閉這個連接了。

而對客戶端來說，它在進行完第二次握手後就已經處於連接狀態了，只有當服務端重新發來確認數據包的時候，客戶端才能意識到第三次握手失敗

9.GET和POST的區別？

• 從功能上來說，GET請求一般是用來從服務器上獲取資源，而POST請求是更新服務器上的資源
• 從請求參數上來說。GET請求會將請求參數拼接到URL後，也就是會將請求參數寫在請求頭中，以？來分割URL和請求參數。如果參數是中文或者其他字符的話，還需要使用BASE64進行加密，得出如%E4%BD%A0%E5%A5%BD這樣的格式。而%後面所跟的就是該字符的ASCLL碼的16進製表示。而POST請求來說，它會將請求參數包裝在請求體中，所以相對於GET請求來說更加安全。
• 從大小來看。因爲GET請求會將請求參數拼接到URL後，並且瀏覽器和服務器對URL的長度會有限制，所以GET請求發送的數據量比較小；而POST請求的參數包裝在請求體中，沒有大小限制
• GET請求只能支持ASCLL字符，如果傳遞中文字符可能會出現亂碼；POST請求標準字符集，可以正確傳遞中文字符

10.TCP和UDP的區別？

TCP和UDP都是傳輸層的協議，它們的區別是：

• TCP是面向連接的，在進行數據傳輸的前後必須要進行連接的創建和釋放；而UDP是無連接的，無需創建連接就可以直接進行數據傳輸
• TCP是可靠傳輸；TCP必須保證傳輸的每個數據都能準確無誤地被接受，所以接受端在收到數據塊之中，必須還回傳一個確認信號。TCP使用像數據包檢驗，超時重傳，流量控制，擁塞控制等方法來保證可靠傳輸；而UDP是不可靠傳輸，在接受到數據之後，不需要回傳任何信息，所以發送端也不知道數據塊是否被成功接收到
• TCP是面向字節流的。也就是說對於TCP來說處理的數據是字節流，自己只是把字節流劃分爲大小不同的各個數據塊。而UDP是面向報文的，也就是說，UDP對從應用層獲得的報文不會作任何處理，只是簡單地加上UDP首部就可以進行傳輸。

11.從瀏覽器輸入一個網址到獲得頁面的過程?

1）從瀏覽器輸入一個URL，那麼就會以依此從瀏覽器緩存，主機緩存，本地域名服務器中查看是否有對應的DNS緩存，如果有的話，就直接獲得該域名對應的IP地址；否則的話就要以一個遞歸的方式進行DNS解析，具體的流程就是先去獲取根域名地址，然後獲取一級域名地址，最後一步步獲得該域名對應的IP地址

2）獲取到IP地址後，在傳輸層進行端口號的配置，然後通過三次握手建立TCP連接

3）TCP連接建立起來之後，瀏覽器向服務器發送HTTP請求。

4）接下來就是網絡層的工作，網絡層的主要工作就是去按照路由表去選擇最佳的路由路徑。當然這個工作不只會進行一次，在路由器間的每次跳轉都會執行這個過程。路由選擇協議一般有RIP（基於距離向量的路由選擇協議）和OSPF（基於最短路徑的路由選擇協議。這裏的最短路徑綜合了時延，帶寬等因素的最短，而不僅僅是跳數）

5）接下來就是使用ARP協議根據IP地址獲取MAC物理地址了，解析出MAC物理地址後，在鏈路層封裝成幀，然後交付物理層進行運輸

6）服務端接受到請求後，將請求的資源進行返回。

7）瀏覽器獲取到請求的資源，根據這些資源和數據渲染頁面，最後向用戶呈現一個完整的頁面

12.ARP協議工作原理

ARP協議是網絡層的一個協議，它的作用就是完成一個局域網內IP地址與MAC物理地址的一個映射。

首先，每臺主機都會維護一個ARP高速緩存，其中存放着本局域網內一部分結點的IP地址與MAC地址的映射。當源主機有一個數據包需要發送到目的主機時，首先會查看主機的ARP高速緩存下是否有對應的映射關係，如果有的話可以直接完成轉化。如果沒有，源主機會發起一個ARP請求的廣播包，廣播到當前局域網內的所有主機中，每個主機都會查看請求中的目的IP和自己的IP是否相同，如果不相同則直接忽視，如果相同，那麼目的主機首先會將源主機的IP地址和MAC地址記錄到自己的緩存中，然後通過單播向源主機發送ARP響應數據包，然後源主機就會記錄下這個映射關係。如果源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗

13.OSI七層模型瞭解嗎？

OSI七層模型是國際標準組織提出的一種網絡參考模型，對比常見的TCP/IP五層模型，它在傳輸層和應用層之間多了表示層和會話層這兩層。在TCP/IP五層模型中，這兩層實際上是歸入了應用層中。

那表示層的作用就是確保不同類型的主機可以完成通信。具體的操作包括對數據進行壓縮和解壓，語言翻譯，在安全層面上來看，對數據進行加密和解密。比如HTTPS的安全保證就在這一層完成

會話層負責維護網絡中結點之間的通信會話。

這兩個再加上應用層可以稱爲這個網絡模型中的資源子網，而下面四層可以稱爲通信子網

14.TCP/IP四層模型瞭解嗎？

TCP/IP四層模型就是應用層，傳輸層，網絡層，接口層。它和最常見的五層模型相比呢，就是將鏈路層和物理層合併成爲了接口層

15.你知道對稱加密和非對稱加密嗎？

對稱加密就是說對數據的加密和解密使用的是同一個密鑰。也就是說通信一方會生成一個密鑰用於對於數據進行加密，加密完成後，會將該密鑰發送給通信另一方。通信另一方接收到密鑰後，就可以以此來對信息進行解密

• 優點：實現簡單，而且速度快
• 缺點：對稱加密最大的問題就是密鑰的傳輸，密鑰在網絡中進行傳輸這個過程依然是有風險的，可能會被黑客攔截下來。所以說對稱加密的安全性不太高

非對稱加密就是說數據的加密和解密用的是不同的密鑰，並且只有同一對密鑰纔可以對消息進行加密解密。通信一方會生成兩個密鑰，一個作爲私鑰自己報關，另外一個作爲公鑰發送通信另一方，通信另一方用公鑰對消息進行加密後併發送，持有私鑰的一方就可以使用私鑰對數據進行解密

• 優點：安全性得到了很好的保障
• 缺點：速度相對於對稱加密來說較慢

16.HTTP和HTTPS有什麼區別？

http是超文本傳輸協議，並且它是明文傳輸，也就是說如果有第三方將http請求攔截下來，是可以直接讀懂請求內容的。所以不適用於用來傳輸一些敏感信息。

https是安全，使用ssl來驗證客戶端和服務端的身份，並且可以對傳輸數據進行加密。具體的做法就是使用對稱加密與非對稱加密混合，再加上第三方證書來完成。

• 首先客戶端用https的URL去訪問服務器，請求建立SSL連接。這個請求包括用來識別身份的客戶端證書，客戶端支持支持的SSL版本，以及可以使用的加密算法。
• 服務端收到連接後，確認證書無誤後，會生成一對非對稱加密的密鑰，然後第三方證書機構使用密鑰對其中的公鑰進行加密，然後生成一個公鑰數字簽名證書，服務端將這個證書發送給客戶端
• 客戶端接受到之後，首先要對數字簽名進行檢驗，瀏覽器一般有內置的證書私鑰，無需從其他地方獲取，使用私鑰對數字簽名進行解密並驗證，驗證通過後（爲了防止中間人將公鑰進行了替換）。生成一個對稱加密的密鑰，然後使用傳過來的公鑰對這個密鑰進行加密之後，發送給服務端。
• 服務端收到之後，使用非對稱加密的私鑰對密鑰進行解密，那麼就獲得了雙方進行通信的這個對稱密鑰了。此後就可以進行通信

區別：

• HTTP它是明文傳輸，是不安全；而HTTPS具有SSL加密傳輸協議
• 所使用的端口不一樣，HTTP使用80端口，而HTTPS使用443端口
• HTTPS需要進行一些額外的加密解密以及驗證操作，所以速度比較慢
• HTTPS需要申請CA證書，這個證書是第三方的，所以需要支付費用

17.常用的HTTP方法說一下？

• GET：用於請求資源，它的請求參數會拼接到URI上，所以有長度限制
• POST：用於向服務器傳輸數據，請求參數會在報文請求體上，而不會在URI上
• PUT：用於傳輸文件，文件內存在報文主體上，保存到對應URI位置
• DELETE：用於刪除文件，和PUT方法相反。
• HEAD：和GET有點類似，但它只會獲取報文首部，一般用來檢查URI的有效性以及資源更新時間
• OPTION：查詢對應URI所支持的一些HTTP方法，在應答報文上的首部會有一個Allow字段，後面就跟着所有支持的HTTP方法

18.HTTP1.1版本新特性

• 1.提供持久連接：在1.1之前的版本，每次連接只能進行一次請求；比如說假設我請求一個html文件，其中除了文件之外裏面還有兩個圖片資源，那麼在以前的版本就要進行三次TCP連接的創建與銷燬。這是一個很浪費資源的操作。在1.1版本開始就默認持久連接，也就是一次連接可以進行多次請求，只要客戶端和服務端任意一端沒有明確要斷開連接，連接就可以保存下去。其實1.0的版本也可以進行持久連接，但是沒有在規範裏面，而1.1只是將它加入了規範之中，成爲了一種默認情況
• 管線化：就是連續發送多個請求，而不需要一個個等待迴應。
• 斷點續傳：客戶端從服務端中下載資源，進行到一半的時候發生了網絡中斷，下次重連的時候只需要繼續傳輸剩下的片段即可。實現原理就是客戶端請求報文首部會有一個Range字段，它指示了已經下載的字節數，那麼服務端收到之後直接傳輸接下來的內容即可。當然還會有一個版本號，防止在這期間文件進行了更新。

19.Cookie和Session的區別？

Cookie和Session可以說都是對HTTP功能的一個拓展。因爲HTTP是無連接的，也就是說只要連接關閉之後，是無法記憶之前發生的請求或者響應狀態的，但是很多時候都需要實現這種類似於持久化的功能。所以就有了Cookie和Session。

Cookie其實就是一個文本信息，儲存在客戶端瀏覽器中。在客戶端和服務端進行通信時，如果需要設置Cookie，服務端就會發回一個響應報文，它的首部就會有一個字段叫做setCookie，客戶端收到此報文後就會在瀏覽器上設置對應的Cookie，下次連接請求時，會把Cookie信息也發送過去，服務端收到這個Cookie。Cookie的作用主要有兩種吧，一種是和Session搭配使用，用來在服務器上追蹤Session，然後Session追蹤會話狀態。還有一種是可以作一種緩存的功能，比如說像自動登陸這樣的功能。可以直接在前端的js上獲取Cookie的內容進行拼接到請求體中

Session它是存在於服務端上的，服務端就以一個類似於HashMap的格式去儲存多個Session。當客戶端發出請求時，就會去查看有沒有攜帶着一個叫SessionId的Cookie，如果沒有的話，說明這是第一次進行通信嘛，那麼服務端就會生成對應的Session和SessionId來儲存用戶狀態，然後通過在迴應報文在客戶端上設置對應的Cookie。那麼客戶端下一次訪問的時候就可以直接查找到對應的Session了

區別：

• Cookie存放在客戶端瀏覽器上，而Session存放在服務端上；所以Session數量過多會對服務端帶來負擔。
• Cookie是不安全的，有一種可能就是別人將瀏覽器上Cookie轉移走，僞裝自己的身份來訪問網站。
• 如果對安全性要求較高，可以使用Session；如果是對服務端資源比較緊缺的話可以使用Cookie

20.HTTP緩存機制你瞭解嘛？

HTTP緩存機制有三個主體：客戶端瀏覽器，緩存數據庫，服務端。

HTTP緩存分爲兩類：強緩存和協商緩存

強緩存的機制很簡單：客戶端發出請求時首先去查看緩存數據庫是否有對應的資源，如果沒有的話，就直接去查詢服務端，如果響應報文首部的cache-control字段是public的話，就會在緩存數據庫中記錄這個資源，然後響應碼是200；如果緩存數據庫中有對應資源且未過期的話，就會直接使用緩存數據庫中的資源，並且響應碼是304.

協商緩存。如果緩存數據庫中對應的資源已經過期，或者報文首部明確指定每次從緩存中獲取資源都需要去服務端進行驗證，並且不允許使用舊數據的話，就要使用協商緩存。協商緩存的機制就是：發出請求後查看緩存數據庫中對應的資源是否已過期，如果已經過期，就要發送一個HEAD請求到服務端中，查看對應資源是否已經被修改過，如果被更新過的話，就需要從服務端獲取一個新值，如果沒有更新過，則直接使用緩存數據庫的值。

21.Token是什麼？和Cookie比起來的優勢？

token是一種無狀態持久機制。也就是說服務端在生成token並且發送給客戶端之後，服務端本身不需要做一些額外的記錄。所以和Cookie比起來，token可以一定程度上降低服務端的開銷。因爲Cookie很多時候是配合Session一起使用的嘛，Session儲存在服務端，會加大服務器壓力。

那token的工作流程就是：首先客戶端建立鏈接訪問服務端的資源，服務端對客戶端的權限校驗通過後，就會生成一個對應的token，然後服務端使用一個私鑰在token上添加一個數字簽名。這樣就可以防止第三方惡意製作虛假的token。客戶端接收到這個token後，既可以把它存放在本地儲存中，也可以存放在cookie中，之後客戶端發出的每次請求都要攜帶這個token，服務端對這個token進行檢驗，通過之後客戶端就可以直接訪問對應的資源

對比cookie：

• token是無狀態的，也就是說服務端在生成token之後不需要進行額外的處理；而使用cookie的話一般還要先在服務端生成session並儲存。所以token可以減少服務端壓力
• token可以在多個服務之間進行共享。而使用cookie和session的話，如果服務端使用了負載均衡的架構的話，可能還需要進行一些額外的處理，比如說用一個redis來統一管理這些session

22.HTTP如何傳輸大文件

有幾個方法：

• 數據壓縮。客戶端在發出請求時，請求報文首部有一個叫做Accept-Encoding字段，上面列舉着客戶端支持的壓縮方式，比如gzip，br。服務端接收到之後會選擇其中一種方式對數據進行壓縮。但缺點是這種方式只能對文本數據進行壓縮，如果是音頻或者圖像的話，這種數據本身就已經是高度壓縮了，再進行壓縮效果也不明顯。
• 分塊傳輸。將大文件分割成多個塊進行傳輸，如果服務端使用分塊傳輸的話，響應報文首部會有一個“Transfer-Encoding: chunked”屬性，這個屬性就表明這次數據的傳輸使用了分塊傳輸。
• 範圍傳輸：就是說可以只將一個大文件其中的一部分進行範圍傳輸。最直觀的感受就是我們網站上看電影的時候，可以跳過片頭直接看中間的片段，這就是使用了HTTP的範圍傳輸。客戶端的發出請求報文時，報文頭有一個叫做Range的字段，這個字段後面跟着一個範圍，比如說x-y就是表示請求x到y之間的數據。那服務器收到這個請求之後判斷這個範圍是否合法，如果合法的話就會將數據的其中一個片段進行回傳。