从 HTTP/1 到 HTTP/2,以及即将到来的 HTTP/3

发布于 2019-09-26  约 10 分钟

如今的生活中已经离不开互联网,智能家居、在线支付、网上购物都需要互联网的支持。互联网切切实实地给生活带来了诸多便利。有了互联网,我们可以呆在空调房里,一边刷着微博,一边等透心凉的西瓜送到手上,安安静静地做一个吃瓜群众。

互联网的建立打破了地域限制,用户直接上网就可以浏览到各种信息。用户上网的过程,即浏览器向服务端发送请求,然后将服务端主机上的内容显示到本地。而浏览器与服务器之间,走的就是 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(互联网工程任务组)标准认为仍未达到目标。网站管理者应该根据自身实际情况进行权衡,来确定哪个协议适合自己的网站,这样才是正确的做法。

未来如何,我们拭目以待!

推荐阅读:

一文读懂 HTTP/2 特性

夜空中最靓的二狗子是如何让 HTTPS 快上加快的?

阅读 823发布于 2019-09-26

推荐阅读
云叔
用户专栏

-- 隐于云端,静闻天籁 --

56 人关注
130 篇文章
专栏主页
目录