各位看官老爺大家好，趁着一個陽光明媚的夜晚，閒來無事，開始了我的無聊博客.....
什麼是RPC？
RPC(Remote Procedure Call) 全名叫做遠程過程調用，計算機的一個通信協議，我在第一次接觸它的時候就是學到Dubbo的時候，當時我還是比較懵逼的，啥是RPC嘞(雖然現在也很懵逼)。
emm…就拿一個大家都熟悉的下訂單例子來解釋吧，我們現在的大型項目都是分佈式的，每一個模塊或者服務都是在不同的服務器上面，我們一個簡單的下訂單，就會使用到一系列的服務。比如說庫存模塊，折扣模塊，物流模塊，支付模塊，我們要使用它們，就必須要通知到它們，告訴它們, “嗨，兄弟，給我辦個事”, 於是，它們就會按照你的通知，完成你的需求，並將結果返回給你。這就是一次遠程調用（而這一過程對於我們使用者來說是透明的，我們只需要拿來用即可）（淺顯的理解，大佬勿噴）。
而如果我們想實現這樣的通信效果，就必須得進行網絡通信，如果每次調用都得進行網絡通信的代碼書寫的話，無疑是很麻煩的，如果，我們可以像單體架構那樣
@Autowired
private ProductService productService;
這麼注入，再進行對應方法的調用
productService.buy("六味地黃丸");
就可以進行方法的調用，而不用寫有關網絡編程的代碼,就會很舒服，天上飛的理念必有落地的實現，這就是RPC出現的原因，也是它廣爲人知的一個重要原因。而給我們提供了這種方式的具體實現，就是RPC框架。
什麼是http
http(Hyper Text Transfer Protocol )超文本傳輸協議，像我這種學web的小朋友天天低頭擡頭睜眼閉眼都是http，到底什麼是http呢?
接下來我們進行說文解字，關於這個，也是我逛博客的時候學的，所以，學的累了逛逛csdn還是很好的學習方式(我沒收黑錢，我也沒說博客園和簡書不好)
什麼是超文本 :
我們在兩臺電腦之間除了會想要傳輸一些文字外，視頻，圖片啥的也想要傳輸，所以，傳統的文本的定義就被擴大了，這種擴大了定義的文本就被稱爲了"超文本"
什麼是傳輸 :
在我們兩臺電腦之間進行數據的傳輸時，我們的傳輸的超文本會被解析爲二進制數據包，通過傳輸載體將二進制數據包由一個電腦終端傳送到另一個電腦終端的過程就叫做傳輸
什麼是網絡協議 :
在網絡中數據傳輸和管理的規範, 簡單的說，我們人之間如果進行交流的話，肯定要遵守某種規定，不然大家說的話肯定互相都聽不懂，同樣，對於發送和接收數據的兩臺電腦，都要遵守某種協議才能接受和發送數據，這種協議就叫做網絡協議。
說了這麼多，肯定有觀衆老爺開始嘀咕了, 媽的說麼這麼多還是沒有說什麼是http
其實將上面的一總結就是一個http的定義 :
所謂http， 就是指一種可以在兩臺電腦之間傳輸超文本的網絡協議
什麼是Https呢?
這裏，很多看客老爺就又要說了，媽的這就完了？, http那麼多東西你就說這麼點，爆出地址，給你寄點土特產.....
其實，這篇博客是小弟的第一次寫博客，主要是熟悉一下功能，後續會對這三種各分一篇進行詳細介紹
ps: 如果我會的話......
如果你認爲Https是Http的複數形式，就是很多個http的話，那就沒啥好說的了(ps : 其實我剛開始就是這麼想的)
好了，不扯犢子了，其實，在我們的http協議中，信息傳輸是以明文的方式，不做任何加密，我們的客戶端給服務器發送的請求完全是在網絡上"裸奔", 被中間人有意的截獲的話，會發生意想不到的後果，那可怎麼辦呢?
這可難不倒聰明的程序員，我們可以使用對稱加密方式，約定一個密鑰，後續的過程中，發送方和接收方都使用這一密鑰對信息進行加密和解密。
肯定有觀衆老爺又要問了, 媽的，啥是對稱加密了?
對於這樣的暴躁老哥，我採用度孃的話進行統一回復，對稱加密是指採用單鑰密碼系統的加密方法,同一個密鑰可以同時用作信息的加密和解密,也稱爲單密鑰加密。
這樣就安全了嗎? 道高一尺魔高一丈，我們的第一次發送加密方式和密鑰的請求是明文的，如果倒黴的話被中間人截獲了，中間人掌握了我們的加密方式和密鑰，那麼，後續的請求自然逃不過它的魔爪…
於是，我們又採用非對稱加密的方式對密鑰的傳輸做一層的額外的保護。
這次不等暴躁老哥提問，直接扔出度孃的回答來堵住暴躁老哥的嘴
對稱加密算法在加密和解密時使用的是同一個祕鑰；而非對稱加密算法需要兩個密鑰 來進行加密和解密，這兩個密鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）,
我在加一句，公鑰加密可以用私鑰解開，私鑰加密可以用公鑰解開
首先我們的客戶端在和服務端進行通信的時候，服務端將自己的公鑰GongKey1 發送給客戶端，收到服務端發的GongKey1後，客戶端自己生成一個用於對稱加密的密鑰Key1, 並用剛纔發過來的GongKey1對Key1進行加密，服務端用自己的私鑰SiKey將公鑰加密的Key1進行解密，然後就可以使用Key1進行通信了，這樣的話，即使在通信過程中，中間人截獲了第一次的公鑰，由於不知道私鑰是啥，也是無可奈何。
但是，黑客文化博大精神，按照慣例，這既然沒有說到https，就說明當前的做法依然是不安全的，怎麼破解呢？
中間人雖然不知道密鑰是什麼，但是可以攔截到公鑰之後進行調包，將自己生成的一對公鑰和私鑰中的公鑰發送給客戶端，天真的客戶端不知道此時危機已經悄悄的降臨，按照先前的流程，依然將自己的生成的對稱加密的密鑰用發送來的公鑰進行加密，發送給服務端，這就樂壞了中間人，用自己的私鑰將公鑰解密，提取出對稱加密的密鑰，於是，後續的就都被中間人所截獲了…所以，不管是中間人還是中間商都是可怕的東西…
最後，我們按照傳統的故事結尾，使用了終極大招，請外援(證書頒發機構), 和上面說的過程類似 ：
- 首先服務端將自己生成的公鑰GongKey發送給證書頒發機構，證書機構本身持有一對公鑰和私鑰，用自己的私鑰對服務端傳來的GongKey1進行加密，並通過服務端的地址來生成一個證書籤名，同樣使用了私鑰加密，證書完成後，證書機構將證書返回給服務端
- 當客戶端請求的時候，服務端並不是直接返回自己的公鑰，而是將自己的證書給客戶端進行發送
- 客戶噸接受之後，現鑑別真僞 : 各個瀏覽器和操作系統廠商已經將權威證書機構的名稱和公鑰進行了存儲，所以，客戶端通過證書機構的名稱，就可以從本地找出對應的公鑰，從而解密出了證書籤名
- 客戶端利用同樣的簽名規則生成一個證書籤名，如果兩個證書籤名一樣的話，就說明證書是有效的，然後客戶端就可以使用證書機構的公鑰，解密出服務端發來的公鑰，之後的流程就和之前一樣了，這裏只是防止了中間商，呸，中間人進行攔截調包。
- 我們的https就是在http協議的基礎上加上了SSL層，上面所說的認證過程就發生在了SSL層
- 上面的內容是我在一個公衆裏學會的，給大家安利一下(真的沒收黑錢，有好東西要大家分享嘛)，叫做程序員小灰，公衆號作者很用心，在裏面我也學到了很多…
結束語
是時候對各位看官老爺說再見了，全文3000字全部手寫，都夠打好幾把lol了！！
第一次寫博客，感覺寫的還可以，自我感覺良好，之後也會慢慢開始寫的，再次感謝各位看官老爺捧場.......
如對所寫內容有不同意見，請在評論區發表您的寶貴言論，我們共同進步!!!
最後，不管各位路過的看官老爺收穫如何，點個讚唄.....