AI智能
改变未来

为什么HTTP/3要基于UDP?可靠吗?

[TOC]

推荐阅读:

  • 计算机网络汇总

HTTP/3

竟然是基于

UDP

的!开始我也很疑惑,

UDP

传输不可靠,没有拥塞机制,究竟怎么操作呢?

先说解决方案:

QUIC(Quick UDP Internet Connection)是谷歌制定的一种基于UDP的低时延的互联网传输层协议 !

QUIC很好地解决了当今传输层和应用层面临的各种需求,包括处理更多的连接,安全性,和低延迟。

前言

有关于 TCP 和 UDP “连接”这个词,是一个逻辑中的“虚拟”的概念,是为了方便我们的学习理解。

UDP的无连接,TCP的连接,唯区别是,UDP把只管发送,TCP每次都对发送的数据进行ACK确认。

这部分代码是放在传输层,还是放在应用层,这都关系不大。

QUIC是可以独立于操作系统发行的,避免了操作系统缓慢的更新换代问题。

QUIC依然要面对消息的可靠性、滑动窗口、拥塞控制等问题,你可以认为它就是一个TCP(但是本质不一样)。

Chromium 官方宣布 Chrome正在部署到 HTTP/3 与IETF QUIC。

为什么转用UDP?

因为TCP本身非常复杂,并且有太多历史遗留的包袱。

TCP协议,目前已经被编码到了操作系统,不论是协议升级,还是Bug修复,都是一个大工程。

选择了

UDP

, UDP是一张白纸,它只是IP协议的一个编程接口。

  • HTTP3创造出Connection ID概念实现了连接迁移,通过融合传输层、表示层,既缩短了握手时长,也加密了传输层中的绝大部分字段,提升了网络安全性。

  • HTTP3在Packet层保障了连接的可靠性,在QUIC Frame层实现了有序字节流,在HTTP3 Frame层实现了HTTP语义,这彻底解开了队头阻塞问题,真正实现了应用层的多路复用。

  • QPACK使用独立的单向Stream分别传输动态表编码、解码信息,这样乱序、并发传输HTTP消息的Stream既不会出现队头阻塞,也能基于时序性大幅压缩HTTP Header的体积。

HTTP/3解决了那些问题?

  • HTTP3基于UDP协议重新定义了连接,在QUIC层实现了无序、并发字节流的传输,解决了队头阻塞问题(包括基于QPACK解决了动态表的队头阻塞);

  • HTTP3重新定义了TLS协议加密QUIC头部的方式,既提高了网络攻击成本,又降低了建立连接的速度(仅需1个RTT就可以同时完成建链与密钥协商);

  • HTTP3 将Packet、QUIC Frame、HTTP3 Frame分离,实现了连接迁移功能,降低了5G环境下高速移动设备的连接维护成本。

队头阻塞问题

HTTP2协议基于TCP有序字节流实现,因此应用层的多路复用并不能做到无序地并发,在丢包场景下会出现队头阻塞问题。

HTTP3采用UDP作为传输层协议,重新实现了无序连接,并在此基础上通过有序的QUIC Stream提供了多路复用。

QPACK编码

与HTTP2中的HPACK编码方式相似,HTTP3中的QPACK也采用了静态表、动态表及Huffman编码。

HTTP/2 没使⽤常⻅的 gzip 压缩⽅式来压缩头部,⽽是开发了 HPACK 算法,HPACK 算法主要包含:

  • 静态字典;(高频头部或者字段,共61种,QPACK中,则上升为98个静态表项)
  • 动态字典;(自行构建。Index 62 起步)动态表编解码方式差距很大
  • Huffman 编码 编码(压缩算法);

客户端和服务器两端都会建⽴和维护「字典」,⽤⻓度较⼩的索引号表示重复的字符串,再⽤ Huffman 编码压缩数据,可达到 50%~90% 的⾼压缩率。

动态表就是将未包含在静态表中的Header项,在首次出现时加入动态表,这样后续传输时仅用数字表示,大大提升了编码效率。

因此,动态表是天然具备时序性的,如果首次出现的请求出现了丢包,后续请求解码HPACK头部时,会被阻塞。

QPACK将动态表的编码、解码独立在单向Stream中传输,仅当单向Stream中的动态表编码成功后,接收端才能解码双向Stream上HTTP消息里的动态表索引。

IOT

物联网时代,移动设备接入的网络会频繁变动,从而导致设备IP地址改变。

对于通过四元组(源IP、源端口、目的IP、目的端口)定位连接的TCP协议来说,这意味着连接需要断开重连。

而HTTP3的QUIC层允许移动设备更换IP地址后,只要仍保有上下文信息(比如连接ID、TLS密钥等),就可以复用原连接。

  • Packet Header实现了可靠的连接。

  • QUIC Frame Header在无序的Packet报文中,基于QUIC Stream概念实现了有序的字节流,这允许HTTP消息可以像在TCP连接上一样传输;

  • HTTP3 Frame Header定义了HTTP Header、Body的格式,以及服务器推送、QPACK编解码流等功能。

为了进一步提升网络传输效率,Packet Header又可以细分为两种:

  • Long Packet Header用于首次建立连接;

  • Short Packet Header用于日常传输数据。

参考

  • https://tools.ietf.org/html/draft-ietf-quic-http-34
  • https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-17
  • https://ably.com/topic/http3?amp%3Butm_campaign=evergreen&%3Butm_source=reddit&utm_medium=referral
  • https://www.nginx.org.cn/article/detail/422
  • https://www.chinaz.com/2020/1009/1192436.shtml
赞(0) 打赏
未经允许不得转载:爱站程序员基地 » 为什么HTTP/3要基于UDP?可靠吗?