寫在最前

超文本傳輸協(xié)議（Hyper Text Transfer Protocol救湖，HTTP）是一個(gè)簡(jiǎn)單的請(qǐng)求-響應(yīng)協(xié)議拣播，它是基于 TCP 協(xié)議的應(yīng)用層傳輸協(xié)議晾咪。它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。

HTTP 是一種無狀態(tài) (stateless) 協(xié)議, HTTP 協(xié)議本身不會(huì)對(duì)發(fā)送過的請(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

l GET：用于請(qǐng)求訪問已經(jīng)被 URI（統(tǒng)一資源標(biāo)識(shí)符）識(shí)別的資源税产，可以通過 URL 傳參給服務(wù)器。

l POST：用于傳輸信息給服務(wù)器偷崩，主要功能與 GET 方法類似辟拷，但一般推薦使用 POST 方式。

l PUT：傳輸文件阐斜，報(bào)文主體中包含文件內(nèi)容衫冻，保存到對(duì)應(yīng) URI 位置。

l HEAD：獲得報(bào)文首部谒出，與 GET 方法類似隅俘，只是不返回報(bào)文主體，一般用于驗(yàn)證 URI 是否有效笤喳。

l DELETE：刪除文件为居，與 PUT 方法相反，刪除對(duì)應(yīng) URI 位置的文件杀狡。

l 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)求沒有請(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è)方面：

1. 從功能上講呜象，GET 一般用來從服務(wù)器上獲取資源膳凝，POST 一般用來更新服務(wù)器上的資源
2. 從 REST 服務(wù)角度上說，GET 是冪等的恭陡，即讀取同一個(gè)資源蹬音，總是得到相同的數(shù)據(jù)，而 POST 不是冪等的休玩，因?yàn)槊看握?qǐng)求對(duì)資源的改變并不是相同的著淆；
3. 從請(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)求體中扬舒。
4. 從安全性上看，POST 的安全性要比 GET 的安全性高凫佛，因?yàn)?GET 請(qǐng)求提交的數(shù)據(jù)將明文出現(xiàn)在 URL 上讲坎，而且 POST 請(qǐng)求參數(shù)則被包裝到請(qǐng)求體中孕惜，相對(duì)更安全。
5. 從請(qǐng)求的大小看晨炕，GET 請(qǐng)求的長(zhǎng)度受限于瀏覽器或服務(wù)器對(duì) URL 長(zhǎng)度的限制衫画，允許發(fā)送的數(shù)據(jù)量比較小，而 POST 請(qǐng)求則是沒有大小限制的瓮栗。

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)體組成。

常見 Response Code 分類

1. 1xx（臨時(shí)響應(yīng)）：信息愿阐，服務(wù)器收到請(qǐng)求微服，需要請(qǐng)求者繼續(xù)執(zhí)行操作；
2. 2xx（成功）：操作被成功接收并處理缨历；
3. 3xx（重定向）：需要進(jìn)一步的操作以完成請(qǐng)求以蕴；
4. 4xx（客戶端錯(cuò)誤）：請(qǐng)求包含語法錯(cuò)誤或無法完成請(qǐng)求；
5. 5xx（服務(wù)器錯(cuò)誤）：服務(wù)器在處理請(qǐng)求的過程中發(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丛肮，然后回車，到底發(fā)生了什么觉吭？

1. 由域名→ IP 地址 尋找 IP 地址的過程依次經(jīng)過了瀏覽器緩存腾供、系統(tǒng)緩存、hosts 文件鲜滩、路由器緩存、 遞歸搜索根域名服務(wù)器（DNS解析）节值。
2. 建立 TCP/IP 連接（三次握手具體過程）徙硅。
3. 由瀏覽器發(fā)送一個(gè) HTTP 請(qǐng)求。
4. 經(jīng)過路由器的轉(zhuǎn)發(fā)搞疗，通過服務(wù)器的防火墻嗓蘑，該 HTTP 請(qǐng)求到達(dá)了服務(wù)器。
5. 服務(wù)器處理該 HTTP 請(qǐng)求匿乃，返回一個(gè) HTML 文件桩皿。
6. 瀏覽器解析該 HTML 文件，并且顯示在瀏覽器端幢炸。
7. 服務(wù)器關(guān)閉 TCP 連接（四次揮手具體過程）泄隔。

Https

HTTP 協(xié)議運(yùn)行在 TCP 之上，明文傳輸宛徊，客戶端與服務(wù)器端都無法驗(yàn)證對(duì)方的身份佛嬉。Https 是通過 SSL(Secure Socket Layer, 安全套接層 )或 TLS(Transport Layer Security, 安全層傳輸協(xié)議)的組合使用逻澳，加密 HTTP 的通信內(nèi)容。屬于通信加密暖呕，即在整個(gè)通信線路中加密斜做。

HTTPS 采用共享密鑰加密（對(duì)稱）和公開密鑰加密（非對(duì)稱）兩者并用的混合加密機(jī)制。若密鑰能夠?qū)崿F(xiàn)安全交換,那么有可能會(huì)考慮僅使用公開密鑰加密來通信湾揽。但是公開密鑰加密與共享密鑰加密相比,其處理速度要慢瓤逼。

HTTP 的不足

1. 竊聽風(fēng)險(xiǎn)：通信使用明文(不加密),內(nèi)容可能會(huì)被竊聽；
2. 冒充風(fēng)險(xiǎn)：不驗(yàn)證通信方的身份,因此有可能遭遇偽裝库物；
3. 篡改風(fēng)險(xiǎn)：無法證明報(bào)文的完整性,所以有可能已遭篡改抛姑；

兩者區(qū)別

1. 端口不同：Http 與 Http 使用不同的連接方式，用的端口也不一樣艳狐，前者是80定硝，后者是443；
2. 資源消耗：和 Http 通信相比毫目，Https 通信會(huì)由于加減密處理消耗更多的 CPU 和內(nèi)存資源蔬啡；
3. 開銷：Https 通信需要證書，而證書一般需要向認(rèn)證機(jī)構(gòu)購買镀虐；
4. 如果對(duì)部署證書有興趣可以看看：Docker通過Nginx箱蟆，ACME快速部署證書

HTTPS 工作原理

【1】客戶端發(fā)起 HTTPS 請(qǐng)求

用戶在瀏覽器里輸入一個(gè) https 網(wǎng)址，然后連接到 server 的 443 端口刮便。

【2】服務(wù)端的配置

采用 HTTPS 協(xié)議的服務(wù)器必須要有一套數(shù)字證書空猜，可以自己制作，也可以向組織申請(qǐng)恨旱，區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過辈毯，才可以繼續(xù)訪問，而使用受信任的公司申請(qǐng)的證書則不會(huì)彈出提示頁面搜贤。

這套證書其實(shí)就是一對(duì)公鑰和私鑰谆沃，可以想象成一把鑰匙和一個(gè)鎖頭，只是全世界只有你一個(gè)人有這把鑰匙仪芒，你可以把鎖頭給別人唁影，別人可以用這個(gè)鎖把重要的東西鎖起來，然后發(fā)給你掂名，因?yàn)橹挥心阋粋€(gè)人有這把鑰匙据沈，所以只有你才能看到被這把鎖鎖起來的東西。

【3】傳送證書

這個(gè)證書其實(shí)就是公鑰饺蔑，只是包含了很多信息锌介，如證書的頒發(fā)機(jī)構(gòu)，過期時(shí)間等等膀钠。

【4】客戶端解析證書

由客戶端的 TLS 來完成掏湾，首先會(huì)驗(yàn)證公鑰是否有效裹虫，比如頒發(fā)機(jī)構(gòu)，過期時(shí)間等等融击。如果發(fā)現(xiàn)異常筑公，則會(huì)彈出一個(gè)警告框，提示證書存在問題尊浪。

如果證書沒有問題匣屡，那么就生成一個(gè)隨機(jī)值，然后用證書對(duì)該隨機(jī)值進(jìn)行加密拇涤，就好像上面說的捣作，把隨機(jī)值用鎖頭鎖起來，這樣除非有鑰匙鹅士，不然看不到被鎖住的內(nèi)容券躁。

【5】傳送加密信息

用證書加密后的隨機(jī)值，目的就是讓服務(wù)端得到這個(gè)隨機(jī)值掉盅，以后客戶端和服務(wù)端的通信就可以通過這個(gè)隨機(jī)值來進(jìn)行加密解密了也拜。

【6】服務(wù)端解密信息

服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機(jī)值(私鑰)趾痘，然后把內(nèi)容通過該值進(jìn)行對(duì)稱加密慢哈，所謂對(duì)稱加密就是，將信息和私鑰通過某種算法混合在一起永票，這樣除非知道私鑰卵贱，不然無法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個(gè)私鑰侣集，所以只要加密算法夠厲害键俱，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全肚吏。

【7】傳輸加密后的信息

服務(wù)段用私鑰加密后的信息方妖，可以在客戶端被還原。

【8】客戶端解密信息

客戶端用之前生成的私鑰解密服務(wù)段傳過來的信息罚攀，于是獲取了解密后的內(nèi)容，整個(gè)過程第三方即使監(jiān)聽到了數(shù)據(jù)雌澄，也無法解密信息斋泄。

HTTPS 的缺點(diǎn)

1. HTTPS 協(xié)議多次握手，導(dǎo)致頁面的加載時(shí)間延長(zhǎng)近 50%镐牺；
2. HTTPS 連接緩存不如 HTTP 高效炫掐，會(huì)增加數(shù)據(jù)開銷和功耗；
3. SSL 涉及到的安全算法會(huì)消耗 CPU 資源睬涧，對(duì)服務(wù)器資源消耗較大募胃；

————————————————

版權(quán)聲明：本文為CSDN博主「九七年生于初夏」的原創(chuàng)文章旗唁，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明痹束。

原文鏈接：https://blog.csdn.net/csp732171109/article/details/122608300

作者：易道云控

鏈接：http://www.reibang.com/p/6153bf335d4b

來源：簡(jiǎn)書

著作權(quán)歸作者所有检疫。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處祷嘶。