早期以信息发布为主的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握手

握手阶段分成五步：

1. 客户端给出协议版本号、生成的随机数（Client random），以及客户端支持的加密方法。
2. 服务端确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数。
3. 客户端确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给服务器。
4. 服务器使用自己的私钥，获取客户端发来的随机数（Premaster secret）。
5. 双方根据约定的加密方法，使用前面的三个随机数，生成会话密钥（session key），用来加密接下来的对话过程。

握手阶段有三点需要注意：

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

DH握手

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