全網最強的 HTTP 協議講解
寫在最前
超文本傳輸協議(Hyper Text Transfer Protocol
,HTTP)是一個簡單的請求 - 響應協議,它是基於 TCP 協議的應用層傳輸協議。它指定了客戶端可能發送給服務器什麼樣的消息以及得到什麼樣的響應。
HTTP 是一種無狀態 (stateless) 協議, HTTP 協議本身不會對發送過的請求和響應的通信狀態進行持久化處理。這樣做的目的是爲了保持 HTTP 協議的簡單性,從而能夠快速處理大量的事務,提高效率。
HTTP 請求體
HTTP 請求體是請求數據時發送給服務器的數據,畢竟向服務器拿數據,先要表明怎麼要,以及要什麼!
HTTP 請求體由:請求行 、請求頭、請求體組成。
常用的 HTTP Method
-
GET
:用於請求訪問已經被 URI(統一資源標識符)識別的資源,可以通過 URL 傳參給服務器。 -
POST
:用於傳輸信息給服務器,主要功能與 GET 方法類似,但一般推薦使用 POST 方式。 -
PUT
:傳輸文件,報文主體中包含文件內容,保存到對應 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;
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 的區別
GET 與 POST 是我們常用的兩種 HTTP Method,二者之間的區別主要包括如下五個方面:
-
從功能上講,GET 一般用來從服務器上獲取資源,POST 一般用來更新服務器上的資源;
-
從 REST 服務角度上說,GET 是冪等的,即讀取同一個資源,總是得到相同的數據,而 POST 不是冪等的,因爲每次請求對資源的改變並不是相同的;
-
從請求參數形式上看,GET 請求的數據會附在 URL 之後,即將請求數據放置在 HTTP 報文的請求頭中,以? 分割 URL 和傳輸數據,參數之間以 & 相連;而 POST 請求會把提交的數據則放置在是 HTTP 請求報文的請求體中。
-
從安全性上看,POST 的安全性要比 GET 的安全性高,因爲 GET 請求提交的數據將明文出現在 URL 上,而且 POST 請求參數則被包裝到請求體中,相對更安全。
-
從請求的大小看,GET 請求的長度受限於瀏覽器或服務器對 URL 長度的限制,允許發送的數據量比較小,而 POST 請求則是沒有大小限制的。
Http 響應報文
HTTP 的響應報文是服務器返回的數據,必須先有請求體再有響應報文。
HTTP 響應報文由:狀態行、響應頭、響應體
組成。
常見 Response Code 分類
-
1xx(臨時響應):信息,服務器收到請求,需要請求者繼續執行操作;
-
2xx(成功):操作被成功接收並處理;
-
3xx(重定向):需要進一步的操作以完成請求;
-
4xx(客戶端錯誤):請求包含語法錯誤或無法完成請求;
-
5xx(服務器錯誤):服務器在處理請求的過程中發生了錯誤;
響應示例
# Version Response Code 狀態行
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 請求所經歷的步驟
當我們在 web 瀏覽器的地址欄中輸入:
www.baidu.com
,然後回車,到底發生了什麼?
-
由域名→ IP 地址 尋找 IP 地址的過程依次經過了瀏覽器緩存、系統緩存、hosts 文件、路由器緩存、 遞歸搜索根域名服務器(DNS 解析)。
-
建立 TCP/IP 連接(三次握手具體過程)。
-
由瀏覽器發送一個 HTTP 請求。
-
經過路由器的轉發,通過服務器的防火牆,該 HTTP 請求到達了服務器。
-
服務器處理該 HTTP 請求,返回一個 HTML 文件。
-
瀏覽器解析該 HTML 文件,並且顯示在瀏覽器端。
-
服務器關閉 TCP 連接(四次揮手具體過程)。
Https
HTTP 協議運行在 TCP 之上,明文傳輸,客戶端與服務器端都無法驗證對方的身份。Https 是通過 SSL(Secure Socket Layer
, 安全套接層 ) 或 TLS(Transport Layer Security
, 安全層傳輸協議) 的組合使用,加密 HTTP 的通信內容。屬於通信加密,即在整個通信線路中加密。
HTTPS 採用共享密鑰加密(對稱)和公開密鑰加密(非對稱)兩者並用的混合加密機制。若密鑰能夠實現安全交換, 那麼有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比, 其處理速度要慢。
HTTP 的不足
-
竊聽風險: 通信使用明文 (不加密), 內容可能會被竊聽;
-
冒充風險: 不驗證通信方的身份, 因此有可能遭遇僞裝;
-
篡改風險: 無法證明報文的完整性, 所以有可能已遭篡改;
兩者區別
-
端口不同: Http 與 Http 使用不同的連接方式,用的端口也不一樣,前者是 80,後者是 443;
-
資源消耗: 和 Http 通信相比,Https 通信會由於加減密處理消耗更多的 CPU 和內存資源;
-
開銷: Https 通信需要證書,而證書一般需要向認證機構購買;
HTTPS 工作原理
【1】客戶端發起 HTTPS 請求
用戶在瀏覽器裏輸入一個 https 網址,然後連接到 server 的 443 端口。
【2】服務端的配置
採用 HTTPS 協議的服務器必須要有一套數字證書,可以自己製作,也可以向組織申請,區別就是自己頒發的證書需要客戶端驗證通過,纔可以繼續訪問,而使用受信任的公司申請的證書則不會彈出提示頁面。
這套證書其實就是一對公鑰和私鑰,可以想象成一把鑰匙和一個鎖頭,只是全世界只有你一個人有這把鑰匙,你可以把鎖頭給別人,別人可以用這個鎖把重要的東西鎖起來,然後發給你,因爲只有你一個人有這把鑰匙,所以只有你才能看到被這把鎖鎖起來的東西。
【3】傳送證書
這個證書其實就是公鑰,只是包含了很多信息,如證書的頒發機構,過期時間等等。
【4】客戶端解析證書
由客戶端的 TLS 來完成,首先會驗證公鑰是否有效,比如頒發機構,過期時間等等。如果發現異常,則會彈出一個警告框,提示證書存在問題。
如果證書沒有問題,那麼就生成一個隨機值,然後用證書對該隨機值進行加密,就好像上面說的,把隨機值用鎖頭鎖起來,這樣除非有鑰匙,不然看不到被鎖住的內容。
【5】傳送加密信息
用證書加密後的隨機值,目的就是讓服務端得到這個隨機值,以後客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。
【6】服務端解密信息
服務端用私鑰解密後,得到了客戶端傳過來的隨機值 (私鑰),然後把內容通過該值進行對稱加密,所謂對稱加密就是,將信息和私鑰通過某種算法混合在一起,這樣除非知道私鑰,不然無法獲取內容,而正好客戶端和服務端都知道這個私鑰,所以只要加密算法夠厲害,私鑰夠複雜,數據就夠安全。
【7】傳輸加密後的信息
服務段用私鑰加密後的信息,可以在客戶端被還原。
【8】客戶端解密信息
客戶端用之前生成的私鑰解密服務段傳過來的信息,於是獲取瞭解密後的內容,整個過程第三方即使監聽到了數據,也無法解密信息。
HTTPS 的缺點
-
HTTPS 協議多次握手,導致頁面的加載時間延長近 50%;
-
HTTPS 連接緩存不如 HTTP 高效,會增加數據開銷和功耗;
-
SSL 涉及到的安全算法會消耗 CPU 資源,對服務器資源消耗較大;
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/hEzu91CRPMvbrBvImPMibQ