HTTP/3 是什么？
说明： 本文来自Medium，作者：Grigor Khachatryan
文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。
这段时间在研究 HTTP/2 的相关知识，没想到 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）的支持。
reddit 的一位用户对 TCP 和 QUIC 的区分有个很好的解释：
开发 TCP 的时候需要通过比现在更大丢包率的网络进行数据包传递，并且当时的计算机系统需要更长的时间来响应 TCP 消息。例如，即便在 5 秒内无法完成 TCP 握手，主机的链接超时仍为 20 秒，即使在你不太可能获得响应的情况下。长时间的延迟是网络应用存在停滞时间过长的原因。我们无法更改这个 70 年代产生的协议，尽管在看到可靠性以及速度有很大提升的情况下。
在最大限度的与当前 TCP 兼容，而不是最终减少不会改变包的默认值的情况下，协议开发者开始使用 UDP 并在此基础上实现自己 TCP。 向 IPv6 的转变是修改 TCP 诸多问题的理想时间，例如大部分的超时，窗口尺寸（window size）以及 TCP 的慢启动。有些值可以在你的操作系统中调整，但是最烦人的超时是不能调整的。如果你终止已经有 5 秒超时的一条 TCP 套接字（TCP socket）， 操作系统依旧需要为此保持打开状态，直到 20 秒以后结束，这会消耗系统资源。
参考资料：
