济南做网站哪家便宜,上海做网站,seo整站优化服务教程,建造网站 备案为什么需要基于 UDP 实现可靠传输
主要是 TCP 协议四个方面的缺陷#xff1a;
升级 TCP 的工作很困难#xff1b;TCP 建立连接的延迟#xff1b;TCP 存在队头阻塞问题#xff1b;网络迁移需要重新建立 TCP 连接#xff1b; 因此#xff0c;基于UDP实现可靠传输并不是重…为什么需要基于 UDP 实现可靠传输
主要是 TCP 协议四个方面的缺陷
升级 TCP 的工作很困难TCP 建立连接的延迟TCP 存在队头阻塞问题网络迁移需要重新建立 TCP 连接 因此基于UDP实现可靠传输并不是重复造轮子而是根据特定的需求和场景选择合适的工具和机制以满足应用程序的要求。 QUIC 协议
现在市面上已经有基于 UDP 协议实现的可靠传输协议的成熟方案了那就是 QUIC 协议已经应用在了HTTP/3。
这次聊聊 QUIC 是如何实现可靠传输的又是如何解决上面 TCP 协议四个方面的缺陷 QUIC 是如何实现可靠传输的
要基于 UDP 实现的可靠传输协议那么就要在应用层下功夫也就是要设计好协议的头部字段。
拿 HTTP/3 举例子在 UDP 报文头部与 HTTP 消息之间共有 3 层头部 Packet Header Packet Header 首次建立连接时和日常传输数据时使用的 Header 是不同的 QUIC 也是需要三次握手来建立连接的主要目的是为了协商连接 ID。协商出连接 ID 后后续传输时双方只需要固定住连接 ID从而实现连接迁移功能。所以你可以看到日常传输数据的 Short Packet Header 不需要在传输 Source Connection ID 字段了只需要传输 Destination Connection ID。 Short Packet Header 中的 Packet Number 是每个报文独一无二的编号它是严格递增的也就是说就算 Packet N 丢失了重传的 Packet N 的 Packet Number 已经不是 N而是一个比 N 大的值。 为什么这样子设计 TCP 在重传报文时的序列号和原始报文的序列号是一样的也正是由于这个特性引入了 TCP 重传的歧义问题。当 TCP 发生超时重传后客户端发起重传然后接收到了服务端确认 ACK 。由于客户端原始报文和重传报文序列号都是一样的那么服务端针对这两个报文回复的都是相同的 ACK。 这样的话客户端就无法判断出是「原始报文的响应」还是「重传报文的响应」这样在计算 RTT往返时间 时应该选择从发送原始报文开始计算还是重传原始报文开始计算呢 RTO 超时时间是基于 RTT 来计算的那么如果 RTT 计算不精准那么 RTO 超时时间也会不精确这样可能导致重传的概率事件增大。 QUIC 报文中的 Pakcet Number 是严格递增的 即使是重传报文它的 Pakcet Number 也是递增的这样就能更加精确计算出报文的 RTT。 另外还有一个好处单调递增的设计可以让数据包不再像 TCP 那样必须有序确认支持乱序确认当数据包Packet N 丢失后只要有新的已接收数据包确认当前窗口就会继续向右滑动这样就不会因为丢包重传将当前窗口阻塞在原地从而解决了队头阻塞问题。
QUIC Frame Header
一个 Packet 报文中可以存放多个 QUIC Frame。 每一个 Frame 都有明确的类型针对类型的不同功能也不同自然格式也不同。
我这里只举例 Stream 类型的 Frame 格式Stream 可以认为就是一条 HTTP 请求它长这样 在前面介绍 Packet Header 时说到 Packet Number 是严格递增即使重传报文的 Packet Number 也是递增的既然重传数据包与丢失数据包编号并不一致我们怎么确定这两个数据包的内容一样呢 所以引入 Frame Header 这一层丢失的数据包和重传的数据包 Stream ID 与 Offset 都一致说明这两个数据包的内容一致。这些数据包传输到接收端后接收端能根据 Stream ID 与 Offset 字段信息将 Stream x 和 Stream xy 按照顺序组织起来然后交给应用程序处理。
QUIC 是如何解决 TCP 队头阻塞问题的
在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (Stream)。 但是 QUIC 给每一个 Stream 都分配了一个独立的滑动窗口这样使得一个连接上的多个 Stream 之间没有依赖关系都是相互独立的各自控制的滑动窗口。 假如 Stream2 丢了一个 UDP 包也只会影响 Stream2 的处理不会影响其他 Stream与 HTTP/2 不同HTTP/2 只要某个流中的数据包丢失了其他流也会因此受影响。 QUIC 是如何做流量控制的 QUIC 是基于 UDP 传输的而 UDP 没有流量控制因此 QUIC 实现了自己的流量控制机制QUIC 的滑动窗口滑动的条件跟 TCP 有一点差别但是同一个 Stream 的数据也是要保证顺序的不然无法实现可靠传输因此同一个 Stream 的数据包丢失了也会造成窗口无法滑动。 QUIC 的 每个 Stream 都有各自的滑动窗口不同 Stream 互相独立队头的 Stream A 被阻塞后不妨碍 StreamB、C的读取。而对于 HTTP/2 而言所有的 Stream 都跑在一条 TCP 连接上而这些 Stream 共享一个滑动窗口因此同一个Connection内Stream A 被阻塞后StreamB、C 必须等待。
QUIC 实现了两种级别的流量控制分别为 Stream 和 Connection 两种级别 Stream 级别的流量控制Stream 可以认为就是一条 HTTP 请求每个 Stream 都有独立的滑动窗口所以每个 Stream 都可以做流量控制防止单个 Stream 消耗连接Connection的全部接收缓冲。 Connection 流量控制限制连接中所有 Stream 相加起来的总字节数防止发送方超过连接的缓冲容量。
QUIC 更快的连接建立 对于 HTTP/1 和 HTTP/2 协议TCP 和 TLS 是分层的分别属于内核实现的传输层、openssl 库实现的表示层因此它们难以合并在一起需要分批次来握手先 TCP 握手1RTT再 TLS 握手2RTT所以需要 3RTT 的延迟才能传输数据就算 Session 会话服用也需要至少 2 个 RTT。 HTTP/3 在传输数据前虽然需要 QUIC 协议握手这个握手过程只需要 1 RTT握手的目的是为确认双方的「连接 ID」连接迁移就是基于连接 ID 实现的。 但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层而是QUIC 内部包含了 TLS它在自己的帧会携带 TLS 里的“记录”再加上 QUIC 使用的是 TLS1.3因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商甚至在第二次连接的时候应用数据包可以和 QUIC 握手信息连接信息 TLS 信息一起发送达到 0-RTT 的效果。
如下图右边部分HTTP/3 当会话恢复时有效负载数据与第一个数据包一起发送可以做到 0-RTT下图的右下角 QUIC 平滑迁移连接
基于 TCP 传输协议的 HTTP 协议由于是通过四元组源 IP、源端口、目的 IP、目的端口确定一条 TCP 连接。
那么当移动设备的网络从 4G 切换到 WIFI 时意味着 IP 地址变化了那么就必须要断开连接然后重新建立 TCP 连接。 而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延以及 TCP 慢启动的减速过程给用户的感觉就是网络突然卡顿了一下因此连接的迁移成本是很高的。 QUIC 协议没有用四元组的方式来“绑定”连接而是通过连接 ID来标记通信的两个端点客户端和服务器可以各自选择一组 ID 来标记自己因此即使移动设备的网络变化后导致 IP 地址变化了只要仍保有上下文信息比如连接 ID、TLS 密钥等就可以“无缝”地复用原连接消除重连的成本达到了连接迁移的功能。
