還有不懂 HTTP 協(xié)議的嗎？快來(lái)看吧
超文本傳輸協(xié)議（Hyper Text Transfer Protocol，HTTP）是一個(gè)簡(jiǎn)單的請(qǐng)求-響應(yīng)協(xié)議，它是基于 TCP 協(xié)議的應(yīng)用層傳輸協(xié)議。它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。
HTTP 是一種無(wú)狀態(tài) (stateless) 協(xié)議, HTTP 協(xié)議本身不會(huì)對(duì)發(fā)送過(guò)的請(qǐng)求和響應(yīng)的通信狀態(tài)進(jìn)行持久化處理。這樣做的目的是為了保持 HTTP 協(xié)議的簡(jiǎn)單性，從而能夠快速處理大量的事務(wù)，提高效率。
HTTP 請(qǐng)求體
HTTP 請(qǐng)求體是請(qǐng)求數(shù)據(jù)時(shí)發(fā)送給服務(wù)器的數(shù)據(jù)，畢竟向服務(wù)器拿數(shù)據(jù)，先要表明怎么要，以及要什么！
HTTP 請(qǐng)求體由：請(qǐng)求行 、請(qǐng)求頭、請(qǐng)求體組成。
常用的 HTTP Method
GET：用于請(qǐng)求訪問(wèn)已經(jīng)被 URI（統(tǒng)一資源標(biāo)識(shí)符）識(shí)別的資源，可以通過(guò) URL 傳參給服務(wù)器。POST：用于傳輸信息給服務(wù)器，主要功能與 GET 方法類似，但一般推薦使用 POST 方式。PUT：傳輸文件，報(bào)文主體中包含文件內(nèi)容，保存到對(duì)應(yīng) URI 位置。HEAD：獲得報(bào)文首部，與 GET 方法類似，只是不返回報(bào)文主體，一般用于驗(yàn)證 URI 是否有效。DELETE：刪除文件，與 PUT 方法相反，刪除對(duì)應(yīng) URI 位置的文件。OPTIONS：查詢相應(yīng) URI 支持的 HTTP 方法。
Post 請(qǐng)求示例
# Method URL Version 請(qǐng)求行
POST /httpLearn/postRequest HTTP/1.1
# Request Header 請(qǐng)求頭
Host: 127.0.0.1:8080
User-Agent: apifox/1.0.0 (https://www.apifox.cn)
Content-Length: 126
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
# Request Message 請(qǐng)求體
----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="param"
post
----WebKitFormBoundary7MA4YWxkTrZu0gW
Get 請(qǐng)求示例
Get 請(qǐng)求沒(méi)有請(qǐng)求體
# Method URL Version 請(qǐng)求行
GET /httpLearn/getRequest?param=123 HTTP/1.1
# Request Header 請(qǐng)求頭
Host: 127.0.0.1:8080
User-Agent: apifox/1.0.0 (https://www.apifox.cn)
GET 與 POST 的區(qū)別
GET 與 POST 是我們常用的兩種 HTTP Method，二者之間的區(qū)別主要包括如下五個(gè)方面：
從功能上講，GET 一般用來(lái)從服務(wù)器上獲取資源，POST 一般用來(lái)更新服務(wù)器上的資源； 從 REST 服務(wù)角度上說(shuō)，GET 是冪等的，即讀取同一個(gè)資源，總是得到相同的數(shù)據(jù)，而 POST 不是冪等的，因?yàn)槊看握?qǐng)求對(duì)資源的改變并不是相同的； 從請(qǐng)求參數(shù)形式上看，GET 請(qǐng)求的數(shù)據(jù)會(huì)附在 URL 之后，即將請(qǐng)求數(shù)據(jù)放置在 HTTP 報(bào)文的請(qǐng)求頭中，以?分割 URL 和傳輸數(shù)據(jù)，參數(shù)之間以 & 相連；而 POST 請(qǐng)求會(huì)把提交的數(shù)據(jù)則放置在是 HTTP 請(qǐng)求報(bào)文的請(qǐng)求體中。 從安全性上看，POST 的安全性要比 GET 的安全性高，因?yàn)?GET 請(qǐng)求提交的數(shù)據(jù)將明文出現(xiàn)在 URL 上，而且 POST 請(qǐng)求參數(shù)則被包裝到請(qǐng)求體中，相對(duì)更安全。 從請(qǐng)求的大小看，GET 請(qǐng)求的長(zhǎng)度受限于瀏覽器或服務(wù)器對(duì) URL 長(zhǎng)度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而 POST 請(qǐng)求則是沒(méi)有大小限制的。
Http 響應(yīng)報(bào)文
HTTP 的響應(yīng)報(bào)文是服務(wù)器返回的數(shù)據(jù)，必須先有請(qǐng)求體再有響應(yīng)報(bào)文。
HTTP 響應(yīng)報(bào)文由：狀態(tài)行、響應(yīng)頭、響應(yīng)體組成。
常見(jiàn) Response Code 分類
1xx（臨時(shí)響應(yīng)）：信息，服務(wù)器收到請(qǐng)求，需要請(qǐng)求者繼續(xù)執(zhí)行操作； 2xx（成功）：操作被成功接收并處理； 3xx（重定向）：需要進(jìn)一步的操作以完成請(qǐng)求； 4xx（客戶端錯(cuò)誤）：請(qǐng)求包含語(yǔ)法錯(cuò)誤或無(wú)法完成請(qǐng)求； 5xx（服務(wù)器錯(cuò)誤）：服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了錯(cuò)誤；
響應(yīng)示例
# Version Response Code 狀態(tài)行
HTTP/1.1 200 OK
# Response Header 響應(yīng)頭
Content-Type:text/plain;charset=UTF-8
Content-Length:31
Date:Wed, 19 Jan 2022 11:37:00 GMT
Keep-Alive:timeout=60
Connection:keep-alive
# Response Message 響應(yīng)體
post request is ok,param = post
一次完整 HTTP 請(qǐng)求所經(jīng)歷的步驟
當(dāng)我們?cè)?web 瀏覽器的地址欄中輸入：
www.baidu.com，然后回車(chē)，到底發(fā)生了什么？
由域名→ IP 地址 尋找 IP 地址的過(guò)程依次經(jīng)過(guò)了瀏覽器緩存、系統(tǒng)緩存、hosts 文件、路由器緩存、 遞歸搜索根域名服務(wù)器（DNS解析）。 建立 TCP/IP 連接（三次握手具體過(guò)程）。 由瀏覽器發(fā)送一個(gè) HTTP 請(qǐng)求。 經(jīng)過(guò)路由器的轉(zhuǎn)發(fā)，通過(guò)服務(wù)器的防火墻，該 HTTP 請(qǐng)求到達(dá)了服務(wù)器。 服務(wù)器處理該 HTTP 請(qǐng)求，返回一個(gè) HTML 文件。 瀏覽器解析該 HTML 文件，并且顯示在瀏覽器端。 服務(wù)器關(guān)閉 TCP 連接（四次揮手具體過(guò)程）。
Https
HTTP 協(xié)議運(yùn)行在 TCP 之上，明文傳輸，客戶端與服務(wù)器端都無(wú)法驗(yàn)證對(duì)方的身份。Https 是通過(guò) SSL(Secure Socket Layer, 安全套接層 )或 TLS(Transport Layer Security, 安全層傳輸協(xié)議)的組合使用，加密 HTTP 的通信內(nèi)容。屬于通信加密，即在整個(gè)通信線路中加密。
HTTPS 采用共享密鑰加密（對(duì)稱）和公開(kāi)密鑰加密（非對(duì)稱）兩者并用的混合加密機(jī)制。若密鑰能夠?qū)崿F(xiàn)安全交換,那么有可能會(huì)考慮僅使用公開(kāi)密鑰加密來(lái)通信。但是公開(kāi)密鑰加密與共享密鑰加密相比,其處理速度要慢。
HTTP 的不足
竊聽(tīng)風(fēng)險(xiǎn)： 通信使用明文(不加密),內(nèi)容可能會(huì)被竊聽(tīng)； 冒充風(fēng)險(xiǎn)： 不驗(yàn)證通信方的身份,因此有可能遭遇偽裝； 篡改風(fēng)險(xiǎn)： 無(wú)法證明報(bào)文的完整性,所以有可能已遭篡改；
兩者區(qū)別
端口不同： Http 與 Http 使用不同的連接方式，用的端口也不一樣，前者是80，后者是443； 資源消耗： 和 Http 通信相比，Https 通信會(huì)由于加減密處理消耗更多的 CPU 和內(nèi)存資源； 開(kāi)銷(xiāo)： Https 通信需要證書(shū)，而證書(shū)一般需要向認(rèn)證機(jī)構(gòu)購(gòu)買(mǎi)；
HTTPS 工作原理
【1】客戶端發(fā)起 HTTPS 請(qǐng)求
用戶在瀏覽器里輸入一個(gè) https 網(wǎng)址，然后連接到 server 的 443 端口。
【2】服務(wù)端的配置
采用 HTTPS 協(xié)議的服務(wù)器必須要有一套數(shù)字證書(shū)，可以自己制作，也可以向組織申請(qǐng)，區(qū)別就是自己頒發(fā)的證書(shū)需要客戶端驗(yàn)證通過(guò)，才可以繼續(xù)訪問(wèn)，而使用受信任的公司申請(qǐng)的證書(shū)則不會(huì)彈出提示頁(yè)面。
這套證書(shū)其實(shí)就是一對(duì)公鑰和私鑰，可以想象成一把鑰匙和一個(gè)鎖頭，只是全世界只有你一個(gè)人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個(gè)鎖把重要的東西鎖起來(lái)，然后發(fā)給你，因?yàn)橹挥心阋粋€(gè)人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來(lái)的東西。
【3】傳送證書(shū)
這個(gè)證書(shū)其實(shí)就是公鑰，只是包含了很多信息，如證書(shū)的頒發(fā)機(jī)構(gòu)，過(guò)期時(shí)間等等。
【4】客戶端解析證書(shū)
由客戶端的 TLS 來(lái)完成，首先會(huì)驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過(guò)期時(shí)間等等。如果發(fā)現(xiàn)異常，則會(huì)彈出一個(gè)警告框，提示證書(shū)存在問(wèn)題。
如果證書(shū)沒(méi)有問(wèn)題，那么就生成一個(gè)隨機(jī)值，然后用證書(shū)對(duì)該隨機(jī)值進(jìn)行加密，就好像上面說(shuō)的，把隨機(jī)值用鎖頭鎖起來(lái)，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。
【5】傳送加密信息
用證書(shū)加密后的隨機(jī)值，目的就是讓服務(wù)端得到這個(gè)隨機(jī)值，以后客戶端和服務(wù)端的通信就可以通過(guò)這個(gè)隨機(jī)值來(lái)進(jìn)行加密解密了。
【6】服務(wù)端解密信息
服務(wù)端用私鑰解密后，得到了客戶端傳過(guò)來(lái)的隨機(jī)值(私鑰)，然后把內(nèi)容通過(guò)該值進(jìn)行對(duì)稱加密，所謂對(duì)稱加密就是，將信息和私鑰通過(guò)某種算法混合在一起，這樣除非知道私鑰，不然無(wú)法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個(gè)私鑰，所以只要加密算法夠厲害，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。
【7】傳輸加密后的信息
服務(wù)段用私鑰加密后的信息，可以在客戶端被還原。
【8】客戶端解密信息
客戶端用之前生成的私鑰解密服務(wù)段傳過(guò)來(lái)的信息，于是獲取了解密后的內(nèi)容，整個(gè)過(guò)程第三方即使監(jiān)聽(tīng)到了數(shù)據(jù)，也無(wú)法解密信息。
HTTPS 的缺點(diǎn)
HTTPS 協(xié)議多次握手，導(dǎo)致頁(yè)面的加載時(shí)間延長(zhǎng)近 50%； HTTPS 連接緩存不如 HTTP 高效，會(huì)增加數(shù)據(jù)開(kāi)銷(xiāo)和功耗； SSL 涉及到的安全算法會(huì)消耗 CPU 資源，對(duì)服務(wù)器資源消耗較大；
鏈接：blog.csdn.net/csp732171109/article/details/122608300
（版權(quán)歸原作者所有，侵刪）
