如今的生活中已经离不开互联网，智能家居、在线支付、网上购物都需要互联网的支持。互联网切切实实地给生活带来了诸多便利。有了互联网，我们可以呆在空调房里，一边刷着微博，一边等透心凉的西瓜送到手上，安安静静地做一个吃瓜群众。
互联网的建立打破了地域限制，用户直接上网就可以浏览到各种信息。用户上网的过程，即浏览器向服务端发送请求，然后将服务端主机上的内容显示到本地。而浏览器与服务器之间，走的就是 HTTP 协议。HTTP（Hypertext Transfer Protocol），超文本传输协议，它是应用层协议。由于其简捷、快速的方式，适用于分布式和合作式超媒体信息系统。自 1990 年起，HTTP 就已经被应用于万维网（WWW）全球信息服务系统。
HTTP 协议发展至今已经更新迭代了多个版本，下面我们来看看 HTTP 的发展史。
最原始的 HTTP/0.9
已过时的 HTTP/0.9 是 HTTP 协议的第一个版本，诞生于 1989 年。它的组成极其简单，只允许客户端发送 GET 这一种请求，而且不支持请求头。由于没有协议头，所以 HTTP/0.9 只能支持一种内容——纯文本。服务器只能回应 HTML 格式的字符串，不能回应别的格式。服务器发送完毕后，就会关闭 TCP 连接。
HTTP/0.9 具有典型的无状态性，每个访问都独立处理，处理完成后就会断开连接。如果请求的页面不存在，也不会返回任何错误码。
进化后的 HTTP/1
HTTP/1 是 HTTP 1.0 和 HTTP 1.1 的统称，分别指 HTTP 协议的版本是 1.0 和 1.1。
HTTP 1.0 是 HTTP 协议的第二个版本，至今仍被广泛采用。它在 HTTP/0.9 的基础上做了大量的扩充和改进，包括：
可以发送更多格式的内容，如图像、视频、二进制文件，不仅仅局限于文本了
在 GET 的基础上，增加了 HEAD 和 POST 请求方法
改变了 HTTP 请求和回应的格式。除了数据部分，每次通信都必须包括头信息（HTTP Header），用来描述一些元数据，即增加了请求头信息
新增了响应状态码（status code）、多字符集支持、权限（authorization）、缓存（cache）、内容编码（content encoding）等功能
虽然还是无状态协议，不过在请求（request）中增加 了“Connection: keep-alive”Header 头后就能支持长连接
更新后的 HTTP 1.0 相比之前变化尤其大，支持的功能也很丰富，但仍有诸多缺点。
HTTP 1.0 默认不支持长连接，这样就增加了 TCP 连接次数，造成开销浪费。HTTP 1.0 所保持的 TCP 每次只能处理一个请求，虽然能一次性接收多个请求，但是还是得按顺序一次处理一个请求，这样在后续请求等待前序请求完成时，很容易造成阻塞。同时，它还不支持断点续传。
这时，HTTP 1.1 登场了。它也是目前主流的 HTTP 协议版本，相比于 HTTP 1.0，它有了明显的优势：
加强和优化长连接
HTTP 1.1 支持长连接和请求的流水线处理，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟。在 HTTP 1.1 中默认开启 “Connection: keep-alive”，一定程度上弥补了 HTTP 1.0 每次请求都要创建连接的缺点。
缓存支持
所有 HTTP 1.1 请求里的响应头都包含了“Date：”标头，因此每个 Response 都为缓存添加了时间戳。
请求头引入了 range 头域
它允许只请求资源的某个部分，即返回状态码是 206（Partial Content），这样就方便了开发者自由的选择，以便于充分的利用带宽和连接。
采用分块传输编码
对于一些很耗时的动态操作，服务器需要等到所有操作完成后才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用流模式来取代缓存模式。
新增了多个请求方法和错误状态码
包括 PUT、PATCH、HEAD、OPTIONS、DELETE。另外，客户端请求的头信息中新增了 Host 字段，用来指定服务器的域名。同时新增了 24 个错误状态码。
HTTP 1.1 虽然增加了很多功能，但是它自身仍然有很多不足。由于各个请求到达服务器的速度不同，如果先发的请求先到达可能会发生阻塞，剩下所有的请求都会被阻塞在那次请求应答之后，这样就降低了带宽。
增强后的 HTTP/2
随着 Web 技术的飞速发展，HTTP 1.1 已经无法满足用户对性能的要求，此后 Google 推出协议 SPDY，意在解决 HTTP 1.1 中广为人知的性能问题。HTTP/2 因此应运而生，它是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。
那 HTTP/2 到底有哪些具体变化呢？
- 多路复用：HTTP/2 使用多路复用技术，使用一个 TCP 连接并发处理多个请求，不但节约了开销而且可处理请求的数量也比 HTTP 1.1 大了很多
- 数据传输：HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效
- 头部压缩：HTTP 1.1 不支持 Header 数据压缩，HTTP/2 使用 HPACK 算法对 Header 的数据进行压缩，使得数据传输更快
- 服务器推送（Server Push）：当对支持 HTTP/2 的服务器请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到服务器，这种方式适用于加载静态资源，节约带宽
> 小广告时间：
又拍云 CDN 当前已全平台支持 HTTP/2，并已默认开启。又因 HTTP/2 是在 HTTPS 协议的基础上实现的，所以只要使用又拍云 HTTPS 加速服务的域名，都可免费享受 HTTP/2 服务，无需做任何特殊配置。而开启 HTTPS，只需完成证书申请与管理，无须繁杂流程，轻松实现网站与 Web 应用的 HTTPS 加密部署。
即将到来的 HTTP/3
就像 HTTP/1 到 HTTP/2 一样，HTTP/3 到来同样有着它的重要任务。
由于 HTTP/2 是基于 HTTP/1 的升级，因此第一个版本中发现的许多核心问题都会向前延伸。其中就包括 TCP 协议在整个互联网上实施的方式所带来的问题：HTTP/2 使用了多路复用，一般来说同一个地址只需要使用一个 TCP 连接；单连接最终会成为网络质量较差的环境中的数据瓶颈 - 网络质量下降更容易出现丢包，导致在重传期间不能传输其他数据，势必会降低整个请求的处理速度。
修改 TCP 协议显然是不可能的，因此 HTTP/3 引用了基于 UDP 的 QUIC 协议，并有望成为 HTTP 协议的第三个正式版本。HTTP/3 曾用名 HTTP-over-QUIC，QUIC 代表“快速 UDP 互联网连接”，本身就是 Google 试图将 TCP 协议重写进而改进出来的一种技术，它结合了 HTTP/2，TCP，UDP 和 TLS（用于加密）等等。
针对 HTTP/2 的软肋，HTTP/3 和 QUIC 弥补了前者的不足。QUIC 使用 UDP 协议，它在两个端点间创建连线，且支持多路复用连线。QUIC 能够提供等同于 SSL/TLS 层级的网络安全保护，减少数据传输及创建连线时的延迟时间，双向控制带宽，以避免网络拥塞。Google 希望使用这个协议来取代 TCP 协议，使网页传输速度更快。
展望未来
有些人认为，目前 HTTP/2 的标准尚未完全采用，推出 HTTP/3 可能还为时尚早。这确实是一个有效的观点，但是正如我们所看到的，这个协议已经得到了世界大规模的测试和实现。谷歌早在 2015 年就已经开始测试，并且在 2017 年 Facebook 也进行了测试。
从概念上讲，HTTP/3 是一个出色的协议。但是，在当前的应用程序中实现，仍然需要进行大量的迭代更新。虽然 QUIC 和 UDP 的结合为 Google 提供了出色的使用示例，但 IETF（互联网工程任务组）标准认为仍未达到目标。网站管理者应该根据自身实际情况进行权衡，来确定哪个协议适合自己的网站，这样才是正确的做法。
未来如何，我们拭目以待！
