帶你重新認識下HTTP協定--面試必備！！

1、HTTP基礎

超文本傳輸協定。

• 協定：HTTP是用在計算機世界裡的協定，它使用計算機能夠了解的語言确立了一種計算機之間交流通信的規範。
• 傳輸：HTTP是一個在計算機世界裡專門用來在倆點之間傳輸資料的約定和規範。HTTP 協定是一個雙向協定
• 超文本：它是文字、圖檔、視訊等的混合體，最關鍵有超連結，能從一個超文本跳轉到另外一個超文本。

總結：HTTP是一個在計算機世界倆點之間傳輸超文本資料的約定和規範

2、HTTP常見字段

HOST：伺服器域名

Content-Length：本次回應的資料長度

Connection：Keep-Alive 是否使用長連結

Accept：用戶端請求時告訴伺服器自己接受哪些格式

Accept-Encoding：告訴伺服器接受哪些壓縮方法

Content-Type：伺服器告訴用戶端本次資料格式

Content-Encoding：伺服器傳回的資料用了什麼壓縮格式

HTTP是基于TCP進行通信的，HTTP協定通過設定回車符、換行符作為HTTP header的邊界，通過Context-Length字段作為HTTP body的邊界。來解決粘包問題。

3、HTTP緩存技術

強制緩存和協商緩存

3.1 強制緩存

隻要浏覽器緩存沒有過期，則直接使用浏覽器的本地緩存，決定是否使用緩存的主動性在于浏覽器這邊。

強緩存利用HTTP響應頭部字段實作

• Cache-Control：相對時間（優先級高）
• Expires：絕對時間

3.2 協商緩存

當我們在浏覽器使用開發者工具的時候，你可能會看到過某些請求的響應碼是 304，這個是告訴浏覽器可以使用本地緩存的資源，通常這種通過服務端告知用戶端是否可以使用緩存的方式被稱為協商緩存。

• 基于時間實作
• 基于唯一辨別實作

協商緩存需要配合強制緩存中Cacha-Control字段來使用，隻有在未能命中強制緩存的時候，才能發起帶有協商緩存字段的請求。

4、HTTP/1.1

優點：

1. 簡單：HTTP基本的封包格式就是header+body，頭部資訊也是key-value簡單文本形式。
2. 靈活易于擴充：HTTP協定裡的各類請求方法、URI/URL、狀态碼、頭字段等每個組成要求都沒有被固定死，都允許開發人員自定義和補充。
3. 應用廣泛和跨平台

缺點：

1. 無狀态
2. 明文傳輸
3. 不安全

4.1 HTTP性能：

HTTP協定是基于TCP/IP，采用請求-應答通信 模式

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

管道網絡傳輸（預設不開啟）： 即可在一個TCP連結裡面，用戶端可以發起多個請求，隻要第一個請求發出去了，不必等其回來就可以發出第二個請求出去。伺服器必須按照接收請求的順序發送對這些管道化請求的響應。HTTP/1.1 管道解決了請求的隊頭阻塞，但是沒有解決響應的隊頭阻塞。（如果伺服器在處理A請求耗時較長，後續的請求都會被阻塞住）

5、HTTP/1.1、HTTP/2、HTTP/3演變

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

• 使用長連接配接改善HTTP/1.0短連結造成的性能開銷
• 使用管道網絡傳輸

HTTP1.1性能瓶頸

• 請求/相應頭部未經壓縮就發送，首部資訊越多延遲越大，隻能壓縮Body部分
• 發送冗長的首部。每次互相發送相同的首部造成。
• 伺服器是按請求的順序相應的。隊頭阻塞
• 沒有請求優先級控制
• 請求隻能從用戶端開始，伺服器隻能被動響應

5.1 HTTP/2做了什麼優化

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

• 頭部壓縮
• 二進制格式
• 并發傳輸
• 伺服器主動推送資源

1. 頭部壓縮

如果同時發出多個請求且它們的頭一樣或者相似，那麼協定會幫你消除重複的部分

利用HPACK算法：在用戶端和伺服器同時維護一張頭資訊表。所有字段都會存入這個表，生成一個索引号，相同的頭部隻發送索引号。

1. 二進制格式

頭資訊和資料體都是二進制，統稱為幀：頭資訊幀和資料幀

1. 并發傳輸

HTTP/1.1的實作是基于請求-相應模式。同一個連接配接中，HTTP完成一個事務，才能處理下一個事務。

HTTP/2引入Stream。多個Stream複用在一條TCP連接配接。一個TCP連接配接包好多個Stream，Stream裡包含一個或多個Message，對應HTTP/1中的請求和響應。Message裡包含一個或多個Frame，Frame是HTTP/2最小機關。以二進制存放HTTP/1中的内容（頭部和包體）

針對不同的HTTP請求用獨一無二的Stream ID來區分，接收端可以通過Stream ID有序組成HTTP消息，不同的額Stream可以亂序發送的。是以可以并發不同的Stream。

1. 伺服器推送

HTTP/2中用戶端和伺服器雙方都可以建立Stream。用戶端Stream ID為奇數、伺服器Stream ID為偶數

例如用戶端通過 HTTP/1.1 請求從伺服器那擷取到了 HTML 檔案，而 HTML 可能還需要依賴 CSS 來渲染頁面，這時用戶端還要再發起擷取 CSS 檔案的請求，需要兩次消息往返，HTTP/2中伺服器可以主動推送CSS檔案。

缺陷：

HTTP/2還是存在對頭阻塞問題。但不是在HTTP層，而是在TCP這一層。

HTTP/2是基于TCP協定來傳輸資料，TCP是位元組流協定，TCP層必須保證收到的位元組資料是完成且連續的，然後核心才會講緩沖區裡的資料傳回給HTTP應用，那麼目前一個位元組資料沒有到達時，後收到的位元組資料隻能存放在核心緩沖區裡，隻有等到上一個請求最後一個位元組資料到達時，HTTP/2應用層才能從核心中拿到資料。

是以一旦發生丢包現象，就會觸發TCP的重傳機制，這個TCP連接配接中的所有HTTP請求都必須等待這個丢了的包被重傳回來。

C++音視訊學習資料免費擷取方法：關注音視訊開發T哥，點選「連結」即可免費擷取2023年最新C++音視訊開發進階獨家免費學習大禮包！

5.2 HTTP/3 做了哪些優化？

因為HTTP/2在TCP層出現了隊頭阻塞，是以HTTP/3把HTTP下層的TCP協定改成了UDP

UDP 發送是不管順序，并且HTTP/3基于UDP的QUIC協定可以實作類似TCP的可靠性傳輸

QUIC特點：

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

1. 無隊頭阻塞

QUIC協定也有類似HTTP/2 Stream多路複用概念，在一個連接配接上建立并發傳輸多個Stream，Stream可以認為就是一條HTTP請求

QUIC 有自己的一套機制可以保證傳輸的可靠性的。當某個流發生丢包時，隻會阻塞這個流，其他流不會受到影響，是以不存在隊頭阻塞問題。 是以QUIC連接配接上的多個Stream之間并沒有依賴，都是獨立的。

1. 更快的連接配接

對于HTTP/1和HTTP/2協定，TCP和TLS時分層的，需要分批次來握手，先TCP握手，在TLS握手。

但是HTTP/3的QUIC協定并不是與TLS分層，而是QUIC包含了TLS。它在自己的幀會攜帶TLS裡的記錄，同時QUIC使用的是TLS/1.3，隻需要1個RTT就可以同時完成建立連接配接與密鑰協商。

、

甚至第二次連接配接時，應用資料包可以和QUIC握手資訊一起發送，達到0-RTT。

1. 連接配接遷移

基于TCP傳輸協定的HTTP協定，通過四元組（源IP、源端口、目的IP、目的端口）确定一條TCP連接配接。那麼例如裝置從4G切換到WIFI時，意味着IP位址變了，那麼就必須重建立立連接配接

而QUIC協定沒有用四元組來綁定連接配接，而是通過連接配接ID來标記通信的倆個端點，用戶端和服務端各選擇一組ID來标記自己。是以即使網絡變化，但是隻要仍保有上下文資訊（比如連接配接 ID、TLS 密鑰等），就可以無縫第複用原連接配接。

是以，QUIC是一個在UDP之上的僞TCP+TLS+HTTP/2的多路複用協定

6、HTTP和HTTPS

差別：

• HTTP是超文本傳輸協定，資訊是明文傳輸，存在安全風險，HPPTS在TCP和HTTP網絡層增加了SSL/TLS安全協定，使得封包能夠加密傳輸
• HTTP 連接配接建立相對簡單， TCP 三次握手之後便可進行 HTTP 的封包傳輸。而 HTTPS 在 TCP 三次握手之後，還需進行 SSL/TLS 的握手過程，才可進入加密封包傳輸。
• HTTP 預設端口号是 80，HTTPS 預設端口号是 443。
• HTTPS協定需要像CA（證書權威機構）申請數字證書

HTTP由于是明文傳輸，存在三個風險：竊聽風險，篡改風險，冒充風險

HTTPS加入了SSL/TLS協定，解決了上述問題。包括資訊加密，校驗機制，身份證書

1. 混合加密

HTTP采用的是對稱加密和非對稱加密結合的混合加密方式

• 在通信建立前采用非對稱加密的方式交換會話密鑰
• 通信過程中全部使用對稱加密的會話密鑰加密明文資料

1. 摘要算法+數字簽名

為了保證傳輸的内容不被篡改，對内容計算出一個【指紋】，然後同内容一同傳輸對方，對方接收後，先是對内容也算出一個指紋，然後跟發送方指紋做比較，如果指紋相同。證明内容沒有被篡改。

用摘要算法（哈希函數）來計算出内容的哈希值，這個哈希值是唯一的。且無法通過哈希值推算出内容

通過數字簽名來保證傳輸的内容不被替換掉。利用非對稱加密， 私鑰是由服務端保管，然後服務端會向用戶端頒發對應的公鑰。如果用戶端收到的資訊，能被公鑰解密，就說明該消息是由伺服器發送的。

1. 數字證書

在計算機裡，将伺服器公鑰房子數字證書裡（由數字認證機構頒發簡稱CA），隻要證書是可信的，公鑰就是可信的。通過數字證書的方式保證伺服器公鑰的身份，解決冒充的風險。

6.1 HTTPS是如果建立連接配接

SSL/TLS協定基本流程：

• 用戶端像伺服器索要并驗證伺服器的公鑰。
• 雙方協商生産會話密鑰
• 雙方采用會話密鑰進行加密通信

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

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

TLS協定建立過程

1. ClientHello

首先用戶端向伺服器發起加密通信請求，包括用戶端支援的TLS協定版本，用戶端産生的随機數，用戶端支援的密碼套件清單

1. ServerHello

伺服器收到用戶端請求後，像用戶端做出響應。内容包括确認TLS協定版本、伺服器産生的随機數、确認的密碼套件清單、伺服器的數字證書

1. 用戶端回應

用戶端收到伺服器的回應後，首先确認伺服器證書的正确性，如果沒有問題取出弓腰，然後使用它加密向伺服器發送一個随機數随機數、加密通信算法改變通知、告知随後的資訊采用會話密鑰加密通信。表示用戶端的握手階段已經結束。用戶端握手結束通知，并把之前所有内容的資料做個摘要，供伺服器校驗。

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

1. 伺服器最後回應

伺服器收到用戶端的第三個随機數之後，計算出本次會話密鑰。然後向用戶端發送最後消息，加密通信算法改變通知，表示随後資訊都将用會話密鑰通信。伺服器握手結束通知，把之前所有内容的資料做個摘要，供用戶端校驗。

至此整個TLS握手階段結束，用戶端和服務端進入加密通信，使用最普通的HTTP協定。但是會用會話密鑰加密通信的内容

6.2 HTTPS如何保證完整性的

TLS在實作上分為握手協定和記錄協定倆層

• TLS握手協定就是TLS四次握手的過程，負責協商加密算法和生成對稱密鑰，後續用此密鑰來保護應用資料。
• TLS記錄協定負責保護應用程式資料并驗證其完整性和來源，是以對HTTP資料加密是使用記錄協定。TLS記錄協定主要負責消息的壓縮、加密及資料的認證。

• 首先消息會被分割成多個較短的片段，對每個片段進行壓縮。
• 經過壓縮的片段會被加上消息驗證碼（MAC值，是通過雜湊演算法生成的），這是為了保證完整性，并進行資料的認證。通過附加消息認證碼的MAC值，可以識别出篡改，為了防止重播攻擊，在計算消息認證碼時，還加上了片段的編碼。
• 經過壓縮的片段在加上消息認證碼會一起通過對稱密鑰進行加密。
• 上述加密的資料在加上由資料類型、版本号、壓縮後的長度組成的封包頭就是最終的封包資料

原文連結：帶你重新認識下HTTP協定--面試必備！！