• 1、網路分層結構
• 2、三次握手
• 3、四次揮手
• 4、第四次揮手為什麼要等待2MSL？
• 5、為什麼是四次揮手？
• 6、TCP和UDP的區別
• 7、TCP有哪些特點？
• 8、HTTP協會的特點
• 9、HTTP報文格式
  • • 1、HTTP由請求行、請求頭部、空行、請求體四部分組成
    • 2、HTTP響應也由四個部分組成，分別是：狀態行、響應頭、空行和響應體。
• 10、HTTP狀態碼有哪些
• 11、HTTP1.0和HTTP1.1的區別?
• 12、HTTP1.1和 HTTP2.0的區別？
• 13、HTTPS和HTTP的區別
• 14、什麼是數字證書？
• 15、HTTPS原理
• 16、DNS 的解析過程？
• 17、瀏覽器中輸入URL返回頁面過程？
• 18、Cookie和Session的區別？
• 19、什麼是對稱加密和非對稱加密？
• 20、http GET 和 POST 請求的優缺

1、網路分層結構

計算機網路體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時候考察比較多的是五層模型。

TCP/IP五層模型：應用層、傳輸層、網路層、資料鏈路層、物理層。

• 物理層：實現相鄰節點間位元流的透明傳輸，儘可能遮蔽傳輸介質和物理裝置的差異。

• 資料鏈路層：在兩個相鄰節點之間傳送資料時，資料鏈路層將網路層交下來的 IP 資料報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。

• 網路層：選擇合適的路由和交換結點，確保資料及時傳送。主要包括IP協議

• 傳輸層：負責向兩臺主機程序之間的通訊提供資料傳輸服務。傳輸層的協議主要有傳輸控制協議TCP和使用者資料協議UDP。

• 應用層：為應用程式提供互動服務。在網際網路中的應用層協議很多，如域名系統DNS、HTTP協議、SMTP協議等。

2、三次握手

疑問一，圖中傳遞過程中出現的幾個字元（SYN,ACK,FIN,seq,ack）各代表什麼意思

SYN，ACK，FIN存放在TCP的標誌位，一共有6個字元，這裡就介紹這三個：

SYN：代表請求建立連線，所以在三次握手中前兩次要SYN=1，表示這兩次用於建立連線，至於第三次什麼用，在疑問三裡解答。

FIN：表示請求關閉連線，在四次分手時，我們發現FIN發了兩遍。這是因為TCP的連線是雙向的，所以一次FIN只能關閉一個方向。

ACK：代表確認接受，從上面可以發現，不管是三次握手還是四次分手，在迴應的時候都會加上ACK=1，表示訊息接收到了，並且在建立連線以後的傳送資料時，都需加上ACK=1,來表示資料接收成功。

seq:序列號，什麼意思呢？當傳送一個數據時，資料是被拆成多個數據包來發送，序列號就是對每個資料包進行編號，這樣接受方才能對資料包進行再次拼接。

初始序列號是隨機生成的，這樣不一樣的資料拆包解包就不會連線錯了。（例如：兩個資料都被拆成1，2，3和一個數據是1，2，3一個是101，102，103，很明顯後者不會連線錯誤）

ack:這個代表下一個資料包的編號，這也就是為什麼第二請求時，ack是seq+1，

假設傳送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是

CLOSED。

1、第一次握手：客戶端向服務端發起建立連線請求，客戶端會隨機生成一個起始序列號x，客戶端向服務端傳送的欄位中包含標誌位SYN=1，序列號seq=x。第一次握手前客戶端的狀態為CLOSE，第一次握手後客戶端的狀態為SYN-SEND。此時服務端的狀態為LISTEN

• 2、第二次握手：服務端在收到客戶端發來的報文後，會隨機生成一個服務端的起始序列號y，然後給客戶端回覆一段報文，其中包括標誌位SYN=1，ACK=1，序列號seq=y，確認號ack=x+1。第二次握手前服務端的狀態為LISTEN，第二次握手後服務端的狀態為SYN-RCVD，此時客戶端的狀態為SYN-SENT。（其中SYN=1表示要和客戶端建立一個連線，ACK=1表示確認序號有效）

• 3、第三次握手：客戶端收到服務端發來的報文後，會再向服務端傳送報文，其中包含標誌位ACK=1，序列號seq=x+1，確認號ack=y+1。第三次握手前客戶端的狀態為SYN-SENT，第三次握手後客戶端和服務端的狀態都為ESTABLISHED。此時連線建立完成。

注意：兩次握手可以嗎？

第三次握手主要為了防止已失效的連線請求報文段突然又傳輸到了服務端，導致產生問題。

• 比如客戶端A發出連線請求，可能因為網路阻塞原因，A沒有收到確認報文，於是A再重傳一次連線請求。

• 連線成功，等待資料傳輸完畢後，就釋放了連線。

• 然後A發出的第一個連線請求等到連線釋放以後的某個時間才到達服務端B，此時B誤認為A又發出一次新的連線請求，於是就向A發出確認報文段。

• 如果不採用三次握手，只要B發出確認，就建立新的連線了，此時A不會響應B的確認且不傳送資料，則B一直等待A傳送資料，浪費資源。

3、四次揮手

• 1、A的應用程序先向其TCP發出連線釋放報文段（FIN=1，seq=u），並停止再發送資料，主動關閉TCP連線，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。

• 2、B收到連線釋放報文段後即發出確認報文段（ACK=1，ack=u+1，seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，A到B的連線釋放。

A收到B的確認後，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連線釋放報文段。

• 3、B傳送完資料，就會發出連線釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進入LAST-ACK（最後確認）狀態，等待A的確認。

• 4、A收到B的連線釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設定的時間2MSL（最大報文段生存時間）後，A才進入CLOSED狀態。B收到A發出的確認報文段後關閉連線，若沒收到A發出的確認報文段，B就會重傳連線釋放報文段。

4、第四次揮手為什麼要等待2MSL？

• 保證A傳送的最後一個ACK報文段能夠到達B。這個

ACK報文段有可能丟失，B收不到這個確認報文，就會超時重傳連線釋放報文段，然後A可以在

2MSL時間內收到這個重傳的連線釋放報文段，接著A重傳一次確認，重新啟動2MSL計時器，最後A和B都進入到CLOSED狀態，若A在TIME-WAIT狀態不等待一段時間，而是傳送完ACK報文段後立即釋放連線，則無法收到B重傳的連線釋放報文段，所以不會再發送一次確認報文段，B就無法正常進入到CLOSED狀態。

• 防止已失效的連線請求報文段出現在本連線中。A在傳送完最後一個

ACK報文段後，再經過2MSL，就可以使這個連線所產生的所有報文段都從網路中消失，使下一個新的連線中不會出現舊的連線請求報文段。

5、為什麼是四次揮手？

因為當Server端收到Client端的

SYN連線請求報文後，可以直接傳送

SYN+ACK報文。但是在關閉連線時，當Server端收到Client端發出的連線釋放報文時，很可能並不會立即關閉SOCKET，所以Server端先回復一個

ACK報文，告訴Client端我收到你的連線釋放報文了。只有等到Server端所有的報文都發送完了，這時Server端才能傳送連線釋放報文，之後兩邊才會真正的斷開連線。故需要四次揮手。

6、TCP和UDP的區別

• 1、TCP面向連線；UDP是無連線的，即傳送資料之前不需要建立連線。

• 2、TCP提供可靠傳輸；UDP不保證可靠交付

• 3、TCP面向位元組流。將資料看成一串無結構的位元組流；UDP是面向報文的

• 4、TCP有擁塞控制；UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如實時視訊會議）

• 5、每一條TCP連線只能是點對點的；UDP是一對一。一對多，多對多的通訊方式

• 6、TCP首部開銷是20位元組；UDP的首部開銷小，只有8位元組

7、TCP有哪些特點？

• TCP是面向連線的運輸層協議。

• 點對點，每一條TCP連線只能有兩個端點。

• TCP提供可靠交付的服務。

• TCP提供全雙工通訊。

• 面向位元組流。

8、HTTP協會的特點

1. HTTP允許傳輸任意型別的資料。傳輸的型別由Content-Type加以標記。
2. 無狀態。對於客戶端每次傳送的請求，伺服器都認為是一個新的請求，上一次會話和下一次會話之間沒有聯絡。
3. 支援客戶端/伺服器模式。

9、HTTP報文格式

1、HTTP由請求行、請求頭部、空行、請求體四部分組成

• 請求行：包括請求方法，訪問的資源URL，使用的HTTP版本。GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。

• 請求頭：格式為“屬性名:屬性值”，服務端根據請求頭獲取客戶端的資訊，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。

• 請求體：使用者的請求資料如使用者名稱，密碼等。

請求報文示例：

POST /xxx HTTP/1.1 請求行
Accept:image/gif.image/jpeg, 請求頭部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=dabin 請求體

2、HTTP響應也由四個部分組成，分別是：狀態行、響應頭、空行和響應體。

• 狀態行：協議版本，狀態碼及狀態描述。

• 響應頭：響應頭欄位主要有

connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。

• 響應體：伺服器返回給客戶端的內容。

響應報文示例：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <body>響應體</body>
</html>

10、HTTP狀態碼有哪些

11、HTTP1.0和HTTP1.1的區別?

• 長連線：HTTP1.0預設使用短連線，每次請求都需要建立新的TCP連線，連線不能複用。HTTP1.1支援長連線，複用TCP連線，允許客戶端通過同一連線傳送多個請求。不過，這個優化策略也存在問題，當一個隊頭的請求不能收到響應的資源時，它將會阻塞後面的請求。這就是“隊頭阻塞”問題。
• 斷點續傳：HTTP1.0 不支援斷點續傳。HTTP1.1 新增了 range欄位，用來指定資料位元組位置，支援斷點續傳
• 錯誤狀態響應碼：在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突、410（Gone）表示伺服器上的某個資源被永久性的刪除。
• Host頭處理：在HTTP1.0中認為每臺伺服器都繫結一個唯一的IP地址，因此，請求訊息中的URL並沒有傳遞主機名。到了HTTP1.1時代，虛擬主機技術發展迅速，在一臺物理伺服器上可以存在多個虛擬主機，並且它們共享一個IP地址，故HTTP1.1增加了HOST資訊。

12、HTTP1.1和 HTTP2.0的區別？

HTTP2.0相比HTTP1.1支援的特性：

• 新的二進位制格式：HTTP1.1 基於文字格式傳輸資料；HTTP2.0採用二進位制格式傳輸資料，解析更高效。
• 多路複用：在一個連線裡，允許同時傳送多個請求或響應，並且這些請求或響應能夠並行的傳輸而不被阻塞，避免 HTTP1.1 出現的”隊頭堵塞”問題。
• 頭部壓縮，HTTP1.1的header帶有大量資訊，而且每次都要重複傳送；HTTP2.0 把header從資料中分離，並封裝成頭幀和資料幀，使用特定演算法壓縮頭幀，有效減少頭資訊大小。並且HTTP2.0在客戶端和伺服器端記錄了之前傳送的鍵值對，對於相同的資料，不會重複傳送。\比如請求a傳送了所有的頭資訊欄位，請求b則\只需要傳送差異資料，這樣可以減少冗餘資料，降低開銷。
• 服務端推送：HTTP2.0允許伺服器向客戶端推送資源，無需客戶端傳送請求到伺服器獲取。

13、HTTPS和HTTP的區別

• 1、HTTP是超文字傳輸協議、資訊是明文傳輸；HTTPS則是具有安全性的SSL加密傳輸協議

• 2、HTTP和HTTPS用的埠不一樣，HTTP是80，HTTPS是443

• HTTPS協議需要到CA機構申請證書，一般需要一定的費用

• 3、HTTP執行在TCP協議之上；HTTPS執行在SSL協議之上，SSL執行在TCP協議之上

14、什麼是數字證書？

服務端可以向證書頒發機構CA申請證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內容：證書內容、證書籤名演算法和簽名，簽名是為了驗證身份。

服務端把證書傳輸給瀏覽器，瀏覽器從證書裡取公鑰。證書可以證明該公鑰對應本網站。

數字簽名的製作過程：

1. CA使用證書籤名演算法對證書內容進行hash運算。
2. 對hash後的值用CA的私鑰加密，得到數字簽名。

瀏覽器驗證過程：

1. 獲取證書，得到證書內容、證書籤名演算法和數字簽名。
2. 用CA機構的公鑰對數字簽名解密（由於是瀏覽器信任的機構，所以瀏覽器會儲存它的公鑰）。
3. 用證書裡的簽名演算法對證書內容進行hash運算。
4. 比較解密後的數字簽名和對證書內容做hash運算後得到的雜湊值，相等則表明證書可信。

15、HTTPS原理

• 1、客戶端發起一個http請求

• 2.、服務端把自己的資訊以數字證書的形式返回給客戶端（證書內容包括金鑰私鑰、網站地址、證書頒發機構、失效日期）。證書中有一個公鑰用來加密資訊，私鑰由伺服器持有。

• 3、驗證證書的合法性

  • 客戶端收到伺服器的響應後會驗證證書的合法性（證書中包含的地址是否和正在訪問的地址是否一致，證書的是否過期）

• 4、生成隨機密碼

  • 如果驗證通過、或使用者接受不受信任的證書，瀏覽器會生成一個隨機的對稱金鑰（Session Key）並用於公鑰加密，讓伺服器私鑰解密，解密後就用這個對稱金鑰進行傳輸了，並且能夠說明伺服器確是私鑰的持有者

• 5、生成對稱加密演算法

  • 驗證完服務端身份後，客戶端生成一個對稱加密的演算法和對應金鑰。以公鑰加密後傳送給服務端。此時被黑客截獲也是沒有用的，因為只有伺服器端的私鑰才能對其解密。之後客戶端與服務端可以用這個對稱加密演算法加密和解密通訊內容。

16、DNS 的解析過程？

域名到IP地址的解析過程的要點如下：

當某一個應用需要把主機名解析為IP地址時，該應用程序就呼叫解析程式，並稱為DNS的一個客戶，把待解析的域名放在DNS請求報文中，以UDP使用者資料報方式發給本地域名伺服器。本地域名伺服器在查詢域名後，把對應的IP地址放在回答報文中返回。應用程式獲得目的主機的IP地址後即可進行通訊。

若本地域名伺服器不能回答該請求，則此域名伺服器就暫時稱為DNS的另一個客戶，並向其他域名伺服器發出查詢請求（發給其他根域名伺服器，若根域名伺服器叫去指定的其他頂級域名伺服器查詢請求）。這種過程直至找到能夠回答該請求的域名伺服器為止。此過程在後面作進一步討論。

17、瀏覽器中輸入URL返回頁面過程？

• 1、解析域名，找到主機IP

• 2、瀏覽器利用 IP 直接與網站主機通訊，三次握手，建立 TCP 連線。瀏覽器會以一個隨機埠向服務端的 web 程式 80 埠發起 TCP 的連線。

• 3、建立TCP連線後，瀏覽器向伺服器主機發送一個HTTP請求

• 4、伺服器響應請求，傳送響應資料

• 5、瀏覽器解析響應內容，進行渲染，呈現給使用者
  

18、Cookie和Session的區別？

• 作用範圍不同：Cookie儲存在客戶端，Session儲存在伺服器端

• 有效期不同：Cookie可設定長時間的保持，比如我們常常使用的預設登陸功能，Session一般失效時間比較短，客戶端關閉或者Session超時就會失效

• 隱私策略不同：Cookie儲存在客戶端，容易被竊取；Session儲存在Session儲存在服務端，安全性相對較高點

• 儲存大小不一樣：單個 Cookie 儲存的資料不能超過 4K；對於 Session 來說儲存沒有上限，但出於對伺服器的效能考慮，Session 內不要存放過多的資料，並且需要設定 Session 刪除機制。

19、什麼是對稱加密和非對稱加密？

對稱加密：通訊雙方使用相同的金鑰進行加密。特點是加密速度快，但是缺點是金鑰洩露會導致密文資料被破解。常見的對稱加密有AES和DES演算法。

非對稱加密：它需要生成兩個金鑰，公鑰和私鑰。公鑰是公開的，任何人都可以獲得，而私鑰是私人保管的。公鑰負責加密，私鑰負責解密；或者私鑰負責加密，公鑰負責解密。這種加密演算法安全性更高，但是計算量相比對稱加密大很多，加密和解密都很慢。常見的非對稱演算法有RSA和DSA。

20、http GET 和 POST 請求的優缺

此問答案來源連結：https://blog.csdn.net/zzk220106/article/details/78595108

• 區別
  （1）post更安全（不會作為url的一部分，不會被快取、儲存在伺服器日誌、以及瀏覽器瀏覽記錄中）
  （2）post傳送的資料更大（get有url長度限制）
  （3）post能傳送更多的資料型別（get只能傳送ASCII字元）
  （4）post比get慢
  （5）post用於修改和寫入資料，get一般用於搜尋排序和篩選之類的操作
  （6）get請求的是靜態資源，則會快取，如果是資料，則不會快取

• 為什麼get比post更快
  1.post請求包含更多的請求頭
  因為post需要在請求的body部分包含資料，所以會多了幾個資料描述部分的首部欄位（如：content-type）,這其實是微乎其微的。
  2.最重要的一條，post在真正接收資料之前會先將請求頭髮送給伺服器進行確認，然後才真正傳送資料

• post請求的過程：
  （1）瀏覽器請求tcp連線（第一次握手）
  （2）伺服器答應進行tcp連線（第二次握手）
  （3）瀏覽器確認，併發送post請求頭（第三次握手，這個報文比較小，所以http會在此時進行第一次資料傳送）
  （4）伺服器返回100 Continue響應
  （5）瀏覽器傳送資料
  （6）伺服器返回200 OK響應

• get請求的過程：
  （1）瀏覽器請求tcp連線（第一次握手）
  （2）伺服器答應進行tcp連線（第二次握手）
  （3）瀏覽器確認，併發送get請求頭和資料（第三次握手，這個報文比較小，所以http會在此時進行第一次資料傳送）
  （4）伺服器返回200 OK響應
  也就是說，目測get的總耗是post的2/3左右，這個口說無憑，網上已經有網友進行過測試。

• get傳參最大長度的理解誤區
  （1）http協議並未規定get和post的長度限制
  （2）get的最大長度限制是因為瀏覽器和web伺服器限制了URL的長度
  （3）不同的瀏覽器和web伺服器，限制的最大長度不一樣
  （4）要支援IE，則最大長度為2083byte，若支援Chrome，則最大長度8182byte