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

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

HTTP 請求體

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

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

常用的 HTTP Method

• GET：用于請求訪問已經(jīng)被 URI（統(tǒng)一資源標識符）識別的資源，可以通過 URL 傳參給服務(wù)器。
• POST：用于傳輸信息給服務(wù)器，主要功能與 GET 方法類似，但一般推薦使用 POST 方式。
• PUT：傳輸文件，報文主體中包含文件內(nèi)容，保存到對應(yīng) URI 位置。
• HEAD：獲得報文首部，與 GET 方法類似，只是不返回報文主體，一般用于驗證 URI 是否有效。
• DELETE：刪除文件，與 PUT 方法相反，刪除對應(yīng) URI 位置的文件。
• OPTIONS：查詢相應(yīng) 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 一般用來從服務(wù)器上獲取資源，POST 一般用來更新服務(wù)器上的資源；
• 從 REST 服務(wù)角度上說，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 請求的長度受限于瀏覽器或服務(wù)器對 URL 長度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而 POST 請求則是沒有大小限制的。

Http 響應(yīng)報文

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

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

常見 Response Code 分類

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

響應(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 請求所經(jīng)歷的步驟

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

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

Https

HTTP 協(xié)議運行在 TCP 之上，明文傳輸，客戶端與服務(wù)器端都無法驗證對方的身份。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 通信需要證書，而證書一般需要向認證機構(gòu)購買；

HTTPS 工作原理

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

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

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

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

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

【3】傳送證書

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

【4】客戶端解析證書

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

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

【5】傳送加密信息

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

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

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

【7】傳輸加密后的信息

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

【8】客戶端解密信息

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

HTTPS 的缺點

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