請求安全性： 服務(wù)器端在接收到請求的時候，要主動鑒別該請求是否有效，是否可接受。

　　token:已登陸用戶的識別碼
　　　　解決的問題:用戶調(diào)用接口時，不用每次都帶上用戶名和密碼，避免了頻繁在網(wǎng)絡(luò)中傳輸密碼被截獲的風(fēng)險(xiǎn)。
　　　　使用場景:用戶登錄系統(tǒng)時傳入用戶名和密碼，服務(wù)器校驗(yàn)成功之后，根據(jù)uuid等參數(shù)生成token返回給客戶端，同時把該token和該用戶的對應(yīng)關(guān)系緩存在服務(wù)器端?？蛻舳嗽诤罄m(xù)的請求接口中不用每次都傳入用戶名和密碼，只需要傳入token即可。服務(wù)器會根據(jù)token確定客戶端的身份。
　　　　注意:token可設(shè)置生效時間，token失效之后，客戶端重新請求token。

? ? ? ? sign:請求參數(shù)的簽名
　　　　解決問題:避免請求參數(shù)被惡意修改。保證了請求數(shù)據(jù)的一致性。
　　　　使用場景:客戶端和服務(wù)端約定一個簽名生成算法?？蛻舳嗽谡埱蠼涌谥罢{(diào)用簽名算法，根據(jù)參數(shù)生成sign值。然后把sign和請求參數(shù)一并傳給服務(wù)器。
　　　　服務(wù)器收到到參數(shù)和簽名之后，根據(jù)請求參數(shù)，調(diào)用簽名算法計(jì)算出簽名，然后比較該簽名和客戶端傳過來的簽名是否一致，如果一致，則說明請求參數(shù)未被修改過，如果不一致，則說明請求參數(shù)被修改過。

　　nonce：請求中附帶的隨機(jī)數(shù)
　　　　解決問題:防止惡意程序重復(fù)向服務(wù)器重復(fù)發(fā)送相同的請求。
　　　　使用場景：客服端在向服務(wù)器發(fā)出請求之前，隨機(jī)生成nonce參數(shù)。服務(wù)器在接收到請求之后，取出nonce參數(shù)，然后去緩存中查找是否已存在nonce的值。如果存在，則說明該請求已經(jīng)收到過，則 拒絕本次請求，如果不存在，則說明首次接收到該請求，正常進(jìn)行處理。

　　timestamp：客服端發(fā)送請求的時間戳(timestamp一般和nonce組合使用)
　　　　解決的問題:防止服務(wù)器端緩存nonce數(shù)據(jù)量過大的問題。當(dāng)服務(wù)器緩存的nonce較多時，每次查找nonce就會耗費(fèi)大量時間。通過添加請求時間戳，判斷請求時間到服務(wù)器接收到請求的時間差是否在有效處理時間內(nèi)（例如5分鐘），如果在5分鐘之內(nèi)則進(jìn)行處理，如果超出五分鐘則拒絕該請求。這樣，服務(wù)器端在緩存nonce的時候，可以設(shè)置nonce的緩存時間為5分鐘，超出5分鐘之后，自動清除掉緩存中的nonce，這樣就避免了緩存大量nonce的問題。

　　　　使用場景:客服端在發(fā)出請求時，附帶timestamp，記錄下當(dāng)前的請求時間。服務(wù)器接收到請求時，取出timestamp，判斷和當(dāng)前的時間差，如果超出一定的時間(例如5分鐘)，則放棄該請求。如果在5分鐘之內(nèi)，則取出nonce，去緩存中查找nonce，如果已存在則拒絕掉，如果不存在則正常處理。

?

數(shù)據(jù)保密性： http請求的數(shù)據(jù)無論是GET還是POST都可能會被抓包獲取到數(shù)據(jù)。為了避免用戶的敏感數(shù)據(jù)被竊取，則需要對數(shù)據(jù)進(jìn)行加密處理。

? ? ? ??AES:對稱加密算法
　　　　使用方式:客服端和服務(wù)器端共同確定一個用來加密和解密的秘鑰。然后客服端在請求服務(wù)器是通過該秘鑰對數(shù)據(jù)進(jìn)行加密，服務(wù)器端在接收到請求之后使用該秘鑰對數(shù)據(jù)進(jìn)行解密。
　　　　優(yōu)勢：加密效率高
　　　　缺點(diǎn):秘鑰需要共享給客戶端，具有泄露的風(fēng)險(xiǎn)

? ? ? ??RSA:非對稱加密算法
　　　　使用方式:服務(wù)器端生成公鑰和私鑰，把公鑰發(fā)送給客戶端?？头嗽谡埱蠓?wù)器是，通過公鑰對數(shù)據(jù)進(jìn)行加密。服務(wù)器端接收到請求之后，使用私鑰對加密的數(shù)據(jù)進(jìn)行解密。
　　　　優(yōu)勢:不需要共享私鑰，避免了私鑰泄露的風(fēng)險(xiǎn)。
　　　　劣勢：加密效率低，數(shù)據(jù)量大是較為耗時

? ? ? ??實(shí)際場景中，一般使用如下策略進(jìn)行加密：

? ? ? ? ? ? ? ??服務(wù)器端通過RSA生成公鑰，然后把公鑰給客戶端。客服端在請求服務(wù)器前， 隨機(jī)生成AES秘鑰，然后用AES秘鑰加密請求數(shù)據(jù)。之后用RSA公鑰對AES秘鑰進(jìn)行加密，然后把加密之后的AES秘鑰和加密后的請求數(shù)據(jù)一起發(fā)送給服務(wù)器。服務(wù)器收到請求之后，先用RSA私鑰解密出AES秘鑰，然后用AES秘鑰對請求數(shù)據(jù)進(jìn)行解密，獲取請求數(shù)據(jù)。

?

? ? ? ?

其他常見算法說明：
　　　MD5:信息摘要算法,不是加密算法。
　　　　　　加密算法需要能夠解密出原始數(shù)據(jù)的。MD5是不可逆的，不存在解密的說法。MD5的目的是用來校驗(yàn)文件/數(shù)據(jù)是否和原始數(shù)據(jù)一致，是否被修改過。只要文件/數(shù)據(jù)被修改過，則計(jì)算出的MD5就不一致。SHA-1類似,可以從來文件校驗(yàn)和計(jì)算數(shù)字簽名。
　　　　　　應(yīng)用場景:作為計(jì)算sign簽名的算法，校驗(yàn)數(shù)據(jù)的一致性

　　Base64:編碼規(guī)范，不是加密算法。
　　　　　　其存在的目的是為了解決部分網(wǎng)絡(luò)傳輸不支持不可見字符的問題。通過Base64編碼把數(shù)據(jù)流轉(zhuǎn)化為可打印顯示的字符，之后通過網(wǎng)絡(luò)進(jìn)行傳輸。既然是編碼，那么就可以被解碼還原的。其類似于URL編碼,為了把一些特殊字符轉(zhuǎn)化為安全字符。
　　　　　　應(yīng)用場景:RSA的公鑰為byte數(shù)組，在傳給客戶端的時候 ，就可以通過Base64編碼把byte數(shù)組轉(zhuǎn)換為字符串，然后傳給客戶端。

?

總結(jié)

以上是生活随笔為你收集整理的网络请求中常见的加密机制和加密算法理解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。