QUIC(Quick UDP Internet Connection)是Google提出的一个基于UDP的传输协议,因其高效的传输效率和多路并发的能力,已经成为下一代互联网协议HTTP/3的底层传输协议。除了应用于Web领域,它的优势同样适用于一些通用的需要低延迟、高吞吐特性的传输场景。本文从QUIC的由来和优势出发,分享实际项目中需要考虑的问题和解决思路,通过测试对比QUIC和TCP的实际传输能力,希望有助于大家理解和实践QUIC协议。
PART 01 为什么需要QUIC?
众所周知,HTTP从最初的HTTP/0.9,经历了HTTP/1.x,HTTP/2到最新的HTTP/3这几个大的更新版本。在HTTP/3版本之前,HTTP底层都是用TCP传输数据,而伴随着移动互联网的发展,网络交互场景越来越丰富并要求及时性,传统TCP固有的性能瓶颈越来越不能满足需求,原因有以下几点:
建立连接的握手延迟大
HTTPS包含两个握手:1)TCP三次握手,1个RTT;2)TLS握手,2个RTT。完整握手总共需要3个RTT,对于直播等需要首帧秒开场景,握手延迟太大。
多路复用的队首阻塞
以HTTP/2多路复用为例,多个数据请求作为不同的流,共用一条TCP连接发送,所有的流应用层都必须按序处理。若某个流的数据丢失,后面其他流的数据都会被阻塞,直到丢失的流数据重传完成其他流才能被继续传输。即使接收端已经收到之后流的数据包,HTTP协议也不会通知应用层去处理。
TCP协议的更新滞后
TCP协议是实现在操作系统内核内,但是用户端的操作系统版本升级非常困难,很多老旧的系统像WindowsXP还有大量用户使用,因此TCP协议的一些更新很难被快速推广。
正是考虑到以上的这些问题,QUIC在应用层之上基于UDP实现丢包恢复,拥塞控制,加解密,多路复用等功能,既能优化握手延迟,同时又完全解决内核协议更新滞后问题。
PART 02 QUIC的优势
这里列举下QUIC的主要优势。