各位看官老爷大家好，趁着一个阳光明媚的夜晚，闲来无事，开始了我的无聊博客.....
什么是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了！！
第一次写博客，感觉写的还可以，自我感觉良好，之后也会慢慢开始写的，再次感谢各位看官老爷捧场.......
如对所写内容有不同意见，请在评论区发表您的宝贵言论，我们共同进步!!!
最后，不管各位路过的看官老爷收获如何，点个赞呗.....
