前端面試-Http那些事兒（圖解Http）

不論是在工做仍是面試中，Http這一塊的知識，對於每一個前端開發都是必備的。這篇筆記，是我的在學習 圖解Http 這本書的時候，記錄一些平時工做面試中，用得比較多的知識點，拿出來和你們分享一下。全部圖片取材都源於 圖解 Http，文章僅供我的學習使用。

一. 網絡基礎

1.1 TCP/IP 協議族

計算機與網絡設備要相互通訊，雙方就必須基於相同的方法。不一樣的硬件、操做系統之間的通訊，全部的這一切都須要一種規則。而咱們就把這種規則稱爲協議（protocol）。 像這樣把與互聯網相關聯的協議集合起來總稱爲TCP/IP。也有說法認爲，TCP/IP是指TCP和IP這兩種協議。還有一種說法認爲，TCP/IP是在IP協議的通訊過程當中，使用到的協議族的統稱。

1.2 TCP/IP 的分層管理

• 應用層：直接跟用戶接觸，向用戶提供應用服務
  • Http協議，DNS域解析
• 傳輸層：TCP，UDP 提供兩臺計算機之間的傳輸
  • TCP或者UDP
• 網絡層：在衆多的選項內選擇一條傳輸路線
  • IP
• 鏈路層：用來處理鏈接網絡的硬件部分

1.3 TCP/IP 通訊傳輸流

• 利用TCP/IP 協議族進行網絡通訊時，會經過分層順序與對方通訊。

• 發送端在層與層之間傳輸數據時，每通過一層，一定會打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，沒通過一層會把對應的首部消去

1.4 TCP 的三次握手

三次握手是由發送端發起的，在發送數據以前，發送端會給接收端發送一個確認消息，當接收端接到發送端的消息而且作出迴應以後，發送端纔會開始數據的傳輸

1.5 DNS 域解析

DNS(Domain Name System) 服務是和 HTTP 協議同樣位於應用層的協議，它提供域名到 IP 之間的解析服務

1.6 HTTP協議通訊流程

1.7 URL/URI

URI（Uniform Resource Iden-tifier）：統一資源定位符，標識某一互聯網上面的資源

URL（Uniform Resource Locator）： 統一資源地址，標識資源的位置

• URI格式

二. HTTP協議

2.1 HTTP的做用

HTTP協議和 TCP/IP 協議族內的其它衆多協議相同，用於客戶端和服務器之間的通訊

請求訪問的一端稱爲客戶端，提供資源響應的一端稱爲服務端

2.2 無狀態協議

http 是一種不保存狀態，即無狀態的協議

在調用過程當中，對請求和響應都不作持久化處理

優勢：

• 更快的處理大量事物
• 確保協議的可伸縮性

缺點：

• 某些請求或者登錄狀態須要保持狀態

2.3 Http的請求方法

GET : 主要用來獲取資源，參數包含在URL中可見，因此安全性比較差，瀏覽器對GET方法的參數長度有限制

POST ：主要用來獲取和傳輸資源，參數包含在請求體中，且參數長度比GET大的多，對外不可見，相對較爲安全，

PUT ：向服務器提交數據，更新服務器資源

DELETE ：刪除服務器數據

HEAD ：獲取報文首部

2.4 持久化鏈接

問題： 在 Http 最初的版本中，沒進行一次 Http 通訊都會斷開一次鏈接，所以當請求過多的時候，都會形成無謂的通訊開銷

解決： Http/1.1 提出了持久鏈接的概念

持久鏈接： 持久鏈接的特色是，只要任意一方沒有明確提出斷開鏈接，就保持TCP鏈接狀態

優勢： 持久鏈接的好處在於減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使HTTP 請求和響應可以更早地結束，這樣 Web 頁面的顯示速度也就相應提升了

2.5 Cookie

前面說過，Http是無狀態的

• 沒有Cookie狀態下的請求

• 第2次之後（有了Cookie）請求

• 報文說明

三. HTTP報文

Http 包含請求報文和響應報文，經過依賴這兩種報文來達到信息的資源的請求和響應

3.1 請求報文和響應報文的結構

請求報文：

• 請求行：請求方法，協議名，版本號，請求URI
• 請求頭部
• 空行
• 請求體

響應報文

• 狀態行：協議名，版本號，返回的狀態碼
• 響應頭部
• 空行
• 響應體

3.2 報文實例

四. HTTP首部

​ 請求頭參數：

​ Content-type

​ Host

​ Connection

​ Content-length

​ cookie

​ Date

​ last-modify

​ cache-control

HTTP 首部是構成HTTP報文的要素之一

在HTTP通訊過程當中，不管是請求仍是響應都會使用首部字段，它能起到傳遞額外信息的做用

4.1 首部分類

1. 通用首部字段：請求報文和相應報文都會使用的

2. 請求首部字段

3. 響應首部字段

4. 實體首部字段：補充了資源內容的更新時間等實體相關的信息

五. HTTP狀態碼

狀態碼錶示客戶端請求的返回結果

狀態碼中的第一位指定響應類別，後兩類無分類

• 狀態碼類別

5.1 常見狀態碼

• 200：OK，請求成功，請求被正常處理
• 204：請求成功，可是沒有資源返回
• 301：永久性重定向
• 302：臨時性重定向
• 403：服務器拒絕訪問
• 404：沒法找到請求資源
• 500：服務器錯誤

六. HTTP緩存處理

緩存是指代理服務器內保存的資源副本，利用緩存能夠減小對服務器的訪問，所以也就節省了通訊流量和通訊時間

緩存是服務器是代理服務器的一種，當代理轉發從服務器返回的資源時，代理服務器會返回一份資源的副本

6.1 緩存服務器

6.2 客戶端緩存

緩存不只能夠存在於緩存服務器內，還能夠存在客戶端瀏覽器中。把客戶端緩存稱爲臨時網絡文件

另外，和緩存服務器相同的一點是，當斷定緩存過時後，會向源服務器確認資源的有效性。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資源。

6.3 緩存有效期

6.4 緩存相關設置

• 強緩存：
  • Cache-Control
  • Expires
  • Pragma：在 HTTP 1.1中已經被廢棄
• 協商緩存：
  • ETag/If-Not-Match
  • Last-Modified/If-Modified-Since

6.5 瀏覽器首次和再次發送請求的執行流程圖

瀏覽器首次發送請求

瀏覽器再次發送請求

參考文章：簡書：一文讀懂http緩存

七. 其它問題

7.1 GET和POST的區別

1. GET請求的參數包含在URL中，對外可見，因此安全性較差，POST請求的參數包含在請求體中，對外不可見，相對安全
2. 瀏覽器會主動緩存GET請求的相關資源，可是對於POST，瀏覽器不會主動緩存，除非手動設置
3. GET請求的參數有長度限制，可是POST沒有
4. GET請求在瀏覽器回退時是無害的，可是POST會從新發送請求
5. GET請求的參數，會被保存在瀏覽器的歷史記錄裏面，可是POST不會

7.2 TCP和UDP的區別

​ TCP： 三次握手，穩定性強，數據可靠，速度慢，佔用系統資源高，適合少許的數據傳輸

​ UDP:

​ 總結：

​ - TCP面向鏈接，UDP是無鏈接的，即發送數據以前不須要創建鏈接

​ - TCP提供可靠的服務，即TCP鏈接傳送的數據，無差錯，不丟失。UDP盡最大努力交付，可是不保證數 據的可靠性

​ - TCP只能是一對一，UDP能夠一對一，一對多，多對一