谁不是作为管理员忙于优化Web服务器，不太可能偶然发现HTTP / 3。任何试图阅读该主题的人都会遇到令人眼花缭乱的首字母缩略词和术语，如qQUIC，iQUIC，HTTP-over-QUIC或HTTP / QUIC，这些都不是不言自明的。隐藏这些缩略语的背后隐藏着什么，连接它们以及它如何继续使用HTTP是本文的内容。

超文本传输协议（简称HTTP）是除了URL和HTML之外的万维网的三大支柱之一。当然，HTTP也有不同的开发阶段，可以从版本控制中读取。然而，与合理维护良好的HTML标准相比，近年来相对较少。1999年推出的HTTP / 1.1至今仍被绝大多数网站使用。尽管差不多四年的继任者HTTP / 2承诺了巨大的速度优势，但它仍然只能带来不到34％的差距。

目前的协议版本HTTP / 2几乎不为人所知，更不用说传播 - 门前已有接班人：HTTP / 3。第三个版本应该带来一些根本性的变化。

图1：层模型和日志分类

一个四级社会，或：层模型

新协议版本的主要原因是基于技术创新。实际上，旧的TCP应该被新的传输协议QUIC取代。这就是为什么我们在这种情况下谈论HTTP-over-QUIC，HTTP / QUIC或类似的东西。为了更好地理解QUIC的技术和使用，回到计算机科学的第一个学期并重新访问TCP / IP层模型是有帮助的（图1）。

为了能够将来自网络电缆的电子信号显示为网页，它们通过四层。在稍微更详细的OSI层模型中，有七个，但就我们的目的而言，简化的四层视图已经足够了。每个层由特定协议表示，该协议接受相邻层的信号或数据，处理它并将其转发到下一层。

从信号的纯物理传输开始，到质量保证到应用程序（例如浏览器）中的表示，每个级别都有其自身的含义。HTTP是最后一层协议，即应用层。它不仅用于传输超文本标记语言（HTML）思想，还用于传输z。作为音频，视频和图片。如果发生加密，则在第四层和第五层之间使用传输层安全性（TLS）。在传输层，使用已经变得很旧的TCP（传输控制协议）。另一种更快的传输协议是UDP（用户数据报协议）。由于UDP无法保证所有数据包都被传输，

当视频传输时，如果以每秒24帧中的一帧丢失某些信息，则几乎不可察觉。但是，HTML文件几乎没用，只有一个HTML标签的非传输剪辑。

曾几何时......

由于每个好的计算机科学讲座都包含历史性的游览，因此这里将简要介绍HTTP的发展（图2）。有史以来第一次，Tim Berners-Lee在1991年夏天提到了HTTP。他对WWW的概念包括三个组件HTML，统一资源定位器（然后是通用文档标识符，UDI）和HTTP。当时，HTTP仍然是一个非常简单的基于文本的协议，每次传输都需要自己的TCP连接。请求是一行的，来自服务器的响应仅包含所需的资源。

HTTP在接下来的几年里逐渐发展到了它的任务，并且来自多方面，或多或少地混乱，配备了新功能。五年后，在1996年夏天，互联网工程任务组（IETF）总结了最常见的功能，并在备忘录RFC1945中描述了HTTP / 1 。然而，重要的是要注意这不是一个标准：“这份备忘录没有规定任何形式的互联网标准，”它当时非常简洁地说。

在上述备忘录开始前一年开始制定官方标准，最初名称为HTTP / NG（NG代表下一代）。1997年，它成为RFC2068版本的HTTP / 1.1，现在也作为“真正的”标准推出。

最重要的变化是keepalive函数，它允许第一次持久连接。现在可以使用开放的TCP连接进行多个数据传输。此外，该协议还支持首次向服务器发送数据（PUT方法）。通过流水线理论上，理论上也可以进行查询，而不必等待答案 - 一个功能，当时仅由少数浏览器支持。

在那之后，HTTP安静了一段时间。直到2012年，HTTP / 2的草案才开始实施，主要基于SPDY，这是Google自2009年以来一直在努力的替代协议。在HTTP / 2标准正式出台，2015年。主要变化：多路复用已启用改进的异步数据交换。它也是第一次使用二进制协议。因此，数据不再以纯文本形式传输（方框：“Transitory，Persistent，Pipelining and Multiplexing”，图3）。

Transitory，Persistent，Pipelining and Multiplexing

Transitory
必须为每次数据交换创建TCP连接。

持久性
开放式TCP连接可用于多个请求和响应。

流水线操作
可以在不等待服务器响应的情况下发出HTTP请求。答案必须与请求的顺序相匹配。

多路复用
HTTP请求可以独立于先前的响应进行，顺序无关紧要。

首字母缩写词potpourri - HTTP / 3的方式

QUIC（快速UDP Internet连接）是Google于2012年首次推出的协议。从那时起，QUIC已在许多Google产品中实施，包括服务器端和客户端。2016年，IETF成立了一个工作组来解决这项新技术的标准化问题，以便将其用于HTTP。虽然QUIC的名称没有进一步采用，但它坚持认为它不是缩写：“QUIC是一个名字，而不是一个缩写”。

为了更好地区分分支，他们从加利福尼亚qQUIC调用了开发，并选择iQUIC作为计划的IETF标准。当然，必须调整使用QUIC的底层HTTP。该项目的工作标题最初是HTTP-over-QUIC或HTTP / QUIC。在2018年底，他们正式宣布他们正在开发最新版本的协议：HTTP / 3。

两个世界中最好的一个

长期以来，TCP一直是WWW的忠实仆人，但它不再符合现代要求。该协议不仅需要固定的发送订单，还需要发送数据的收据。这使得协议可靠，但也很慢。UDP速度更快但可靠性更低。该协议检查数据的完整性，但在出现错误或数据丢失时不采取纠正措施。

借助HTTP / 2和许多新功能，他们尝试将两种协议的优点结合起来，而不会失去对TCP的依赖。尽管HTTP / 2和多路复用仍在继续的一个问题是TCP级别的线头阻塞。如果在TCP传输期间丢失数据包，则所有后续数据包必须等待数据包的新传输。另一方面，QUIC启用真正的多路复用：请求可以异步发送，答案的顺序无关紧要，丢失的数据包不再保留队列（图4）。

这同样适用于应该在HTTP / 2中使用的持久连接，以减少所需的TCP连接数。但是，网络改变了。例如，如果您将智能手机从Wi-Fi更改为移动网络，则会丢失TCP连接。与基于发送方和接收方的IP地址和端口的TCP连接的识别不同，QUIC连接被赋予唯一的64位标识符。这是跨网络维护的，因此可以实现真正的持久连接。

另一项改进涉及通信的加密。以前，传输层安全性（TLS）充当HTTP和TCP之间的附加层。即使在HTTP / 2标准中，也不强制使用TLS。相反，流行的浏览器为HTTP / 2提供了加密连接，可以说是准标准。QUIC采用更激进的方法并直接实现加密。因此消除了TLS中间层，QUIC接管了连接的加密和认证。这也对性能产生积极影响。但并非全部：TLS仅加密有效负载，连接的元数据可以纯文本形式读取。另一方面，QUIC还加密连接元数据，提供额外的安全性。

QUIC在野外

任何想要了解qQUIC技术模型的人都可以使用众多Google服务中的一种。在Chrome浏览器的开发者控制台中，如果您之前通过上下文菜单启用了相应的列，则网络选项卡将显示您正在使用的协议（图5）。Google QUIC的官方网站还提供了详细的文档和一些代码示例。

网络诊断程序Wireshark还能够显示二进制QUIC数据，甚至可以区分gQUIC和iQUIC。为了以纯文本形式查看qQUIC流量，必须在GQUIC [sic]协议的设置中激活所有（Google）QUIC Payload的强制解码的复选标记。当然，只要协议允许，内容才会被解密。搜索查询无法以明文形式显示。该协议的快速过滤器是gquic。到z。例如，要显示初始gQUIC请求，请使用快速过滤器gquic.tag == CHLO。图6显示了gQUIC（此处为Q043版本）无需加密即可传输的数据摘录。

还有许多实验但也是QUIC的商业实现。例如，商业服务器软件LiteSpeed提供QUIC支持。对于nginx，还有一个实验性QUIC模块，以及Caddy。Caddy 在Go中使用了一个基于gQUIC和iQUIC的实现。可以在GitHub上找到所有QUIC实现的官方列表。

对于浏览器当然有Chrome，它支持自2012年以来的内部gQUIC。基本上，每个浏览器都准备好用于QUIC，如果他使用至少从版本29开始的渲染引擎Chromium - 作为z。B.歌剧院自2013年以来一直在做。在Opera中，您可能需要通过opera：flags首选项页面手动启用QUIC 。

展望

下一次HTTP演进背后的真正明星是QUIC。新的传输协议旨在取代历史悠久的TCP，以提高速度，移动性和安全性，并且还将更加一致地实现HTTP / 2的承诺。

当QUIC或HTTP / 3作为标准提供时，仍然完全不清楚。因此，开发人员和管理员仍有时间为未来制定计划或恐慌。恐慌其实不合适。QUIC在用户空间中运行，因此应易于实现。由于广泛的UDP被用作子结构，因此浏览器软件的更新就足够了，而不必等待下一个操作系统的发布。此外，QUIC被描述为向后兼容。因此，如果新协议的远程站尚未就绪，则提供对TCP的回退。

在Cloudflare，预计QUIC工作组将在年底前提交第一份完成的草案。但是，HTTP工作组尚未公布固定日期。但是，至少已经宣布将及时开发必要的扩展来为QUIC准备HTTP。那是件好事。