Get best of the week

UDP上的HTTP-有益地使用QUIC协议



QUIC（快速UDP Internet连接）是基于UDP的协议，支持TCP，TLS和HTTP / 2的所有功能，并解决了大多数问题。它通常被称为新的或“实验性”协议，但是它在实验阶段中长期存在：开发已经进行了7年以上。在这段时间内，该协议没有成为标准，但仍被广泛使用。例如，诸如Google和Facebook之类的巨头使用QUIC来加快流量并减少移动网络中的延迟，IETF宣布将其协议分支作为HTTP / 3标准的基础（尽管HTTP / 2 仅使用44.8％的站点）。

概念


QUIC的开发是对传统TCP的替代，后者最初是为损耗较低的有线网络设计的。 TCP按顺序传送数据包，因此当数据包丢失时，整个队列（行头阻塞）会增加，这会对连接的质量和稳定性产生负面影响。为了避免大量损失，蜂窝网络诉诸使用大缓冲区，这又导致冗余和错误的否定协议反应（bufferbloat）。此外，TCP花费大量时间建立连接：SYN / ACK和TLS请求分开进行，与QUIC一样，需要三个往返而不是一个。



由于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中成功完成的：

优步对QUIC实施的评论


QUIC , (HTTP/2 TLS/TCP) QUIC. Cronet Chromium Projects, , – gQUIC. , IETF.

Cronet Android-, QUIC. , . , , OkHttp, Cronet OkHttp API. , ( Retrofit) API.

Android-, Cronet Uber iOS, HTTP- API, NSURLProtocol. , iOS Foundation, - URL- , Cronet iOS- .
摘自Uber文章的译本

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

毫不奇怪，Google Cloud可以很好地与Google开发的协议配合使用，但是有哪些替代方案？

Nginx的


不久之前，CloudFlare 尝试使用其Quiche工具跨过 Nginx（默认情况下不知道HTTP / 3）。该实现以单个.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进行连接，但是您可以使用Chrome Canary并使用flag --enable-quic来运行它，然后转到您的服务器或quic.rocks网站，然后在开发人员工具中查看连接类型：

而不是HTTP / 3，它是编写的http2+quic/99，但是本质上是同一件事。

其他技术



结论




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

您已经可以为基础结构配置QUIC交互，甚至可以将其提供给浏览器-它们都计划添加协议支持，而带有caniuse的悲伤统计信息将变得更加有趣。


More articles:


All Articles