1. Http

1.1 Http的定義

超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）是用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。它是互聯(lián)網(wǎng)上最廣泛應(yīng)用的數(shù)據(jù)通信協(xié)議之一，尤其對于萬維網(wǎng)（WWW）服務(wù)而言是至關(guān)重要的基礎(chǔ)。HTTP協(xié)議定義了客戶端（如網(wǎng)頁瀏覽器）和服務(wù)器之間的通信格式和交互方式。

1.2 Http協(xié)議的特點

• 請求/響應(yīng)模型
  • HTTP采用客戶端發(fā)起請求，服務(wù)器返回響應(yīng)的模式進行工作。客戶端通過發(fā)送一個HTTP請求來獲取或提交網(wǎng)頁資源，服務(wù)器根據(jù)請求內(nèi)容生成相應(yīng)的HTTP響應(yīng)并回送給客戶端。
• 無狀態(tài)性
  • HTTP協(xié)議本身是無狀態(tài)的，這意味著每次請求都是獨立處理，服務(wù)器不保留客戶端請求之間的任何上下文信息。后來引入的Cookie和Session機制彌補了這一特性帶來的問題，允許在多次請求間維持狀態(tài)信息。
• 基于TCP/IP
  • HTTP通常運行在TCP/IP協(xié)議棧的應(yīng)用層之上，默認(rèn)使用TCP端口80進行通信。HTTPS（安全HTTP）則使用SSL/TLS加密，在默認(rèn)情況下運行在TCP端口443上。
• 消息結(jié)構(gòu)
  • HTTP消息包括請求消息和響應(yīng)消息，它們由起始行、頭部（headers）、空行和可選的消息主體組成。起始行定義了操作方法（GET、POST等）和目標(biāo)資源的URI；頭部包含了若干屬性值對，描述了請求或響應(yīng)的附加信息；消息主體承載了實際要傳輸?shù)臄?shù)據(jù)內(nèi)容，如HTML文檔、圖片或其他類型的數(shù)據(jù)。
• 版本演化
  • HTTP協(xié)議經(jīng)歷了多個版本的發(fā)展，例如HTTP/1.0、HTTP/1.1、HTTP/2和HTTP/3，每個新版本都在性能、效率、安全性等方面有所改進。

1.3 Http協(xié)議的缺點

• 明文運輸
  • 導(dǎo)致可能會被竊聽
• 不驗證報文的完整性
  • 導(dǎo)致可能會被篡改
• 無法驗證上方的身份
  • 可能會出現(xiàn)偽裝攻擊

1.3.1 如何解決“明文傳輸”

可以使用對稱加密，即加密和解密使用的是同一密鑰S。但是如何把密鑰交到對方手上就是一個很大的問題。

為了解決對稱加密中的密鑰分發(fā)難題，數(shù)學(xué)家們設(shè)計出了非對稱加密體系。非對稱加密算法的核心特點是采用一對密鑰，一個是公開的公鑰，另一個是私密的私鑰。這兩把密鑰不是互相解密的關(guān)系，而是具有特定的匹配性：用公鑰加密的數(shù)據(jù)只能通過對應(yīng)的私鑰解密，私鑰加密的可以用公鑰進行解密。

設(shè)想場景是這樣的：假設(shè)A作為客戶端，B作為服務(wù)端。首先，A和B各自生成一對非對稱密鑰，即公鑰和私鑰，并將各自的公鑰安全地發(fā)布在網(wǎng)絡(luò)上，使得任何人都能獲取到A的公鑰A_pub和B的公鑰B_pub。

當(dāng)A需要向B發(fā)送加密信息時，A會使用從網(wǎng)絡(luò)上獲取到的B的公鑰B_pub來加密要發(fā)送的信息。這樣一來，即便信息在互聯(lián)網(wǎng)上傳輸?shù)倪^程中被第三方截獲，由于只有B持有的私鑰B_priv能夠解密這條信息，所以他人無法解讀和篡改其中的內(nèi)容。

最后，當(dāng)B接收到經(jīng)由其公鑰加密的密文后，只需使用自己的私鑰B_priv對其進行解密，從而確保了通信的保密性和完整性。通過這種方法，非對稱加密算法有效地解決了在開放網(wǎng)絡(luò)環(huán)境下安全傳輸密鑰的問題，保障了數(shù)據(jù)在傳輸過程中的安全。

存在的問題

如果有一個中間人M在客戶端和服務(wù)端獲取對方公鑰的時候，用自己的公鑰M進行了替換。那么中間人不僅可以解析消息，還可以篡改消息。因為客戶端A所認(rèn)為的公鑰B其實是公鑰M，服務(wù)端認(rèn)為的公鑰A其實也是公鑰M。這就涉及到了一個問題，如何驗證接收到的公鑰是你要的公鑰。

1.3.2 利用數(shù)字證書

因為服務(wù)端的公鑰無法在客戶端證明確實是來自于服務(wù)端的，所以需要找一個第三方機構(gòu)來做公證證明這個公鑰確實是來自于服務(wù)端的。那怎么做公證呢？
服務(wù)端去證書授權(quán)中心申請證書，服務(wù)端會把自己的網(wǎng)站信息以及服務(wù)端公鑰給到證書授權(quán)中心那邊，而證書授權(quán)中心會根據(jù)這些生成一張由網(wǎng)站信息、證書信息、證書授權(quán)中心的數(shù)字簽名以及服務(wù)端公鑰等組成的證書。這里需要注意的是網(wǎng)站信息、證書信息、服務(wù)端公鑰等信息在證書中都是以明文形式保存的。

新的問題來了：

• 如何保證這些明文沒有被篡改過？
  • 我們可以計算一個對應(yīng)的消息摘要值，當(dāng)明文被修改后，消息摘要值就對不上了
• 又有小朋友會問，那我如果修改明文后，重新計算了消息摘要值并替換呢？
  • 那這個時候就需要對這個摘要利用CA的私鑰進行數(shù)字簽名（如果想要生成一個對應(yīng)的數(shù)字簽名就需要CA的私鑰，很明顯中間者無法獲得）。
  • 當(dāng)客戶端收到后就可以利用（消息摘要，數(shù)字簽名，CA的公鑰）進行驗證
  • 中間值修改消息后，即使生成新的消息摘要和數(shù)字簽名也無法和CA的公鑰進行匹配
• 新的問題又出現(xiàn)了，CA的公鑰如何獲得呢？
  • CA機構(gòu)的公鑰是預(yù)裝在操作系統(tǒng)中的，就這解決了公鑰的來源問題。

代碼如下：

# 導(dǎo)入rsa庫
import rsa
# RSA密鑰對生成
(public_key, private_key) = rsa.newkeys(2048)  # 生成2048位密鑰對
# RSA加密
message = b"This is a secret message"
cipher_text = rsa.encrypt(message, public_key)
# RSA解密
decrypted_message = rsa.decrypt(cipher_text, private_key)
# RSA數(shù)字簽名
message_hash = rsa.compute_hash(message, 'SHA-256')  # 計算消息摘要
signature = rsa.sign(message_hash, private_key, 'SHA-256')
# 驗證簽名
is_signature_valid = rsa.verify(message_hash, signature, public_key)
if is_signature_valid:print("驗證簽名有效")
else:print("中途被修改啦")

2.Https

HTTPS（全稱為Hypertext Transfer Protocol Secure）是一種網(wǎng)絡(luò)安全協(xié)議，設(shè)計用于在互聯(lián)網(wǎng)上提供安全的通信和數(shù)據(jù)傳輸。它是在標(biāo)準(zhǔn)HTTP協(xié)議的基礎(chǔ)上添加了一層安全措施，具體來說就是整合了SSL（Secure Sockets Layer）或其后續(xù)版本TLS（Transport Layer Security）協(xié)議，以實現(xiàn)數(shù)據(jù)加密、服務(wù)器身份驗證以及消息完整性校驗等功能。

當(dāng)瀏覽器和服務(wù)器通過HTTPS連接時，它們會先執(zhí)行握手過程來協(xié)商加密算法和交換公鑰等信息，從而建立一個安全的連接通道。所有在HTTPS連接上傳輸?shù)臄?shù)據(jù)都會經(jīng)過加密處理，這確保了敏感信息（如密碼、信用卡號和個人信息）在網(wǎng)絡(luò)中傳輸時不會被竊聽或篡改。

此外，HTTPS還提供了服務(wù)器身份認(rèn)證功能，通過證書頒發(fā)機構(gòu)簽發(fā)的SSL證書，客戶端（如瀏覽器）可以驗證服務(wù)器的真實身份，防止中間人攻擊和仿冒網(wǎng)站。

總結(jié)來說，HTTPS的主要特點包括：

數(shù)據(jù)加密：使用對稱加密和非對稱加密相結(jié)合的方式來加密客戶端和服務(wù)端之間的通信內(nèi)容。
身份驗證：服務(wù)器通過SSL/TLS證書向客戶端證明其真實身份。
保證數(shù)據(jù)完整性：通過消息認(rèn)證碼（MAC）來防止數(shù)據(jù)在傳輸過程中被篡改。
默認(rèn)使用端口號443而非HTTP的80端口。

2.1 為什么Https還有對稱加密

因為非對稱加密需要對信息進行加解密，這其中是非常耗時的，對稱加密算法比非對稱加密算法快大約1500倍！所以，HTTPS在通過非對稱加密進行身份驗證完畢后，后續(xù)通信會通過對稱加密來進行，我們來看看是怎么實現(xiàn)的。

2.2 Https單向認(rèn)證

1. 客戶端向服務(wù)端發(fā)送SSL協(xié)議版本號、加密算法種類、隨機數(shù)等信息。
2. 服務(wù)端給客戶端返回服務(wù)端申請的證書（包含服務(wù)端公鑰B、數(shù)字簽名）、SSL協(xié)議版本號、加密算法種類、隨機數(shù)等信息。
3. 客戶端拿到服務(wù)端返回的證書驗證服務(wù)端的合法性，包括：
   • 證書是否過期
   • 該CA機構(gòu)是否可靠
   • 返回的公鑰是否能正確解開返回證書中的數(shù)字簽名
   • 服務(wù)器證書上的域名是否和服務(wù)器的實際域名相匹配
     驗證通過后，將繼續(xù)進行通信，否則，終止通信
4. 客戶端向服務(wù)端發(fā)送自己所能支持的對稱加密方案，供服務(wù)端進行選擇。
5. 服務(wù)端在客戶端提供的加密方案中選擇加密程度最高的加密方式。
6. 服務(wù)端將選擇好的加密方案通過明文方式返回給客戶端。
7. 客戶端接收到服務(wù)端返回的加密方式后，使用該加密方式生成產(chǎn)生隨機碼，用作通信過程中對稱加密密鑰，使用服務(wù)端返回的公鑰B進行加密，將加密后的隨機碼發(fā)送至服務(wù)端。
8. 服務(wù)端收到客戶端返回的加密信息后，使用自己的私鑰B進行解密，獲取對稱加密密鑰。 在接下來的會話中，服務(wù)端和客戶端將會使用該對稱加密密鑰進行對稱加密，保證通信過程中信息的安全。

2.3 Https雙向認(rèn)證

1. 客戶端向服務(wù)端發(fā)送SSL協(xié)議版本號、加密算法種類、隨機數(shù)等信息。
2. 服務(wù)端給客戶端返回服務(wù)端申請的證書（包含服務(wù)端公鑰B、數(shù)字簽名）、SSL協(xié)議版本號、加密算法種類、隨機數(shù)等信息。
3. 客戶端拿到服務(wù)端返回的證書驗證服務(wù)端的合法性，包括：
   • 證書是否過期
   • 該CA機構(gòu)是否可靠
   • 返回的公鑰是否能正確解開返回證書中的數(shù)字簽名
   • 服務(wù)器證書上的域名是否和服務(wù)器的實際域名相匹配
     驗證通過后，將繼續(xù)進行通信，否則，終止通信
4. 服務(wù)端要求客戶端發(fā)送客戶端的證書，客戶端會將自己的證書發(fā)送至服務(wù)端。
5. 服務(wù)端驗證客戶端的證書，通過驗證后，獲得客戶端公鑰A。
6. 客戶端向服務(wù)端發(fā)送自己所能支持的對稱加密方案，供服務(wù)端進行選擇。
7. 服務(wù)端在客戶端提供的加密方案中選擇加密程度最高的加密方式。
8. 服務(wù)端將選擇好的加密方案通過客戶端公鑰A加密后返回給客戶端。
9. 客戶端接收到服務(wù)端返回的信息后，通過客戶端私鑰A解密，獲取到對稱加密方式后，使用該加密方式生成產(chǎn)生隨機碼，用作通信過程中對稱加密密鑰，使用服務(wù)端返回的公鑰B進行加密，將加密后的隨機碼發(fā)送至服務(wù)端。
10. 服務(wù)端收到客戶端返回的加密信息后，使用自己的私鑰B進行解密，獲取對稱加密密鑰。 在接下來的會話中，服務(wù)端和客戶端將會使用該對稱加密密鑰進行對稱加密，保證通信過程中信息的安全。
    使用單向認(rèn)證還是雙向認(rèn)證是由服務(wù)端來決定的（默認(rèn)單向）

3.Http各個版本

3.1 Http/0.9

HTTP/0.9 是超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）的第一個正式版本。這個早期版本于1991年隨著萬維網(wǎng)（World Wide Web）的誕生而出現(xiàn)，由蒂姆·伯納斯-李（Tim Berners-Lee）設(shè)計。
特點：

• 請求方式簡單
  • 只支持GET請求方法。請求行中只包含要獲取的資源文件名，不包含版本號、主機名或任何其他HTTP頭信息。
• 響應(yīng)格式簡單
  • 服務(wù)器回應(yīng)的內(nèi)容直接跟在換行符后面，沒有狀態(tài)行、響應(yīng)頭或者空行，只有純文本或HTML內(nèi)容
• 無錯誤代碼反饋
  • 如果請求失敗，服務(wù)器無法通過HTTP協(xié)議返回特定的錯誤代碼，只能關(guān)閉連接
• 不支持持久連接
  • 每個請求與響應(yīng)都對應(yīng)一個新的TCP連接，連接在每次傳輸完成后立即關(guān)閉

3.2 Http/1.0

HTTP/1.0 是超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）的第二個正式版本，發(fā)布于1996年，是對早期HTTP/0.9的重大改進。相比于HTTP/0.9，HTTP/1.0引入了許多關(guān)鍵特性和增強功能，使其更適合大規(guī)模的Web服務(wù)：
特點

• 請求方法多樣化
  • 除了基本的GET方法之外，新增了POST方法，允許客戶端向服務(wù)器發(fā)送數(shù)據(jù)。
• 狀態(tài)碼系統(tǒng)
  • 在HTTP響應(yīng)中加入了狀態(tài)碼，比如常見的200（成功）、404（未找到）、500（服務(wù)器內(nèi)部錯誤）等
• 頭部信息
  • HTTP/1.0支持在請求和響應(yīng)中攜帶頭部信息，比如User-Agent、Content-Type、Connection等
• 持續(xù)連接選項
  • 盡管默認(rèn)情況下HTTP/1.0仍采用“每個請求-響應(yīng)后關(guān)閉連接”的模式，但該版本首次引入了Connection: keep-alive頭部字段，允許客戶端和服務(wù)器協(xié)商保持TCP連接打開，以便復(fù)用連接處理多個請求，從而提高性能。
• 多部分?jǐn)?shù)據(jù)
  • HTTP/1.0支持多部分編碼（multipart encoding），允許在一個HTTP消息體中發(fā)送多個不同類型的實體，這一特性在文件上傳等場景下尤為重要

3.3 Http/1.1

HTTP/1.1 是超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）的第三個主要版本，發(fā)布于1999年，相較于HTTP/1.0做出了許多重要的改進和優(yōu)化，旨在提高網(wǎng)絡(luò)應(yīng)用的性能和功能性。
特點

• 持久連接（Persistent Connections）
  • HTTP/1.1默認(rèn)啟用持久連接，即TCP連接在處理完一個請求之后并不會立即關(guān)閉，而是保持一段時間內(nèi)的開放狀態(tài)，以便處理更多的請求，大大減少了建立連接的開銷，提升了整體性能。
• 管道化（Pipelining）
  • 在同一TCP連接上，客戶端可以連續(xù)發(fā)送多個請求而不需等待前一個請求的響應(yīng)，服務(wù)器則按照請求到達(dá)的順序依次響應(yīng)。雖然管道化理論上可以進一步提升性能，但由于隊頭阻塞（Head of Line Blocking）的問題，在實際應(yīng)用中效果有限。
• 緩存控制（Cache Control）
  • HTTP/1.1增強了緩存機制，引入了新的頭部字段如Cache-Control、Expires、ETag等，使緩存管理更加靈活和精細(xì)。
• 分塊傳輸編碼（Chunked Transfer Encoding）
  • 允許動態(tài)生成內(nèi)容的長度未知時，服務(wù)器將響應(yīng)內(nèi)容分成若干個塊進行傳輸，每一塊都有自己的大小標(biāo)識，這樣客戶端可以在接收到部分?jǐn)?shù)據(jù)后就開始處理，無需預(yù)先知道整個響應(yīng)的大小。
• Host頭域
  • 強制要求客戶端在請求中指定Host頭域，使得一臺服務(wù)器可以托管多個域名和站點，為虛擬主機技術(shù)提供了基礎(chǔ)。（簡單來說就上在一個ip：port上可以部署多個網(wǎng)站，使用Host頭域進行區(qū)分）
• 請求方法擴展
  • HTTP/1.1定義了更多的請求方法，如PUT、DELETE、OPTIONS、HEAD等，增加了HTTP協(xié)議的交互能力。
• 錯誤通知更完善
  • HTTP/1.1提供了更為豐富的狀態(tài)碼和錯誤信息，幫助開發(fā)者更好地理解和調(diào)試應(yīng)用程序。
• 帶寬優(yōu)化
  • 通過gzip壓縮等方式，HTTP/1.1支持內(nèi)容壓縮傳輸，降低網(wǎng)絡(luò)帶寬消耗。

3.4 Http/2.0

HTTP/2.0 是 HTTP 協(xié)議的繼 HTTP/1.1 后的重要升級版本，于2015年5月正式發(fā)布。HTTP/2.0 的核心目標(biāo)是改善網(wǎng)頁性能，特別是在高并發(fā)場景下減少延遲，提高網(wǎng)絡(luò)資源利用率。主要的新特性包括：
特點

• 多路復(fù)用（Multiplexing）
  • 這是HTTP/2最顯著的改進之一。在HTTP/1.x中，一次TCP連接在同一時刻只能處理一個請求，而在HTTP/2中，一個TCP連接上可以并發(fā)處理多個請求和響應(yīng)，消除了HTTP/1.x中的“隊頭阻塞”問題，大幅提高了頁面加載速度。
• 二進制分幀（Binary Framing）
  • HTTP/2將所有傳輸?shù)男畔⒎指畛啥鄠€幀，這些幀可以交錯、亂序發(fā)送，然后在另一端再重新組裝。每個幀都有專門的目的，如HEADERS幀用于傳輸HTTP首部，DATA幀用于傳輸請求/響應(yīng)主體。
• 頭部壓縮（Header Compression）
  • HTTP/2使用HPACK算法對請求和響應(yīng)的頭部信息進行壓縮，因為HTTP頭部信息往往有很多重復(fù)內(nèi)容，壓縮頭部信息可以顯著減少數(shù)據(jù)傳輸量。
• 服務(wù)器推送（Server Push）
  • 服務(wù)器在客戶端請求一個資源的同時，可以預(yù)測客戶端可能還需要哪些資源，并主動把這些資源推送給客戶端，減少了客戶端發(fā)起請求的延遲和往返時間。
• 優(yōu)先級和流控制
  • HTTP/2允許為每個流設(shè)置優(yōu)先級，以便服務(wù)器合理安排資源發(fā)送順序。另外，通過流控制機制，兩端可以協(xié)調(diào)數(shù)據(jù)發(fā)送速度，防止擁塞和數(shù)據(jù)丟失。
• 單一連接
  • 鼓勵客戶端和服務(wù)器維持一個長連接以供多個請求/響應(yīng)交換，減少建立新連接的開銷

重要概念

HTTP2.0中，有兩個概念非常重要：幀（frame）和流（stream）。
幀是最小的數(shù)據(jù)單位，每個幀會標(biāo)識出該幀屬于哪個流，流是多個幀組成的數(shù)據(jù)流。
所謂多路復(fù)用，即在一個TCP連接中存在多個流，即可以同時發(fā)送多個請求，對端可以通過幀中的表示知道該幀屬于哪個請求。在客戶端，這些幀亂序發(fā)送，到對端后再根據(jù)每個幀首部的流標(biāo)識符重新組裝。通過該技術(shù)，可以避免HTTP舊版本的隊頭阻塞問題，極大提高傳輸性能。

3.5 Http/3.0

HTTP/3.0 是超文本傳輸協(xié)議（HTTP）的最新版本，旨在進一步改進網(wǎng)絡(luò)應(yīng)用的性能和效率。作為HTTP/2.0的繼承者，HTTP/3.0 最顯著的變化是放棄了對TCP的依賴，轉(zhuǎn)而采用基于UDP的QUIC協(xié)議作為傳輸層。

QUIC（Quick UDP Internet Connections）最初由Google提出并開發(fā)，現(xiàn)在已經(jīng)成為IETF標(biāo)準(zhǔn)。QUIC的設(shè)計目標(biāo)在于解決TCP存在的延遲和性能問題，特別是隊頭阻塞（Head-of-line blocking）問題，同時提供類似TCP的可靠傳輸保證，包括流量控制、錯誤檢測和糾正、連接遷移等功能。

特點

• 多路復(fù)用和低延遲
  • 每個HTTP請求/響應(yīng)在QUIC協(xié)議中映射為一個獨立的數(shù)據(jù)流，即使網(wǎng)絡(luò)中某數(shù)據(jù)包丟失，也不會阻塞其它數(shù)據(jù)流，從而減少了延遲。
• 快速連接建立
  • QUIC使用了基于TLS 1.3的快速握手機制，可以實現(xiàn)0-RTT（Zero Round Trip Time）的連接建立，也就是說在某些情況下客戶端可以在第一個數(shù)據(jù)包就發(fā)送請求數(shù)據(jù)，而無需等待握手完成。
• 連接遷移
  • QUIC支持在IP地址改變（如Wi-Fi切換到蜂窩網(wǎng)絡(luò)）時保持連接，這有助于移動設(shè)備在網(wǎng)絡(luò)條件改變時保持活躍連接和流暢體驗。
• 安全集成
  • QUIC內(nèi)建了TLS加密，確保數(shù)據(jù)在傳輸過程中受到保護，同時也簡化了安全傳輸?shù)膶崿F(xiàn)。
• 錯誤恢復(fù)和重傳機制
  • QUIC擁有更好的丟包檢測和重傳策略，可以更快速地識別和補償丟包，從而提高傳輸效率。