在去年的生日周，我们宣布初步支持QUIC和HTTP/3（或"HTTP over QUIC"，当时称之为"HTTP over QUIC"），这是网络的新标准，能够更快、更可靠、更安全地连接到网站和api等web端点。我们还让我们的客户加入一个等待名单，在他们成为QUIC和HTTP/3之后，他们就可以尝试使用QUIC和HTTP/3有空。自从然后，我们通过互联网工程工作组与业界同行合作，包括googlechrome和Mozilla Firefox，对HTTP/3和QUIC标准文档进行迭代。在标准日趋成熟的同时，我们还致力于提高对我们网络。我们现在我们很高兴地宣布，Cloudflare edge网络提供了QUIC和HTTP/3支持。我们很高兴谷歌Chrome和Mozilla Firefox加入我们的声明，这两家领先的浏览器供应商和合作伙伴致力于使web更快、更可靠全部。进来谷歌（Google）软件工程师瑞安•汉密尔顿（ryanhamilton）的话是："HTTP/3应该让每个人的网络变得更好。Chrome和Cloudflare团队紧密合作，将HTTP/3和QUIC从最初的标准引入到广泛采用的改进web的技术中。行业领导者之间的紧密合作使互联网标准创新成为可能，我们期待着我们继续合作。"这对您，一个使用我们的服务和边缘网络使您的web呈现更快、更安全的Cloudflare客户意味着什么？一旦在Cloudflare仪表板中为您的域启用了HTTP/3支持，您的客户就可以使用HTTP/3与您的网站和API进行交互。我们一直在稳步邀请HTTP/3等待名单上的客户打开该功能（所以请留意我们的电子邮件），在接下来的几周内，我们将向所有人。什么这个声明是否意味着如果你是互联网用户，通过浏览器和其他客户端与网站和API交互？从今天开始，您可以使用Chrome Canary通过HTTP/3与Cloudflare和其他服务器交互。对于那些正在寻找命令行客户机的人，curl还提供了对HTTP/3的支持。下面将介绍如何在HTTP/3中使用Chrome和curl邮递员从历史上看，互联网上的鸡和蛋标准创新一直很困难，因为有一个先有鸡有蛋的问题：服务器支持（如Cloudflare或其他大型响应数据源）还是客户端支持（如浏览器，操作系统等）？连接的双方都需要支持一个新的通信协议，以便在所有。Cloudflare在推动web标准向前发展方面有着悠久的历史，从HTTP/2（HTTP/3之前的HTTP版本）到TLS1.3，再到加密的SNI。我们通过与志同道合的组织合作来推动标准的发展，这些组织和我们一样希望帮助建立一个更好的互联网。我们将HTTP/3推向主流的努力是否定的不同的。贯穿始终在HTTP/3标准开发过程中，我们一直与业界合作伙伴密切合作，以构建和验证客户端HTTP/3支持与我们的边缘支持兼容。我们很高兴加入googlechrome和curl，它们现在都可以通过HTTP/3向Cloudflare edge发出请求。Mozilla Firefox希望尽快在夜间发布支持好吧。带着总而言之：今天是互联网用户的好日子；HTTP/3的广泛推出将意味着所有人都有更快的web体验，而今天的支持是朝着这个方向迈出的一大步那个。更多重要的是，今天是互联网的好日子：Chrome、curl和Cloudflare，很快，Mozilla迅速推出了对HTTP/3的实验性但功能性的支持，这表明互联网标准的创建过程是可行的。在互联网工程任务组的协调下，行业合作伙伴、竞争对手和其他关键利益相关者可以共同制定出有益于整个互联网的标准，而不仅仅是庞然大物。埃里克Firefox的CTO Rescorla很好地总结道："开发一个新的网络协议很难，把它做好需要大家一起努力。在过去的几年里，我们一直在与Cloudflare和其他行业合作伙伴一起测试tls1.3和现在的HTTP/3和QUIC。Cloudflare对这些协议的早期服务器端支持帮助我们解决了客户端Firefox实现中的互操作性问题。我们期待着共同提高互联网的安全性和性能？在我们深入研究HTTP/3之前，为了更好地理解HTTP/3为什么会这样，让我们快速了解一下HTTP的发展历程需要。它所有这些都始于1996年发布的HTTP/1.0规范，该规范定义了我们今天所知道的基本HTTP文本有线格式（在本文中，我假装HTTP/0.9从未存在过）。在HTTP/1.0中，为客户机和服务器之间的每个请求/响应交换创建一个新的TCP连接，这意味着所有请求都会产生延迟惩罚，因为TCP和TLS握手在每次握手之前完成请求。更糟不过，与其在建立连接后尽快发送所有未完成的数据，TCP实施了一个称为"慢启动"的预热期，它允许TCP拥塞控制算法在网络路径上发生拥塞之前确定在任何给定时刻可以传输的数据量，并避免用它无法处理的数据包淹没网络。但是，由于新的连接必须经过缓慢启动过程，它们不能使用所有可用的网络带宽马上。那个HTTP/1.1HTTP规范的修订版在几年后试图通过引入"保持活动"连接的概念来解决这些问题，该概念允许客户端重用TCP连接，从而在多个请求之间分摊初始连接建立和缓慢启动的成本。但这并非灵丹妙药：虽然多个请求可以共享同一个连接，但它们仍然必须一个接一个地序列化，因此客户机和服务器只能在任何给定的时间为每个请求/响应执行一个交换连接。如随着网络的发展，浏览器发现自己在获取数据时需要越来越多的并发性随着每个网站所需资源（CSS、JavaScript、图像等）数量的增加，呈现web页面。但是，由于HTTP/1.1一次只允许客户端进行一个HTTP请求/响应交换，所以在网络层获得并发的唯一方法是并行使用多个到同一个源的TCP连接，从而失去了保持活动连接的大部分好处。虽然连接仍会在一定程度上（但较小）被重用，但我们又回到了原点一个。终于十多年后，SPDY和HTTP/2相继问世，它引入了HTTP"流"的概念：一种允许HTTP实现同时将不同的HTTP交换复用到同一TCP上的抽象连接，允许浏览器更有效地重用TCP连接。但是，再说一次，这不是什么灵丹妙药！HTTP/2解决了最初的问题——单个TCP连接的效率低下——因为现在可以在同一个连接上同时传输多个请求/响应。然而，所有请求和响应都同样受到分组丢失的影响（例如，由于网络拥塞），即使丢失的数据只涉及单个请求。这是因为虽然HTTP/2层可以在不同的流上隔离不同的HTTP交换，但TCP对这种抽象一无所知，它所看到的只是一个没有特定的字节流意思是说TCP的作用是以正确的顺序将整个字节流从一个端点传递到另一个端点。当携带这些字节的TCP数据包在网络路径上丢失时，它会在流中产生一个空白，当检测到丢失时，TCP需要通过重新发送受影响的数据包来填充它。这样做时，丢失字节之后的成功传递字节都不能传递到应用程序，即使它们本身没有丢失，并且属于完全独立的HTTP请求。因此，它们最终会被不必要的延迟，因为TCP无法知道应用程序是否能够在没有丢失位的情况下处理它们。这个问题被称为"线路头阻塞"。输入HTTP/3这就是HTTP/3发挥作用的地方：它没有使用TCP作为会话的传输层，而是使用了QUIC，一种新的互联网传输协议，它在传输层将流作为一级公民引入。QUIC流共享同一个QUIC连接，因此不需要额外的握手和缓慢的启动来创建新的QUIC流，但是QUIC流是独立传递的，因此在大多数情况下，影响一个流的包丢失不会影响其他流。这是可能的，因为QUIC包封装在UDP之上数据报。使用与TCP相比，UDP允许更大的灵活性，并使QUIC实现完全生活在用户空间中—对协议实现的更新不像TCP那样与操作系统更新绑定在一起。有了QUIC，HTTP级别的流可以简单地映射到QUIC流之上，从而获得HTTP/2的所有好处，而无需前端阻塞.QUIC还结合了典型的3路TCP握手和tls1.3的握手。将这些步骤结合起来意味着默认情况下提供加密和身份验证，还可以更快地建立连接。换句话说，即使HTTP会话中的初始请求需要一个新的QUIC连接，在数据开始流动之前所产生的延迟也低于TCPTLS。但是为什么不直接在QUIC上使用HTTP/2，而不是创建一个全新的HTTP修订版呢？毕竟，HTTP/2还提供了流复用特性。事实证明，这比那个。虽然确实，一些HTTP/2特性可以很容易地映射到QUIC之上，但并非所有特性都是这样。尤其是HTTP/2