说明: 本文来自Medium,作者:Grigor Khachatryan

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。

这段时间在研究 HTTP/2 的相关知识,没想到 HTTP/3 也在酝酿中,于是乎找到一篇介绍 HTTP/3 的文章,学习并在此进行记录。

HTTP/3

HTTP-over-QUIC 这个实验性的协议会被命名为 HTTP/3,IETF 的一位成员披露了这条消息。

从 HTTP/1.1(发布于1999年)到 HTTP/2 已经过了许多年,而在 2019 年将大大推动 HTTP/3 的发展。

HTTP/3 由 Google 的 QUIC 协议发展而来。它开始于 Mark Nottingham 的建议

所以啥是 QUIC ?

QUIC(Quick UDP Internet Connections / 快速 UDP 网络连接)是一种新的传输模式,与 TCP 相比减少了延迟。大体来说,QUIC 类似于 UDP 上实现 TCP + TLS + HTTP/2。由于 TCP 在操作系统内核和中间件之上实现的,导致对于 TCP 进行重大更新几乎是不可能的。然而,QUIC 基于 UDP 之上实现,所以就没有这些限制。

QUIC 于现有 TCP + TLS + HTTP/2 上的主要功能包括:

  • 大大减少建立时间
  • 改善拥塞控制(congestion control)
  • 无队头阻塞(Head-of-line blocking)的多路复用
  • 前向纠错(Forward error correction)
  • 连接迁移(Connection migration)

Google,从 Chrome 到 Google 服务器的所有请求中,大约有一半是通过 QUIC 提供的,并且他们还在继续增加 QUIC 的占比,最终使其成为Google 客户端——Chrome 以及移动 apps 到 Google 服务器之间的默认传输方式。Google 计划正式向 IETF 提出 QUIC,使其成为一个网络标准,但首先还需要做一些工作,比如更新线路标准并将其实现从 SPDY-over-QUIC 更新为 HTTP2-over-QUIC(当前的 HTTP-over-QUIC 协议草案 使用最新发布的 TLS 1.3 协议)。在接下来的几个月内,Google 打算减少握手开销以便用于更好的服务器扩展,提升前向纠错和改善拥塞避免,同时增加对多路径链接(multipath connections)的支持。

HTTPS over TCP + TLS vs HTTPS over QUIC

reddit 的一位用户对 TCP 和 QUIC 的区分有个很好的解释:

开发 TCP 的时候需要通过比现在更大丢包率的网络进行数据包传递,并且当时的计算机系统需要更长的时间来响应 TCP 消息。例如,即便在 5 秒内无法完成 TCP 握手,主机的链接超时仍为 20 秒,即使在你不太可能获得响应的情况下。长时间的延迟是网络应用存在停滞时间过长的原因。我们无法更改这个 70 年代产生的协议,尽管在看到可靠性以及速度有很大提升的情况下。

在最大限度的与当前 TCP 兼容,而不是最终减少不会改变包的默认值的情况下,协议开发者开始使用 UDP 并在此基础上实现自己 TCP。 向 IPv6 的转变是修改 TCP 诸多问题的理想时间,例如大部分的超时,窗口尺寸(window size)以及 TCP 的慢启动。有些值可以在你的操作系统中调整,但是最烦人的超时是不能调整的。如果你终止已经有 5 秒超时的一条 TCP 套接字(TCP socket), 操作系统依旧需要为此保持打开状态,直到 20 秒以后结束,这会消耗系统资源。

参考资料:

  1. HTTP/3详解
  2. What is QUIC?
  3. HTTP/3 - HTTP over QUIC is the next generation by Daniel Stenberg (墙裂推荐)
  4. 上一条视频的幻灯片