一文带你了解QUIC协议

描述

当通过网络传输数据时,一种新的协议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)

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

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

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

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

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

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

HTTP/1.1(1997)

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)的问题。如图所示:

服务器

头部压缩:使用 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 使用相同的语法和语义结构,并且适用于同一请求/响应方法、状态码和协议字段。此外,两者都使用设计相似的头部压缩算法(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协议,客户端和服务器之间交换了三种类型的数据包,如下图所示:

服务器

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

翻译 / Alex  技术Review / 袁荣喜 原文链接: https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2021/07/16/road_to_quic-DGa5.html 特别说明:原作者Anubhab Sahu已授权本文的翻译与发布,特此感谢。

编辑:jq

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分