当通过网络传输数据时,一种新的协议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
-
服务器
+关注
关注
12文章
9153浏览量
85407 -
TCP
+关注
关注
8文章
1353浏览量
79068 -
UDP
+关注
关注
0文章
325浏览量
33934 -
Quic
+关注
关注
0文章
25浏览量
7298
原文标题:QUIC协议的演进之路
文章出处:【微信号:xunwei201508,微信公众号:讯维官方公众号】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论