資料傳輸安全性保證
前言
資料傳輸過程中，安全性十分重要，尤其是對於一些敏感的使用者資訊，其安全性保證更應當被重視。
現代軟體開發中，無論是基於敏捷式的軟體開發，或者基於前後端分離的軟體開發，都離不開提供對外介面，而請求這些介面資料的安全性應當得到保證。
方法
保證傳輸資料的安全性，主要有以下方法：
資料加密
資料加密一直是保密資料的重要部分，常見的加密演算法有可逆加密演算法和不可逆加密演算法，可逆加密演算法又分為對稱加密演算法和非對稱加密演算法。
比如一個系統的登陸操作，客戶輸入使用者名稱登陸，如果不進行任何保障措施，使用者名稱和密碼明文傳輸，被不法分子截獲資料後，顯然是不安全的。如果我們這時對密碼進行不可逆加密，如md5，對使用者名稱進行可逆加密，如des，這時候在截獲資料時，得到的將是一串密文，顯然，即使要破解，也需要相當時間。
但這樣，有一個明顯問題，就是介面吞吐量下降，明顯，加密情況下，由於需要解密資料，介面的響應速度會下降。
可能，對於一些非重要資料，我們這樣犧牲系統性能換取來的安全可能有些過了。
資料簽名
資料簽名又是什麼呢？它和資料加密的區別呢？
資料簽名，相當於對傳輸的資料，進行一些不可逆加密演算法後，如md5，生成一段簽名字串sign。
比如上述列子中，登陸操作中如果還要傳輸IP，地點等等資料，這些資料明顯沒那麼重要，這時可以對全部傳輸資料進行簽名，生成sign，將其傳入後端，後端用同樣演算法及金鑰計算比較sign，如果一致認為資料正確，直接拿到IP，地點等資料（不用解密，相對於解密各個資訊，理論上所有資訊計算簽名要節省時間），不一致則認為被修改過，返回錯誤資訊。
session，token機制
session（cookie）和token機制的出現是為了校驗使用者狀態的。
比如不法分子知道了我們的後臺介面，惡意偽造大量資料攻擊，即使這些資料不正確，而伺服器每次都需要校驗這些資料的正確性，顯然帶來大量效能消耗。
我們當然可以進行一些優化操作，如對於同一個IP，短時間大量請求則封掉該IP一段時間，但這不是太合理的。
設想，如果使用者登陸後，儲存狀態，只有登陸的使用者可以訪問這些介面，每次請求到來，均先校驗使用者登陸狀態，對於session，如果沒有sessionid或者sessionid錯誤或者過期則直接返回登陸介面。對於token，與session同理，沒有token或者token錯誤或者過期的直接返回登陸頁面。
這樣，我們開始校驗token或者session，就可以拒絕大量偽造請求。
Https（數字證書機制）
上面，無論資料加密還是簽名，我們發現最重要的就是加密方法和加密金鑰。
對於兩臺伺服器互動，可能不用太擔心，但是如果是webapp或者原生app，不法分子反編譯前端程式碼後，就有可能拿到加密方法和加密key，怎麼辦呢？
這就屬於Https要解決的事情，下篇文章會介紹https，這兒先簡單說下：
在加密演算法中，有一種叫做非對稱加密的演算法，有公鑰和私鑰組成，他有個特點：公鑰加密的資料，只有私鑰能解密；私鑰加密的資料，只有公鑰能解密。
https就是需要讓客戶端與伺服器端安全地協商出一個對稱加密演算法。剩下的就是通訊時雙方使用這個對稱加密演算法進行加密解密。
①客戶端啟動，傳送請求到服務端，服務端通過非對稱加密演算法（如RSA）生成公鑰pubkey1和私鑰prikey1。
②服務端將公鑰pubkey1發給客戶端，客戶端用自己的非對稱加密演算法也生成一套公鑰pubkey2和私鑰prikey2，並將公鑰pubkey2通過pubkey1加密後返回服務端。
③服務端用私鑰prikey1解密後拿到pubkey2，並將確定好的未來互動的對稱加密演算法和金鑰通過pubkey2加密，返回客戶端。
④客戶端用私鑰pubkey2解密資料，拿到伺服器給定的加密演算法和金鑰，雙方開始用其資料通訊。
這樣仍有一個問題，如何證明公鑰pubkey1加密的這串數字是客戶端來的，即證明他就是他。。。
這就是https的數字證書，相當於網路中心的部分，證明他就是他。數字證書就是來幹這個的。
其他
安全性保證還有其他可以自己操作的方法。
如對於兩臺穩定的伺服器互動，直接進行IP校驗或許比token，session機制更好更方便。及一些其他的操作，如同一IP短時間大量錯誤報文，可以將其暫時拉入黑名單。等等。
其他
資料安全一直是資料互動的永恆話題，保證資料安全，肯定是需要消耗一定的系統性能的。如何選擇合適的安全保證機制，是每一個軟體開發工程師應該瞭解和掌握的。