3.1 HTTP常見面試題

1、HTTP基本概念：

• 超文本傳輸協議：在計算機世界里專門在「兩點」之間「傳輸」文字、圖片、音頻、視頻等「超文本」數據的「約定和規范」
• HTTP常見的狀態碼 [[Pasted image 20250705140705.png]]
• HTTP常見字段
  • Host 字段：客戶端發送請求時，用來指定服務器的域名
  • Content-Length 字段：服務器在返回數據時本次回應的數據長度。HTTP協議通過設置回車符、換行符作為HTTP header的邊界，通過Content-Length字段作為HTTP body的邊界，這兩個方式都是為了解決“粘包”的問題。
  • Connection 字段：常用于客戶端要求服務器使用「HTTP 長連接」機制，以便其他請求復用
  • Content-Type 字段：用于服務器回應時，告訴客戶端，本次數據是什么格式。（客戶端請求的時候，可以使用 Accept 字段聲明自己可以接受哪些數據格式。）
  • Content-Encoding 字段：說明數據的壓縮方法。表示服務器返回的數據使用了什么壓縮格式（客戶端在請求時，用 Accept-Encoding 字段說明自己可以接受哪些壓縮方法）
    2、GET 與 POST
• GET 的語義是從服務器獲取指定的資源，比如打開瀏覽器文章，瀏覽器就會發送 GET 請求給服務器，服務器就會返回文章的所有文字及資源。GET 請求的參數位置一般是寫在 URL 中[[Pasted image 20250705143554.png]]
• POST 的語義是根據請求負荷（報文body）對指定的資源做出處理，在文章底部留言后點擊「提交」，瀏覽器就會執行一次POST請求，把你的留言文字放進了報文body里，然后拼接好POST請求頭，通過TCP協議發送給服務器。POST 請求攜帶數據的位置一般是寫在報文 body 中[[Pasted image 20250705143636.png]]
• GET 和 POST 請求都是明文的，避免被竊取就要用HTTPS協議 [[Pasted image 20250705144047.png]]
  3、HTTP緩存技術
• 強制緩存：只要瀏覽器判斷緩存沒有過期，則直接使用瀏覽器的本地緩存，決定是否使用緩存的主動性在于瀏覽器這邊。強緩存是利用下面這兩個 HTTP 響應頭部（Response Header）字段Cache-Control和Expires實現[[Pasted image 20250705144933.png]]
• 協商緩存：當我們在瀏覽器使用開發者工具的時候，你可能會看到過某些請求的響應碼是304，這個是告訴瀏覽器可以使用本地緩存的資源，通常這種通過服務端告知客戶端是否可以使用緩存的方式被稱為協商緩存。Etag實現協商緩存的過程：[[Pasted image 20250705150930.png]]
  4、HTTP特性
• HTTP/1.1 優點「簡單、靈活和易于擴展、應用廣泛和跨平臺」
  • 1. 簡單
  • 2. 靈活和易于擴展
    • • HTTPS 就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層；
    • • HTTPS 就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層；
  • 3. 應用廣泛和跨平臺
• HTTP/1.1 缺點「無狀態、明文傳輸」，同時還有一大缺點「不安全」
  • 1. 無狀態雙刃劍：不需要額外記錄狀態信息，減輕服務器負擔，但服務器沒有記憶能力，它在完成有關聯性的操作時會非常麻煩。例如登錄->添加購物車->下單->結算->支付，這系列操作都要知道用戶的身份才行
  • 2. 明文傳輸雙刃劍：抓包調試方便，但信息裸奔
  • 3. 不安全：明文不加密，不驗證通信方身份，無法證明報文完整性（可能被篡改）。可用HTTPS解決，加入SSL/TLS層
• HTTP/1.1 性能
  • 1. 長連接：減少TCP重復建立和斷開的額外開銷
  • 2. 管道網絡傳輸：長連接使得管道傳輸成為可能，即可在同一個TCP連接里面，客戶端可以發起多個請求，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。
  • 3. 隊頭阻塞：順序發送的請求序列中的一個請求因為某種原因被阻塞時，在后面排隊的所有請求也一同被阻塞了
    5、HTTP 與 HTTPS

• HTTP是超文本傳輸協議，信息是明文傳輸，存在安全風險的問題。HTTPS則解決HTTP不安全的缺陷，在TCP和HTTP網絡層之間加入了SSL/TLS安全協議，使得報文能夠加密傳輸。
• 如何解決HTTP的缺點
  • 1. 混合加密：采用的是對稱加密和非對稱加密結合的「混合加密」方式，解決明文竊聽問題。
    • 在通信建立前采用非對稱加密的方式交換「會話秘鑰」
    • 在通信過程中全部使用對稱加密的「會話秘鑰」的方式加密明文數據
  • 2. 摘要算法 + 數字簽名：解決內容篡改
    • 用摘要算法（哈希函數）來計算出內容的哈希值
    • 非對稱加密算法（數字前面算法）：通過「私鑰加密，公鑰解密」的方式，來確認消息的身份[[Pasted image 20250705161048.png]]
  • 3. 數字證書：將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，實現身份驗證環節

• HTTPS 是如何建立連接的（這部分不太懂）
  • TLS 協議建立的詳細流程
  • 客戶端校驗數字證書的流程
• HTTPS的應用數據是如何保證完整性的（這部分不太懂）
  • TLS 記錄協議負責保護應用程序數據并驗證其完整性和來源
• HTTPS 一定安全可靠嗎
  6、HTTP/1.1、HTTP/2、HTTP/3 演變 [[Pasted image 20250705172849.png]]
• HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
  • • 使用長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。
  • 支持管道（pipeline）網絡傳輸，只要第一個請求發出去了，不必等其回來
• HTTP/2 做了什么優化？
  • HTTP/2 協議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
  • 1. 頭部壓縮：HPACK 算法，在客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表
  • 2. 二進制格式：不再像 HTTP/1.1 里的純文本形式的報文，而是全面采用了二進制格式
  • 3. 并發傳輸：引出了 Stream 概念，多個 Stream 復用在一條 TCP 連接
  • 4. 服務器推送：服務端不再是被動地響應，可以主動向客戶端發送消息
• HTTP/3 做了哪些優化？
  • HTTP/2 雖然通過多個請求復用一個 TCP 連接解決了 HTTP 的隊頭阻塞 ，但是一旦發生丟包，就會阻塞住所有的 HTTP 請求，這屬于 TCP 層隊頭阻塞。HTTP/2 隊頭阻塞的問題是因為 TCP，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！
  • 基于 UDP 的 QUIC 協議 可以實現類似 TCP 的可靠性傳輸。QUIC 有以下 3 個特點。
    • 1、無隊頭阻塞：當某個流發生丟包時，只會阻塞這個流，其他流不會受到影響
    • 2、更快的連接建立：QUIC 內部包含了 TLS
    • 3、連接遷移： QUIC 協議沒有用四元組的方式來“綁定”連接，而是通過連接 ID 來標記通信的兩個端點

3.2 HTTP/1.1 如何優化

1、下面這三種優化思路來優化 HTTP/1.1 協議：

• 盡量避免發送HTTP請求;
• 在需要發送HTTP請求時，考慮如何減少請求次數；
• 減少服務器的HTTP響應的數據大小；
  2、盡量避免發送HTTP請求：緩存技術 [[Pasted image 20250706112045.png]] [[Pasted image 20250705150930.png]]
  3、考慮如何減少請求次數
• 減少重定向請求次數：重定向的工作交由代理服務器完成，就能減少 HTTP 請求次數了
• 合并請求：把多個訪問小文件的請求合并成一個大的請求，減少了重復發送的 HTTP 頭部。
• 延遲發送請求：通過「按需獲取」的方式，來減少第一時間的 HTTP 請求次數
  4、減少服務器的HTTP響應的數據大小
• 無損壓縮：資源經過壓縮后，信息不被破壞，還能完全恢復到壓縮前的原樣，適合用在文本文件、程序可執行文件、程序源代碼。（對原始資源建立統計模型，利用這個統計模型，將常出現的數據用較短的二進制比特序列表示，將不常出現的數據用較長的二進制比特序列表示）客戶端支持的壓縮算法，會在 HTTP 請求中通過頭部中的 Accept-Encoding 字段
• 有損壓縮：解壓的數據會與原始數據不同但是非常接近。HTTP 請求頭部中的 Accept 字段里的「 q 質量因子」，告訴服務器期望的資源質量。

3.3 HTTPS RSA握手解析

1、HTTPS 在 HTTP 與 TCP 層之間加入了 TLS 協議，來解決上述的風險。[[Pasted image 20250706133549.png]]
2、TLS 握手過程，不同的密鑰交換算法，TLS 的握手過程可能會有一些區別。密鑰交換算法，因為考慮到性能的問題，所以雙方在加密應用信息時使用的是對稱加密密鑰，而對稱加密密鑰是不能被泄漏的，為了保證對稱加密密鑰的安全性，所以使用非對稱加密的方式來保護對稱加密密鑰的協商，這個工作就是密鑰交換算法負責的。（最簡單的 RSA 密鑰交換算法）

• 經過「四個消息」就可以完成 TLS 握手，也就是需要 2個 RTT 的時延（RTT（Round-Trip Time）時延是指數據從發送端到接收端并返回發送端所需的總時間，即一次完整的“往返”通信延遲）
  3、RSA 握手過程
• 在RSA密鑰協商算法中，客戶端會生成隨機密鑰，并使用服務端的公鑰加密后再傳給服務端。根據非對
  稱加密算法，公鑰加密的消息僅能通過私鑰解密，這樣服務端解密后，雙方就得到了相同的密鑰（服務端就得到客戶端生成的隨機秘鑰），再用它加密應用消息。
• 使用RSA密鑰協商算法的最大問題是不支持前向保密。因為客戶端傳遞隨機數（用于生成對稱加密密鑰的條件之一）給服務端時使用的是公鑰加密的，服務端收到后，會用私鑰解密得到隨機數。所以一旦服務端的私鑰泄漏了，過去被第三方截獲的所有TLS通訊密文都會被破解。為了解決這個問題，后面就出現了 ECDHE 密鑰協商算法

3.4 HTTPS ECDHE 握手解析

1、HTTPS 常用的密鑰交換算法有兩種，分別是 RSA 和 ECDHE 算法。ECDHE秘鑰交換算法[[Pasted image 20250706153243.png]]

3.5 HTTPS 如何優化

3.6 HTTP/2 牛逼在哪？

1、HTTP/2 出來的目的是為了改善 HTTP 的性能

• 兼容 HTTP/ 1.1
• HPACK 算法壓縮頭部：客戶端和服務器兩端都會建立和維護「字典」，用長度較小的索引號表示重復的字符串，再用 Huffman 編碼壓縮數據，可達到 50%~90% 的高壓縮率。
• 二進制幀：將 HTTP/1 的文本格式改成二進制格式傳輸數據，極大提高了 HTTP 傳輸效率
• 并發傳輸：HTTP/2 通過 Stream 實現的并發
• 服務器主動推送資源

3.7 HTTP/3 強勢來襲

1、HTTP/2 的缺點

• 隊頭阻塞：當 TCP 丟包時，整個 TCP 都要等待重傳
• TCP 與 TLS 的握手時延遲：發起 HTTP 請求時，需要經過 TCP 三次握手和 TLS 四次握手
• 網絡遷移需要重新連接：IP 地址或者端口變動了，就會導致需要 TCP 與 TLS 重新握手（比如 4G 網絡環境切換成 WiFi）
  2、HTTP/3 QUIC協議：將傳輸協議替換成了 UDP，還基于 UDP 協議在「應用層」實現了 QUIC 協議[[Pasted image 20250706191606.png]]
• 無隊頭阻塞
• 更快的連接建立
• 連接遷移

3.8 HTTP 和 RPC 的區別

1、服務發現：在 HTTP 中，你知道服務的域名，就可以通過 DNS 服務去解析得到它背后的 IP 地址；而 RPC 的話，就有些區別，一般會有專門的中間服務去保存服務名和IP信息
2、底層連接形式：RPC 協議一般還會再建個連接池
3、傳輸的內容。

• 將結構體轉為二進制數組的過程就叫序列化，反過來將二進制數組復原成結構體的過程叫反序列化

RPC（Remote Procedure Call），又叫做遠程過程調用。它本身并不是一個具體的協議，而是一種調用方式。如果現在這不是個本地方法，而是個遠端服務器暴露出來的一個方法 remoteFunc，如果我們還能像調用本地方法那樣去調用它，這樣就可以屏蔽掉一些網絡細節

HTTP 和 WebSocker

1、HTTP協議設計之初，考慮的是看看網頁文本的場景，能做到客戶端發起請求再由服務器響應就夠了，根本就沒考慮網頁游戲這種，客戶端和服務器之間都要互相主動發大量數據的場景。所以，為了更好的支持這樣的場景，我們需要另外一個基于TCP的新協議，新的應用層協議WebSocket就被設計出來了。
2、瀏覽器在 TCP 三次握手建立連接之后，都統一使用 HTTP 協議先進行一次通信。

• 如果這時候是想建立 WebSocket 連接，就會在 HTTP 請求里帶上一些特殊的header 頭 [[Pasted image 20250706201759.png]]
  3、WebSocker的消息格式 [[QQ_1751804965426.png]]
• 數據包在WebSocket中被叫做幀
• 適用于需要服務器和客戶端（瀏覽器）頻繁交互的大部分場景，比如網頁/小程序游戲，網頁聊天室，以及一些類似飛書這樣的網頁協同辦公軟件

我們知道TCP連接的兩端，同一時間里，雙方都可以主動向對方發送數據。這就是所謂的全雙工。而現在使用最廣泛的HTTP/1.1，也是基于TCP協議的，同一時間里，客戶端和服務器只能有一方主動發數據，這就是所謂的半雙工。[[Pasted image 20250706203228.png]]

3.1 HTTP常見面試題

1、HTTP基本概念：

• 超文本傳輸協議：在計算機世界里專門在「兩點」之間「傳輸」文字、圖片、音頻、視頻等「超文本」數據的「約定和規范」
• HTTP常見的狀態碼 [[Pasted image 20250705140705.png]]
• HTTP常見字段
  • Host?字段：客戶端發送請求時，用來指定服務器的域名
  • Content-Length 字段：服務器在返回數據時本次回應的數據長度。HTTP協議通過設置回車符、換行符作為HTTP header的邊界，通過Content-Length字段作為HTTP body的邊界，這兩個方式都是為了解決“粘包”的問題。
  • Connection 字段：常用于客戶端要求服務器使用「HTTP 長連接」機制，以便其他請求復用
  • Content-Type 字段：用于服務器回應時，告訴客戶端，本次數據是什么格式。（客戶端請求的時候，可以使用?Accept?字段聲明自己可以接受哪些數據格式。）
  • Content-Encoding 字段：說明數據的壓縮方法。表示服務器返回的數據使用了什么壓縮格式（客戶端在請求時，用?Accept-Encoding?字段說明自己可以接受哪些壓縮方法）
    2、GET 與 POST
• GET 的語義是從服務器獲取指定的資源，比如打開瀏覽器文章，瀏覽器就會發送 GET 請求給服務器，服務器就會返回文章的所有文字及資源。GET 請求的參數位置一般是寫在 URL 中[[Pasted image 20250705143554.png]]
• POST 的語義是根據請求負荷（報文body）對指定的資源做出處理，在文章底部留言后點擊「提交」，瀏覽器就會執行一次POST請求，把你的留言文字放進了報文body里，然后拼接好POST請求頭，通過TCP協議發送給服務器。POST 請求攜帶數據的位置一般是寫在報文 body 中[[Pasted image 20250705143636.png]]
• GET 和 POST 請求都是明文的，避免被竊取就要用HTTPS協議 [[Pasted image 20250705144047.png]]
  3、HTTP緩存技術
• 強制緩存：只要瀏覽器判斷緩存沒有過期，則直接使用瀏覽器的本地緩存，決定是否使用緩存的主動性在于瀏覽器這邊。強緩存是利用下面這兩個 HTTP 響應頭部（Response Header）字段Cache-Control和Expires實現[[Pasted image 20250705144933.png]]
• 協商緩存：當我們在瀏覽器使用開發者工具的時候，你可能會看到過某些請求的響應碼是304，這個是告訴瀏覽器可以使用本地緩存的資源，通常這種通過服務端告知客戶端是否可以使用緩存的方式被稱為協商緩存。Etag實現協商緩存的過程：[[Pasted image 20250705150930.png]]
  4、HTTP特性
• HTTP/1.1 優點「簡單、靈活和易于擴展、應用廣泛和跨平臺」
  • 1. 簡單
  • 2. 靈活和易于擴展
    • • HTTPS 就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層；
    • • HTTPS 就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層；
  • 3. 應用廣泛和跨平臺
• HTTP/1.1 缺點「無狀態、明文傳輸」，同時還有一大缺點「不安全」
  • 1. 無狀態雙刃劍：不需要額外記錄狀態信息，減輕服務器負擔，但服務器沒有記憶能力，它在完成有關聯性的操作時會非常麻煩。例如登錄->添加購物車->下單->結算->支付，這系列操作都要知道用戶的身份才行
  • 2. 明文傳輸雙刃劍：抓包調試方便，但信息裸奔
  • 3. 不安全：明文不加密，不驗證通信方身份，無法證明報文完整性（可能被篡改）。可用HTTPS解決，加入SSL/TLS層
• HTTP/1.1 性能
  • 1. 長連接：減少TCP重復建立和斷開的額外開銷
  • 2. 管道網絡傳輸：長連接使得管道傳輸成為可能，即可在同一個TCP連接里面，客戶端可以發起多個請求，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。
  • 3. 隊頭阻塞：順序發送的請求序列中的一個請求因為某種原因被阻塞時，在后面排隊的所有請求也一同被阻塞了
    5、HTTP 與 HTTPS

• HTTP是超文本傳輸協議，信息是明文傳輸，存在安全風險的問題。HTTPS則解決HTTP不安全的缺陷，在TCP和HTTP網絡層之間加入了SSL/TLS安全協議，使得報文能夠加密傳輸。
• 如何解決HTTP的缺點
  • 1. 混合加密：采用的是對稱加密和非對稱加密結合的「混合加密」方式，解決明文竊聽問題。
    • 在通信建立前采用非對稱加密的方式交換「會話秘鑰」
    • 在通信過程中全部使用對稱加密的「會話秘鑰」的方式加密明文數據
  • 2. 摘要算法 + 數字簽名：解決內容篡改
    • 用摘要算法（哈希函數）來計算出內容的哈希值
    • 非對稱加密算法（數字前面算法）：通過「私鑰加密，公鑰解密」的方式，來確認消息的身份[[Pasted image 20250705161048.png]]
  • 3. 數字證書：將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，實現身份驗證環節

• HTTPS 是如何建立連接的（這部分不太懂）
  • TLS 協議建立的詳細流程
  • 客戶端校驗數字證書的流程
• HTTPS的應用數據是如何保證完整性的（這部分不太懂）
  • TLS 記錄協議負責保護應用程序數據并驗證其完整性和來源
• HTTPS 一定安全可靠嗎
  6、HTTP/1.1、HTTP/2、HTTP/3 演變 [[Pasted image 20250705172849.png]]
• HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
  • • 使用長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。
  • 支持管道（pipeline）網絡傳輸，只要第一個請求發出去了，不必等其回來
• HTTP/2 做了什么優化？
  • HTTP/2 協議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
  • 1. 頭部壓縮：HPACK?算法，在客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表
  • 2. 二進制格式：不再像 HTTP/1.1 里的純文本形式的報文，而是全面采用了二進制格式
  • 3. 并發傳輸：引出了 Stream 概念，多個 Stream 復用在一條 TCP 連接
  • 4. 服務器推送：服務端不再是被動地響應，可以主動向客戶端發送消息
• HTTP/3 做了哪些優化？
  • HTTP/2 雖然通過多個請求復用一個 TCP 連接解決了 HTTP 的隊頭阻塞 ，但是一旦發生丟包，就會阻塞住所有的 HTTP 請求，這屬于 TCP 層隊頭阻塞。HTTP/2 隊頭阻塞的問題是因為 TCP，所以?HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！
  • 基于 UDP 的?QUIC 協議?可以實現類似 TCP 的可靠性傳輸。QUIC 有以下 3 個特點。
    • 1、無隊頭阻塞：當某個流發生丟包時，只會阻塞這個流，其他流不會受到影響
    • 2、更快的連接建立：QUIC 內部包含了 TLS
    • 3、連接遷移：?QUIC 協議沒有用四元組的方式來“綁定”連接，而是通過連接 ID?來標記通信的兩個端點

3.2 HTTP/1.1 如何優化

1、下面這三種優化思路來優化 HTTP/1.1 協議：

• 盡量避免發送HTTP請求;
• 在需要發送HTTP請求時，考慮如何減少請求次數；
• 減少服務器的HTTP響應的數據大小；
  2、盡量避免發送HTTP請求：緩存技術 [[Pasted image 20250706112045.png]] [[Pasted image 20250705150930.png]]
  3、考慮如何減少請求次數
• 減少重定向請求次數：重定向的工作交由代理服務器完成，就能減少 HTTP 請求次數了
• 合并請求：把多個訪問小文件的請求合并成一個大的請求，減少了重復發送的 HTTP 頭部。
• 延遲發送請求：通過「按需獲取」的方式，來減少第一時間的 HTTP 請求次數
  4、減少服務器的HTTP響應的數據大小
• 無損壓縮：資源經過壓縮后，信息不被破壞，還能完全恢復到壓縮前的原樣，適合用在文本文件、程序可執行文件、程序源代碼。（對原始資源建立統計模型，利用這個統計模型，將常出現的數據用較短的二進制比特序列表示，將不常出現的數據用較長的二進制比特序列表示）客戶端支持的壓縮算法，會在 HTTP 請求中通過頭部中的?Accept-Encoding?字段
• 有損壓縮：解壓的數據會與原始數據不同但是非常接近。HTTP 請求頭部中的?Accept?字段里的「 q 質量因子」，告訴服務器期望的資源質量。

3.3 HTTPS RSA握手解析

1、HTTPS?在 HTTP 與 TCP 層之間加入了 TLS 協議，來解決上述的風險。[[Pasted image 20250706133549.png]]
2、TLS 握手過程，不同的密鑰交換算法，TLS 的握手過程可能會有一些區別。密鑰交換算法，因為考慮到性能的問題，所以雙方在加密應用信息時使用的是對稱加密密鑰，而對稱加密密鑰是不能被泄漏的，為了保證對稱加密密鑰的安全性，所以使用非對稱加密的方式來保護對稱加密密鑰的協商，這個工作就是密鑰交換算法負責的。（最簡單的?RSA?密鑰交換算法）

• 經過「四個消息」就可以完成 TLS 握手，也就是需要 2個 RTT 的時延（RTT（Round-Trip Time）時延是指數據從發送端到接收端并返回發送端所需的總時間，即一次完整的“往返”通信延遲）
  3、RSA 握手過程
• 在RSA密鑰協商算法中，客戶端會生成隨機密鑰，并使用服務端的公鑰加密后再傳給服務端。根據非對
  稱加密算法，公鑰加密的消息僅能通過私鑰解密，這樣服務端解密后，雙方就得到了相同的密鑰（服務端就得到客戶端生成的隨機秘鑰），再用它加密應用消息。
• 使用RSA密鑰協商算法的最大問題是不支持前向保密。因為客戶端傳遞隨機數（用于生成對稱加密密鑰的條件之一）給服務端時使用的是公鑰加密的，服務端收到后，會用私鑰解密得到隨機數。所以一旦服務端的私鑰泄漏了，過去被第三方截獲的所有TLS通訊密文都會被破解。為了解決這個問題，后面就出現了 ECDHE 密鑰協商算法

3.4 HTTPS ECDHE 握手解析

1、HTTPS 常用的密鑰交換算法有兩種，分別是 RSA 和 ECDHE 算法。ECDHE秘鑰交換算法[[Pasted image 20250706153243.png]]

3.5 HTTPS 如何優化

3.6 HTTP/2 牛逼在哪？

1、HTTP/2 出來的目的是為了改善 HTTP 的性能

• 兼容 HTTP/ 1.1
• HPACK?算法壓縮頭部：客戶端和服務器兩端都會建立和維護「字典」，用長度較小的索引號表示重復的字符串，再用 Huffman 編碼壓縮數據，可達到 50%~90% 的高壓縮率。
• 二進制幀：將 HTTP/1 的文本格式改成二進制格式傳輸數據，極大提高了 HTTP 傳輸效率
• 并發傳輸：HTTP/2 通過 Stream 實現的并發
• 服務器主動推送資源

3.7 HTTP/3 強勢來襲

1、HTTP/2 的缺點

• 隊頭阻塞：當 TCP 丟包時，整個 TCP 都要等待重傳
• TCP 與 TLS 的握手時延遲：發起 HTTP 請求時，需要經過 TCP 三次握手和 TLS 四次握手
• 網絡遷移需要重新連接：IP 地址或者端口變動了，就會導致需要 TCP 與 TLS 重新握手（比如 4G 網絡環境切換成 WiFi）
  2、HTTP/3 QUIC協議：將傳輸協議替換成了 UDP，還基于 UDP 協議在「應用層」實現了?QUIC 協議[[Pasted image 20250706191606.png]]
• 無隊頭阻塞
• 更快的連接建立
• 連接遷移

3.8 HTTP 和 RPC 的區別

1、服務發現：在?HTTP?中，你知道服務的域名，就可以通過?DNS 服務去解析得到它背后的 IP 地址；而?RPC?的話，就有些區別，一般會有專門的中間服務去保存服務名和IP信息
2、底層連接形式：RPC 協議一般還會再建個連接池
3、傳輸的內容。

• 將結構體轉為二進制數組的過程就叫序列化，反過來將二進制數組復原成結構體的過程叫反序列化

RPC（Remote?Procedure?Call），又叫做遠程過程調用。它本身并不是一個具體的協議，而是一種調用方式。如果現在這不是個本地方法，而是個遠端服務器暴露出來的一個方法?remoteFunc，如果我們還能像調用本地方法那樣去調用它，這樣就可以屏蔽掉一些網絡細節

HTTP 和 WebSocker

1、HTTP協議設計之初，考慮的是看看網頁文本的場景，能做到客戶端發起請求再由服務器響應就夠了，根本就沒考慮網頁游戲這種，客戶端和服務器之間都要互相主動發大量數據的場景。所以，為了更好的支持這樣的場景，我們需要另外一個基于TCP的新協議，新的應用層協議WebSocket就被設計出來了。
2、瀏覽器在?TCP 三次握手建立連接之后，都統一使用 HTTP 協議先進行一次通信。

• 如果這時候是想建立 WebSocket 連接，就會在 HTTP 請求里帶上一些特殊的header 頭 [[Pasted image 20250706201759.png]]
  3、WebSocker的消息格式 [[QQ_1751804965426.png]]
• 數據包在WebSocket中被叫做幀
• 適用于需要服務器和客戶端（瀏覽器）頻繁交互的大部分場景，比如網頁/小程序游戲，網頁聊天室，以及一些類似飛書這樣的網頁協同辦公軟件

我們知道TCP連接的兩端，同一時間里，雙方都可以主動向對方發送數據。這就是所謂的全雙工。而現在使用最廣泛的HTTP/1.1，也是基于TCP協議的，同一時間里，客戶端和服務器只能有一方主動發數據，這就是所謂的半雙工。[[Pasted image 20250706203228.png]]