1.HTTP請求的構(gòu)造

常見的構(gòu)造HTTP 請求的方式有以下幾種:

1. 直接通過瀏覽器地址欄, 輸入一個 URL 就可以構(gòu)造出一個 GET 請求.
2. 直接點擊收藏夾, 得到的也是 GET 請求.
3. HTML 中的一些特殊標(biāo)簽也會觸發(fā) GET 請求, 如: link, script, img, a…
4. 還可以通過form表單標(biāo)簽來實現(xiàn) GET/POST 請求的構(gòu)造.
5. 通過 JS 中的 ajax 實現(xiàn)各種請求的構(gòu)造.

1.1 from表單請求構(gòu)造

使用 form 表單標(biāo)簽構(gòu)造請求, action 屬性中的 URL 指的是接收請求的服務(wù)器地址.
基本格式:

<form action="URL" method="http方法類型"></form>

例如使用input標(biāo)簽來構(gòu)造HTTP請求:

<form action="https://www.baidu.com" method="get"><input type="text" name="StudentName"><input type="submit" value="提交">
</form>

上述代碼中,input type = "submit"構(gòu)造了一個特殊的提交按鈕,value屬性描述了按鈕中的文本.點擊這個按鈕就會觸發(fā)該from表單的提交操作.也就是構(gòu)造http請求發(fā)送給服務(wù)器.

輸入名字,點擊提交之后:

我們可以看到,我們構(gòu)造的這個請求,百度的服務(wù)器沒有做特別的處理,仍然返回的是百度主頁.
打開fiddler,可以看到:

接下來我們構(gòu)造一個pose請求:

<form action="https://www.baidu.com" method="pose"><input type="text" name="StudentName"><input type="submit" value="提交"></form>

對于from構(gòu)造的post請求來說,body里的數(shù)據(jù)格式就和query string是非常相似的.也是鍵值對結(jié)構(gòu).鍵值對之間使用&來分割.鍵和值之間使用=來分割.

值得注意的是,from標(biāo)簽只能構(gòu)造GET和POST,無法構(gòu)造PUT,DELET,OPTIONS等方法的請求.

1.2 ajax構(gòu)造HTTP請求

ajax即Asynchronous Javascript And XML（異步JavaScript和XML）也是瀏覽器提供的一種,通過js構(gòu)造HTTP請求的方式.它的功能比from更強.

關(guān)于同步和異步的理解:
A等待B:
同步:A始終盯著B,A負(fù)責(zé)關(guān)注B啥時候就緒.
異步:A不盯著B,B就緒之后主動通知A.(常見)

html中,通過ajax發(fā)起http請求,就屬于是"異步"的方式.這一行代碼執(zhí)行"發(fā)送請求"操作之后,不必等待服務(wù)器響應(yīng)回來,就立即往下執(zhí)行.當(dāng)服務(wù)器的響應(yīng)回來之后,再由瀏覽器通知到我們的代碼中.

代碼中使用ajax:

1. js提供ajax的api,但是原生api不好用(此處不做介紹)
2. jQuery提供的ajax,api針對原生api的封裝.較為簡單.

第一步, 引入 jQuery, 搜索 jQuery cdn, 找到一個 jQuery cdn 文件的 URL, 我們選擇 min 版本的, 比如我這里得到的是 https://cdn.bootcdn.net/ajax/libs/jquery/3.6.4/jquery.min.js.
第二步, 使用 $ 對象中的 ajax 函數(shù), 傳入一個 js 對象作為參數(shù), 這個對象里面需要包含 HTTP 方法類型 type, 請求的 url, 請求成功后該做什么 success, 失敗后該做什么 error

<!-- 引入query --><script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.6.4/jquery.min.js"></script><script>$.ajax({type:'get',url:'https://www.baidu.com?studentName=zhangsan',// 此處的success就聲明了一個回調(diào)函數(shù),就會在服務(wù)器響應(yīng)返回到瀏覽器的時候觸發(fā)該回調(diào).//此處的 回調(diào) 體現(xiàn)了 異步success:function(data){console.log("當(dāng)服務(wù)器返回的響應(yīng)到達(dá)瀏覽器之后,瀏覽器觸發(fā)該回調(diào),通知到我們的代碼中");}});console.log("瀏覽器立即往下執(zhí)行后續(xù)代碼");</script>

但是運行后我們可以看到:

該代碼直接執(zhí)行只能看到構(gòu)造的請求,無法獲取到正確的響應(yīng).因為我們發(fā)送請求給百度服務(wù)器,百度的服務(wù)器沒有處理我們的請求.

構(gòu)造請求的順序是從上到下的.但是收到響應(yīng)的順序/觸發(fā)回調(diào)的順序不確定.

ajax 相比于 form 標(biāo)簽功能更強, 構(gòu)造請求更加靈活, form 只支持 get 和 post 請求的構(gòu)造, 而 ajax 還支持 put, delete等, ajax 還可以靈活的設(shè)置 header 和body.

1.3 Postman的使用

Postman是谷歌的一款接口測試插件, 它使用簡單, 支持用例管理, 支持get, post, 文件上傳, 響應(yīng)驗證, 變量管理, 環(huán)境參數(shù)管理等功能, 可以批量運行, 并支持用例導(dǎo)出, 導(dǎo)入.
Postman下載(官網(wǎng))
下載好后可去’使用郵箱去注冊一個賬號進(jìn)行登錄
進(jìn)入后創(chuàng)建一個工作空間:

創(chuàng)建好后,再點擊+創(chuàng)建一個標(biāo)簽頁:

熟悉頁面:

除此之外,Postman還可以生成構(gòu)造請求的diamante,方便在我們自己的代碼中集成.

在此可以選擇使用哪種語言構(gòu)造HTTP請求.

2. HTTPS

2.1 什么是HTTPS?

在網(wǎng)絡(luò)傳輸過程中, 存在著運營商劫持和一些黑客入侵這樣的危險, 在之前只有HTTP的明文傳輸數(shù)據(jù)環(huán)境下, 這樣的問題是有些泛濫的, 這種情況下就不清楚在中間傳輸過程中就被哪一服務(wù)器將數(shù)據(jù)篡改了, 所以在后來就引入了HTTPS.

HTTPS (全稱: Hyper Text Transfer Protocol over Secure Socket Layer), 就是 HTTP + 安全層(SSL), 是以安全為目標(biāo)的 HTTP 通道, 簡單講就是 HTT P的安全版本, 即 HTTP 下加入 SSL 層, HTTPS 的安全基礎(chǔ)是 SSL.

HTTPS 和 HTTP 一樣, 都是應(yīng)用層協(xié)議, HTTPS 相比于 HTTP 多了一個加密的功能, 就是在 HTTP 基礎(chǔ)上引入了SSL/TLS 加密機制, 該功能作用不是防止數(shù)據(jù)被窺察, 而是為了防止數(shù)據(jù)被篡改, HTTP 是明文傳輸, HTTPS 是密文傳輸, HTTPS 可以更好地保護數(shù)據(jù)的傳輸.

如何理解這里的安全?

安全這個概念只是相對而言, “道高一尺, 魔高一丈”, 不管安全措施如何完善, 相信總是有更厲害的大佬有針對攻擊辦法, 但我們認(rèn)為, 網(wǎng)絡(luò)傳輸中, 只要黑客解密的成本超過了數(shù)據(jù)本身的價值, 就認(rèn)為是安全的了.

這里有幾個專有名詞需要了解一下

明文: 傳輸?shù)脑紨?shù)據(jù).
密文: 原始數(shù)據(jù)被加密后的數(shù)據(jù).
密鑰: 可以將明文轉(zhuǎn)換成密文, 也可以將密文轉(zhuǎn)換為明文的 “鑰匙”.

2.2 HTTPS中的加密機制(SSL/TLS)

HTTPS 引入的加密層, 稱為 SSL 或 TLS, 在 SSL 中加密的機制主要有兩種:

1. 對稱加密
2. 非對稱加密

SSL/TLS 部分其實并不是只在 HTTPS 中使用, 在其他的場景中也會用到(比如 SSH 協(xié)議, JDBC 等).

2.2.1 HTTP的安全問題

HTTP 是明文傳輸?shù)? 當(dāng)有黑客或者運營商從中作梗, 就可以直接篡改客戶端和服務(wù)器之間傳輸?shù)臄?shù)據(jù), 此時就沒有什么安全性可言, 客戶端和服務(wù)器拿到什么樣的數(shù)據(jù)完全就是黑客說了算了.

也就是說, 只要網(wǎng)絡(luò)上的數(shù)據(jù)是明文傳輸?shù)? 都是存在被劫持, 被篡改的風(fēng)險的, 所以為了能夠改善這種問題, 就引入了加密, HTTPS 就應(yīng)運而生了.

2.2.2 對稱加密

對稱加密就是客戶端和服務(wù)器使用相同的密鑰對密文進(jìn)行加密與解密, 密鑰就可以認(rèn)為是一串?dāng)?shù)字/字符串, 加密就是把明文 (HTTPS 中就是針對 HTTP 的各種 header 和 body) 和密鑰字符串進(jìn)行一系列的數(shù)學(xué)變換.

a(明文) + key = b(密文), 這是加密的過程

b(密文) + key = a(明文), 這是解密的過程

要注意, 這里密文傳輸安全的前提是黑客并不知道密鑰是什么, 這就要求不同的客戶端使用的是不同的密鑰才行, 因為如果不同客戶端使用的是相同的密鑰, 那么黑客只需要自己啟動一個客戶端就能拿到密鑰, 成本不高, 就沒什么安全可言了.

所以, 不同的客戶端需要有不同的密鑰, 這個密鑰要么由服務(wù)器生成, 要么由客戶端生成, 假設(shè)我們這里是由客戶端生成密鑰, 客戶端生成密鑰后就需要在傳輸數(shù)據(jù)之前需要先將密鑰發(fā)送給服務(wù)器, 即如下過程:

這樣不同的客戶端就使用了不同的對稱密鑰來對數(shù)據(jù)進(jìn)行加密, 那么當(dāng)客戶端生成對稱密鑰后, 先將對稱密鑰傳輸?shù)椒?wù)器, 服務(wù)器拿到密鑰后再進(jìn)行業(yè)務(wù)數(shù)據(jù)的傳輸, 之后就使用從客戶端拿到的密鑰進(jìn)行數(shù)據(jù)的加密和解密了.
但此時還是有問題的, 一開始密鑰傳輸?shù)陌踩珕栴}如何得到保障呢? 在此時的場景下, 密鑰剛剛生成, 也就是服務(wù)器還不知道密鑰是什么, 所以這次密鑰的傳輸還是只能使用明文傳輸, 很容易就被黑客攔截獲取了, 這樣的加密也就形同虛設(shè)了, 所以就引入了下面的 “非對稱加密”.

2.2.3 非對稱加密

為了讓密鑰安全的傳輸?shù)椒?wù)器, 就需要對密鑰也進(jìn)行加密.

對于非對稱加密, 它擁有兩個密鑰, 一個公鑰和一個私鑰, 其中公鑰 “人人” 都能獲取到, 而私鑰是構(gòu)造私鑰的 “人” 才知道.

相當(dāng)于我們現(xiàn)實生活中的鎖與鑰匙, 而這個鎖就相當(dāng)于公鑰, 鑰匙就相當(dāng)于私鑰.

其中公鑰是用來加密的, 而私鑰是用來解密的.

明文 + 公鑰 = 密文
密文 + 私鑰 = 明文

此時, 就可以使用非對稱加密了, 首先客戶端會向服務(wù)器詢問服務(wù)器的公鑰是什么, 然后服務(wù)器會向客戶端發(fā)送一個公鑰, 客戶端收到公鑰后會使用這個公鑰對客戶端構(gòu)造的對稱密鑰進(jìn)行加密, 然后會把加密后的對稱密鑰傳輸給服務(wù)器, 服務(wù)器使用私鑰解密得到客戶端的對稱密鑰, 之后的業(yè)務(wù)數(shù)據(jù)就可以使用這個對稱密鑰進(jìn)行加密和解密了(對稱加密).
注意的是,非對稱加密只是用來傳輸密鑰的,一旦對稱密鑰到達(dá)服務(wù)器之后,后續(xù)的傳輸都是使用對稱密鑰來加密和解密.
那么為什么有了非對稱加密,還要繼續(xù)使用對稱加密呢?
這是因為使用對稱加密傳輸?shù)乃俣仁潜容^快的,而非對稱加密速度就慢很多.實際場景會要求盡可能提高整體的速度,使用對稱加密更為合適.

2.2.3 中間人問題

有了上面的非對稱加密, 數(shù)據(jù)傳輸?shù)陌踩鋵嵾€是存在問題的, 可能會存在 “中間人” 問題, 這個中間人對于服務(wù)器會偽裝成 "客戶端"的身份, 對于客戶端, 中間人就會偽裝成 “服務(wù)器”;

當(dāng)服務(wù)器發(fā)送自己的公鑰給客戶端,中間人也會生成一對公鑰與私鑰,中間人就把服務(wù)器的公鑰換成自己的公鑰,然后客戶端使用中間人的公鑰加密對稱密鑰,然后發(fā)送給服務(wù)器,此時中間人就可以通過自己的私鑰獲得對稱密鑰,獲取密鑰后中間人會將密鑰使用服務(wù)器的公鑰在加密發(fā)送給服務(wù)器.

此時數(shù)據(jù)傳輸又變成"透明"的了,在之后的對稱加密傳輸過程中,中間人已經(jīng)知道了對稱密鑰,就可以將客戶端請求/服務(wù)器響應(yīng)的密文數(shù)據(jù)解密得到原始數(shù)據(jù),中間人就可以針對原始數(shù)據(jù)進(jìn)行篡改,然后再加密發(fā)送,這樣中間人就能夠拿到客戶端和服務(wù)器之間的傳輸數(shù)據(jù),可以進(jìn)行查看和篡改.

2.2.5 證書

中間人問題的解決方案是引入一個第三方工信機構(gòu), 現(xiàn)在的服務(wù)器 (網(wǎng)站) 一般在設(shè)立之初, 就需要去專門的認(rèn)證機構(gòu), 申請證書, 服務(wù)器先提供資質(zhì)證明給工信機構(gòu), 工信機構(gòu)通過審核后, 會給服務(wù)器發(fā)送一個證書, 該證書不是普通的證書, 里面含有一些校驗機制 (校驗的過程類似 TCP/UDP 的校驗和), 然后服務(wù)器會把自己的公鑰放入證書中, 客戶端也不再詢問公鑰, 而是詢問服務(wù)器證書, 得到證書后會去查該證書是否合法, 如果合法才會使用服務(wù)器證書中的公鑰去進(jìn)行對密文請求與密鑰的加密, 并發(fā)送給服務(wù)器, 如果不合法瀏覽器就會彈窗警告.

這個過程就類似于我們使用的身份證來證明身份, 派出所就是第三方的認(rèn)證機構(gòu), 身份證是無法被其他地方生成或者篡改的, 其他人就可以通過身份證來辨識我們的身份.

那么客戶端是如何對證書進(jìn)行驗證的呢?
實際上, 操作系統(tǒng)是會內(nèi)置一些工信機構(gòu)的信息(包含工信機構(gòu)的公鑰)的.

首先我們需要知道證書上面會有一個特定的字段, 叫做證書的簽名, 這個簽名是一個被加密的字符串, 是通過對證書中所有的屬性, 計算出來的一個校驗和(簽名), 再由頒布證書的工信機構(gòu)使用它的私鑰對這個簽名進(jìn)行加密.

證書
字段1:abc
字段2:cde
字段3:okm
公鑰:0x112233

簽名:dgiuwdhqduhouiqdhq

此處的簽名就是被加密的字符串.
客戶端就可以使用認(rèn)證機構(gòu)提供的公鑰進(jìn)行解密,解密之后,得到的結(jié)果相當(dāng)于是一個hash1值.(類似于tcp udp里的校驗和 根據(jù)證書的其他字段綜合計算出來的結(jié)果)
客戶端可以使用同樣的hash算法,針對其他字段再算一次hash值,得到hash2.
看看hash1(從簽名中解出來的)和hash2(客戶端自己算的)值是否相同.相同就是沒有被篡改過的.

黑客即使把證書中服務(wù)器的公鑰篡改替換成自己的公鑰, 然后黑客再針對證書中的各個屬性, 重新計算簽名, 下一步, 黑客就需要把簽名重新加密, 這里黑客就無能為力了, 因為想要加密, 黑客就必須知道工信機構(gòu)的私鑰, 顯然, 黑客是無法知道的.