HTTP協(xié)議一知半解？這篇幫你全面了解！

超文本傳輸協(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

• GET：用于請(qǐng)求訪問已經(jīng)被 URI（統(tǒng)一資源標(biāo)識(shí)符）識(shí)別的資源，可以通過 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)求沒有請(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 一般用來從服務(wù)器上獲取資源，POST 一般用來更新服務(wù)器上的資源；
• 從 REST 服務(wù)角度上說，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)求則是沒有大小限制的。

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 分類

• 1xx（臨時(shí)響應(yīng)）：信息，服務(wù)器收到請(qǐng)求，需要請(qǐng)求者繼續(xù)執(zhí)行操作；
• 2xx（成功）：操作被成功接收并處理；
• 3xx（重定向）：需要進(jìn)一步的操作以完成請(qǐng)求；
• 4xx（客戶端錯(cuò)誤）：請(qǐng)求包含語法錯(cuò)誤或無法完成請(qǐng)求；
• 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ā)生了什么？

• 由域名→ IP 地址 尋找 IP 地址的過程依次經(jīng)過了瀏覽器緩存、系統(tǒng)緩存、hosts 文件、路由器緩存、 遞歸搜索根域名服務(wù)器（DNS解析）。
• 建立 TCP/IP 連接（三次握手具體過程）。
• 由瀏覽器發(fā)送一個(gè) HTTP 請(qǐng)求。
• 經(jīng)過路由器的轉(zhuǎn)發(fā)，通過服務(wù)器的防火墻，該 HTTP 請(qǐng)求到達(dá)了服務(wù)器。
• 服務(wù)器處理該 HTTP 請(qǐng)求，返回一個(gè) HTML 文件。
• 瀏覽器解析該 HTML 文件，并且顯示在瀏覽器端。
• 服務(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 的不足

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

兩者區(qū)別

• 端口不同： Http 與 Http 使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；
• 資源消耗： 和 Http 通信相比，Https 通信會(huì)由于加減密處理消耗更多的 CPU 和內(nèi)存資源；
• 開銷： Https 通信需要證書，而證書一般需要向認(rèn)證機(jī)構(gòu)購買；

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)

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

來源：blog.csdn.net/csp732171109/article/details/122608300