20 多年来，我们一直使用 HTTP 协议查看网页。 大多数用户甚至不会考虑它是什么以及它是如何工作的。 其他人知道HTTP下面有TLS，TCP下面是IP，等等。 还有一些人（异端分子）认为 TCP 已经成为过去；他们想要更快、更可靠、更安全的东西。 但在尝试发明一种新的理想协议时，他们又回到了 80 年代的技术，并试图在此基础上建立他们的美丽新世界。
一点历史：HTTP/1.1
1997年，文本信息交换协议HTTP 1.1版获得了自己的RFC。 当时，该协议已经被浏览器使用了几年，而新标准又持续了十五年。 该协议仅适用于请求-响应原则，主要用于文本信息的传输。
HTTP 被设计为在 TCP 协议之上运行，确保数据包可靠地传送到目的地。 TCP 的工作原理是在端点之间建立和维护可靠的连接并将流量分成段。 段有自己的序列号和校验和。 如果突然其中一个数据段未到达或到达时校验和不正确，则传输将停止，直到恢复丢失的数据段。
在 HTTP/1.0 中，TCP 连接在每次请求后都会关闭。 这是非常浪费的，因为…… 建立 TCP 连接（3 次握手）是一个缓慢的过程。 HTTP/1.1 引入了 keep-alive 机制，该机制允许您为多个请求重复使用一个连接。 然而，由于它很容易成为瓶颈，HTTP/1.1 的各种实现都允许向同一主机打开多个 TCP 连接。 例如，Chrome 和最新版本的 Firefox 允许最多六个连接。
加密也应该留给其他协议，为此，在 TCP 上使用了 TLS 协议，这可靠地保护了数据，但进一步增加了建立连接所需的时间。 结果，握手过程开始是这样的：
Cloudflare 插图
因此 HTTP/1.1 存在许多问题：
- 连接设置速度慢。
- 数据以文本形式传输，图片、视频等非文本信息的传输是无效的。
- 一个 TCP 连接用于一个请求，这意味着其他请求必须要么寻找另一个连接，要么等待当前请求释放它。
- 仅支持拉动模型。 标准中没有关于服务器推送的内容。
- 标题以文本形式传输。
如果服务器推送至少是使用 WebSocket 协议实现的，那么就必须更彻底地处理其他问题。
一点现代感：HTTP/2
2012 年，Google 开始研究 SPDY（发音为“speedy”）协议。 该协议旨在解决 HTTP/1.1 的主要问题，同时保持向后兼容性。 2015年，IETF工作组推出了基于SPDY协议的HTTP/2规范。 以下是 HTTP/2 的差异：
- 二进制序列化。
- 将多个 HTTP 请求复用到单个 TCP 连接中。
- 开箱即用的服务器推送（无 WebSocket）。
该协议向前迈出了一大步。 他强烈地 并且不需要创建多个 TCP 连接：对一台主机的所有请求都被复用为一个。 也就是说，在一个连接中存在多个所谓的流，每个流都有自己的 ID。 奖励是盒装服务器推送。
然而，多路复用会导致另一个关键问题。 想象一下，我们正在向一台服务器异步执行 5 个请求。 当使用 HTTP/2 时，所有这些请求都将在同一个 TCP 连接内进行，这意味着如果任何请求的其中一个报文段丢失或接收不正确，所有请求和响应的传输都将停止，直到丢失的报文段被恢复。恢复了。 显然，连接质量越差，HTTP/2 的运行速度就越慢。 ，在丢失数据包占所有数据包 2% 的情况下，浏览器中的 HTTP/1.1 表现优于 HTTP/2，因为它打开了 6 个连接而不是 XNUMX 个。
这个问题被称为“队头阻塞”，不幸的是，使用 TCP 时无法解决它。
丹尼尔·斯坦伯格的插图
结果，HTTP/2 标准的开发人员做得非常出色，几乎做了 OSI 模型应用层能做的所有事情。 是时候深入到传输层并发明一种新的传输协议了。
我们需要一个新协议：UDP 与 TCP
很快我们就发现，在当今的现实中，实施全新的传输层协议是一项不可能完成的任务。 事实上，硬件或中间件（路由器、防火墙、NAT 服务器...）了解传输层，向它们传授一些新知识是一项极其困难的任务。 另外，对传输协议的支持是内置在操作系统内核中的，内核也不太愿意改变。
在这里，人们可能会举手说：“我们当然会发明一种新的带有偏好和妓女的 HTTP/3，但这需要 10 到 15 年的时间才能实现（大约在这段时间之后，大多数硬件将被替换）”，但还有一个不那么明显的选择是使用 UDP 协议。 是的，是的，我们在九十年代末和 XNUMX 年代初用来通过 LAN 传输文件的协议相同。 当今几乎所有的硬件都可以与它配合使用。
UDP相对于TCP有什么优点？ 首先，我们没有硬件知道的传输层会话。 这使我们能够自己确定端点上的会话并解决那里的冲突。 也就是说，我们不限于一个或多个会话（如 TCP 中），而是可以根据需要创建任意多个会话。 其次，通过UDP传输数据比通过TCP传输更快。 因此，理论上我们可以突破HTTP/2目前达到的速度上限。
然而，UDP并不能保证可靠的数据传输。 事实上，我们只是发送数据包，希望对方能够收到。 还没有收到？ 好吧，运气不好...这足以传输成人视频，但对于更严重的事情，您需要可靠性，这意味着您必须在 UDP 之上包装其他内容。
与 HTTP/2 一样，Google 于 2012 年开始创建新协议，即与 SPDY 的工作大约在同一时间开始。 2013年，吉姆·罗斯金德向公众展示 ，并且已于 2015 年在 IETF 中引入了互联网草案以实现标准化。 即使在当时，Roskind 在 Google 开发的协议也与标准有很大不同，因此 Google 版本开始被称为 gQUIC。
什么是 QUIC
首先，正如已经提到的，这是 UDP 的包装。 QUIC 连接建立在 UDP 之上，与 HTTP/2 类似，其中可以存在多个流。 这些流仅存在于端点上并且独立提供服务。 如果一个流发生丢包，不会影响其他流。
丹尼尔·斯坦伯格的插图
其次，加密不再在单独的层面上实现，而是包含在协议中。 这允许您在一次握手中建立连接并交换公钥，还允许您使用巧妙的 0-RTT 握手机制并完全避免握手延迟。 此外，现在可以对单个数据包进行加密。 这使得您不必等待从流中接收数据完成，而是独立解密接收到的数据包。 这种操作模式在 TCP 中通常是不可能的，因为TLS 和 TCP 彼此独立工作，TLS 无法知道 TCP 数据将被切成哪些部分。 因此，他无法准备他的数据段，以便它们一对一地适合 TCP 数据段并且可以独立解密。 所有这些改进使得 QUIC 与 TCP 相比能够减少延迟。
第三，轻流的概念允许您将连接与客户端的 IP 地址解耦。 这很重要，例如，当客户端从一个 Wi-Fi 接入点切换到另一个 Wi-Fi 接入点并更改其 IP 时。 在这种情况下，使用 TCP 时，会发生一个漫长的过程，在此期间现有的 TCP 连接超时，并从新 IP 创建新连接。 对于 QUIC，客户端只需继续从具有旧流 ID 的新 IP 向服务器发送数据包即可。 因为流 ID 现在是唯一的并且不会重复使用；服务器了解客户端已更改 IP，重新发送丢失的数据包并在新地址继续通信。
第四，QUIC是在应用程序级别实现的，而不是操作系统级别。 一方面，这允许您快速更改协议，因为要获得更新，您只需更新库，而不是等待新的操作系统版本。 另一方面，这导致处理器消耗的强劲增加。
最后，头条新闻。 标头压缩是 QUIC 和 gQUIC 之间的区别之一。 我不认为在这方面投入大量时间有什么意义，我只是说在提交标准化的版本中，标头压缩尽可能类似于 HTTP/2 中的标头压缩。 您可以阅读更多内容 .
快了多少？
这是一个很难的问题。 事实是，在我们有一个标准之前，没有什么特别可以衡量的。 也许我们唯一的统计数据是来自 Google 的统计数据，该公司自 2013 年和 2016 年以来一直在使用 gQUIC 现在，从 Chrome 浏览器流向其服务器的大约 90% 的流量都使用 QUIC。 在同一演示中，他们报告说，与 TCP 相比，通过 gQUIC 的页面加载速度提高了约 5%，视频流的卡顿现象减少了 30%。
2017 年，Arash Molavi Kakhki 领导的一组研究人员发表了 研究 gQUIC 与 TCP 相比的性能。
该研究揭示了 gQUIC 的几个弱点，例如网络数据包混合的不稳定、对通道带宽的贪婪（不公平）以及小（最多 10 kb）对象的传输速度较慢。 然而，后者可以通过使用 0-RTT 来补偿。 在所有其他研究案例中，与 TCP 相比，gQUIC 的速度有所提高。 这里很难谈论具体数字。 更好地阅读 или .
这里必须要说的是，这些数据是专门针对gQUIC的，与正在开发的标准无关。 QUIC 将会发生什么：这仍然是一个秘密，但希望 gQUIC 中发现的弱点能够得到考虑和纠正。
未来展望：HTTP/3 怎么样？
但这里一切都很清楚：API 不会以任何方式改变。 一切都将与 HTTP/2 中完全相同。 好吧，如果 API 保持不变，则必须通过在支持 QUIC 传输的后端使用新版本的库来解决向 HTTP/3 的过渡。 确实，您将不得不在相当长的一段时间内保留旧版本 HTTP 的回退，因为Internet 目前尚未准备好完全过渡到 UDP。
谁已经支持了
这里 现有的 QUIC 实现。 尽管缺乏标准，但这份清单还不错。
目前没有浏览器在生产版本中支持 QUIC。 最近有消息称 Chrome 中包含了对 HTTP/3 的支持，但到目前为止仅在 Canary 中。
在后端中，HTTP/3 仅支持 и ，但仍处于实验阶段。 NGINX 将于 2019 年春季结束 ，他们开始致力于 HTTP/3 支持，但尚未完成。
存在哪些问题？
你我都生活在现实世界中，任何重大技术都无法在不遇到阻力的情况下普及到大众，QUIC 也不例外。
最重要的是，您需要以某种方式向浏览器解释“https://”不再是它通向 TCP 端口 443 的事实。 可能根本就没有TCP。 Alt-Svc 标头用于此目的。 它允许您告诉浏览器该网站也可通过某协议、某地址访问。 从理论上讲，这应该很有效，但在实践中我们会遇到这样的事实：例如，可以在防火墙上禁止 UDP 以避免 DDoS 攻击。
但即使不禁止 UDP，客户端也可能位于配置为通过 IP 地址保持 TCP 会话的 NAT 路由器后面，并且因为我们使用 UDP，它没有硬件会话，NAT 不会保持连接，以及 QUIC 会话 .
所有这些问题都是由于UDP以前没有被用来传输互联网内容，硬件制造商无法预见到这种情况会发生。 同样，管理员尚未真正了解如何正确配置网络以使 QUIC 正常工作。 这种情况将逐渐改变，并且无论如何，这种改变将比实施新的传输层协议花费更少的时间。
此外，如前所述，QUIC 极大地增加了 CPU 使用率。 丹尼尔·斯坦伯格 处理器增长达三倍。
HTTP/3什么时候到来？
标准 到 2020 年 2019 月，但鉴于原定于 XNUMX 年 XNUMX 月提交的文件目前尚未完成，我们可以说该日期很可能会推迟。
嗯，谷歌自 2013 年以来一直在使用其 gQUIC 实现。 如果您查看发送到 Google 搜索引擎的 HTTP 请求，您将看到以下内容：
发现
QUIC 现在看起来是一项相当粗糙但非常有前途的技术。 考虑到过去20年，所有传输层协议的优化都主要围绕TCP，QUIC在大多数情况下性能最好，看起来已经非常好了。
然而，仍有一些未解决的问题需要在未来几年内解决。 由于涉及硬件，这一过程可能会被延迟，而没有人喜欢更新硬件，但尽管如此，所有问题看起来都可以解决，迟早我们都会拥有 HTTP/3。
未来就在眼前！
来源： habr.com