我也忘了自己怎么就去了解这些东西了，既然已经了解了，就记下来吧。
Table of Contents
在讨论HTTPS和HTTP之前，我们先谈论一些概念： 明文、密文、密钥、对称加密、非对称加密、摘要、数字签名、数字证书 。当然谈论玩这些概念之后，HTTPS和HTTP的区别自然就出来了。
任何事物的发展都是循序渐进的过程，加密算法也是如此，由简单的加密算法到复杂加密算法是在加密算法研究解密研究不断地博弈中逐渐演进的。本文也将从简到难进行介绍。
一些基本概念和加密方式
明文：没有加密的原始数据
密文：加密之后的数据
秘钥：用于加密或者解密的钥匙，在这个场景中，秘钥是使用加密算法进行加密或解密的时候需要输入的参数。
对称加密：对称加密对应对称秘钥，也就是说在加密和解密的时候使用的是同一个参数。
非对称加密：分对称加密对应于两个秘钥，分别成为公钥和私钥。私钥顾名思义是私有的钥匙，是有发布方持有的，别人看不到的。公钥是发布方发布可以供任何人使用的钥匙。
使用方式有两种：
- 用私钥加密，然后用公钥解密
- 用公钥加密，然后用私钥解密
数字签名
签名，顾名思义是为了证明一个人的身份所做的事。比如服务器A发了一个数据给你，你怎么知道这个数据就是服务器A发给你的呢，而且这个这个数据在传输的过程中有没有被篡改过呢？那就需要验证服务器A的签名。以下是验证的步骤：
- 首先服务端会先把报文经过Hash处理转为Digest，然后使用私钥对这个Digest进行加密生成签名
- 报文和签名会一同发给客户端
- 在客户端，首先会使用公钥对签名进行解密，如果解密成功（生成Digest2），说明公钥和私钥是配对的，也就是说发送端就是客户端所期望的服务端。
- 然后客户端对收到的报文进行同样的Hash处理生成Digest1，如果Digest1和Digest2完全一致，则说明报文在传输过程中没有被更改过。
数字证书（CA, Certificate Authority )
为什么有了签名还需要CA，现在来解释一下。虽然客户端可以通过公钥来验证服务端签名的正确性，但是客户端该怎么保证公钥的正确性呢？比如现在客户端想从服务端A获取一个消息，但是有个攻击者A’冒充A对客户端说我就是A，并把产生的公钥给了客户端。这个时候客户端拿到了A’的公钥，但是客户端认为这个公钥是A的，所以当攻击者A’向客户端发了消息之后，客户端通过公钥验证了签名，便信以为真地认为是A给它发了信息，但其实信息是A’发的。所以说仅仅有数字签名还是有问题的。
所以说为了保证签名验证的正确性，就现需要保证公钥的正确性，而数字证书就是实现公钥正确性的手段。数字证书简称CA，它由权威机构给某网站颁发的一种认可凭证，这个凭证是被大家（浏览器）所认可的 。数字证书一般由数字证书认证机构发布，证书里面包含了真实服务器的公钥和网站的其他一些信息，数字证书机构用自己的私钥加密之后发给浏览器，浏览器用数字证书机构的公钥解密之后得到真实服务器的公钥。因为颁布证书的机构是一种权威的机构，是大家都认可的，因此是可信的。
不同加密方式的比较
现在将剖析一下上面提出的几种加密方式为什么有的是不安全的。
明文传输
显然是不安全的，很容易被中间人截获甚至更改传输的信息。
对称加密
假设A与B要进行对话，因为是对称加密，那么对话开始之前，A必要要把秘钥告诉B，如果秘钥在传输过程中被其他人知道了，那么其他人也可以用这个秘钥去解密信息，因此也不是很安全。
非对称加密
相对于对称加密要安全很多。加密的方式如下：
- 在开始聊天之前，A先生成一个密钥2，B生成一对公钥1和私钥1
- 聊天开始B把公钥1给A
- 然后A使用B给的公钥1加密自己的密钥2，并将加密之后的密钥2发给B，B通过私钥1解密得到密钥2，这样A和B就都有密钥2了，而且密钥2在传输的时候是经过加密的，也就是说不会被他人截获
- 最后A和B就可以都通过密钥2加密得到密文来进行聊天了
非对称加密看起来似乎是无懈可击的，但其实还是有破解的办法，假设在A与B进行聊天的时候，有一个中间人Bad Guy想偷听他们的对话，他可以这样做：
- 当B把公钥1给A的时候，Bad Guy从中间截获，并将公钥1替换为自己的公钥3给A
- 这时候A以为公钥3就是B给的，便用公钥3加密了密钥2发了除去，这是Bad Guy又从中间截获，解密获得密钥2，并将密钥2重新用公钥1加密给B，B收到后也成功解密得到了密钥2，此时B也觉得这个聊天好像没什么问题
- 在之后A与B的聊天中，由于都是通过密钥2加密的，这时候三者都有了密钥2，因此Bad Guy可以随意从中间获取A和B的聊天信息
签名和证书
关于签名和证书在上面已经具体说了，在这里就不分析了
HTTP和HTTPS
HTTP直接发送明文，很不安全，HTTPS会通过加密的方式传输信息更加的安全。
References
[1] 什么是 HTTPS 协议？