目录
基本区别
Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。
二者之间存在如下不同：
端口不同：Http与Https使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗：和HTTP通信相比，Https通信会由于加解密处理消耗更多的CPU和内存资源；
开销：Https通信需要证书，而证书一般需要向认证机构购买；
HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。HTTPS协议要申请CA认证；HTTPS的安全基础是TLS/SSL
https使用的方式是对称加密+非对称加密相结合的手段 可以解决DNS劫持的问题（http协议访问网站有可能出现网站是钓鱼网站，劫持DNS）
什么是无状态，什么是无连接
标准的http协议是无状态的，无连接的
标准的http协议指的是不包括cookies, session，application（Application（Java Web中的ServletContext）这两个名词概念是不同的，暂时不做区分）：与一个Web应用程序相对应，为应用程序提供了一个全局的状态，所有客户都可以使用该状态。）的http协议，他们都不属于标准协议，虽然各种网络应用提供商，实现语言、web容器等，都默认支持它
无连接指的是什么
每一个访问都是无连接，服务器挨个处理访问队列里的访问，处理完一个就关闭连接，这事儿就完了，然后处理下一个新的
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接
(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。使用http协议，服务器中不会保存客户端的状态所产生的问题通过增加cookie和session机制解决了。）
对称加密与非对称加密
对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。
对称加密
小明和小红是一对“地下情侣”，可偏偏他们一个坐在教室前，一个坐在教室后，所以晚自习的时候也只能通过纸条传情。这时一个很尴尬的事情就出现了，由于无法直接将纸条交给对方，因此纸条必须要经过多个人的传递，可总有一两个八卦的人喜欢看纸条里写的什么。为了避免被班主任抓包以及被同学们窥视，他们两约定，用现代汉语词典当作“密码本”，以后传纸条时，纸条上的内容是要写的字在词典里的页码及顺序，这样即使纸条被别人看了，不知道密码本是什么的人也就不会得知纸条里的真正内容了。
在上述的例子中，纸条是承载信息的载体，纸条里的内容是信息，汉语词典是密钥，将文字映射到汉语词典的页码和顺序是加密方式（算法）。
类似于上面这种，在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥的加密方式就是对称密钥加密（Symmetric-key algorithm）
这种加密方式虽然简单，但是其弊端也是非常明显的。在上面的例子中，如果传递纸条的人知道了他们这种加密方式，那就同样可以通过查阅汉语词典解析出他们的纸条内容。如下图所示。这样为什么众多抗战片中会出现疯狂抢夺密码本这一情节也就很好理解了。
密钥：客户端，服务端用来加密解密
使用密钥做到是对称加密，使用同样一把钥匙加解密。
密钥是一个双方用来加密解密的，但是密钥本身也会出现安全性的问题。
事实上本身使用密钥的手段可以保证安全，但是密钥本身存在的安全问题。
非对称加密
小区里的小伙伴们经常可以在自家的邮箱里收到信件，比如你的录取通知书，当然更多可能是广告。不过，虽然说所有人都可以往里面扔邮件，但是只有你可以打开这个邮箱查看这个邮件。
上面这个过程就是一个很形象的非对称加密。
非对称加密不同于对称加密，它有一对秘钥，一个称为公钥（publicKey） ，另一个称为私钥（privateKey），并且*只知道公钥是无法推算出私钥。*就和上面的例子中只知道邮箱位置却并不能打开邮箱是一个道理。
使用公钥进行加密，就要使用对应的私钥进行解密
使用私钥进行解密，就要使用对应的公钥进行加密
对称加密效率比非对称加密的效率要高
公钥/私钥的用法
第一种用法：公钥加密，私钥解密。—用于加解密
第二种用法：私钥签名，公钥验签。—用于签名
其实很容易理解：
既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密；
既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。
这里提一点：签名 ≠ 加密，通俗点说加密就是你哪怕看到了不该看到的东西，也理解不了。而签名就是你做了任何事，都抵赖不了。
具体的加密解密的流程
https使用的方式是对称加密+非对称加密相结合的手段
先使用公钥私钥来生成密钥，也就是说使用非对称加密生成密钥可以保证密钥是真正可靠的是安全的
密钥生成以后，对称的加密解密
密钥用来加密解密真正的数据。
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
但是，这里如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
CA证书
通过CA（Certificate Authority）来保证public key的真实性。CA也是基于非对称加密算法来工作。有了CA，B会先把自己的public key（和一些其他信息）交给CA。CA用自己的private key加密这些数据，加密完的数据称为B的数字证书。现在B要向A传递public key，B传递的是CA加密之后的数字证书。A收到以后，会通过CA发布的CA证书（包含了CA的public key），来解密B的数字证书，从而获得B的public key。
证书的类型
权威的证书颁发机构的（CA）证书
如何确保那个工商管理局就是一个真的工商管理局，就是说工商管理局也应该有一个证书证明自己是一个权威别人不可以伪造自己是一个工商管理局。这个就是由CA机构来颁发的CA证书。
完全可以把一个假的CA证书发给浏览器，进而欺骗。CA的大杀器就是，CA把自己的CA证书集成在了浏览器和操作系统里面。A拿到浏览器或者操作系统的时候，已经有了CA证书，没有必要通过网络获取，那自然也不存在劫持的问题。
确保整个通过CA（Certificate Authority）来保证public key的真实性，
解决的问题：保证服务器是真实的，不是一个钓鱼网站
https服务器的证书 （服务器返回给客户端的证书）
解决的问题：明文传输数据的问题
证书中包含公钥的内容。
开始加密通信之前，客户端和服务器首先必须建立连接和交换参数，这个过程叫做握手（handshake）。
握手阶段
握手阶段分成五步。
这里的服务器返回的数字证书的来源 是通过CA，B会先把自己的public key（和一些其他信息）交给CA。CA用自己的private key加密这些数据，加密完的数据称为B的数字证书。
客户端拿到这个证书，证书里面就包含了公钥。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的公钥。将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
第四五步就是双方协商生成对话密钥，也即是根据公钥和私钥生成密钥的过程。之后双方采用“对话密钥” 进行加密通信
握手阶段有三点需要注意。
（1）生成对话密钥一共需要三个随机数。
整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。
（2）握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。
（3）服务器公钥放在服务器的数字证书之中。
通过CA证书理解加密解密
用户向web服务器发起一个安全连接的请求
服务器返回经过CA认证的数字证书，证书里面包含了服务器的public key(CA证书也就是由受信任的CA机构颁发给服务器证书)
用户拿到数字证书，用自己浏览器内置的CA证书解密得到服务器的public key
用户用服务器的public key加密一个用于接下来的对称加密算法的密钥，传给web服务器(公钥加密)
服务器拿到这个加密的密钥，解密获取密钥（私钥解密），再使用对称加密算法，和用户完成接下来的网络通信
发送数据
真正的发送数据的阶段:使用的对话密钥（也就是上面的密钥）对称加密方式加密解密传输数据，客户端使用对话密钥加密数据，服务端使用对话密钥解密数据。即使其他网站获取到了数据，但是它没有双方约定好的密钥，所以是无法进行解密的。
————————————————
版权声明：本文为CSDN博主「应钟二十六」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_45271990/article/details/115495121