今天给各位分享

早期以信息发布为主的Web 1.0时代，HTTP已可以满足绝大部分需要证书费用、服务器的计算资源都比较昂贵，作为HTTP安全扩展的HTTPS，通常只应用在登录、交易等少数环境中但随着越来越多的重要业务往线上转移，网站对用户隐私和安全性也越来越重视。

对于防止恶意监听、中间人攻击、恶意劫持篡改，HTTPS是目前较为可行的方案，全站HTTPS逐渐成为主流网站的选择HTTP简介HTTP（HyperText Transfer Protocol，超文本传输协议）,是一种无状态 (stateless) 协议，提供了一组规则和标准，从而让信息能够在互联网上进行传播。

在HTTP中，客户端通过Socket创建一个TCP/IP连接，并连接到服务器，完成信息交换后，就会关闭TCP连接（后来通过Connection: Keep-Alive实现长连接）HTTP消息组成：请求行或响应行

HTTP头部HTML实体，包括请求实体和响应实体HTTP请求结构，响应结构如图所示：

1. HTTP头部HTTP头部由一系列的键值对组成，允许客户端向服务器端发送一些附加信息或者客户端自身的信息，如：accept、accept-encoding、cookie等http头后面必须有一个空行。

2. 请求行请求行由方法、URL、HTTP版本组成。

3. 响应行响应行由HTTP版本、状态码、信息提示符组成。

HTTP2.0和HTTP1.X相比的新特性新的二进制格式，HTTP1.x的解析是基于文本基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。

基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮多路复用，即每一个请求都是是用作连接共享机制的一个请求对应一个id，这样一个连接上可以有多个请求，每个连接的请求可以随机的混杂在一起，接收方可以根据请求的id将请求再归属到各自不同的服务端请求里面。

header压缩，HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

服务端推送，同SPDY一样，HTTP2.0也具有server push功能HTTP安全问题通信使用明文(不加密),内容可能会被窃听不验证通信方的身份,因此有可能遭遇伪装无法证明报文的完整性,所以有可能已遭篡改。

HTTPS协议HTTPS 是最流行的 HTTP 安全形式使用 HTTPS 时，所有的 HTTP 请求和响应数据在发送到网络之前，都要进行加密 HTTPS 在 HTTP 下面提供了一个传输级的密码安全层——可以使用 SSL，也可以使用其后继者——传输层安全(TLS)。

相关术语密钥：改变密码行为的数字化参数对称密钥加密系统：编、解码使用相同密钥的算法不对称密钥加密系统：编、解码使用不同密钥的算法公开密钥加密系统：一种能够使数百万计算机便捷地发送机密报文的系统数字签名：用来验证报文未被伪造或篡改的校验和。

数字证书：由一个可信的组织验证和签发的识别信息密钥协商算法：解决动态密钥分配、存储、传输等问题TLS/SSL协议TLS/SSL协议包含以下一些关键步骤：传输的数据必须具有机密性和完整性，一般采用对称加密算法和HMAC算法，这两个算法需要一系列的密钥块（key_block），比如对称加密算法的密钥、HMAC算法的密钥，如果是AES-128-CBC-PKCS#7加密标准，还需要初始化向量。

所有的加密块都由主密钥（Master Secret）生成，主密钥就是第1章中讲解的会话密钥，使用密码衍生算法将主密钥转换为多个密码快主密钥来自预备主密钥（Premaster Secret），预备主密钥采用同样的密码衍生算法转换为主密钥，预备主密钥采用RSA或者DH（ECDH）算法协商而来。

不管采用哪种密钥协商算法，服务器必须有一对密钥（可以是RSA或者ECDSA密钥），公钥发给客户端，私钥自己保留不同的密钥协商算法，服务器密钥对的作用也是不同的通过这些关键步骤，好像TLS/SSL协议的任务已经结束，但这种方案会遇到中间人攻击，这是TLS/SSL协议无法解决的问题，必须结合PKI的技术进行解决，PKI的核心是证书，证书背后的密码学算法是数字签名技术。

对于客户端来说，需要校验证书，确保接收到的服务器公钥是经过认证的，不存在伪造，也就是客户端需要对服务器的身份进行验证TLS/SSL协议核心就三大步骤：认证、密钥协商、数据加密。RSA握手

握手阶段分成五步：客户端给出协议版本号、生成的随机数（Client random），以及客户端支持的加密方法服务端确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数客户端确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给服务器。

服务器使用自己的私钥，获取客户端发来的随机数（Premaster secret）双方根据约定的加密方法，使用前面的三个随机数，生成会话密钥（session key），用来加密接下来的对话过程握手阶段有三点需要注意：。

生成对话密钥一共需要三个随机数握手之后的对话使用对话密钥（session key）加密（对称加密），服务器的公钥和私钥只用于加密和解密对话密钥（session key）（非对称加密），无其他作用服务器公钥放在服务器的数字证书之中。

DH握手

RSA整个握手阶段都不加密，都是明文的因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解为了足够安全，我们可以考虑把握手阶段的算法从默认的RSA算法，改为 Diffie-Hellman算法（简称DH算法）。

采用DH算法后，Premaster secret不需要传递，双方只要交换各自的参数，就可以算出这个随机数参考《深入浅出HTTPS：从原理到实战》（虞卫东）blog.cloudflare.com/keyless-ssl…

segmentfault.com/a/119000001…作者：黑漏链接：https://juejin.cn/post/6943389596117893134