面试常见问题，HTTPS优化总结易记版：
1、HSTS重定向技术：将http自动转换为https，减少301重定向
2、TLS握手优化：在TLS握手完成前客户端就提前向服务器发送数据
3、会话标识符：服务器记录下与某客户端的会话ID，下次连接客户端发ID过来就可以直接用之前的私钥交流了
4、OSCP Stapling：服务器将带有 CA 机构签名的 OCSP 响应在握手时发给客户端，省的客户端再去CA查询
5、完全前向加密PFS：使用更牛逼复杂的秘钥算法
HTTP与HTTPS介绍
超文本传输协议HTTP协议被用于在Web浏览器和网站服务之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
套接字：
套接字是一种通信机制，它有三个属性确定，它们是域（domain），类型（type），和协议（protocol）。域指定套接字通信中使用的网络介质，最常见的是AF_INET（IPv4）或者AF_INET6（IPv6），它们用于Internet网络。类型包括流套接字（SOCK_STREAM）、数据报套接字（SOCK_DGRAM）和原始套接字（SOCK_RAW）。流套接字用于提供面向连接、可靠的数据传输服务，数据报套接字提供无连接的服务，而原始套接字可以读写内核没有处理的IP数据包。
HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全
HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
HTTPS和HTTP的主要区别
- https协议需要到CA申请证书，一般免费证书比较少，因而需要一定费用。
- http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。
- http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- http的连接很简单，是无状态的；https协议是有SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTP无状态
HTTP是无状态：是指http的每一次请求都是一次单独的请求，是指协议对于事务处理没有记忆能力。浏览器第一次向服务器发送请求，服务器给出响应；同一个浏览器第二次向服务器发送请求，浏览器同样给出响应，但是因为HTTP协议无状态，没有记忆能力，所以服务器不知道这个浏览器上次来过，第二次给出响应和第一次给出响应相同，每次都需要重传信息，导致传送的数据量增大。
http无状态的优点
不需要额外的资源来记录状态信息，不仅实现上会简单一些，而且还能减轻服务器的负担。
对于有状态协议来说，如果将会话状态与连接绑定在一起，那么如果连接意外断开，整个会话就会丢失，重新连接之后一般需要从头开始
http无状态的缺点
因为每个请求都是独立的，所以单个请求需要的所有信息都必须要包含在请求中一次发送到服务端，这导致单个消息的结构需要比较复杂，必须能够支持大量元数据
HTTPS的主干层次介绍
这部分内容作为前提点缀，如果你是初次了解HTTPS，看不懂这里不要紧，只要把文章后面看完，再回过头来看这里的内容，就能恍然大悟了。
第一层：HTTPS本质上是为了实现加密通信，理论上，加密通信就是双方都持有一个对称加密的秘钥，然后就可以安全通信了
但是，无论这个最初的秘钥是由客户端传给服务端，还是服务端传给客户端，都是明文传输，中间人都可以知道。那就让这个过程变成密文就好了呗，而且还得是中间人解不开的密文。
第二层：使用非对称加密 加密客户端与服务端协商生成对称秘钥之前各种盐值、种子。
但是，在使用非对称加密秘钥之前，比如由服务端生成非对称秘钥，它需要将生成的公钥给到客户端，这个时候公钥就会在网络中明文传输，任何人都可以更改，会有中间人攻击的问题。因此，只能引入公信机构CA，使我们传输自己的公钥时可以保证不会被篡改！
第三层：服务端把自己的公钥给 CA，让 CA 用 CA 的私钥加密，然后返回加密结果（可以用CA的公钥解密，如果要篡改结果，必须再次用 CA 的私钥加密，由于中间人没法获取私钥，所以无法篡改）。
对称加密与非对称加密
对称加密:
就是通过同一个“密钥”，将明文加密成密文，并且也能把密文解密成明文。引用对称加密之后，即使数据被截获，由于黑客不知道密钥是什么，因此就无法解密，不知道请求的内容。
非对称加密：
非对称加密要用到两个密钥，一个叫做“公钥”（pub)，一个叫做“私钥”(pri)。
公钥和私钥是配对的，没有规定哪个用来加密，哪个用来解密。最大的缺点就是运算速度非常慢，比对称加密慢得多。
通过公钥对明文加密，变成密文
通过私钥对密文解密，变成明文
也可以反过来：通过私钥对明文加密，变成密文
通过公钥对密文解密，变成明文
通常是公钥加密，私钥解密。
客户端在使用HTTPS方式与Web服务器通信时的步骤
（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
（3）客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。
（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
（5）Web服务器利用自己的私钥解密出会话密钥。
（6）Web服务器利用会话密钥加密与客户端之间的通信。
尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，他大幅增加了中间人攻击的成本
SSL与TLS
SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。
TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。TLS是HTTP与TCP协议之间的一层，通常TLS发生在TCP三次握手之后，此时进行TLS四次握手，然后再进行HTTP通信
HTTPS的缺点
虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
实践中建议保留http。所以我们在切换的时候可以做http和https的兼容，具体实现方式是，去掉页面链接中的http头部，这样可以自动匹配http头和https头。例如：将http://www.baidu.com改为//www.baidu.com。然后当用户从http的入口进入访问页面时，页面就是http，如果用户是从https的入口进入访问页面，页面即使https的
如何优化HTTPS的速度
HTTPS连接大致可以划分为两个部分：第一个是建立连接时的非对称加密握手，第二个是握手后的对称加密报文传输。
由于目前流行的 AES、ChaCha20 性能都很好，还有硬件优化，报文传输的性能损耗可以说是非常地小，小到几乎可以忽略不计了。所以，通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。
在 TCP 建连之后，正式数据传输之前，HTTPS 比 HTTP 增加了一个 TLS 握手的步骤，这个步骤最长可以花费两个消息往返，也就是 2-RTT（TLS1.3只需1-RTT）。而且在握手消息的网络耗时之外，还会有其他的一些“隐形”消耗，比如：
产生用于密钥交换的临时公私钥对（ECDHE）；
验证证书时访问 CA 获取 CRL 或者 OCSP；
非对称加密解密处理“Pre-Master”。
1、HSTS重定向技术
HSTS（HTTP Strict Transport Security，HTTP 严格传输安全）技术，启用HSTS后，将保证浏览器始终连接到网站的 HTTPS 加密版本。这相当于告诉浏览器：我这个网站必须严格使用 HTTPS 协议，在半年之内（182.5 天）都不允许用 HTTP，你以后就自己做转换吧，不要再来麻烦我了。
1. 用户在浏览器里输入 HTTP 协议进行访问时，浏览器会自动将 HTTP 转换为 HTTPS 进行访问，确保用户访问安全；
2. 省去301跳转的出现，缩短访问时间；
3. 能阻止基于 SSL Strip 的中间人攻击，万一证书有错误，则显示错误，用户不能回避警告，从而能够更加有效安全的保障用户的访问。
2、TLS握手优化
在传输应用数据之前，客户端必须与服务端协商密钥、加密算法等信息，服务端还要把自己的证书发给客户端表明其身份，这些环节构成 TLS 握手过程。
使用 ECDHE 椭圆曲线密码套件，可以节约带宽和计算量，还能实现“False Start”，采用 False Start （抢先开始）技术，浏览器在与服务器完成 TLS 握手前，就开始发送请求数据，服务器在收到这些数据后，完成 TLS 握手的同时，开始发送响应数据。
开启 False Start 功能后，数据传输时间将进一步缩短。
3、Session Identifier（会话标识符）复用
如果用户的一个业务请求包含了多条的加密流，客户端与服务器将会反复握手，必定会导致更多的时间损耗。或者某些特殊情况导致了对话突然中断，双方就需要重新握手，增加了用户访问时间。
（1）服务器为每一次的会话都生成并记录一个 ID 号，然后发送给客户端；
（2）如果客户端发起重新连接，则只要向服务器发送该 ID 号；
（3）服务器收到客户端发来的 ID 号，然后查找自己的会话记录，匹配 ID 之后，双方就可以重新使用之前的对称加密秘钥进行数据加密传输，而不必重新生成，减少交互时间（只用一个消息往返就可以建立安全连接）。
但它也有缺点，服务器必须保存每一个客户端的会话数据，对于拥有百万、千万级别用户的网站来说存储量就成了大问题，加重了服务器的负担。于是又出现了第二种“Session Ticket”的方案。
它有点类似 HTTP 的 Cookie，存储的责任由服务器转移到了客户端，服务器加密会话信息，用“New Session Ticket”消息发给客户端，让客户端保存。重连的时候，客户端使用扩展“session_ticket”发送“Ticket”而不是“Session ID”，服务器解密后验证有效期，就可以恢复会话，开始加密通信。不过“Session Ticket”方案需要使用一个固定的密钥文件（ticket_key）来加密 Ticket，为了防止密钥被破解，保证“前向安全”，密钥文件需要定期轮换，比如设置为一小时或者一天。
4、开启OSCP Stapling（OSCP装订），提高TLS握手效率
客户端的证书验证其实是个很复杂的操作，除了要公钥解密验证多个证书签名外，因为证书还有可能会被撤销失效，客户端有时还会再去访问 CA，下载 CRL （Certificate revocation list，证书吊销列表，用于确认证书是否有效，体积较大，现基本不用）或者 OCSP 数据，这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信，增加好几个 RTT。
采用OCSP Stapling ，提升 HTTPS 性能。服务端主动获取 OCSP 查询结果并随着证书一起发送给客户端，从而客户端可直接通过 Web Server 验证证书，提高 TLS 握手效率。
服务器模拟浏览器向 CA 发起请求，并将带有 CA 机构签名的 OCSP 响应保存到本地，然后在与客户端握手阶段，将 OCSP 响应下发给浏览器，省去浏览器的在线验证过程。由于浏览器不需要直接向 CA 站点查询证书状态，这个功能对访问速度的提升非常明显。
5、完全前向加密PFS，保护用户数据，预防私钥泄漏
非对称加密算法 RSA，包含了公钥、私钥，其中私钥是保密不对外公开的，由于此算法既可以用于加密也可以用于签名，所以用途甚广，但是还是会遇到一些问题：
（1） 假如我是一名黑客，虽然现在我不知道私钥，但是我可以先把客户端与服务器之前的传输数据（已加密）全部保存下来
（2）如果某一天，服务器维护人员不小心把私钥泄露了，或者服务器被我攻破获取到了私钥
（3）那我就可以利用这个私钥，破解掉之前已被我保存的数据，从中获取有用的信息，即所谓的“今日截获，明日破解”。
所以为了防止上述现象发生，我们必须保护好自己的私钥。
如果私钥确实被泄漏了，那我们改如何补救呢？那就需要PFS（perfect forward secrecy）完全前向保密功能，此功能用于客户端与服务器交换对称密钥，起到前向保密的作用，也即就算私钥被泄漏，黑客也无法破解先前已加密的数据。维基解释是：长期使用的主密钥泄漏不会导致过去的会话密钥泄漏
实现此功能需要服务器支持以下算法和签名组合：
（1）ECDHE 密钥交换、RSA 签名；
（2）ECDHE 密钥交换、ECDSA 签名；
ECDHE 算法在每次握手时都会生成一对临时的公钥和私钥，每次通信的密钥对都是不同的，也就是“一次一密”，即使黑客花大力气破解了这一次的会话密钥，也只是这次通信被攻击，之前的历史消息不会受到影响，仍然是安全的。
使用ECDHE算法的TLS交换过程具有如下优点：运算速度快，安全性高，还支持“False Start”，能够把握手的消息往返由 2-RTT 减少到 1-RTT
所以现在主流的服务器和浏览器在握手阶段都已经不再使用 RSA，改用 ECDHE，而 TLS1.3 在协议里明确废除 RSA 和 DH 则在标准层面保证了“前向安全”。
更多详细信息：https://blog.csdn.net/qq_35642036/article/details/82788421
