本页使用了标题或全文手工转换

快速UDP网络连接

维基百科,自由的百科全书
(重定向自QUIC
跳到导航 跳到搜索

快速UDP網路連接(英語:Quick UDP Internet Connections,缩写:QUIC[1])是一種實驗性的網路傳輸協定,位于OSI模型傳輸層。由Google開發,在2013年實作。QUIC使用UDP协议,它在兩個端點間建立連線,且支援多路複用連線。[2]在設計之初,QUIC希望能夠提供等同於SSL/TLS層級的網路安全保護,減少資料傳輸及建立連線時的延遲時間,雙向控制頻寬,以避免網路擁塞。Google希望使用這個協定來取代TCP協定,使網頁傳輸速度加快,計劃將QUIC提交至網際網路工程任務小組(IETF),讓它成為下一代的正式網路規範[3]。2015 年 6 月,QUIC的网络草案英语Internet Draft被正式提交至互联网工程任务组[4]2018 年 10 月,互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP (英語:HTTP over QUIC) 重命名为 HTTP/3 以为确立下一代规范做准备。[5]

介绍[编辑]

QUIC旨在提供几乎等同于TCP连接的可靠性,但延迟大大减少。它主要通过两个理解HTTP流量的行为来实现这一点。[6]

第一个变化是在连接建立期间大大减少开销英语Overhead (computing)。由于大多数HTTP连接都需要TLS,因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。 当客户端打开连接时,服务器响应的数据包包括将来的数据包加密所需的数据。这消除了TCP上的先连接并通过附加数据包协商安全协议的需要。其他协议可以以相同的方式进行服务,并将多个步骤组合到一个请求中。 然后,这些数据既可用于初始设置中的后续请求,也可用于未来的请求。[6]

QUIC使用UDP协议作为其基础,不包括丢失恢复。相反,每个QUIC流是单独控制的,并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误,协议栈仍然可以独立地继续为其他流提供服务。 这在提高易出错链路的性能方面非常有用,因为在大多数情况下TCP协议通知数据包丢失或损坏之前可能会收到大量的正常数据,但是在纠正错误之前其他的正常请求都会等待甚至重发。 QUIC在修复单个流时可以自由处理其他数据,也就是说即使一个请求发生了错误也不会影响到其他的请求。[7]

QUIC包括许多其他更普通的更改,这些更改也可以优化整体延迟和吞吐量。例如,每个数据包是单独加密的,因此加密数据时不需要等待部分数据包。 在TCP下通常不可能这样做,其中加密记录在字节流中,并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商,但QUIC旨在通过单个握手过程完成这些。[8]

QUIC的另一个目标是提高网络切换期间的性能,例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。 当这发生在TCP上时,一个冗长的过程开始了:每个现有连接一个接一个地超时英语Timeout (computing),然后根据需要重新建立。期间存在较高延迟,因为新连接需要等待旧连接超时后才会建立。 为解决此问题,QUIC包含一个连接标识符,该标识符唯一地标识客户端与服务器之间的连接,而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新建立连接,因为即使用户的IP地址发生变化,原始连接ID仍然有效。[9]

QUIC在应用程序空间英语Application domain中实现,而不是在操作系统内核中实现。当数据在应用程序之间移动时,这通常会由于上下文切换而调用额外的开销。 但是在QUIC下协议栈旨在由单个应用程序使用,每个应用程序使用QUIC在UDP上托管自己的连接。最终差异可能非常小,因为整个HTTP/2堆栈的大部分已经存在于应用程序(或更常见的库)中。 将剩余部分放在这些库中,基本上是纠错,对HTTP/2堆栈的大小或整体复杂性几乎没有影响。[8]

QUIC允许更容易地进行未来更改,因为它不需要更改内核就可以进行更新。 QUIC的长期目标之一是添加前向纠错和改进的拥塞控制[9]

关于从TCP迁移到UDP的一个问题是TCP被广泛采用,并且互联网基础设施中的许多中间设备被调整为UDP速率限制甚至阻止UDP。 Google进行了一些探索性实验来描述这一点,发现只有少数连接存在此问题。[10]所以Chromium的网络堆栈同时打开QUIC和传统TCP连接,并在QUIC连接失败时以零延迟回退到TCP连接。[11]

gQUIC与iQUIC[编辑]

由Google创建并以QUIC的名称提交给IETF的协议与随后在IETF中创建的QUIC完全不同(尽管名称相同)。 最初的Google QUIC(也称为gQUIC)严格来说是通过加密UDP发送HTTP/2帧的协议,而IETF创建的QUIC是通用传输协议,也就是说HTTP以外的其他协议(如SMTPDNSSSHTelnetNTP)也可以使用它。重要的是要注意并记住其差异。 自2012年以来,Google在其服务及Chrome中使用的QUIC版本(直到2019年2月)为Google QUIC。随着时间的推移,它正在逐渐变得类似于IETF QUIC(也称为iQUIC)。

实现[编辑]

客户端[编辑]

Google Chrome于2012年开始开发QUIC协议并且于Chromium版本 29 (2013年8月20日释出) 发布。QUIC协议在当前Chrome版本中被默认开启,活跃的会话列表在chrome://net-internals/#quic中可见。

服务端[编辑]

截至2017年,有三种活跃维护中的实现。谷歌的服务器及谷歌发布的原型服务器使用Go语言编写的quic-goCaddy的试验性QUIC支持。在2017年7月11日,LiteSpeed科技正式在他们的负载均衡WebADC)及 LiteSpeed 服务器中支持QUIC。截止 17 年 12 月, 97.5%的使用 QUIC 协议的网站在 LiteSpeed 服务器中运行[12]

另有几种不再维护的社区产品,基于Chromium实现并且减少使用依赖的libquic、提供libquic的Go语言绑定的goquic、打包为Docker镜像的用来转换为普通HTTP请求的反向代理quic-reverse-proxy

参见[编辑]

参考资料[编辑]

  1. ^ Innovating Transport with QUIC: Design Approaches and Research Challenges,2017
  2. ^ MULTIPLEXED STREAM TRANSPORT OVER UDP,Google
  3. ^ Google推動QUIC新協定,讓網頁瀏覽、影片播放更快速,T客邦,2015-04-22
  4. ^ I-D Action: draft-tsvwg-quic-protocol-00.txt. www.ietf.org. [2018-12-10]. 
  5. ^ Cimpanu, Catalin. HTTP-over-QUIC to be renamed HTTP/3. ZDNet. [2018-12-10] (英语). 
  6. ^ 6.0 6.1 Bright, Peter. The next version of HTTP won’t be using TCP. Arstechnica. 12 November 2018. 
  7. ^ Behr, Michael; Swett, Ian. Introducing QUIC support for HTTPS load balancing. Google Cloud Platform Blog. Google. [16 June 2018]. 
  8. ^ 8.0 8.1 QUIC: IETF-88 TSV Area Presentation (PDF). Jim Roskind, Google. [2013-11-07]. 
  9. ^ 9.0 9.1 QUIC at 10,000 feet. Chromium. 
  10. ^ QUIC: Design Document and Specification Rationale. Jim Roskind, Chromium Contributor. 
  11. ^ Applicability of the QUIC Transport Protocol. IETF Network Working Group. 22 October 2018. 
  12. ^ Distribution of Web Servers among websites that use QUIC. w3techs.com. [2018-12-10]. 

外部連結[编辑]