目錄
1.前言
2.正文
2.1狀態碼
2.2HTTP與HTTPS的關系
2.3SSL協議
2.3.1對稱加密
2.3.2非對稱加密
2.3.3中間人攻擊
2.3.4校驗機制
2.3.4.1證書
2.3.4.2數字簽名
1. 數字簽名的生成過程
2. 數字簽名的驗證過程
2.4TLS協議（握手過程）
3.小結
1.前言
哈嘍大家好吖，今天繼續來給大家網絡原理相關方面的講解，主要內容包括狀態碼以及HTTPS中加密的全過程，讓我們開始吧。
2.正文
2.1狀態碼
想必大家都遇到過這個畫面：
這個耳熟能詳的“404”，就是狀態碼啦。
狀態碼（HTTP與HTTPS互通）是服務器與客戶端通信的“語言”，用3位數字直觀反饋請求結果。它不僅是開發調試的核心工具，也是優化用戶體驗和排查問題的關鍵線索。
HTTP狀態碼
https://baike.baidu.com/item/http%e7%8a%b6%e6%80%81%e7%a0%81/5053660
HTTP狀態碼按首位數字分為5類：
類別 范圍 含義 核心邏輯 1xx 100-199 信息性狀態 請求已被接收，需客戶端繼續操作 2xx 200-299 成功響應 請求被正確處理并返回預期結果 3xx 300-399 重定向 資源位置變化，需客戶端跳轉 4xx 400-499 客戶端錯誤 請求語法錯誤或權限不足 5xx 500-599 服務器錯誤 服務器無法完成合法請求
在我前面SpringMVC的博文中，狀態碼為我們的調試工作發揮了舉足輕重的作用，下面我們介紹幾個比較重要的狀態碼。
?2xx：成功響應：
200 OK
默認成功狀態，適用于GET、POST等請求。
常見誤區：
POST請求成功后，部分開發者誤用200而非201（資源已創建）。
刪除操作成功后，建議返回204（無內容）而非200。
201 Created
場景：資源創建成功（如提交表單生成新訂單）。
響應頭要求：必須包含?Location?字段指向新資源地址。204 No Content
場景：請求成功但無需返回內容（如刪除資源、提交無返回的表單）。
技術細節：響應體必須為空，瀏覽器不會刷新頁面。
4xx：客戶端錯誤：
400 Bad Request
通用錯誤：請求語法錯誤（如JSON格式錯誤、缺少必填參數）。
開發技巧：后端應返回具體錯誤信息（如?{ "error": "Invalid email format" }）。401 Unauthorized
未認證：需身份驗證（如未登錄用戶訪問個人中心）。
響應頭要求：必須包含?WWW-Authenticate?字段定義認證方式。403 Forbidden
無權限：身份已認證，但無權訪問資源（如普通用戶訪問管理員頁面）。
與401的區別：401是“未證明身份”，403是“身份已知但權限不足”。404 Not Found
資源不存在：URL路徑錯誤或資源已被刪除。
SEO影響：過多404錯誤會降低網站排名，建議配置自定義404頁面引導用戶。429 Too Many Requests
限流防護：客戶端請求頻率過高（如API防刷機制）。
響應頭要求：應包含?Retry-After?告知重試時間。
5xx：服務器錯誤：
500 Internal Server Error
通用服務端錯誤：代碼異常（如未捕獲的Exception、數據庫連接失敗）。
開發建議：記錄詳細日志（如錯誤堆棧、請求參數），避免直接返回原始錯誤給客戶端。502 Bad Gateway
網關錯誤：代理服務器（如Nginx）無法從上游服務器（如Node.js）獲取響應。
常見原因：上游服務崩潰、防火墻攔截、請求超時。503 Service Unavailable
服務不可用：服務器臨時過載或維護（如電商大促時流量激增）。
優化方案：返回?Retry-After?頭，配合負載均衡和熔斷機制。504 Gateway Timeout
網關超時：代理服務器等待上游響應超時。
排查方向：檢查后端服務性能、數據庫查詢效率、網絡延遲。
?2.2HTTP與HTTPS的關系
通俗理解：
HTTP（HyperText Transfer Protocol）：
一種明文傳輸協議，數據在客戶端與服務器之間以未加密形式傳輸，如同寄送明信片，內容對所有人可見。
HTTPS（HTTP Secure）：
HTTP的安全升級版，通過?SSL/TLS協議?對傳輸內容加密，如同將明信片裝入防拆封的保險箱。
橫向對比HTTP與HTTPS協議：
1)數據傳輸安全性:
- HTTP:數據以明文傳輸，容易被竊聽、篡改。
- HTTPS:通過 SSL/TLS 協議對數據進行加密傳輸，提供數據機密性和完整性保障。
2)端口號:
- HTTP:默認使用端口 80。
- HTTPS:默認使用端口 443。
3)性能:
- HTTP:無加密過程，連接建立速度稍快。
- HTTPS:基于 HTTP上又加了SSL(Secure Sockets Layer)或TLS(Transport Layer Security)協議來實現的加密傳輸,加解密過程增加了計算開銷，握手時間較長，但現代硬件和協議優化已使性能差距減小。?
下文我們就要展開本文的重中之重，加密的全過程了。?
2.3SSL協議
2.3.1對稱加密
定義：
對稱加密是一種加密方式，加密和解密使用同一個密鑰。就像用同一把鑰匙鎖門和開門，只有持有鑰匙的人才能操作。
具體步驟：
- 客戶端與服務器通過TLS握手協商出一個會話密鑰（Session Key）。
- 雙方使用該密鑰對HTTP報文進行對稱加密傳輸。
- 會話結束后密鑰銷毀，下次連接生成新密鑰。
?對稱加密效率較高，但相反的安全性不足：
2.3.2非對稱加密
定義：
非對稱加密使用一對數學關聯的密鑰：
公鑰（Public Key）：公開給所有人，用于加密數據（如同信箱的投遞口）
私鑰（Private Key）：嚴格保密，用于解密數據（如同信箱的專屬鑰匙）
核心特性：
公鑰加密 → 私鑰解密：任何人都能用公鑰加密數據，但只有私鑰持有者能解密。
私鑰簽名 → 公鑰驗簽：私鑰可生成數字簽名，公鑰可驗證簽名真實性。
對稱加密，成本是比較高的，不適合加密大量的數據。大量的業務數據仍然通過對稱密鑰來加密
對稱密鑰，如果數據量小則通過非對稱加密的方式來傳輸?。
當前的場景有三個密鑰：
- 客戶端生成的對稱密鑰。
- 服務器生成的公鑰，可以給所有設備告知。
- 服務器生成的私鑰，只有自己知道?。
上述這樣的流程存在重大安全隱患，黑客可以通過特殊手段，來獲取到對稱密鑰~~ 破壞后續傳輸的安全性~那就是中間人攻擊?。
2.3.3中間人攻擊
定義：
中間人攻擊（Man-in-the-Middle Attack, MITM）指攻擊者秘密介入通信雙方之間，竊聽、攔截甚至篡改數據，而通信雙方對此毫無察覺。
核心原理：
偽裝身份：攻擊者偽造通信一方的身份（如偽裝成服務器或路由器）。
劫持通信：將雙方的流量引導至攻擊者控制的節點。
操縱數據：解密、查看或修改數據后轉發給真實接收方。
通俗理解：
正常通信：A → 快遞員 → B
中間人攻擊：A → 偽裝成快遞員的黑客 → B
雖然服務器私鑰并沒有被黑客獲取，但請求與相應都被黑客一覽無余，所以為了安全，引入了一些校驗機制，其中包括證書與數字簽名。?
2.3.4校驗機制
在HTTPS通信中，校驗機制需解決兩個核心問題：
身份真實性：確保通信的服務器是合法的（防止中間人偽造）。
數據完整性：確保傳輸的證書和數據未被篡改。
解決方案：
證書?→ 證明服務器身份
數字簽名?→ 驗證證書的合法性
2.3.4.1證書
一個標準的證書包含以下關鍵信息：
| 字段 | 作用 |
|---|---|
| Subject（主體） | 證書持有者的信息（如域名、組織名稱） |
| Public Key | 服務器的公鑰（用于加密數據或驗證簽名） |
| Issuer（頒發者） | 簽發證書的權威機構（CA，如Let's Encrypt、DigiCert） |
| 有效期 | 證書的有效起止時間 |
證書頒發流程：
生成密鑰對：服務器生成公鑰和私鑰。
CSR（證書簽名請求）：服務器向CA提交包含公鑰、域名等信息的CSR文件。
CA驗證身份：CA通過DNS記錄、文件驗證或郵件驗證確認申請者對域名的控制權。
簽發證書：CA用私鑰對證書內容簽名，生成最終證書。
先講解完證書的概念，到下文數字簽名介紹完后會講解客戶端拿到證書和數字簽名會做些什么?
2.3.4.2數字簽名
數字簽名，本質上是一個校驗和。
1. 數字簽名的生成過程
計算哈希值：對證書內容（除簽名外）使用哈希算法生成摘要。
私鑰加密哈希值：CA用私鑰對哈希值加密，生成數字簽名。
2. 數字簽名的驗證過程
解密簽名：瀏覽器用CA的公鑰解密簽名，得到哈希值H1。
重新計算哈希值：對收到的證書內容計算哈希值H2。
比對哈希值：若H1=H2，則證書未被篡改；否則判定為偽造證書。
如果校驗和一樣，則說明收到的數據是原始數據。
驗證邏輯：
只有CA的私鑰能生成合法簽名 → 簽名合法則證書可信。
哈希值匹配 → 證書內容未被篡改。
客戶端如何確保拿到的 pub2是公證機構的 pub2，而不是黑客偽造的 pub2 呢？？
pub2就不是通過網絡傳輸的，而是操作系統中內置的~(安裝好系統,系統就內置了一系列知名公正機構的公鑰)只要安裝正版系統，不是黑客搞的盜版系統就可以信任 pub2 是正確合法的~
如果黑客想要直接修改證書中的公鑰為自己的公鑰，此時就會導致客戶端計算的校驗和和解密出來的原始校驗和就對不上。
此時客戶端就會報錯，瀏覽器就會彈出一個紅色的頁面，告訴你該網站不安全，是否要繼續訪問。
2.4TLS協議（握手過程）
概念
TLS（Transport Layer Security）是SSL的繼任者，用于在互聯網上建立加密通信通道，解決三大核心問題：
保密性：數據加密傳輸（防竊聽）。
完整性：數據未被篡改（防篡改）。
真實性：驗證通信方身份（防偽裝）。
握手流程解析：
- 客戶端發送 ClientHello 消息給服務器，包含客戶端支持的 SSL/TLS 版本、加密套件列表以及一個隨機數(Client Random)
- 服務器響應 ServerHello 消息，包含服務器選定的 SSL/TLS 版本、加密套件以及另一個隨機數(Server Random)
- 服務器發送證書(Certificate)給客戶端，證書包含服務器的公鑰以及由受信任的證書頒發機構(CA)簽名的數字證書。
- 如果服務器需要客戶端認證，則請求客戶端證書(Client Certificate Request)。
- 服務器發送 ServerHelloDone 消息，表示握手的初步消息已經發完。
- 客戶端驗證服務器證書，如果證書有效，它會生成一個預主密鑰(Pre-Master Secret)，并使用服務器的公鑰加密這個預主密鑰，把它發送給服務器。
- 服務器使用私鑰解密預主密鑰，客戶端和服務器使用約定好的算法計算出主密鑰(MasterSecret)。
- 客戶端發送 ChangeCipherSpec 消息，表示后續的通信將使用協商好的密鑰和加密算法。
- 客戶端發送 Finished 消息，包含使用主密鑰計算的握手消息摘要，以確認握手的完整性。
- 服務器發送 ChangeCipherSpec 消息，也表示后續通信將使用協商好的密鑰和加密算法.。
- 服務器發送 Finished 消息，包含使用主密鑰計算的握手消息摘要，雙方握手完成，后續通信開始使用對稱加密進行。
（部分內容參考面試鴨）
握手過程中的安全機制
1. 防中間人攻擊
證書驗證：確保服務器公鑰未被偽造。
簽名驗證：Server Key Exchange消息中的參數由服務器私鑰簽名。
2. 前向保密（Perfect Forward Secrecy, PFS）
原理：每次會話使用臨時密鑰（如ECDHE），即使長期私鑰泄露，歷史通信仍安全。
啟用條件：使用ECDHE密鑰交換算法。
3. 防重放攻擊
隨機數（Client/Server Random）：確保每次會話密鑰唯一。
Finished消息：驗證握手過程完整性。
3.小結
今天的分享到這里就結束了，喜歡的小伙伴點點贊點點關注，你的支持就是對我最大的鼓勵，大家加油！
