当前位置: 首页 > news >正文

QUIC——UDP实现可靠性传输

首先我们要知道TCP存在什么样的痛点问题

  • TCP的升级很困难
  • TCP建立连接的延迟
  • 网络迁移需要重新建立连接
  • TCP存在队头阻塞问题

QUIC就是为了解决以上的问题而诞生了, 下面我会介绍QUIC的一些特性和原理

QUIC对比TCP优势:

握手建连更快

QUIC内部包含了TLS, 它在自己的帧会携带TLS里的记录, 再加上QUIC使用的是TLS1.3, 因此仅需1个RTT就可以同时完成建立与密钥协商, 甚至第二次连接的时候, 应用数据包和QUIC握手信息一起发送, 达到0-RTT的效果. 

而HTTP/1和HTTP/2协议, TCP和TLS都是分层的, 分别在内核的传输层和openssl的表示层, 所以要先进行TCP握手(1-RTT), 在进行TLS握手(2RTT), 所以需要3-RTT的延迟才能传输数据. 

QUIC建连时间大约0~1 RTT,在两方面做了优化:

1)传输层使用了UDP,减少了1个RTT三次握手的延迟。

2)加密协议采用了TLS 协议的最新版本TLS 1.3,相对之前的TLS 1.1-1.2,TLS1.3允许客户端无需等待TLS握手完成就开始发送应用程序数据的操作,可以支持1 RTT和0RTT。

对于QUIC协议,客户端第一次建连的握手协商需1-RTT,而已建连的客户端重新建连可以使用之前协商好的缓存信息来恢复TLS连接,仅需0-RTT时间。因此QUIC建连时间大部分0-RTT、极少部分1-RTT,相比HTTPS的3-RTT的建连,具有极大的优势。

避免队首阻塞的多路复用

QUIC同样支持多路复用,QUIC的流与流之间完全隔离的,互相没有时序依赖。如果某个流出现丢包,不会阻塞其他流数据的传输和应用层处理,所以这个方案并不会造成队首阻塞。

支持连接迁移

什么是连接迁移?举个例子,当你用手机使用蜂窝网络参加远程会议,当你把网络切换到WLAN时,会议客户端会立马重连,视频同时出现一瞬间的卡顿。这是因为,TCP采用四元组(包括源IP、源端口、目标地址、目标端口)标识一个连接,在网络切换时,客户端的IP发生变化,TCP连接被瞬间切断然后重连。连接迁移就是当四元组中任一值发生变化时,连接依旧能保持,不中断业务。QUIC支持连接迁移,它用一个(一般是64位随机数)ConnectionID标识连接,这样即使源的IP或端口发生变化,只要ConnectionID一致,连接都可以保持,不会发生切断重连。

可插拔的拥塞控制

QUIC是应用层协议,用户可以插拔式选择像Cubic、BBR、Reno等拥塞控制算法,也可以根据具体的场景定制私有算法。

Quic使用可插拔的拥塞控制,相较于TCP,它能提供更丰富的拥塞控制信息。比如对于每一个包,不管是原始包还是重传包,都带有一个新的序列号(seq),这使得Quic能够区分ACK是重传包还是原始包,从而避免了TCP重传模糊的问题。Quic同时还带有收到数据包与发出ACK之间的时延信息。这些信息能够帮助更精确的计算RTT。此外,Quic的ACK Frame 支持256个NACK 区间,相比于TCP的SACK(Selective Acknowledgment)更弹性化,更丰富的信息会让client和server 哪些包已经被对方收到。

QUIC 的传输控制不再依赖内核的拥塞控制算法,而是实现在应用层上,这意味着我们根据不同的业务场景,实现和配置不同的拥塞控制算法以及参数。GOOGLE 提出的 BBR 拥塞控制算法与 CUBIC 是思路完全不一样的算法,在弱网和一定丢包场景,BBR 比 CUBIC 更不敏感,性能也更好。在 QUIC 下我们可以根据业务随意指定拥塞控制算法和参数,甚至同一个业务的不同连接也可以使用不同的拥塞控制算法。

前向纠错(FEC: Fowrard Error Correcting)

QUIC支持前向纠错,弱网丢包环境下,动态的增加一些FEC数据包,可以减少重传次数,提升传输效率。

如果接收端出现少量(不超过FEC的纠错能力)的丢包或错包,可以借助冗余纠错码恢复丢失或损坏的数据包,这就不需要再重传该数据包了,降低了丢包重传概率,自然就减少了拥塞控制机制的触发次数,可以维持较高的网络利用效率。

QUIC连接

QUIC也是需要三次握手来建立连接的, 目的是为了协商连接ID. 协商好连接ID后, 后续双方都只需要连接ID,就可以实现连接迁移的问题了. 并且QUIC传输过程中的Packet Number是每个报文独一无二的编号, 它是严格递增的. 

为什么要这样设计?

这个设计是为了解决TCP重传的一个歧义问题. 例如下图所示, 当TCP发生超时重传的时候, 客户端发起了重传, 客户端发起了重传, 然后收到了来自服务器的确认ACK. 但是客户端原始报文和重传报文序号都是一样的, 所以服务器回复的都是相同的ACK.

所以, 客户端是无法知道哪个是原始的报文, 哪个是重传的报文的. 这样RTT就会有误,

  • 如果计算为原始的报文, 但是实际上是重传的响应, 那么RTT会变大
  • 如果计算为重传的报文, 但是实际上是原始的响应, 那么RTT会变小

RTO(超时时间)是通过RTT来计算的, 如果RTP不准, 那么重传的概率也会变大.

所以, QUIC这样的传输方式可以准确的计算出RTT, RTO的计算也是准确的. 如下图所示

QUIC解决TCP队头阻塞问题

TCP的队头阻塞问题其实就是出现在接收窗口的队头阻塞问题

当接收方收到的是有序数据时, 接收窗口才会滑动, 然后那些已经接收并且被确认的有序数据可以被应用层读取.

但是, 如果接收窗口收到的数据不是有序的, 那么就会阻塞住, 一直等待数据的到达. 这时候就出现了队头阻塞问题.  所以可以的出一个结论: TCP是为了保证数据的有序性

上图所示, QUIC借鉴了HTTP/2里的Stream的概念, 在一个QUIC连接中可以并发发送多个请求

每一个steam都分配了一个独立的滑动窗口, 这样使得一个连接上的多个Stream之间没有任何依赖关系, 都是独立的, 各自控制滑动窗口.

相关文章:

  • DeepSeek眼中的文明印记:山海经
  • 软件评测师 案例真题笔记
  • 黑马程序员TypeScript课程笔记3
  • 电脑安装系统蓝屏的原因
  • 【相机基础知识与物体检测】更新中
  • CMS32M65xx/67xx系列CoreMark跑分测试
  • 应用智能化转型—MCP原理分析
  • dvwa7——SQL Injection
  • MyBatis 的动态 SQL
  • 【Java实用工具类】手撸SqlBuilder工具类,优雅拼接动态SQL,MyBatisPlus同款风格!
  • mybatis打印完整的SQL,p6spy
  • LeetCode 高频 SQL 50 题(基础版) 之 【高级查询和连接】· 下
  • SQL思路解析:窗口滑动的应用
  • 剑指offer15_数值的整数次方
  • JavaScript性能优化实战:从核心原理到工程实践的全流程解析
  • java反序列化:CC5利用链解析
  • 【Python进阶】装饰器
  • SpringBoot接入Kimi实践记录轻松上手
  • 九(5).引用和指针的区别
  • 基于大模型的短暂性脑缺血发作(TIA)全流程预测与诊疗辅助系统详细技术方案
  • 沈阳网站建设方案策划/网络培训学校
  • html5网站制作实战/新手学seo
  • 烟台做网站优化/沈阳seo排名公司
  • 网页设计实训总结万能版1000字/廊坊网站seo
  • 外链 推网站怎么做/阳西网站seo
  • 养生网站建设免费/百度客服怎么联系