免费个人简历制作网站,天津企业网站建设公司,seo的培训班,成都广告公司排名前十名目录
QUIC 是如何实现可靠传输的#xff1f;
Packet Header
QUIC Frame Header
QUIC 是如何解决 TCP 队头阻塞问题的#xff1f;
什么是TCP对头阻塞问题#xff1a;
HTTP/2 的队头阻塞:
没有队头阻塞的 QUIC
QUIC 是如何做流量控制的#xff1f;
QUIC 实现流量控制…目录
QUIC 是如何实现可靠传输的
Packet Header
QUIC Frame Header
QUIC 是如何解决 TCP 队头阻塞问题的
什么是TCP对头阻塞问题
HTTP/2 的队头阻塞:
没有队头阻塞的 QUIC
QUIC 是如何做流量控制的
QUIC 实现流量控制的方式
QUIC 对拥塞控制改进
QUIC 更快的连接建立
QUIC 是如何迁移连接的 已经有基于 UDP 协议实现的可靠传输协议的成熟方案了那就是 QUIC 协议已经应用在了 HTTP/3。 QUIC 是如何实现可靠传输的
要基于 UDP 实现的可靠传输协议那么就要在应用层下功夫也就是要设计好协议的头部字段。 Packet Header
首次建立连接时和日常传输数据时使用的 Header 是不同的.
QUIC 也是需要三次握手来建立连接的主要目的是为了协商连接 ID。QUIC 报文中的 Pakcet Number 是严格递增的 即使是重传报文它的 Pakcet Number 也是递增的这样就能更加精确计算出报文的 RTT。
QUIC 使用的 Packet Number 单调递增的设计可以让数据包不再像 TCP 那样必须有序确认QUIC 支持乱序确认当数据包Packet N 丢失后只要有新的已接收数据包确认当前窗口就会继续向右滑动。 QUIC Frame Header
QUIC 通过单向递增的 Packet Number配合 Stream ID 与 Offset 字段信息可以支持乱序确认而不影响数据包的正确组装摆脱了TCP 必须按顺序确认应答 ACK 的限制解决了 TCP 因某个数据包重传而阻塞后续所有待发送数据包的问题。
QUIC 是如何解决 TCP 队头阻塞问题的
什么是TCP对头阻塞问题
其实就是接收窗口的对头阻塞问题接收方收到的数据必须是在接收窗口范围内如果收到超过窗口范围的数据就丢弃数据 当接收窗口收到有序数据时接收窗口才能往前滑动然后那些已经接收并且被确认的「有序」数据就可以被应用层读取。 当接收窗口收到的数据不是有序的比如收到第 3340 字节的数据由于第 32 字节数据没有收到 接收窗口无法向前滑动那么即使先收到第 3340 字节的数据这些数据也无法被应用层读取的。只有当发送方重传了第 32 字节数据并且被接收方收到后接收窗口才会往前滑动然后应用层才能从内核读取第 3240 字节的数据。 TCP 必须按序处理数据也就是 TCP 层为了保证数据的有序性只有在处理完有序的数据后滑动窗口才能往前滑动否则就停留停留「接收窗口」会使得应用层无法读取新的数据。
HTTP/2 的队头阻塞:
HTTP/2 通过抽象出 Stream 的概念实现了 HTTP 并发传输一个 Stream 就代表 HTTP/1.1 里的请求和响应。不同 Stream 的帧是可以乱序发送的因此可以并发不同的 Stream 因为每个帧的头部会携带 Stream ID 信息所以接收端可以通过 Stream ID 有序组装成 HTTP 消息而同一 Stream 内部的帧必须是严格有序的。
是 HTTP/2 多个 Stream 请求都是在一条 TCP 连接上传输这意味着多个 Stream 共用同一个 TCP 滑动窗口那么当发生数据丢失滑动窗口是无法往前移动的此时就会阻塞住所有的 HTTP 请求这属于 TCP 层队头阻塞。
没有队头阻塞的 QUIC
QUIC 也借鉴 HTTP/2 里的 Stream 的概念在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (Stream)。 QUIC 给每一个 Stream 都分配了一个独立的滑动窗口,各自控制的滑动窗口
QUIC 是如何做流量控制的
TCP 流量控制是通过让「接收方」告诉「发送方」它接收方的接收窗口有多大从而让「发送方」根据「接收方」的实际接收能力控制发送的数据量。
QUIC 实现流量控制的方式
通过 window_update 帧告诉对端自己可以接收的字节数这样发送方就不会发送超过这个数量的数据。通过 BlockFrame 告诉对端由于流量控制被阻塞了无法发送数据。 TCP 的接收窗口在收到有序的数据后接收窗口才能往前滑动 QUIC 是基于 UDP 传输的而 UDP 没有流量控制因此 QUIC 实现了自己的流量控制机制。 QUIC 的 每个 Stream 都有各自的滑动窗口不同 Stream 互相独立队头的 Stream A 被阻塞后不妨碍 StreamB、C的读取。
QUIC 对拥塞控制改进
QUIC 协议当前默认使用了 TCP 的 Cubic 拥塞控制算法。QUIC 是处于应用层的应用程序层面就能实现不同的拥塞控制算法不需要操作系统不需要内核支持可以针对不同的应用设置不同的拥塞控制算法。
QUIC 更快的连接建立
QUIC 内部包含了 TLS它在自己的帧会携带 TLS 里的“记录”再加上 QUIC 使用的是 TLS1.3因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商甚至在第二次连接的时候应用数据包可以和 QUIC 握手信息连接信息 TLS 信息一起发送达到 0-RTT 的效果。
QUIC 是如何迁移连接的
TCP传输协议使用HTTP协议通过四元组确定一条TCP连接。
QUIC 协议没有用四元组的方式来“绑定”连接而是通过连接 ID来标记通信的两个端点客户端和服务器可以各自选择一组 ID 来标记自己因此即使移动设备的网络变化后导致 IP 地址变化了只要仍保有上下文信息比如连接 ID、TLS 密钥等就可以“无缝”地复用原连接消除重连的成本没有丝毫卡顿感达到了连接迁移的功能。
