HTTP初始（二）——HTTP家族(HTTPS)

Http家族

正文部分的MIME类型

在讲解各个版本的HTTP的异同前我们先来介绍以下MIME，全称为“Multipurpose Internet Mail Extensions”，中文名为“多用途网络邮件拓展协议”。从MIME的中文名称我们就不难得出，它最初的设计目的就是为了在发送电子邮件时附加多媒体数据，让邮件客户程序能根据其类型进行处理。它使得HTTP传输的不仅可以是普通的HTML文本，还可有包含很多媒体类型，如image、video、application等。

我们知道HTTP/9.0后的请求和响应的正文部分是可以任意的数据格式，所以只有统一格式才能确保接收方能看得懂发送方的正文数据。而HTTP采用MIME协议来规范正文的数据格式，具体体现是在HTTP请求头和响应头中有一个Content-type项，用来指定请求正文和响应正文中MIME类型。每个MIME类型由两部分组成，前面是数据的大类别，后面是具体的子类别(文件拓展名)。如image/gif。

常见的文件拓展名于MIME类型的对应关系

HTTP/0.9

1991年发布的HTTP/0.9是第一个HTTP版本，同时也是最简单的HTTP。HTTP请求中不包括HTTP的版本号和头部信息，仅有一个GET方法，HTTP响应结果也只包含HTTP文档。该版本已过时。

HTTP/1.0

HTPP/1.0于1996年发布，它在HTTP/0.9的基础上做出了很大改进。

相比于HTTP/0.9的改动：

• 格式上：HTTP/1.0中请求和响应都增加了版本号和头部信息。
• 内容上：采用MIME协议，可以传输照片、视频等。响应结果中包含状态码（status code）、限权（authorization）、缓存（cache）和内容编码（content encoding）等信息。
• 方法上：不仅支持GET，还支持POST等。

HTTP/1.0的特点和缺点：

1. 无连接：指服务器处理完客户的请求，并收到客户的应答后，就断开连接。也就是说每次HTTP请求都要建立一个新的TCP，而频繁的建立客户端与服务器端的TCP连接很耗资源，会降低服务器端的响应速度。
2. 队列阻塞：在HTTP/1.0中，同一个TCP连接只能处理一个HTTP请求，只有前一个请求的响应收到了才能发送下一个HTTP请求，一旦收到响应非常慢，那么后面的请求只能等待，这就导致了队列阻塞。所以，HTTP1.0的队列阻塞发生在客户端。

HTTP/1.1

看名字就可以知道，HTTP1.1是为了克服HTTP1.0的缺点出现的升级版。它不仅继承了HTTP1.0简单的特点，还克服了诸多HTTP1.0性能上的问题。

HTTP/1.1的特点和缺点：

1. 持久TCP连接（长连接）：HTPP/1.1建立TCP连接后，允许处理多个有序的HTTP请求。在HTTP/1.1请求头中，以下选项用来设定持久TCP连接的参数：Connection: Keep-Alive Keep-Alive: max=5, timeout=120 Keep-Alive/Close表示保持连接或者断开连接，max表示允许处理的最大http请求数目，timeout表示TCP连接的最长闲置时间
2. 管道机制：HTTP/1.1引入了管道机制，即不需要等待上一个请求的响应结果到来就可以发送下一个请求。基于管道机制，在一个TCP连接中，客户端可以连续发送几个请求，服务端按照接受请求的先后顺序，依次把响应返回给客户端。这样就解决了HTTP/1.0中的请求任务队列阻塞问题。
3. 队列阻塞：尽管HTTP1.1支持持久TCP连接，并引入了管道机制，但是HTTP/1.1的处理机制的核心还是按照请求的先后顺序来处理HTTP请求的，并依次返回相应内容。所以只有前一个HTTP相应生成完毕，才能生成下一个响应。如果生成前一个响应非常慢，那么后面的响应任务只能等待，这样会导致响应任务队列阻塞。所以，HTTP/1.1的队列阻塞发生在服务器端。

HTTP/2.0

HTTP/2.0的显著特点是低延时传输。

相比于HTTP/1.1其特点和改进主要有：

1. 二进制协议：在HTTP/1.1中请求和响应的头部信息是文本，正文信息既可以是文本，也可以是二进制数据。HTTP/2.0则是一个彻底的二进制协议，头部和正文信息都是二进制数据；HTTP/2.0将数据分成一个一个的帧，头部帧存储元数据（即头部信息），数据帧存放正文数据。
2. 多路复用 在HTTP/2.0中，同一个TCP连接，可以并发传输多个响应的结果二进制数据流。这样就解决了HTTP/1.1中的响应任务队列堵塞问题。
3. 头部压缩 我们这里先过一遍压缩的概念：1.通信双方各拥有一本字典，记录着某些字符所对应得文本内容，例如d代表着东边的，x代表着大西瓜；2.消息发送方根据字典生成消息“dx"; 3.消息接受方，接收到消息后根据字典还原内容：“东边的大西瓜”。我们在第一篇提到过，HTTP协议具有无状态特点，所以每次请求都要带上所有信息。当同一个客户端重复访问服务器时，会有很多重复的数据，比如User Agent和Cookie，这样会增加带宽的用以及延迟。为了解决这个问题，HTTP/2.0中专门为头部压缩设计了一套压缩算法——HPACK。 官方文档里的对Hpack的主要思想说明，RFC 7541协议：
   • 将header里的字段列表视为可包括重复对的name-value键值对的有序集合，分别使用8位字节表示name和value
   • 当字段被编码/解码时，对应的字典会不断扩充
   • 在编码形式中，header字段可以直接表示，也可以使用header field tables 中对应的引用。因此，可以使用引用和文字值的混合来header字段列表。
   • 文字值要么直接编码，要么使用静态huffman代码
   • 编码器负责决定在标题字段表中插入哪些标题字段作为新条目。解码器执行对编码器规定的报头字段表的修改，重建处理中的报头字段列表

总结：头部信息以霍夫曼编码对文本值进行编码，所有的头部信息都被放在一张头部信息表里面，由客户端和服务器端共同维护，随后的请求中省略所有重复的信息，仅使用一个索引号，服务端根据索引号从头部信息表中检索响应的信息。

1. 推送 这是一个很厉害的功能，它使得在HTTP/2.0中，服务端可以主动地向客户端推送消息，甚至不需要客户端去发送请求。

HTTPS

我们在HTTP初识（一）中提到过“https就是在http的基础上加入了SSL”，现在我们就来聊一聊这具体是怎么一回事。HTTPS其实相比于HTTP而言没什么新花样，只是将默认端口更改为443，去掉明文传输。

图来！

从图上我们可以很直观的得出，其实HTTPS就是在HTTP下面加入了SSL，让HTTP运行在SSL上。而SSL依靠证书来验证服务器的身份，并对浏览器和服务器之间的通信进行数据加密，以保证数据传输的安全性，其主要流程如下:

参考自《Offer来了》

1. 发起请求：客户端在通过TCP和服务器建立连接之后（默认使用44端口），发出一个请求证书的消息给服务器，在该请求消息里包含自己可实现的算法列表和其他需要的消息。
2. 证书返回：服务器端在收到消息后回应客户端并返回证书，在证书中包含服务器信息、域名、申请证书的公司、公钥、数据加密算法等。
3. 证书验证：客户端在收到证书后，判断证书签发机构是否正确，并使用该签发机构的公钥确认签名是否有效，客户端还会确保在证书中列出的域名为正在连接的域名、如果客户端确认证书有效，则生成对称密钥，并使用公钥将对称密钥加密。
4. 密钥交换：客户端将加密后的对称密钥发送给服务器，服务器在收到对称密钥后使用私钥解密。
5. 数据传输：经过上述步骤，客户端和服务器就完成了密钥对的交换，在之后的数据传输过程中，客户端和服务器端就可以基于对称加密（加密和解密使用相同的加密算法）将数据加密后在网络上传输，保证了网络数据传输的安全性。

END