在去年的生日周，我们宣布了对QUIC的早期支持，QUIC是下一代默认加密的网络传输协议，旨在保护和加速互联网。我们还没有准备好让每个Cloudflare客户都能使用此功能，但是在您等待的时候，我们认为您可能会喜欢一片甜饼，我们自己的QUIC协议的开源实现铁锈蛋饼随着标准化进程的推进，我们可以随时了解QUIC协议的变化，并更容易地试验新特性。让我们快速看一下一起。简单引导quiche最初开发的主要设计原则是通过一个最小和直观的API将大部分QUIC复杂性暴露给应用程序，但没有对应用程序本身做太多假设，为了让我们可以在不同的上下文。用于例如，虽然我们认为Rust很好，但是在Cloudflare的边缘网络上处理HTTP请求的大部分堆栈仍然是用很好的ol'C编写的，这意味着我们的QUIC实现需要集成到那个。那个quicheapi可以处理从网络套接字接收的QUIC数据包并生成要发送回的数据包，但不会接触套接字本身。它还暴露了RITIAPI API上的一个薄层，以集成到C/C++（和其他语言）中。更简单。那个应用程序负责从网络获取数据（例如，通过套接字），传递给quiche，并将quiche生成的数据发送回网络。应用程序还需要处理计时器，quiche告诉它何时唤醒（例如，一旦相应的重传超时过期，重新传输丢失的数据包就需要这样做）。这使得应用程序可以自由决定如何最好地实现I/O和事件循环支持，取决于操作系统或网络框架提供的支持用过了。谢谢为此，我们能够将quiche集成到我们的NGINX fork中（尽管它还没有准备好开源），而不需要对NGINX内部进行重大更改。还可以与cURL一起构建Quiche，以支持cURL非常早期（而且非常实验性）的QUIC支持。当然，您可以使用quiche来实现用Rust编写的QUIC客户端和服务器好吧。更多几年前，我们将整个HTTPS协议栈迁移到了Google开发的crypto和TLS库BoringSSL。这使我们能够简化我们的堆栈（我们以前必须为OpenSSL维护自己的内部补丁，以实现BoringSSL提供的许多开箱即用的特性）以及发布更多令人兴奋的新特性快点。为了不遵循QUIC标准化流程的，QUIC协议本身使用tls1.3作为连接握手的一部分，因此我们的QUIC实现也将使用BoringSSL来实现协议。如就QUIC而言，TLS库需要提供加密参数（包括加密机密）的协商，然后由QUIC层本身用来加密/解密线路上的数据包。TLS记录层被QUIC帧代替，以避免开销和重复，因此TLS握手消息直接在加密的QUIC上传输包。这个使与现有TLS实现的集成更具挑战性，因为它们需要按原样公开原始TLS握手消息，没有记录层或保护，这将由蛋奶饼处理本身。博林格斯尔提供了一个专用的API，可以被QUIC实现使用，这需要一些调整，正如您所期望的那样，这些新的、实验性的东西，但总的来说，融入蛋奶酥。一个当TLS握手直接使用BoringSSL的API（通过Rust的FFI支持）实现时，要实现QUIC的包保护，我们决定使用ring，这是一个非常流行的Rust库，它提供安全和快速的加密原语环提供了大部分相同的功能您可以使用BoringSSL的libcrypto获得加密原语，但通过直观和安全的Rust API公开。事实上，ring使用了一些与BoringSSL同样使用的加密算法的快速实现，但是通过一个更好的API。但是QUIC对密码学的使用有点独特，嗯，异国情调：数据包的有效负载保护使用标准AEAD（"带关联数据的认证加密"）算法，如AES-GCM和ChaCha20-Poly1305，但对数据包报头的保护是不同的，是专门为QUIC设计的，以防止网络上的中间盒拦截数据包的一些元数据（如Ring最初并没有公开实现QUIC头保护所需的原语，但是添加对它们的支持很容易，我们的更改（现在也是开源的）在RingV0.14.0中正式发布，每个人都可以使用使用结论while蛋奶酥是最新加入的QUIC实现（它的第一次提交可以追溯到大约3个月前），它已经能够与其他更成熟的实现进行互操作，并执行许多QUIC的实现特色菜。蛋奶酥，就像QUIC本身一样，还没有"完成"（或者说是完美的）。随着我们从互联网上更广泛的QUIC部署中获得经验和教训，bug将会被发现并修复，新的令人兴奋的特性将被实现（然后会发现更多的bug），API兼容性也会被破坏。