🎬?個人主頁：誰在夜里看海.
📖?個人專欄：《C++系列》《Linux系列》《算法系列》
???道阻且長，行則將至
目錄
📚 引言
📚 一、HTTP
📖 1.概述
📖 2.URL
🔖結構
🔖轉義
📖 3.格式
🔖請求格式
🔖響應格式
📚二、HTTPS
📖 1.概念
📖 2.加密方式
🔖對稱加密
🔖非對稱加密
📖 3.數據摘要
🔖概念
🔖數字簽名
📖 4.HTTPS的工作過程
🔖過程推斷
🔖證書?
📚 引言
上一篇文章我們講述了TCP/UDP協議，那是位于傳輸層的負責端到端通信，確保數據的可靠傳輸的協議，這篇文章我們來談一談應用層的協議。
如果說傳輸層協議的作用是確保數據能夠傳輸到位，那么應用層協議的作用就是確保數據能被正確解析。具體地說，應用層協議決定了數據在網絡上傳輸時的結構、順序、傳輸規則以及數據如何被應用程序解釋，應用層協議有效支持不同設備、操作系統和應用程序之間的相互通信和數據交換。
應用層協議可以由我們程序員自己定義，只需要通信雙方遵守相同的協議即可，不過在現實中，已經有許多現成且優秀的應用層協議供我們參考使用，其中之一就是我們下面要講述的HTTP(超文本傳輸協議)。
📚 一、HTTP
📖 1.概述
HTTP（HyperText Transfer Protocol） 是一種用于客戶端（通常是瀏覽器）與服務器之間傳輸超文本（主要是網頁）的協議。它是Web通信的基礎協議，用于支持瀏覽器與Web服務器之間的請求和響應。
雖然HTTP的通用客戶端是瀏覽器，但這并不意味著HTTP是基于瀏覽器的協議，事實上它廣泛用于各種客戶端與服務器間的通信，除了瀏覽器之外，其他許多應用（如移動應用、API、爬蟲等）也使用HTTP協議進行數據交換：
① 在瀏覽器中：我們使用HTTP協議來請求Web服務器上的資源。當你輸入一個網址（如www.example.com）并按下回車時，瀏覽器實際上向服務器發送一個HTTP請求，服務器返回相應的HTTP響應，其中包含網頁內容。
② 其他應用程序：HTTP并不僅限于瀏覽器，其他應用程序（如移動應用、桌面應用、API接口等）也可以通過HTTP協議與服務器進行數據交換。
📖 2.URL
URL（Uniform Resource Locator）是一種用于標識互聯網資源的地址，我們平時俗稱的“網址”就是URL，URL除了可以指向網頁，還可以指向圖片、視頻、文件、API接口等網絡資源。它的作用是幫助客戶端（如瀏覽器）在互聯網上找到并訪問特定的資源。
🔖結構
一個典型的URL格式如下：
http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1① 協議 http://?指定了訪問該URL時使用的協議，http標識使用HTTP(超文本傳輸協議)；
② 用戶信息 user:pass@?這個部分是可選的，表示URL的用戶名和密碼，通常用于需要身份驗證的站點。user是用戶名，pass是密碼，這種方式稱為基本認證；
③ 主機名 www.example.jp?這是服務器的主機名（或域名），表示要連接的Web服務器地址；
④ 端口?:80?這是可選的，表示與目標服務器通信時使用的端口號。80是HTTP協議的默認端口。如果未指定端口，HTTP會默認使用端口80；
⑤ 路徑?/dir/index.htm?這部分表示服務器上的資源路徑，指向某個文件或目錄；
⑥?查詢參數??uid=1?這是URL的查詢部分，通常用于向服務器傳遞額外的參數;
⑦?片段標識符?#ch1?片段標識符是URL的一個可選部分，通常用于標識資源中的某個位置或段落。
🔖轉義
像 / ? : 等這樣的字符, 已經被URL當做特殊意義理解了，因此這些字符不能隨意出現。因此，某個參數中需要帶有這些特殊字符, 就必須先對特殊字符進行轉義。
轉義的規則如下: 將需要轉碼的字符轉為16進制，然后從右到左，取4位(不足4位直接處理)，每2位做一位，前面加上%，編碼成%XY 格式?
例如：
這里“+”就被轉義成“%2B”。
urlencode 和 urldecode?分別是編碼和解碼的過程，我們可以用在線轉義工具對URL進行轉義：
UrlEncode編碼和UrlDecode解碼-在線URL編碼解碼工具
📖 3.格式
HTTP有兩種基本的消息格式：請求格式（Request）和響應格式（Response）
🔖請求格式
請求格式由以下幾個部分組成：
請求行
請求頭
空行
請求體
示例：
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8name=John&age=25
① 請求行
請求行包含請求方法、請求的資源路徑和協議版本
<方法> <請求路徑> <協議版本>
方法：HTTP請求的方法指明客戶端希望對指定資源執行的操作。常見的方法有：
GET：請求指定資源，僅讀取資源，不進行修改（冪等，即多次執行統一操作結果不變）
POST：向指定資源提交數據（不冪等，多次提交會創建多份資源）
PUT：向指定資源上傳數據（如果資源存在，替換該資源；資源不存在則創建，因此冪等）
DELETE：刪除指定資源
HEAD：與GET類似，不過只獲取響應頭部，不獲取實體內容
請求路徑：指定要請求的資源的路徑（可以是相對路徑或絕對路徑）
協議版本：表明使用的HTTP協議的版本，常見的有HTTP/1.1和HTTP/2
② 請求頭
請求頭是由多個鍵值對組成，用于提供額外的請求信息，如瀏覽器類型、支持的編碼格式、Cookie信息等。請求頭通常包括以下內容：
Host：指定服務器的域名或IP地址
User-Agent：客戶端的瀏覽器和操作系統信息
Accept：瀏覽器可以處理的響應內容類型
Content-Type：請求體的內容類型，通常在
POST或PUT請求中使用Authorization：用于HTTP認證的信息
Cookie：客戶端的Cookie信息
③ 空行
請求頭和請求體之間會有一個空行，用于分隔請求頭和請求體部分。
④ 請求體
請求體包含了實際發送到服務器的數據，通常在POST、PUT等請求方法中使用。對于GET等方法，請求體一般為空。
🔖響應格式
響應格式由以下幾個部分組成：?
響應行
響應頭
空行
響應體
示例：
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Server: Apache/2.4.7 (Ubuntu)<html><body><h1>Welcome to my website</h1></body>
</html>
① 響應行
響應行由協議版本、狀態碼和狀態描述組成。格式如下：
<協議版本> <狀態碼> <狀態描述>
協議版本：表明使用的HTTP協議版本?
狀態碼：服務器返回的數字代碼，表示響應的狀態
2xx：請求成功（如
200 OK）3xx：重定向（如
301 Moved Permanently）4xx：客戶端錯誤（如
404 Not Found）5xx：服務器錯誤（如
500 Internal Server Error）
狀態描述：狀態碼的簡要描述（如OK、Not Found）?
② 響應頭
響應頭包含了關于服務器、響應內容以及其他一些元數據的描述。常見的響應頭包括：
Content-Type：響應體的媒體類型
Content-Length：響應體的大小（以字節為單位）
Server：服務器軟件的名稱
Location：用于重定向的URL
Set-Cookie：設置客戶端的Cookie
③ 空行?
響應頭和響應體之間也有一個空行，用于分隔響應頭和響應體部分。
④?響應體
響應體包含了實際的資源數據或響應內容。它可以是HTML頁面、JSON數據、圖片等。
📚二、HTTPS
📖 1.概念
由于HTTP的內容是明文傳輸的，明文數據會經過路由器、WiFi熱點、通信服務運營商、代理服務器等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙方察覺，這就是中間人攻擊，所以我們才需要對數據進行加密。
加密就是把明文（要傳輸的信息）進行一系列變換，形成密文；
解密就是把密文再進行一系列變換，還原成明文。
在這個加密和解密的過程中，往往需要一個或者多個中間的數據輔助這個過程，這樣的數據就叫做密鑰。
HTTPS在HTTP的基礎上加入了SSL/TLS（安全套接字層/傳輸層安全協議）加密協議，用來對網絡通信進行加密和認證，從而確保數據在傳輸過程中不被竊取、篡改或偽造。簡單來說，HTTPS是HTTP協議的加密版本，用于保護HTTP通信的安全性。
📖 2.加密方式
加密方式有許許多多，但總體可以分成對稱加密和非對稱加密
🔖對稱加密
采?單鑰密碼系統的加密?法，同?個密鑰可以同時?作信息的加密和解密，這種加密?法稱為對 稱加密，也稱為單密鑰加密，特征：加密和解密所?的密鑰是相同的。
工作原理：
① 加密：發送方使用密鑰將明文數據轉換成密文；
② 傳輸：密文通過不安全的通道（網絡）發送到接收方；
③ 解密：接收方使用相同的密鑰將密文還原成明文。
??加密與解密的實現基于通信雙方使用相同的加密/解密算法，因此加密算法可以看作是公開的
例如：簡單的對稱加密，加密/解密算法為按位異或
明文a ^ 密鑰b 得到 密文c；
密文c ^ 密鑰b 還原會明文 a。
因為加密和解密都使用同一個密鑰，所以密鑰的管理和安全性至關重要。如果密鑰泄露，任何人都能解密收到的數據。
🔖非對稱加密
與對稱加密不同，非對稱加密的加密與解密所使用的密鑰是不同的，其中一個是公開密鑰（簡稱公鑰），一個是私有密鑰（簡稱私鑰）。
工作原理：
① 加密：發送方使用公鑰將明文數據轉換成密文；
② 解密：接受放使用私鑰將密文數據還原成明文。
（當然公鑰和私鑰也可以反著用）
這種方式的核心思想是，雖然每個人都可以通過公鑰來加密數據，但只有持有相應私鑰的人才能解密數據。由于公鑰和私鑰是成對生成的，公鑰和私鑰之間具有數學上的關系，但私鑰不能從公鑰推算出來。
??這種方法最大的缺點是：運算速度?常慢。
📖 3.數據摘要
上述的加密方法可以確保明文數據不會泄露，即使密文在傳輸過程中被中間人截取，但如果沒有對應的密鑰就無法將密文還原成明文。但是除此之外，我們還需要考慮一個問題，那就是數據完整性。
如果密文被中間人截取，他可以在不清楚密鑰的情況下對密文進行修改，這樣接收方得到的就不是原來的密文，也無法還原成正確的明文了，所以我們還需要保證密文在傳輸過程中不被修改。于是引入了數據摘要的概念。
🔖概念
數據摘要（數字指紋）的基本原理是利?單向散列函數(Hash函數)對信息進?運算,?成?串固定?度的數字摘要。數字摘要并不是?種加密機制，因為它沒有解密的過程。
工作原理：
① 生成摘要：對數據進行運算生成數字摘要；
② 驗證完整性：接收方對數據進行相同運算，將結果與摘要進行比對，若相同則表示未被修改。
??但還有問題，如果中間人對數據修改后，將摘要也一并修改了，這樣接收方就看不出來數據被篡改了，這該怎么解決呢？
🔖數字簽名
既然如此，我們將數據摘要也進行加密，就得到了數據簽名。我們使用非對稱加密方式，那么接收方的驗證步驟就變成了：
① 使用私鑰將數字簽名還原成數字摘要；
② 將數據用哈希函數進行運算，得到結果與數字摘要進行比對，驗證完整性。
📖 4.HTTPS的工作過程
直接介紹HTTPS的工作原理可能會有些難以理解，有了以上的知識儲備，我們可以自行推斷一下HTTPS的工作過程：
🔖過程推斷
① 只使用對稱加密
即通信雙方各自持有一個相同的密鑰，發送數據時，使用密鑰對明文加密；接收數據時使用密鑰將密文還原。如果這個密鑰只有通信雙方知曉，那么通信安全就可以得到保證。
但是并沒有想象的這么簡單，服務器需要同時對很多客戶端提供服務，如果與每個客戶端使用的密鑰都不一樣，那么服務器還需要維護客戶端與密鑰的關聯關系，這非常繁瑣。這種方法行不通。
② 只使用非對稱加密
如果通信雙方都使用非對稱加密呢，即雙方都持有各自的公鑰私鑰對，通信過程為：
1??在通信前，雙方先交換各自的公鑰；
2??服務器發送數據：使用客戶端的公鑰對數據加密；服務器接收數據：使用自己的私鑰對數據解密。
3??客戶端發送數據：使用服務器的公鑰對數據加密；客戶端接收數據：使用自己的私鑰對數據解密。
??但是我們上面提到了，非對稱加密的最大問題是運算速度很慢，如果雙方都使用非對稱加密的話，效率太低了。這種辦法也行不通
③ 非對稱加密+對稱加密
方法①的運行速度快，但問題在于，服務器要存儲管理每個客戶端的對稱密鑰，不論是否正在進行通信。那么我們可不可以優化一下，只在通信的過程中保存對稱密鑰，通信結束就解除綁定：
1??服務器擁有一對非對稱密鑰對，與客戶端進行通信前，先將公鑰發送給客戶端；
2??客戶端將自己的對稱密鑰通過公鑰加密，發送給服務器；
3??服務器通過解密得到對稱密鑰，之后的通信就可以通過這個對稱密鑰進行了。
上述過程只進行了一次非對稱加密解密過程，后面的操作全都是對稱的，這樣一來相比方法②大大提高了效率，看似是最可行的，但是！
上述過程都忽略了一個重要問題：如果在通信開始前，中間人攻擊就已經存在了呢?？
拿方法③舉例，服務器將公鑰發送給客戶端時被中間人截獲，中間人把自己的對稱密鑰加密后發送給服務器，這樣一來，中間人就可以假冒客戶端與服務器進行通信，而服務器對此一無所知；
相同地，中間人可以將自己的公鑰發送給客戶端，并獲取客戶端的對稱密鑰，這樣一來，中間人就可以假冒服務器與客戶端進行通信，客戶端對此也一無所知！
上面的問題關鍵在于：客戶端不能確定公鑰的來源，如果可以確定公鑰來自于服務器，就可以放心地將私鑰加密發送過去了。
要解決上述問題，就要引入證書的概念：
🔖證書?
服務端在使?HTTPS前，需要向CA機構申領?份數字證書，數字證書?含有證書申請者信息、公鑰信 息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書?獲取公鑰就?了，證書就如?份證，證明服務端公鑰的權威。
所以服務器向客戶端發送的其實是包含公鑰信息的證書，那么客戶端怎么通過證書驗證公鑰的來源正確性呢？
方法①：直接查看域名信息是否正確，但是如果證書被中間人篡改了呢，公鑰已經被替換了呢？
這里就要用到我們提到過的數據簽名。通過數據簽名，我們可以確保證書的完整性，具體步驟為：
1??客戶端收到證書，向CA機構申請還原簽名為數據摘要（私鑰只有CA機構擁有，確保了安全性）；
2??將明文信息通過哈西函數進行運算，將結果與摘要比對，如果相同，則公鑰可信；如果不相同，則公鑰不可信。
如此一來，就解決了中間人攻擊的問題。
?那如果中間人發送了一個合法的證書呢（中間人向CA機構申請了一個證書）
?只需要查看域名信息即可
?如果中間人用于申請證書的域名與真域名極度相似，造成混淆呢
?這就需要公安機關來“重拳出擊”了?
以上就是【HTTP的清風與HTTPS的密語】的全部內容，歡迎指正~?
碼文不易，還請多多關注支持，這是我持續創作的最大動力！
