https HTTP一般以明文传输，容易被攻击者窃取重要信息。 所以HTTPS应运而生。
HTTPS的统称(hypertexttransferprotocoloversecuresocketlayer )是全名稍长，HTTPS和HTTP之间存在较大差异的是HTTPS旨在实现安全的HTTP通道
HTTPS是在HTTP中添加了SSL层，即HTTPS=HTTP SSL。
HTTPS工作在443端口，而HTTP默认工作在80端口。
SSL是“安全套接字层”的缩写，在中文中被称为“安全覆盖层”。 是20世纪90年代中期，网景公司设计的。 到了1999年，SSL得到了广泛的应用，成为了网上的事实标准。 ITF将SSL标准化。 标准化后，SSL更改为传输层安全协议(TLS )。 SSL/TLS
SSL原理详细信息SSL协议结构：
SSL协议分为两层，下层为SSL记录协议，上层为SSL握手协议、SSL密码更改协议、SSL告警协议。
1 .底层是SSL记录协议，主要作用是为上层协议提供基本的安全服务
构建在可靠传输的基础上，对高层数据进行分块、压缩、计算，添加、加密MAC (消息认证码)，最后将记录块传输给对方。
2 .上层为SSL握手协议、SSL密码更改协议、SSL报警协议
1 SSL握手协议： SSL握手协议封装在SSL日志记录协议中，服务器和客户端可以在APP应用程序发送和接收数据之前相互验证，并协商加密算法和密钥首次建立SSL连接时，服务器与客户端交换一系列消息。
2更改SSL密码协议：在SSL传输期间确保安全性，客户端和服务器都必须每隔一段时间更改加密规范
3 SSL报警协议：用于向对等方传递有关SSL的警告。 如果通信中有一方发现了某种异常，则需要向对方发送警告消息通知。
SSL工作大致可分为两个阶段http://www.Sina.com/handshake phase (握持手段阶段)
协商加密算法认证服务器是用于加密和消息认证代码(MAC )的会话密钥http://www.Sina.com/securedatatransferphase (安全传输码)
SSL协议提供的服务：1)通过已建立的SSL数据通道安全传输数据，对用户和服务器进行身份验证，确保数据被发送到正确的客户端和服务器
2 )加密数据，以免数据在途中被盗
3 )维护数据完整性，确保数据在传输过程中不发生更改。
如果hpdds在浏览器地址栏中输入以https开头的地址，则浏览器和服务器之间将在接下来的几百毫秒内进行大量通信。
认证服务器：浏览器包含受信任的CA机构列表，并存储这些CA机构的证书。 第一阶段的服务器提供通过CA机构认证颁发的服务器证书。 如果认证了服务器证书的CA机构存在于浏览器的受信任的CA机构的列表中，且服务器证书的信息与当前访问的站点(域名等)一致，则浏览器认为服务器端可信，从服务器证书中获取服务器的公钥，然后否则，浏览器会提示用户，并根据用户的选择决定是否继续。 当然，您可以管理此受信任的CA机构列表，添加您想信任的CA机构，或删除不信任的CA机构。
SSL原理
在使用SSL进行通信之前，首先使用SSL的Handshake协议在通信的两端握手，协商用于数据传输的相关安全参数，包括加密算法、共享密钥和生成密钥所需的资料
SSL阶段1中的客户端首先向服务端发送客户端hello消息，服务端收到客户端hello消息，然后发送服务器hello消息以响应客户端。
1.第一阶段：客户端浏览器向服务器端发送以下信息：
版本号(客户端支持的SSL /TLS协议的版本号。 ）
Random客户端生成的#随机数#
会话id会话id
Cipher Suite :加密套件包括三个部分：
1、加密算法； 2、完整性检查算法(MD5、哈希算法)； 3 )密钥协商算法主要是看客户端和服务端支持哪一种算法，客户端会将自己支持的加密算法发送给服务端。 压缩算法)。
预约
2.第二阶段：服务器端向客户端发送以下信息：
服务列出自己支持的版本，并与客户端进行比较，以检索客户端支持的最新版本
在服务器侧生成#随机数#
服务端也列出加密工具包，协商后使用统一的加密工具包
客户端产生的会话ID写进服务器里面
如果支持客户端的压缩算法，则使用
扩展包
在此阶段之后通信双方分别确定了：
1、SSL的版本；2、加密套件；3、压缩算法；4、俩个随机数
SSL第二阶段服务器向客户端发送消息，本阶段服务器是唯一发送方，客户端是唯一接收方。
本阶段共有四个消息，如下：
证书：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。服务器密钥交换（可选）：这里视密钥交换算法而定。证书请求：服务端可能会要求客户自身进行验证。服务器握手完成：第二阶段的结束，第三阶段开始的信号 Certificate（可选）——第一次建立必须要有证书一般情况下，除了会话恢复时不需要发送该消息，在SSL握手的全过程中都需要该消息。消息中包含一个X.509证书，证书中包含公钥，发给客户端用来验证签名或者在密钥交换时给消息加密。
这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥，以便后面的使用。
根据之前的client hello消息中的cipther suite信息决定了，密钥交换的方法（例如RSA和DH），因此在此消息中便会完成密钥交换所需的一系列参数。
Certificate Request（可选）——可以是单向身份认证，也可以是双向这一步是可选的，在安全性要求高的场合可以看到；服务端发送Certificate Request消息，请求客户端发送他自己的证书来进行验证。该消息中包含服务器端支持的证书类型（RSA、DSA、ECDSA），和服务器所信任的所有证书的发行机构的CA列表，客户端会用这些信息来筛选证书。
ServerHello Done表示服务器已将所有的信息发送完毕，等待客户端发送消息
SSL第三阶段客户端收到服务器发送的一系列消息并解析后，将本端相应的消息发送给服务器。
客户机启动SSL握手第3阶段，是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方。该阶段分为3步：
证书（可选）：为了对服务器证明自身，客户要发送一个证书信息，这是可选的，在IIS中可以配置强制客户端证书认证。
客户机密钥交换（Pre-master-secret）：这里客户端将预备主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。
证书验证（可选）：对从第一条消息以来的所有握手消息进行签名。
Certificate（可选） 如果在第二阶段服务器要求客户端发送证书，客户端便会发送自己的证书，服务器端之前在发送的Certificate Request消息中包含了服务器所支持的证书类型和CA列表，客户端会在证书中找到满足要求的一个发送给服务器。若客户端没有证书，则会发送一个no_certificate警告。
Client Key Exchange 根据之前从服务端收到的随机数，按照不同的密钥交换算法，算出一个Pre-master，发送给服务器，服务器收到pre-master,算出一个main-master。而客户端也能通过Pre-master自己算出一个main-master。如此一来，双方就算出了对称密钥。如果是RSA算法，会生成一个48位的随机数，然后用server的公钥加密后放入报文中；如果是DH算法，发送的就是客户端的DH参数，之后客户端和服务端根据DH算法，计算出相同的Pre-master secret。本消息在发送过程中，使用了服务器的公钥加密，服务器在收到后需要用服务器的私钥解密才能得到Pre-master Key。 Certificate Verify（可选）只有在客户端在发送了证书到服务端时，这个消息才需要发送，其中包含签名，对从握手第一条消息以来的所有握手消息的HMAC值（用master_secret）进行签名。
SSL第四阶段完成握手协议，建立SSL连接。
该阶段有四个消息交互，前两个为客户端发送，后两个为服务器发送。
建立起一个安全的连接，客户端发送一个Change Cipher spec消息，并且把协商得到的Cipher suite拷贝到当前连接的状态之中。然后客户端使用新的算法和密钥参数发送一个Finished消息，这条消息可以检测密钥交换和认证过程是否已经成功，其中包括一个校验值，对客户端整个握手消息进行校验。服务器同样发送一个Change Cipher Spec消息和Finished消息。握手过程完成，客户端和服务器可以交换应用层数据进行通信。
Change Cipher Spec编码改变通知，表示随后的信息将用双方商定的加密算法和和密钥发送（ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了）。
Client finished客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面所有发送的内容的hash值，用来供服务器校验。（使用HMAC算法计算收到和发送的所有握手消息的摘要，加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。）
Server Finished服务端握手结束通知。
使用私钥解密加密的Pre-master数据，基于之前(Client Hello 和 Server Hello)交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
计算之前所有接收信息的hash值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
发送一个Change Cipher Spec（告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了）
服务端也会使用Session Secret加密一段Finish消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。
会话恢复是指只要客户端和服务器已经通信过一次，它们就可以通过会话恢复的方式来跳过整个握手阶段而直接进行数据传输。SSL采用会话恢复的方式来减少SSL握手过程中造成的巨大开销。此功能从之前的13步减少到6步，大大减少了开销。
两种会话机制
会话标识 session ID: 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息，占用服务器资源较多;会话记录 session ticket :需要服务器和客户端都支持，属于一个扩展字段，支持范围约60%(无可靠统计与来源)，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务器资源很少。二者对比，主要是保存协商信息的位置与方式不同，类似与 http 中的 session 与 cookie。二者都存在的情况下，(nginx 实现)优先使用 session_ticket。
恢复过程
如果服务器和客户端之间曾经建立过连接，服务器会在握手成功后返回一个session ID，并保存对应的参数在服务器中。如果客户端和服务器需要再次连接，则需要在Client hello消息中携带记录的信息，返回给服务器。服务器根据收的到的Session ID检索缓存记录，如果有缓存，则返回一个Change Cipher Spec消息和Finished消息，如果没有缓存则正常进行握手。如果客户端能够验证通过服务器加密数据，则同样回复一个Change Cipher Spec消息和Finished消息。服务器验证通过则握手建立成功，开始进行正常的加密数据通信。
SSL记录协议主要用于实现对数据的分块、加密解密、压缩解压缩、完整性检测和封装各种高层协议。
主要包括：
内容类型协议版本号记录数据的长度数据有效载荷散列算法计算消息认证代码 将上层分下来的数据包分成合适的数据块，但是每个数据块不得超过214字节。对每个数据块进行压缩，但是不能丢失数据信息。计算压缩后的数据消息认证码MAC，并添加在压缩包后。添加后总长度不得超过2262字节。对称密码加密。给SSL添加一个首部。其中包括:内容类型、主要版本、次要版本、压缩长度等信息。通过以上过程把原始的数据加密为SSL协议的记录集。参考：https://blog.csdn.net/weixin_43997530/article/details/108048388