Quick UDP Internet Connections 让互联网更快的协议，QUIC在腾讯的实践及性能优化

时间  2019-11-18
标签 quick udp internet connections 互联网 更快 协议 quic 腾讯 实践 性能 优化 栏目 腾讯 繁體版
原文   原文链接

 

https://mp.weixin.qq.com/s/44ysXnVBUq_nJByMyX9n5Ahtml

让互联网更快：通往QUIC之路

QUIC（Quick UDP Internet Connections）是一种默认加密的新互联网传输协议，它提供了多项改进，旨在加速HTTP传输并使其更加安全，目标是想最终取代TCP和TLS协议。在本文中，咱们将概述QUIC协议的一些关键特性和它们给Web带来的好处，以及支持这一全新协议过程当中遇到的一些挑战。python

实际上有两个协议共享QUIC这个名称，其一是“Google QUIC”（下称“gQUIC”），是Google工程师几年前设计的原始协议，通过多年的实验，现已被IETF（Internet Engineering Task Force）采用并正在进行标准化。android

 

另外一个是“IETF QUIC”（下称“QUIC”），因为和gQUIC有着显著的差异，所以能够认为它是一个单独的协议。经过许多组织和我的的协做努力，从数据传输格式到握手和HTTP映射，QUIC改进了原有的gQUIC设计，但共同目标仍然是尽量让互联网变得更快、更安全。那么，QUIC都提供了哪些改进呢？git

 

内置的安全和性能机制github

 

QUIC与如今经常使用的TCP相比，一个完全的改变是它的设计目标：默认提供安全的传输协议。QUIC经过在传输层提供安全特性（如身份验证和加密）来实现，而以往这些功能一般由更高层的协议（如TLS）处理。web

 

最初的QUIC握手方式结合了TCP经典的三次握手与TLS 1.3对端点的认证以及加密参数的协商。对于熟悉TLS协议的人来讲，QUIC实际上是取代了TLS记录协议，保留了TLS握手协议。算法

 

这不只确保了链接始终被认证和加密，并且还使得初始链接创建更快：与TCP和TLS 1.3握手相结合所需的两次往返相比，典型的QUIC握手只须要在客户端和服务器之间完成一次往返。chrome

不只如此，QUIC还加密了可能被中间设备滥用而干扰链接的其它元数据。例如，当使用链接迁移时，被动式攻击可使用数据包序号来关联多个网络路径上的用户活动（见下文）。经过加密数据包序号，QUIC能够确保它们不能被链接端点以外的任何实体关联活动。shell

 

加密也能够成为僵化问题（ossification）的有效补救措施，这使得协议的灵活性（例如可以协商不一样版本的协议）因为错误的假设而在实践中不能被使用。僵化问题致使了TLS 1.3部署的长期延迟，而在几回更改（防止中间设备错误地阻止新版本的TLS协议）被采用以后才使得部署变得可能。浏览器

 

队头阻塞

 

HTTP/2提供的重要改进之一是可以将不一样的HTTP请求复用同一个TCP链接，这使得HTTP/2应用程序能够并行处理请求并更好地利用可用的网络带宽。

 

这是一项重大改进，若是想要同时处理多个HTTP/1.1请求（例如当浏览器须要同时获取CSS和JavaScript资源渲染网页时），应用程序须要启动多个TCP + TLS链接。建立新链接须要重复屡次初始握手，以及初始拥塞窗口加速，这意味着网页的渲染速度会下降，而多路复用HTTP则避免了这些问题。

然而，它也有一个缺陷，因为多个请求/响应使用相同的TCP链接传输，因此它们都受到数据包丢失的影响（例如因为网络拥塞），即便丢失的数据仅涉及单个请求。这种现象被称为“队头阻塞”。

 

QUIC更进一步为多路复用提供了良好的支持，使得不一样的HTTP流能够依次映射到不一样的QUIC传输流，可是它们仍然共享相同的QUIC链接，所以不须要进行额外的握手，而且共享拥塞状态， QUIC流是独立传递的，所以在大多数状况下，一个流的数据包丢失不会影响其它传输流。

 

这能够大大减小例如渲染完整网页（包括CSS、JavaScript、图片和其它类型资源）所需的时间，特别是在经过具备较高丢包率的高拥塞网络时。

 

这很简单，呃？

 

为了实现这些目标，QUIC协议须要打破许多网络应用程序认为理所固然的一些假设，这可能使QUIC的实现和部署更加困难。

 

QUIC的设计基于UDP数据报来简化部署，同时避免部分网络设备丢弃未知协议数据包的问题，由于绝大多数设备已经支持UDP。这也容许了QUIC在用户空间中实现，例如，浏览器可以实现新的协议功能并发送给用户，而无需等待操做系统更新。

 

然而，尽管预期的目标是避免破坏，但它仍在防止滥用并将数据包路由到正确的端点方面极具挑战性。

 

经过一个NAT问题深刻理解

 

典型的NAT路由器可使用传统的4元组（源IP地址和端口，目的IP地址和端口）跟踪经过它们的TCP链接，并经过观察传输的TCP SYN、ACK和FIN数据包，能够检测到链接的创建和终止。这样能够精确地管理NAT绑定的生命周期和内外部IP地址和端口的关联关系。

可是这在QUIC还不能实现，由于目前部署的NAT路由器不了解QUIC，所以它们一般会回退到默认配置，而后对UDP流处理的不太准确，一般会使用任意的，有时很是短的超时，可能会影响长时间运行的链接。

 

当NAT从新绑定时（例如超时），NAT外部的端点将看到来自与最初创建链接时观察到的源端口不一样的数据包，这使得仅使用4元组没法跟踪链接。

不只仅是NAT！QUIC旨在提供的功能之一称为“链接迁移”，容许QUIC端点随意迁移到不一样IP地址和网络路径的链接。例如，当已知的Wi-Fi网络可用时（例如，当用户进入他们喜欢的咖啡店时），移动客户端可以在蜂窝数据网络和Wi-Fi之间迁移QUIC链接。

 

QUIC试图经过引入链接ID的概念来解决这个问题：一个由QUIC数据包携带的可变长度的opaque blob，可用于标识链接。端点可使用此ID来跟踪它们负责的链接，而无需检查4元组（实际上，可能有多个ID标识相同的链接，例如，为了不在使用链接迁移时连接不一样的路径， 但这种行为是由端点而不是中间设备控制的）。

 

可是，这也给使用anycast寻址和ECMP路由的网络运营商带来了问题，其中单个目标IP地址可能潜在地识别数百甚至数千个服务器。因为这些网络使用的边缘路由器还不知道如何处理QUIC流量，所以可能会发生UDP数据包虽然属于相同的QUIC链接（即具备相同的链接ID）但具备不一样的4元组（因为 NAT从新绑定或链接迁移）被路由到不一样的服务器，从而破坏了链接。

为了解决这个问题，网络运营商可能须要采用更智能的4层负载均衡解决方案，它们能够经过软件实现，而无需接触边缘路由器便可部署（参见Facebook的Katran项目）。

 

QPACK

 

HTTP/2带来的另外一个好处是头部压缩（header compression或HPACK），它容许HTTP/2端点经过从HTTP请求和响应中删除冗余来减小网络传输的数据量。

 

特别是，在其它技术中，HPACK使用以前的HTTP请求（或响应）发送（或接收）的报头动态填充表项，容许端点在新请求（或响应）中引用先前遇到的报头，而不是再次传输。

 

HPACK的动态表须要在编码器（发送HTTP请求或响应的一方）和解码器（接收它们的一方）之间同步，不然解码器将没法解码它接收的内容。

 

对于TCP上的HTTP/2，这种同步是透明的，由于传输层（TCP）负责以与发送它们相同的顺序提供HTTP请求和响应，更新表的指令能够简单地由编码器做为部分请求（或响应）自己，使得编码很是简单。但对于QUIC来讲，这有些复杂。

 

QUIC能够独立地在不一样的流上处理多个HTTP请求（或响应），这意味着虽然就单个流而言它负责按顺序交付数据，可是跨多个流是没有顺序保证的。

 

举例来讲，若是客户端经过QUIC流A发送HTTP请求A，而后经过流B发送请求B，因为网络中的数据包从新排序或丢失，可能会发生服务器在请求A以前接收到请求B，而且请求B被编码引用了来自请求A的头，那么服务器将没法解码它，由于它尚未接收到请求A。

 

在gQUIC协议中，经过简单地在同一gQUIC流上串行化全部HTTP请求和响应头（不是body）来解决这个问题，这意味着不管如何都会按顺序传递报头。这是一个很是简单的方案，能够实现重用大量现有的HTTP/2代码，但另外一方面它增长了QUIC指望减小的队头阻塞。所以，IETF QUIC工做组设计了一组HTTP和QUIC之间（“HTTP/QUIC”）的新映射关系，以及称为“QPACK”的新报头压缩方案。

 

在HTTP/QUIC映射和QPACK规范的最新草案中，每一个HTTP请求/响应交换使用自身的双向QUIC流，所以没有队头阻塞。此外，为了支持QPACK，每端须要额外建立两个单向QUIC流，一个用于向另外一个对等体发送QPACK表更新，另外一个用于确认另外一方接收的更新。这样，QPACK编码器只有在解码器明确确认以后才能使用动态表引用。

 

应对反射攻击

 

基于UDP的协议中的一个常见问题是它们容易受到反射攻击，攻击者经过源IP地址欺骗（它们看起来像是发送自受害者）诱使一些服务器向第三方受害者发送大量数据。

当服务器发送的响应大于收到的请求时，这种攻击很是有效，这种状况咱们称为“放大”。

TCP一般不受这种攻击影响，由于在握手期间发送的初始数据包（SYN，SYN+ACK，...）具备相同的长度，因此它们不具备任何放大的潜力。

 

另外一方面，QUIC的握手是很是不对称的：像TLS同样，在第一次传输中，QUIC服务器一般发送本身的证书链，这可能很是大，而客户端只须要发送几个字节（QUIC包中嵌入的TLS ClientHello消息）。所以，客户端发送的初始QUIC数据包必须填充到特定的最小长度（即便数据包的实际内容要小得多）。然而，这种缓解仍然不够，由于常见的服务器响应会跨多个数据包，可能仍远远大于客户端填充后的数据包。

 

QUIC协议还定义了一种显式的源地址验证机制，服务器先不发送长响应，而是仅发送一个小得多的retry数据包，其中包含一个惟一的加密令牌，而后客户端必须在新的初始数据包中回应它。这样，服务器就更方便确认客户端不会进行源IP地址欺骗（由于它收到了retry数据包），而且能够完成握手。这种缓解方法的缺点是它将初始握手持续时间从单次往返增长到两次。

 

另外一种解决方案经过减小服务器响应下降反射攻击效果，例如采用ECDSA证书（一般比RSA小不少）。此外，也能够尝试经过现成的压缩算法（如zlib和brotli）压缩TLS证书，这也是gQUIC最初引入的特性，但目前在TLS中还不可用。

 

UDP性能

 

QUIC常常出现的问题之一是已经部署的硬件和软件没法识别它。前面介绍了QUIC如未尝试解决路由器等网络中间设备问题，但另外一个可能存在的问题是在QUIC端点上经过UDP发送和接收数据的性能。多年来，不少工做旨在优化TCP，包括在软件（如操做系统）和硬件（如网络接口）中构建卸载功能，但目前这些功能都不适用于UDP。

 

然而，QUIC具有这些功能只是时间问题。以最近在Linux上实现UDP通用分段卸载（Generic Segmentation Offloading）的工做为例，这将容许应用程序在用户空间和内核空间网络堆栈之间聚集和传输多个UDP段转换为单个（或者近似）UDP段。此外，还有在Linux上添加zerocopy套接字支持的例子，这将使应用程序避免将用户空间内存复制到内核空间。

 

结论

 

与HTTP/2和TLS 1.3同样，QUIC将提供多项旨在提升网站性能和安全等方面的新功能，目前IETF工做组计划在今年年末前提供QUIC规范的初版。

 

原文连接：

https://blog.cloudflare.com/the-road-to-quic/

 

https://mp.weixin.qq.com/s/_RAXrlGPeN_3D6dhJFf6Qg

 

做者｜罗成编辑｜小智本文主要介绍 QUIC 协议在腾讯内部及腾讯云上的实践和性能优化。欲了解 QUIC 协议产生的背景和核心特性，可阅读今日二条推文。写在前面

若是你的 App，在不须要任何修改的状况下就能提高 15% 以上的访问速度。特别是弱网络的时候可以提高 20% 以上的访问速度。

若是你的 App，在频繁切换 4G 和 WIFI 网络的状况下，不会断线，不须要重连，用户无任何感知。若是你的 App，既须要 TLS 的安全，也想实现多路复用的强大。

若是你刚刚才据说 HTTP2 是下一代互联网协议，若是你刚刚才关注到 TLS1.3 是一个革命性具备里程碑意义的协议，可是这两个协议却一直在被另外一个更新兴的协议所影响和挑战。

若是这个新兴的协议，它的名字就叫作“快”，而且正在标准化为新一代的互联网传输协议。

你愿意花一点点时间了解这个协议吗？你愿意投入精力去研究这个协议吗？你愿意全力推进业务来使用这个协议吗？

QUIC 在腾讯的实践

腾讯安全云网关 (STGW) 和腾讯云负载均衡器（Cloud Load Balance）在 2017 年 7 月份就已经在服务端上支持了 Quic 协议，在工程实现上也有不少优化点，同时在生产环境中也取得了较好的效果。相比如今几个开源的方案，STGW 的实现主要有以下几个优势：

  1. 高性能。

    • 复用 Nginx 全异步事件驱动框架。

    • 私钥代理计算集群加速签名计算。

    • 全局缓存提速，减小计算量的同时，提高访问速度。

  2. 强大的功能。

    • 支持 Nginx 现有所有模块指令，丰富的第三方模块。

    • 复用 Nginx 模块框架，很是灵活地新增第三方功能。

  3. 稳定性。

    • 代码彻底自主可控。

    • 正在经受腾讯亿万级并发流量的考验。

同时咱们也在腾讯不少业务包括 QQ 空间、WEB 游戏页面、腾讯云 CLB 上灰度支持了 QUIC 协议。详细的收益数据能够参考第 6 章。

QUIC 线下测试方案

在决定使用 QUIC 协议以前，咱们须要对 QUIC 协议的特性及性能作一个全面的测试，如何测试呢？这里简单说一下测试方案。

须要特别说明的测试是在 2016 年末进行的，目前全部域名已经失效，没法再进行测试。

页面构造

根据 httparchive.org 的统计，构造了以下页面：

 

测试环境

手机：华为 mate9 

User-Agent：MHA-AL00 Build/HUAWEIMHA-AL00) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Mobile Safari/537.36

操做系统：Android 7.0

服务端 QUIC 程序：caddy 0.9.4

 

网站和客户端分布以下：

 

QUIC 测试框架

  • ①表示客户端主动发起的用户请求。

  • ②表示从 html 里发出的资源请求。

  • ③表示数据上报请求。

测试流程

整个测试流程经过 python 脚本和 adb shell 工具自动化进行。其中移动端和 PC 端的控制流程有所区别。分别简介以下：

 移动端测试流程

准备事项：

  1. 打开手机的 usb 调试选项。

  2. 在 PC 端安装 adb。

  3. 在 PC 上经过 USB 链接手机，确保可以经过 adb  devices 命令发现设备。

  4. 在服务端配置 cache-control: no-cache, no-store。禁止客户端缓存。

自动化测试流程以下：

  1. 启动 android chrome。

  2. 访问 https://www.helloworlds.cc。

  3. 待页面加载完后会触发 onload 事件，将各个时间点上报。

 PC 端流程

PC 端不须要 adb，使用 webbrowser 模块控制 chrome 完成便可。

测试结论

因为公司内网的 WIFI 环境不稳定，屡次测试发现数据跳动较大，4G 环境下的数据更加稳定可靠，因此主要结论参考 4G 网络下的数据。

QUIC 的优点很是明显，即便在元素比较少（12 个元素）的状况下，相比 HTTP 也能提高 9%，相比 HTTP2 提高 42%，相比 HTTPS 提高 52%。

在页面元素增多的状况下，QUIC 的优点就更加明显，相比 HTTP 提高 36%，相比 HTTP2 提高 47%，相比 HTTPS 提高 64%。

QUIC 性能优化

QUIC 的特性虽然比较先进，可是实现起来却很是复杂，在工程实现方面也有不少优化的空间。好比如何提高 0RTT 成功率，减小服务端的 CPU 消耗量，实现链接迁移和动态的拥塞控制算法等。

提高 0RTT 成功率

安全传输层虽然可以实现 0RTT，优点很是明显。但问题是，不是每一次链接都能实现 0RTT，对于咱们的客户端和服务端来说，如何最大程度地提高 0RTT 的成功率？

0RTT 能实现的关键是 ServerConfig。就像 TLS session resume 实现的关键是 session id 或者 session ticket 同样。

ServerConfig 到达服务端后，咱们根据 ServerConfig ID 查找本地内存，若是找到了，即认为这个数据是可信的，可以完成 0RTT 握手。

可是会有两个问题：

  1. 进程间 ID 数据没法共享。

  2. 多台服务器间的 ID 数据没法共享。

明确了问题，那工程层面就须要实现多进程共享及分布式多集群的 ID 共享。

 

SeverConfig Cache 集群

Stgw 在生成 ServerConfig ID 和内容时，会存储到全局的 Cache 集群。用户握手请求落到任意一台 STGW 机器，从全局 Cache 集群都能找到相应的内容，实现 0RTT 握手。

加密性能的优化 签名计算

QUIC 实现 0RTT 的前提是 ServerConfig 这个内容签名和校验都没有问题。因为 ServerConfig 涉及到 RSA 签名或者 ECDSA 签名，很是消耗咱们的 CPU 资源。根据以前的测试数据，RSA 私钥签名计算会下降 90% 的性能。

那如何优化呢？使用 RSA 或者 ECDSA 异步代理计算。核心思路也是三点：

  1. 算法分离。剥离私钥计算部分，不让这个过程占用本地 CPU 资源。

  2. 异步执行。算法剥离和执行异步的，上层服务不须要同步等待这个计算过程的完成。

  3. 并行计算。咱们使用配置了专用硬件的私钥计算集群来完成私钥计算。

架构以下图所示：

 

签名代理计算

 对称加密的优化

相比非对称密钥交换算法来说，对称加密算法的性能很是卓越（好 1 到 2 个数量级），可是若是应用层传输内容较大的话，特别是移动端的 CPU 计算能力较弱，对称加密算法对性能的影响也不容忽视。

 

表格 1 经常使用对称加密算法性能比较

如何优化呢？经过异步代理的方式显然不可能。缘由是：

会极大下降用户访问速度。因为应用层的每个字节都须要对称加解密，使用异步的方式实现会严重下降加解密的实时性。

那有没有同步的优化方式呢？有。相似 SSL 硬件加速卡，intel 针对 AES 算法实现硬件加速，并将它集成到了 CPU 指令里。

AES-NI 指令

AES-NI 是 intel 推出的针对 AES 对称加密算法进行优化的一系列指令，经过硬件计算实现计算速度的提高。

如何测试 AES-NI 的性能呢？

经过环境变量

aes-ni: OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-gcm 或者在代码里将 crypto/evp/e_aes.c # define AESNI_CAPABLE (OPENSSL_ia32cap_P[1]&(1<<(57-32))) 进行设置。

aesni 对性能的提高约 20%， 由 4.3W 提高到 5.1W。

这里须要注意的是，若是须要单独使用 openssl 的 API 进行 AES 对称加解密，最好使用 aes evp API，这样才会默认开启 AES-NI 指令。

chacha20-poly1305

chacha20-poly1305 是由 Dan Bernstein 发明，而且由 google 推出的一种带身份认证的对称加密算法。其中 chacha20 是指对称加密算法，poly1305 指身份认证算法。这个算法是对没有 AES 硬件加速功能的移动平台的补充，好比 ARM 芯片。

从 google 公布的数据来看，chacha20-poly1305 可以提高 30% 以上的加解密性能，节省移动端耗电量。固然，若是手机端支持 AES-NI 指令的话，chacha20 就没有优点了。

Openssl 在 1.1.0 版本中正式支持了 chacha20-poly1305。

链接迁移 (Connection Migration) 的实现

那 STGW 服务端如何实现的呢？咱们在 CLB 四层转发层面实现了根据 ID 进行哈希的负载均衡算法，保证将相同 ID 的 QUIC 请求落到相同的 CLB7 层集群上，在 CLB7 上，咱们又会优先根据 ID 进行处理。

图示以下：

 

QUIC 链接迁移

如上图所述，客户端最开始使用 4G 移动网络访问业务，源 IP 假设为 IP1，整个访问流程使用蓝色线条标识。

当用户进入 WIFI 网络时，源 IP 发生了变化，从 IP1 切换到了 IP2，整个访问流程使用绿色线条标识。因为接入的 CLB4 有可能发生变化，但整个 CLB 集群统一使用 QUIC Connection ID 调度，只要 QUIC 链接的 ID 没有发生变化，可以将该请求调度到相同的 CLB7 层机器上。

同一台 CLB7 保存了相同的 Stream 及 Connection 处理上下文，可以将该请求继续调度到相同的业务 RS 机器。

整个网络和 IP 切换过程，对于用户和业务来说，没有任何感知。

动态的流量控制和拥塞控制

STGW 在链接和 Stream 级别设置了不一样的窗口数。

最重要的是，咱们能够在内存不足或者上游处理性能出现问题时，经过流量控制来限制传输速率，保障服务可用性。

性能统计

STGW 针对 QUIC 的线上使用状况进行了不少的变量统计和分析，包括 0RTT 握手成功率，握手时间，密码套件使用分布，QUIC 协议版本，stream 并发数量等。

这些统计变量可以为咱们的协议优化提供更加精细的数据支撑。

QUIC 线上灰度数据

QUIC 目前已经在 STGW 上线运行。咱们针对腾讯几个重要域名（包括 QQ 黄钻页面，游戏页面）进行了灰度实验。

 

Qzone QUIC 页面

如上图所示，图中红色箭头指向的绿色标识表示该页面使用了 QUIC 协议。

灰度实验的效果也很是明显，其中 quic 请求的首字节时间 (rspStart) 比 http2 平均减小 326ms, 性能提高约 25%; 这主要得益于 quic 的 0RTT 和 1RTT 握手时间，可以更早的发出请求。

此外 quic 请求发出的时间 (reqStart) 比 h2 平均减小 250ms; 另外 quic 请求页面加载完成的时间 (loadEnd) 平均减小 2s，因为总体页面比较复杂, 不少其它的资源加载阻塞，致使总体加载完成的时间比较长约 9s，性能提高比例约 22%。

上述数据有两个问题，仅供参考：

  1. 因为咱们的页面并无所有改形成 QUIC 协议，因此性能数据应该还能够进一步提高。

  2. 每一个业务的页面构成不同，提高的性能数据也会有差异。

CLB-QUIC-DEMO

前面提到的 QUIC 实践和优化都是针对服务端。为了方便广大开发者进一步了解 QUIC 在客户端的使用，咱们提供了一个安卓客户端的 DEMO，仅供参考。

DEMO 已经在 github 上开源，地址以下：

https://github.com/tencentyun/clb-quic-demo

DEMO 的主要目的有两个：

  1. 简单说明一下在客户端使用 QUIC。

  2. 简单对比 HTTP2 和 QUIC 的性能差异。

 

若是有用户想使用 QUIC 协议，客户端作一下改造，服务端直接使用腾讯云 CLB 负载均衡器就能实现了。

如前所述，CLB 在协议计算性能和访问速度、安全性能方面，作了很是多优化。

结    论

QUIC 协议很是复杂，由于它作了太多事情：

为了实现传输的可靠性，它基本上实现而且改进了整个 TCP 协议的功能，包括序列号，重传，拥塞控制，流量控制等。

为了实现传输的安全性，它又完全重构了 TLS 协议，包括证书压缩，握手消息，0RTT 等。虽而后续可能会采用 TLS1.3 协议，可是事实上是 QUIC 推进了 TLS1.3 的发展。

为了实现传输的并发性，它又实现了 HTTP2 的大部分特性，包括多路复用，流量控制等。

虽然如此复杂，可是 QUIC 做为一个新兴的协议，已经展示了很是强大的生命力和广阔的前景。

目前国内外除了 Google 大规模采用外，还鲜有其余互联网公司使用。STGW 做为腾讯的安全云网关，咱们有责任，有义务对业界先进的标准协议提供支持和优化。同时腾讯云也是国内第一家支持 QUIC 协议的云厂商，由于这个协议能切实改善客户端的访问速度和终端用户体验。

咱们不只在服务端实现了 Quic 协议的支持，优化了 QUIC 协议方面的性能问题，同时也但愿经过本身一些经验的分享，推进 QUIC 协议的发展，构造一个更加安全更加快速的互联网世界。

Let’Quic,  Make Web Faster。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程