HTTP 與 HTTPS 的區別？

• HTTP 明文傳輸，數據未經加密，安全性較差。HTTPS（SSL + HTTP）的數據傳輸過程是加密的，安全性較好。
• 使用 HTTPS 協議需要到 CA 申請證書。
• HTTP 的頁面響應速度比 HTTPS 快，主要是因為 HTTP 使用 TCP 三次握手建立連接，而 HTTPS 除了 TCP 的三個包，還要加上 SSL 握手的消耗。
• HTTP 使用 80 端口，HTTPS 使用 443 端口。
• 實際上 HTTPS 就是構建在 SSL/TLS 之上的 HTTP 協議，所以 HTTPS 比 HTTP 更消耗服務器資源。

HTTPS 加密與認證的過程？

ClientHello

首先，由客戶端向服務端發起加密通信請求，客戶端主要向服務器發送：

• 客戶端支持的 SSL/TLS 協議版本；
• 客戶端產生的隨機數（Client Random）；
• 客戶端支持的密碼套件列表。

ServerHello

服務器收到客戶端的請求后，向客戶端發出響應，服務端回應的內容如下：

• 確認 SSL/TLS 協議版本（如果瀏覽器不支持，則關閉加密通信）；
• 服務端產生的隨機數（Server Random）；
• 確認的密碼套件列表；
• 服務端的數字證書；

客戶端回應

客戶端收到服務端的回應之后，首先通過瀏覽器或 OS 中的 CA 公鑰，確認服務端的數字證書的真實性，如果證書沒問題，客戶端會從數字證書中取出服務端的公鑰，然后使用它加密報文，向服務端發送如下信息：

• 一個隨機數，該隨機數會被服務端公鑰加密；
• 加密通信算法改變通知，表示隨后的信息都將用會話密鑰加密通信；
• 客戶端握手結束通知，表示客戶端的握手階段已經結束；
• 為之前所有數據進行總結，供服務端校驗；

至此，服務端和客戶端共生成了三個隨機數（客戶端生成了兩個，而服務端生成了一個），接著用雙方協商的加密算法，各自生成本次通信的1會話密鑰。

服務端回應

服務端收到客戶端的第三個隨機數之后，通過協商的加密算法，計算出本次通信的會話密鑰。服務端向客戶端發送最后的消息：

• 加密通信算法改變通知，表示隨后的信息通過會話密鑰加密通信；
• 服務端握手結束通知，表示服務端的握手階段已經結束；
• 總結之前的內容，供客戶端校驗；

接下來，客戶端與服務端進入加密通信，就完全是使用普通的 HTTP 協議了。

HTTPS 一定安全可靠嗎？

HTTPS 協議到目前為止本身是沒什么漏洞的。即使 HTTPS 成功被中間人攻擊，本質上也是客戶端的漏洞（瀏覽器在瀏覽證書非法的網站時，會提示用戶確認，因為它識別出了證書是非法的，是由中間人偽造的，用戶如果仍然繼續訪問，相當于用戶接受了中間人偽造的證書），并不是 HTTPS 不夠安全。

HTTPS 狀態碼的含義？

1. 100 類狀態碼屬于提示信息，是協議處理的中間狀態，實際用到的較少；
2. 200 類狀態碼表示服務器成功處理了客戶端的請求；
3. 300 類狀態碼表示客戶端請求的資源發生了變動，需要客戶端使用新的 URL 重新發送請求獲取資源，也就是重定向；
4. 400 類狀態碼表示客戶端發送的報文有誤，服務器無法處理；
5. 500 類狀態碼表示客戶端請求報文正確，但服務器處理時內部發生了錯誤，屬于服務器端的錯誤碼。

HTTP 緩存有哪些實現方式？

• 強制緩存：強制緩存指的是只要瀏覽器判斷緩存沒過期，則直接使用瀏覽器的本地緩存，決定是否使用緩存的主動性在瀏覽器；
• 協商緩存：請求的響應碼為 304，告訴瀏覽器可以使用本地緩存的資源，通過服務通知客戶端是否可以使用緩存的方式是協商緩存。

HTTP 1.0、HTTP 1.1、HTTP 2.0 和 HTTP 3.0 的區別？

HTTP 1.0

• 無連接：每次請求都要建立連接，需要使用 keep-alive 參數建立長連接，建立連接非常消耗資源。
• 隊頭阻塞：HTTP 1.0 規定下一個請求必須在前一個請求響應到達前才能發送，假設前一個請求響應一直不到達，那么下一個請求就一直不發送，后面的請求就阻塞了。
• 緩存：在 HTTP 1.0 中主要使用 header 中的協商緩存 last-modified/if-modified-since，強緩存 Expires 來作為緩存判斷的標準。

HTTP 1.1

• 長連接：好處在于減少了 TCP 連接的重復建立和斷開連接所造成的額外開銷，減輕了服務器端的負載。
• 支持管道（pipeline）網絡傳輸：只要第一個請求發送出去了，不必等其回來，就可以發第二個請求出去，減少了整體的響應時間（對比 HTTP 1.0，1.0 需要在發送方接收到前一個請求的響應后才能發送下一個請求，可能產生隊頭阻塞）。
• 緩存處理：HTTP 1.1 引入了更多的緩存控制策略，有可供選擇的緩存頭來控制緩存策略。
• 斷點續傳：HTTP 1.1 在請求頭引入了 range 頭域，它允許只請求資源的某個部分，即返回碼是 206（Partial Content），這樣就方便了開發者自由地選擇以便于充分利用帶寬和連接。

HTTP 2.0

• header 壓縮：HTTP 1 系列的 header 帶有大量信息，且每次都要重復發送，HTTP 2.0 使用 encoder 減少需要傳輸的 header 大小，通訊雙方各自 cache 一份 header fields 表，避免了重復的 header 傳輸，減少了需要傳輸的數據包的大小。
• 多路復用：使用多路復用技術，做到同一個連接并發處理多個請求，且并發請求的數量比 HTTP 1.1 大好幾個數量級。【補充，多路復用：多路復用（Multiplexing）是一種通信技術，旨在通過單一物理通信同時傳輸多路獨立信號，從而高效利用通信資源，其核心思想是共享資源，分時/分頻/分碼傳輸】
• 新的二進制幀格式：HTTP 2.0 把請求在應用部分切分成二進制幀并標上序號，服務器收到二進制幀后組成請求進行處理，從而達到并發發送請求的效果，對于服務器端，響應可以通過序號確定是哪個請求，從而避免混亂的情況產生。
• 服務器推送：HTTP 2.0 引入了 server push，它允許服務端推送資源給瀏覽器，在瀏覽器明確地請求前，客戶端可以不用再次創建連接請求從服務端獲取已經推送給瀏覽器的資源。這樣客戶端可以直接在本地加載資源，不用通過網絡。

HTTP 3.0（QUIC）

• HTTP 3.0（QUIC）直接棄用 TCP，將傳輸層協議改為 UDP，使用 UDP 實現可靠傳輸。
• 0-RTT：緩存當前會話的上下文，下次恢復會話的時候，只需要將之前的緩存傳遞給服務器，驗證通過，就可以傳輸了（這是 QUIC 協議相比于 HTTP 2.0 協議惹眼最大的優勢）。
• 多路復用：QUIC 基于 UDP，一個連接上的多個 stream 之間互相沒有依賴，即使丟包也只需要發送丟失的包，而不需要重傳整個連接；
• 更好的移動端表現：QUIC 在移動端的表現比 TCP 好，因為 TCP 是基于 IP 識別連接，而 QUIC 通過 ID 識別連接，無論網絡環境如何變化，只要 ID 不變，就能迅速重連。
• 加密認證的報文：TCP 協議頭沒有經過任何加密和認證，在傳輸過程中很容易被中間網絡設備篡改、注入和竊聽。QUIC 的 packet 除了個別報文，所有報文頭都是經過認證的，報文 Body 都是經過加密的，對 QUIC 進行的任何修改都可以在接收端及時發現，有效地降低了安全風險【即，雖然 UDP 的傳輸存在風險，但是 QUIC 報文經過加密認證，接收端可以在報文被修改的時候及時發現，極大程度上降低了基于 UDP 傳輸存在的風險】。
• 向前糾錯機制：向前糾錯（Foward Error Connec，FEC）指的是，每個數據包除了這個包本身的數據之外，還包括其他包的數據，因此少量的丟包可以通過其他包的榮譽數據直接組裝而無需重傳。向前糾錯犧牲了每個數據包可以發送數據的上限，但是其帶來的提升彌補了甚至效果比丟包導致的數據重傳更好，因為數據重傳會消耗更多的時間（包括確認數據包丟失、請求重傳、等待新數據包等）。

QUIC 協議的概念和特點？

概念

QUIC（Quick UDP Internet Connections）是一種基于 UDP 的現代傳輸協議，具有類似 TCP 的連接管理、擁塞窗口、流量控制等網絡特性，使得 UDP 協議更可靠【可以理解為，QUIC 是一個基于 UDP 的應用層協議，它使得 UDP 更可靠，其可靠性接近于 TCP】。

特點

基于 UDP 的高效傳輸

繞過 TCP 隊頭阻塞和握手延遲，利用 UDP 的無連接特性實現快速傳輸，同時在應用層實現可靠性機制（如丟包重傳）。

極速連接建立

0-RTT/1-RTT握手：通過緩存密鑰和會話信息，QUIC 建立首次連接僅需 1 次往返（1-RTT），后續連接可達到 0 次往返，顯著降低延遲。

多路復用與無隊頭阻塞

單一連接支持多個獨立數據流，各流之間互不阻塞。即使某個流丟包，其他流仍然正常傳輸，解決了 TCP 隊頭阻塞的問題。

內置加密與隱私增強

強制使用 TLS 1.3 加密，所有報文頭部和載荷均加密，防止中間設備篡改或嗅探，提升隱私保護。

無縫連接遷移

使用連接 ID 而非 IP + 端口來標識連接，網絡切換時（如 WIFI 轉 5G）無需重連，保障移動場景下的連續性。

靈活擁塞控制

支持可插拔的擁塞控制算法（如 BBR），適用不同網絡條件，優化吞吐量與公平性。

前向糾錯（FEC）

早期版本通過冗余數據包減少重傳，雖在標準中未保留，但設計理念仍在影響容錯機制。

QUIC 如何實現可靠傳輸？

1. 有序交付和確認機制；
2. 只能重傳策略；
3. 增強型擁塞控制；
4. 前向糾錯；
5. 流與連接級可靠性；
6. 加密完整性驗證；

HTTP 的 GET 和 POST 方法區別？

語義與用途

• GET：用于獲取資源（冪等操作），不應對服務器狀態產生副作用；
• POST：用于提交數據，通常會產生副作用（如創建新資源）；

參數傳遞

• GET：參數通過 URL 的查詢字符串傳遞，比如example.com/search?q=keyword&page=2；
• POST：參數封裝在請求體中傳輸；

數據限制

• GET：受 URL 長度限制（通常 2048 字符，因瀏覽器/服務器而異）；
• POST：理論上無限制，實際受服務器配置約束；

緩存與歷史記錄

• GET：可能被瀏覽器緩存，保存在歷史記錄中；
• POST：不會被緩存，刷新時瀏覽器重新提交；

安全性
POST 的安全性比 GET 高，因為 GET 請求提交的數據明文出現在 URL 中，而 POST 請求參數則被放在請求體中。

冪等性

• GET：冪等（多次執行結果相同）；
• POST：非冪等（可能產生不同結果）；

常見誤區

• POST 并不比 GET 更安全（安全性依賴于 HTTPS）；
• POST 沒有“隱藏參數”特性；
• 大數據傳輸推薦 POST，但 HTTP 規范未限制 GET 的請求體使用；

GET 請求可以帶 body 嗎？

RFC 規范并沒有規定 GET 請求不能帶 body。任何請求都可以帶 body。 GET 請求是獲取資源，所以根據這個語義，其實不需要用到 body。URL 中的查詢參數也不是 GET 所獨有的，POST 請求的 URL 中也可以有參數的。

既然有 HTTP 協議，為什么還要有 RPC？

定義：基于傳輸層的 TCP 協議，產生了應用層的 HTTP 協議和 RPC 協議（實際上 RPC 不能被稱之為具體的協議，它其實是一種調用方式），本質上 HTTP 和 RPC 只是定義了不同格式的應用層協議而已。HTTP 是超文本傳輸協議，RPC 是遠程過程調用。雖然大部分 RPC 協議的底層使用 TCP，但實際上 RPC 并不是一定要基于 TCP 進行傳輸，可以改用 UDP 或 HTTP。

服務發現：在使用 HTTP 時，只要知道服務的域名，就可以通過 DNS 服務去解析得到 IP 地址，默認 80 端口。RPC 一般有專門的中間服務去保存服務名和 IP 信息，比如 consul（服務發現）或 etcd，或 redis。想要訪問某個服務，就去這些中間服務獲取 IP 和端口信息。由于 DNS 也是服務發現的一種，所以也有基于 DNS 去做服務發現的組件，比如 CoreDNS。

底層連接方式：HTTP 協議默認在建立底層 TCP 連接后會一直保持連接（keep-alive），之后的請求和響應會復用連接。RPC 通過 TCP 長連接進行數據交互，但 RPC 一般還會建一個連接池，在請求量大的時候，建立多條連接放在池內，要發數據時從池里取一條連接出來，用完放回去，便于下次復用。

傳輸的內容：HTTP 設計初是用于做網頁文本展示的，傳輸內容以字符串為主，有 header 和 body。在 body 這塊，它使用 json 來序列化結構體數據，內容會有冗余。RPC 因為定制化程度更高，可以采用體積更小的 protobuf 或其他序列化協議去保存結構體數據，同時也不需要像 HTTP 那樣考慮各種瀏覽器行為，比如 302 重定向。因此性能也會更好一些，這也是在公司內部微服務中拋棄 HTTP，選擇使用 RPC 的最主要原因【總結一下，拋棄 HTTP 改用 RPC 的主要原因是 RPC 的傳輸數據格式的定制化程度更高，不需要像 HTTP 那樣考慮瀏覽器行為，因此性能更好】。

【協議效率差異：HTTP/1.1 文本協議中的 Header 包含冗余，比如 Cookie/UA 等無意義字段，ASCII 編碼的體積較大；而 RPC 在編碼時使用二進制，基于 Protobuf/Thrift 的編碼體積可以縮小 50% 到 80%，序列化速度快 5 ~ 10 倍】

通信模型深度：HTTP 基于 Request 和 Response 進行單向通信，而 RPC 支持 Streaming、背壓控制、元數據交換等高級且復雜的交互模式。

什么是 XSS 攻擊？有什么解決辦法？

XSS 是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些腳本代碼嵌入到 web 頁面中去，使別的用戶訪問時都會執行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

什么是 CSRF 攻擊？有什么解決辦法？

CSRF 就是跨站請求偽造。比如，登錄受信任網站 A，并在本地生成 Cookie，之后在不登出 A 的情況下，訪問危險網站 B（利用了 A 的漏洞）。可以通過 Token 驗證、隱藏 token 到 http head 中（隱藏令牌）、Referer 驗證等方式防范。

什么是中間人攻擊以及如何防范？

中間人攻擊指攻擊者與通訊的兩端分別創建獨立的聯系，并交換其所收到的數據，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。

可以通過使用HTTPS協議，禁用不安全的SSL協議，啟用虛擬專用網（VPN）來防范。