HTTP3 QUIC数据包重传机制

原创 已于 2024-06-24 08:12:46 修改 · 1.7k 阅读 · 21 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#http3 #QUIC #重传机制

于 2024-06-24 08:10:46 首次发布

文章目录

1. 数据包编号（Packet Number）

每个 QUIC 数据包都有一个唯一的包编号，这个编号是全局递增的，而不是像 TCP 那样基于字节的序列号。包编号的独立性使得 QUIC 能够快速检测到哪些数据包丢失，并决定需要重传哪些包。

2. ACK 帧和确认机制

QUIC 使用 ACK 帧来确认接收到的数据包，并提供详细的丢包信息。ACK 帧包含以下信息：

  • 已接收数据包的最高包编号。
  • 确认的接收包编号范围。
  • 丢失的包编号。

3. 快速重传和恢复机制

当发送方接收到 ACK 帧后，会根据确认的信息判断哪些数据包需要重传。QUIC 实现了多种重传策略以确保高效的数据传输：

基于时间的重传

  • 超时重传：如果发送方在预期的时间内没有收到某个数据包的确认，会触发超时重传。QUIC 通过计算RTT（往返时间）和网络抖动来动态调整重传超时时间。

基于确认的重传

  • 快速重传：如果接收到的 ACK 帧中表明一个数据包被确认丢失，发送方会立即重传该数据包，而无需等待超时。这种机制类似于 TCP 中的快速重传，但由于 QUIC 的包编号机制，执行更高效。

4. 独立的流和帧

  • QUIC 中的数据传输基于流和帧，每个流都是独立的，包含多个帧。帧的类型包括数据帧、ACK 帧、握手帧等。丢包重传只涉及具体丢失的帧，而不会影响其他流中的帧。这种设计避免了传统 TCP 中的队头阻塞问题。
    在 QUIC 和 HTTP/3 中，数据传输的单位是“包”（packet）和“帧”（frame）

    • QUIC 包（Packet）：QUIC 在 UDP 之上实现，每个 QUIC 包可以包含多个不同类型的帧。包是传输的最小单位，通过网络进行传输。
    • HTTP/3 帧（Frame）：HTTP/3 数据被分割成帧进行传输。帧是 HTTP/3 协议中的数据单元，一个 QUIC 包可以包含多个 HTTP/3 帧

5. 拥塞控制

  • QUIC 实现了现代的拥塞控制算法（如 BBR），确保在网络状况变化时能够动态调整发送速率，优化带宽利用和数据传输效率。QUIC 的拥塞控制机制与重传机制相结合，提高了整体传输性能。

6. 流量控制

  • QUIC 为每个流和整个连接分别实现了流量控制。发送方在发送数据前会检查流量控制窗口，确保不会发送超过接收方处理能力的数据量。这有助于在重传时避免网络拥塞和接收方过载。

QUIC 和 HTTP/3 数据传输示例

流程图示

Client                            Server
   |                                 |
   |--- QUIC Packet 1 (Frame 1,2) -->|
   |--- QUIC Packet 2 (Frame 3,4) -->|
   |--- QUIC Packet 3 (Frame 5,6) -->| (Lost)
   |--- QUIC Packet 4 (Frame 7,8) -->|
   |--- QUIC Packet 5 (Frame 9,10) ->|
   |                                 |
   |<--- ACK (ack=1,2,4,5; lost=3) - |
   |                                 |
   |--- Retransmit QUIC Packet 3 --->|
   |                                 |
   |<--- ACK (ack=3) --------------- |
   |                                 |

①数据包发送过程

  1. 客户端发送 QUIC 包：

    • 客户端发送多个 QUIC 包（包 1、2、3、4、5），每个包包含一个或多个 HTTP/3 帧
    • 包 1、2、4、5 被成功接收，但包 3 丢失（包 3 可能包含 HTTP/3 的数据帧和控制帧）

  2. 服务器接收 QUIC 包：

    • 服务器接收到包 1、2、4、5，并发送 ACK 帧，确认接收的包编号，同时指出包 3 丢失

②丢包检测和重传

  1. 客户端接收 ACK 帧：

    • 客户端接收到服务器的 ACK 帧，包含确认接收到的包编号（1、2、4、5）和丢失的包编号（3）

  2. 客户端触发重传：

    • 客户端检测到包 3 丢失，立即准备重传包 3。由于 QUIC 的快速重传机制，客户端无需等待超时即可重传丢失的包

  3. 客户端重传 QUIC 包 3：

    • 客户端重传包 3，确保丢失的数据能够重新传输到服务器。包 3 仍然包含原始的 HTTP/3 帧，以便服务器进行处理

③数据包确认和传输完成

  1. 服务器接收重传的 QUIC 包 3：

    • 服务器成功接收到重传的包 3，更新接收状态，并发送新的 ACK 帧，确认包编号 3

  2. 客户端接收最终 ACK：

    • 客户端接收到服务器的 ACK 帧，确认所有包已成功传输，传输过程完成
一文看懂QUIC，TLS，HTTP3
ZJQ的博客
07-09 611
TLS协议通过加密、认证和完整性验证等机制，为互联网通信提供了强大的安全保障。在HTTPS等协议中，TLS协议的应用使得网络通信更加安全可靠。随着技术的发展和安全性的提升，TLS协议将继续在网络安全领域发挥重要作用。HTTP/3是基于QUIC（Quick UDP Internet Connections）协议的新一代HTTP协议。QUIC协议由Google于2012年开发，旨在通过优化传输层协议来改进HTTP的性能。HTTP/3是自2015年HTTP/2获得批准以来对HTTP协议的第一次重大升级。
quic java_HTTP3.0(QUIC的实现机制)
weixin_35925956的博客
02-21 2988
回顾HTTP2.0HTTP1.1在应用层以纯文本的形式进行通信，每次通信都要带完整的HTTP的头，而且不考虑pipeli模式的化，每次的过程总是像上面描述的那样一去一回。那样在实时性、并发想上都存在问题头部压缩：HTTP2.0会对HTTP的头进行一定的压缩，将原来每次都要携带的大量key value在两端建立一个索引表，对相同的头只发送索引表中的索引HTTP2.0协议将一个TCP的连接中，切分成多...
关于QUIC协议的连接、重传、多路复用、流量控制
凯凯王的技术生涯
11-23 4019
QUIC协议是基于UDP封住的一个协议
【Linux高级全栈开发】2.2.3 UDP的可靠传输协议QUIC
qq_43714515的博客
06-27 933
本文介绍了基于UDP的可靠传输协议QUIC的核心机制及其与TCP的对比。QUIC通过ACK确认、重传策略、序号机制、数据重排和窗口控制实现可靠性传输，克服了UDP不可靠的特性。文章详细解析了QUIC的ACK机制（累积确认）、重传机制（超时重传和快速重传），以及滑动窗口的流量控制原理。通过对比TCP和UDP的差异，说明UDP在实时性应用中的优势及不足。最后介绍了ARQ协议的三种模式（停等式、回退n帧、选择性重传），分析各自的优缺点及适用场景，为网络协议选择提供参考依据。
新一代基于UDP的低延时网络传输层协议——QUIC
idaretobe的专栏
06-29 343
如果你的 App，在不需要任何修改的情况下就能提升 15% 以上的访问速度。特别是弱网络的时候能够提升 20% 以上的访问速度。如果你的 App，在频繁切换 4G 和 WIFI 网络的情况下，不会断线，不需要重连，用户无任何感知。如果你的 App，既需要 TLS 的安全，也想实现 HTTP2 多路复用的强大。如果你刚刚才听说 HTTP2 是下一代互联网协议，如果你刚刚才关注到 TLS1.3 是一个革命性具有里程碑意义的协议，但是这两个协议却一直在被另一个更新兴的协议所影响和挑战。
TCP抓包工具和QUIC协议 Day9
akashcai的博客
04-11 1232
QUIC 的 每个 Stream 都有各自的滑动窗口，不同 Stream 互相独立，队头的 Stream A 被阻塞后，不妨碍 StreamB、C的读取。QUIC 是基于 UDP 传输的，而 UDP 没有流量控制，因此 QUIC 实现了自己的流量控制机制，QUIC 的滑动窗口滑动的条件跟 TCP 有一点差别，但是同一个 Stream 的数据也是要保证顺序的，不然无法实现可靠传输，因此同一个 Stream 的数据包丢失了，也会造成窗口无法滑动。但是因为 QUIC 处于应用层，所以就可以。
QUIC原理及使用
John_ToStr的博客
12-25 1148
QUIC原理及使用
HTTP的复盘与整理
ChenTest100的博客
04-22 4216
参考笔记 概述 HTTP即超文本传输协议（ HyperText Transfer Protocol），用以浏览器和服务器之间传递数据，HTTP1.0版本是无状态（stateless）的，即同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时相同，服务器不维护任何有关客户端过去所发请求的信息。 HTTP的操作过程 用户点击链接后浏览器分析URL，与对应的服务器建立TCP链接（耗费1RTT）； 服务器持续监听80端口，监听到请求后同意建立连接，与浏览器建立起TCP连接； 浏览器发
quic-protocol:Google对QUIC（HTTP3）协议的纯Java实现
03-19
5. **快速重传和恢复**：QUIC通过使用更灵活的丢包检测和恢复机制，可以更快地处理丢包情况，改善了网络拥塞控制。 6. **版本协商**：QUIC协议支持版本协商，允许协议不断进化和更新，而不会中断现有的连接。 在...
QUIC 和 HTTP/3：提升网络性能的关键技术
陆业聪
09-16 1761
本文深入探讨了现代互联网关键技术 QUIC 和 HTTP/3。文章阐述了它们的起源、设计目标、核心特性，以及与传统协议的区别。同时，文章还分析了 QUIC 和 HTTP/3 的部署现状、性能评估，以及对未来互联网的影响和发展趋势。
QUIC/HTTP3 协议简析
github_36774378的博客
06-29 1854
从 HTTP 的进化历史讲起，细说使用协议的变迁，了解原因发现问题，解码 QUIC 在 HTTP3 中的支撑作用，共同探讨 HTTP3 的未来。 HTTP、HTTP2 和 HTTP3 先和大家来回顾一下 HTTP 的历史，看看 HTTP3 相比 HTTP、HTTP2 都有哪些改进和升级的地方。 HTTP VS HTTP2 多路复用：多路复用时，多文件传输有时只需维护一个 TCP 连接。如果是 HTTP1 协议下，每份资源的传输对应一个 TCP 连接，一般最多只能开启 6 个 TCP 连接来传输多路数据，.
gscan_quic-master.zip
12-08
ctf-wscan-master.zip
计算机网络:HTTP断点重传是什么
三木的博客
05-28 273
断点重传是HTTP/1.1协议支持的特性.实现断点续传的功能,需要客户端记录当前下载的进度,并在需要续传是通知服务端当前要下载的内容.
QUIC不可靠的数据报扩展(An Unreliable Datagram Extension to QUIC)
sjtu_ysw的博客
05-09 1030
QUIC不可靠的数据报扩展 P.S. QUIC出了数据包扩展，允许QUIC数据包丢包而不重传，这样QUIC可以更好地适应低延迟媒体传输场景，例如RTC场景。个人认为这一步其实在向WebRTC靠拢，之前一直有传闻说考虑把WebRTC的底层协议换成QUIC，但是当时存在很多问题，其中一个大问题就是QUIC不允许丢包，会自动进行重传，这在RTC领域明显是不合适的。但是即使QUIC现在支持丢包，要把QUIC放进WebRTC还是要解决相当多的问题，加密的重复？QUIC拥塞控制与WebRTC的拥塞控制配合？另外，替换后
学习笔记_UDP的可靠传输协议QUIC
chuaded的博客
02-11 1814
学习笔记_UDP的可靠传输协议QUIC UDP可靠性设计，解决的是数据实时性问题，流速问题 如何做到可靠性传输 ACK机制 确保对方应答 重传机制 定时机制，重传策略 序号机制 3 2 1 ->2 3 1 对包进行编号 重排机制 2 3 1 -> 3 2 1 根据包的序号进行重排，不是当前的先进行缓存 窗口机制 发送数据给对方，当时对方一直收，导致我的发送缓存区满了 UDP和TCP的区别 UDP每一次必须一次读完，没读完的就丢掉了 选项 UDP TCP 是否连接 无连接 面向
QUIC接收包处理
Hello
09-07 1441
接收包处理： quic_process_packet_interface.h 这个头文件中有个只包含一个类 // A class to process each incoming packet. 意思是一个处理所有到来包的类 class ProcessPacketInterface { public: virtual ~ProcessPacketInterface() {} v...
QUIC的不可靠数据报扩展(RFC9221中文版)
aashuii的博客
03-27 1735
RFC9221 QUIC不可靠数据报扩展
谷歌出品!读懂 QUIC 协议:更快、更高效的通信协议
青玉白露的博客
01-25 4250
在TCP里，如果一个segment传递丢失，那么后续segment乱序到达，也不会被应用层使用，只到丢失的segment重传成功为止，因此TCP实现的HTTP2的多路复用能力受到制约。QUIC解决了上面的歧义问题。与采用Sequence Number 标记不同的是，其使用的Packet Number标记严格单调递增，如果 Packet N 丢失了，那么重传时 Packet 的标识不会是 N，而是比 N 大的数字，比如N+M，这样发送方接收到确认消息时就能方便地知道 ACK 对应的是原始请求还是重传请求。
快速UDP网络连接之QUIC协议介绍
琅嬛福地
06-16 3675
这个算法在多媒 体网关拥塞控制有重要的地位。QUIC的FEC是使用的XOR的方式，即发N + 1个包， 多发一个冗余的包，在正常数据的N个包里面任意一个包丢了，可以通过这个冗 余的包恢复出来，使用异或可以做到切换网络操持连接。由于原始包和重传包的序列号是一样的，客户端不知道服 务器返回的 ACK 包到底是原始包的，还是重传包的。新的传输层协议通常会经过严格的设计，分析和评估可重复的结果，证明候选协议对 现有协议的正确性和公平性，开发新的传输层协议和它在操作系统进行广泛部署之间 通常需要花费数年的时间。
quic如何统计虚假重传
最新发布
07-01
<think>我们正在讨论QUIC协议中的虚假重传统计问题。虚假重传是指实际上不需要的重传，即原始数据包已经到达，但发送方误以为丢失而进行了重传。在QUIC中，我们可以通过以下方式来统计虚假重传： 1. **使用ACK帧信息**：QUIC的ACK帧包含接收方已经接收到的数据包的范围。当发送方收到一个ACK帧，如果该ACK帧确认了之前被标记为丢失的数据包（即该数据包在重传之后才被确认），那么这次重传就可以被标记为虚假重传。2.**利用数据包编号**：QUIC的数据包编号是单调递增的，且每个数据包都有唯一的编号。当发送方重传一个数据包时，它会使用一个新的数据包编号（与原始数据包不同）。这样，当接收方确认这个新的数据包编号时，发送方可以知道这是对重传数据包的确认。但是，如果接收方在重传数据包到达之前就已经确认了原始数据包（即原始数据包只是延迟到达），那么发送方就可以知道这次重传是虚假的。3.**记录重传事件**：发送方需要维护一个重传列表，记录每个被重传的数据包的原始数据包编号和重传数据包编号。当收到一个ACK帧时，检查ACK帧中确认的数据包编号：-如果ACK帧确认了原始数据包（即原始数据包编号），并且这个原始数据包已经被重传过（即在重传列表中），那么这次重传就是虚假的。-如果ACK帧确认的是重传的数据包（即重传数据包编号），那么这次重传是有效的（非虚假）。 4. **处理延迟的ACK**：由于网络延迟，ACK帧可能会延迟到达。因此，发送方需要设置一个合理的等待时间，在收到ACK帧之前不能立即判定重传是虚假的。通常，当发送方收到一个ACK帧确认了原始数据包，而该数据包已经被重传，那么就可以立即判定为虚假重传。5.**统计计数器**：在发送方维护一个计数器，每当检测到一次虚假重传时，计数器增加。下面是一个简化的伪代码示例，说明如何实现虚假重传的统计： ```pythonclassQUICSender:def __init__(self):self.spurious_retrans_count =0self.retransmissions ={}#重传记录：key为原始包编号，value为[重传包编号,是否已被判定为虚假]defon_packet_loss(self,original_packet_number):#当检测到丢包时，进行重传retrans_packet_number =self.allocate_new_packet_number()self.send_retransmission(original_packet_number, retrans_packet_number)#记录重传self.retransmissions[original_packet_number]= [retrans_packet_number,False]def on_ack_received(self, ack_frame):# ack_frame包含确认的数据包编号列表for acked_pnin ack_frame.acked_packets:#检查这个被确认的包是否是一个原始包（即曾经被重传过）ifacked_pnin self.retransmissions:retrans_info =self.retransmissions[acked_pn]ifnot retrans_info[1]:#如果还没有被判定为虚假重传#被确认的是原始包，说明重传是虚假的self.spurious_retrans_count +=1retrans_info[1]= True#标记为已处理#检查这个被确认的包是否是一个重传包（即重传包的编号）#注意：重传包的编号也可能被记录，但这里我们主要关注原始包被确认的情况#另外，我们也可以记录重传包被确认的情况，用于分析重传的有效性，但这不是虚假重传的统计重点#其他方法... ```注意：在实际实现中，还需要考虑重传记录的清理（例如，当原始包和重传包都被确认后，可以清除记录）以及超时处理（避免记录无限增长）。 在QUIC实现中，如Google的QUIC实现（chromium中的quic部分）或LSQUIC（LiteSpeed）中，都有类似的机制来检测和统计虚假重传。 **相关问题**1.在QUIC协议中，如何定义和检测虚假重传？ 2.除了虚假重传，QUIC还有哪些重传机制？ 3. QUIC中如何优化重传策略以减少虚假重传？ 4.虚假重传对QUIC性能有什么影响？</think>### QUIC协议中虚假重传的统计方法 在QUIC协议中，**虚假重传**（Spurious Retransmission）指发送方误判数据包丢失而进行的不必要重传。统计虚假重传的关键在于识别以下场景： > **原始数据包实际未丢失**，但发送方因延迟或误判触发了重传，随后原始数据包被确认。 #### 统计原理与步骤 1. **记录重传事件** 发送方维护重传记录表，包含： ```plaintext | 原始包编号 | 重传包编号 | 重传触发时间 | 是否被标记为虚假 | ``` 2. **检测虚假重传** 当收到接收方的ACK帧时： - 若ACK确认了**原始包编号**（非重传包编号），且该包存在于重传记录中 → 判定为虚假重传 - 示例流程： ```mermaid graph LR A[发送包#100] -->|网络延迟| B[触发重传#200] B --> C[接收方收到#100] C --> D[ACK确认#100] D --> E[标记#200为虚假重传] ``` 3. **计数器更新** 检测到虚假重传时： - 全局计数器 `spurious_retrans_count++` - 关联的拥塞控制算法需调整参数（如增大RTO阈值） #### 技术实现要点 - **唯一包编号机制** QUIC为每个数据包分配唯一递增编号（包括原始包和重传包），避免TCP重传歧义问题[^1]。 - **ACK帧分析** 解析ACK帧中的`Largest Acknowledged`字段，确认原始包是否被接收： ```cpp if (acked_packet == original_packet && retrans_record.exists(acked_packet)) { spurious_retrans_count++; } ``` - **时间窗口判定** 设置合理的时间阈值（如`2 × RTT`），避免过早判定虚假重传。 #### 优化建议 1. **结合Eifel算法** 使用时间戳选项精确计算RTT，降低误判概率[^2]。 2. **动态RTO调整** 虚假重传率超过阈值时自动增大重传超时（RTO）系数： $$ \text{RTO} = \beta \times \text{SRTT} + 4 \times \text{RTT\_var} \quad (\beta \text{可动态调整}) $$ 3. **内核级统计** 在QUIC实现中嵌入调试接口（如Linux内核的`netstat -s`）： ```bash $ netstat -s | grep quic QUIC: 12 spurious retransmissions detected ``` ### 相关问题 1. QUIC协议如何通过唯一包编号解决TCP的重传歧义问题？ 2. 虚假重传率过高会对QUIC性能产生什么影响？ 3. 除了统计虚假重传，QUIC还有哪些拥塞控制优化机制？ 4. 如何在实际网络中验证QUIC的虚假重传统计准确性？ [^1]: QUIC通过唯一包编号避免重传歧义，提升RTT测量精度。 [^2]: QUIC使用基于窗口的拥塞控制算法，ACK帧携带精确接收信息。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值