QUIC协议的演进之路

LiveVideoStack 2021年8月5日

当通过网络传输数据时,一种新的协议QUIC(Quick UDP Internet Connection,快速UDP互联网连接)正在成为FAANG的默认选择。本篇文章描述了QUIC协议是如何克服其他版本HTTP的限制脱颖而出的。


FAANG是美国市场上五大最受欢迎和表现最佳的科技股的首字母缩写,即Facebook、Apple、Amazon、Netflix和Google。


HTTP的演进


HTTP属于应用层传输协议,运行于TCP/IP之上。现在它已成为万维网中数据交换的基础。HTTP包括4个稳定版本:HTTP/0.9、HTTP/1.0、HTTP/1.1 和HTTP/2。HTTP/3于2018年首次提出,目前已获得全球2/3 web浏览器的支持。


HTTP/0.9(1991)


HTTP/0.9是HTTP的第一个版本,用作W3C的底层通信协议。它是一个非常简单的客户端-服务器、请求-响应、使用Telnet的协议,只支持GET命令(作为请求方法)和超文本协议(作为响应类型)。该协议不包含HTTP消息头,且发送响应后,连接会立即断开。


HTTP/1.0(1996)


QUIC协议的演进之路


HTTP/0.9极其简单,且使用非常受限。新的HTTP版本HTTP/1.0引入了很多新特性,使它更加通用。这些新的特性包括:


  • 每次HTTP 请求/响应都会重新建立TCP连接

  • 添加了对 POST 和 HEAD 方法的支持

  • 协议头带有版本号、协议类型、状态码字段

  • 响应类型:超文本、脚本、媒体、样式表

  • 支持keep-alive连接,但默认情况下它是“关闭”的


HTTP/1.1(1997)

QUIC协议的演进之路


HTTP/1.0的主要缺陷是:它在每次请求\响应时都要建立新的TCP连接。这种做法非常耗时,且影响客户端和服务器的性能。HTTP/1.1的出现解决了这一问题:


  • 单个TCP连接上可以传送多个HTTP请求和响应

  • 添加了对 PUT、DELETE、TRACE、OPTIONS 方法的支持

  • 默认持久连接


HTTP/2(2015)


随着流媒体内容的增加,网站也开始变得越来越复杂。为了满足这种需求,HTTP/1.1的功能不断扩展:首次支持多个TCP连接,并试验性地引入了管道机制(pipelining),即在同一个TCP连接里面,客户端可以同时发送多个请求但扩展不可能无止境,最终需要采用一个新的协议,于是HTTP/2出现了,该协议包括如下重大改进:


  • 多路复用:这是HTTP/2的一个特性,允许同时通过单个TCP连接发起多重请求-响应消息。每次HTTP请求-响应都被分割成二进制帧,客户端和服务器都以二进制帧为基本单位发送消息(请求和响应)。通过多路复用,客户端无需再等待上一个请求完成就可以发送多重请求。这样,HTTP/2便解决了HTTP队头阻塞(HoL)的问题。如图所示:


QUIC协议的演进之路


  • 头部压缩:使用 HPACK 压缩消息头

  • 非阻塞下载

  • 支持服务器推送

  • 采用二进制分帧,不再是纯文本

  • 解决了队头阻塞问题


HTTP/3(2018)


通过多路复用,HTTP/2解决了队头阻塞问题。但如果TCP流中出现了丢包,根据TCP的拥塞控制机制,其他数据流就只能等待丢包被重新发送和接收。所以,TCP的队头阻塞问题在HTTP/2中依然存在。


HTTP/3通过使用基于UDP的传输协议QUIC解决了这一问题。


HTTP/3是自HTTP/2之后最新且最主要的HTTP版本。因为HTTP/3本身就是为QUIC协议设计的,所以也被描述为基于QUIC的HTTP/2。HTTP/3的目标是通过使用谷歌的QUIC协议提供快速、可靠安全的网络连接。HTTP/3包括以下特性:


  • 使用基于UDP的QUIC作为传输协议

  • 解决了TCP队头阻塞问题

  • 使用QPACK头部压缩机制

  • 提供更快页面加载时间


HTTP/2 VS HTTP/3


下图展示了HTTP/2和HTTP/3两者的对比:

QUIC协议的演进之路


相同点:


HTTP/2 和 HTTP/3 使用相同的语法和语义结构,并且适用于同一请求/响应方法、状态码和协议字段。此外,两者都使用设计相似的头部压缩算法(HPACK 和 QPACK)。


不同点:

特性

HTTP/2

HTTP/3

传输层协议

TCP

基于UDP的QUIC

头部压缩算法

HPACK

QPACK

队头阻塞问题

解决HTTP队头阻塞

同时解决HTTP和TCP 队头阻塞

握手协议

TCP + TLS

QUIC

加密协商

可通过TLS(默认版本为1.2,后续版本可选)与ALPN协议扩展进行协商

使用用于QUIC协议的Alt-Svc(以 TLS 1.3 作为 TLS 的最低版本)

握手时间

因为需要TCP和TLS 握手,所以更慢

QUIC协议直接处理数据流,所以更快

QUIC是一种新的多路传输层网络协议标准,建立在 UDP 之上。QUIC的主要目标是通过减少页面加载时间提升用户体验,并提高HTTPS的传输性能。它在本质上是TCP+TLS+HTTP/2。


设计HTTP/3的目的就是要充分利用 QUIC 的优势。QUIC 协议本身可以处理数据流,所以排除了 TCP 队头阻塞问题。


QUIC 的一些关键特性包括:


  • 基于UDP

  • 使用没有队头阻塞的连接复用

  • 重构TCP的关键机制(连接复用、连接建立、拥塞控制、可靠性),并成为可靠的传输协议


交换数据包


对于典型的QUIC协议,客户端和服务器之间交换了三种类型的数据包,如下图所示:

QUIC协议的演进之路


QUIC协议的演进之路


QUIC连接建立和安全的净荷包


1. 安全的首包

首先,客户端在一个CRYPTO 帧中传输包含TLS 1.3 Client Hello的首包。Client Hello包含不同类型的的扩展项,如目标服务器的SNI(Server Name Indication,服务器名称指示 )、QUIC 传输参数、压缩证书等,以及客户端支持的压缩方法和不同的加密套件。


如果服务器接受QUIC和TLS 1.3参数,它也会在CRYPTO帧中发送包含对客户端首包确认信息和TLS 1.3 Server Hello的首包信息。Server Hello中包含被服务器接收的加密套件和不同的扩展(如密钥共享、支持的版本等)。在客户端接收到 Server Hello后,会向服务器发送一个ACK确认包。


这三个首包都可能包含一个填充帧,以根据需要增加数据包的大小。


2. 握手包

客户端和服务器之间的首包被交换以后,服务器会发送一个握手数据包,其中包含余下的服务器端消息,如证书、与服务器身份验证相关的加密扩展。客户端会验证这些证书,然后QUIC 握手以客户端发送的握手消息结束。


3. 安全的净荷包

一旦安全的QUIC连接建立,客户端与服务器之间的信息便可以安全传输。


QUIC 0-RTT


为了缩短建立新连接的时间,QUIC采用0-RTT。在这里,如果客户端之前使用1-RTT连接到服务器,则服务器必须存储与流量控制相关的传输参数的副本,如 initial_max_data、
initial_max_stream_data_bidi_local 等。


下一次,在QUIC 0-RTT模式中,客户端立即开始与服务器的数据传输,不需要等待握手完成。


然而,0-RTT也有设计上的缺陷:允许重放攻击


我们为什么要用QUIC?


传统的TCP协议是建立在操作系统层和中间路由模块之上实现的,它的握手阶段信息很容易被这些中间模块篡改而变得不安全。


但QUIC协议是在UDP之上的用户级(如浏览器)中实现的,因此它更加灵活、对用户更友好,并且能够在短时间内支持更多设备。


在 QUIC 中,传输相关的信息被不同的保护层加密,握手包在传输链路上不容易被识别和修改。因此它提供了更安全的网络数据传输。


延伸阅读:

QUIC Version 1 (RFC 9000) 作为标准化版本现已发布

一文看懂WebTransport

QUIC助力Snapchat提升用户体验

新一代直播传输协议SRT

三十年TCP与七年QUIC 谁才是未来?


翻译 / Alex

技术Review / 袁荣喜

原文链接:

https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2021/07/16/road_to_quic-DGa5.html

特别说明:原作者Anubhab Sahu已授权本文的翻译与发布,特此感谢。


还可输入800
全部评论
作者介绍

LiveVideoStack

音视频技术社区

文章

粉丝

视频

阅读排行
  • 2周
  • 4周
  • 16周
热门视频

用互联网发展视角看元宇宙创新

龙明康/AI工程院常务副院长

单目3D人体姿态估计的挑战和探索

宋波/人工智能高级工程师