HTTP over UDP - 充分利用 QUIC 协议

QUIC（快速 UDP Internet 连接）是一种基于 UDP 的协议，支持 TCP、TLS 和 HTTP/2 的所有功能并解决它们的大部分问题。 它通常被称为新的或“实验性”协议，但它早已超出了实验阶段：开发已经持续了 7 年多。 在此期间，该协议并未成为标准，但仍然广泛传播。 例如，Google 和 Facebook 等巨头使用 QUIC 来加速流量并减少移动网络中的延迟，IETF 宣布该协议的分支是 HTTP/3 标准的基础（尽管 HTTP/2 使用 只有44.8％ 站点）。

概念

QUIC 是作为传统 TCP 的替代品而开发的，后者最初是为低损耗有线网络设计的。 TCP 按顺序传送数据包，因此如果丢失一个数据包，整个队列就会停止（线头阻塞），这会对连接的质量和稳定性产生负面影响。 为了避免巨大的损失，蜂窝网络诉诸于使用大缓冲区，这反过来又导致协议的冗余和误报响应（缓冲膨胀）。 此外，TCP 花费大量时间建立连接：SYN/ACK 和 TLS 请求是分开处理的，需要 XNUMX 次往返，而不是像 QUIC 那样需要 XNUMX 次往返。

由于 QUIC 结合了 TCP 替代和 TLS 1.3 的实现，因此所有连接始终都是加密的，并且解密此类流量并不比通过 HTTPS 传输更容易。 此外，QUIC 是在应用程序级别实现的，因为完全替换 TCP 堆栈需要 永恒.

尽管 HTTP/2 支持多路复用，但由于需要按顺序传送数据包，队头阻塞问题仍然存在。 QUIC 是在 UDP 之上实现的，因此原则上没有阻塞，并且为了防止数据包永远丢失，它们被编号并可以包含部分“邻居”，从而提供冗余。 此外，QUIC 将整体队列拆分为多个线程，用于单个连接中不同类型的请求。 因此，如果数据包丢失，则仅一个队列可能会出现问题（例如，传输特定文件）：

使用

最初，QUIC 是在 Google 内部开发的，主要是为在公司内部使用而定制的。 2013年，它被转移到IETF进行标准化（目前仍在进行中），现在每个人都可以通过提出自己缺失的内容来参与协议的开发。 IETF 工作组组织年度会议，批准新标准并讨论创新。 QUIC 的这一实现被认为是主要实现，HTTP/3 标准正是在其基础上获得认证的。

到目前为止，还没有讨论将 HTTP/3 作为主要协议，因为它还没有完成并且几乎不被支持：

但 QUIC 可以作为应用程序和服务器之间的传输来实现，Uber 已经成功做到了这一点：

Uber对引入QUIC的评论

为了在连接不良的环境中成功嵌入 QUIC 并提高应用程序性能，我们用 QUIC 协议替换了旧堆栈（基于 TLS/TCP 的 HTTP/2）。 我们使用了网络图书馆 克罗内特 из 铬项目，其中包含原始的 Google 版本协议 - gQUIC。 该实现也在不断改进，以遵循最新的 IETF 规范。

我们首先将 Cronet 集成到我们的 Android 应用程序中以添加对 QUIC 的支持。 整合的方式是尽可能降低迁移成本。 而不是完全替换使用该库的旧网络堆栈 好的http，我们在 OkHttp API 框架下集成了 Cronet。 通过这种方式进行集成，我们避免了对网络调用的更改（这些调用由 改造）在 API 级别。

与 Android 设备的方法类似，我们在 iOS 上的 Uber 应用程序中实现了 Cronet，拦截来自网络的 HTTP 流量 API运用 NSURL协议。 这种抽象由 iOS 基金会提供，可处理特定于协议的 URL 数据，并确保我们可以将 Cronet 集成到我们的 iOS 应用程序中，而无需大量迁移成本。

取自 这个翻译 优步文章

在后端，他们通过 Google Cloud lb 捕获了 QUIC 连接，这 支持协议 自2018年中期以来。

谷歌云与谷歌开发的协议配合得很好，这并不奇怪，但还有什么替代方案呢？

Nginx的

不久前 CloudFlare 我尝试着穿越 nginx（默认情况下不支持 HTTP/3）及其 Quiche 工具。 该实现可作为单个 .patch 文件使用，该文件附带安装教程：

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

如有必要，您可以在此处连接模块

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

剩下的就是启用 HTTP/3 支持

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

目前还无法在常规浏览器中通过 HTTP/3 连接，但您可以使用 镀铬加那利 并用标志运行它 --enable-quic，转到您的服务器或例如 quic.rocks 站点，然后在开发人员工具中查看连接类型：

它不是 HTTP/3，而是这样写的 http2+quic/99，但本质上是一样的。

其他技术

• QUIC也支持 的Litespeed （大张旗鼓地通过 HTTP/3 连接到 Facebook）和渐进式 盒。 Apache 还不能做到，但工作正在进行中 如火如荼.
• 21 月 XNUMX 日更新 WebRTC 标准草案
• 就在微软刚开业的那天 msquic实现代码，其中尚未提供 IETF 标准的所有功能，但这已经是一个很大的突破。

结论

对 QUIC 的兴趣不稳定，但正在增长，并且正在进行标准化工作。 该协议的新实现几乎每个月都会出现，并且每年都有越来越多的开发人员相信 QUIC 是未来。 甚至有可能将该协议包含在 TCP 堆栈的未来版本中，这意味着整个互联网迟早会转向更稳定、更快的连接。

现在您已经可以为您的基础设施配置 QUIC 交互，甚至将其提供给浏览器 - 他们都计划添加对该协议的支持，而 caniuse 的悲伤统计数据将变得更加令人高兴。

来源： habr.com