快速UDP网络连接

title: 背景.
content: 传输控制协议 (TCP) 旨在提供一个在两个端点之间发送数据流的接口。将数据发送到TCP系统可以确保数据以完全相同的形式传递到另一端,否则连接将提示存在错误。  为此,TCP将数据分解成网络数据包,并在每个数据包中添加少量数据。该附加数据包括用于检测丢失或无序传输的数据包的序列号,以及允许检测数据包数据中的错误的校验和。当任何一个问题出现时,TCP使用自动重复请求(ARQ)来告诉发送者重新发送丢失或损坏的数据包。  在大多数实现中,TCP会将连接上的任何错误视为阻塞,停止进一步传输,直到错误得到解决或连接被视为失败。如果使用单个连接来发送多个数据流,就像在HTTP/2协议中那样,所有这些数据流都会被阻止,尽管其中只有一个可能有问题。例如,如果在下载用于收藏夹图标的GIF图像时出现一个错误,页面的其余部分将等待问题得到解决。  由于TCP系统被设计成看起来像一个“数据管道”,或流,它故意包含很少的对它传输的数据的理解。如果数据有额外的要求,如使用TLS加密,这必须由运行在传输控制协议之上的系统设置,使用传输控制协议与连接另一端的类似软件进行通信。每种设置任务都需要自己的握手过程。这通常需要多次往返请求和响应,直到建立连接。由于长距离通信的固有延迟,这会给整个传输增加大量开销。
title: 介绍.
content: QUIC旨在提供几乎等同于TCP连接的可靠性,但延迟大大减少。它主要通过两个理解HTTP流量的行为来实现这一点。  第一个变化是在连接建立期间大大减少。由于大多数HTTP连接都需要TLS,因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。 当客户端打开连接时,服务器响应的数据包包括将来的数据包加密所需的数据。这消除了TCP上的先连接并通过附加数据包协商安全协议的需要。其他协议可以以相同的方式进行服务,并将多个步骤组合到一个请求中。 然后,这些数据既可用于初始设置中的后续请求,也可用于未来的请求。  QUIC使用UDP协议作为其基础,不包括丢失恢复。相反,每个QUIC流是单独控制的,并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误,协议栈仍然可以独立地继续为其他流提供服务。 这在提高易出错链路的性能方面非常有用,因为在大多数情况下TCP协议通知数据包丢失或损坏之前可能会收到大量的正常数据,但是在纠正错误之前其他的正常请求都会等待甚至重发。 QUIC在修复单个流时可以自由处理其他数据,也就是说即使一个请求发生了错误也不会影响到其他的请求。  QUIC包括许多其他更普通的更改,这些更改也可以优化整体延迟和吞吐量。例如,每个数据包是单独加密的,因此加密数据时不需要等待部分数据包。 在TCP下通常不可能这样做,其中加密记录在字节流中,并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商,但QUIC旨在通过单个握手过程完成这些。  QUIC的另一个目标是提高网络切换期间的性能,例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。 当这发生在TCP上时,一个冗长的过程开始了:每个现有连接一个接一个地,然后根据需要重新建立。期间存在较高延迟,因为新连接需要等待旧连接超时后才会建立。 为解决此问题,QUIC包含一个连接标识符,该标识符唯一地标识客户端与服务器之间的连接,而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新建立连接,因为即使用户的IP地址发生变化,原始连接ID仍然有效。  QUIC在中实现,而不是在操作系统内核中实现。当数据在应用程序之间移动时,这通常会由于上下文切换而调用额外的开销。 但是在QUIC下协议栈旨在由单个应用程序使用,每个应用程序使用QUIC在UDP上托管自己的连接。最终差异可能非常小,因为整个HTTP/2堆栈的大部分已经存在于应用程序(或更常见的库)中。 将剩余部分放在这些库中,基本上是纠错,对HTTP/2堆栈的大小或整体复杂性几乎没有影响。  QUIC允许更容易地进行未来更改,因为它不需要更改内核就可以进行更新。 QUIC的长期目标之一是添加前向纠错和改进的拥塞控制。  关于从TCP迁移到UDP的一个问题是TCP被广泛采用,并且互联网基础设施中的许多中间设备被调整为UDP速率限制甚至阻止UDP。 Google进行了一些探索性实验来描述这一点,发现只有少数连接存在此问题。所以Chromium的网络堆栈同时打开QUIC和传统TCP连接,并在QUIC连接失败时以零延迟回退到TCP连接。
title: gQUIC与iQUIC.
content: 由Google创建并以QUIC的名称提交给IETF的协议与随后在IETF中创建的QUIC完全不同(尽管名称相同)。 最初的Google QUIC(也称为gQUIC)严格来说是通过加密UDP发送HTTP/2帧的协议,而IETF创建的QUIC是通用传输协议,也就是说HTTP以外的其他协议(如SMTP、DNS、SSH、Telnet、NTP)也可以使用它。重要的是要注意并记住其差异。 自2012年以来,Google在其服务及Chrome中使用的QUIC版本(直到2019年2月)为Google QUIC。随着时间的推移,它正在逐渐变得类似于IETF QUIC(也称为iQUIC)。
title: 流量控制.
title: Google BBR.
content: BBR 算法主要出发点是,数据包丢失可能并不意味着网络拥塞。例如,一瞬间的无线电干扰,数据包就可能会丢失。Cubic 和其他基于拥塞的算法不区分这种虚假的损失和真正的拥塞,在两种情况下都降低了它们的发送速率。另一方面,BBR不那么容易受到惊吓。  因此,即使面对次优的网络条件,BBR也能提供持续的吞吐量性能。
title: 实现.
title: 客户端.
content: Google Chrome于2012年开始开发QUIC协议并且于Chromium版本 29 (2013年8月20日释出) 发布。QUIC协议在当前Chrome版本中被默认开启,活跃的会话列表在codice_1中可见。
title: 服务端.
content: 截至2017年,有三种活跃维护中的实现。谷歌的服务器及谷歌发布的原型服务器使用Go语言编写的quic-go及Caddy的试验性QUIC支持。在2017年7月11日,LiteSpeed科技正式在他们的负载均衡(WebADC)及 LiteSpeed 服务器中支持QUIC。截止 17 年 12 月, 97.5%的使用 QUIC 协议的网站在 LiteSpeed 服务器中运行。  另有几种不再维护的社区产品,基于Chromium实现并且减少使用依赖的libquic、提供libquic的Go语言绑定的goquic、打包为Docker镜像的用来转换为普通HTTP请求的反向代理quic-reverse-proxy。

Summary: 快速UDP网络连接(英语:Quick UDP Internet Connections,缩写:QUIC)是一种实验性的网络传输协定。由Google开发,在2013年实作。QUIC使用UDP协议,它在两个端点间建立连线,且支援多路复用连线。在设计之初,QUIC希望能够提供基于TLS/DTLS的网络安全保护,减少资料传输及建立连线时的延迟时间,双向控制带宽,以避免网络拥塞。Google希望使用这个协定来取代HTTPS/HTTP协定,使网页传输速度加快,计划将QUIC提交至因特网工程任务小组(IETF),让它成为下一代的正式网络规范。2015年6月,QUIC的网络草案被正式提交至互联网工程任务组。2018 年 10 月,互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP()重命名为HTTP/3以为确立下一代规范做准备。

QUIC: QUIC (pronounced 'quick') is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described to the IETF. While still an Internet Draft, QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. Microsoft Edge and Firefox support it, even if not enabled by default, as does Safari Technology Preview.