夸夸其谈，简单说说HTTP的优化历程
HTTP（超文本传输）协议，它是Web上任何数据交换的基础，同时也是一个客户端-服务器协议；这些年间，HTTP经历很多变化，也有助于塑造其灵活性,下面我们来简单谈谈HTTP在各个版本做了哪些改变
通过本文，你将了解学习到如下内容
HTTP这些年来，在迭代过程做了哪些优化，以及存在哪些不足?HTTP0.9、Http1.0和Http1.1、SPDY及2.0、QUIC（HTTP 3.0）各个版本的变化
HTTP/0.9—单行协议
在早期最初的HTTP版本中,它非常简单，也被称为单行协议。顾名思义，请求由一行组成，并以唯一可能的方法开始，GET后跟上资源的路径，最终的响应也只包含文件本身,没有状态码和错误码，并且由于没有HTTP标头,它不能传输除HTML以外的文件
<html>
Hello World
</html>
复制代码
HTTP/1.0—构建可扩展化
对于HTTP1.0,它最早在网页中使用是1996年，而该版本的出现意味着在浏览器和服务器中变得更加通用起来，引入了HTTP标头的概念，让协议变得非常灵活和可扩展。
感兴趣的小伙伴可以查看官方1996 年 11 月发布了一份描述常见做法的信息文档
它被称为并定义了 HTTP/1.0
HTTP1.0是一种无状态、无连接的应用层协议。
它规定每次让客户端和服务器都保持短连接，这也意味这它的连接是不复用的，每次在发起网络请求的时候都需要重写建立TCP连接；
同时如果有多个网络请求的时候，它规定必须等待前一个请求响应之后，才会发送下一个网络请求，这就是所谓的队头阻塞（head of line blocking）
HTTP/1.1—标准化协议
由于HTTP1.0的网络使用效率非常低效，每次请求都需要重新建立TCP连接，为了克服了诸多HTTP1.0性能上的问题，HTTP1.1出现了，作为HTTP 的第一个标准化版本HTTP/1.1 于 1997 年初发布，仅比 HTTP/1.0 晚了几个月，并且在1999年广泛运用于现在各大浏览器网络请求中
感兴趣的小伙伴可以阅读1997 年 1 月发布的HTTP1.1的信息文档
它可以重复使用连接，节省了响应的时间，引入了持久连接，不再需要多次打开才能显示嵌入在单个原始文档中的资源，默认开启
Connection: keep-alive引入了额外更多缓存策略控制，例如
cache-control等, 不单单只有1.0中提供的headers的expires作为缓存判断标准已经具备支持断点续传的能力，由于
HTTP/1.0存在浪费带宽的现象，客户端只需要一部分数据，而服务端却将全部数据发送过来了；对此Http1.1做了相应的带宽优化，可以进行分块响应，在header引入了range域,允许只请求一部分，让开发者可充分利用带宽，避免浪费引入了内容协商，包括语言、编码和类型。客户端和服务器现在可以就交换哪些内容达成一致，并且在错误通知管理上做了优化，增加了24个错误状态码，比如410表示服务端上数据被永久删除等等
对于
Host头做了处理，一台服务器上可以有多个虚拟主机，共享同一个IP地址，这也意味着HTTP1.1有从同一IP地址托管不同域的能力
存在的缺陷
虽然
HTTP1.1让TCP连接可以复用，但依旧没有解决队头阻塞的问题，也就是后面的请求依然需要等待前一个请求完成后才能进行,不允许存在两个并行的响应；由于所有请求都集中在一条连接中，在网络拥塞的情况下就很容易造成队头阻塞相对低效的
TCP利用,HTTP1.1无法充分利用TCP提供的所有性能，如果有多个请求的时候，HTTP1.0会开启多个TCP连接来同时处理多个请求,这样以来，当网络资源增多的时候，这个加载时间也会随之增加。由于队首阻塞的问题，即便网络带宽再打也无法被充分利用，对于网络延迟也是非常敏感的，过高的延迟会导致页面访问速度直线下滑
Google SPDY
SPDY作为Google开发的基于TCP的应用层协议,目的就是为了提供网页访问速度和提高安全性；它对于之前的HTTP1.1在性能上做了优化，它并不是一种HTTP协议的替代方案，而是对HTTP协议的增强，SPDY主要有如下几个方面的优势：
SPDY是允许在单个TCP连接上多次请求，不需要单独开放连接，有效避免了开启多个TCP连接造成的网络延迟，简单来说，就是多路复用TCP通道，降低HTTP的高延时。对于多路复用，
SPDY允许请求设置优先级,不必像之前HTTP一样遵从先入先出的按顺序处理请求。头部压缩,舍弃掉了不必要的头部信息，可以节省一些等待时间。
基于SSL的安全传输，它是被
Google强制使用的，经过SSL加密后，让请求传输变得安全。
虽然SPDY相对之前HTTP版本来说已经很优秀了，但它依旧是使用文本格式解析的协议
HTTP/2.0—更高性能的协议
对于2010年Google推出的SPDY实验性协议，它响应能力的提高并解决了重复数据传输的问题，作为了HTTP2.0协议的基础。对于HTTP2.0的新特性，如下文所述：
HTTP2.0相比之前版本的HTTP和SPDY最大的不同在于它的协议解析采用二进制格式，目的是为了避免文本解析的天然缺陷，文本格式表现形式有很多不同，要考虑的场景很多，而由于二进制格式只有0和1，所以会更加方便；HTTP2.0为此专门增加了二进制分帧层，将传输信息分割成帧，并进行二进制编码帧的使用会更加便捷，更容易获取到协议本身的内容
数据流以消息的形式发送，每个消息是由一个或多个帧组成
由于是基于
SPDY的改进的协议，它同样是多路复用TCP的，即所有请求通信都在一个TCP连接上完成；同时，服务端与客户端是双向实时通信的，即连接共享；减少了网络返回传输的数据量，并且提高了相应网络的访问速度，相比
HTTP1.x请求资源的时间消耗更少HTTP2.0相比SPDY同样由加密组的限制，但不同的是，它允许明文传输，而SPDY是强制进行SSL/TLS加密传输压缩请求头，消除了传输数据的重复和开销
服务器推送，它允许服务器通过称为服务器推送的机制在客户端缓存中填充数据
存在的缺陷
虽然
HTTP2.0通过多路复用解决了HTTP层,但本身是基于TCP来实现的，所以在TCP层依旧存在队头阻塞的问题，简单来说，TCP在收到数据包后，里面的数据有可能是乱序的，TCP需要排序整理之后才给上层使用，如果某个包丢失了，就必须要等待重传，因为这个丢失的包从而导致了整个连接被阻塞了。由于是基于
TCP连接，总所周知，它是可靠的，面向连接的传输协议，但是它加载速度相对缓慢，而网络环境改变速度很快，归根结底，其本质就是TCP的问题。
QUIC(HTTP/3.0)
Google 2013年实现，QUIC的出现旨在为 HTTP 连接提供更低的延迟，和HTTP2.0一样，它也是一个多路复用协议，到了2018年 这个基于QUIC协议的HTTP 才正式被确认为HTTP3.0；
QUIC 可以简单理解为 HTTP 2.0 + TLS 1.3 + UDP
解决了在连接复用中
HTTP 2.0 + TCP存在的队首阻塞问题，前面说过HTTP2.0是运行在单个TCP连接上的，因此TCP层处理的丢包检测和重传可以阻止所有流,这样的话是有可能导致队首阻塞的，而QUIC在UDP上运行多个流，并为每个流独立实现丢包检测和重传，这样如果发生错误，只会阻塞该数据包中包含数据的流。由于是基于
UDP，所以可以灵活控制拥塞协议，并且它可以支持快速握手，减少了TCP三次握手及TLS握手的时间，并优化了失败重传策略和流量控制算法。连接迁移：采用了类似
Connection id的特性，不需要在切换网络的时候重新连接，这样用户在使用APP的体验会更加流畅