寫在最前

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

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

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

l PUT：傳輸文件，報文主體中包含文件內(nèi)容，保存到對應(yīng) URI 位置。

l HEAD：獲得報文首部，與 GET 方法類似，只是不返回報文主體，一般用于驗證 URI 是否有效。

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

l 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ū)別主要包括如下五個方面：

1. 從功能上講，GET 一般用來從服務(wù)器上獲取資源，POST 一般用來更新服務(wù)器上的資源
2. 從 REST 服務(wù)角度上說，GET 是冪等的，即讀取同一個資源，總是得到相同的數(shù)據(jù)，而 POST 不是冪等的，因為每次請求對資源的改變并不是相同的；
3. 從請求參數(shù)形式上看，GET 請求的數(shù)據(jù)會附在 URL 之后，即將請求數(shù)據(jù)放置在 HTTP 報文的請求頭中，以?分割 URL 和傳輸數(shù)據(jù)，參數(shù)之間以 & 相連；而 POST 請求會把提交的數(shù)據(jù)則放置在是 HTTP 請求報文的請求體中。
4. 從安全性上看，POST 的安全性要比 GET 的安全性高，因為 GET 請求提交的數(shù)據(jù)將明文出現(xiàn)在 URL 上，而且 POST 請求參數(shù)則被包裝到請求體中，相對更安全。
5. 從請求的大小看，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 分類

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

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

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

兩者區(qū)別

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

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ù)端都知道這個私鑰，所以只要加密算法夠厲害，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。

【7】傳輸加密后的信息

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

【8】客戶端解密信息

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

HTTPS 的缺點

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