图片来自云时代架构
HTTPS（全称：Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。正因为它的安全性，才使用https。
在我们王服务器发送隐私数据时例如银行卡身份证啥的，这些数据是不能被他人获取到的，如果使用http进行通信，数据传输间的安全性得不到保障可能会被他人所截取，最后被他人所利用。总结其有三点弊端：
-
无法保证消息的保密性
-
无法保证消息的完整性和准确性
-
无法保证消息来源的可靠性
为了解决http中存在的问题，https采用了一些加解密，数字证书，数字签名的技术来实现。
对称加密与非对称加密
为了保证消息的保密性，就需要用到加密和解密。加解密算法目前主流的分为对称加密和非对称加密。
1.对称加密（共享密匙加密）：客户端和服务器公用一个密匙用来对消息加解密，这种方式称为对称加密。客户端和服务器约定好一个加密的密匙。客户端在发消息前用该密匙对消息加密，发送给服务器后，服务器再用该密匙进行解密拿到消息。
但是存在密钥泄露也存在安全性问题。
2.非对称加密（公有密匙加密）：既然对称加密中，密匙那么容易泄露，那么我们可以采用一种非对称加密的方式来解决。
采用非对称加密时，客户端和服务端均拥有一个公有密匙和一个私有密匙。公有密匙可以对外暴露，而私有密匙只有自己可见。
使用公有密匙加密的消息，只有对应的私有密匙才能解开。反过来，使用私有密匙加密的消息，只有公有密匙才能解开。这样客户端在发送消息前，先用服务器的公匙对消息进行加密，服务器收到后再用自己的私匙进行解密。
非对称加密也存在不安全可能，而且性能相对对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。正是因为如此，https将两种加密结合了起来。
数字证书与数字签名
为了解决非对称加密中公匙来源的不安全性。我们可以使用数字证书和数字签名来解决。
https没有采用单一的技术去实现，而是根据他们的特点，充分的将这些技术整合进去，以达到性能与安全最大化。这套整合的技术我们称之为SSL（Secure Scoket Layer 安全套接层）。所以https并非是一项新的协议，它只是在http上披了一层加密的外壳。
流程图：
1.客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密匙长度等）。
2.服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容时从接收到的客户端加密组件内筛选出来的。
3.服务器发送证书报文。报文中包含公开密匙证书。
4.最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
5.SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密匙进行加密。
6.接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密匙加密。
7.客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
8.服务器同样发送Change Cipher Spec报文
9.服务器同样发送Finished报文
10.服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会收到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
11.应用层协议通信，即发送HTTP相应。
12.最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信
使用场景：
1.https虽然提供了消息安全传输的通道，但是每次消息的加解密十分耗时，消息系统资源。所以，除非在一些对安全性比较高的场景下，比如银行系统，购物系统中我们必须要使用https进行通信，其他一些对安全性要求不高的场景，其实没必要使用https。
2.使用https需要使用到数字证书，但是一般权威机构颁发的数字证书都是收费的，而且价格也是不菲的，所以对于一些个人网站特别是学生来讲，如果对安全性要求不高，也没必要使用https。