http是非常常見的應用層協議，是超文字傳輸協議的簡稱，其傳輸的內容都是明文的。在這個混亂的世界，明文傳輸資訊想想就可怕，網路「小混混」的手段遠比我們這些凡人高明得多，他們有一萬種方式劫持，篡改我們的資料。對於乙個**或者服務，如果你給你的使用者兩個選擇：
通訊資料明文傳輸，速度快；
通訊資料加密傳輸，但是速度可能會稍微慢一點.
我想，只要腦袋沒有長歪的使用者都寧願犧牲一點速度去換取資料傳輸的安全。
這樣，https的存在就具備了合理性，https中的s表示ssl或者tls，就是在原http的基礎上加上一層用於資料加密、解密、身份認證的安全層。
雖然要層層漸進，但是我們不妨先奉上剛畫好的還熱乎著的https通訊完整流程圖：
從上圖可以看到，右邊有一堆鑰匙，一看到鑰匙我們就能想到這個過程免不了加密。另外，那些鑰匙長得還不一樣，有些只有一把，有些是一對，嗯，是的，你看得真仔細。
好的，扯遠了，現在開始層層漸進。
第一層（安全傳輸資料）
假如我們要實現乙個功能：乙個使用者a給乙個使用者b發訊息，但是要保證這個訊息的內容只能被a和b知道，其他的無論是墨淵上神還是太上老君都沒辦法破解或者篡改訊息的內容。
如上圖，需求就是這麼簡單，a給b發一條訊息，因為比較私密，不想被其他人看到。
由於訊息不想被其他人看到，所以我們自然而然就會想到為訊息加密，並且只有a和b才有解密的金鑰。這裡需要考慮幾點：
使用什麼加密方式？
金鑰怎麼告知對方？
對於第乙個問題，加密演算法分為兩類：對稱加密和非對稱加密，這裡我們選擇對稱機密，原因有如下幾個：
對稱加密速度快，加密時cpu資源消耗少；
非對稱加密對待加密的資料的長度有比較嚴格的要求，不能太長，但是實際中訊息可能會很長（比如你給你女朋友發情書），因此非對稱加密就滿足不了；
對於第二個問題，這是導致整個https通訊過程很複雜的根本原因。
如果a或b直接把他們之間用於解密的金鑰通過網際網路傳輸給對方，那一旦金鑰被第三者劫持，第三者就能正確解密a,b之間的通訊資料。
第二層（安全傳輸金鑰）
通過第一層的描述，第二層需要解決的問題是：安全地傳輸a,b之間用於解密資料的金鑰。
因為如果傳輸過程中這把金鑰被第三者拿到了，就能解密傳通訊資料，所以，這把金鑰必須得加密，就算第三者劫持到這把加密過的金鑰，他也不能解密，得到真正的金鑰。
這裡有乙個問題，那要用什麼方式加密這把金鑰呢？如果使用對稱加密，那這個對稱加密的金鑰又怎麼安全地告訴對方呢？完了，陷入死迴圈了…. 所以，一定不能用對稱加密
那就是用非對稱加密咯，那如何應用非對稱加密來加密那把金鑰呢？
考慮如下方式：
客戶端： 我要發起https請求，麻煩給我乙個非對稱加密的公鑰；
伺服器： (生成一對非對稱加密的金鑰對，然後把公鑰發給客戶端)，接著，這是公鑰；
客戶端：（收到公鑰，生成乙個隨機數，作為上圖中那一把金鑰，用剛才收到的公鑰加密這個金鑰，然後發給伺服器）這是我剛生成的加密過的金鑰；
伺服器：（收到加密後的金鑰，用本地的第一步自己生成的非對稱加密的私鑰解密，得到真正的金鑰）;
現在，客戶端和伺服器都知道了這把金鑰，就能愉快地用這個金鑰對稱加密資料…
分析一下上面步驟的可行性：
因為還可能存在一種」中間人攻擊」的情況，如下圖：
感謝xngpro的指正，上圖第7步，應該是『壞人用b私鑰解密得到k，然後使用a公鑰加密發給伺服器』
這種情況下，客戶端和伺服器之間通訊的資料就完全被壞人破解了。
第三層（安全傳輸公鑰）
從上一層可以知道，要保證資料的安全，就必須得保證伺服器給客戶端下發的公鑰是真正的公鑰，而不是中間人偽造的公鑰。那怎麼保證呢？
那就得引入數字證書了，數字證書是伺服器主動去權威機構申請的，證書中包含了上乙個圖中的加密過的a公鑰和權威機構的資訊，所以伺服器只需要給客戶端下發數字證書即可。現在流程圖如下：
那數字證書中的a公鑰是如何加密的呢？
答案是非對稱加密，只不過這裡是使用只有權威機構自己才有的私鑰加密。
等一下，既然a公鑰被權威機構的私鑰加密了，那客戶端收到證書之後怎麼解密證書中的a公鑰呢?需要有權威機構的公鑰才能解密啊！那這個權威機構的公鑰又是怎麼安全地傳輸給客戶端的呢？感覺進入了雞生蛋，蛋生雞的悖論了~~
別慌，答案是權威機構的公鑰不需要傳輸，因為權威機構會和主流的瀏覽器或作業系統合作，將他們的公鑰內建在瀏覽器或作業系統環境中。客戶端收到證書之後，只需要從證書中找到權威機構的資訊，並從本地環境中找到權威機構的公鑰，就能正確解密a公鑰。
這樣就絕對安全了嗎？既然權威技能能給伺服器簽發數字證書，那為什麼就不可能給中間人簽發數字證書呢?畢竟賺錢的生意權威機構也不會拒絕的呀。
試想一下：
伺服器給客戶端下發數字證書時證書被中間人劫持了，中間人將伺服器的證書替換成自己的證書下發給客戶端，客戶端收到之後能夠通過權威機構的公鑰解密證書內容（因為中間人的證書也是權威機構私鑰加密的），從而獲取公鑰，但是，這裡的公鑰並不是伺服器原本的a公鑰，而是中間人自己證書中的b公鑰。從第二層可知，如果不能保證客戶端收到的公鑰是伺服器下發的，那整個通訊資料的安全就沒法保證。簡單總結就是證書被調包~所以，還得保證客戶端收到的證書就是伺服器下發的證書，沒有被中間人篡改過。
第四層（安全傳輸證書）
這一層，我們的任務是：保證客戶端收到的證書是伺服器下發的證書，沒有被中間人篡改過。
所以，這裡就有兩個需求:
其實這些問題，數字證書本身已經提供方案了，數字證書中除了包含加密之後的伺服器公鑰，權威機構的資訊之外，還包含了證書內容的簽名(先通過hash函式計算得到證書數字摘要，然後用權威機構私鑰加密數字摘要得到數字簽名)，簽名計算方法以及證書對應的網域名稱。這樣一來，客戶端收到證書之後：
從上面的分析可以看到，數字證書中的資訊確實能讓客戶端辨別證書的真偽。
怎麼樣？經過這麼幾句通俗的話，是不是對https的通訊機制有了比較清晰的認識了。當然了，有一些可能是我胡扯的，不一定對，大家多多指正！
還不懂Redis？看完這個故事就明白了！
你好，我是redis，乙個叫antirez的男人把我帶到了這個世界上。說起我的誕生，跟關聯式資料庫mysql還挺有淵源的。在我還沒來到這個世界上的時候，mysql過的很辛苦，網際網路發展的越來越快，它容納的資料也越來越多，使用者請求也隨之暴漲，而每乙個使用者請求都變成了對它的乙個又乙個讀寫操作，my...
遞迴 邏輯解釋 看完不懂 罵我
方法 其實就是 計畫 遞迴 用白話邏輯思考 很簡單 比如 計畫 要去商場購買年貨，這個商場有6層樓。衣服 鞋 手機 床單 2 樓 首飾 超市 問題 我們決定先去 這樣我們可以輕鬆一點，不用拎著東西去 在拎著下來，是吧 到達 我麼要幹的事就是買東西吧，我已經計畫好 每層都要買，選購並返回 計算 總 是...
「啁啾」看完這篇再不懂，放棄吧
另一種常見的解釋 它實際上是一種調頻訊號。這句話不知道誤導了多少良家 在大多數人的認知裡，調頻指的是，高頻代表1，低頻代表0，用不同的頻率來代表數碼訊號。而 啁啾 並不是指訊號頻譜分析中對頻率分量的調製，指的對瞬時頻率的調製。概念區分 瞬時頻率 頻率分量 有乙個調角訊號ej 0t t e ej 0 ...