全網(wǎng)最強的 HTTP 協(xié)議講解

超文本傳輸協(xié)議（Hyper Text Transfer Protocol，HTTP）是一個簡單的請求-響應協(xié)議，它是基于 TCP 協(xié)議的應用層傳輸協(xié)議。它指定了客戶端可能發(fā)送給服務器什么樣的消息以及得到什么樣的響應。

HTTP 是一種無狀態(tài) (stateless) 協(xié)議, HTTP 協(xié)議本身不會對發(fā)送過的請求和響應的通信狀態(tài)進行持久化處理。這樣做的目的是為了保持 HTTP 協(xié)議的簡單性，從而能夠快速處理大量的事務，提高效率。

HTTP 請求體

HTTP 請求體是請求數(shù)據(jù)時發(fā)送給服務器的數(shù)據(jù)，畢竟向服務器拿數(shù)據(jù)，先要表明怎么要，以及要什么！

HTTP 請求體由：請求行 、請求頭、請求體組成。

常用的 HTTP Method

• GET：用于請求訪問已經(jīng)被 URI（統(tǒng)一資源標識符）識別的資源，可以通過 URL 傳參給服務器。
• POST：用于傳輸信息給服務器，主要功能與 GET 方法類似，但一般推薦使用 POST 方式。
• PUT：傳輸文件，報文主體中包含文件內(nèi)容，保存到對應 URI 位置。
• HEAD：獲得報文首部，與 GET 方法類似，只是不返回報文主體，一般用于驗證 URI 是否有效。
• DELETE：刪除文件，與 PUT 方法相反，刪除對應 URI 位置的文件。
• OPTIONS：查詢相應 URI 支持的 HTTP 方法。

Post 請求示例

# Method URL Version  請求行
POST /httpLearn/postRequest HTTP/1.1
# Request Header  請求頭
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  請求體
----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="param"

post
----WebKitFormBoundary7MA4YWxkTrZu0gW

Get 請求示例

Get 請求沒有請求體

# Method URL Version  請求行
GET /httpLearn/getRequest?param=123 HTTP/1.1
# Request Header  請求頭
Host: 127.0.0.1:8080
User-Agent: apifox/1.0.0 (https://www.apifox.cn)

GET 與 POST 的區(qū)別

GET 與 POST 是我們常用的兩種 HTTP Method，二者之間的區(qū)別主要包括如下五個方面：

• 從功能上講，GET 一般用來從服務器上獲取資源，POST 一般用來更新服務器上的資源；
• 從 REST 服務角度上說，GET 是冪等的，即讀取同一個資源，總是得到相同的數(shù)據(jù)，而 POST 不是冪等的，因為每次請求對資源的改變并不是相同的；
• 從請求參數(shù)形式上看，GET 請求的數(shù)據(jù)會附在 URL 之后，即將請求數(shù)據(jù)放置在 HTTP 報文的請求頭中，以?分割 URL 和傳輸數(shù)據(jù)，參數(shù)之間以 & 相連；而 POST 請求會把提交的數(shù)據(jù)則放置在是 HTTP 請求報文的請求體中。
• 從安全性上看，POST 的安全性要比 GET 的安全性高，因為 GET 請求提交的數(shù)據(jù)將明文出現(xiàn)在 URL 上，而且 POST 請求參數(shù)則被包裝到請求體中，相對更安全。
• 從請求的大小看，GET 請求的長度受限于瀏覽器或服務器對 URL 長度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而 POST 請求則是沒有大小限制的。

Http 響應報文

HTTP 的響應報文是服務器返回的數(shù)據(jù)，必須先有請求體再有響應報文。

HTTP 響應報文由：狀態(tài)行、響應頭、響應體組成。

常見 Response Code 分類

• 1xx（臨時響應）：信息，服務器收到請求，需要請求者繼續(xù)執(zhí)行操作；
• 2xx（成功）：操作被成功接收并處理；
• 3xx（重定向）：需要進一步的操作以完成請求；
• 4xx（客戶端錯誤）：請求包含語法錯誤或無法完成請求；
• 5xx（服務器錯誤）：服務器在處理請求的過程中發(fā)生了錯誤；

響應示例

# Version  Response Code  狀態(tài)行
HTTP/1.1 200 OK
# Response Header  響應頭
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  響應體
post request is ok,param = post

一次完整 HTTP 請求所經(jīng)歷的步驟

當我們在 web 瀏覽器的地址欄中輸入：www.baidu.com，然后回車，到底發(fā)生了什么？

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

Https

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

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

HTTP 的不足

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

兩者區(qū)別

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

HTTPS 工作原理

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

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

【2】服務端的配置

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

這套證書其實就是一對公鑰和私鑰，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發(fā)給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。

【3】傳送證書

這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機構，過期時間等等。

【4】客戶端解析證書

由客戶端的 TLS 來完成，首先會驗證公鑰是否有效，比如頒發(fā)機構，過期時間等等。如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。

如果證書沒有問題，那么就生成一個隨機值，然后用證書對該隨機值進行加密，就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。

【5】傳送加密信息

用證書加密后的隨機值，目的就是讓服務端得到這個隨機值，以后客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。

【6】服務端解密信息

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

【7】傳輸加密后的信息

服務段用私鑰加密后的信息，可以在客戶端被還原。

【8】客戶端解密信息

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

HTTPS 的缺點

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

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