HTTPS、HTTP2详解

​我们几乎每天都在网上冲浪，接收或发出大量的数据，而这些是怎样被表示并发送接收的的呢？今天就来聊聊处在TCP/IP模型应用层的HTTP协议。

​中文名：超文本传输协议，是万维网的基础。服务器与用户通过这个协议完成了数据点到点的传输，Restful API也是基于它而定的一种架构标准。接下来直接进入正题，从http1.1版本开讲。

​1.1的版本虽然已诞生许久，但依然经久不衰。其特点简而言之就是基于TCP连接，以请求-应答的方式进行交互，明文的方式进行传输，处理是无状态的。它的缺点也非常明显，其一，以明文的方式进行传输，数据安全性较低，其二，虽然已经采用keep-alive的连接方式，Pipeline的复用机制，但由于需要按次序处理，所以依然容易造成队头阻塞的问题。其三，报头偏重，浪费资源。至于无状态，这就要分场景而言，例如在直播领域无状态反而由于开销较小，成了个优势。

HTTPS

​对于安全性这方面，前辈们选择添砖加瓦，创造了TLS/SSL协议，采用混合加密的方式保障信息的安全。这里的混合加密是指对称加密与非对称加密的结合。

​对称加密是我们较为熟知的方式，发送方用一个密码进行加密，接收方再用这个密码解密，较好理解。非对称加密则是采用私钥与公钥这种密钥对的方式进行加密解密。公钥可对外发布，私钥自己保留，公钥可加密解密私钥发来的信息，私钥对公钥亦然，其原理可以去看下椭圆曲线加密算法。这种非对称加密最常见的应用实例就是HTTPS的身份验证。

​权威的第三方机构生成密钥对，公钥加上一些机构和时间等信息形成证书，证书将直接内置于客户端，服务端则内置私钥与证书。在TCP连接建立完成后，客户端发送hello消息，说明自己支持的加密套件，服务端收到后回复hello信息，其中包含证书，选择的加密套件，客户端经过与内置的证书进行比对，确认无误后用此证书中的公钥加密对称密钥，回复给服务端，此后的信息都将进行对称加密。但是这里有个问题，如果server的hello信息被黑客截取，篡改了其中的证书信息，我们怎么来确定它的完整性呢？前辈们提出了数字签名的方案。服务端将证书的信息进行摘要计算（如MD5），再将摘要信息用私钥进行加密生成数字签名，和证书一同发送给客户端，客户端收到后，用公钥解密得到摘要信息，以相同的方式计算，如果得到相同结果则可以确认信息未被修改。

HTTP2

​安全的问题已经解决，接下来解决性能的问题，HTTP2登场。

1. ​二进制分帧。将报文称之为消息，分成头报头帧和DATA帧，这些帧具有相同的ID。在传输时，同一ID的帧必须按顺序发送，不同ID的帧可以乱序发送。

2. 更好的多路复用。在HTTP1.1中，对单个域名的有6—8的TCP连接数量的限制。在HTTP2中，一个域名只需要一个TCP连接，这个连接可以承载不限数量的双向传输序列（这种双向传输序列被称为流）。

3. 头部压缩。服务器与客户端维持两个字典和一个表，静态字典（包含常见的头部方法与值，共61个表项），动态字典（可以动态添加）与静态哈夫曼表（对不包含在另两个字典的头部进行压缩）。当发送的报头在静态字典中时，一个字符即可表示，不在时则基于哈夫曼表进行编码发送，并且将这个包头加入到动态字典中，下次传输也只需要一个字符就可以代替。当然，这里讲的比较笼统，能否加入到动态字典也是有要求的，具体细节读者可查看RFC7541。

4. 加入PUSH方法。原来客户端解析网页时需要读取HTML取资源，而现在服务器可通过PUSH直接将HTML连同所需资源一同发到客户端，降低了延迟。

5. 加入就请求优先级。HTTP2中每个请求消息都带有一个31bits的优先级，0为最高级，客户端和服务器可根据不同的优先级采取不同的处理策略。