HTTP 基本概念

?一、HTTP 是什么？

HTTP(HyperText Transfer?Protocol) ：超文本傳輸協(xié)議。

HTTP 是一個在計算機世界里專門在「兩點」之間「傳輸」文字、圖片、音頻、視頻等「超文本」數據的「約定和規(guī)范」。

「HTTP 是用于從互聯(lián)網服務器傳輸超文本到本地瀏覽器的協(xié)議」，這種說法正確嗎？

不正確。因為也可以是「服務器< -- >服務器」，所以采用兩點之間的描述會更準確。

二、HTTP 常見的狀態(tài)碼

2xx成功 ：

• 「200 OK」是最常見的成功狀態(tài)碼，表示一切正常。如果是非?HEAD?請求，服務器返回的響應頭都會有 body 數據。

• 「204 No Content」與 200 OK 基本相同，但響應頭沒有 body 數據。

• 「206 Partial Content」是應用于 HTTP 分塊下載或斷點續(xù)傳，表示響應返回的 body 數據并不是資源的全部，而是其中的一部分，也是服務器處理成功的狀態(tài)。

3xx重定向：

• 「301 Moved Permanently」永久重定向，請求的資源已經不存在了，需改用新的 URL 再次訪問。

• 「302 Found」臨時重定向，請求的資源還在，但暫時需要用另一個 URL 來訪問。

301 和 302 都會在響應頭里使用字段?Location，指明后續(xù)要跳轉的 URL，瀏覽器會自動重定向新的 URL。

• 「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，也就是告訴客戶端可以繼續(xù)使用緩存資源，用于緩存控制。

4xx客戶端錯誤：

• 「400 Bad Request」客戶端請求的報文有錯誤，但只是個籠統(tǒng)的錯誤。

• 「403 Forbidden」服務器禁止訪問資源，并不是客戶端的請求出錯。

• 「404 Not Found」請求的資源在服務器上不存在或未找到。

5xx服務器錯誤：

• 「500 Internal Server Error」服務器籠統(tǒng)的通用錯誤碼。

• 「501 Not Implemented」客戶端請求的功能還不支持，類似“即將開業(yè)，敬請期待”。

• 「502 Bad Gateway」通常是服務器作為網關或代理時返回的錯誤碼，表示服務器自身工作正常，訪問后端服務器發(fā)生了錯誤。

• 「503 Service Unavailable」服務器當前很忙，暫時無法響應。

三、HTTP 常見字段

1.Host：www.example.com

客戶端發(fā)送請求時，用于指定服務器的域名,可以將請求發(fā)往「同一臺」服務器上的不同網站。

2.Content-Length：1000

服務器返回數據時，表示本次回應的數據長度是 1000 個字節(jié)，后面的字節(jié)屬于下一個回應。

(HTTP 基于 TCP 傳輸協(xié)議進行通信，而使用了 TCP 協(xié)議會存在“粘包”問題，于是HTTP 協(xié)議通過設置回車符、換行符作為 HTTP header 的邊界，通過 Content-Length 字段作為 HTTP body 的邊界，來解決“粘包”問題。)

3.Connection：Keep-Alive

客戶端發(fā)送請求時，用于保持連接，當客戶端發(fā)送另一個請求時，會使用同一個連接，一直持續(xù)到客戶端或服務器端提出斷開連接。

HTTP/1.1 版本的默認連接都是長連接，但為了兼容老版本的 HTTP，需要指定Connection：Keep-Alive?

注意：

HTTP Keep-Alive 和 TCP Keepalive并不相同

HTTP Keep-Alive：保持連接

TCP Keepalive：檢查連接是否有效

4.Content-Type: text/html; Charset=utf-8

服務器返回數據時，表示數據格式(這里表示發(fā)送網頁，編碼是UTF-8)

5.Accept: */*

客戶端發(fā)送請求時，聲明自己可接受的數據格式(這里表示可接受任何格式)

6.Content-Encoding：gzip

服務器返回數據時，使用的數據壓縮方法。

7.Accept-Encoding: gzip, deflate

客戶端發(fā)送請求時，聲明自己可接受的壓縮方法。

GET 與 POST

GET ：從服務器獲取指定的資源。

POST ：根據請求負荷（報文body）對指定的資源做出處理。

GET 和 POST 方法都是安全和冪等的嗎？

在 HTTP 協(xié)議里安全和冪等的概念：

• 「安全」：請求方法不會「破壞」服務器上的資源。
• 「冪等」：多次執(zhí)行相同的操作，結果都是「相同」的。

從 RFC 規(guī)范定義的語義來看：

• GET 方法安全且冪等的，因為它是「只讀」操作，無論操作多少次，服務器上的數據都是安全的，且每次的結果都是相同的。所以，可以對 GET 請求的數據做緩存，這個緩存可以做到瀏覽器本身上（徹底避免瀏覽器發(fā)請求），也可以做到代理上（如nginx），而且在瀏覽器中 GET 請求可以保存為書簽。
• POST?因為是「新增或提交數據」的操作，會修改服務器上的資源，所以是不安全的，且多次提交數據就會創(chuàng)建多個資源，所以不是冪等的。所以，瀏覽器一般不會緩存 POST 請求，也不能把 POST 請求保存為書簽。

GET 方法是安全、冪等、可被緩存的。

POST 不安全，不冪等，（大部分實現）不可緩存。

但是實際過程中，開發(fā)者不一定會按照 RFC 規(guī)范定義的語義來實現 GET 和 POST 方法。比如：

• 用 GET 方法實現新增或刪除數據的請求，這樣實現的 GET 方法就不是安全和冪等。
• 用 POST 方法實現查詢數據的請求，這樣實現的 POST 方法就是安全和冪等。

并不能說 GET 不如 POST 安全的。

因為 HTTP 傳輸的內容都是明文的，雖然在瀏覽器地址攔看不到 POST 提交的 body 數據，但是只要抓個包就都能看到了。

所以，要避免傳輸過程中數據被竊取，就要使用 HTTPS 協(xié)議，這樣所有 HTTP 的數據都會被加密傳輸。

GET 請求可以帶 body 嗎？

理論上，任何請求都可以帶 body 。只是因為 RFC 規(guī)范定義的 GET 請求是獲取資源，所以根據這個語義不需要用到 body。

另外，URL 中的查詢參數也不是 GET 所獨有的，POST 請求的 URL 中也可以有參數的。

HTTP 緩存機制

一、強制緩存

只要瀏覽器判斷緩存沒有過期，則直接使用瀏覽器的本地緩存而無需再請求服務器。

強制緩存是利用下面這兩個 HTTP 響應頭部（Response Header）字段實現的，它們都用來表示資源在客戶端緩存的有效期：

• Cache-Control， 是一個相對時間；
• Expires，是一個絕對時間；

如果 HTTP 響應頭部同時有 Cache-Control 和 Expires 字段的話，Cache-Control 的優(yōu)先級高于 Expires?。

Cache-control 選項更多一些，設置更加精細，所以建議使用 Cache-Control 來實現強制緩存。具體的實現流程如下：

• 當瀏覽器第一次請求訪問服務器資源時，服務器會在返回這個資源的同時，在 Response 頭部加上 Cache-Control，Cache-Control 中設置了過期時間大?。?/li>
• 瀏覽器再次請求訪問服務器中的該資源時，會先通過請求資源的時間與 Cache-Control 中設置的過期時間大小，來計算出該資源是否過期，如果沒有，則使用該緩存，否則重新請求服務器；
• 服務器再次收到請求后，會再次更新 Response 頭部的 Cache-Control。

二、協(xié)商緩存

與服務端協(xié)商之后，通過協(xié)商結果來判斷是否使用本地緩存。

協(xié)商緩存可以基于兩種頭部來實現。

第一種：請求頭部中的?If-Modified-Since?字段與響應頭部中的Last-Modified字段

????????????????(基于時間實現)

• 響應頭部中的?Last-Modified：標示這個響應資源的最后修改時間；
• 請求頭部中的?If-Modified-Since：當資源過期了，發(fā)現響應頭中具有 Last-Modified 聲明，則再次發(fā)起請求的時候帶上 Last-Modified 的時間，服務器收到請求后發(fā)現有 If-Modified-Since 則與被請求資源的最后修改時間進行對比（Last-Modified）。
• 如果最后修改時間較早，說明資源又被改過，則返回最新資源，HTTP 200 OK；
• 如果最后修改時間較小，說明資源無新修改，響應 HTTP 304 走緩存。

第二種：請求頭部中的?If-None-Match?字段與響應頭部中的?ETag?字段

????????????????(基于一個唯一標識實現，能更準確地判斷文件內容是否被修改)

• 響應頭部中ETag：唯一標識響應資源；
• 請求頭部中的?If-None-Match：當資源過期時，瀏覽器發(fā)現響應頭里有 Etag，則再次向服務器發(fā)起請求時，會將請求頭 If-None-Match 值設置為 Etag 的值。服務器收到請求后進行比對，如果資源沒有變化返回 304，如果資源變化了返回 200。

如果在第一次請求資源的時候，服務端返回的 HTTP 響應頭部同時有 Etag 和 Last-Modified 字段，那么客戶端再下一次請求的時候，如果帶上了 ETag 和 Last-Modified 字段信息給服務端，這時 Etag 的優(yōu)先級更高，也就是服務端先會判斷 Etag 是否變化了，如果 Etag 有變化就不用在判斷 Last-Modified 了，如果 Etag 沒有變化，然后再看 Last-Modified。

為什么 ETag 的優(yōu)先級更高？

這是因為 ETag 主要能解決 Last-Modified 幾個比較難以解決的問題：

1. 在沒有修改文件內容情況下文件的最后修改時間可能也會改變，這會導致客戶端認為這文件被改動了，從而重新請求；
2. 可能有些文件是在秒級以內修改的，If-Modified-Since?能檢查到的粒度是秒級的，使用 Etag就能夠保證這種需求下客戶端在 1 秒內能刷新多次；
3. 有些服務器不能精確獲取文件的最后修改時間。

注意，協(xié)商緩存這兩個字段都需要配合強制緩存中 Cache-Control 字段來使用，只有在未能命中強制緩存的時候，才能發(fā)起帶有協(xié)商緩存字段的請求。

HTTP緩存如果通過查詢Cache-Control字段或Expires字段，發(fā)現資源沒有過期，那么會先走強制緩存，如果過期了，就走協(xié)商緩存，協(xié)商緩存有兩種形式，一種是基于時間實現的請求頭部中的?If-Modified-Since?字段與響應頭部中的Last-Modified字段，資源過期時，發(fā)送請求時If-Modified-Since?字段會帶上Last-Modified字段，服務器收到后對Last-Modified字段進行比對，如果最后修改時間較早，說明資源又被改過，則返回最新資源，HTTP 200 OK；如果最后修改時間較小，說明資源無新修改，響應 HTTP 304 走緩存。第二種是請求頭部中的?If-None-Match?字段與響應頭部中的?ETag?字段，發(fā)起請求時，會將請求頭 If-None-Match 值設置為 Etag 的值。服務器收到請求后進行比對，如果資源沒有變化返回 304，如果資源變化了返回 200。兩種方式可以并存，此時Etag的優(yōu)先級更高。

HTTP/1.1 特性

HTTP/1.1 的優(yōu)點有哪些？

「簡單、靈活和易于擴展、應用廣泛和跨平臺」

1. 簡單

HTTP 基本的報文格式就是?header + body，頭部信息也是?key-value?簡單文本的形式，易于理解。

2. 靈活和易于擴展

HTTP 協(xié)議里的各類請求方法、URI/URL、狀態(tài)碼、頭字段等每個組成要求都沒有被固定死，都允許開發(fā)人員自定義和擴充。

同時 HTTP 由于是工作在應用層（?OSI?第七層），則它下層可以隨意變化，比如：

• HTTPS 就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層；
• HTTP/1.1 和 HTTP/2.0 傳輸協(xié)議使用的是 TCP 協(xié)議，而到了 HTTP/3.0 傳輸協(xié)議改用了 UDP 協(xié)議。

3. 應用廣泛和跨平臺

HTTP/1.1 的缺點有哪些？

HTTP 協(xié)議里有優(yōu)缺點一體的雙刃劍，分別是「無狀態(tài)、明文傳輸」，同時還有一大缺點「不安全」。

1. 無狀態(tài)雙刃劍

無狀態(tài)的好處，因為服務器不會去記憶 HTTP 的狀態(tài)，所以不需要額外的資源來記錄狀態(tài)信息，這能減輕服務器的負擔。

無狀態(tài)的壞處，沒有記憶能力，那么在完成有關聯(lián)性的操作時會非常麻煩。

例如登錄->添加購物車->下單->結算->支付，這系列操作都要知道用戶的身份才行。但服務器不知道這些請求是有關聯(lián)的，每次都要問一遍身份信息。

通常使用?Cookie?技術來解決無狀態(tài)問題。

Cookie?通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態(tài)。

相當于，在客戶端第一次請求后，服務器會下發(fā)一個裝有客戶信息的「小貼紙」，后續(xù)客戶端請求服務器的時候，帶上「小貼紙」，服務器就能認得了

2. 明文傳輸雙刃劍

明文傳輸雖然易于閱讀，但也增加了信息泄露的風險。

HTTP/1.1 的性能如何？

HTTP 協(xié)議是基于?TCP/IP，并且使用了「請求 - 應答」的通信模式，所以性能的關鍵就在這兩點里。

1. 長連接

早期 HTTP/1.0 性能上的一個很大的問題，那就是每發(fā)起一個請求，都要新建一次 TCP 連接（三次握手），而且是串行請求，做了無謂的 TCP 連接建立和斷開，增加了通信開銷。

HTTP/1.1 提出了長連接的通信方式，也叫持久連接。這種方式減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載。

持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。

如果某個 HTTP 長連接超過一定時間沒有任何數據交互，服務端就會主動斷開這個連接。

2. 管道網絡傳輸

HTTP/1.1 采用了長連接的方式，這使得管道（pipeline）網絡傳輸成為了可能。

即可在同一個 TCP 連接里面，客戶端可以發(fā)起多個請求，只要第一個請求發(fā)出去了，不必等其回來，就可以發(fā)第二個請求出去，可以減少整體的響應時間。

舉例來說，客戶端需要請求兩個資源。以前的做法是，在同一個 TCP 連接里面，先發(fā)送 A 請求，然后等待服務器做出回應，收到后再發(fā)出 B 請求。那么，管道機制則是允許瀏覽器同時發(fā)出 A 請求和 B 請求，如下圖：

但是服務器必須按照接收請求的順序發(fā)送對這些管道化請求的響應。

如果服務端在處理 A 請求時耗時比較長，那么后續(xù)的請求的處理都會被阻塞住，這稱為「隊頭堵塞」。

所以，HTTP/1.1 管道解決了請求的隊頭阻塞，但是沒有解決響應的隊頭阻塞。

注意：

實際上 HTTP/1.1 管道化技術不是默認開啟，而且瀏覽器基本都沒有支持，知道有這個功能，但是沒有被使用就行了。

3. 隊頭阻塞

「請求 - 應答」的模式會造成 HTTP 的性能問題。

當順序發(fā)送的請求序列中的一個請求因為某種原因被阻塞時，在后面排隊的所有請求也一同被阻塞了，會招致客戶端一直請求不到數據，這就是「隊頭阻塞」，好比上班的路上塞車。

總之 HTTP/1.1 的性能一般，后續(xù)的 HTTP/2 和 HTTP/3 就是在優(yōu)化 HTTP 的性能。

HTTP/1.1采用了長連接來提高性能，只要客戶端和服務器端沒有一方主動斷開連接，就會在一定時間內保持連接，從而避免了多次連接和斷開產生的開銷，長連接使得管道網絡傳輸成為可能，之前的情況是必須等第一個請求得到響應時才能發(fā)送第二個請求，如果使用管道網絡傳輸，那么就可以在發(fā)送的第一個請求沒有得到響應時就發(fā)送第二個請求，但是服務器必須按照接收請求的順序發(fā)送對這些管道化請求的響應，如果服務端在處理某一個請求時耗時比較長，那么后續(xù)的請求的處理都會被阻塞住，這稱為「隊頭堵塞」，就和堵車一樣，會導致客戶端一直請求不到數據。

所以，HTTP/1.1 管道解決了請求的隊頭阻塞，但是沒有解決響應的隊頭阻塞，不過管道網絡傳輸默認關閉，且大多數瀏覽器沒有支持，知道就行。

HTTP 和 HTTPS

一、HTTP

1.明文傳輸，不安全

2.默認端口號：80

3.TCP三次握手即可

二、HTTPS

1.加密傳輸，更安全(在HTTP層與TCP層之間加上了SSL/TTL安全協(xié)議)

?SSL和TTL是在不同時期的兩種叫法，含義相同。

2.默認端口號：443

3.TCP三次握手+SSL/TTL四次握手(RSA算法和ECDHE算法)

4.采用對稱加密和非對稱加密結合的「混合加密」方式：

• 在通信建立前采用非對稱加密的方式交換「會話秘鑰」。
• 在通信過程中全部使用對稱加密的「會話秘鑰」的方式加密明文數據。

采用「混合加密」的方式的原因：

• 對稱加密只使用一個密鑰，運算速度快，密鑰必須保密，無法做到安全的密鑰交換。
• 非對稱加密使用兩個密鑰：公鑰和私鑰，公鑰可以任意分發(fā)而私鑰保密，更安全但速度慢(公鑰加密，私鑰解密)。

5.摘要算法 + 數字簽名

為了保證傳輸的內容不被篡改，會先對內容計算出一個「指紋」，再把「指紋」和內容一起傳輸給對方。

對方收到后，先是對內容也計算出一個「指紋」，然后跟發(fā)送方發(fā)送的「指紋」做一個比較，如果「指紋」相同，說明內容沒有被篡改。

在計算機里會用摘要算法（哈希函數）來計算出內容的哈希值，也就是內容的「指紋」，這個哈希值是唯一的，且無法通過哈希值推導出內容。

通過哈希算法可以確保內容不會被篡改，但是并不能保證「內容 + 哈希值」不會被中間人替換，因為這里缺少對客戶端收到的消息是否來源于服務端的證明。

所以需要通過非對稱加密「公鑰加密，私鑰解密」的方式，來確認消息的身份。

6.需要向 CA（證書權威機構）申請數字證書（防止公鑰和私鑰被同時偽造）

數字證書中含有公鑰和CA的數字簽名(CA相當于權威認證，如果CA簽名可信，那么公鑰就可信)

HTTPS 是如何建立連接的？其間交互了什么？

SSL/TLS 協(xié)議基本流程：

• 客戶端向服務器索要并驗證服務器的公鑰。
• 雙方協(xié)商生產「會話秘鑰」。
• 雙方采用「會話秘鑰」進行加密通信。

前兩步也就是 SSL/TLS 的建立過程，也就是 TLS 握手階段。

TLS 的「握手階段」涉及四次通信，使用不同的密鑰交換算法，TLS 握手流程也會不一樣的，常用的密鑰交換算法有兩種：RSA 算法和 ECDHE 算法 。

TLS 協(xié)議建立的詳細流程：

1. ClientHello

首先，由客戶端向服務器發(fā)起加密通信請求，也就是?ClientHello?請求。

在這一步，客戶端主要向服務器發(fā)送以下信息：

（1）客戶端支持的 TLS 協(xié)議版本，如 TLS 1.2 版本。

（2）客戶端生產的隨機數（Client Random），后面用于生成「會話秘鑰」條件之一。

（3）客戶端支持的密碼套件列表，如 RSA 加密算法。

2. SeverHello

服務器收到客戶端請求后，向客戶端發(fā)出響應，也就是?SeverHello。服務器回應的內容有如下內容：

（1）確認 TLS 協(xié)議版本，如果瀏覽器不支持，則關閉加密通信。

（2）服務器生產的隨機數（Server Random），也是后面用于生產「會話秘鑰」條件之一。

（3）確認的密碼套件列表，如 RSA 加密算法。

（4）服務器的數字證書。

3.客戶端回應

客戶端收到服務器的回應之后，首先通過瀏覽器或者操作系統(tǒng)中的 CA 公鑰，確認服務器的數字證書的真實性。

如果證書沒有問題，客戶端會從數字證書中取出服務器的公鑰，然后使用它加密報文，向服務器發(fā)送如下信息：

（1）一個隨機數（pre-master key）。該隨機數會被服務器公鑰加密。

（2）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。

（3）客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時把之前所有內容的發(fā)生的數據做個摘要，用來供服務端校驗。

上面第一項的隨機數是整個握手階段的第三個隨機數，會發(fā)給服務端，所以這個隨機數客戶端和服務端都是一樣的。

服務器和客戶端有了這三個隨機數（Client Random、Server Random、pre-master key），接著就用雙方協(xié)商的加密算法，各自生成本次通信的「會話秘鑰」。

4. 服務器的最后回應

服務器收到客戶端的第三個隨機數（pre-master key）之后，通過協(xié)商的加密算法，計算出本次通信的「會話秘鑰」。

然后，向客戶端發(fā)送最后的信息：

（1）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。

（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時把之前所有內容的發(fā)生的數據做個摘要，用來供客戶端校驗。

至此，整個 TLS 的握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的 HTTP 協(xié)議，只不過用「會話秘鑰」加密內容。

不過，基于 RSA 算法的 HTTPS 存在「前向安全」的問題：如果服務端的私鑰泄漏了，過去被第三方截獲的所有 TLS 通訊密文都會被破解。

為了解決這個問題，后面就出現了 ECDHE 密鑰協(xié)商算法，現在大多數網站使用的正是 ECDHE 密鑰協(xié)商算法。

客戶端校驗數字證書的流程是怎樣的？

CA 簽發(fā)證書的過程：

• 首先 CA 會把持有者的公鑰、用途、頒發(fā)者、有效時間等信息打成一個包，然后對這些信息進行 Hash 計算，得到一個 Hash 值；
• 然后 CA 會使用自己的私鑰將該 Hash 值加密，生成 Certificate Signature，也就是 CA 對證書做了簽名；
• 最后將 Certificate Signature 添加在文件證書上，形成數字證書；

客戶端校驗服務端的數字證書的過程：

• 首先客戶端會使用同樣的 Hash 算法獲取該證書的 Hash 值 H1；
• 通常瀏覽器和操作系統(tǒng)中集成了 CA 的公鑰信息，瀏覽器收到證書后可以使用 CA 的公鑰解密 Certificate Signature 內容，得到一個 Hash 值 H2 ；
• 最后比較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認為證書不可信。

但事實上，證書的驗證過程中還存在一個證書信任鏈的問題，因為我們向 CA 申請的證書一般不是根證書簽發(fā)的，而是由中間證書簽發(fā)的，比如百度的證書，從下圖你可以看到，證書的層級有三級：

對于這種三級層級關系的證書的驗證過程如下：

• 客戶端收到 baidu.com 的證書后，發(fā)現這個證書的簽發(fā)者不是根證書，就無法根據本地已有的根證書中的公鑰去驗證 baidu.com 證書是否可信。于是，客戶端根據 baidu.com 證書中的簽發(fā)者，找到該證書的頒發(fā)機構是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 請求該中間證書。
• 請求到證書后發(fā)現 “GlobalSign Organization Validation CA - SHA256 - G2” 證書是由 “GlobalSign Root CA” 簽發(fā)的，由于 “GlobalSign Root CA” 沒有再上級簽發(fā)機構，說明它是根證書，也就是自簽證書。應用軟件會檢查此證書有否已預載于根證書清單上，如果有，則可以利用根證書中的公鑰去驗證 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，如果發(fā)現驗證通過，就認為該中間證書是可信的。
• “GlobalSign Organization Validation CA - SHA256 - G2” 證書被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 證書中的公鑰去驗證 baidu.com 證書的可信性，如果驗證通過，就可以信任 baidu.com 證書。

在這四個步驟中，最開始客戶端只信任根證書 GlobalSign Root CA 證書的，然后 “GlobalSign Root CA” 證書信任 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，而 “GlobalSign Organization Validation CA - SHA256 - G2” 證書又信任 baidu.com 證書，于是客戶端也信任 baidu.com 證書。

總括來說，由于用戶信任 GlobalSign，所以由 GlobalSign 所擔保的 baidu.com 可以被信任，另外由于用戶信任操作系統(tǒng)或瀏覽器的軟件商，所以由軟件商預載了根證書的 GlobalSign 都可被信任。

過程就是從最下級找到最上級，再用最上級的公鑰驗證下一級是否可信，再用下一級的公鑰驗證下下一級是否可信，以此類推。

為什么需要證書鏈這么麻煩的流程？Root CA 為什么不直接頒發(fā)證書，而是要搞那么多中間層級呢？

這是為了確保根證書的絕對安全性，將根證書隔離地越嚴格越好，不然根證書如果失守了，那么整個信任鏈都會有問題。

HTTPS 的應用數據是如何保證完整性的？

TLS 在實現上分為握手協(xié)議和記錄協(xié)議兩層：

• TLS 握手協(xié)議就是我們前面說的 TLS 四次握手的過程，負責協(xié)商加密算法和生成對稱密鑰，后續(xù)用此密鑰來保護應用程序數據（即 HTTP 數據）；
• TLS 記錄協(xié)議負責保護應用程序數據并驗證其完整性和來源，所以對 HTTP 數據加密是使用記錄協(xié)議；

TLS 記錄協(xié)議主要負責消息（HTTP 數據）的壓縮，加密及數據的認證，過程如下圖：

具體過程如下：

• 首先，消息被分割成多個較短的片段,然后分別對每個片段進行壓縮。

• 接下來，經過壓縮的片段會被加上消息認證碼（MAC 值，這個是通過哈希算法生成的），這是為了保證完整性，并進行數據的認證。通過附加消息認證碼的 MAC 值，可以識別出篡改。與此同時，為了防止重放攻擊，在計算消息認證碼時，還加上了片段的編碼。

• 再接下來，經過壓縮的片段再加上消息認證碼會一起通過對稱密碼進行加密。

• 最后，上述經過加密的數據再加上由數據類型、版本號、壓縮后的長度組成的報頭就是最終的報文數據。

記錄協(xié)議完成后，最終的報文數據將傳遞到傳輸控制協(xié)議 (TCP) 層進行傳輸。

消息被分割成多個較短的片段,然后分別對每個片段進行壓縮，每個被壓縮的片段都會被加上由哈希算法生成的MAC值，也就是消息認證碼，之后進行對稱加密生成密文，最后為密文加上由數據類型、版本號、壓縮后的長度組成的報頭形成最終的報文數據，然后就可以傳遞到傳輸控制協(xié)議 (TCP) 層進行傳輸。

三、HTTPS的可靠性

HTTPS 協(xié)議本身到目前為止還是沒有任何漏洞的，即使你成功進行中間人攻擊，本質上是利用了客戶端的漏洞（用戶點擊繼續(xù)訪問或者被惡意導入偽造的根證書），并不是 HTTPS 不夠安全。

客戶端漏洞如下：

客戶端通過瀏覽器向服務端發(fā)起 HTTPS 請求時，被「假基站」轉發(fā)到了一個「中間人服務器」，于是客戶端是和「中間人服務器」完成了 TLS 握手，然后這個「中間人服務器」再與真正的服務端完成 TLS 握手。

問題產生的原因：

1.執(zhí)意信任網站

2.電腦中毒，被惡意導入了中間人的根證書

解決方法：

1.防范病毒，不要點擊任何證書非法的網站。

2.?HTTPS 雙向認證：一般我們的 HTTPS 是單向認證，客戶端只會驗證了服務端的身份，但是服務端并不會驗證客戶端的身份。

為什么抓包工具能截取 HTTPS 數據？

工作原理與中間人一致的。

對于 HTTPS 連接來說，中間人要滿足以下兩點，才能實現真正的明文代理:

1. 中間人，作為客戶端與真實服務端建立連接這一步不會有問題，因為服務端不會校驗客戶端的身份；
2. 中間人，作為服務端與真實客戶端建立連接，這里會有客戶端信任服務端的問題，也就是服務端必須有對應域名的私鑰；

中間人要拿到私鑰只能通過如下方式：

1. 去網站服務端拿到私鑰；
2. 去CA處拿域名簽發(fā)私鑰；
3. 自己簽發(fā)證書，切要被瀏覽器信任；

抓包工具只能使用第三種方式取得中間人的身份。

HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

HTTP/1.1 相比 HTTP/1.0 性能上的改進：

• 使用長連接改善了短連接造成的性能開銷。
• 支持管道網絡傳輸，只要第一個請求發(fā)出去了，不必等其回來，就可以發(fā)第二個請求出去，減少整體的響應時間。

但 HTTP/1.1 還是有性能瓶頸：

• 請求 / 響應頭部（Header）未經壓縮就發(fā)送，首部信息越多延遲越大。只能壓縮?Body?的部分；
• 發(fā)送冗長的首部。每次互相發(fā)送相同的首部造成的浪費較多；
• 服務器是按請求的順序響應的，如果服務器響應慢，會招致客戶端一直請求不到數據，也就是隊頭阻塞；
• 沒有請求優(yōu)先級控制；
• 請求只能從客戶端開始，服務器只能被動響應。

HTTP/2 做了什么優(yōu)化？

HTTP/2 協(xié)議是基于 HTTPS 的。?

那 HTTP/2 相比 HTTP/1.1 性能上的改進：

• 頭部壓縮
• 二進制格式
• 并發(fā)傳輸
• 服務器主動推送資源

1. 頭部壓縮

HTTP/2 會壓縮頭（Header）如果你同時發(fā)出多個請求，他們的頭是一樣的或是相似的，那么，協(xié)議會幫你消除重復的部分。

這就是所謂的?HPACK?算法：在客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發(fā)送同樣字段了，只發(fā)送索引號來提高速度。

2. 二進制格式

HTTP/2 不再像 HTTP/1.1 里的純文本形式的報文，而是全面采用了二進制格式，頭信息和數據體都是二進制，并且統(tǒng)稱為幀（frame）：頭信息幀（Headers Frame）和數據幀（Data Frame）。

這樣雖然對人不友好，但是對計算機非常友好，因為計算機只懂二進制，那么收到報文后，無需再將明文的報文轉成二進制，而是直接解析二進制報文，這增加了數據傳輸的效率。

比如狀態(tài)碼 200 ，在 HTTP/1.1 是用 '2''0''0' 三個字符來表示（二進制：00110010 00110000 00110000），共用了 3 個字節(jié)，在 HTTP/2 對于狀態(tài)碼 200 的二進制編碼是 10001000，只用了 1 字節(jié)就能表示，相比于 HTTP/1.1 節(jié)省了 2 個字節(jié)。

3. 并發(fā)傳輸

我們都知道 HTTP/1.1 的實現是基于請求-響應模型的。同一個連接中，HTTP 完成一個事務（請求與響應），才能處理下一個事務，也就是說在發(fā)出請求等待響應的過程中，是沒辦法做其他事情的，如果響應遲遲不來，那么后續(xù)的請求是無法發(fā)送的，也造成了隊頭阻塞的問題。

而 HTTP/2 引出了 Stream 概念，多個 Stream 復用在一條 TCP 連接。

從上圖可以看到，1 個 TCP 連接包含多個 Stream，Stream 里可以包含 1 個或多個 Message，Message 對應 HTTP/1 中的請求或響應，由 HTTP 頭部和包體構成。Message 里包含一條或者多個 Frame，Frame 是 HTTP/2 最小單位，以二進制壓縮格式存放 HTTP/1 中的內容（頭部和包體）。

針對不同的 HTTP 請求用獨一無二的 Stream ID 來區(qū)分，接收端可以通過 Stream ID 有序組裝成 HTTP 消息，不同 Stream 的幀是可以亂序發(fā)送的，因此可以并發(fā)不同的 Stream ，也就是 HTTP/2 可以并行交錯地發(fā)送請求和響應。

比如下圖，服務端并行交錯地發(fā)送了兩個響應： Stream 1 和 Stream 3，這兩個 Stream 都是跑在一個 TCP 連接上，客戶端收到后，會根據相同的 Stream ID 有序組裝成 HTTP 消息。

4、服務器推送

HTTP/2 的服務端可以主動向客戶端發(fā)送消息。

客戶端和服務器雙方都可以建立 Stream， Stream ID 也是有區(qū)別的，客戶端建立的 Stream 必須是奇數號，而服務器建立的 Stream 必須是偶數號。

比如下圖，Stream 1 是客戶端向服務端請求的資源，屬于客戶端建立的 Stream，所以該 Stream 的 ID 是奇數（數字 1）；Stream 2 和 4 都是服務端主動向客戶端推送的資源，屬于服務端建立的 Stream，所以這兩個 Stream 的 ID 是偶數（數字 2 和 4）。

再比如，客戶端通過 HTTP/1.1 請求從服務器那獲取到了 HTML 文件，而 HTML 可能還需要依賴 CSS 來渲染頁面，這時客戶端還要再發(fā)起獲取 CSS 文件的請求，需要兩次消息往返，而在 HTTP/2 中，客戶端在訪問 HTML 時，服務器可以直接主動推送 CSS 文件，減少了消息傳遞的次數。

HTTP/2 有什么缺陷？

HTTP/2 通過 Stream 的并發(fā)能力，解決了 HTTP/1 在HTTP 這一層面隊頭阻塞的問題，但是 HTTP/2 還是存在?TCP 這一層面的隊頭阻塞。

HTTP/2 是基于 TCP 協(xié)議來傳輸數據的，TCP 是字節(jié)流協(xié)議，TCP 層必須保證收到的字節(jié)數據是完整且連續(xù)的，這樣內核才會將緩沖區(qū)里的數據返回給 HTTP 應用，那么當「前 1 個字節(jié)數據」沒有到達時，后收到的字節(jié)數據只能存放在內核緩沖區(qū)里，只有等到這 1 個字節(jié)數據到達時，HTTP/2 應用層才能從內核中拿到數據，這就是 HTTP/2 隊頭阻塞問題。

舉個例子，如下圖：

圖中發(fā)送方發(fā)送了很多個 packet，每個 packet 都有自己的序號，你可以認為是 TCP 的序列號，其中 packet 3 在網絡中丟失了，即使 packet 4-6 被接收方收到后，由于內核中的 TCP 數據不是連續(xù)的，于是接收方的應用層就無法從內核中讀取到，只有等到 packet 3 重傳后，接收方的應用層才可以從內核中讀取到數據，這就是 HTTP/2 的隊頭阻塞問題，是在 TCP 層面發(fā)生的。

所以，一旦發(fā)生了丟包現象，就會觸發(fā) TCP 的重傳機制，這樣在一個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。

HTTP/3 做了哪些優(yōu)化？

前面提到 HTTP/1.1 和 HTTP/2 都有隊頭阻塞的問題：

• HTTP/1.1 中的管道雖然解決了請求的隊頭阻塞，但是沒有解決響應的隊頭阻塞，因為服務端需要按順序響應收到的請求，如果服務端處理某個請求消耗的時間比較長，那么只能等響應完這個請求后， 才能處理下一個請求，這屬于 HTTP 層隊頭阻塞。
• HTTP/2 雖然通過多個請求復用一個 TCP 連接解決了 HTTP 的隊頭阻塞 ，但是一旦發(fā)生丟包，就會阻塞住所有的 HTTP 請求，這屬于 TCP 層隊頭阻塞。?

HTTP/2 隊頭阻塞的問題是因為 TCP，所以?HTTP/3 把 HTTP 下層的 TCP 協(xié)議改成了 UDP。

UDP 發(fā)送是不管順序，也不管丟包的，所以不會出現像 HTTP/2 隊頭阻塞的問題。

雖然 UDP 是不可靠傳輸的，但基于 UDP 的?QUIC 協(xié)議?可以實現類似 TCP 的可靠性傳輸。

QUIC 有以下 3 個特點。

• 無隊頭阻塞
• 更快的連接建立
• 連接遷移

1、無隊頭阻塞

QUIC 協(xié)議也有類似 HTTP/2 Stream 與多路復用的概念，也是可以在同一條連接上并發(fā)傳輸多個 Stream，Stream 可以認為就是一條 HTTP 請求。

QUIC 連接上的多個 Stream 之間是獨立的，當某個流發(fā)生丟包時，只會阻塞這個流，其他流不會受到影響，不存在隊頭阻塞問題。

而HTTP/2 只要某個流中的數據包丟失了，其他流也會受影響。

2、更快的連接建立

對于 HTTP/1 和 HTTP/2 協(xié)議，TCP 和 TLS 是分層的，分別屬于內核實現的傳輸層、openssl 庫實現的表示層，因此它們需要分批次來握手，先 TCP 握手，再 TLS 握手。

HTTP/3 在傳輸數據前雖然需要 QUIC 協(xié)議握手，但是這個握手過程只需要 1 RTT，握手的目的是為確認雙方的「連接 ID」，連接遷移就是基于連接 ID 實現的。

但是 HTTP/3 的 QUIC 協(xié)議并不是與 TLS 分層，而是 QUIC 內部包含了 TLS，它在自己的幀會攜帶 TLS 里的“記錄”，再加上 QUIC 使用的是 TLS/1.3，因此僅需 1 個 RTT 就可以「同時」完成建立連接與密鑰協(xié)商，如下圖：

甚至，在第二次連接的時候，應用數據包可以和 QUIC 握手信息（連接信息 + TLS 信息）一起發(fā)送，達到 0-RTT 的效果。

如下圖右邊部分，HTTP/3 當會話恢復時，有效負載數據與第一個數據包一起發(fā)送，可以做到 0-RTT（下圖的右下角）：

3、連接遷移

基于 TCP 傳輸協(xié)議的 HTTP 協(xié)議，由于是通過四元組（源 IP、源端口、目的 IP、目的端口）確定一條 TCP 連接。

那么當移動設備的網絡從 4G 切換到 WIFI 時，意味著 IP 地址變化了，那么就必須要斷開連接，然后重新建立連接。而建立連接的過程包含 TCP 三次握手和 TLS 四次握手的時延，以及 TCP 慢啟動的減速過程，給用戶的感覺就是網絡突然卡頓了一下，因此連接的遷移成本是很高的。

而 QUIC 協(xié)議沒有用四元組的方式來“綁定”連接，而是通過連接 ID?來標記通信的兩個端點，客戶端和服務器可以各自選擇一組 ID 來標記自己，因此即使移動設備的網絡變化后，導致 IP 地址變化了，只要仍保有上下文信息（比如連接 ID、TLS 密鑰等），就可以“無縫”地復用原連接，消除重連的成本，沒有絲毫卡頓感，達到了連接遷移的功能。

所以， QUIC 是一個在 UDP 之上的偽?TCP + TLS + HTTP/2 的多路復用的協(xié)議。

QUIC 是新協(xié)議，對于很多網絡設備，根本不知道什么是 QUIC，只會當做 UDP，這樣會出現新的問題，因為有的網絡設備是會丟掉 UDP 包的，而 QUIC 是基于 UDP 實現的，那么如果網絡設備無法識別這個是 QUIC 包，那么就會當作 UDP包，然后被丟棄。

HTTP/3 現在普及的進度非常的緩慢，不知道未來 UDP 是否能夠逆襲 TCP。

HTTP/1.1相較于HTTP/1.0新增了長連接，解決了請求時的隊頭阻塞，但沒有解決響應時的隊頭阻塞。

而HTTP/2進行了頭部壓縮，以及二進制格式傳輸，并基于HTTPS將多個 Stream 復用在一條 TCP 連接中，解決了HTTP層面請求和響應的隊頭阻塞，通過Stream ID來區(qū)分不同的流，并且不同 Stream 的幀是可以亂序發(fā)送的，再由接收端通過 Stream ID 有序組裝成 HTTP 消息，但沒有解決TCP層面的隊頭阻塞，如果一個Stream中的包丟了，就會觸發(fā) TCP 的重傳機制，這樣在一個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。HTTP/2 的服務端可以主動向客戶端發(fā)送消息。

HTTP/3通過在TCP層使用UDP而不是TCP來解決HTTP/2在TCP層存在的隊頭阻塞，并且基于 UDP 的?QUIC 協(xié)議?可以實現類似 TCP 的可靠性傳輸。QUIC 連接上的多個 Stream 之間是獨立的，當某個流發(fā)生丟包時，只會阻塞這個流，其他流不會受到影響，不存在隊頭阻塞問題。對于 HTTP/1 和 HTTP/2 協(xié)議，TCP 和 TLS 是分層的，需要先 TCP 握手，再 TLS 握手，而HTTP/3 的 QUIC 協(xié)議并不是與 TLS 分層，而是 QUIC 內部包含了 TLS，所以只需要QUIC 協(xié)議握手。連接遷移上QUIC 協(xié)議沒有用四元組的方式來“綁定”連接，而是通過連接 ID?來標記通信的兩個端點，客戶端和服務器可以各自選擇一組 ID 來標記自己，因此即使移動設備的網絡變化后，導致 IP 地址變化了，只要仍保有上下文信息（比如連接 ID、TLS 密鑰等），就可以“無縫”地復用原連接，消除重連的成本，沒有絲毫卡頓感，達到了連接遷移的功能。但HTTP/3 現在普及的進度非常的緩慢，不知道未來 UDP 是否能夠逆襲 TCP。文章來源地址http://www.zghlxwxcb.cn/news/detail-848394.html

到了這里，關于HTTP 常見面試題（計算機網絡）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！