二十多年来，我们一直在使用HTTP协议查看网页。 大多数用户根本不考虑它是什么以及它如何工作。 其他人知道，在HTTP下有TLS，在其下有TCP，在IP下有IP，等等。 其他人-异端主义者-相信TCP是上个世纪，他们想要更快，更可靠和更安全的东西。 但是，在尝试发明新的理想协议的过程中，他们回到了80年代的技术中，并试图在其上建立自己的勇敢的新世界。
一点历史：HTTP / 1.1
在1997年，HTTP版本1.1文本交换协议获得了RFC。 当时，该协议已被浏览器使用了几年，而新标准又持续了十五年。 该协议仅在请求-响应的基础上起作用，并且主要用于传输文本信息。
HTTP被设计为在TCP协议之上运行，从而保证了将数据包可靠地传递到目的地。 TCP基于在端点之间建立和维护可靠的连接以及对流量进行分段。 段具有自己的序列号和校验和。 如果突然出现其中一个段不正确或校验错误，传输将停止，直到丢失的段恢复为止。
在HTTP / 1.0中，每次请求后都会关闭TCP连接。 从那以来，这是非常浪费的 建立TCP连接（3-Way-Handshake）不是一个快速的过程。 HTTP / 1.1引入了保持活动机制，该机制使您可以将单个连接重用于多个请求。 但是，由于它很容易成为瓶颈，因此在不同的HTTP / 1.1实现中允许到同一主机的多个TCP / IP连接。 例如，在Chrome和最新版本的Firefox中，最多允许六个连接。
还应该将加密留给其他协议使用，为此，在TCP上使用了TLS协议，该协议可靠地保护了数据，但进一步增加了建立连接所需的时间。 结果，握手过程开始如下所示：
Cloudflare图因此，HTTP / 1.1存在许多问题：
- 连接设置缓慢。
- 一个TCP连接用于一个请求，这意味着其余请求必须找到另一个连接，或者等待当前请求释放它。
- 仅支持拉动模型。 标准中没有关于服务器推送的内容。
- 标题以文本形式传输。
如果使用WebSocket协议实现服务器推送，则必须更彻底地解决其余问题。
有点现代：HTTP / 2
2012年，谷歌开始研究SPDY协议（发音为“速度”）。 该协议旨在解决HTTP / 1.1的基本问题，同时必须保持向后兼容性。 2015年，IETF工作组引入了基于SPDY协议的HTTP / 2规范。 这是HTTP / 2中的区别：
- 二进制序列化。
- 将多个HTTP请求复用到单个TCP连接中。
- 开箱即用的服务器（不带WebSocket）。
该协议是向前迈出的一大步。 它大大
优于第一个版本 ，并且不需要创建多个TCP连接：对一个主机的所有请求都被多路复用为一个。 也就是说，在一个连接中，有几个所谓的流，每个流都有自己的ID。 奖金是盒装服务器推。
但是，乘法会导致另一个基石问题。 想象一下，我们异步地对一台服务器执行5个请求。 当使用HTTP / 2时，所有这些请求将在同一TCP连接中执行，这意味着，如果任何请求的段之一丢失或到达不正确，则所有请求和响应的传输将停止，直到恢复丢失的段。 显然，连接质量越差，HTTP / 2的工作就越慢。
根据Daniel Stenberg的说法 ，在丢失的数据包占总数2％的情况下，浏览器中的HTTP / 1.1会打开6个连接而不是一个，因此其性能优于HTTP / 2。
这个问题称为“行头阻塞”，不幸的是，无法使用TCP来解决。
丹尼尔·斯坦伯格的插图结果，HTTP / 2标准的开发人员做了出色的工作，几乎完成了OSI模型应用程序级别可以完成的所有工作。 现在该下到传输层并发明新的传输协议了。
我们需要一个新的协议：UDP vs TCP
很快就很清楚，引入一个全新的传输层协议是当今现实中无法解决的任务。 事实是，腺体或中间盒（路由器，防火墙，NAT服务器...）了解传输级别，并且教给他们一些新知识是非常困难的任务。 另外，对传输协议的支持被连接到操作系统的内核中，并且内核也不太愿意改变。
在这里，我们可以放弃说：“我们当然会发明具有优先权和礼貌的新HTTP / 3，但是它将在10到15年内实施（大约在这个时候大部分腺体将被替换）”，但是还有一个不是最显而易见的选择：使用UDP协议。 是的，是的，这与我们在90年代末和零开始时将文件扔到LAN上的协议相同。 如今，几乎所有铁片都知道如何使用它。
UDP优于TCP的优点是什么？ 首先，我们没有铁知道的运输级别会议。 这使我们能够自行确定端点上的会话并解决那里出现的冲突。 也就是说，我们不限于一个或几个会话（如TCP），但是我们可以根据需要创建它们。 其次，通过UDP的数据传输比通过TCP的数据传输更快。 因此，从理论上讲，我们可以突破HTTP / 2中达到的当今速度上限。
但是，UDP不保证可靠的数据传输。 实际上，我们只是发送数据包，希望它们会在另一端收到。 没有收到？ 好吧，不走运……这足以为成人传输视频，但是对于更严重的事情，您需要可靠性，这意味着您必须在UDP之上缠绕其他内容。
与HTTP / 2一样，创建新协议的工作始于2012年，即大约在SPDY工作开始的同时在Google进行。 2013年，Jim Roskind向公众介绍
了QUIC协议（Quick UDP Internet Connections） ，并于2015年引入了Internet Draft以标准化IETF。 那时，Roskind在Google上开发的协议与标准协议已经非常不同，因此Google版本称为gQUIC。
什么是QUIC
首先，如前所述，这是UDP的包装。 QUIC连接高于UDP，在UDP中，类似于HTTP / 2，可能存在多个流。 这些流仅存在于端点，并独立提供服务。 如果丢包发生在一个流中，则不会以任何方式影响其他流。
丹尼尔·斯坦伯格的插图其次，加密现在不是在单独的级别上实现的，而是包含在协议中。 这样，您可以在一次握手中建立连接并交换公共密钥，还可以使用棘手的0-RTT握手机制，通常可以避免握手时的延迟。 此外，现在可以对单个数据包进行加密。 这使您不必等待从流接收数据的完成，而是独立地解密接收到的数据包。 在TCP中根本无法使用这种操作模式，因为 TLS和TCP彼此独立工作，并且TLS不知道TCP数据将分成哪些部分。 因此，我无法准备自己的段，以便它们一对一地适合TCP段，并且无法独立解密。 与TCP相比，所有这些改进使QUIC可以减少延迟。
第三，简单流的概念使您可以从客户端的IP地址断开连接。 例如，当客户端从一个Wi-Fi接入点切换到另一个Wi-Fi接入点并更改其IP时，这一点很重要。 在这种情况下，使用TCP时会发生一个漫长的过程，在此过程中，现有的TCP连接将超时超时，并根据新IP创建新连接。 对于QUIC，客户端只是继续使用旧的流ID将数据包从新IP发送到服务器。 因为 流ID现在是唯一的，并且不会重用，服务器了解客户端已更改IP，发送丢失的数据包并继续与新地址通信。
第四，QUIC是在应用程序级别而非操作系统上实现的。 一方面，这可以更快地更改协议，因为 要获取更新，只需更新库，而不要等待操作系统的新版本。 另一方面，这导致处理器消耗的大幅增加。
最后，头条新闻。 标头压缩仅指的是QUIC和gQUIC不同的点。 我没有理由为此花很多时间，我只能说在提交标准化的版本中，头压缩与HTTP / 2中的头压缩尽可能相似。 更多细节可以在
这里阅读。
它快多少？
这是一个棘手的问题。 事实是，虽然我们没有标准，但没有什么特别的可衡量的标准。 也许我们仅有的统计信息是Google的统计信息，该统计信息自2013年以来一直使用gQUIC，2016年
向IETF报告说，现在有90％的Chrome浏览器流向其服务器的流量正在使用QUIC。 在同一演示中，他们报告说，通过gQUIC，与TCP相比，页面加载速度提高了约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仅支持
Caddy和
Cloudflare ，但到目前为止还只是实验性的。 NGINX在2019年春末
宣布 ，他们已开始进行HTTP / 3支持的工作，但尚未完成。
有什么问题
我们生活在现实世界中，没有任何一项大技术都能在没有遇到阻力的情况下传给大众，QUIC也不例外。
最重要的是，您需要以某种方式向浏览器说明“ https：//”不再是导致443rd TCP端口的事实。 可能根本没有TCP。 为此，请使用Alt-Svc标头。 它允许浏览器获知该网站也可在该地址处以该协议使用。 从理论上讲，它应该像时钟一样工作，但是在实践中，我们偶然发现了这样一个事实，例如可以在防火墙上禁用UDP以避免DDoS攻击。
但是，即使不禁止UDP，客户端也可能位于配置为通过IP地址保持TCP会话的NAT路由器之后，例如 我们使用UDP，其中没有硬件会话，NAT将无法保持连接，而QUIC会话
将始终终止 。
所有这些问题都与以下事实有关：UDP以前没有用于传输Internet内容，并且硬件制造商无法预料到这种情况会发生。 同样，管理员还不了解如何为QUIC正确配置其网络。 这种情况将缓慢改变，并且在任何情况下，与引入新的传输层协议相比，这种改变将花费更少的时间。
另外，如上所述，QUIC大大提高了处理器利用率。 Daniel Stenberg对处理器的增长进行了三倍的
评估 。
当HTTP / 3出现时
他们
希望在 2020年5月之前
采用该标准，但鉴于计划在2019年7月完成的文件仍未完成，我们可以说日期最有可能被推迟。
好的，自2013年以来，谷歌一直在使用其gQUIC的实现。 如果您查看发送到Google搜索引擎的HTTP请求，则可以看到以下内容：
结论
QUIC现在看起来像是一种相当粗糙但非常有前途的技术。 考虑到在过去的20年中，传输层协议的所有优化都主要与TCP，QUIC有关，在大多数情况下，它们在性能上都占优势，现在看来非常好。
但是，在未来几年中仍然有未解决的问题必须解决。 由于涉及到硬件这一事实，该过程可能会被延迟，没有人喜欢更新，但是尽管如此，所有问题看起来都可以解决，我们迟早都会拥有HTTP / 3。
未来不远了！